Tại sao Observability và Telemetry là chìa khóa cho kỹ sư phần mềm hiện đại?

Tại sao Observability và Telemetry là chìa khóa cho kỹ sư phần mềm hiện đại?

Trong bài phát biểu của mình tại hội nghị GOTO Copenhagen, Martin Thwaites đã chỉ ra rằng khả năng quan sát (observability) cần phải tiến hóa để bắt kịp với các kiến trúc Serverless và hướng sự kiện (event-driven). Theo ông, OpenTelemetry có thể giúp tách rời telemetry khỏi các nhà cung cấp dịch vụ, cho phép các nhà phát triển tạo ra dữ liệu nhất quán và chất lượng cao, từ đó giải thích hành vi thực tế của hệ thống. Việc sử dụng từ vựng chung và telemetry tốt sẽ giúp quá trình gỡ lỗi nhanh hơn, đồng thời cải thiện độ tin cậy, tốc độ và năng suất của đội ngũ.

Observability trong kỷ nguyên kiến trúc hiện đại

Observability hiện đại gắn liền chặt chẽ với định nghĩa về các "hệ thống" hiện đại, quy trình phát triển "hiện đại" và kiến trúc "hiện đại". Thwaites giải thích rằng đây là cách chúng ta nói về sự thay đổi trong cách kiến trúc, xây dựng và hỗ trợ các hệ thống so với thời của các ứng dụng monolith và máy chủ vật lý truyền thống.

"Chúng ta hiện đang xây dựng các kiến trúc Serverless, Hướng sự kiện và dựa trên Cell (Cell-based), do đó cách chúng ta nghĩ về telemetry và cuối cùng là observability xung quanh chúng cũng nên thay đổi theo," Thwaites nhấn mạnh.

Vai trò của OpenTelemetry

OpenTelemetry đóng vai trò là chất kết dính giữa các hệ thống của bạn, ghi lại những gì đang xảy ra (phát telemetry), và hệ thống (hoặc nhiều hệ thống) giúp bạn hiểu rõ dữ liệu đó. Điểm quan trọng là nó không bị ràng buộc với bất kỳ cách cụ thể nào để điều tra dữ liệu, nghĩa là nó không phụ thuộc vào cách một nhà cung cấp hay giải pháp cụ thể lựa chọn.

"Sự tách rời này biến nó thành một công cụ tập trung vào nhà phát triển. Bạn có thể tập trung vào việc tạo ra telemetry tốt nhất có thể, thay vì điều chỉnh nó để phù hợp với sản phẩm hiện tại của mình," Thwaites cho biết.

Định nghĩa về Telemetry tốt

Theo Thwaites, telemetry tốt là dữ liệu tập trung vào việc mô tả cách hệ thống "hoạt động" trong môi trường sản xuất (production). Ở đây, "hoạt động" đề cập đến cách mỗi dịch vụ phục vụ một yêu cầu hoặc tương tác cụ thể.

"Nó sẽ cho phép bạn, từ dữ liệu đó, hiểu điều gì làm cho tương tác này khác với tương tác khác, và điều đó đã gây ra điều gì trong hệ thống, dù đó là các cuộc gọi database cụ thể hay các luồng code (codepaths) độc đáo nào đó đã được thực thi."

Nếu việc này được thực hiện nhất quán, quá trình gỡ lỗi các vấn đề trong môi trường production sẽ trở nên cực kỳ đơn giản và nhanh chóng.

Tính nhất quán và công cụ Weaver

Một trong những vấn đề được nhận thấy qua nhiều năm giám sát hệ thống là tính nhất quán trong telemetry là rất quan trọng. Sự thiếu nhất quán trong cách mọi người nói về hiệu suất hệ thống trở nên cấp thiết hơn khi độ phức tạp của các hệ thống đó tăng lên.

Thwaites đã đề cập đến Weaver, một công cụ dùng để tài liệu hóa telemetry được phát ra bởi các hệ thống, vượt ra ngoài các thuộc tính tiêu chuẩn như HTTP hay gRPC.

"Nó cho phép các đội ngũ định nghĩa một từ vựng chung về telemetry theo cách mà các backend observability, công cụ AI và cuối cùng là con người có thể sử dụng để hiểu hệ thống phức tạp đó."

Weaver cũng cung cấp kiểm tra trực tiếp (live checking) và theo dõi ngoại lệ đối với telemetry để đảm bảo rằng bạn chỉ sử dụng các quy ước đã được phê duyệt, cũng như tạo mã (code generation) để việc áp dụng trở nên dễ dàng hơn.

Telemetry là nhiệm vụ của lập trình viên

Việc tạo ra telemetry tốt là yếu tố quan trọng nhất sẽ thúc đẩy khả năng hỗ trợ các hệ thống production của đội ngũ bạn.

"Những đội ngũ tốt nhất mà tôi từng làm việc cùng đã dành nhiều thời gian để quản lý telemetry họ tạo ra tương đương với thời gian viết mã thực hiện kết quả kinh doanh," Thwaites lập luận.

Ông khẳng định đây là một nhiệm vụ phát triển (development task), không phải là nhiệm vụ vận hành (operations task). Một khi các đội ngũ chấp nhận telemetry là một phần cốt lõi của việc phát triển phần mềm tốt, bạn sẽ thấy tác động của nó theo nhiều cách khác nhau: từ thời gian khắc phục sự cố (MTTR), thời gian phát hiện sự cố (MTTD), niềm vui của lập trình viên cho đến tỷ lệ lỗi.

Tầm quan trọng đối với AI và TDD

Trong cuộc phỏng vấn với InfoQ, Thwaites cũng bàn về mối liên hệ giữa observability với các ứng dụng Trí tuệ nhân tạo (AI). Ông cho rằng observability được thiết kế như một phương tiện để đặt ra các câu hỏi cho hệ thống production mà bạn không biết mình cần hỏi khi viết mã, và đây chính xác là những gì chúng ta cần khi một hệ thống sử dụng AI để thực hiện nhiệm vụ. Chúng ta không biết hệ thống sẽ phản ứng như thế nào với một đầu vào cụ thể, và telemetry vững chắc bao gồm bối cảnh kinh doanh độc đáo là rất cần thiết để trả lời những câu hỏi khó khăn này.

Về mối liên hệ giữa telemetry và Phát triển hướng kiểm thử (TDD), Thwaites giải thích rằng telemetry là một đầu ra cốt lõi của ứng dụng. Nếu viết các bài kiểm tra trong quy trình TDD và sử dụng telemetry như một phần của các bài kiểm tra đó để hiểu rằng một hành động đã được thực hiện đúng, thì mã được tạo ra sẽ được thiết kế để có thể quan sát (observable) ngay từ đầu.