- Sau hai sự cố gần đây, GitHub đang đặt tính khả dụng làm ưu tiên cao nhất, đồng thời điều chỉnh lại hạ tầng và kiến trúc để đáp ứng khối lượng công việc phát triển tăng vọt cùng agentic development workflows
- Chỉ một pull request cũng có thể liên kết rộng tới kho Git, Actions, tìm kiếm, thông báo, quyền hạn, webhooks, APIs, tác vụ nền, bộ nhớ đệm và cơ sở dữ liệu, nên khi các điểm kém hiệu quả nhỏ tích tụ lại, chúng có thể dẫn tới tắc nghẽn hàng đợi và lan truyền phụ thuộc
- Trong ngắn hạn, GitHub đang tập trung giảm nút thắt cổ chai và tải cơ sở dữ liệu thông qua di chuyển backend cho webhooks, thiết kế lại bộ nhớ đệm phiên người dùng, điều chỉnh luồng xác thực và phân quyền, cùng việc mở rộng tài nguyên tính toán dựa trên Azure
- Về dài hạn, GitHub đang tăng cường khả năng phục hồi và tính linh hoạt bằng cách cô lập các dịch vụ cốt lõi, giảm các điểm lỗi đơn lẻ, chuyển một phần Ruby monolith sang Go, chuyển sang public cloud và chuẩn bị lộ trình multi cloud
- Cả sự cố hồi quy merge queue ngày 23 tháng 4 và sự cố quá tải Elasticsearch ngày 27 tháng 4 đều không gây mất dữ liệu, và GitHub cũng đang tăng cường minh bạch bằng cách đưa chỉ số availability lên status page và mở rộng phạm vi công khai tới cả các sự cố nhỏ
Bối cảnh của các biện pháp ứng phó về tính khả dụng
- Sau hai sự cố gần đây, GitHub đã tổng hợp tình hình cải thiện tính khả dụng và độ tin cậy
- Từ tháng 10 năm 2025, công ty đã triển khai kế hoạch mở rộng dung lượng gấp 10 lần, và đến tháng 2 năm 2026 thì nhu cầu thiết kế theo giả định quy mô lớn gấp 30 lần hiện tại đã trở nên rõ ràng
- Bối cảnh chính là sự thay đổi trong cách phát triển phần mềm, khi từ nửa cuối năm 2025 trở đi, agentic development workflows tăng tốc mạnh mẽ
- Việc tạo kho lưu trữ, hoạt động pull request, mức sử dụng API, tự động hóa và khối lượng công việc trên các kho lớn đều đang tăng nhanh
Gánh nặng cấu trúc bộc lộ trong quá trình mở rộng
- Một pull request có thể đồng thời tác động tới kho Git, mergeability checks, branch protection, GitHub Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches và databases
- Ở quy mô lớn, ngay cả những điểm kém hiệu quả nhỏ cũng có thể tích tụ thành tắc nghẽn hàng đợi, chuyển tải từ cache miss sang cơ sở dữ liệu, chậm trễ lập chỉ mục, khuếch đại lưu lượng retry và ảnh hưởng đa sản phẩm từ các phụ thuộc chậm
- Thứ tự ưu tiên được xác định là tính khả dụng trước tiên, sau đó là dung lượng, rồi mới đến tính năng mới
- GitHub đang song song thực hiện giảm các công việc không cần thiết, cải thiện bộ nhớ đệm, cô lập các dịch vụ cốt lõi, loại bỏ điểm lỗi đơn lẻ và chuyển các tuyến nhạy cảm về hiệu năng sang các hệ thống chuyên dụng
- Bài toán trọng tâm là giảm mức độ kết dính ẩn, giới hạn blast radius và bảo đảm graceful degradation để toàn bộ hệ thống không sụp đổ chỉ vì một phân hệ bị áp lực
Các cải tiến đang được triển khai
- Trong ngắn hạn, GitHub tập trung xử lý các nút thắt cổ chai xuất hiện nhanh hơn dự kiến
- Công ty đã chuyển webhooks sang một backend khác ngoài MySQL, thiết kế lại bộ nhớ đệm phiên người dùng và chỉnh sửa lại luồng xác thực, phân quyền để giảm mạnh tải cho cơ sở dữ liệu
- GitHub cũng tận dụng quá trình chuyển sang Azure để đảm bảo có nhiều tài nguyên tính toán hơn
- Sau đó, trọng tâm được chuyển sang cô lập các dịch vụ cốt lõi như git và GitHub Actions, đồng thời giảm các điểm lỗi đơn lẻ
- Công ty đã phân tích chi tiết các lớp phụ thuộc và lưu lượng để xác định cần tách phần nào, rồi triển khai biện pháp theo thứ tự rủi ro nhằm giảm thiểu tác động của nhiều dạng tấn công lên lưu lượng bình thường
- Việc chuyển một phần mã nhạy cảm về hiệu năng hoặc quy mô từ Ruby monolith sang Go cũng đang được đẩy nhanh
- Trong khi đang chuyển từ các trung tâm dữ liệu tự vận hành quy mô nhỏ sang public cloud, GitHub cũng đã bắt đầu thúc đẩy lộ trình multi cloud cho dài hạn
- Các biện pháp dài hạn này là cần thiết để bảo đảm khả năng phục hồi, độ trễ thấp và tính linh hoạt trong tương lai
Ứng phó với kho lưu trữ lớn và merge queue
- So với việc số lượng kho tăng lên, GitHub cho rằng thách thức mở rộng khó hơn là sự gia tăng của các monorepo lớn
- Trong 3 tháng gần đây, công ty đã tăng mạnh đầu tư để ứng phó xu hướng này ở cả hệ thống git lẫn trải nghiệm pull request
- Công việc liên quan tới thiết kế API mới nhằm đạt hiệu quả và khả năng mở rộng cao hơn cũng đang được tiến hành, và sẽ được công bố trong một bài blog riêng
- GitHub cũng đầu tư vào tối ưu hóa tác vụ merge queue, do đây là yếu tố quan trọng với các kho có hàng nghìn pull request mỗi ngày
Sự cố gần đây 1: vấn đề merge queue ngày 23 tháng 4
- Ngày 23 tháng 4, đã xảy ra hồi quy trong hoạt động của merge queue đối với pull request
- Trong merge queue sử dụng phương thức squash merge, khi một merge group chứa từ hai pull request trở lên thì một merge commit không chính xác được tạo ra
- Với các trường hợp bị ảnh hưởng, các lần hợp nhất sau đó có thể vô tình hoàn tác các thay đổi từ pull request đã được hợp nhất trước đó cùng các commit hiện có
- Trong khoảng thời gian chịu ảnh hưởng, 658 kho lưu trữ và 2.092 pull request đã bị tác động
- Các con số ban đầu được ước tính theo hướng thận trọng nên số liệu được chia sẻ lúc đầu có phần cao hơn một chút
- Các pull request được merge ngoài merge queue không bị ảnh hưởng, và các nhóm merge queue dùng phương thức merge hoặc rebase cũng không bị tác động
- Không có mất dữ liệu. Mọi commit đều vẫn được lưu trong Git
- Tuy vậy, trạng thái nhánh mặc định của các kho bị ảnh hưởng đã bị sai lệch, và không thể tự động khôi phục an toàn cho mọi kho
- incident root cause analysis: có thể xem thêm chi tiết
- Sự cố này cũng làm lộ ra nhiều thất bại trong quy trình, và GitHub đang thay đổi các quy trình đó để tránh tái diễn vấn đề cùng loại
Sự cố gần đây 2: vấn đề liên quan đến tìm kiếm ngày 27 tháng 4
- Ngày 27 tháng 4, đã xảy ra sự cố ở phân hệ Elasticsearch vốn phụ trách nhiều trải nghiệm dựa trên tìm kiếm
- Phạm vi ảnh hưởng bao gồm một số giao diện dựa trên tìm kiếm của pull requests, issues và projects
- Phân tích nguyên nhân gốc rễ vẫn đang được hoàn tất và sẽ sớm được công bố
- Theo những gì đã xác định tới nay, cụm hệ thống đã rơi vào trạng thái quá tải, dẫn đến việc không thể trả về kết quả tìm kiếm
- Một khả năng bị botnet attack cũng đang được xem xét như nguyên nhân gây quá tải, nhưng phân tích nguyên nhân gốc vẫn chưa hoàn tất
- Không có mất dữ liệu, và các thao tác Git cùng APIs không bị ảnh hưởng
- Tuy nhiên, một số giao diện phụ thuộc vào tìm kiếm hoàn toàn không thể hiển thị kết quả, gây ra nhiều nhầm lẫn
- Đây là khu vực mà việc cô lập hoàn toàn để loại bỏ điểm lỗi đơn lẻ vẫn chưa hoàn tất, và trước đó các khu vực khác có mức ưu tiên rủi ro cao hơn
- GitHub đang áp dụng cùng cách phân tích phụ thuộc và giảm blast radius để hạ thấp khả năng xảy ra cũng như tác động của kiểu sự cố này
Tăng cường minh bạch về sự cố
- Trong các sự cố, nhu cầu của khách hàng về tính minh bạch cao hơn đã trở nên rõ ràng
- Gần đây GitHub đã cập nhật GitHub status page để bao gồm chỉ số availability
- Công ty quyết định đăng cả các sự cố nhỏ lên status chứ không chỉ các sự cố lớn, với mục tiêu giúp người dùng không phải đoán xem vấn đề nằm ở phía họ hay phía GitHub
- Cách phân loại sự cố cũng đang tiếp tục được cải thiện để quy mô và phạm vi trở nên dễ hiểu hơn
- Đồng thời, GitHub cũng đang cải thiện cách khách hàng chia sẻ tín hiệu và báo cáo vấn đề trong lúc sự cố diễn ra
Cam kết trong thời gian tới
- GitHub cam kết cải thiện tính khả dụng, tăng cường khả năng phục hồi, mở rộng phù hợp với quy mô phát triển phần mềm trong tương lai và giao tiếp minh bạch hơn
- Số lượng kho bị ảnh hưởng trong sự cố ngày 23 tháng 4 đã được cập nhật tính đến ngày 28 tháng 4 năm 2026
1 bình luận
Ý kiến trên Hacker News
Chỉ riêng từ đầu năm nay, GitHub đã gặp hàng chục sự cố, và so với năm ngoái thì độ sẵn sàng cùng độ tin cậy đã tệ đi rõ rệt
Đến mức này thì đủ nghiêm trọng để dashboard và heatmap phải quay cuồng, và tôi nghĩ nó đã tới mức sự bất ổn của GitHub trở thành meme trên những nơi như HN hay Reddit
Vậy mà vẫn nói ưu tiên là "availability, capacity, new features" thì đúng là quá lỏng lẻo trong việc nhìn nhận thực tế
Lúc này ưu tiên 1, 2, 3 đều phải là availability, và ít nhất trong 6 tháng đừng nói chuyện gì khác ngoài sửa cho xong việc đó
Sáu tháng trước họ còn nói di chuyển sang Azure là ưu tiên số một nên sẽ hoãn phát triển tính năng, còn bây giờ lại nói availability là ưu tiên hàng đầu, nghe khá thiếu nhất quán
Khi đó họ nói hạn chế dung lượng ở data center Virginia là vấn đề mang tính "existential" vì nhu cầu AI và Copilot, nên giờ vẫn còn loạng choạng vì đúng vấn đề đó thì lại càng khó hiểu hơn
Nói là hoãn phát triển tính năng nhưng mỗi tuần vẫn có tính năng mới và thay đổi UI, và cách đây không lâu còn đổi cả giao diện xem issue đơn
Một công ty có nguồn lực cỡ Microsoft mà cứ liên tục mắc kẹt ở đúng một chỗ như vậy thì khó mà tin nổi, và chiến lược mua các dịch vụ dev phổ biến rồi chuyển hết lên cùng một platform cũng trông khá bất an
Trong các tổ chức kỹ thuật lớn, ưu tiên không nhất thiết loại trừ lẫn nhau, và những team không thể đóng góp trực tiếp vào ưu tiên cốt lõi vẫn có thể tiếp tục làm các tính năng khác
https://news.ycombinator.com/item?id=47912521
Phần cứng chuyên dụng có thể dễ dự đoán hơn cloud, và kiểu quyết định như "đừng sang Azure nữa, mua thêm vài rack đi" có lẽ không phải thứ ban lãnh đạo GitHub có thể tự quyết
GitHub không phải kiểu website cần redesign mỗi 5 phút, và đôi lúc trông như các quản lý đang cố chứng minh lý do tồn tại của mình bằng cách đẩy ra các tính năng mới chỉ để có tính năng mới
Kết quả là càng làm hỏng nhiều hơn thì lại càng phản tác dụng trong việc giữ người dùng
Search cũng bị nerf đáng kể, và giống như Google Search hay YouTube, tôi không hiểu vì sao ai cũng cứ tiếp tục phá hỏng một chức năng tìm kiếm vốn đang hoạt động bình thường
Chưa kể Microsoft vừa có Azure DevOps gần như bị bỏ mặc, vừa có GitHub, mà tôi ghét cả hai, đặc biệt là hệ thống ticket của chúng
Tôi đã quá chán cảnh mỗi dự án Jira lại cấu hình một kiểu, vậy mà giờ còn phải thốt lên rằng "thà quay lại Jira còn hơn"
Bài đó cho cảm giác khó mà đọc một cách nghiêm túc
Những biểu đồ chỉ đẩy số lên to đùng mà không có nhãn, thứ tự ưu tiên không khớp với cảm nhận thực tế, và thái độ không thực sự thừa nhận uptime tệ hại trong 12 tháng qua khiến người ta rất khó chịu
Dù đúng là thiếu nhãn trục ở góc dưới bên trái, nhưng ý chính rằng tốc độ tăng trưởng từ 2023→2024→2025→2026 là rất nhanh vẫn được truyền tải
Nó đọc như thể vào đầu hoặc cuối 2026 sẽ có mức tăng trưởng còn lớn hơn tổng của 3 năm trước cộng lại, và dù không biết số trên trục thì vẫn có thể thấy xu hướng đại khái
Cần giả định đó là biểu đồ tuyến tính, nhưng trong ngữ cảnh này thì giả định đó không có vẻ quá vô lý
Nếu là một công ty đang trải qua tăng trưởng lớn hơn nhiều so với kế hoạch thì vấn đề dung lượng gần như là không thể tránh khỏi, và giờ có vẻ đã vượt khỏi mức chỉ cần nhét thêm phần cứng, mà cần tối ưu hiệu quả backend
Các mục tiêu họ viết ra nhìn chung cũng nhắm tới hướng đó
https://x.com/kdaigle/status/2040164759836778878
Không rõ là người ta không tin tăng trưởng hiện tại là hàm mũ, hay là cho rằng tăng 10 lần mỗi năm cũng chẳng khó gì lắm
https://damrnelson.github.io/github-historical-uptime/
Câu "đã bắt đầu lộ trình multi cloud" nghe như Microsoft đang ngầm thừa nhận rằng chỉ với Azure thì họ không kéo được mức độ tin cậy như mong muốn
Nó có thể giúp giữ chân khách hàng
Ban đầu mục tiêu là vận hành gần như không cần con người can thiệp, nhưng giờ thì nghe như kiểu ai đó gắn cổng serial vào rack hoặc VM rồi trực tiếp đụng tay vào là quy trình hằng ngày
Nhưng hiện tôi không tìm lại được link
Từ thứ Hai đến thứ Năm, khoảng 9–11 giờ sáng Pacific là lúc có nhiều độc giả năng động nhất, còn cuối tuần thì ít cạnh tranh hơn nhưng mức độ tham gia cũng thấp hơn
CTO của GitHub cũng ngồi trong hội đồng quản trị của Codepath.org, mà phần mô tả ở đó lại kiểu "xây dựng thế hệ kỹ sư, CTO và nhà sáng lập AI-native đầu tiên", nên cũng phần nào đoán được vấn đề nằm ở đâu
Cảm nhận thực tế là độ ổn định của GitHub đã tệ đi nhiều, và gần đây ngay cả dữ liệu hiển thị trên web cũng khó mà tin được
Từ hôm qua, tôi và vài đồng nghiệp đã xác nhận rằng ở nhiều repo, danh sách PR hiển thị không đầy đủ
Ví dụ ở https://github.com/gap-system/gap/pulls, tab ghi "Pull requests 78" nhưng trong danh sách chỉ hiện "35 open"
78 mới là con số đúng, điều này còn được xác nhận bằng
gh pr list, thế mà https://www.githubstatus.com vẫn hiển thị "all systems operational"Dùng CLI thì vẫn ra danh sách, nhưng đi qua đường web có search là biến mất hết
Bộ phận hỗ trợ đã thừa nhận vấn đề này, nhưng sau đó thì im lặng, và trên status page cũng chẳng có gì ngoài một issue ngày 27 có vẻ có liên quan
Ở một số repo có vẻ đã được xử lý giữa chừng, nhưng ở nhiều org và repo khác thì vẫn tái hiện đều đều
https://github.com/orgs/community/discussions/193388
Tôi phải lục trong trang branch mới tìm thấy các PR bị thiếu
Có khi đây không hẳn là bug hoàn toàn, mà là một quyết định rất tệ từ góc độ sản phẩm để giảm tải hạ tầng
Dù sao thì việc họ công khai dữ liệu repo/issues/commits mới trong vài năm qua vẫn khá thú vị
Đúng như nhiều người bên ngoài vẫn đoán, nó xác nhận rằng các agent đang tạo thêm tải đột ngột và rất lớn lên GitHub
Vừa phục vụ một nền người dùng vốn đã khổng lồ, vừa tăng trưởng theo cấp số nhân như startup thì gần như chắc chắn sẽ trở thành mục tiêu bị soi, và tổ chức cũng khó mà xoay trở nhanh
Mặt khác thì họ cũng có nhân lực, hạ tầng và tiền bạc nhiều hơn startup rất nhiều
Chỉ có một biểu đồ không nhãn và các con số đỉnh hiện tại mà thôi
Tôi thật sự không hiểu họ định làm gì với những biểu đồ đó, trông gần như kiểu tranh ấn tượng của nghệ sĩ
Nhìn vào biểu đồ commit thì chẳng giải thích được vì sao có những bậc nhảy lớn rồi dốc xuống từ từ, vì sao các bậc nhảy đó không xảy ra ở những mốc đều nhau, hay vì sao cú nhảy lớn hơn đôi khi lại có độ dốc nhỏ hơn
Các biểu đồ khác lại chuyển động theo hình dạng hoàn toàn khác, nên lại càng kỳ quặc
Mục đích không phải để cho thấy dữ liệu thật hay ý nghĩa của dữ liệu, mà chỉ để truyền đạt rằng "có cái gì đó đang tăng"
Tôi nghĩ federated forges mới là tương lai
Repo nên được host trên sovereign infra của riêng từng bên, rồi chồng lên bằng global ID và metadata được liên kết như issue, PR các kiểu
Loại global index này cũng khá dễ dựng, nên availability sẽ không còn là mối lo lớn, và chúng tôi cũng đang làm theo hướng đó
Cuối cùng nếu vẫn dùng dịch vụ host bên thứ ba thì rất có thể lại chỉ xuất hiện 1–3 nhà cung cấp lớn
Và dù có self-host để tránh vấn đề availability, nếu phụ thuộc vẫn nằm ở các dịch vụ lớn như GitHub thì sự cố bên đó vẫn không tránh được
Vì vậy giải pháp thực tế vẫn là proxy hoặc mirror mọi thứ đang dùng, giống như hiện nay
Giữ cùng một repo trên GitHub, Codeberg và self-host, rồi chỉ cần đảm bảo tính nhất quán của nhánh chính
Sau đó có thể cập nhật ở đâu cũng được, miễn là đặt link rõ ràng trong README
Nếu có thể nối sang một forge khác chỉ cần có API hoặc webhook đủ ổn mà vẫn giữ được cùng mức tiện lợi, tôi muốn chuyển hết sang self-host
Phía agent cũng sẽ phải mở giao diện ra, nhưng nếu có cấu trúc plugin thì có vẻ có thể gỡ phụ thuộc GitHub rồi xử lý phần còn lại bằng MCP hoặc skills
Tôi không ngại self-host các runner lớn nên gần đây đã chuyển sang Codeberg, còn các tác vụ cron nhỏ thì dùng runner mà Codeberg cung cấp
Bên đó thậm chí còn có lazy runner cho kiểu use case này
Những gì họ đang làm trông như thế này
Trợ cấp token đã hút đủ dữ liệu huấn luyện, và mảng kinh doanh agentic junkies giờ đã đủ lớn để tự quay flywheel, nên họ định cắt đi và dọn dẹp các sản phẩm dẫn lỗ
https://news.ycombinator.com/item?id=47923357