GitHub công bố postmortem tuần này cho outage ngày 17/8 — lần lớn thứ hai trong tháng — và chôn trong phần “công việc phía trước” là một con số khiến bất kỳ tech lead nào đang chạy fleet coding agent phải dừng lại tính toán: GitHub giờ xử lý 2,9 tỷ commit, 130 triệu pull request merge, và 24 triệu repo mới mỗi tháng, và riêng AI coding agent đã tạo ra khoảng 17 triệu pull request mỗi tháng. Hồi tháng 4, GitHub đã căng thẳng ở mức 1,4 tỷ commit/tháng. Đó là khối lượng commit tăng gấp đôi trong bốn tháng. Không có capacity planning truyền thống nào giả định một đường cong tăng trưởng như vậy, vì capacity planning truyền thống chưa bao giờ được xây cho một thế giới nơi git client chính không phải con người gõ git push chục lần một ngày.

Phép toán phá vỡ giả định của autoscaling

Logic autoscaling tiêu chuẩn — thêm capacity tỷ lệ với load quan sát được, với headroom cho spike traffic bình thường — giả định load tăng gần tuyến tính với số lượng user, hoặc tệ nhất theo pattern mùa vụ dự đoán được (Black Friday, ngày ra mắt sản phẩm). Giải thích của chính GitHub cho outage là “thiếu capacity” khi tăng trưởng usage vượt qua autoscaling. Lý do điều này đáng để suy ngẫm không phải vì kỹ sư GitHub kém về capacity planning — mà vì một fleet agent tự động không hành xử như một fleet con người, kể cả cùng headcount.

Một kỹ sư con người làm feature trong một ngày thường: vài commit, một hai lần push, mở một PR, đôi khi rebase. Một session agentic coding làm cùng feature đó có thể trông hoàn toàn khác: clone hoặc fetch mỗi lần container mới khởi động, commit mỗi vòng lặp test-fix, force-push mỗi lần retry, mở PR cho mỗi candidate branch nếu bạn chạy pattern “sinh N candidate, chọn cái tốt nhất”, và webhook bắn ra cho mỗi sự kiện đó. Nếu team bạn có năm kỹ sư mỗi người chạy hai ba coding agent song song — một setup Claude Code / Codex / Cursor hoàn toàn bình thường vào giữa 2026 — bạn có thể đang tạo ra nhiều hơn một bậc độ lớn lượng git operation so với những gì headcount gợi ý, mà không ai chủ động quyết định “scale load lên GitHub” cả.

Chi tiết phụ thuộc Azure dễ bỏ qua

Chôn trong cùng postmortem: Microsoft Azure giờ xử lý khoảng 58% platform load của GitHub và một nửa toàn bộ Git operation. Đó không phải lời chỉ trích kiến trúc — Azure là nền tảng hợp lý cho GitHub — nhưng là một data point hữu ích cho bất kỳ ai đang phân tích failure domain cho pipeline CI/CD của chính mình. Nếu deploy pipeline, git hosting, và compute chạy agent của bạn cuối cùng đều chia sẻ một failure domain (dù gián tiếp, qua một cloud provider chung gặp ngày xui), một outage không độc lập giữa ba thứ đó theo cách runbook incident của bạn có lẽ đang giả định. Đáng để audit thực sự: khi GitHub sập, CI của bạn có degrade theo không vì cùng region với agent runner? On-call rotation của bạn có fallback không phụ thuộc vào GitHub Issues để phối hợp incident không?

Mô hình chi phí thô cho fleet agent của chính bạn

Trước khi đọc postmortem này mình chưa từng thực sự ngồi ước tính traffic git do agent tạo ra của chính mình so với baseline theo nhịp con người. Phiên bản thô, đáng chạy cho team của bạn:

human_dev_git_ops_per_day  = commits(~6) + pushes(~3) + prs(~1) + fetches(~10)
agent_session_git_ops      = clone_or_fetch(1 mỗi lần container khởi động)
                            + commits(1 mỗi vòng test-fix, thường 5-15)
                            + force_pushes(1 mỗi lần retry, thường 3-8)
                            + prs(1 mỗi candidate branch, 1-5 nếu dùng fan-out)
                            + webhook_events(1 cho mỗi operation trên)

agents_per_dev              = 2-3  # setup subagent / worktree song song điển hình
multiplier                  = (agent_session_git_ops * agents_per_dev) / human_dev_git_ops_per_day

Điền số bảo thủ — 8 commit mỗi session agent, 2 force-push, 2 PR mỗi fan-out, 3 agent chạy song song mỗi kỹ sư — bạn sẽ ra khoảng hệ số nhân 6-10x trên khối lượng git operation thô mỗi kỹ sư, chưa tính webhook fan-out đến CI, status check, và bot nào đó refetch mỗi lần push. Con số này khớp khá sát với quỹ đạo tăng gấp đôi trong bốn tháng của chính GitHub, và là loại con số nên xuất hiện trong cuộc trò chuyện capacity infra của chính team bạn, không chỉ của GitHub.

Những gì mình thực sự đã thay đổi vì điều này

Vài điều chỉnh cụ thể đáng làm nếu bạn đang chạy fleet agent thật trên hạ tầng git dùng chung, của chính bạn hay của vendor:

1. So le lịch chạy agent theo schedule. Nếu task digest hàng đêm, batch refactor, hay job agent theo lịch của bạn đều bắn cùng một phút cron, bạn đang tạo chính xác pattern burst đồng bộ phá vỡ giả định autoscaling. Jitter lịch cron của bạn.
2. Giới hạn độ rộng fan-out một cách tường minh. “Sinh 5 candidate branch và chọn cái tốt nhất” là pattern thật, nhưng cũng là hệ số nhân 5x trên khối lượng PR và webhook cho một đơn vị công việc logic. Mặc định ít candidate hơn trừ khi có lý do cụ thể để mở rộng.
3. Ưu tiên fetch-and-rebase thay vì force-push lặp lại mỗi lần retry khi workflow cho phép — mỗi force-push là một full ref update và một webhook event; gộp các retry thành một push cuối session giảm đáng kể số operation.
4. Audit failure domain, không chỉ SLA uptime. Biết cái gì thực sự chia sẻ hạ tầng với git host của bạn trước khi bạn cần câu trả lời đó trong lúc incident, không phải lúc viết postmortem.

Bài học lớn hơn thực ra không phải về riêng GitHub — mà là giả định được đóng cứng trong hầu hết hạ tầng, kể cả hạ tầng bạn không kiểm soát, vẫn là “load scale theo headcount con người.” Giả định đó âm thầm ngừng đúng vào đâu đó trong năm qua, và những tổ chức nhận ra trước khi postmortem của vendor báo cho họ biết là những tổ chức không bị page vì thiếu capacity của người khác.