Các câu hỏi trong buổi phỏng vấn DevOps vừa rồi của mình

Thứ 2 vừa rồi mình có đi phỏng vấn tìm chân trời mới, nay nhận mail pass mới tự tin viết bài chia sẻ sau những năm gắn bó với công ty hiện tại. Tuy cũng đã từng ngồi vị trí phỏng vấn nhưng có một vài câu hỏi được hỏi thấy cũng wow. Lúc đó có note lại luôn và nay ngồi viết ra đây cho mọi người có thể tham khảo nhé. Mình cũng có trả lời theo ý nhưng vì là trải nghiệm cá nhân không ai như ai nên mình thấy đưa mọi người tham khảo hướng đi sẽ hợp lý hơn là kể chi tiết dài dòng.

1. Đã từng gặp sự cố nghiêm trọng nhất là gì? Giải quyết ra sao?

Có lần hệ thống gặp lỗi 502 đồng loạt, user login không được, backend CPU thấp nhưng toàn request fail. Sau khi kiểm tra kỹ thì phát hiện:

Sidecar Envoy hết connection pool outbound vì đợt rollout trước đó config max_connections quá thấp.
Lỗi không xuất hiện ngay mà rò rỉ dần sau khoảng 15 tiếng chạy load thật.

Cách xử lý:

Restart toàn bộ pod để reset pool tạm thời.
Patch lại cấu hình sidecar (istio envoyFilter).
Viết lại liveness probe để auto detect số lượng connection bất thường.
Sau đó thêm metric vào Grafana để alert theo pool saturation chứ không chỉ CPU.

2. Làm sao rollback nhanh nhất khi Helm upgrade lỗi mà vẫn đảm bảo version chính xác?

Có 3 bước:

helm rollback <release-name> <revision-number> là nhanh nhất.
Nhưng để đảm bảo rollback đúng version, mình thường dùng helm history để xem image tag, chart version, timestamp.
Ngoài ra, luôn gắn annotation vào mỗi deployment với build_id từ CI/CD để dễ trace log và diff version nhanh hơn khi rollback.

Quan trọng là rollout phải có maxSurge và maxUnavailable cấu hình hợp lý để rollback không gây downtime.

3. Nếu phải build platform để hỗ trợ 10 team dev, sẽ thiết kế hạ tầng CI/CD như nào?

Chắc bài toán kiểu này mọi người đi phỏng vấn cũng hay được hỏi, thì mình thiết kế như sau:

Mỗi team sẽ có project riêng, repo riêng, nhưng CI/CD dùng pipeline template central (DAG hoặc GitHub Actions reusable workflow).
Tạo shared runner (GitLab CI hoặc GitHub Actions) với pre-cached Docker layer, kèm buildkit để build nhanh.
Cho phép team define riêng biến env nhưng phải duyệt qua secret manager (Vault hoặc SSM).
CD sẽ qua ArgoCD sync theo branch/tag, team không được push YAML trực tiếp lên cluster.
Policy bằng OPA để ngăn deploy image không scan hoặc không đúng registry.

Mục tiêu là dev có thể tự deploy, rollback mà không cần gọi DevOps, nhưng vẫn giữ được audit & guardrail.

4. Có kinh nghiệm tách database shared không? Làm thế nào để đảm bảo consistency?

Trước có làm cho hệ thống multi-tenant dùng chung database MySQL, sau đó tách ra vì nhu cầu tenant lớn và dữ liệu cũng khá lớn.

Cách làm:

Dùng CDC (Debezium) để monitor dữ liệu từng tenant khi migrate.
Viết tool read-write routing: đọc từ cả hai nơi (shared + new) nhưng ghi chỉ ghi vào DB mới.
Có step verify record consistency giữa 2 DB.
Trong quá trình migrate, lock các flow critical (như transaction), làm vào low traffic window.
Sau khi tách thành công thì viết lại ORM để map sang DB riêng per-tenant.

5. Làm sao phân biệt được lỗi đến từ code hay từ môi trường?

Câu hỏi này thấy rất hay luôn. Nguyên tắc mình dùng là phân tích theo 4 chiều:

Có deploy mới không? => Nếu có, nghi ngờ code.
Có sự thay đổi infra không? => Nghi hạ tầng.
Có lỗi random hay deterministic? => Lỗi random nghi infra (timeout, DNS), lỗi cố định nghi logic code.
Có correlation với traffic spike không? => Rất có thể là bottleneck infra.

Để chắc chắn, so sánh log/metric giữa các version code và các node khác nhau. Nếu cùng version code mà pod A lỗi còn pod B không => môi trường có vấn đề.

Ngoài ra, nếu hệ thống tracing đã được setup => xem chi tiết flow event

6. Khi hệ thống chạy bình thường nhưng latency tăng bất thường thì điều tra từ đâu?

Câu hỏi này cũng đến từ kinh nghiệm thực tế để trả lời được với mình bắt đầu từ ingress gateway:

Check TLS handshake time, connection open.
Xem có retry hoặc circuit breaker nào trong mesh đang bị trip không.
Check CPU throttling hoặc GC pause nếu app là Java/Node.

Tiếp theo là so sánh latency giữa các hop: frontend => API gateway => backend => DB.

Nếu latency tăng từ DB layer:

Check query slow log, connection pool.
Đôi khi là issue từ DNS hoặc network packet loss, phải dùng mtr để trace.

Nếu không tìm được gì, mình thường dump trace với eBPF hoặc Istio tap để xem real flow.

7. Có policy gì để ngăn người mới phá staging?

Cái này thì chắc mọi người cũng hay gặp quá rồi, và solution mình nghĩ ra áp dụng vào công ty cũ là:

Tạo 2 environment: dev (ai cũng push được) và staging (chỉ CI/CD trigger được).
Dùng ArgoCD để sync staging theo tag không cho merge vào staging branch nếu không có approve.
Giới hạn quyền Helm install chỉ còn service account từ pipeline.
Có alert khi staging có bất kỳ image không nằm trong registry nội bộ.
Và đặc biệt: luôn auto snapshot volume trước khi sync staging (rất nhiều người rollback chết volume rồi mới biết).

8. Từng troubleshoot hệ thống gắn sidecar chưa? Biết cách trace request trong mesh không?

Mình từng dùng Istio, Linkerd, và Envoy standalone và cách mình trace như sau.

Troubleshoot:

Dùng `istioctl proxy-config route ` để check route rule.
Dùng istioctl pc clusters để verify DNS resolve và timeout config.
Dùng Zipkin/Jaeger để trace full flow request.

Một lần sidecar drop toàn bộ request là do outbound policy block port 443 vì rule config sai. Lúc đó, log app không ra gì, chỉ Envoy log báo connection fail. Nếu không quen trace Envoy thì nhìn rất mù mờ.

9. Auto scaling thì từng setup có dùng custom metrics chưa? Scale theo cái gì?

Mình từng scale theo:

Queue depth (SQS/RabbitMQ) => qua Prometheus Adapter
Request per second từ ingress controller log
CPU + concurrent user bằng HPA v2 + KEDA

Custom metric rất mạnh nhưng cũng dễ bị “phản chủ” nếu không cẩn thận window average hoặc set scale threshold sai. Có lần scale vọt từ 5 => 50 replica vì metric spike trong 5 giây do healthcheck timeout, phải thêm cooldown + hysteresis logic để chống false alarm.