From vendors to vanguard: Airbnb's hard-won lessons in observability ownership

Airbnb · 2026 · 4. Điều chỉnh · Độ khó: Khó — bài gốc

Kể lại cuộc migration bắt đầu khoảng 2021. Đọc cùng Airbnb 2017 (khung alert trên Datadog bị thay) và Airbnb 2026 (hệ mới tự giám sát). Phần dùng AI để sinh PromQL được tóm tắt ngắn.

Bối cảnh

• Airbnb ban đầu thuê ngoài observability. Theo Airbnb, khi công ty trưởng thành, nhu cầu lệch khỏi động cơ của nhà cung cấp: tính tiền theo lượng dữ liệu nạp vào, nên chi phí tăng, trong khi thêm dữ liệu không tự làm MTTD/MTTR giảm; và vì đứng ngoài vòng phản hồi về cách dữ liệu được dùng, họ khó cải thiện workflow hay tối ưu chi phí.
• Họ thay mọi lớp của hạ tầng metric (instrument, thu thập, lưu trữ, hiển thị) bằng hệ tự vận hành dựa trên Prometheus. Quy mô migrate: khoảng 1.000 service, 300 triệu timeseries, 3.100 dashboard, hơn 300.000 alert.

Thay đổi chính

• Bản v1 (thất bại): làm theo lối "leo Everest ngày đầu": chọn service khó nhất (dữ liệu thưa, metric không theo chuẩn của hệ mới) làm đầu tiên, cố bắt chước hành vi hệ cũ để dashboard và alert trông y hệt. Kết quả: mất nhiều thời gian cho service đầu, báo động giả, dashboard lệch giữa hai hệ, phải đào tạo nhiều. Bài học họ rút ra: đừng sửa luôn các pattern dashboard/alert sai trong lúc migrate; tài liệu và đào tạo cho ngôn ngữ query mới là bắt buộc.
• Bản v2:
  • Bắt đầu bằng service dễ, gần với hệ đích: kiểm storage chịu được tải và hành xử thế nào lúc sự cố, làm công cụ dịch dashboard/alert, viết tài liệu, cho một nhóm nhỏ dùng giao diện mới để gom phản hồi UX trước khi mở rộng.
  • Dịch ý định của query, không dịch từng chữ: dashboard lâu năm có nhiều query sai (lấy trung bình của p95, cộng tổng latency). Bộ dịch nhận ra ý định (ví dụ có p95) thì bỏ các aggregation chồng lên và trả về query histogram chuẩn. Vì giữ nguyên tên metric cũ (để code và dữ liệu không lệch nhau), không suy được loại metric từ hậu tố _total như thường lệ trong Prometheus; họ dựng metadata engine trong lớp dịch, quét định kỳ mọi metric và ghi loại bằng một label nội bộ (otel_metric_type).
  • Không giữ shim ngôn ngữ cũ sau migration để người dùng học PromQL; kèm công cụ AI có metadata ngữ nghĩa của metric (loại, đơn vị) để sinh PromQL. Theo Airbnb, các việc như chẩn đoán sự cố, tạo dashboard từ vài giờ xuống vài phút.
  • Thay luôn khung alert dù kế hoạch ban đầu là giữ nguyên: alert viết như code có autocomplete, backtesting (alert này lẽ ra đã bắn khi nào trong quá khứ), diff trước khi deploy. Theo Airbnb, việc này làm người dùng thấy giá trị của migration ngoài chi phí, và vì alert tập trung nên công migrate của khách giảm.

Vì sao

• Theo Airbnb, tự động hoá thôi chưa đủ: dịch mù các pattern sai chỉ chuyển nợ kỹ thuật sang hệ mới; những lúc có tác động lớn nhất là khi chủ động phá tương thích để có mặc định tốt hơn (Migration không downtime).
• Lớp đắt nhất khi đổi backend không phải storage mà là lớp tương tác (frontend, công cụ viết alert, workflow): họ phải chuyển mọi team sang công cụ hiển thị và khung alert mới cùng lúc. Lời khuyên của họ: sở hữu lớp tương tác ngay cả khi chưa định migrate (Observability và monitoring).
• Định giá theo lượng nạp của nhà cung cấp tạo động cơ ngược với tối ưu chi phí của khách (Chi phí hạ tầng và build vs buy).

Bài học cho SWE

• Migration nhiều khách: service đầu tiên để chứng minh đường đi, nên chọn cái dễ; để service khó ra sau khi công cụ đã chín.
• Bộ dịch nên hiểu ý định để chuẩn hoá, kèm metadata đáng tin về loại metric thay vì suy từ tên.
• Ban đầu đừng đổi hành vi cho khách, nhưng nếu một thay đổi làm migration có giá trị rõ cho họ (alert tốt hơn), nó có thể giảm tổng công sức.

Liên quan

• Airbnb 2017 · Airbnb 2026 · Uber 2026 · Miro 2020 · ClickHouse 2025 (cùng lý do chi phí khi rời nhà cung cấp)
• Observability và monitoring · Migration không downtime · Chi phí hạ tầng và build vs buy