Hôm nay mình có đọc được chia sẻ từ một DevOps Architect đi phỏng vấn ở Atlassian, một trong những ông lớn của làng làm tool cho Dev, các bác hẳn đều biết rồi. Nhìn xong cũng phải thốt lên là nó chất hơn nước cất luôn các bác. Đây không phải là mấy câu hỏi kiểu lý thuyết suông, mà toàn là “thực chiến” đâm thẳng vào những vấn đề đau đầu nhất khi vận hành hệ thống lớn.
Mình chia sẻ lại đây cho các bác cùng xem và chiêm nghiệm, coi là để lên được level Architect ở những công ty top đầu thì cần những gì nhé.

Vòng 1: Infra, Kubernetes, và Cloud Patterns (45 phút) – Vòng gửi xe nhưng “căng đét”
Ngay từ vòng đầu đã toàn những câu hỏi đòi hỏi kinh nghiệm sâu và tư duy thiết kế hệ thống. Không có chuyện chỉ biết dăm ba câu lệnh kubectl
là qua được đâu.
- Thiết kế cluster EKS multi-tenant: Làm sao để các team dev, QA, prod dùng chung một cluster mà không dính dáng gì tới nhau? Cách isolate tài nguyên, network, permission thế nào cho chuẩn?
- Quản lý Kustomize overlays: Khi có hơn 10 cái Kustomize overlays, làm thế nào để quản lý mà không bị drift hay duplicate?
- Bảo mật S3 replication cross-region: Giải thích cách bác bảo mật việc nhân bản dữ liệu S3 giữa các region khác nhau và làm sao để xác thực tính data integrity khi scale.
- Xử lý lỗi systemd trong container: Khi
systemd
trên một node container gặp lỗi, chuyện gì sẽ xảy ra? Bác sẽ tự động phục hồi nó như thế nào? - Phát hiện và ngăn chặn tấn công lateral movement: Chiến lược này để detect và minimize việc một pod bị chiếm quyền và từ đó mitigate các pod khác trong cùng cluster.
- Upgrade zero-downtime cho stateful workload: Các bác sẽ dùng Helm 3 để nâng cấp một ứng dụng có trạng thái stateful mà không gây ra downtime cho service như thế nào?
- Kiến trúc hybrid cloud routing: Mô tả một kiến trúc routing giữa GCP và AWS. Bác sẽ đặt các enforce boundaries ở đâu để kiểm soát traffic và security?
- Khôi phục Terraform state: Chẳng may file state của Terraform bị corrupt trong lúc đang migration backend. Chiến lược rebuild của bác là gì?
- Thử tài Bash One-liner: Viết một dòng lệnh Bash để tìm tất cả các container đang chạy và sử dụng memory RSS lớn hơn 500MB trên một node.
Vòng 2: “Dập lửa” thực tế, RCA, và Chaos Control (75 phút) – Màn đấu trí cân não
Vòng này là để kiểm tra bản lĩnh xử lý troubleshooting. Toàn là những kịch bản oái oăm mà các bác đi làm kiểu gì cũng đã từng toát mồ hôi.
- Lỗi TLS handshake trên ALB: Một config mới trên AWS ALB gây ra lỗi TLS handshake lúc được lúc không. Trình bày toàn bộ quá trình RCA của bác.
kubectl logs
không ra gì: Các node k8s vẫn báo “healthy”, nhưng lệnhkubectl logs
vào các pod quan trọng thì lại trống trơn. Chuyện gì đang xảy ra vậy?- Sidecar agent gây CPU throttling: Bác vừa deploy một con sidecar để ghi log, tự nhiên CPU throttling tăng đột biến. Diagnose và rollback thế nào cho an toàn?
- Autoscaling không hoạt động: CPU đã vượt ngưỡng từ lâu mà autoscaling không thèm “nhảy”. Lỗi nằm ở đâu: hệ thống metrics, HPA, hay API server?
- Người dùng báo lỗi 504 Gateway Timeout: User cuối báo lỗi 504 liên tục, nhưng health check của ELB vẫn báo “xanh lè”. Quy trình khoanh vùng và xử lý sự cố của bác là gì?
- Mất log của systemd journal: Log của
systemd journal
trên một vài AMI biến mất sạch sau khi reboot. Bác sẽ kiểm tra những gì trong quá trình build image và boot? - Pod bị OOMKilled nhưng không có log: Một pod quan trọng ở môi trường production bị “OOMKilled” (chết do hết RAM) nhưng không tìm thấy một dòng log nào. Bác sẽ “điều tra” ở forensic-level như thế nào?
- Kernel panic trên node GKE: Một node trên GKE bị “kernel panic” ngay giữa lúc đang deploy. Làm sao để xác định nguyên nhân là do infra, do base image, hay do chính app?
Vòng 3: Tầm nhìn Leader, Nguyên tắc Vận hành (30 phút) – Tầm vóc của một Architect
Vòng cuối không hỏi sâu về kỹ thuật nữa, mà là về tư duy, chiến lược và khả năng làm việc với con người. Đây chính là thứ phân biệt một Senior Engineer và một Architect.
- Cấp quyền cho Developer: Làm thế nào để thiết kế một hạ tầng vừa cấp quyền cho dev tự do sáng tạo, vừa không cung cấp cho họ quyền kiểm soát?
- Checklist cho custom AMI: Trước khi duyệt một custom AMI lên production, checklist ở tầng Linux của bác gồm những gì?
- Chuyển đổi sang Service-Mesh: Bác được yêu cầu chuyển từ mô hình logging tập trung sang mô hình observability dựa trên service-mesh. Bác sẽ phân tích các yếu tố được và mất như thế nào?
- Chaos Engineering: Bác mô phỏng chaos ở production trong môi trường staging cho kubernetes như thế nào?
- Bảo vệ SLOs: Khi các chỉ số SLOs (Service Level Objectives) mà bác đặt ra có nguy cơ làm chậm tiến độ của dự án và bị leader phản đối, bác sẽ xử lý ra sao?
Nhìn chung, đây là những câu hỏi cực kỳ chất lượng, không chỉ kiểm tra kiến thức mà còn cả kinh nghiệm và tầm nhìn. Để pass được những vòng này, khả năng là không chỉ cần vững về tool, mà phải hiểu sâu về bản chất của hệ thống, từ kernel Linux, networking, cho đến cách tổ chức và con người vận hành nó.
Nếu các bác muốn mình sẽ làm riêng bài viết để trả lời những câu hỏi phỏng vấn này dựa theo kinh nghiệm thực tế của mình đi làm cũng khoảng chục năm trong nghề để cùng học hỏi với các bác có thể sẽ giúp bác nào chưa có nhiều trải nghiệm sẽ thêm được giá trị nhất định. Hy vọng bài chia sẻ này giúp các bác có thêm cái nhìn về yêu cầu của thị trường ở những vị trí cấp cao.