Câu trả lời ngắn: Khi GitHub Actions hoặc GitHub API có thể ngừng hoạt động trong nhiều giờ, hãy chuẩn bị đường CI/CD bên ngoài GitHub, mirror mã nguồn có thể truy cập độc lập, kho artefact hoặc container registry không cùng điểm lỗi, bản sao cấu hình và bí mật cần thiết, cùng runbook chuyển đổi đã được diễn tập.
Đừng xem self-hosted runner là phương án dự phòng hoàn chỉnh. Runner tự quản lý vẫn cần kết nối với GitHub để nhận job và tải phiên bản runner; nếu control plane hoặc Actions API gặp sự cố, runner có thể không nhận được công việc mới (theo docs.github.com).
Bài viết dành cho đội ngũ nhỏ và người mới làm DevOps. Mục tiêu thực tế là giữ ba khả năng: đưa hệ thống về trạng thái an toàn, tạo artefact đáng tin cậy cho một bản phát hành khẩn cấp và quay lại quy trình bình thường mà không tạo lịch sử phát hành trùng lặp. Bài viết không giả định rằng bạn cần xây dựng một nền tảng thay thế có quy mô tương đương doanh nghiệp lớn.
Xác định mức liên tục cần bảo vệ
Trước khi chọn công cụ, hãy quyết định điều gì phải tiếp tục trong outage. Với nhiều đội ngũ, thứ tự ưu tiên hợp lý là:
- Mức 1 – an toàn vận hành: không phát hành tính năng mới, nhưng vẫn rollback về bản ổn định đang chạy.
- Mức 2 – phát hành khẩn cấp: build và triển khai một thay đổi nhỏ đã được con người kiểm tra.
- Mức 3 – liên tục đầy đủ: vẫn chạy tự động lint, unit test, build, scan và deploy gần như bình thường.
Đội ngũ nhỏ nên hoàn thành Mức 1 và Mức 2 trước. Mức 3 chỉ phù hợp khi gián đoạn phát hành gây thiệt hại lớn hoặc hệ thống có yêu cầu thời gian khôi phục nghiêm ngặt. Đây là lựa chọn về mức chấp nhận rủi ro và chi phí vận hành, không phải yêu cầu kỹ thuật giống nhau cho mọi dự án.
| Loại hệ thống | Mục tiêu nên đặt | Giải pháp tối thiểu |
|---|---|---|
| Website hoặc ứng dụng ít thay đổi | Rollback và phát hành khẩn cấp | Lưu image đã ký, runbook triển khai thủ công và quyền khẩn cấp có thời hạn |
| Sản phẩm SaaS đang vận hành | Giữ khả năng sửa lỗi nghiêm trọng | CI/CD thay thế cho nhánh phát hành, registry ngoài GitHub và kiểm tra bắt buộc |
| Hệ thống xử lý giao dịch hoặc dữ liệu quan trọng | Giảm tối đa thời gian ngừng phát hành | Hai đường CI/CD, secret manager độc lập, diễn tập định kỳ và phê duyệt hai người |
Vẽ bản đồ phụ thuộc của pipeline
Lập một bảng cho từng dịch vụ trong quy trình hiện tại. Ghi chủ sở hữu, địa chỉ truy cập, thời gian lưu giữ, quyền cần có và cách kiểm tra. Nếu một mục không có người phụ trách hoặc không có đường truy cập khi GitHub hỏng, đó là điểm lỗi đơn cần xử lý.
| Thành phần | Phụ thuộc thường gặp | Câu hỏi khi outage | Phương án dự phòng |
|---|---|---|---|
| Mã nguồn | GitHub repository, Git clone, pull request | Có lấy được commit đã phê duyệt không? | Git mirror ngoài GitHub hoặc bản sao định kỳ chỉ đọc |
| CI | GitHub Actions workflow | Có chạy test và lint được không? | CI/CD độc lập hoặc script chạy cục bộ với phiên bản cố định |
| Runner | GitHub-hosted runner, self-hosted runner | Runner có nhận job mới không? | Runner do hệ thống CI thay thế điều phối |
| Phụ thuộc build | npm, PyPI, Maven, NuGet, Docker base image | Có tải được package và image không? | Proxy hoặc registry mirror độc lập với điểm lỗi chính |
| Artefact | Actions artifacts, GitHub Packages, image registry | Có lấy được bản đã build để triển khai không? | Kho artefact độc lập, retention rõ ràng và checksum |
| Bí mật | Secrets, signing key, cloud credentials | Có thể xác thực mà không cần GitHub không? | Secret manager và credential khẩn cấp có thời hạn |
| Triển khai | Cloud API, Kubernetes, VM, CDN | Ai được phép triển khai và bằng cách nào? | Runbook thủ công hoặc hệ thống deploy độc lập |
Chuẩn bị đường CI/CD thay thế
Đường thay thế không cần chạy mọi workflow. Route tối thiểu nên lấy đúng commit hoặc gói mã đã được phê duyệt, cài dependency từ nguồn đã kiểm soát, chạy các kiểm tra bắt buộc, tạo artefact bất biến, ghi metadata build và chỉ triển khai sau phê duyệt độc lập.
- Lấy commit cố định từ mirror, không đọc nhánh
mainđang nằm trên GitHub. - Cài dependency từ lockfile, cache hoặc proxy registry đã kiểm soát phiên bản.
- Chạy lint, unit test, kiểm tra dependency và build theo tiêu chí đã định trước.
- Đóng gói artefact hoặc container image với mã phiên bản bất biến.
- Ghi commit SHA, checksum, thời điểm build, phiên bản công cụ và người phê duyệt.
- Chỉ triển khai sau phê duyệt thủ công hoặc cơ chế bảo vệ tương đương.
Control plane, credential và log của đường thay thế phải độc lập với GitHub ở mức phù hợp với mục tiêu liên tục. Một hệ thống CI khác nhưng vẫn lấy mã, secret, image nền và artefact từ cùng một dịch vụ có thể chỉ giảm một phần rủi ro.
Nếu repository dùng reusable workflow hoặc action nội bộ, hãy cố định tham chiếu tới commit SHA thay vì nhánh thay đổi khi gọi chúng; đây là biện pháp tăng tính ổn định và khả năng kiểm toán (theo docs.github.com).
Mẫu chạy khẩn cấp từ mirror
Mẫu dưới đây được chạy trong shell trên máy CI khẩn cấp hoặc máy vận hành đã được phê duyệt, không chạy trong giao diện GitHub. Các script ci/test-required.sh, ci/build-image.sh, ci/verify-release.sh và ci/deploy-approved.sh là thành phần bạn phải chuẩn bị trước; chúng phải trả mã lỗi khác 0 khi kiểm tra hoặc triển khai thất bại.
#!/usr/bin/env bash
set -Eeuo pipefail
: "${MIRROR_URL:?Đặt MIRROR_URL tới Git mirror độc lập}"
: "${COMMIT_SHA:?Đặt COMMIT_SHA của commit đã được phê duyệt}"
: "${IMAGE_REPOSITORY:?Đặt IMAGE_REPOSITORY của registry độc lập}"
: "${IMAGE_TAG:?Đặt IMAGE_TAG bất biến, ví dụ release-abc1234}"
: "${DEPLOY_ENV:?Đặt DEPLOY_ENV, ví dụ staging hoặc production}"
WORKDIR="${WORKDIR:-/tmp/emergency-release-${COMMIT_SHA}}"
IMAGE_REF="${IMAGE_REPOSITORY}:${IMAGE_TAG}"
rm -rf -- "$WORKDIR"
git clone --no-checkout "$MIRROR_URL" "$WORKDIR"
git -C "$WORKDIR" fetch --no-tags origin "$COMMIT_SHA"
git -C "$WORKDIR" cat-file -e "${COMMIT_SHA}^{commit}"
git -C "$WORKDIR" checkout --detach "$COMMIT_SHA"
cd "$WORKDIR"
./ci/test-required.sh
./ci/build-image.sh "$IMAGE_REF"
./ci/verify-release.sh "$IMAGE_REF" "$COMMIT_SHA"
printf 'Đã build và kiểm tra %s từ commit %s.\n' "$IMAGE_REF" "$COMMIT_SHA"
printf 'Chỉ tiếp tục sau phê duyệt theo runbook; môi trường: %s\n' "$DEPLOY_ENV"
./ci/deploy-approved.sh "$IMAGE_REF" "$DEPLOY_ENV" "$COMMIT_SHA"
printf 'Đã gửi triển khai %s tới %s. Hãy kiểm tra health check và log triển khai.\n' "$IMAGE_REF" "$DEPLOY_ENV"Thay các biến môi trường bằng giá trị thật trước khi chạy. Kết quả mong đợi là mã nguồn được checkout ở trạng thái detached tại đúng commit, các bước kiểm tra kết thúc thành công, image có tham chiếu bất biến và script triển khai ghi nhận đúng môi trường. Nếu git fetch không tìm thấy commit, dừng lại; không thay bằng nhánh mới nhất. Nếu bước xác minh hoặc health check thất bại, không tiếp tục phát hành và chuyển sang rollback.
Không đưa token, khóa riêng hoặc mật khẩu vào lệnh, repository hay log. Script triển khai phải lấy credential từ secret manager độc lập, giới hạn quyền theo môi trường và không in giá trị bí mật ra đầu ra chuẩn.
Tách mã nguồn, dependency và artefact khỏi một điểm lỗi
Mã nguồn: tạo mirror định kỳ sang nhà cung cấp hoặc máy chủ Git độc lập. Ghi thời điểm đồng bộ cuối cùng và commit mới nhất đã có trong mirror. Kiểm tra định kỳ cả thao tác clone và việc lấy đúng commit, vì một mirror chưa từng được khôi phục chỉ là giả định.
Artefact: không coi Actions artifact là bản lưu trữ phát hành lâu dài. Với mỗi bản phát hành, lưu image hoặc gói nhị phân vào kho có chính sách retention rõ ràng, kèm commit SHA, checksum, manifest dependency và hướng dẫn rollback.
Dependency: lockfile, cache hoặc proxy registry giúp route khẩn cấp không tự kéo phiên bản mới nhất trong lúc sự cố. Việc build lại với dependency mới có thể tạo artefact khác bản đã kiểm thử; nếu không thể lấy đúng dependency, nên rollback hoặc chờ thay vì bỏ qua kiểm tra.
Kiểm tra chuỗi cung ứng: duy trì quét dependency ngoài thời điểm outage và định trước cách xử lý cảnh báo trước khi phát hành. Nếu đang dùng GitHub Dependabot, có thể xem hướng dẫn bật cảnh báo mã độc Dependabot; tuy nhiên, kế hoạch liên tục không nên chỉ dựa vào một giao diện hoặc API của GitHub.
Chuẩn bị quyền truy cập và bí mật khẩn cấp
- Tạo credential triển khai khẩn cấp có phạm vi quyền hẹp, thời hạn ngắn và chỉ dùng cho môi trường cần thiết.
- Bảo đảm có ít nhất hai người có thể phê duyệt hoặc kích hoạt quy trình, tránh phụ thuộc vào một cá nhân.
- Dùng secret manager độc lập với GitHub, có log truy cập và quy trình thu hồi.
- Bảo vệ khóa ký artefact hoặc image riêng; không chép khóa riêng vào repository, máy cá nhân hoặc file script.
- Duy trì danh sách liên hệ ngoài GitHub để thông báo khi issue, pull request và comment không truy cập được.
Quyền khẩn cấp không nên là token quản trị toàn quyền được lưu trong file văn bản. Sau khi sử dụng, hãy thu hồi hoặc xoay vòng credential, kiểm tra log và ghi lại commit, artefact, người phê duyệt cùng thời điểm triển khai.
Runbook khi GitHub Actions hoặc API bắt đầu lỗi
1. Xác nhận sự cố nền tảng
Kiểm tra trang trạng thái GitHub, thử một yêu cầu API an toàn, ghi thời điểm lỗi và so sánh với repository hoặc workflow khác. Không vội sửa YAML hoặc tạo hàng loạt lần chạy lại khi dịch vụ đang bất ổn.
Nếu API trả mã 403 hoặc 429, hãy phân biệt giới hạn tốc độ với outage. Tôn trọng retry-after, thời điểm reset và dùng backoff tăng dần; tiếp tục gửi request sau khi bị giới hạn có thể làm integration bị chặn (theo docs.github.com).
2. Đóng băng thao tác có thể làm tăng hậu quả
- Tạm dừng auto-deploy, migration dữ liệu và job có tác dụng ghi ngoài hệ thống.
- Không xóa workflow run, artefact hoặc runner để “làm sạch hàng đợi”.
- Ghi lại commit, bản phát hành và thay đổi đang chờ xử lý.
- Thông báo trạng thái cho nhóm phát triển, vận hành và người chịu trách nhiệm sản phẩm qua kênh liên lạc ngoài GitHub.
3. Chọn chế độ vận hành
- Chế độ chờ: dùng khi chưa có nhu cầu phát hành; chỉ giám sát và chuẩn bị rollback.
- Chế độ phát hành khẩn cấp: dùng khi có lỗi nghiêm trọng; chạy route thay thế với commit cố định, kiểm tra tối thiểu và phê duyệt hai người.
- Chế độ thủ công có kiểm soát: chỉ dùng khi route CI thay thế không sẵn sàng; một người build, một người kiểm tra log và artefact, người có quyền riêng mới triển khai.
4. Ghi sổ mọi hành động
Tạo bản ghi ngoài GitHub gồm mã sự cố, thời gian bắt đầu, commit sử dụng, kết quả kiểm thử, checksum artefact, người phê duyệt, lệnh triển khai, kết quả health check và quyết định rollback. Đây là nguồn đối soát khi GitHub hoạt động trở lại.
Khôi phục sau outage và tránh phát hành trùng
Khi GitHub hoạt động bình thường, không lập tức chạy lại mọi workflow. Thực hiện theo thứ tự:
- Đối chiếu workflow đã thành công, thất bại, queued và chưa từng tạo được run.
- So sánh commit đã build trong route dự phòng với commit hiện có trên GitHub.
- Kiểm tra artefact và môi trường sản xuất để tránh triển khai cùng một thay đổi hai lần.
- Chỉ chạy lại workflow cần thiết, ưu tiên commit SHA hoặc sự kiện mới có chủ đích.
- Đánh dấu rõ bản phát hành thủ công trong hệ thống quản lý thay đổi.
- Thu hồi credential khẩn cấp, kiểm tra quyền và lưu log cho post-incident review.
GitHub từng ghi nhận có sự kiện trong thời gian incident không thể tự động replay, vì vậy không nên giả định rằng hệ thống sẽ tự chạy bù. Mỗi workflow quan trọng cần tiêu chí rõ ràng: retry, trigger lại bằng commit mới, hay bỏ qua vì artefact đã được phát hành.
Danh sách kiểm tra trước khi coi kế hoạch hoàn tất
- Có sơ đồ phụ thuộc và chủ sở hữu cho mã nguồn, CI, runner, registry, secret và deploy.
- Có mirror mã nguồn ngoài GitHub và đã kiểm tra cách lấy đúng commit.
- Có artefact hoặc container image ở kho độc lập, kèm checksum và thông tin build.
- Có route build–test–deploy thay thế không cần GitHub Actions control plane.
- Có credential khẩn cấp giới hạn quyền, thời hạn sử dụng và quy trình thu hồi.
- Có runbook với điều kiện chuyển chế độ, người phê duyệt và quy trình rollback.
- Có cơ chế ngăn build từ dependency chưa khóa phiên bản.
- Đã diễn tập với tình huống GitHub API không phản hồi và kiểm tra trong môi trường không sản xuất trước.
- Có quy trình đối soát workflow, artefact và log sau khi GitHub phục hồi.
Điểm bắt đầu thực tế: trước tiên hãy hoàn thành mirror mã nguồn, lưu một artefact phát hành ngoài GitHub, viết runbook rollback và chạy thử build–test–deploy bằng commit cố định trong môi trường không sản xuất. Sau khi xác nhận route này hoạt động, mới quyết định có cần đầu tư vào CI/CD thay thế đầy đủ hay không.
Nguồn tham khảo
