Engineering operational excellence, a case of continuous improvement

Nubank · 2023 · 3. Quy mô lớn · Độ khó: Cơ bản — bài gốc

Bài về quy trình ở một đơn vị (NuSeguros, bảo hiểm); không có số liệu kết quả.

Bối cảnh

Nubank (2023) có stack đồng nhất: hàng nghìn service Clojure trên Kafka, Datomic, DynamoDB; app Flutter; pipeline dữ liệu Scala. Engineer sản phẩm vừa làm tính năng vừa lo job nền, tích hợp đối tác, hỗ trợ khách, debug, giám sát, tiết kiệm chi phí.
Theo tác giả, cái khó là giữa hai cực: quy trình quá nặng hoặc không có quy trình.

Mục tiêu gắn metric: học từ lỗi (metric: số nguyên nhân gốc tạo mới so với đã giải), có thêm thời gian cho giá trị kinh doanh (metric: số ticket mức thấp/cao, nhiều ticket thấp thì nên ưu tiên nợ kỹ thuật), trải nghiệm khách (tỉ lệ lỗi, thời gian phản hồi).
Lập kế hoạch: mỗi tính năng có SLI/SLO từ lúc thiết kế, kèm playbook và dashboard; metric và dashboard mặc định có sẵn nên chi phí thấp.
Vận hành: trực theo tuần (đổi ca trưa thứ Tư), trong giờ làm việc như thường, ngoài giờ chỉ nhận ticket mức cao đã định nghĩa lúc thiết kế; bàn giao ticket còn dở cho ca sau. Mọi vi phạm ngưỡng SLO tự mở ticket có mức độ; support cũng mở ticket; tất cả về một nền tảng theo dõi, báo vào kênh Slack, mức cao thì gọi người trực phải vào trong thời gian cam kết.
Playbook: gặp lỗi đã biết thì làm theo SOP để giảm nhẹ nhanh; người trực phải viết playbook cho lỗi mới và cập nhật playbook cũ trong ca của mình.
Cải tiến: họp tổng kết mỗi ca (số ticket, mức độ, tác động, nguyên nhân gốc mới và đã giải), postmortem theo five whys, mỗi cuộc họp ra action item có chủ và hạn (thường là cuộc họp tuần sau).

Theo Nubank: nguồn ticket chung (SLO + support) cho dữ liệu để đo các mục tiêu; "cơ chế" (alarm, guard rail, kiểm tra) đáng tin hơn thiện chí.

Đặt SLO lúc thiết kế và để vi phạm SLO tự sinh ticket thì on-call có hàng đợi việc đo được, không chỉ alert.
Theo dõi tỉ lệ nguyên nhân gốc tạo mới/đã giải để biết team đang trả nợ hay tích nợ.
Viết playbook là việc của ca trực, không là dự án riêng.