Xây dựng nền tảng Observability tương lai: Bài học từ Skyscanner và OpenTelemetry

Trong thế giới phát triển phần mềm hiện đại, việc duy trì tính ổn định của hệ thống phân tán là một thách thức lớn. Tại hội nghị InfoQ Dev Summit Munich, Wayne Bell (Giám đốc Nền tảng tại Skyscanner) và Dan Gomez Blanco (Kiến trúc sư Observability tại New Relic, cựu nhân viên Skyscanner) đã có bài thuyết trình sâu sắc về việc xây dựng một nền tảng observability (khả năng quan sát) có khả năng thích ứng với tương lai.

Bài viết này sẽ tóm tắt hành trình của Skyscanner trong việc tái cấu trúc hệ thống quan sát của mình, từ việc áp dụng các tiêu chuẩn mở như OpenTelemetry cho đến thay đổi tư duy văn hóa để trao quyền cho các kỹ sư.

Tầm quan trọng của ngữ cảnh (Context)

Mọi thứ đều xoay quanh ngữ cảnh. Trong observability, ngữ cảnh là yếu tố giúp chúng ta trả lời các câu hỏi bằng bằng chứng thực tế thay vì dựa vào trực giác. Trước đây, chúng ta thường nói về ba trụ cột: metrics (số liệu), traces (vết dấu) và logs (nhật ký). Tuy nhiên, việc coi chúng là các trụ cột riêng biệt thường tạo ra các "silos" dữ liệu.

OpenTelemetry Instrumentation

Bạn có thể có số liệu về việc CPU bị giới hạn, nhưng làm thế nào để biết nó có liên quan đến trải nghiệm người dùng kém hay không? OpenTelemetry giải quyết vấn đề này bằng cách chuyển từ các trụ cột riêng lẻ sang các tín hiệu có tương quan (correlated signals). Ví dụ, với một enduser.id chuẩn, bạn có thể thấy bao nhiêu người dùng bị ảnh hưởng bởi một sự cố, và từ đó truy vết (trace) để tìm nguyên nhân gốc rễ trong một giao dịch cụ thể.

Tương lai hóa với OpenTelemetry

Vào năm 2020, Skyscanner đối mặt với một kiến trúc observability phức tạp với nhiều mối quan hệ nhà cung cấp khác nhau và các hệ thống nội bộ tản mạn. Điều này dẫn đến việc dữ liệu đo lường bị đứt gãy và các kỹ sư phải chuyển đổi ngữ cảnh liên tục giữa các nền tảng trong lúc xử lý sự cố.

Giải pháp của họ là dựa vào hai nguyên tắc:

1. Sử dụng OpenTelemetry ở các lớp đo lường, xuất, chuyển chuyển và xử lý.
2. Sử dụng một nền tảng duy nhất để tương quan tất cả dữ liệu đo lường.

OpenTelemetry giúp tách biệt các mối quan tâm xuyên suốt (cross-cutting concerns) khỏi việc triển khai cụ thể. Điều này mang lại một API ổn định cho các kỹ sư, giúp họ không phải refactor mã mỗi khi nền tảng thay đổi cấu hình bên dưới. Hơn nữa, việc tích hợp telemetry trực tiếp vào các thư viện (như Deno, Quarkus, Azure SDK) giúp giảm chi phí vận hành và đảm bảo dữ liệu được thu thập ngay khi tính năng mới được ra mắt.

Ranh giới của Nền tảng là gì?

Một câu hỏi quan trọng là: Nền tảng của bạn nằm ở đâu? Nhiều người nghĩ nền tảng chỉ là hạ tầng (infrastructure). Tuy nhiên, để đảm bảo tính nhất quán, ranh giới của nền tảng cần được mở rộng sang phía ứng dụng.

Thay vì chỉ cung cấp hạ tầng và để người dùng tự cấu hình, đội ngũ nền tảng nên "nướng" các cấu hình tốt nhất vào trong bộ công cụ mà các nhà phát triển sử dụng. Điều này có thể thực hiện thông qua các biến môi trường, file cấu hình chia sẻ, hoặc các Docker image cơ sở. Mục tiêu là cung cấp cho kỹ sư một "khả năng quan sát khả thi tối thiểu" (minimal viable telemetry) mà họ cần để vận hành dịch vụ mà không cần cấu hình thủ công phức tạp.

Văn hóa: Phần khó khăn nhất

Dan Gomez Blanco nhận định rằng công cụ là phần dễ nhất, còn văn hóa mới là thách thức thực sự. Wayne Bell đã chia sẻ câu chuyện chuyển đổi từ vai trò sản phẩm sang vai trò nền tảng tại Skyscanner và những khó khăn trong việc thúc đẩy việc áp dụng nền tảng mới.

Ban đầu, việc áp đặt các tiêu chuẩn mới gặp phải sự kháng cự. Các kỹ sư cảm thấy quyền tự chủ của họ bị đe dọa và họ giữ lại các hệ thống cũ vì chúng quen thuộc. Wayne nhận ra rằng thay vì áp đặt, họ cần thay đổi tư duy: Nền tảng cũng là một Sản phẩm (Platform as a Product).

Trong tư duy này, các kỹ sư chính là "khách hàng". Đội ngũ nền tảng cần:

• Hiểu nỗi đau của khách hàng (các kỹ sư).
• Xác định các kết quả chung (shared outcomes) với các chủ sở hữu sản phẩm.
• Để các kỹ sư tham gia vào việc định nghĩa tiêu chuẩn.
• Đo lường mức độ trưởng thành và ăn mừng những thất bại (như cơ hội học hỏi).

Kết quả đạt được

Việc áp dụng tư duy "Nền tảng là Sản phẩm" và OpenTelemetry đã mang lại những kết quả ấn tượng cho Skyscanner:

• Giảm 20% sự cố lặp lại: Nhờ khả năng tìm ra nguyên nhân gốc rễ nhanh hơn và ngăn chặn sự cố tái diễn.
• Giảm 40% nỗ lực trùng lặp: Giảm tải nhận thức (cognitive load) và độ phức tạp cho các kỹ sư, giúp họ tập trung vào việc phục vụ hành khách.
• Tiêu chuẩn SLO được sở hữu bởi sản phẩm: Các chỉ số SLO (Service Level Objectives) hiện được gắn liền với kết quả kinh doanh của hành khách thay vì chỉ là các số liệu kỹ thuật khô khan.

Kết luận

Hành trình của Skyscanner cho thấy rằng xây dựng một nền tảng observability thành công không chỉ là việc chọn đúng công nghệ. Đó là sự kết hợp giữa việc sử dụng các tiêu chuẩn mở như OpenTelemetry để tạo ra sự ổn định kỹ thuật, và việc thay đổi văn hóa tổ chức để coi nền tảng là một sản phẩm phục vụ chính các kỹ sư.

"Nếu bạn muốn cung cấp cho các kỹ sư một sự trừu tượng ổn định, các tiêu chuẩn mở là con đường nên đi. Văn hóa mới là thứ thúc đẩy việc áp dụng, niềm tin và cuối cùng là tác động của nền tảng." - Dan Gomez Blanco.