Engineering Manager- (DevOps & SRE)

Quản lý rủi ro là xác định sớm, đánh giá, có kế hoạch ứng phó và theo dõi liên tục.

• Lập danh sách rủi ro (risk register) ngay từ đầu: nhân sự, công nghệ mới, phụ thuộc bên thứ ba, yêu cầu chưa rõ, hạ tầng.
• Đánh giá khả năng xảy ra và mức ảnh hưởng, ưu tiên rủi ro cao.
• Chọn cách ứng phó: tránh, giảm thiểu, chuyển giao, chấp nhận; mỗi rủi ro có người chịu trách nhiệm theo dõi.
• Xem lại trong các buổi họp định kỳ, cập nhật khi tình hình thay đổi.

Ví dụ theo STAR: "API của đối tác chưa sẵn sàng (S), em cần giữ tiến độ tích hợp (T). Em đề xuất team làm mock theo tài liệu API, đồng thời hẹn mốc kiểm tra với đối tác hàng tuần (A). Khi API thật có, phần tích hợp chỉ mất vài ngày điều chỉnh (R)."

Đầu tiên là minh bạch: báo sớm, kèm nguyên nhân và phương án, không chỉ báo tin xấu.

• Đánh giá lại thực trạng: còn bao nhiêu việc, velocity thực tế, đường găng (critical path).
• Đưa các phương án với đánh đổi rõ ràng: cắt bớt phạm vi cho đợt đầu, dời mốc, bổ sung nguồn lực (lưu ý người mới cần thời gian làm quen), song song hoá một số việc.
• Đề xuất một phương án bạn khuyến nghị và lý do.
• Sau khi chốt: kế hoạch mới, mốc kiểm tra gần hơn, báo cáo thường xuyên hơn để lấy lại niềm tin.
• Tìm nguyên nhân gốc để không lặp lại.

Người phỏng vấn muốn nghe: bạn không giấu, không đổ lỗi cho team hay khách, và biết rằng thêm người vào dự án đang trễ thường không giúp kịp ngay.

Không chỉ "đúng hạn, đúng ngân sách", mà còn giá trị mang lại và sức khoẻ của team.

• Dự án: tiến độ theo mốc, chi phí so với ngân sách, phạm vi bàn giao, chất lượng (bug sau release, số lần hotfix), mức hài lòng của khách hàng.
• Sản phẩm: chỉ số gắn với mục tiêu như người dùng hoạt động, tỷ lệ chuyển đổi, tỷ lệ giữ chân, doanh thu, chi phí vận hành giảm.
• Team: tốc độ ổn định, ít OT kéo dài, tỷ lệ nghỉ việc thấp, retrospective có cải tiến thật.

Ví dụ: "Dự án trước bàn giao trễ hai tuần so với kế hoạch ban đầu nhưng khách đã đồng ý từ sớm vì đổi phạm vi; sau go-live ít lỗi nghiêm trọng và khách ký tiếp giai đoạn 2. Em coi đó là thành công."

Hay sai: chỉ nói về output (số tính năng) mà không nói outcome.

SLI là chỉ số đo trải nghiệm người dùng (tỷ lệ request thành công, độ trễ p99); SLO là mục tiêu cho SLI đó trong một khoảng thời gian; error budget là phần được phép hỏng còn lại.

• Ví dụ: SLO 99.9% request thành công trong 30 ngày, nghĩa là budget 0.1% request lỗi.
• Alert theo burn rate: budget đang bị tiêu nhanh bất thường (đo trên cửa sổ ngắn và dài) thì báo, thay vì báo mỗi khi CPU cao.
• Hết budget: ưu tiên việc ổn định, chậm lại tính năng mới.

Hay sai: đặt alert trên nguyên nhân (CPU, RAM) thay vì triệu chứng người dùng thấy, dẫn đến báo động giả và mệt mỏi vì alert.

GitOps coi Git là nguồn sự thật cho trạng thái hệ thống; một agent trong cluster (Argo CD, Flux) liên tục kéo và đồng bộ, thay vì CI đẩy thẳng bằng kubectl.

• Tách repo code ứng dụng và repo cấu hình deploy; CI build image rồi mở PR cập nhật tag.
• Cấu hình dùng chung bằng Helm chart hoặc Kustomize, overlay riêng cho dev/staging/prod.
• Lên prod qua PR có review; rollback bằng git revert.
• Bật phát hiện drift và tự sửa lệch cấu hình.
• CI không cần giữ credential admin của cluster.

