Embedded SRE at Mercari

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

Bài của engineering manager team Microservices SRE, giới thiệu mô hình; bài kể từ góc nhìn một SRE nhúng là Mercari 2022. Mọi nhận định là theo Mercari.

Bối cảnh

• Chuyển từ team ops tập trung sang DevOps và "you build it, you run it" làm gánh nặng vận hành của team sản phẩm tăng, nhiều team còn non tay.
• Mercari tách hẳn hai việc: platform engineering (team Platform dựng công cụ để team sản phẩm tự đi hết vòng đời phát triển) và SRE (thực hành vận hành production: response, observability, availability, delivery). SRE đứng giữa, là khách hàng của team Platform: Platform giải quyết khoảng 80% vấn đề chung cho mọi service, SRE lo 20% còn lại riêng theo service hay domain, và phản hồi lại cho Platform.

Thay đổi chính (mô hình nhúng)

• SRE là thực hành, không phải một vai trò cố định: không tuyển SRE cho từng team (theo Mercari rất khó); thay vào đó cử SRE vào team sản phẩm tạm thời rồi luân chuyển, để kiến thức lan dần thành thực hành chung của SWE.
• Chọn team (theo Mercari là quyết định quan trọng nhất): định lượng bằng dashboard toàn hệ (team nhiều sự cố, nhiều alert, error rate cao, ít dùng tính năng nền tảng mới), định tính bằng khảo sát developer và các đợt ra mắt lớn sắp tới; cuối cùng nói chuyện với EM và tech lead để thống nhất kỳ vọng.
• Làm việc: SRE tham gia họp, backlog và on-call của team, nhưng chỉ làm việc độ tin cậy, không làm tính năng. Checklist chung: Production Readiness Checklist, backup và khôi phục, observability, on-call và xử lý sự cố, playbook. Mục tiêu đặt bằng OKR: team sản phẩm có KR về độ tin cậy (đặt SLI/SLO và dùng trong quyết định sản phẩm), SRE có KR cho cả hệ (ví dụ playbook chuẩn nhiều team dùng được).
• Đánh giá: mỗi quý EM và tech lead chấm qua khảo sát (đánh giá chung, độ tin cậy có cải thiện không, team có tự tin vận hành khi SRE rời đi không).
• Luân chuyển mỗi hai quý, đủ để làm quen domain nhưng không để team phụ thuộc; giữa hai lần nhúng có thể có một quý làm việc độ tin cậy cho toàn hệ (ví dụ hệ quản lý playbook).
• Ví dụ: team search infra (traffic lớn nhất, release nhiều: benchmark chống hồi quy latency, chi phí, SLI/SLO); team monolith API đang chuyển từ on-prem lên Google Cloud (đưa về cùng stack monitoring với microservice để tracing liền mạch).
• Hướng tới: nhúng theo division (nhiều team cùng domain) thay vì từng team, vì số SRE quá ít so với số team và đổi domain mỗi lần luân chuyển tốn sức. Lâu dài, ba hướng theo ngôn ngữ Team Topologies: thành enabling team cho cả tính năng nền tảng mới; chuyên nhúng vào complicated subsystem; hoặc nhập vào Platform và cung cấp SRE dưới dạng công cụ.

Bài học cho SWE

• Tách platform engineering (công cụ chung) khỏi SRE (áp dụng vào từng service) giúp mỗi bên tập trung; SRE dùng công cụ của Platform và phản hồi lại (Nền tảng nội bộ cho service (đường ray chung)).
• Mục tiêu của SRE nhúng là tự làm mình thừa ở từng team; đo bằng việc team có tự vận hành được sau khi SRE rời đi (Mô hình tổ chức SRE).
• Khi ít SRE, chọn team nhúng bằng dữ liệu (sự cố, alert, error rate) cộng với trao đổi trực tiếp.

Liên quan

• Cùng công ty: Mercari 2019 · Mercari 2022
• Mô hình tổ chức SRE · Nền tảng nội bộ cho service (đường ray chung)