- CI/CD là gì? Sự khác biệt giữa CI và CD?
CI (Continuous Integration): tự động build và test mỗi lần push hoặc mở PR, bắt lỗi lúc còn dễ sửa. CD (Continuous Delivery): CI xanh thì tự deploy lên staging, còn lên production vẫn cần người duyệt. Continuous Deployment: deploy thẳng lên production, không cần…
- GitHub Actions là gì? Cấu trúc của một workflow file?
GitHub Actions là nền tảng CI/CD tích hợp sẵn trong GitHub, kích hoạt bằng event (push, pullrequest, schedule, workflowdispatch). Workflow viết bằng YAML trong .github/workflows/: on khai báo trigger, jobs mặc định chạy song song (dùng needs: nếu muốn tuần tự), mỗi job gồm các…
- Blue-Green deployment và Canary deployment là gì?
- CI/CD pipeline là gì? Frontend project thường cấu hình pipeline gồm những bước nào?
CI/CD (Continuous Integration / Continuous Deployment) là quy trình tự động kiểm tra và deploy code mỗi khi có thay đổi. Pipeline frontend chạy tuần tự để fail-fast: (1) lint + format check (nhanh nhất), (2) type check tsc --noEmit, (3) unit tests với coverage…
- GitLab CI, Jenkins, CircleCI khác gì so với GitHub Actions?
GitHub Actions (built-in GitHub, free cho public repo): YAML trong .github/workflows/, marketplace lớn nhất, ưu tiên cho dự án đã ở GitHub. GitLab CI (built-in GitLab): .gitlab-ci.yml ở root repo, runner self-host miễn phí, auto-DevOps stack đầy đủ — phù hợp self-hosted enterprise. Jenkins (self-hosted,…
- GitOps là gì? ArgoCD và Flux hoạt động thế nào?
GitOps = Git là single source of truth cho cả app code lẫn infrastructure state — cluster tự reconcile để match Git, không có ai kubectl apply bằng tay. Nguyên tắc cốt lõi: (1) Declarative — toàn bộ state mô tả bằng YAML/Helm/Kustomize trong Git;…
- Cách thiết kế CI pipeline fail-fast, hiệu quả về thời gian?
Nguyên tắc: test rẻ chạy trước, test đắt chạy sau, song song hoá tối đa, cache mạnh tay, và chỉ chạy job liên quan tới file vừa đổi. Thứ tự stage (rẻ → đắt), stage sau chỉ chạy khi stage trước xanh: 1. Lint +…
- Quản lý secrets trong CI/CD an toàn như thế nào?
Không bao giờ commit secret vào code, kể cả file .env. Chỗ để đúng là secret store của chính CI (GitHub Secrets, GitLab Variables) hoặc vault tập trung (HashiCorp Vault, AWS Secrets Manager). Cách làm nên theo: - Secret của CI: GitHub Settings → Secrets…
- Rolling, recreate, canary, blue-green deploy: khi nào dùng cái nào?
Rolling update (default K8s Deployment): thay pods dần dần, maxSurge: 25%, maxUnavailable: 25% — zero-downtime, dễ hiểu, hợp với stateless service phần lớn case. Recreate: kill toàn bộ pod cũ trước khi start pod mới — có downtime, dùng khi schema migration không backward-compatible (không…
- Build artifact, immutable image, semantic versioning trong CI/CD?
Build once, deploy many: artifact (Docker image, jar, zip) build 1 lần ở stage CI, promote qua các môi trường (dev → staging → prod) — không bao giờ rebuild từ source ở mỗi môi trường. Tại sao immutable: rebuild ở mỗi env risk subtle…
- Trunk-based development vs Git Flow trong CI/CD hiện đại?
Trunk-based development (TBD): mọi developer commit thẳng vào main (hoặc PR ngắn hạn < 1 ngày), feature flag để hide work-in-progress khỏi user. Phù hợp team CI/CD mature, deploy nhiều lần/ngày, test automation tốt. Git Flow (Vincent Driessen, 2010): branch develop riêng, feature/, release/, hotfix/…
- Pre-commit hooks, lint-staged, husky — CI gate phía client vs phía server?
Client-side hooks (husky + lint-staged): chạy nhanh, kiểm tra cơ bản (format, lint file đã sửa) — UX tốt vì fail trước khi commit. Server-side CI gate: source of truth, không thể bypass — luôn phải có vì hook client có thể --no-verify. husky quản…
- Chaos engineering là gì? Vì sao lại chủ động gây lỗi cho hệ thống?
- Quy trình quét lỗ hổng image nên đặt ở đâu trong CI? Scanner báo hàng trăm CVE thì xử lý thế nào?
- Bạn thiết kế một pipeline CI/CD nhiều stage thế nào? Job nào chạy song song, job nào phải tuần tự?
Nguyên tắc: việc rẻ và hay hỏng đặt trước, việc đắt đặt sau. Một bố cục thường dùng: - Stage 1 (song song): lint, typecheck, unit test — chỉ cần source code, không phụ thuộc nhau. - Stage 2: build → sinh ra một artifact…
- Cache dependency trong CI nên đặt key thế nào? Vì sao phải băm lockfile?
Cache key phải thay đổi khi và chỉ khi tập dependency thay đổi. Cách chuẩn: băm nội dung lockfile (pnpm-lock.yaml, package-lock.json, go.sum, poetry.lock). Hai lỗi hay gặp: 1. Key cố định (key: node-modules) — cache không bao giờ được làm mới, build dùng dependency cũ…
- Làm sao chuyển kết quả build từ job này sang job khác? Artifact khác cache thế nào?
Mỗi job trong CI chạy trên runner riêng, filesystem riêng — file build ở job A không tự có ở job B. Cần đẩy qua artifact. Khác biệt cốt lõi: Artifact Cache --------- Mục đích Truyền kết quả giữa job / lưu để tải về…
- Matrix build là gì? Khi nào cần và cần lưu ý gì để không tốn thời gian?
Matrix cho phép khai báo một job rồi CI tự nhân bản job đó theo tổ hợp các biến — mỗi tổ hợp chạy song song trên runner riêng. Khai báo trên sinh ra 4 job. Dùng khi sản phẩm phải chạy trên nhiều môi…
- Test suite chạy 30 phút làm nghẽn pipeline. Bạn chia chạy song song thế nào?
Chia suite thành shard — mỗi runner chạy một phần rời nhau, rồi gộp kết quả. Hầu hết runner hiện đại (Vitest, Jest, Playwright, pytest-xdist) có sẵn cờ shard nên không cần tự chia file. Điều kiện bắt buộc trước khi song song hoá: -…
- Pipeline thỉnh thoảng đỏ, chạy lại là xanh. Bạn xử lý test flaky thế nào?
Vấn đề lớn nhất không phải một test hỏng, mà là đội mất niềm tin vào CI: khi "đỏ" có thể là nhiễu, người ta bấm rerun theo phản xạ và bỏ qua cả lỗi thật. Quy trình xử lý: 1. Ghi nhận lại, đừng…
- Làm sao chặn merge khi lint / typecheck / coverage không đạt? Cấu hình gate thế nào cho hợp lý?
Gate nằm ở branch protection, không nằm ở workflow. Pipeline chỉ báo cáo trạng thái; nhánh đích mới là nơi quyết định "check này bắt buộc phải xanh mới merge được". Cấu hình tối thiểu cho nhánh chính: - Bật required status checks và chọn…
- Secret trong CI: làm sao chắc chắn nó không lọt ra log?
Secret phải nằm ở secret store của CI (encrypted secrets, GitLab masked variables, Vault), tiêm vào runtime dưới dạng biến môi trường — không bao giờ nằm trong repo, kể cả repo private. CI tự động che secret trong log, nhưng cơ chế này chỉ…
- Cùng một artifact deploy lên dev / staging / production thì config khác nhau xử lý thế nào?
Build một lần, deploy nhiều nơi. Artifact (image) phải bất biến và không chứa bất kỳ giá trị nào phụ thuộc môi trường; khác biệt giữa các môi trường được tiêm lúc chạy, qua biến môi trường / ConfigMap / secret store. Vì sao quan…
- Feature flag giúp tách "deploy" khỏi "release" thế nào? Đánh đổi là gì?
Deploy là đưa code lên server; release là để người dùng thấy tính năng. Feature flag tách hai việc này: code lên production nhưng nhánh mới tắt, bật sau bằng cấu hình, không cần deploy lại. Được gì: - Merge sớm vào nhánh chính →…
- Deploy production xong phát hiện lỗi nghiêm trọng. Bạn rollback trong vài phút bằng cách nào?
Ưu tiên phục hồi dịch vụ trước, điều tra sau. Thứ tự xử lý theo mức rủi ro tăng dần: 1. Tắt feature flag nếu tính năng có flag — vài giây, không đụng tới quy trình deploy. 2. Chuyển traffic về version cũ (blue-green…
- Migration DB đặt ở đâu trong pipeline — trước hay sau khi deploy code? Làm sao deploy không downtime?
- Vì sao nên dùng OIDC thay cho access key dài hạn khi CI deploy lên cloud? Cơ chế hoạt động ra sao?
- PR từ fork chạy CI có rủi ro gì? Bạn cho pipeline chạy an toàn thế nào?
- Monorepo nhiều service: làm sao mỗi PR chỉ chạy job của phần thật sự thay đổi?
- Deploy production cần phê duyệt, thông báo và vết audit. Bạn dựng cơ chế đó trong pipeline thế nào?
- Log, metric và trace mỗi loại trả lời được câu hỏi gì? Khi có sự cố bạn nhìn cái nào trước?
Ba tín hiệu trả lời ba câu hỏi khác nhau, không thay thế cho nhau: - Metric — số liệu tổng hợp theo thời gian (request/s, tỉ lệ lỗi, độ trễ, CPU). Trả lời "có đang hỏng không, hỏng từ lúc nào, mức độ ra…
- Structured log là gì? Correlation id (request id) hoạt động thế nào trong hệ nhiều service?
Structured log là log ghi ra dưới dạng dữ liệu có trường (thường là JSON) thay vì một câu văn xuôi. Nhờ đó hệ thống thu thập log có thể lọc và tổng hợp theo trường mà không phải viết regex vừa rối vừa dễ…
- Các log level dùng thế nào cho đúng? Những gì tuyệt đối không được ghi vào log?
Tiêu chí chọn level: ai sẽ đọc dòng này và họ phải làm gì. - ERROR — đã có việc hỏng cần người xử lý (giao dịch thất bại, không ghi được DB). Nếu ERROR xuất hiện đều đặn mỗi phút mà không ai làm…
- Dashboard cho một service nên có những gì? Sắp xếp ra sao để người trực dùng được lúc 3 giờ sáng?
Mục tiêu của dashboard trực ca không phải "hiển thị mọi metric" mà là trả lời trong 30 giây: service này có ổn không, nếu không thì hỏng ở đâu. Bố cục ba tầng, đọc từ trên xuống: 1. Trải nghiệm người dùng (trên cùng)…
- Chi phí log tăng gấp nhiều lần sau khi lên production. Bạn cắt giảm thế nào mà vẫn debug được?
Chi phí log tỉ lệ với khối lượng nhân thời gian lưu. Cắt theo thứ tự tác động, không cắt bừa: 1. Bỏ log không ai đọc. Phần lớn dung lượng đến từ INFO/DEBUG lặp lại trong vòng lặp nóng (hot loop) và access log…
- Vì sao không được đặt `user_id` (hay `request_id`) làm label của metric? Cardinality là gì?
Cardinality là số chuỗi thời gian (time series) riêng biệt mà một metric sinh ra. Với Prometheus, mỗi tổ hợp giá trị label là một chuỗi riêng, lưu riêng, đánh chỉ mục riêng. Metric đầu có route (vài chục) nhân status (vài giá trị) →…
- RED và USE method là gì? Khi nào dùng cái nào?
Hai bộ khung chọn metric, khác nhau ở đối tượng đo. RED — đo dịch vụ (góc nhìn người dùng gửi request vào): - Rate: số request mỗi giây. - Errors: số/tỉ lệ request thất bại. - Duration: phân bố độ trễ (p50/p95/p99). Áp cho…
- Trace nối được xuyên nhiều service nhờ cơ chế gì? Qua message queue thì làm sao giữ được trace?
Nhờ context propagation: trace context được truyền kèm request chứ không phải suy ra từ log. Với HTTP: chuẩn W3C Trace Context dùng header traceparent chứa traceid (chung cho cả trace) và spanid của span hiện tại (đóng vai trò parent cho chặng sau). Service…
- OpenTelemetry giải quyết vấn đề gì? Gồm những thành phần nào?
Trước OpenTelemetry, mỗi nhà cung cấp giám sát có agent và SDK riêng. Đổi từ vendor này sang vendor khác nghĩa là sửa code trong toàn bộ service. OpenTelemetry tách việc sinh dữ liệu (instrumentation) khỏi nơi lưu và hiển thị (backend) bằng một chuẩn…
- Vì sao nên alert theo triệu chứng thay vì theo nguyên nhân? Cho ví dụ cụ thể.
Alert theo triệu chứng là cảnh báo dựa trên thứ người dùng cảm nhận: tỉ lệ lỗi, độ trễ, không đặt được đơn. Alert theo nguyên nhân dựa trên trạng thái nội bộ: CPU 80%, số pod giảm, cache miss tăng. Ba vấn đề của…
- Alert fatigue là gì? Bạn giảm nó bằng cách nào? Multi-window multi-burn-rate hoạt động ra sao?
- Error budget dùng để quyết định điều gì? SLO đặt 100% có được không?
- Quy trình xử lý một sự cố production diễn ra thế nào? Vì sao giảm thiểu phải đi trước khắc phục nguyên nhân?
- Postmortem không đổ lỗi (blameless) là gì? Một postmortem tốt gồm những phần nào?
