How we manage our 1200 incident playbooks

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

Bối cảnh

• Zalando gom playbook sự cố về một chỗ vào 9/2019, khi chuẩn bị Cyber Week. Đến 2023: hơn 1.200 playbook, cho 850+ application thuộc diện trực, 100+ team on-call (khoảng 1,41 playbook/app, 12/team). Số playbook tăng vọt mỗi quý 3 (chuẩn bị Cyber Week).

Thay đổi chính

• Playbook là thủ tục khẩn cấp được duyệt trước bởi Business Owner của tính năng, dùng khi cơ chế resilience sẵn có (circuit breaker…) không đủ. Thường là cố ý làm xấu trải nghiệm để cứu hệ. Vì đã được duyệt, người trực làm luôn, không phải xin quyết định giữa sự cố.
• Mỗi playbook ghi: điều kiện kích hoạt, tác động kinh doanh, tác động vận hành, thời gian phục hồi, các bước. Thường bao cả một hệ vài microservice, vì nhìn rộng thì có nhiều cách giảm thiểu hơn.
• Ví dụ:
  • Trang danh mục: tắt lần lượt nguồn dữ liệu (teaser, sản phẩm tài trợ, outfit) để giảm tải backend và Elasticsearch, xếp theo tác động kinh doanh thấp nhất trước. Một ca tối Cyber Week, một nửa team điều tra độ trễ khó chẩn đoán, nửa kia chạy liền mấy playbook để giảm tác động.
  • Monitoring ZMON: pre-scale cho Cyber Week làm lượng metric tăng nhiều lần, Cassandra sau KairosDB quá tải. Chia metric thành ba tầng quan trọng; khi quá tải chỉ nhận tầng 1, giảm 40% tải TSDB (thời gian phục hồi 2 phút sau khi đổi cấu hình).
• Quản lý như code: site mkdocs, thư mục sinh theo team trên OpsGenie; ban đầu 3 người review, sau chuyển sang CODEOWNERS theo phòng ban; template pull request có checklist. Sinh thêm file JSON metadata (application, ngày hết hạn) để nối vào quy trình review application; app từ một mức quan trọng trở lên bắt buộc có playbook.
• Playbook được review trong team trực, chia sẻ khi bàn giao ca, diễn tập trong game day.

Vì sao

• Theo Zalando: quyết định khó (hy sinh tính năng nào) nên làm lúc bình tĩnh và có người chịu trách nhiệm kinh doanh; giữa sự cố chỉ thực thi.
• Giữ markdown trong repo dù dữ liệu có cấu trúc không lý tưởng, vì review chéo team qua pull request là lợi thế chính.
• Viết playbook buộc engineer nghĩ trước kịch bản quá tải và hỏng, dẫn tới sửa thiết kế để dễ can thiệp hơn. "Dùng đủ thường thì nên tự động hoá."

Bài học cho SWE

• Chuẩn bị sẵn các nút "giảm cấp có kiểm soát", xếp theo chi phí kinh doanh (Load shedding, rate limit và backpressure).
• Duyệt trước quyết định đánh đổi để người trực không phải chờ ai (Xử lý sự cố và on-call).
• Playbook có ngày hết hạn và được nối vào quy trình review, nếu không nó sẽ cũ.

Liên quan

• Zalando 2021 · Zalando 2024 (cùng công ty, Elasticsearch)
• Booking.com 2017 · Dropbox 2021
• Xử lý sự cố và on-call · Load shedding, rate limit và backpressure