Triggered: Incident #1234 (incident process needs fixing)

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

Bài trên blog PayPal Tech, do một Agile Coach kể. Bài không nêu số liệu kỹ thuật; giá trị nằm ở cách đưa một quy trình chung vào tổ chức gồm nhiều team tự chủ. Các nhận định dưới đây là theo tác giả.

Bối cảnh

• Khối phát triển sản phẩm gồm các team đa chức năng, tự chủ cao, sở hữu tính năng từ frontend đến deploy. Mặt trái: mỗi team có văn hoá và cách làm riêng, không có cơ quan trung tâm quy định quy trình.
• Cuối 2019, tác giả thường được mời đi điều phối postmortem cho nhiều team, và nhận ra không thể chỉ một người làm việc đó.

Thay đổi chính

• Lập nhóm tình nguyện liên phòng ban (Security, IT, Legal, Risk, Engineering). Phát hiện: sự cố không chỉ là việc của engineering. Khi ảnh hưởng tới người dùng, nó là việc của cả risk, legal và chăm sóc khách hàng.
• Bốn điều cần làm rõ:
  • Thế nào là một sự cố (không thì người ta không biết bất thường nào cần báo);
  • mức nghiêm trọng định nghĩa rõ;
  • phân loại sự cố (nhóm chia thành các loại như Security, Operational, Internal…; mỗi loại có tài liệu riêng);
  • giá trị lớn nằm ở tìm mẫu lặp, liên kết giữa các sự cố, không chỉ ở việc sửa ngay.
• Đồng bộ bằng tài liệu (loại Operational): sự cố là gì, trực on-call, sự cố do người dùng báo, nguyên tắc alert, runbook, trong và sau sự cố, postmortem. Cố ý giữ ở mức cao, để chi tiết kỹ thuật cho từng team, vì liệt kê hết sẽ nhanh lỗi thời và lấn vào phần của team. Trang đầu có sơ đồ quy trình đọc được khi đang áp lực.
• Minh bạch bằng danh sách sự cố chung: cổng báo cáo theo từng loại, nộp ngay khi đã dập lửa, bổ sung kết quả postmortem sau. Mỗi báo cáo tự đăng tóm tắt vào một kênh Slack công khai để người khác biết, đề nghị giúp, góp thông tin.
• Ra mắt bằng các buổi "tour" trực tiếp cho từng team thay vì một email.

Vì sao

• Không có quyền ra lệnh thì chỉ thay đổi được bằng đồng thuận (alignment) và minh bạch. Theo tác giả: đừng làm quy trình quá cứng; người ta phải tự muốn báo cáo, không phải coi đó là việc vặt.

Bài học cho SWE

• Định nghĩa "sự cố" và mức nghiêm trọng là bước đầu, trước mọi công cụ (Xử lý sự cố và on-call).
• Danh sách sự cố chung trên toàn tổ chức là điều kiện để thấy mẫu lặp giữa các postmortem (Sự cố và postmortem).
• Còn bỏ ngỏ theo bài: onboarding người mới vào quy trình, giữ nhịp postmortem khi chỉ vài người biết điều phối.

Liên quan

• Booking.com 2017 (quy trình ở tổ chức gần 2.000 người)
• Monzo 2022 · LinkedIn 2018
• Xử lý sự cố và on-call · Sự cố và postmortem