Improving how we deploy GitHub

GitHub · 2021 · 3. Quy mô lớn · Độ khó: Dễ — bài gốc

Bối cảnh

Trong một năm, số developer đóng góp vào app GitHub.com tăng gấp đôi, và công cụ deploy cũ không còn theo kịp.
Deploy bằng chatops trong một kênh Slack (#dotcom-ops) theo mô hình branch deploy (deploy branch rồi mới merge). Một kênh vừa quản lý hàng đợi, vừa theo dõi deploy, vừa làm việc khác cho nhiều người: các bước của một lần deploy bị chen giữa bởi hàng trăm tin nhắn, developer không theo dõi được thay đổi của mình.
Canary chỉ có một tầng 2% traffic, nên nhiều lỗi lọt qua tới 100% rồi mới phải mở sự cố và rollback.
Mỗi bước phải gõ một lệnh chatops riêng và tự phán đoán, hay gõ sai.

Thay đổi chính

Mô hình deploy thành máy trạng thái: một deploy gồm nhiều stage; giữa các stage có gate kiểm tra trước khi đi tiếp.
Chuỗi tự động: canary 2% → canary 20% → production 100% → sẵn sàng merge, mỗi gate là bộ hẹn giờ 5 phút. Có thể tạm dừng để test thêm, rollback/revert nhanh từ giao diện.
Một lệnh chatops khởi động cả chuỗi; theo dõi trên một UI tổng hợp thay cho việc lần theo kênh Slack.
Xây trên hệ thống deploy nội bộ đã có, không viết lại từ đầu.

Kết quả

Theo GitHub: phản hồi nội bộ rất tích cực; kinh nghiệm này góp phần định hình tính năng CD của GitHub Actions. Bài không có số liệu về số sự cố trước/sau.

Vì sao

Theo GitHub: availability là ưu tiên số một, mà số người cùng deploy tăng gấp đôi thì quy trình dựa vào con người và một kênh chat không scale được.

Bài học cho SWE

Công cụ đủ tốt ở N người sẽ vỡ ở 2N người, kể cả khi hệ thống không đổi. Quy mô tổ chức là một trục scale riêng.
Canary nhiều tầng (2% rồi 20%) bắt được loại lỗi mà một tầng nhỏ bỏ sót, nhưng vẫn giới hạn được thiệt hại.
Tự động hoá quy trình nhiều bước giảm lỗi con người; vẫn giữ giao diện quen thuộc (chatops) để khởi động.