Mô hình tổ chức SRE
Chủ đề Bài đọc thử miễn phí
Bài toán
Lúc nhỏ, một team ops hay SRE tập trung trực và vận hành mọi thứ. Khi chuyển sang microservice và "you build it, you run it", team sản phẩm phải tự sở hữu service trên production, nhưng nhiều team chưa có kỹ năng, còn số SRE luôn ít hơn nhiều so với số team. Câu hỏi:
- Đội reliability đứng ở đâu so với team sản phẩm và team nền tảng?
- Làm sao nhân rộng thực hành (SLO, error budget, on-call, playbook) khi không đủ người cho từng team?
- Hỗ trợ được chia theo tiêu chí gì: đều cho mọi team, theo độ quan trọng kinh doanh, hay theo team đang gặp khó?
Trang này nói về vị trí và cách làm việc của đội reliability trong tổ chức. Lịch trực, vai trò khi có sự cố và công cụ quy trình nằm ở Xử lý sự cố và on-call; công cụ dùng chung do team nền tảng làm nằm ở Nền tảng nội bộ cho service (đường ray chung).
Diễn tiến theo thời gian
- 2019 · Booking.com: hàng chục team sản phẩm cùng đẩy code vào một hệ, ai cũng kỳ vọng team reliability làm hết. Reliability Collaboration Model liệt kê mọi việc vận hành và chia theo ba mức hỗ trợ: mặc định mức 3 (team sản phẩm tự lo), mức 1 thì team reliability nhận gần hết, nhưng pager luôn chia chung với developer. Mức do lãnh đạo sản phẩm chọn theo độ quan trọng; Ownership Map lộ hệ được hỗ trợ thừa hoặc thiếu. Booking.com 2019
- 2020 · Netflix: team sở hữu tự trực service của mình; team trung tâm CORE không sở hữu service nào, trực alert trên KPI kinh doanh (lượt bắt đầu stream mỗi giây), gọi đúng team và làm Incident Manager; sau sự cố lo phân tích sociotechnical và chia sẻ bài học cho toàn công ty. Netflix 2020
- 2021→2022 · Mercari: tách platform engineering (công cụ để team sản phẩm tự đi hết vòng đời, khoảng 80% vấn đề chung) khỏi SRE (20% riêng theo service, SRE là khách hàng của Platform). SRE nhúng tạm thời vào team sản phẩm, trực on-call ở đó, chỉ làm việc độ tin cậy (production readiness, backup, observability, playbook, SLI/SLO), luân chuyển mỗi hai quý; đánh giá bằng khảo sát EM/TL, trong đó có câu "team có tự vận hành được khi SRE rời đi không". Hướng tiếp: nhúng theo division thay vì từng team. Mercari 2022 Kể từ góc nhìn một SRE nhúng: đưa SLO và error budget thành điều kiện release, thêm SLI gần người dùng. Mercari 2022
- 2022 · Achievers: từ "chỉ SRE trực" sang "engineer sở hữu service trên production". SRE nhân rộng bằng mặc định do nền tảng sinh: dashboard và bộ alert golden signals cho mọi service (tắt hay tuỳ biến được), SLO và error budget mà product owner cam kết dừng làm tính năng khi không đạt, canary có phân tích tự rollback. Achievers 2022
- 2024 · GitHub: chuẩn reliability/security nhân rộng bằng chương trình quản trị: scorecard áp tự động theo tier khai trong YAML, vai trò sponsor/champion/delegate ở từng tổ chức, dashboard service chưa đạt theo tier; hướng tới biến scorecard thành control (lệch là sự cố). GitHub 2024
Các lựa chọn và đánh đổi
| Mô hình | Ví dụ | Được | Mất |
|---|---|---|---|
| Team ops/SRE tập trung trực tất cả | Achievers trước 2022, Monzo trước 2021 (nhóm primary/shadow chung) | Đơn giản khi nhỏ; một nhóm hiểu toàn hệ | Kiến thức không theo kịp số service; developer không cảm thấy hậu quả |
| Nhóm trung tâm không sở hữu service, canh KPI kinh doanh và chỉ huy sự cố | Netflix CORE 2020 | Thấy sự cố liên service mà alert từng team bỏ sót; bài học lan toàn công ty | Xa chi tiết từng service; cần team sở hữu đủ trưởng thành để tự trực |
| Hỗ trợ theo mức, chọn theo độ quan trọng kinh doanh | Booking 2019 | Công sức reliability tỉ lệ với giá trị; ranh giới việc rõ ràng | Phải liệt kê việc và duy trì bản đồ sở hữu; team mức 3 tự lo hết |
| SRE nhúng có luân chuyển | Mercari 2021–2022 | Đưa thực hành vào tận team; mục tiêu là team tự làm được | Mỗi SRE chỉ phủ vài team mỗi năm; đổi domain tốn sức; khó đánh giá kết quả |
| Mặc định do nền tảng sinh, SRE đứng sau | Achievers 2022, Mercari (vai Platform) | Phủ mọi service ngay, không cần người | Mặc định không hiểu domain; team có thể tắt mà không ai biết |
Quy tắc rút ra
- Team sở hữu vẫn giữ pager dù đội reliability đứng ở đâu: Booking chia pager kể cả ở mức hỗ trợ cao nhất, Netflix để team tự trực service, Mercari cho SRE nhúng trực cùng team chứ không thay team. Booking.com 2019 Netflix 2020 Mercari 2022
- Tách làm công cụ chung (platform) khỏi áp dụng vào từng service (SRE), và cho SRE phản hồi về platform. Mercari 2022
- Khi ít SRE, nhân rộng bằng mặc định (dashboard, alert, SLO template, canary analysis) trước, rồi dồn người vào chỗ dữ liệu cho thấy cần (nhiều sự cố, nhiều alert, ra mắt lớn). Achievers 2022 Mercari 2022
- SLO chỉ có tác dụng khi phía sản phẩm cam kết đánh đổi tốc độ tính năng khi hết error budget; đưa nó vào OKR hay vào điều kiện release. Achievers 2022 Mercari 2022
- Mức hỗ trợ nên do người chịu trách nhiệm kinh doanh chọn theo độ quan trọng, và cần một bản đồ để thấy hỗ trợ thừa hay thiếu. Booking.com 2019
- Đo SRE nhúng bằng việc team tự vận hành được sau khi SRE rời đi, không bằng số việc SRE làm. Mercari 2022
- Một tầng nhìn toàn hệ (alert trên KPI kinh doanh) bổ sung cho alert của từng team. Netflix 2020
Câu hỏi mở
- Mọi nguồn đều do chính công ty tự mô tả; chưa có nguồn so sánh kết quả (MTTR, số sự cố, độ hài lòng) giữa các mô hình, hay trước-sau khi đổi mô hình.
- Tỉ lệ SRE trên số engineer hay số team chưa nguồn nào nêu; Mercari chỉ nói "quá ít so với số team".
- Mercari (2022) đang thử nhúng theo division và nêu ba hướng lâu dài (enabling team, chuyên complicated subsystem, nhập vào Platform); chưa có bài tiếp kể kết quả.
- Ngưỡng tổ chức để chuyển từ nhóm trực chung sang team tự trực: Monzo đổi ở khoảng 100–150 engineer (Monzo 2022); xem thêm câu hỏi mở ở Xử lý sự cố và on-call.
- Liên hệ: Xử lý sự cố và on-call (lịch trực, vai trò khi có sự cố), Nền tảng nội bộ cho service (đường ray chung) (công cụ và mặc định do team nền tảng cung cấp), Observability và monitoring (dashboard, alert mặc định), Deploy và release an toàn (SLO và canary như điều kiện release).
Được nhắc tới trong
Chủ đề (4)
Công ty (5)