Phỏng vấn DevOps ngày nay ít hỏi "Docker là gì" mà hay đặt bạn vào tình huống: deploy xong hệ thống chậm gấp năm lần, pod khởi động lại liên tục, production sập lúc 3 giờ sáng. Bài này gom 30 câu hỏi dạng tình huống theo 6 nhóm: triển khai, CI/CD, hạ tầng và mở rộng, Kubernetes, giám sát, bảo mật và sự cố. Mỗi câu có gợi ý những ý cần nói. Nếu bạn cần ôn kiến thức nền theo từng khái niệm, bộ 50 câu hỏi phỏng vấn DevOps và câu hỏi phỏng vấn Docker là phần bổ trợ.
Khi trả lời, hãy mô tả trình tự hành động và lý do của từng bước. Người phỏng vấn muốn thấy bạn ưu tiên khôi phục dịch vụ, giảm rủi ro và để lại hệ thống tốt hơn sau sự cố.
Nhóm 1: Chiến lược triển khai
1. Thiết kế quy trình deploy không gián đoạn và rollback được trong vài phút
Các ý chính: build một lần thành artifact hoặc image có gắn phiên bản, deploy cùng artifact đó qua các môi trường; chạy nhiều bản sau load balancer và thay dần từng bản; có health check để chỉ chuyển traffic khi bản mới sẵn sàng; giữ bản cũ để rollback bằng cách chuyển traffic hoặc deploy lại image trước đó; tách thay đổi database ra khỏi thay đổi code để rollback code không phá dữ liệu. Có thể bật tắt tính năng mới bằng feature flag thay vì phải rollback cả bản.
2. Blue-green, rolling và canary khác nhau, chọn thế nào?
Rolling thay dần các bản cũ bằng bản mới, tiết kiệm tài nguyên nhưng có lúc hai phiên bản cùng chạy. Blue-green dựng nguyên một môi trường mới song song rồi chuyển toàn bộ traffic, rollback rất nhanh nhưng tốn gấp đôi tài nguyên trong lúc chuyển. Canary cho một phần nhỏ người dùng dùng bản mới trước, theo dõi số đo rồi tăng dần, an toàn nhất cho thay đổi rủi ro nhưng cần hệ thống giám sát tốt để biết khi nào dừng.
3. Migration database mà không gây downtime
Dùng mẫu mở rộng rồi thu hẹp (expand and contract): bước 1 thêm cột hoặc bảng mới theo cách tương thích ngược; bước 2 deploy code ghi cả hai nơi, đọc nơi cũ; bước 3 chuyển dữ liệu cũ sang theo lô nhỏ; bước 4 chuyển sang đọc nơi mới; bước 5 mới xóa cột cũ. Tránh thao tác khóa bảng lâu trên bảng lớn, chạy migration ngoài giờ cao điểm và luôn có bản sao lưu đã kiểm tra khôi phục.
4. Deploy xong CPU tăng vọt, thời gian phản hồi gấp 5 lần, debug theo thứ tự nào?
Trước hết giảm thiệt hại: nếu có tương quan rõ với bản deploy, rollback ngay rồi điều tra sau. Sau đó so sánh số đo trước và sau deploy, xem diff code và cấu hình (thay đổi kích thước pool kết nối, tắt cache, query mới), xem trace của request chậm, kiểm tra database có query mới chạy chậm không, lấy profile CPU của bản mới trên môi trường thử. Cuối cùng thêm kiểm thử hiệu năng vào pipeline để lần sau bắt được sớm hơn.
5. Làm sao đảm bảo bản build hôm nay giống hệt bản đang chạy production?
Khóa phiên bản phụ thuộc bằng file lock, dùng image nền có tag cố định hoặc digest thay vì latest, build trong môi trường container sạch, gắn mã commit vào artifact, lưu artifact vào registry và deploy đúng artifact đó thay vì build lại cho từng môi trường. Hạ tầng cũng nên khai báo bằng code (Terraform, Helm) để tái tạo được.
Nhóm 2: Pipeline CI/CD
6. Pipeline CI/CD cho hệ thống traffic lớn nên có những bước nào?
Thường gồm: kiểm tra định dạng và lint; unit test; build artifact; quét bảo mật phụ thuộc và image; integration test; deploy lên môi trường staging; smoke test hoặc kiểm thử đầu cuối quan trọng; phê duyệt nếu cần; deploy production theo canary hoặc rolling; kiểm tra số đo sau deploy và tự rollback nếu vượt ngưỡng. Bạn có thể dựng nhanh khung workflow để luyện với công cụ tạo GitHub Actions.
7. Rút thời gian build từ 20 phút xuống 5 phút bằng cách nào?
Đo xem bước nào tốn thời gian trước. Các cách hay dùng: cache thư viện phụ thuộc và lớp Docker; sắp xếp Dockerfile để lớp ít thay đổi nằm trên; chạy song song các nhóm test; chỉ build và test phần bị ảnh hưởng trong monorepo; dùng runner mạnh hơn cho bước nặng; tách test chậm sang pipeline chạy định kỳ thay vì mỗi commit.
8. Thiết kế pipeline để lỗi lộ ra sớm (fail fast)
Đặt bước nhanh và hay lỗi nhất lên đầu: lint, kiểm tra kiểu, unit test. Dừng pipeline ngay khi một bước lỗi thay vì chạy tiếp. Chạy kiểm tra cơ bản ngay khi mở pull request. Thông báo lỗi rõ ràng về đúng người, kèm link tới log.
9. Quản lý secret trong CI/CD sao cho không bị lộ?
Không đưa secret vào mã nguồn hay file cấu hình trong repo. Dùng kho secret của nền tảng CI hoặc dịch vụ quản lý secret, cấp quyền theo môi trường, ẩn giá trị trong log. Ưu tiên danh tính tạm thời (OIDC) để pipeline lấy quyền truy cập cloud ngắn hạn thay vì khóa truy cập dài hạn. Bật quét secret trong repo và có quy trình thu hồi khi lỡ lộ.
10. Khi nào nên tách nhiều pipeline thay vì một pipeline lớn?
Khi các phần của hệ thống có vòng đời phát hành khác nhau, khi pipeline chung quá chậm làm mọi đội phải chờ nhau, khi quyền deploy cần tách theo đội, hoặc khi một số bước chỉ cần chạy định kỳ. Đánh đổi là khó quản lý phụ thuộc giữa các phần, nên cần quy ước phiên bản và kiểm thử tương thích.
Nhóm 3: Hạ tầng và mở rộng
11. Khi nào chọn container thay vì máy ảo?
Container khởi động nhanh, nhẹ, đóng gói ứng dụng cùng phụ thuộc nên chạy giống nhau ở mọi môi trường, hợp với dịch vụ stateless và mở rộng nhanh. Máy ảo cách ly mạnh hơn ở mức hệ điều hành, hợp với phần mềm cũ, khối lượng cần kernel riêng hoặc yêu cầu bảo mật cao. Thực tế container thường chạy trên máy ảo.
12. Hệ thống bắt đầu với 1 server, mở rộng lên hàng triệu người dùng thế nào?
Đi từng bước theo điểm nghẽn đo được: tách database ra máy riêng; thêm load balancer và nhiều bản ứng dụng stateless; thêm CDN cho nội dung tĩnh và cache cho dữ liệu đọc nhiều; thêm bản sao đọc cho database; chuyển việc nặng sang hàng đợi; tự động mở rộng theo tải; cuối cùng mới tính đến nhiều vùng hoặc chia nhỏ dữ liệu.
13. Mở rộng dọc và mở rộng ngang chọn theo tiêu chí gì?
Mở rộng dọc nhanh, không đổi kiến trúc, hợp khi tải tăng vừa phải hoặc thành phần khó phân tán (database). Mở rộng ngang cần ứng dụng stateless nhưng chịu lỗi tốt và co giãn theo tải. Tiêu chí: chi phí, giới hạn phần cứng, khả năng chịu lỗi, độ phức tạp vận hành.
14. Thiết kế hệ thống sẵn sàng 99,9% trở lên
99,9% tương đương khoảng 43 phút gián đoạn mỗi tháng. Để đạt mức này: nhiều bản ở nhiều vùng sẵn sàng (availability zone), database có bản sao và chuyển đổi dự phòng tự động, health check và tự thay bản lỗi, deploy an toàn có rollback, giám sát và cảnh báo theo SLO. Nhắc thêm rằng mức sẵn sàng của hệ thống bị giới hạn bởi thành phần yếu nhất mà nó phụ thuộc.
15. Triển khai nhiều region có đáng không?
Đáng khi người dùng phân bố toàn cầu và cần độ trễ thấp, khi yêu cầu chịu được mất cả một region, hoặc khi luật yêu cầu dữ liệu nằm ở khu vực nhất định. Cái giá là chi phí, độ phức tạp đồng bộ dữ liệu, xung đột ghi và quy trình vận hành. Nhiều hệ thống chỉ cần nhiều zone trong một region cộng với sao lưu sang region khác.
Nhóm 4: Kubernetes
16. Pod khởi động lại liên tục, kiểm tra gì trước?
Chạy kubectl describe pod để xem sự kiện và lý do (OOMKilled, CrashLoopBackOff, lỗi kéo image), kubectl logs --previous để xem log của lần chạy trước khi chết. Các nguyên nhân hay gặp: vượt giới hạn bộ nhớ, liveness probe quá khắt khe khiến pod bị giết khi đang khởi động, thiếu biến môi trường hoặc secret, không kết nối được dịch vụ phụ thuộc.
17. Khi nào dùng HPA, khi nào dùng VPA?
HPA (Horizontal Pod Autoscaler) tăng giảm số pod theo CPU, bộ nhớ hoặc số đo tùy chỉnh, hợp với dịch vụ stateless. VPA (Vertical Pod Autoscaler) điều chỉnh request và limit tài nguyên cho từng pod, hợp với khối lượng khó nhân bản hoặc để tìm mức tài nguyên hợp lý. Không nên để cả hai cùng điều khiển theo cùng một số đo CPU hoặc bộ nhớ vì sẽ xung đột.
18. Deploy mà không làm rớt kết nối của người dùng đang hoạt động
Cấu hình readiness probe để pod mới chỉ nhận traffic khi sẵn sàng; dùng preStop hook và thời gian chờ kết thúc đủ dài để pod cũ xử lý xong request đang dở; ứng dụng phải bắt tín hiệu SIGTERM để ngừng nhận việc mới rồi thoát êm; đặt PodDisruptionBudget để luôn còn đủ bản chạy; với WebSocket cần cơ chế kết nối lại phía client.
19. Tối ưu resource request và limit để tránh lãng phí
Đo mức dùng thực tế trong một thời gian rồi đặt request gần mức dùng thường xuyên, limit có khoảng đệm cho lúc cao điểm. Request quá cao làm cụm tưởng đã đầy trong khi máy còn trống; limit bộ nhớ quá thấp gây OOMKilled; limit CPU quá chặt gây chậm do bị bóp. Có thể dùng VPA ở chế độ gợi ý để tham khảo. Khi viết manifest để luyện, công cụ tạo YAML Kubernetes giúp có khung nhanh.
20. Cụm hết tài nguyên khi production đang chạy, xử lý thế nào?
Ưu tiên giữ dịch vụ chính: kiểm tra pod nào đang chiếm nhiều tài nguyên, tạm giảm hoặc dừng tác vụ không quan trọng, dùng PriorityClass để pod quan trọng được xếp lịch trước, thêm node (thủ công hoặc qua cluster autoscaler). Sau sự cố, xem lại request và limit, đặt ResourceQuota theo namespace và cảnh báo sớm khi mức dùng vượt ngưỡng.
Nhóm 5: Giám sát và quan sát hệ thống
21. Cần theo dõi số đo nào để biết hệ thống đang "chết dần"?
Bốn tín hiệu vàng trong tài liệu SRE của Google: độ trễ, lưu lượng, tỷ lệ lỗi và mức bão hòa tài nguyên. Thêm các dấu hiệu tăng chậm: bộ nhớ tăng đều không giảm (rò rỉ), ổ đĩa đầy dần, hàng đợi dài dần, số kết nối database tiến gần giới hạn, chứng chỉ SSL sắp hết hạn.
22. Vì sao ghi log sai cách có thể làm sập hệ thống?
Ghi log quá nhiều ở mức debug làm đầy ổ đĩa, tốn CPU và I/O; ghi log đồng bộ ra đích chậm làm request bị chậm theo; vòng lặp lỗi sinh hàng triệu dòng log trong vài phút; log chứa dữ liệu nhạy cảm gây rủi ro bảo mật. Cách làm đúng: log có cấu trúc, đúng mức, xoay vòng và giới hạn dung lượng, gửi bất đồng bộ, lọc dữ liệu nhạy cảm.
23. Thế nào là cảnh báo vô nghĩa?
Là cảnh báo không cần ai hành động, kêu liên tục rồi tự hết, hoặc báo nguyên nhân thay vì triệu chứng (CPU 80% trong khi người dùng không bị ảnh hưởng). Hậu quả là người trực quen bỏ qua cảnh báo. Nên cảnh báo theo triệu chứng ảnh hưởng người dùng và theo mức tiêu hao error budget, mỗi cảnh báo kèm hướng dẫn xử lý.
24. Tìm nguyên nhân gốc trong hệ thống microservices thế nào?
Dùng distributed tracing với mã theo dõi (trace ID) truyền qua mọi dịch vụ để thấy request đi qua đâu và chậm ở đâu; log có cấu trúc kèm trace ID để nối với trace; dashboard theo từng dịch vụ và phụ thuộc. Tìm thay đổi gần nhất ở dịch vụ liên quan. Sau đó viết báo cáo sau sự cố không quy lỗi cá nhân, tập trung vào việc sửa hệ thống.
25. Phân biệt metrics, logs và traces trong tình huống thực tế
Metrics cho biết có vấn đề (tỷ lệ lỗi tăng từ 14:05). Traces cho biết vấn đề nằm ở đâu (request chậm ở bước gọi dịch vụ thanh toán). Logs cho biết chuyện gì đã xảy ra cụ thể (dịch vụ thanh toán trả lỗi hết thời gian chờ kết nối). OpenTelemetry là chuẩn mở thường dùng để thu cả ba loại dữ liệu.
Nhóm 6: Bảo mật và xử lý sự cố
26. Bảo vệ hạ tầng khỏi tấn công DDoS thế nào?
Đặt dịch vụ sau CDN hoặc dịch vụ chống DDoS của nhà cung cấp; giới hạn tốc độ theo IP và theo người dùng; tường lửa ứng dụng web chặn mẫu tấn công; không để lộ địa chỉ IP gốc của máy chủ; tự động mở rộng có giới hạn chi phí; chuẩn bị sẵn quy trình bật chế độ chống tấn công.
27. Áp dụng nguyên tắc quyền tối thiểu trên cloud ra sao?
Mỗi dịch vụ, mỗi pipeline có danh tính riêng chỉ với quyền cần thiết; không dùng tài khoản gốc cho việc hằng ngày; dùng quyền tạm thời thay khóa dài hạn; tách tài khoản hoặc dự án theo môi trường; rà soát quyền định kỳ và bật nhật ký truy cập để kiểm tra.
28. Thay secret định kỳ mà không gây downtime
Hỗ trợ hai giá trị cùng lúc trong giai đoạn chuyển: tạo secret mới, cấp cho hệ thống phía nhận chấp nhận cả cũ lẫn mới, cập nhật phía gửi sang giá trị mới, kiểm tra không còn ai dùng giá trị cũ rồi mới thu hồi. Ứng dụng nên đọc lại secret mà không cần khởi động lại, hoặc khởi động lại theo kiểu rolling.
29. Production sập lúc 3 giờ sáng, bạn xử lý theo quy trình nào?
Xác nhận sự cố và mức độ ảnh hưởng; báo cho kênh sự cố và chỉ định người điều phối; giảm thiệt hại trước (rollback, chuyển dự phòng, tắt tính năng lỗi); cập nhật trạng thái định kỳ cho các bên liên quan; khi ổn định mới tìm nguyên nhân gốc; viết báo cáo sau sự cố với dòng thời gian, nguyên nhân và việc cần làm để không lặp lại. Có sẵn runbook giúp người trực đêm không phải nghĩ từ đầu.
30. Cả một region của nhà cung cấp cloud ngừng hoạt động, hệ thống sống sót thế nào?
Phụ thuộc vào thiết kế trước đó: có bản sao dữ liệu ở region khác không, mục tiêu thời gian khôi phục (RTO) và lượng dữ liệu chấp nhận mất (RPO) là bao nhiêu, đã diễn tập chuyển region chưa. Các mô hình: sao lưu và khôi phục (rẻ, chậm), bản dự phòng chạy tối thiểu (pilot light), chạy song song nhiều region (nhanh, đắt). Nhấn mạnh rằng kế hoạch chưa từng diễn tập thì gần như chắc chắn sẽ trục trặc khi dùng thật.
Chuẩn bị thế nào cho vòng phỏng vấn DevOps
Dựng một hệ thống nhỏ đầu cuối: ứng dụng đóng gói bằng Docker (có thể bắt đầu từ công cụ tạo Dockerfile), pipeline CI/CD, deploy lên một cụm Kubernetes nhỏ, có giám sát và cảnh báo. Đây là nguồn câu chuyện tốt nhất cho buổi phỏng vấn.
Tập kể sự cố theo khung: chuyện gì xảy ra, bạn làm gì trước, vì sao, kết quả và bài học.
Theo lộ trình nếu đang chuyển nghề: lộ trình DevOps Engineer và khóa học DevOps.
DevOps làm việc sát với đội Backend và QA, nên ôn thêm câu hỏi phỏng vấn Backend và câu hỏi phỏng vấn Tester sẽ giúp bạn trả lời tốt các câu liên quan đến kiểm thử trong pipeline. Nếu cần chỗ dựng môi trường thử miễn phí, xem danh sách dịch vụ có gói miễn phí cho developer.
