How we systematically improved our reliability
Bài tóm tắt Neon 2026 4. Điều chỉnh Độ khó: Trung bình
Neon · 2026 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc
Bối cảnh
- Lakebase Postgres (Neon) chạy một fleet rất lớn trên hai bề mặt (Neon và Databricks), ba cloud, hơn 30 region; mỗi region tới 15 cell (bản triển khai cô lập để scale ngang và thu nhỏ blast radius), tổng hơn 70 môi trường (2026). Ở quy mô hàng triệu database, process crash, máy chết, mạng chập chờn là chuyện hằng ngày.
- Control plane (tạo, cấu hình, theo dõi, phục hồi DB, HA, branch, scale-to-zero) hỏng thì khách không tạo, không đánh thức, không phục hồi được DB, nên không kết nối được.
- Đầu năm 2026, hai sự cố trong một tuần: cả hai bắt đầu từ một dependency bên ngoài hỏng, kích hoạt một vòng tự khuếch đại làm sập control plane và không tự hồi được.
Thay đổi chính
1. Postmortem theo chuẩn Databricks
- Mục đích là giảm thiệt hại cho khách sau này, không phải ghi lại sự kiện; người review không tham gia ứng cứu phải lần được từ trải nghiệm của khách xuống hệ thống và bằng chứng.
- Viết impact trước: ai (có mẫu số và phần trăm), cái gì (endpoint, region, cell, control/data plane, và cái gì không bị), nặng tới đâu (so baseline), bao lâu (liên tục hay ngắt quãng), chắc tới đâu (nguồn đo, điểm mù, chính xác hay ước lượng). Không bịa độ chính xác: không đếm được thì nói vậy và thêm việc cho observability. Đếm cả thiệt hại cho người nội bộ (on-call bị gọi đêm).
- AI agent đào log để đếm khách bị ảnh hưởng, nhưng không dán số của nó vào thẳng: bắt nó dựng notebook đặt mỗi con số cạnh query sinh ra nó để kỹ sư chạy lại. Tốt hơn nữa là có dashboard SLO/SLI để không cần AI.
- Ba mốc thời gian: phát hiện, giảm thiểu (chia nhỏ: gọi đúng người, hiểu vấn đề, quyết định, làm, chờ có tác dụng), hồi phục nhìn từ phía khách. Với mỗi mốc hỏi: cần gì để cắt đôi thời gian này?
- 5 Whys bắt đầu từ impact, rẽ nhánh thành cây: vì sao hỏng, vì sao ảnh hưởng nhiều, vì sao kéo dài, vì sao phát hiện chậm. "Lỗi người" hay "deploy xấu" không phải câu trả lời. Dependency hỏng cũng là lỗi của mình: tìm thứ phòng vệ còn thiếu (timeout, fallback, cache, cô lập).
- Action item cụ thể, kiểm được, xong trong vài ngày tới vài tháng, link từ đúng chỗ trong văn bản. Tóm tắt điều hành viết sau cùng; hai vòng review (team có người ngoài cuộc, và một reviewer cấp cao độc lập).
2. Hơn 30 bản sửa trong ba tháng
- DB của control plane (Postgres): sửa các lần query plan bị thoái hoá và chặn tái diễn, chặn transaction chạy lâu, tắt parallel query (gây lỗi plan và runtime).
- Bug và giá trị mặc định: thư viện mã nguồn mở, xử lý queue, TCP timeout, mặc định của connection pool. Phần lớn không phải code của Neon mà là mặc định thừa hưởng, không hợp với control plane quản lý hàng triệu DB.
- Thiết kế: cơ chế backpressure không hoạt động như mong đợi; dưới tải có starvation và mất công bằng giữa các loại việc.
3. Tìm lỗi sớm hơn: điểm rủi ro cho mỗi thay đổi
- Lỗi đến từ ba nguồn: môi trường (hạ tầng, mạng, dependency; cả hai sự cố bắt đầu ở đây), thay đổi của mình (code, config, migration, vận hành), workload của khách (traffic, retry, input xấu, đỉnh cron mỗi giờ).
- Risk = xác suất × tác động; điểm càng cao thì càng phải qua nhiều kiểm tra ở bốn giai đoạn:
- design: AI skill review độ tin cậy của thiết kế; premortem cho thay đổi rủi ro cao;
- build: review code, load test và failure test, kiểm rollback;
- release: ramp theo bậc, chủ tính năng theo dõi một SLO, operational readiness review;
- operate: bàn giao cho on-call, diễn tập on-call, xem lại mọi lần độ tin cậy tụt.
- Tiếp theo: FMEA, fault tree analysis, tự động hoá stress và failure test.
Bài học cho SWE
- Viết impact có mẫu số và độ chắc chắn trước; nó quyết định mức sửa tương xứng (Sự cố và postmortem).
- "Nhà cung cấp sập" không phải nguyên nhân hành động được; nguyên nhân là phòng vệ còn thiếu ở phía mình.
- Rất nhiều lỗi nằm ở giá trị mặc định của thư viện và pool; ở quy mô lớn phải đặt lại có chủ đích.
- Mức kiểm soát tỉ lệ với rủi ro của thay đổi: rủi ro thấp đi nhanh, rủi ro cao qua premortem và readiness review (Deploy và release an toàn).
- Backpressure chỉ có giá trị nếu đã được thử dưới tải thật; Neon chỉ thấy nó không hoạt động khi có sự cố (Load shedding, rate limit và backpressure).
Liên quan
Được nhắc tới trong
Chủ đề (5)
Công ty (1)