Ôn phỏng vấn DevOps & CI/CD

Ôn phỏng vấn

Câu hỏi phỏng vấn DevOps & CI/CD thường gặp (kèm gợi ý trả lời)

Câu hỏi phỏng vấn DevOps hay gặp: Docker, Kubernetes, CI/CD, Terraform, giám sát và xử lý sự cố, kèm gợi ý trả lời ngắn gọn. Gồm 12 câu do Drama Công Ty biên soạn: đọc ý chính rồi tự trả lời bằng ví dụ từ dự án của bạn.

  1. 01Container khác máy ảo (VM) ở điểm nào? Khi nào vẫn nên dùng VM?Junior

    Gợi ý trả lời

    Container dùng chung kernel của máy chủ và cô lập bằng namespace + cgroup, nên khởi động nhanh và nhẹ; VM ảo hoá cả phần cứng và chạy một hệ điều hành riêng.

    • Container: nhẹ, đóng gói ứng dụng cùng thư viện, hợp microservice và CI/CD.
    • VM: cô lập mạnh hơn, chạy được kernel/OS khác (Windows trên host Linux), hợp workload cần ranh giới bảo mật rõ hoặc phần mềm cũ.
    • Thực tế hai thứ thường đi cùng nhau: node Kubernetes chính là các VM trên cloud.

    Hay sai: nói container "an toàn như VM". Container thoát ra host được nếu chạy --privileged hoặc kernel có lỗ hổng.

  2. 02Bạn viết Dockerfile thế nào để image nhỏ, build nhanh và an toàn?Junior

    Gợi ý trả lời

    Ý chính: dùng multi-stage build, sắp xếp layer để tận dụng cache, và không chạy bằng root.

    FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:22-alpine
USER node
COPY --from=build /app/dist /app
    • Copy file khai báo dependency trước, code sau, để đổi code không phải cài lại package.
    • Dùng .dockerignore loại node_modules, .git, file .env.
    • Không nhét secret vào image (kể cả ở layer đã xoá); dùng build secret hoặc biến môi trường lúc chạy.
    • Ghim phiên bản base image, quét lỗ hổng trong pipeline.
  3. 03CI, Continuous Delivery và Continuous Deployment khác nhau thế nào? Một pipeline cơ bản gồm những bước gì?Junior

    Gợi ý trả lời

    CI là tự động build và test mỗi lần merge code; Continuous Delivery là luôn có bản sẵn sàng deploy nhưng lên production cần bấm duyệt; Continuous Deployment thì tự lên production nếu mọi bước đều qua.

    Pipeline cơ bản:

    • Checkout, cài dependency (có cache).
    • Lint, unit test, quét bảo mật (SAST, dependency, secret).
    • Build artifact/image, gắn tag theo commit SHA, đẩy lên registry.
    • Deploy lên staging, chạy smoke/integration test.
    • Deploy production (thủ công hoặc tự động), có cách rollback.

    Người phỏng vấn muốn nghe: build một lần, dùng cùng một artifact cho mọi môi trường; chỉ cấu hình là khác nhau.

  4. 04Trong Kubernetes, Pod, Deployment và Service là gì và liên quan với nhau thế nào?Junior

    Gợi ý trả lời

    Pod là đơn vị chạy nhỏ nhất (một hoặc vài container dùng chung network); Deployment quản lý số bản sao Pod và việc cập nhật; Service cho một địa chỉ ổn định để gọi tới nhóm Pod.

    • Pod có thể chết và được tạo lại với IP mới, nên không gọi trực tiếp IP Pod.
    • Deployment tạo ReplicaSet, hỗ trợ rolling update và rollback.
    • Service chọn Pod theo label (selector), kiểu ClusterIP (nội bộ), NodePort, LoadBalancer.
    • Từ ngoài vào HTTP thường dùng Ingress hoặc Gateway API phía trước Service.

    Hay sai: label của Pod template không khớp selector của Service, khiến Service không có endpoint nào.

  5. 05Pod bị CrashLoopBackOff, bạn điều tra thế nào?

    Gợi ý trả lời

    CrashLoopBackOff nghĩa là container khởi động rồi thoát liên tục; cần tìm lý do nó thoát.

    kubectl describe pod <pod>      # events, exit code, OOMKilled?
