Question 1

Hãy mô tả một CI/CD pipeline mà bạn đã thiết kế từ đầu. Bạn đã xử lý các bottleneck về tốc độ build và độ tin cậy của pipeline như thế nào?

Accepted Answer

Dùng cấu trúc STAR: (1) Bối cảnh - hệ thống cũ có vấn đề gì, (2) Nhiệm vụ - yêu cầu pipeline mới ra sao, (3) Hành động - các quyết định kỹ thuật cụ thể (cache layer, parallel jobs, artifact reuse), (4) Kết quả - đo bằng số liệu cụ thể (thời gian build giảm bao nhiêu %, tỷ lệ deploy thành công). Nhà tuyển dụng đánh giá ứng viên có kinh nghiệm thực chiến thiết kế CI/CD pipeline, không chỉ biết sử dụng công cụ mà còn hiểu các quyết định kỹ thuật cụ thể đằng sau mỗi lựa chọn. Ứng viên mạnh sẽ đề cập đến chiến lược lưu cache phụ thuộc (ví dụ pnpm store cache trong GitHub Actions), chạy song song các bài kiểm tra, logic dừng sớm khi lỗi, và cách xử lý các bài kiểm tra không ổn định. Điểm cộng nếu ứng viên đề cập đến tích hợp quét bảo mật (SAST/SCA) trong pipeline và giải thích sự khác biệt giữa Continuous Delivery và Continuous Deployment. Nhà tuyển dụng có thể hỏi thêm: 'Bạn xử lý rollback như thế nào khi một bản triển khai gây ra sự cố trên môi trường thực?'

Question 2

Khi một Kubernetes pod liên tục bị CrashLoopBackOff trong môi trường production, quy trình debug của bạn là gì? Hãy dẫn dắt tôi từng bước.

Accepted Answer

Trình bày theo thứ tự triage: (1) `kubectl describe pod` để xem Events và trạng thái container, (2) `kubectl logs --previous` để đọc logs của lần crash trước, (3) Kiểm tra resource limits (OOMKilled?), (4) Kiểm tra liveness/readiness probe configuration, (5) Xem xét image tag và config map/secret thay đổi gần đây. Tìm kiếm ứng viên thể hiện tư duy có hệ thống, không đoán mò. Điểm mạnh: biết dùng `kubectl events --sort-by=.lastTimestamp`, hiểu sự khác biệt giữa OOMKilled và exit code khác, biết dùng `kubectl exec` để debug container còn sống.

Question 3

Công ty bạn có 50 microservices chạy trên Kubernetes và team đang mù quáng về performance - không có observability. Bạn sẽ xây dựng monitoring stack từ đầu như thế nào với budget hạn chế?

Accepted Answer

Trình bày theo 3 trụ cột observability (Metrics, Logs, Traces): (1) Metrics - Prometheus + Grafana (open-source), kube-state-metrics, node-exporter; (2) Logs - tập trung logs với Loki (rẻ hơn ELK) hoặc ELK stack tùy volume; (3) Traces - Jaeger hoặc Tempo. Ưu tiên theo impact: alerts trước, dashboards sau. Ứng viên mạnh sẽ hỏi lại về volume logs và budget trước khi đề xuất giải pháp. Tìm kiếm sự hiểu biết về SLI/SLO (availability, latency, error rate) và cách thiết lập alerting rules thực tế - tránh alert fatigue.

Question 4

Bạn đã triển khai GitOps với ArgoCD chưa? Hãy giải thích sự khác biệt giữa push-based và pull-based deployment, và tại sao GitOps lại phù hợp (hoặc không phù hợp) với môi trường của bạn.

Accepted Answer

