Nếu bạn là một nhà phát triển sử dụng hàng đợi hợp nhất (Merge Queue) của GitHub và đã trải qua một tuần khó khăn vào khoảng ngày 23 tháng 4 năm 2026, thì bạn hoàn toàn không hề tưởng tượng ra mọi chuyện. Mã nguồn của bạn đã thực sự biến mất. Không phải do một commit lỗi, không phải do một thành viên đội nhóm “phá hoại”, mà là do chính GitHub đã lặng lẽ xóa nó.
Đây là câu chuyện về những gì đã xảy ra, tại sao nó lại tồi tệ hơn nhiều so với những con số chính thức được công bố, và ý nghĩa của nó đối với cách chúng ta đặt niềm tin vào các công cụ mà chúng ta đang xây dựng trên đó.
Mục lục
Khi GitHub “Phản Bội” Git: Chi Tiết Về Lỗi Xóa Mã Nguồn Thầm Lặng
Ngày 23 tháng 4 năm 2026: Một Buổi Chiều Ác Mộng
Vào lúc 16:05 UTC ngày 23 tháng 4 năm 2026, một lỗi hồi quy đã âm thầm xâm nhập vào hệ thống hàng đợi hợp nhất của GitHub. Trong ba tiếng rưỡi tiếp theo, các kỹ sư trên khắp thế giới vẫn đang xem xét các pull request (PR), nhấp vào “merge”, và mọi thứ đều có vẻ hoàn toàn bình thường. Dấu tích xanh hiển thị, các thay đổi (diff) sạch sẽ, không có bất kỳ cảnh báo nào.
Tuy nhiên, những gì thực sự đang diễn ra đằng sau hậu trường lại vô cùng kinh hoàng. Một PR với thay đổi hoàn toàn hợp lý, ví dụ:
+29 / -34(thêm 29 dòng, xóa 34 dòng), sẽ được phê duyệt và đưa vào hàng đợi. Nhưng những gì thực sự được hợp nhất vào nhánh
mainlại là một commit với thay đổi
+245 / -1,137. Hàng nghìn dòng mã mà các kỹ sư khác đã triển khai, xem xét và chuyển sang dự án khác đã biến mất không dấu vết. Và mọi lần hợp nhất tiếp theo đều diễn ra trên lịch sử Git đã bị hỏng hóc đó.
Giao diện người dùng không hiển thị bất kỳ vấn đề nào. Trang trạng thái hệ thống (status page) không hề báo cáo sự cố. Nền tảng này đang “nói dối” tất cả mọi người.
Cơ Chế Phía Sau Sự Cố: Điều Gì Đã Thật Sự Sai Lầm?
Hàng đợi hợp nhất của GitHub hoạt động bằng cách tạo một nhánh tạm thời cho mỗi PR trong hàng đợi. Thông thường, nhánh tạm thời đó sẽ bắt đầu từ điểm cuối của nhánh
maincộng với các thay đổi của PR. Quá trình CI (Continuous Integration) sẽ chạy trên đó, nếu thành công, PR sẽ được hợp nhất.
Tuy nhiên, vào ngày 23 tháng 4, hàng đợi bắt đầu xây dựng các nhánh tạm thời từ một điểm khởi đầu sai. Thay vì phân nhánh từ điểm cuối hiện tại của
main, nó lại phân nhánh từ nơi nhánh tính năng ban đầu đã phân tách khỏi
main, có thể là hàng chục hoặc hàng trăm commit trước đó. Sau đó, nó đẩy toàn bộ nội dung của nhánh tạm thời đó lên
main.
Vì vậy, nếu nhánh tính năng của bạn bị tụt hậu 50 commit so với
mainkhi nó đi vào hàng đợi, thì quá trình “hợp nhất” đã âm thầm loại bỏ 50 commit công việc của những người khác như một tác dụng phụ của việc hợp nhất code của bạn. CI vẫn vượt qua vì nhánh tạm thời tự nó là nhất quán nội bộ. Nhưng nhánh
mainlại bị “nổ tung” vì nhánh tạm thời không liên quan gì đến trạng thái hiện tại của
main.
Nguyên nhân gốc rễ? Một đường dẫn mã mới điều chỉnh tính toán cơ sở hợp nhất (merge base computation) lẽ ra phải được kiểm soát bởi một cờ tính năng (feature flag) cho một tính năng chưa được phát hành. Việc kiểm soát này đã không hoàn chỉnh. Hành vi mới đã rò rỉ vào môi trường sản xuất và áp dụng cho tất cả các nhóm hợp nhất kiểu squash merge.
Ba yếu tố khiến lỗi này trở nên đặc biệt nghiêm trọng:
- Giao diện người dùng đã “nói dối”: Bạn đã xem xét
+29/-34. Nhưng commit thực sự được hợp nhất lại là
+245/-1,137. Điều các kỹ sư phê duyệt không phải là điều đã được hợp nhất. Điều này phá vỡ hợp đồng cơ bản nhất của một hệ thống xem xét mã.
- Hoàn toàn không có cảnh báo: Không có xung đột hợp nhất, không có kiểm tra thất bại, không có biểu ngữ cảnh báo trên PR. Các đội chỉ phát hiện ra khi có người nhận thấy mã trên
mainlẽ ra phải có ở đó nhưng lại biến mất.
- Mức độ thiệt hại tỷ lệ thuận với tốc độ hoạt động kho lưu trữ: Kho lưu trữ càng hợp nhất nhanh, các nhánh tính năng càng trôi xa khỏi
main, và mỗi lần hợp nhất lỗi càng gây ra nhiều thiệt hại. Các đội phụ thuộc nhiều nhất vào hàng đợi hợp nhất lại bị ảnh hưởng nặng nề nhất.
Thiệt Hại Thực Tế và Chi Phí Con Người
Đây không phải là một vấn đề lý thuyết. Nhiều đội kỹ thuật đã phải dành cả buổi chiều trong chế độ xử lý sự cố: rà soát biểu đồ commit, khôi phục mã bị xóa thủ công, điều phối phục hồi trên nhiều kho lưu trữ và gửi yêu cầu hỗ trợ mà phải mất nhiều ngày mới nhận được phản hồi.
Một tổ chức báo cáo rằng mọi đội đang chạy trên hàng đợi hợp nhất của GitHub đều bị ảnh hưởng, với hàng chục commit lỗi và hàng trăm commit hiện có bị ghi đè trước khi bất kỳ ai nhận ra. Chỉ riêng một công ty đã tuyên bố gặp phải hơn 200 PR bị hủy hoại.
GitHub sau đó cho biết 2.092 pull request trên 230 kho lưu trữ đã bị ảnh hưởng trong khoảng thời gian từ ngày 22 đến 23 tháng 4. Thông điệp trước đó từ COO của GitHub trên X (Twitter) đã đưa ra con số 2.804 PR, và một số thành viên cộng đồng đã phản đối mạnh mẽ cả hai con số này dựa trên những gì các công ty cá nhân đang trải nghiệm.
Sự cố không được hệ thống giám sát tự động của GitHub phát hiện vì nó ảnh hưởng đến tính đúng đắn của commit hợp nhất chứ không phải tính khả dụng. GitHub chỉ nhận thức được lỗi hồi quy vào lúc 19:38 UTC, sau khi số lượng yêu cầu hỗ trợ khách hàng tăng lên. Biện pháp khắc phục, một thao tác revert và force-deploy, đã hoàn tất vào lúc 20:43 UTC. Ba giờ ba mươi ba phút của sự hỏng hóc thầm lặng.
Trang Thái Hệ Thống GitHub “Vô Dụng” Trước Thảm Họa
Đây là phần gây nhức nhối nhất. Nếu bạn kiểm tra trang trạng thái của GitHub vào ngày 23 tháng 4, bạn có thể đã không thấy điều gì đáng báo động. Không có sự cố lớn nào được báo cáo. Không có sự cố một phần.
Điều đó là do cách tính toán trang trạng thái của GitHub loại trừ cụ thể “Hiệu suất suy giảm” khỏi số liệu thời gian ngừng hoạt động. Nền tảng này tự nó không bao giờ ngừng hoạt động. Các nhà phát triển vẫn có thể đẩy mã, mở PR và nhấp vào merge. Việc nhấp vào merge lại âm thầm phá hủy codebase của họ đã không được ghi nhận là một sự cố trên bảng điều khiển.
Đây là một khoảng trống đáng nói. Thời gian hoạt động (Uptime) và tính đúng đắn (Correctness) không phải là cùng một thứ. Một ngân hàng xử lý các giao dịch của bạn nhưng ghi nhận chúng không chính xác thì không được coi là “hoạt động”. GitHub đã xử lý các lần hợp nhất. Nó chỉ tạo ra kết quả sai. Trang trạng thái không được xây dựng để bắt được loại lỗi này.
Không Phải Chỉ Là Một Ngày Tồi Tệ Đơn Lẻ: Chuỗi Sự Cố Tháng 4/2026
Sẽ dễ dàng hơn để vượt qua sự cố này nếu nó chỉ là một lần duy nhất. Nhưng tháng 4 năm 2026 thực sự là một khoảng thời gian khó khăn đối với GitHub.
Bốn ngày sau sự cố hàng đợi hợp nhất, vào ngày 27 tháng 4, cụm Elasticsearch của GitHub bị quá tải, có thể do một cuộc tấn công botnet, và các giao diện người dùng dựa trên tìm kiếm ngừng trả về kết quả. Danh sách pull request trống rỗng. Các Issue biến mất khỏi tầm nhìn. Các trang Projects và Actions workflow không hiển thị gì. Dữ liệu cơ bản vẫn còn đó, nhưng các nhà phát triển không thể nhìn thấy nó.
Và sau đó, vào ngày 28 tháng 4, cùng buổi sáng khi CTO của GitHub đăng bài xin lỗi về độ tin cậy, một tiết lộ bảo mật riêng biệt đã được công bố: các nhà nghiên cứu tại Wiz đã tìm thấy một lỗ hổng thực thi mã từ xa (RCE) nghiêm trọng trong pipeline
git pushcủa GitHub (CVE-2026-3854, CVSS 8.7). Một lệnh
git pushđược tạo ra đặc biệt với các tùy chọn được tiêm vào có thể dẫn đến thực thi mã không được bảo vệ (unsandboxed) trên máy chủ của GitHub. Nó đã được vá trong 75 phút trên github.com, nhưng thời điểm này thực sự khắc nghiệt.
Ba sự cố đáng kể trong năm ngày: tính đúng đắn của hàng đợi hợp nhất, sự cố tìm kiếm, và một lỗ hổng RCE trong đường dẫn
git pushcốt lõi.
CTO của GitHub, Vlad Fedorov, đã thừa nhận trong bài đăng ngày 28 tháng 4 rằng không có điều nào trong số này là chấp nhận được. Ông cũng tiết lộ quy mô mà GitHub đang phải đối phó: công ty đã lên kế hoạch mở rộng dung lượng lên 10 lần vào tháng 10 năm 2025. Đến tháng 2 năm 2026, các dự báo được thúc đẩy bởi quy trình phát triển dựa trên tác nhân (AI coding tools như Copilot, Cursor và Codex đang tràn ngập nền tảng với các PR tự động) đã buộc phải xem xét lại thành một thiết kế lại 30 lần. GitHub hiện đang đạt đỉnh 90 triệu PR được hợp nhất và 1,4 tỷ commit.
Vấn Đề Kiến Trúc Sâu Xa Hơn: Nguy Cơ Từ Ủy Quyền Tự Động Hóa
Có một lý do tại sao chế độ lỗi cụ thể này lại tồn tại. Hàng đợi hợp nhất của GitHub xây dựng các commit hợp nhất thông qua một đường dẫn mã riêng biệt so với cách một PR thông thường được hợp nhất. Hai đường dẫn mã, hai nơi mà hành vi có thể lặng lẽ sai lệch.
Đây là mối nguy hiểm đi kèm với việc ủy quyền. Một hàng đợi hợp nhất được cho là sẽ tự động hóa chính xác những gì một người sẽ làm khi nhấp vào “Merge pull request”. Ngay khi nó làm điều gì đó mà một người sẽ không làm, bởi vì nó có logic riêng để xây dựng commit hợp nhất, nó có thể âm thầm tạo ra các commit mà không ai viết và không ai phê duyệt.
Đây không chỉ là vấn đề của GitHub. Đó là một mô hình xuất hiện mỗi khi chúng ta cấp cho các hệ thống tự động quyền ghi vào những thứ quan trọng. Hàng đợi, bot, tác nhân AI. Chừng nào các hệ thống đó đang làm điều gì đó tương đương với những gì một con người sẽ làm, các chế độ lỗi sẽ quen thuộc. Khi chúng bắt đầu làm những điều mà một con người sẽ không làm, các lỗi sẽ trở nên vô hình cho đến khi thiệt hại đã xảy ra.
Bài học không phải là tránh hàng đợi hợp nhất. Mà là để đảm bảo rằng bất cứ thứ gì ghi vào
mainvẫn càng gần với các hoạt động git “nhàm chán”, dễ hiểu, không có logic mới lạ trong đường dẫn commit hợp nhất mà người xem xét không thể kiểm tra.
Liệu Các Nhà Phát Triển Có Rời Bỏ GitHub?
Sau một sự cố như thế này, câu hỏi rõ ràng là liệu các nhà phát triển có di chuyển khỏi GitHub hay không. Và câu trả lời trung thực là: có lẽ không đáng kể.
GitHub đã ăn sâu vào hệ thống. Các pipeline CI, tích hợp webhook, chính sách RBAC, quy trình làm việc Actions, quyền ứng dụng của bên thứ ba, cấu trúc nhóm, lịch sử pull request. Việc di chuyển không chỉ là chuyển đổi một URL từ xa. Đó là nhiều tháng làm việc và điều phối.
Sự “dính” này là có thật và không hoàn toàn phi lý. GitHub vẫn là nơi hầu hết mã nguồn mở tồn tại. Nó vẫn là nơi hầu hết các tích hợp hướng đến. Nó vẫn là mặc định. Sự kiểm soát gây nghiện mà nó có đối với hệ sinh thái phát triển giống như một tiện ích công cộng hơn là một sản phẩm SaaS cao cấp. Bạn không thay đổi tiện ích công cộng chỉ vì một tuần tồi tệ.
Nhưng điều mà sự cố này nên thay đổi là mức độ tin cậy cơ bản. GitHub là một cơ sở hạ tầng. Và cơ sở hạ tầng mà âm thầm làm hỏng dữ liệu của bạn, dù chỉ trong vài giờ, mà không có lỗi hiển thị, là cơ sở hạ tầng bạn cần có kế hoạch khôi phục.
Phản ứng tối thiểu không phải là di chuyển. Đó là xác minh. Kiểm tra các squash merge trong các nhóm hàng đợi hợp nhất gồm hai hoặc nhiều PR từ cửa sổ ngày 22 đến 23 tháng 4. Ghi lại những phần nào trong quy trình xây dựng và triển khai của bạn âm thầm giả định lịch sử git là chính xác. Sau đó làm cho giả định đó hiển thị ở một nơi nào đó có thể bị thách thức.
GitHub Đã Cam Kết Những Gì Để Khắc Phục?
Phản ứng sau sự cố của GitHub bao gồm một vài cam kết cụ thể:
- Mở rộng phạm vi kiểm thử để xác thực tính đúng đắn của việc hợp nhất.
- Thêm các kiểm tra hồi quy xác thực nội dung git kết quả trên các cấu hình hợp nhất được hỗ trợ trước khi đưa vào sản xuất.
- Di chuyển mã nhạy cảm về hiệu suất từ codebase Ruby cũ sang Go.
- Chuyển các hệ thống sang cơ sở hạ tầng đám mây công cộng để đáp ứng yêu cầu mở rộng 30 lần.
Cụ thể, lỗi ngày 23 tháng 4 là do việc gắn cờ tính năng không đầy đủ trên một đường dẫn mã mới. Biện pháp khắc phục là một thao tác revert. Khắc phục lâu dài là cải thiện phạm vi kiểm thử cho các nhóm hàng đợi hợp nhất đa PR, vốn rõ ràng là chưa được đại diện đầy đủ trong các bộ kiểm thử hiện có.
Bài Học Đắt Giá: Khi Lớp Nền Tảng “Nhàm Chán” Trở Nên “Thú Vị”
Hàng đợi hợp nhất của GitHub, trong vài giờ vào ngày 23 tháng 4 năm 2026, đã phá vỡ hợp đồng cơ bản nhất của hệ thống kiểm soát phiên bản: rằng những gì bạn phê duyệt là những gì được hợp nhất. Nó đã làm điều đó một cách âm thầm, với giao diện người dùng màu xanh lá cây sạch sẽ, không lỗi và không có mục nào trên trang trạng thái.
Mã nguồn vẫn còn đó trong bộ lưu trữ đối tượng Git. Nhưng lịch sử nhánh đã sai, và không có hệ thống tự động nào có thể sửa chữa nó một cách an toàn trên mọi kho lưu trữ bị ảnh hưởng. Các kỹ sư đã phải làm điều đó bằng tay.
Đó là điều đọng lại. Git được cho là lớp nền tảng “nhàm chán”, đáng tin cậy mà mọi thứ khác được xây dựng trên đó. Khi lớp nền tảng “nhàm chán” trở nên “thú vị”, nó trở nên “thú vị” theo cách tồi tệ nhất có thể.
