Investment Insights from Two Years of AI-Powered Postmortem Analysis

Zalando · 2025 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

• Văn hoá postmortem của Zalando theo sách SRE của Google: team phụ trách làm RCA và hành động phòng ngừa, sự cố chỉ đóng khi lãnh đạo (tới VP Engineering tuỳ mức) ký; bài học đi lên qua họp vận hành hằng tuần.
• Giới hạn: postmortem khác nhau về độ sâu; RCA phản ánh giả định của team; nối các sự cố giữa team cần quan hệ cá nhân. Đọc kỹ một postmortem mất 15–20 phút; với hàng nghìn postmortem, câu hỏi chiến lược như "vì sao datastore hỏng nhiều nhất ở quy mô lớn" không trả lời nhanh được.
• Nhóm phụ trách các datastore trong Tech Radar (Postgres, DynamoDB, S3, ElastiCache, Elasticsearch) thử dùng LLM.

Thay đổi chính

• Thử NotebookLM trước: tóm tắt nhanh gấp 3 nhưng vẫn mất hàng tuần cho một nhóm chuyên gia, và có ảo giác nặng, mất ngữ cảnh sự cố.
• Pipeline nhiều tầng thay vì một model context lớn (tránh "lost in the middle", latency và chi phí): mỗi tầng một mục tiêu, theo kiểu map-fold (map từng tài liệu độc lập, fold bằng LLM hoặc hàm tất định):
  1. Tóm tắt theo 5 mục cố định (chuyện gì, nguyên nhân gốc, tác động, xử lý, phòng ngừa), cấm đoán, thiếu thì ghi rõ là thiếu.
  2. Phân loại: công nghệ nào trực tiếp góp vào sự cố, hoặc "None"; có ví dụ phủ định.
  3. Analyzer: digest 3–5 câu về vai trò của công nghệ trong sự cố, đọc trong 30–60 giây.
  4. Patterns: đưa toàn bộ digest vào một prompt ra báo cáo một trang về các mẫu lặp lại.
  5. Opportunity: từ mẫu ra cơ hội đầu tư.
• Người kiểm ở mọi tầng: lúc phát triển, 100% output được người upvote/downvote so với bản gốc; khi ổn định giảm xuống 10–20% mẫu ngẫu nhiên mỗi lô; báo cáo cuối vẫn do người biên tập.
• Model: bắt đầu bằng model mở 3B–27B tự host (LM Studio), sau chuyển sang Claude Sonnet 4 trên Bedrock, chủ yếu vì yêu cầu pháp lý (postmortem có PII của người trực, số GMV).

Vì sao (kết quả hai năm, theo Zalando)

• Nguyên nhân chính của sự cố datastore là cách dùng, không phải công nghệ hỏng: cấu hình và deploy, capacity và scaling. S3: lỗi cấu hình artifact deploy làm app mất quyền vào bucket → dựng kiểm chứng tự động cho thay đổi IaC, chặn được 25% sự cố datastore về sau. ElastiCache: lặp lại mẫu CPU 80% làm tăng latency lúc cao điểm → định hướng capacity planning và chọn instance. Các mẫu lặp khác: không có kiểm chứng tự động cho cấu hình/IaC, thay đổi thủ công tuỳ hứng, không progressive delivery cho datastore, đánh giá thấp traffic, scale chậm.
• Trong 5 năm chỉ vài sự cố do lỗi của chính công nghệ (driver JDBC, hai bug Postgres: race ở autovacuum launcher bản 12, rò bộ nhớ ở logical replication khi lên 17).
• Phân tích từ hàng ngày xuống hàng giờ; lộ "điểm nóng ẩn" như cấu hình connection pool, circuit breaker gây lỗi dây chuyền.
• Chỗ AI hụt: model nhỏ ảo giác tới 40% (từng bịa cả một sự cố DynamoDB vì chữ DynamoDB có trong tiêu đề playbook được link), prompt chặt + người kiểm còn dưới 15%, model lớn thì gần như hết; surface attribution error (gán công nghệ chỉ vì được nhắc tên) vẫn khoảng 10% kể cả với Sonnet 4; không trích được số (GMV, số khách bị ảnh hưởng, thời gian sửa) đáng tin nên dùng dataset sự cố nội bộ; công nghệ nội bộ (Skipper) phân tích không chấp nhận được. Mỗi tài liệu phải dưới 120 giây để chạy được dữ liệu cả năm: model 27B mất 90–120 giây, pipeline nhiều model nhỏ khoảng 20 + 60 giây (dữ liệu một năm dưới 24 giờ), Sonnet 4 khoảng 30 giây.

Bài học cho SWE

• Kho postmortem là dữ liệu cho quyết định đầu tư, nhưng chỉ khi đọc được ở quy mô; chia việc đọc thành nhiều tầng nhỏ có output người đọc được.
• Mỗi tầng trung gian phải kiểm được bằng người, nếu không không ai tin báo cáo cuối.
• Số liệu định lượng của sự cố nên nằm trong dữ liệu có cấu trúc từ đầu, đừng trông vào trích xuất từ văn bản.

Liên quan

• Sự cố và postmortem · Xử lý sự cố và on-call
• Zalando 2023 · Meta 2025 · Dropbox 2021