Việc đặt trang trạng thái trên một tên miền riêng vì lý do khả dụng là tốt, nhưng khi tên miền chính bị sập mà không cập nhật trang trạng thái đó thì không ổn lắm
Những trang như vậy được cập nhật thủ công thường xuyên hơn bạn nghĩ. Và việc đó cũng thường do người trực on-call, vốn đã có rất nhiều việc cần ưu tiên xử lý trước, thực hiện
Có khi cả hệ thống ống dẫn dùng để cập nhật trang trạng thái cũng sập theo rồi
Có vẻ sự cố kiểu này xảy ra gần như 2 tuần một lần. Dạo này GitHub có chuyện gì vậy?
Có vẻ họ thêm các tính năng mới như Copilot nhưng không đầu tư đủ vào độ tin cậy của site
Nếu không có thay đổi, chỉ cần sửa bug tốt thì tương đối dễ giữ ổn định. Thay đổi, tức tính năng mới, tạo ra bug mới và tải mới
Chắc ai đó quên đưa node_modules vào .gitignore
Có khi những người không hợp với cách quản lý kiểu Microsoft đã đi tìm việc mới rồi?
Đang thử nghiệm gpt4-ops à?
Sự kém cỏi của Microsoft + DDoS?
Có lẽ gom toàn bộ mã nguồn mở của chúng ta vào một chỗ không phải là ý hay >_<
Thực ra điều thay đổi có lẽ chỉ là đến một lúc nào đó ta sẽ ước “giá mà mình ở phía bên kia”
Về cảm giác, giữa việc 1% tổng thể bị sập 100% thời gian và 100% tổng thể bị sập 1% thời gian thì có một phía trông có vẻ tốt hơn, nhưng thực tế phía nào thực dụng hơn thì tôi không chắc. Tất nhiên nếu muốn thì có thể mirror, nhưng hiện tại nếu quyết tâm thì cũng làm được rồi nên đó không phải trọng tâm của chuyện này
Điểm cốt lõi của hệ thống quản lý phiên bản phân tán là mọi người đã git clone đều có một bản sao đầy đủ của toàn bộ repository, và có thể làm hầu hết công việc mà không cần giao tiếp với máy chủ trung tâm
Downtime ngắn chủ yếu ảnh hưởng đến hạ tầng xung quanh mã nguồn thực tế, tức workflow, issue, v.v.
Thành thật mà nói, tập trung ở một chỗ thì tốt hơn. Cả ngành dừng lại cùng lúc còn tốt hơn là những người ngẫu nhiên dừng ở những thời điểm ngẫu nhiên
Giống như khi us-east-1 sập. Vì tất cả cùng chung một con thuyền nên cùng nghỉ, và có lý do chính đáng để thư thả một chút
Để toàn bộ code của công ty ở đó là ý hay. Tự nhiên có giờ nghỉ miễn phí
Điểm bán hàng cốt lõi của GitHub không phải là tính phân tán. Khi tôi đăng ký năm 2008, nó giống một mạng xã hội nơi các lập trình viên gặp nhau hơn
Có vẻ đã hoạt động lại. Tôi muốn được nghe một bản phân tích chuyên sâu về các sự cố gần đây, và một sự đảm bảo rằng họ sẽ ưu tiên độ ổn định hơn tính năng mới
Vài tháng trước tôi nói chuyện với một người bên hỗ trợ khách hàng, và họ gần như đổ lỗi cho đủ loại tùy biến làm cho khách hàng lớn khiến độ ổn định giảm. Kết quả là trông có vẻ nợ kỹ thuật đã chất đống khổng lồ
Để chạy một instance GitHub Enterprise cần khoảng 64GB RAM. Đúng là một con quái vật
Những tùy biến như vậy có thể dẫn đến lỗi hoặc một số tính năng bị trục trặc. Nhưng downtime toàn site, đặc biệt cả nội dung tĩnh như GH Pages cũng sập, thì hoàn toàn là vấn đề SRE
Khả năng cao hơn đây là lỗi định tuyến mạng hoặc một sai sót nào khác ở tầng 4 trở xuống. Phần lớn thay đổi ứng dụng được đưa ra bằng triển khai tuần tự và canary, và nếu có vấn đề thì có thể rollback khá nhanh
Có vẻ sự cố này cũng ảnh hưởng đến GitHub Pages. Trang .github.io hiển thị trang unicorn 503
We're having a really bad day.
The Unicorns have taken over. We're doing our best to get them under control and get GitHub back up and running.
Chà, ngay cả trang trạng thái cũng không tải được. Trông như cả web bị sập, và tôi còn không nhớ lần cuối mọi thứ sập toàn bộ như thế này là khi nào
Phía tôi thì trang trạng thái mở được, nhưng nó hiển thị sai là mọi thứ đều bình thường: https://www.githubstatus.com/
Mọi người đang dùng gì để tự cách ly khỏi những vấn đề kiểu này? Thêm cache cho thao tác đọc có vẻ là quyết định khôn ngoan và cũng cải thiện hiệu năng. Nếu có trường hợp nào tránh được ảnh hưởng thành công thì chia sẻ giúp nhé
Ở công ty cũ, trong cấu hình “GitOps” của một tổ chức, họ mirror GitLab sang AWS CodeCommit và dùng nó làm nguồn sự thật duy nhất cho tự động hóa
Quyết định đó nhiều lần chứng tỏ là lựa chọn sáng suốt, và tôi không nhớ CodeCommit từng có vấn đề đáng chú ý nào. Tuy nhiên nếu trong quy trình phát triển thực tế bạn dùng GitHub làm forge, dùng issue tracker hay PR để review, v.v. thì tôi không biết có cách nào tốt để tự cách ly không
Ở công ty trước đây có GitHub Enterprise tự host nội bộ, và mỗi lần mọi người trên Twitter nói “github sập rồi! hôm nay tan làm sớm!” thì tôi luôn thấy ấm ức :(
Tất nhiên nếu công cụ nào đó yêu cầu cập nhật dependency nằm trên GitHub thường thì vẫn bực, nhưng ít nhất các việc liên quan đến triển khai vẫn chạy được
Nghỉ uống cà phê
git vốn là công cụ được thiết kế để dùng được cả offline, nên tôi dùng local clone đã có sẵn
Trang trạng thái vừa thay đổi:
Investigating - We are currently experiencing an outage of GitHub products and are investigating.
Jun 29, 2023 - 17:52 UTC
Đến cả đọc cũng đỏ hết. Hình như đây là lần đầu tôi thấy mọi mục đều đỏ trên trang trạng thái
1 bình luận
Ý kiến trên Hacker News
https://downdetector.com/status/github/
Nếu không có thay đổi, chỉ cần sửa bug tốt thì tương đối dễ giữ ổn định. Thay đổi, tức tính năng mới, tạo ra bug mới và tải mới
node_modulesvào.gitignoreVề cảm giác, giữa việc 1% tổng thể bị sập 100% thời gian và 100% tổng thể bị sập 1% thời gian thì có một phía trông có vẻ tốt hơn, nhưng thực tế phía nào thực dụng hơn thì tôi không chắc. Tất nhiên nếu muốn thì có thể mirror, nhưng hiện tại nếu quyết tâm thì cũng làm được rồi nên đó không phải trọng tâm của chuyện này
git cloneđều có một bản sao đầy đủ của toàn bộ repository, và có thể làm hầu hết công việc mà không cần giao tiếp với máy chủ trung tâmDowntime ngắn chủ yếu ảnh hưởng đến hạ tầng xung quanh mã nguồn thực tế, tức workflow, issue, v.v.
Giống như khi us-east-1 sập. Vì tất cả cùng chung một con thuyền nên cùng nghỉ, và có lý do chính đáng để thư thả một chút
Vài tháng trước tôi nói chuyện với một người bên hỗ trợ khách hàng, và họ gần như đổ lỗi cho đủ loại tùy biến làm cho khách hàng lớn khiến độ ổn định giảm. Kết quả là trông có vẻ nợ kỹ thuật đã chất đống khổng lồ
Khả năng cao hơn đây là lỗi định tuyến mạng hoặc một sai sót nào khác ở tầng 4 trở xuống. Phần lớn thay đổi ứng dụng được đưa ra bằng triển khai tuần tự và canary, và nếu có vấn đề thì có thể rollback khá nhanh
.github.iohiển thị trang unicorn 503Quyết định đó nhiều lần chứng tỏ là lựa chọn sáng suốt, và tôi không nhớ CodeCommit từng có vấn đề đáng chú ý nào. Tuy nhiên nếu trong quy trình phát triển thực tế bạn dùng GitHub làm forge, dùng issue tracker hay PR để review, v.v. thì tôi không biết có cách nào tốt để tự cách ly không
Tất nhiên nếu công cụ nào đó yêu cầu cập nhật dependency nằm trên GitHub thường thì vẫn bực, nhưng ít nhất các việc liên quan đến triển khai vẫn chạy được
gitvốn là công cụ được thiết kế để dùng được cả offline, nên tôi dùng local clone đã có sẵnInvestigating - We are currently experiencing an outage of GitHub products and are investigating.
Jun 29, 2023 - 17:52 UTC