Giải thích rõ: Push-based - CI pipeline chủ động push thay đổi lên cluster (ví dụ: kubectl apply sau khi build); Pull-based - ArgoCD agent trong cluster liên tục poll Git repo và sync về trạng thái mong muốn. Ưu điểm pull-based: cluster không cần expose API ra ngoài, audit trail tự nhiên qua Git history, self-healing. Ứng viên xuất sắc sẽ thảo luận về secret management trong GitOps (sealed secrets, external-secrets-operator) vì đây là điểm đau thực tế. Cũng nên hỏi về ApplicationSet cho multi-cluster hoặc multi-tenant deployments.

Question 5

Hãy mô tả cách bạn sẽ thực hiện blue-green deployment cho một ứng dụng stateful (có database) mà không gây downtime và không mất dữ liệu.

Accepted Answer

Chia thành 2 phần: (1) Application layer - hai môi trường Blue/Green song song, load balancer switch traffic, health check trước khi switch; (2) Database layer - đây là phần khó: backward-compatible migrations, expand-contract pattern (thêm cột mới trước, app cũ vẫn chạy được, xóa cột cũ sau), read replicas để test Green trước khi switch. Đây là câu hỏi để lọc kỹ sư DevOps thực sự hiểu về stateful workloads. Tìm kiếm đề cập đến: expand-contract migration pattern, feature flags để gradual rollout, và kế hoạch rollback khi schema đã thay đổi.

Question 6

Bạn đã dùng Terraform hoặc Pulumi để quản lý infrastructure chưa? Kể về một lần terraform state bị corrupt hoặc drift và bạn đã xử lý như thế nào.

Accepted Answer

Cấu trúc: (1) Mô tả cách phát hiện drift (terraform plan output, CloudWatch/monitoring alerts), (2) Phân tích root cause - manual change ngoài Terraform? Race condition? (3) Cách fix: `terraform import` để reconcile, hoặc `terraform state rm` + re-import, (4) Phòng ngừa tương lai: remote state locking (S3 + DynamoDB), không cho phép manual changes, drift detection định kỳ. Ứng viên tốt sẽ chủ động nhắc đến state locking để tránh concurrent runs gây conflict. Điểm cộng nếu biết đến Atlantis hoặc Terraform Cloud cho collaborative IaC workflows.

Question 7

Team bạn đang gặp phải alert fatigue - PagerDuty reo cả đêm với các alert không quan trọng và kỹ sư bắt đầu bỏ qua alert. Bạn sẽ giải quyết vấn đề này như thế nào?

Accepted Answer

Tiếp cận theo 4 bước: (1) Audit - phân loại alert theo actionable vs. noise trong 2 tuần, (2) Triage - tắt hoặc downgrade alert không có runbook, (3) Redesign - tập trung vào symptom-based alerts (user impact) thay vì cause-based alerts, (4) Process - thiết lập review cycle hàng tháng, SLO-based alerting, on-call rotation công bằng với secondary on-call. Đây là câu hỏi kết hợp kỹ thuật và leadership. Tìm kiếm ứng viên hiểu rằng alert fatigue là vấn đề văn hóa và kỹ thuật. Câu trả lời mạnh sẽ đề cập đến 'eliminate before you tune' - xóa alert vô dụng trước khi cố điều chỉnh threshold.

Question 8

Giả sử bạn cần tập trung logs từ 30 servers vào một hệ thống duy nhất để phân tích. Bạn sẽ thiết kế ELK stack như thế nào, và bạn sẽ xử lý vấn đề gì khi scale lên?

Accepted Answer

Kiến trúc: (1) Beats/Fluentd agents trên mỗi server thu thập logs, (2) Logstash hoặc Kafka làm buffer và transform (quan trọng khi có spike), (3) Elasticsearch cluster với hot-warm-cold tiering để tiết kiệm chi phí, (4) Kibana cho visualization và alerting. Thảo luận: index lifecycle management (ILM), shard sizing, và retention policy. Hỏi thêm về tại sao cần Kafka giữa Beats và Logstash (backpressure handling, replay capability). Ứng viên mạnh sẽ đề xuất dùng Loki thay ELK nếu budget hạn chế vì Loki không index toàn bộ log content.