kubectl logs <pod> --previous   # log của lần chạy trước khi chết
kubectl get events --sort-by=.lastTimestamp
    • Exit code 137 / OOMKilled: thiếu memory limit hoặc rò rỉ bộ nhớ.
    • Lỗi cấu hình: thiếu biến môi trường, Secret/ConfigMap sai, không kết nối được DB.
    • Liveness probe quá gắt khiến app bị kill khi đang khởi động; cân nhắc startupProbe.
    • Sai lệnh command/args, sai kiến trúc image (arm64 và amd64).

    Người phỏng vấn muốn nghe: quy trình có thứ tự, dựa vào events và log trước khi đoán.

  6. 06Liveness, readiness và startup probe khác nhau thế nào? Cấu hình sai thì hậu quả gì?

    Gợi ý trả lời

    Readiness quyết định Pod có nhận traffic không; liveness quyết định có restart container không; startup probe tạm hoãn hai probe kia cho tới khi app khởi động xong.

    • Readiness fail: Pod bị gỡ khỏi endpoint của Service, không bị restart.
    • Liveness fail: kubelet restart container.
    • Startup probe hợp với app khởi động chậm (JVM, nạp model).

    Lỗi hay gặp:

    • Liveness kiểm tra cả DB bên ngoài: DB chậm là toàn bộ Pod bị restart dây chuyền.
    • Không có readiness: rolling update đẩy traffic vào Pod chưa sẵn sàng, gây lỗi 5xx.

    Người phỏng vấn muốn nghe: liveness chỉ nên kiểm tra chính process còn sống, phần phụ thuộc để cho readiness.

  7. 07Terraform state là gì? Làm việc nhóm với Terraform bạn quản lý state thế nào?

    Gợi ý trả lời

    State là file Terraform ghi lại ánh xạ giữa code và tài nguyên thật; Terraform dựa vào nó để tính plan. Mất hoặc lệch state là nguy cơ tạo trùng hoặc xoá nhầm tài nguyên.

    • Lưu state ở remote backend (S3, GCS, Azure Blob, Terraform Cloud), bật versioning và mã hoá.
    • Bật locking để hai người không apply cùng lúc.
    • Tách state theo môi trường/thành phần để giảm phạm vi ảnh hưởng.
    • Không commit state lên Git: trong đó có thể chứa secret.
    • Chạy plan trong CI cho mỗi PR, apply qua pipeline có duyệt.

    Hay sai: sửa tay trên console rồi quên, tạo drift; nên định kỳ chạy plan để phát hiện.

  8. 08Bạn quản lý secret (mật khẩu DB, API key) trong pipeline và Kubernetes thế nào?

    Gợi ý trả lời

    Nguyên tắc: secret không nằm trong Git, không in ra log, được cấp theo quyền tối thiểu và xoay vòng được.

    • Dùng secret manager (Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) làm nguồn gốc.
    • Đồng bộ vào cluster bằng External Secrets Operator hoặc CSI driver; nếu phải để trong Git thì mã hoá (Sealed Secrets, SOPS).
    • Kubernetes Secret mặc định chỉ base64: bật mã hoá etcd và giới hạn RBAC đọc Secret.
    • CI dùng biến được che (masked), ưu tiên OIDC để lấy credential ngắn hạn thay vì key dài hạn.
    • Bật quét secret khi push code.

    Người phỏng vấn muốn nghe: biết base64 không phải mã hoá, và có kế hoạch xoay key khi bị lộ.

  9. 09So sánh rolling update, blue-green và canary. Bạn chọn chiến lược nào cho hệ thống thanh toán?Senior

    Gợi ý trả lời

    Cả ba đều giảm rủi ro khi deploy nhưng khác ở chi phí và tốc độ phát hiện lỗi.

    • Rolling: thay dần từng Pod, rẻ, mặc định của Deployment; hai phiên bản chạy song song một lúc.
    • Blue-green: dựng nguyên bộ mới, chuyển traffic một lần, rollback tức thì; tốn gấp đôi tài nguyên.
    • Canary: đưa một phần nhỏ traffic sang bản mới, theo dõi metric rồi tăng dần; cần công cụ (service mesh, Argo Rollouts) và metric tốt.

    Với thanh toán, canary kèm tự động rollback theo tỷ lệ lỗi và độ trễ là lựa chọn hợp lý.

    Hay sai: quên migration DB. Schema phải tương thích cả bản cũ lẫn mới (expand rồi mới contract).

  10. 10Production đang lỗi 5xx tăng vọt sau một lần deploy. Bạn xử lý thế nào?Senior

    Gợi ý trả lời

    Ưu tiên khôi phục dịch vụ trước, tìm nguyên nhân gốc sau.

    1. Xác nhận phạm vi qua dashboard: endpoint nào, từ lúc nào, có trùng thời điểm deploy không.
    2. Nếu nghi deploy: rollback ngay (kubectl rollout undo, hoặc revert trong GitOps) thay vì sửa nóng.
    3. Thông báo kênh sự cố, chỉ định người điều phối, ghi lại mốc thời gian.
    4. Sau khi ổn định: so sánh log, trace, diff cấu hình giữa hai phiên bản.
    5. Viết postmortem không đổ lỗi, có hành động phòng ngừa (thêm test, canary, alert).

    Người phỏng vấn muốn nghe: bình tĩnh, có thứ tự, biết giảm thiệt hại trước, và rút kinh nghiệm thành thay đổi quy trình.

  11. 11SLI, SLO và error budget là gì? Bạn đặt alert dựa trên chúng thế nào?Senior

    Gợi ý trả lời

    SLI là chỉ số đo trải nghiệm người dùng (tỷ lệ request thành công, độ trễ p99); SLO là mục tiêu cho SLI đó trong một khoảng thời gian; error budget là phần được phép hỏng còn lại.

    • Ví dụ: SLO 99.9% request thành công trong 30 ngày, nghĩa là budget 0.1% request lỗi.
    • Alert theo burn rate: budget đang bị tiêu nhanh bất thường (đo trên cửa sổ ngắn và dài) thì báo, thay vì báo mỗi khi CPU cao.
    • Hết budget: ưu tiên việc ổn định, chậm lại tính năng mới.

    Hay sai: đặt alert trên nguyên nhân (CPU, RAM) thay vì triệu chứng người dùng thấy, dẫn đến báo động giả và mệt mỏi vì alert.

  12. 12GitOps là gì? Bạn tổ chức repo và quy trình deploy cho nhiều môi trường, nhiều service ra sao?Senior

    Gợi ý trả lời

    GitOps coi Git là nguồn sự thật cho trạng thái hệ thống; một agent trong cluster (Argo CD, Flux) liên tục kéo và đồng bộ, thay vì CI đẩy thẳng bằng kubectl.

    • Tách repo code ứng dụng và repo cấu hình deploy; CI build image rồi mở PR cập nhật tag.
    • Cấu hình dùng chung bằng Helm chart hoặc Kustomize, overlay riêng cho dev/staging/prod.
    • Lên prod qua PR có review; rollback bằng git revert.
    • Bật phát hiện drift và tự sửa lệch cấu hình.
    • CI không cần giữ credential admin của cluster.

    Người phỏng vấn muốn nghe: cân nhắc được đánh đổi, ví dụ secret vẫn cần giải pháp riêng và số lượng PR cập nhật tag có thể nhiều.

Gặp câu hỏi khác khi phỏng vấn? Kể lại ẩn danh để người sau ôn đúng trọng tâm, hoặc xem câu hỏi thật hay gặp ở nhiều công ty.