Presales Engineer (Cloud, AWS)

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.

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

Tránh two-phase commit giữa các service; thay vào đó dùng Saga kết hợp Outbox pattern.

• Saga: chuỗi transaction cục bộ, mỗi bước có hành động bù trừ nếu bước sau thất bại (vd. đặt hàng → giữ tồn kho → thanh toán; thanh toán lỗi thì hoàn tồn kho, huỷ đơn). Có hai kiểu: choreography (các service phản ứng theo event) và orchestration (một service điều phối, dễ theo dõi hơn khi luồng dài).
• Transactional outbox: ghi thay đổi nghiệp vụ và event vào bảng outbox trong cùng một transaction DB, sau đó tiến trình riêng hoặc CDC đẩy event lên broker. Cách này tránh tình huống DB đã lưu mà event bị mất.
• Consumer phải idempotent (lưu id message đã xử lý) vì event có thể đến nhiều lần.

Người phỏng vấn muốn nghe: bạn chấp nhận eventual consistency và thiết kế trạng thái trung gian rõ ràng cho người dùng, vd. đơn ở trạng thái "đang xử lý".

Tách phần nhận yêu cầu khỏi phần gửi qua hàng đợi, và tách riêng từng kênh để kênh này lỗi không ảnh hưởng kênh khác.

• Notification service nhận yêu cầu, kiểm tra cài đặt và tuỳ chọn tắt thông báo của người dùng, render template, rồi đẩy vào queue theo kênh.
• Worker theo kênh gọi nhà cung cấp (FCM/APNs, email, SMS), retry có backoff, chuyển message lỗi vĩnh viễn sang dead letter queue.
• Ưu tiên: OTP, giao dịch dùng queue riêng, không bị kẹt sau chiến dịch marketing gửi hàng loạt.
• Chống trùng: idempotency key cho mỗi thông báo.
• Giới hạn: rate limit theo nhà cung cấp và theo người dùng; tôn trọng khung giờ yên lặng.
• Lưu trạng thái gửi, mở, lỗi để theo dõi và xử lý token thiết bị hết hạn.

Người phỏng vấn muốn nghe: bạn ước lượng được lưu lượng lúc cao điểm và nêu cách scale worker theo độ dài hàng đợi.

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.

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.

Khác nhau ở chỗ bạn tự quản lý tới tầng nào: IaaS bạn lo từ hệ điều hành trở lên, PaaS bạn chỉ lo code và dữ liệu, SaaS bạn chỉ dùng phần mềm.

• IaaS: máy ảo EC2, Azure Virtual Machines, Compute Engine.
• PaaS: Elastic Beanstalk, Azure App Service, Cloud Run, các DB quản lý sẵn như RDS, Cloud SQL.
• SaaS: email, bộ văn phòng, CRM dùng qua trình duyệt.

Người phỏng vấn muốn nghe: mô hình trách nhiệm chung (shared responsibility). Nhà cung cấp lo hạ tầng vật lý; cấu hình bảo mật, quyền truy cập và dữ liệu vẫn là việc của bạn ở mọi mô hình.

Cần đủ ba nguồn tín hiệu được liên kết với nhau: metrics, logs, traces.

• Metrics: theo phương pháp RED cho service (Rate, Errors, Duration với p95, p99) và USE cho tài nguyên. Cảnh báo dựa trên SLO (vd. tỉ lệ lỗi, độ trễ) thay vì CPU đơn thuần.
• Logs có cấu trúc (JSON), kèm trace_id và request_id để lọc toàn bộ log của một request qua nhiều service.
• Distributed tracing với OpenTelemetry: thấy request đi qua những service nào, chậm ở đoạn nào.
• Dashboard theo từng service, ghi nhận các lần deploy để đối chiếu với thời điểm lỗi.

Khi có sự cố: ưu tiên khôi phục (rollback, tắt feature flag) trước, tìm nguyên nhân gốc sau, rồi viết postmortem không đổ lỗi cá nhân.

Người phỏng vấn muốn nghe: một sự cố thật bạn từng tham gia và điều đã cải thiện sau đó.

Dùng STAR: Situation (bối cảnh), Task (nhiệm vụ), Action (bạn làm gì), Result (kết quả). Phần Action nên chiếm nhiều nhất.

Câu mẫu:

• S: "Lead muốn dùng một thư viện mới cho module báo cáo, em thấy thư viện đó còn ít người dùng và lo về bảo trì."
• T: "Em cần nêu rủi ro mà không làm chậm tiến độ."
• A: "Em gặp riêng anh, đưa so sánh hai phương án và đề xuất làm thử một bản nhỏ trong hai ngày để đánh giá."
• R: "Kết quả thử cho thấy thư viện cũ đáp ứng đủ, anh đồng ý giữ lại. Từ đó team có thói quen làm bản thử trước khi đổi công nghệ."

Người phỏng vấn muốn nghe: bạn tranh luận bằng dữ liệu, tôn trọng người khác, và chấp nhận quyết định cuối cùng kể cả khi không theo ý mình.