PLAYBOOK #1: INFRASTRUCTURE MATURITY & SENIOR SIGNALS
Dành cho: Senior DevOps, SRE, Platform Engineer & Tech Lead
“Hạ tầng không chỉ là code, đó là văn hóa vận hành.” Playbook này giúp bạn đo lường sức khỏe hệ thống, chuẩn bị tâm thế cho các buổi phỏng vấn cấp cao và đặc biệt là cách “đọc vị” doanh nghiệp thông qua văn hóa Ownership.
PHẦN 1: 5 Tín hiệu của một hệ thống trưởng thành
Dành cho Senior để đánh giá nhanh hiện trạng hạ tầng khi tiếp quản hoặc xây dựng mới.
1. Observability 2.0 (Không chỉ là Monitoring)
Tiêu chuẩn: Phải có đủ “The Three Pillars”: Metrics, Logs, và Traces.
Senior Signal: Dashboard được phân tách theo từng Microservice; Alerting được cấu chỉnh theo Symptoms (Triệu chứng) thay vì Causes (Nguyên nhân) để giảm thiểu “Alert Fatigue” (Nhiễu cảnh báo).
Real Check: Bạn có biết ngay lập tức dịch vụ nào bị chậm (Latency) mà không cần kiểm tra từng server không?
2. SLO & Incident Culture (Văn hóa chịu trách nhiệm)
Tiêu chuẩn: Có chỉ số SLI/SLO rõ ràng cho từng dịch vụ thay vì chỉ nói “Uptime 99.9%”.
Senior Signal: Triển khai Blameless Postmortem (Hậu kiểm không đổ lỗi) sau mỗi sự cố. Mọi Incident phải có Action Items được đưa vào Backlog ưu tiên. Có khái niệm Error Budget (Ngân sách lỗi) để cân bằng giữa tốc độ tính năng và độ ổn định.
3. Immutable Infrastructure & GitOps
Tiêu chuẩn: Toàn bộ hạ tầng được quản lý bằng IaC (Terraform, CloudFormation, Pulumi).
Senior Signal: Không có việc chỉnh sửa thủ công trên Console (No Manual Changes). Áp dụng Drift Detection (Phát hiện sai lệch cấu trúc). Mọi thay đổi hạ tầng phải qua Pull Request, có Review và Audit trail rõ ràng.
4. CI/CD & Progressive Delivery
Tiêu chuẩn: Pipeline tự động từ Code đến Deploy.
Senior Signal: Có khả năng Rollback tự động trong dưới 5 phút. Áp dụng các chiến lược deploy an toàn như Canary Release hoặc Blue/Green Deployment để cô lập rủi ro.
5. FinOps & Capacity Planning
Tiêu chuẩn: Có báo cáo chi phí Cloud hàng tháng.
Senior Signal: Có tư duy tối ưu hóa dựa trên Workload (Right sizing, Spot Instances, Reserved Instances). Có khả năng dự báo tài nguyên dựa trên tăng trưởng người dùng (Capacity Thinking).
PHẦN 2: Framework Phỏng Vấn Dành Cho Senior (The Architect Mindset)
Khi phỏng vấn Senior, câu trả lời đúng không quan trọng bằng cách tư duy
1. Công thức: Problem → Constraints → Trade-offs
Đừng ngay lập tức chọn công nghệ ngay (ví dụ: “Dùng K8s đi”). Hãy bắt đầu bằng:
Problem: Vấn đề thực sự là gì? (Scalability, Latency, hay Cost?)
Constraints: Rào cản là gì? (Budget, Team size, Legacy system?)
Trade-offs: Tại sao chọn giải pháp này mà không chọn giải pháp kia? (Ví dụ: Chấp nhận độ trễ để đổi lấy tính nhất quán dữ liệu - CAP Theorem).
2. Tam giác chiến lược: Reliability – Security – Cost
Một Senior luôn phải cân bằng 3 vấn đề này. Tăng Reliability (Độ tin cậy) thường làm tăng Cost (Chi phí). Thêm Security thường làm giảm Velocity (Tốc độ). Bạn ưu tiên vấn đề nào trong bối cảnh nào?
3. Định lượng hóa thành công (Success Metrics)
Hãy dùng ngôn ngữ của số liệu để trả lời:
DORA Metrics: Bạn đã cải thiện Deployment Frequency hay Mean Time to Recovery (MTTR) như thế nào?
Efficiency: Bạn đã giúp giảm bao nhiêu % chi phí hạ tầng hay giảm bao nhiêu % tỉ lệ lỗi (Change Failure Rate)?
PHẦN 3: Reverse Interviewing: Cách Đọc Đúng Tín Hiệu Ownership
Đừng để mình rơi vào một “Ticket Center”. Hãy dùng những câu hỏi này để đánh giá chất lượng của Team bạn sắp gia nhập.
On-call: “On-call rotation được tổ chức như thế nào? Có chính sách bù đắp (Compensation) hay Follow-the-sun không? Expectation ngoài giờ là gì?” (Một team tốt sẽ coi trọng sức khỏe tinh thần của Engineer).
SLO: “Team đang đo lường sự thành công dựa trên SLO cụ thể hay chỉ là uptime chung chung? Nếu Error Budget bị cạn kiệt, team sẽ làm gì?” (Hỏi câu này để biết họ có thực sự làm SRE hay chỉ là DevOps trên danh nghĩa).
Postmortem: “Cho tôi ví dụ về một sự cố nghiêm trọng gần đây nhất. Quy trình Postmortem diễn ra thế nào và ai là người chịu trách nhiệm thực thi các action items?” (Để kiểm tra văn hóa “No blame”).
Autonomy: “Platform team đang vận hành theo mô hình tự phục vụ (Self-service) hay đang hoạt động như một Ticket-based team?” (Senior thực thụ sẽ muốn xây dựng Platform để Dev tự dùng, thay vì đi ngồi tạo Database hộ Dev qua ticket).
4. Tài Liệu Tham Khảo
Nội dung này được biên soạn dựa trên các nguyên tắc từ Google SRE Book - bộ tài liệu chuẩn mực cho việc vận hành hệ thống quy mô lớn
1. Google SRE Books (Bộ sách SRE của Google)
Google cung cấp miễn phí toàn bộ nội dung của bộ sách này trực tuyến. Đây là nơi định nghĩa ra khái niệm SRE (Site Reliability Engineering).
Trang chủ bộ sách: https://sre.google/books/
Site Reliability Engineering (The “Original” SRE Book): Tập trung vào lý thuyết và các nguyên tắc cốt lõi của Google: https://sre.google/sre-book/table-of-contents/
The Site Reliability Workbook: Tập trung vào cách triển khai thực tế (Practical): https://sre.google/workbook/table-of-contents/
Building Secure and Reliable Systems: Cách kết hợp giữa bảo mật và độ tin cậy: https://google.github.io/building-secure-and-reliable-systems/raw/toc.html
2. DORA Report (Báo cáo State of DevOps)
DORA (DevOps Research and Assessment) là tổ chức nghiên cứu uy tín nhất thế giới về hiệu suất DevOps, hiện đã được Google Cloud mua lại. Các chỉ số DORA (DORA Metrics) là tiêu chuẩn để đo lường “maturity” của một team kỹ thuật.
Trang chủ DORA: https://dora.dev/
Báo cáo mới nhất (2024 - 2025): https://cloud.google.com/resources/content/2025-dora-ai-assisted-software-development-report
Hướng dẫn về 4 chỉ số đo lường (The Four Keys): DORA Metrics Guide - https://dora.dev/guides/dora-metrics/
Deployment Frequency
Lead Time for Changes
Change Failure Rate
Failed Service Recovery Time (MTTR)
Job phù hợp
Bạn muốn làm việc trong một môi trường có Engineering Excellence? Xem ngay danh sách các vị trí đang chờ bạn tại các công ty hang đầu trên itguru.vn.