Senior Site Reliability Engineer (SRE, GCP, Kubernetes)

State là file Terraform ghi lại ánh xạ giữa code và tài nguyên thật; Terraform dựa vào nó để tính plan. Mất hoặc lệch state là nguy cơ tạo trùng hoặc xoá nhầm tài nguyên.

• Lưu state ở remote backend (S3, GCS, Azure Blob, Terraform Cloud), bật versioning và mã hoá.
• Bật locking để hai người không apply cùng lúc.
• Tách state theo môi trường/thành phần để giảm phạm vi ảnh hưởng.
• Không commit state lên Git: trong đó có thể chứa secret.
• Chạy plan trong CI cho mỗi PR, apply qua pipeline có duyệt.

Hay sai: sửa tay trên console rồi quên, tạo drift; nên định kỳ chạy plan để phát hiện.

Nguyên tắc: secret không nằm trong Git, không in ra log, được cấp theo quyền tối thiểu và xoay vòng được.

• Dùng secret manager (Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) làm nguồn gốc.
• Đồng bộ vào cluster bằng External Secrets Operator hoặc CSI driver; nếu phải để trong Git thì mã hoá (Sealed Secrets, SOPS).
• Kubernetes Secret mặc định chỉ base64: bật mã hoá etcd và giới hạn RBAC đọc Secret.
• CI dùng biến được che (masked), ưu tiên OIDC để lấy credential ngắn hạn thay vì key dài hạn.
• Bật quét secret khi push code.

Người phỏng vấn muốn nghe: biết base64 không phải mã hoá, và có kế hoạch xoay key khi bị lộ.

Cả ba đều giảm rủi ro khi deploy nhưng khác ở chi phí và tốc độ phát hiện lỗi.

• Rolling: thay dần từng Pod, rẻ, mặc định của Deployment; hai phiên bản chạy song song một lúc.
• Blue-green: dựng nguyên bộ mới, chuyển traffic một lần, rollback tức thì; tốn gấp đôi tài nguyên.
• Canary: đưa một phần nhỏ traffic sang bản mới, theo dõi metric rồi tăng dần; cần công cụ (service mesh, Argo Rollouts) và metric tốt.

Với thanh toán, canary kèm tự động rollback theo tỷ lệ lỗi và độ trễ là lựa chọn hợp lý.

Hay sai: quên migration DB. Schema phải tương thích cả bản cũ lẫn mới (expand rồi mới contract).

Bắt đầu từ dữ liệu chi phí, không đoán: xem Cost Explorer/Cost Management theo dịch vụ, region, tag và theo ngày để tìm điểm tăng.

Thủ phạm hay gặp:

• Tài nguyên quên tắt: máy dev, ổ đĩa, snapshot, IP tĩnh không gắn máy.
• Data transfer: traffic ra Internet, qua NAT Gateway, giữa AZ/region.
• Log và metric ghi quá nhiều, giữ quá lâu.
• Auto scaling không co lại.

Tối ưu: right-sizing, Savings Plans/Reserved cho tải nền ổn định, spot cho việc chịu ngắt quãng, lifecycle policy chuyển dữ liệu cũ sang lớp lưu trữ rẻ.

Người phỏng vấn muốn nghe: gắn tag bắt buộc và đặt budget alert để phát hiện sớm.

Trình bày theo luồng request và nói rõ điểm lỗi đơn được loại bỏ ở đâu.

• Biên: DNS, CDN cho nội dung tĩnh, WAF.
• Ứng dụng: load balancer L7 trước nhóm container/VM stateless trải nhiều AZ, auto scaling theo CPU hoặc số request.
• Dữ liệu: DB quản lý sẵn Multi-AZ, read replica cho đọc nhiều, Redis làm cache và session.
• Bất đồng bộ: queue cho việc nặng (gửi mail, xử lý ảnh).
• Vận hành: IaC, backup tự động có thử khôi phục, giám sát và alert theo SLO.

Người phỏng vấn muốn nghe: đánh đổi chi phí. 99.9% thường đủ với một region nhiều AZ; multi-region đắt và phức tạp hơn nhiều.

Ưu tiên khôi phục dịch vụ trước, tìm nguyên nhân gốc sau.

1. Xác nhận phạm vi qua dashboard: endpoint nào, từ lúc nào, có trùng thời điểm deploy không.
2. Nếu nghi deploy: rollback ngay (kubectl rollout undo, hoặc revert trong GitOps) thay vì sửa nóng.
3. Thông báo kênh sự cố, chỉ định người điều phối, ghi lại mốc thời gian.
4. Sau khi ổn định: so sánh log, trace, diff cấu hình giữa hai phiên bản.
5. Viết postmortem không đổ lỗi, có hành động phòng ngừa (thêm test, canary, alert).

Người phỏng vấn muốn nghe: bình tĩnh, có thứ tự, biết giảm thiệt hại trước, và rút kinh nghiệm thành thay đổi quy trình.

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.

RPO là lượng dữ liệu tối đa chấp nhận mất (tính theo thời gian); RTO là thời gian tối đa để khôi phục dịch vụ. Hai con số này do nghiệp vụ quyết định và định giá chiến lược.

Từ rẻ đến đắt:

• Backup & restore: sao lưu sang region khác, dựng lại khi cần; RTO hàng giờ.
• Pilot light: dữ liệu được replicate liên tục, chỉ phần lõi chạy sẵn.
• Warm standby: bản thu nhỏ chạy sẵn ở region khác, scale lên khi failover.
• Active-active: nhiều region cùng phục vụ; RTO/RPO gần 0, phức tạp nhất.

Hay sai: có backup nhưng chưa bao giờ thử khôi phục. Kế hoạch DR phải được diễn tập định kỳ.

Cho thấy bạn tách góp ý khỏi cảm xúc cá nhân và biến nó thành hành động.

• Lắng nghe hết, hỏi lại để hiểu ví dụ cụ thể và kỳ vọng.
• Cảm ơn, kể cả khi chưa đồng ý hoàn toàn; nếu có góc nhìn khác, trao đổi bằng thông tin, không phòng thủ.
• Lên kế hoạch cải thiện và chủ động xin phản hồi lại sau một thời gian.

Câu mẫu: "Có lần lead góp ý code review của em quá dài, khó review. Lúc đầu em hơi chột dạ, nhưng em hỏi anh muốn chia thế nào cho dễ. Từ đó em tách pull request nhỏ theo từng thay đổi, thời gian review của team giảm hẳn và em cũng ít bị yêu cầu sửa lại hơn."

Hay sai: nói "em luôn vui vẻ đón nhận mọi góp ý" mà không có ví dụ.