Senior Cloud Engineer (Google Cloud Platform)

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.

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ỳ.

Dùng mô hình landing zone: tách account (AWS), subscription (Azure) hoặc project (GCP) theo môi trường và team để cô lập quyền, chi phí và phạm vi sự cố.

• Quản lý tập trung bằng AWS Organizations, Azure Management Groups, GCP Organization/Folder.
• Áp guardrail ở cấp tổ chức: chặn region không dùng, bắt buộc mã hoá, cấm tắt log audit (SCP, Azure Policy, Organization Policy).
• Đăng nhập tập trung qua SSO, cấp quyền theo nhóm.
• Tài khoản riêng cho log audit và bảo mật, team ứng dụng không xoá được.
• Mạng nối qua hub (Transit Gateway, hub-spoke VNet, Shared VPC).
• Tag bắt buộc để phân bổ chi phí.

Người phỏng vấn muốn nghe: cân bằng giữa tự chủ của team và kiểm soát tập trung.

Ư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.

Multi-cloud có lý do chính đáng nhưng chi phí vận hành rất lớn; cần hỏi rõ mục tiêu trước khi đồng ý.

Lý do hợp lý:

• Yêu cầu pháp lý hoặc khách hàng chỉ định nhà cung cấp.
• Dùng dịch vụ đặc thù tốt nhất của từng bên.
• Công ty sáp nhập, mỗi bên đã dùng một cloud.

Cái giá:

• Đội phải giỏi hai nền tảng, IAM và mạng khác nhau.
• Chi phí truyền dữ liệu giữa cloud.
• Chỉ dùng mẫu số chung, mất lợi thế dịch vụ managed.

Giảm phụ thuộc thường chỉ cần container, Terraform và tránh API độc quyền ở phần lõi.

Người phỏng vấn muốn nghe: biết hỏi "để giải quyết vấn đề gì", không trả lời có/không ngay.

User đại diện cho một người hoặc ứng dụng với credential dài hạn; role là tập quyền được "đội" tạm thời và cấp credential ngắn hạn tự hết hạn.

• Ứng dụng chạy trên cloud nên dùng role gắn vào máy ảo, container, function (instance profile, managed identity, service account).
• CI/CD ngoài cloud dùng OIDC federation để lấy token ngắn hạn, không cần key cố định.
• Áp dụng least privilege: chỉ cấp đúng action trên đúng resource.
• Bật MFA cho người dùng, hạn chế dùng tài khoản root.

Access key trong code dễ lộ qua Git, log, image; một khi lộ thì dùng được tới khi bị thu hồi.

Người phỏng vấn muốn nghe: policy cụ thể, tránh "Action": "*".

Serverless hợp với tải không đều, xử lý theo sự kiện, đội nhỏ không muốn vận hành server; trả tiền theo lượng dùng.

Hợp:

• Xử lý file khi upload, webhook, cron job, API lưu lượng thấp hoặc thất thường.

Cân nhắc:

• Cold start làm tăng độ trễ request đầu.
• Giới hạn thời gian chạy, bộ nhớ, kích thước gói.
• Tải cao và đều thì container/VM thường rẻ hơn.
• Kết nối DB: nhiều instance mở nhiều connection, cần connection pooler hoặc proxy.
• Khó debug và test cục bộ hơn.

Người phỏng vấn muốn nghe: quyết định dựa trên đặc điểm tải và chi phí, không chọn vì "đang hot".

"I'm a backend developer with about three years of experience, mostly working with Java and Spring Boot on payment systems. In my current role, I'm responsible for the reconciliation module and I've worked closely with clients in Japan and Singapore. I enjoy solving performance problems and improving code quality. Now I'm looking for a product-focused team where I can grow into system design, which is why this position caught my attention."

Mẹo: giữ khung hiện tại – quá khứ – tương lai, nói khoảng một phút. Dùng "I'm responsible for…", "I've worked on…" thay vì "I am in charge about…". Đừng mở đầu bằng tên trường hay quê quán.

Trả lời thẳng thắn và cân bằng: sẵn sàng khi thật sự cần, nhưng không coi OT kéo dài là bình thường.

Câu mẫu: "Em sẵn sàng làm thêm khi có việc gấp như sự cố production hay trước một đợt release quan trọng. Nhưng nếu OT diễn ra thường xuyên, em nghĩ cần xem lại cách estimate hoặc phạm vi, và em sẽ chủ động nêu điều đó với team. Em cũng muốn hỏi thêm: ở team mình OT thường xảy ra trong trường hợp nào và được tính như thế nào ạ?"

Đây cũng là lúc bạn tìm hiểu ngược: OT có được trả lương hoặc nghỉ bù theo quy định không, tần suất ra sao. Câu trả lời của họ cho bạn biết nhiều về văn hoá công ty.

Hay sai: hứa "OT thoải mái" để lấy điểm, rồi vào làm mới thấy không chịu nổi.