Người phỏng vấn muốn nghe: cân nhắc được đánh đổi, ví dụ secret vẫn cần giải pháp riêng và số lượng PR cập nhật tag có thể nhiều.

Phát hiện sớm, nói thật sớm, và chọn phương án cùng team và PO.

• Tìm nguyên nhân: estimate sai, phát sinh việc ngoài kế hoạch, bị block bởi bên khác, có người nghỉ.
• Gỡ block trước: liên hệ team khác, khách hàng, xin môi trường, quyết định nhanh các điểm chờ.
• Cùng PO thương lượng phạm vi: giữ những gì quan trọng nhất cho sprint goal, đẩy phần còn lại sang sprint sau.
• Thông báo cho stakeholder kèm kế hoạch mới, không đợi tới ngày review.
• Retrospective: tìm nguyên nhân gốc để điều chỉnh planning lần sau.

Hay sai: bắt team OT để kịp mà không đổi gì về phạm vi. Làm một lần có thể được, nhưng lặp lại thì chất lượng giảm và người giỏi sẽ nghỉ.

Mỗi yêu cầu "nhỏ" cộng lại thành trễ hạn. Cần quy trình tiếp nhận thay đổi rõ ràng từ đầu dự án.

• Chốt phạm vi bằng tài liệu hoặc backlog đã thống nhất, kèm định nghĩa hoàn thành.
• Mọi yêu cầu mới đi qua một kênh: ghi nhận, đánh giá effort và ảnh hưởng tới mốc bàn giao.
• Đưa lựa chọn cho khách: đổi lấy hạng mục khác, dời mốc, tính thêm chi phí, hoặc để giai đoạn sau.
• Dự án fixed-price: dùng change request có ký duyệt. Dự án time & material: minh bạch ảnh hưởng tới ngân sách.
• Dặn team không nhận yêu cầu trực tiếp từ khách mà không qua PM/PO.

Người phỏng vấn muốn nghe: bạn vẫn giữ được quan hệ tốt với khách. Nói "có, và đây là cái giá" thay vì chỉ nói "không".

Nói chuyện riêng, sớm và dựa trên sự việc trước khi kết luận.

• Chuẩn bị ví dụ cụ thể (task nào, trễ bao lâu, ảnh hưởng gì), tránh nhận xét chung chung kiểu "em làm chậm".
• Hỏi để hiểu nguyên nhân: việc quá sức, thiếu kiến thức, yêu cầu không rõ, vấn đề cá nhân, hay mất động lực.
• Cùng thống nhất kế hoạch: chia task nhỏ hơn, ghép cặp với người kinh nghiệm, check-in thường xuyên hơn, hỗ trợ đào tạo.
• Theo dõi và phản hồi định kỳ. Nếu không cải thiện, phối hợp với line manager/HR theo quy trình của công ty.

Hay sai: góp ý trước cả team, hoặc lẳng lặng giao việc cho người khác làm thay. Cách đó làm người giỏi kiệt sức và vấn đề không được giải quyết.

"I'm working on an e-commerce platform that handles orders for several retail brands. The system is built with microservices on Node.js, using PostgreSQL and Redis, deployed on AWS. My team has six people and we work in two-week sprints. I'm mainly in charge of the order and payment services. Recently, I led the integration with a new payment gateway, from reading the API docs to handling edge cases like timeouts and duplicate callbacks."

Mẹo: đi từ tổng quan (sản phẩm làm gì, cho ai) tới vai trò của riêng bạn. Nói "my team" và "I" rõ ràng để người nghe biết phần nào bạn làm. Không cần kể tên khách hàng nếu bị ràng buộc bảo mật.

Tìm hiểu trước mặt bằng lương cho vị trí và số năm kinh nghiệm (dữ liệu lương trên Drama Công Ty, bạn bè cùng ngành), rồi đưa ra một khoảng có căn cứ.

• Nói rõ gross hay net. Gross là lương trước khi trừ bảo hiểm bắt buộc và thuế thu nhập cá nhân; net là số thực nhận.
• Hỏi tổng thu nhập: lương tháng 13 (không bắt buộc theo luật), thưởng, chu kỳ review lương, bảo hiểm sức khoẻ.
• Lương thử việc theo luật tối thiểu bằng 85% lương chính thức; nhiều công ty trả 100%, cứ hỏi rõ.

Câu mẫu: "Dựa trên kinh nghiệm và mặt bằng thị trường, em mong muốn khoảng X đến Y triệu gross. Em cũng muốn hiểu thêm về thưởng và review lương bên mình."

Hay sai: nói "tuỳ công ty" (dễ bị trả thấp), hoặc khai khống lương hiện tại.