Sự kết thúc của Observability đang đến gần (và tôi thấy ổn)

• Mục tiêu cốt lõi của các công cụ Observability trong vài thập kỷ qua là giúp con người hiểu được dữ liệu telemetry dị thể ở quy mô lớn
• Sự xuất hiện của AI và LLM đang làm thay đổi mô hình cũ xoay quanh “dashboard + cảnh báo + sampling”, khi quá trình phân tích được thay thế bằng tự động hóa
• Trên thực tế, một tác nhân AI đã phân tích nguyên nhân của đột biến độ trễ chỉ trong 80 giây với 8 lần gọi công cụ, tự động hóa công việc vốn được thực hiện trong các bản demo trước đây, với chi phí chỉ 60 xu
• Dashboard đẹp mắt hay khả năng instrument thuận tiện không còn là giá trị đặc biệt nữa, khi LLM đang hàng hóa hóa việc phân tích, còn OpenTelemetry hàng hóa hóa việc instrument
• Observability trong tương lai sẽ lấy “vòng phản hồi nhanh” và quy trình cộng tác AI + con người làm chìa khóa thành công, mở ra thời đại của nhiều phần mềm hơn và nhiều tự động hóa hơn

---

Lịch sử của các công cụ Observability và sự xuất hiện của AI

• Trong nhiều thập kỷ, mục tiêu cốt lõi của các công cụ observability là nén/tóm lược lượng dữ liệu dị thể khổng lồ (telemetry) xuống mức con người có thể hiểu được
• Mỗi khi một lớp trừu tượng phần mềm mới xuất hiện (ví dụ: Rails, AWS, Kubernetes, OpenTelemetry...),
  nhiều công cụ như giám sát, đo lường, dashboard, cảnh báo thích ứng, sampling động... lại được phát triển để che giấu sự phức tạp đó, đồng thời nén độ phức tạp của dữ liệu để phù hợp với khả năng nhận thức của con người

LLM = bộ xấp xỉ hàm phổ dụng, và giờ đã thực sự hữu ích

• Về mặt toán học, LLM chỉ là bộ xấp xỉ hàm phổ dụng (universal function approximator), nhưng trên thực tế lại rất hữu ích trong việc giải quyết các vấn đề observability
• Ví dụ, trong một demo của Honeycomb, một tác nhân AI được yêu cầu phân tích bằng ngôn ngữ tự nhiên một đột biến độ trễ trên heatmap
  • “Hãy phân tích nguyên nhân của đột biến độ trễ xảy ra mỗi 4 giờ trong dịch vụ frontend”
  • LLM dùng sẵn (Claude Sonnet 4) được tích hợp với Model Context Protocol (MCP) của Honeycomb
  • Tự động phân tích nguyên nhân chỉ trong 80 giây, 8 lần gọi công cụ, với chi phí 60 xu
• Mức độ này đã cho thấy khả năng giải quyết kịch bản thực tế theo kiểu zero-shot mà không cần prompt bổ sung, huấn luyện riêng hay hướng dẫn
• Sự hàng hóa hóa của phân tích (commoditization):
  • Khi LLM tự động hóa công việc phân tích, những điểm khác biệt trước đây của các sản phẩm observability (đồ thị đẹp, instrument dễ dàng...) dần mất ý nghĩa
  • OpenTelemetry hàng hóa hóa việc instrument, còn LLM hàng hóa hóa việc phân tích
  • Trong tương lai, “vòng phản hồi nhanh” sẽ thay thế như giá trị cốt lõi của công cụ observability

Vai trò của con người và những thay đổi trong tương lai

• Vai trò của con người sẽ không biến mất hoàn toàn
  • Cũng như sự xuất hiện của cloud không xóa bỏ hoàn toàn bản thân ngành IT, AI cũng sẽ không thay thế hoàn toàn developer hay operator
  • Gia tăng năng suất sẽ mở rộng toàn bộ bức tranh và tạo ra nhiều phần mềm hơn nữa
• Câu hỏi cốt lõi là:
  Trong một thế giới nơi chi phí viết code/refactor/phân tích giảm mạnh, và phân tích trở thành hằng số,
  bản chất của observability sẽ đi về đâu?

Điều thực sự quan trọng là “phản hồi nhanh”

• Điều quan trọng nhất là có được các vòng phản hồi nhanh và dày đặc trong mọi giai đoạn của phát triển và vận hành
  • AI sẽ luôn vượt con người về tốc độ
  • LLM có thể nhanh chóng dựng lên hàng chục giả thuyết, thất bại, rồi cuối cùng tìm ra kết quả đúng
    (với chi phí cũng rất rẻ)
• Triết lý của Honeycomb:
  • Vòng phản hồi nhanh, chia sẻ tri thức cộng tác, phát triển/vận hành theo hướng thử nghiệm
  • Trong tương lai, hỗ trợ AI sẽ được đưa vào toàn bộ vòng đời phát triển và vận hành phần mềm
    • Ví dụ
      • Khi viết code và triển khai, tác nhân AI đưa phản hồi thời gian thực, đề xuất sửa lỗi/cải thiện chất lượng
      • Trong quá trình vận hành, phát hiện/phân tích/ghi báo cáo tự động về emergent behavior, sau khi được phê duyệt thì tự động cải thiện
      • Các tổ chức tiên tiến nhất sẽ tự động hóa vai trò SRE/SWE bằng AI + công cụ, thậm chí trực tiếp hoàn thành mục tiêu kinh doanh
• Các điều kiện tương lai của observability để thành công
  • Hiệu năng truy vấn độ trễ siêu thấp
  • Kho lưu trữ dữ liệu tích hợp
  • Quy trình cộng tác liền mạch giữa con người và AI
• Kết luận:
  • Các công cụ observability truyền thống tập trung vào dashboard, cảnh báo và trực quan hóa
    không còn là cốt lõi trong kỷ nguyên AI,
    và chỉ còn “vòng phản hồi nhanh” cùng nền tảng cộng tác AI - con người là có thể tồn tại

[redlasha]

Cũng như observability không phải là dấu chấm hết của monitoring, LLM chắc hẳn cũng không phải là dấu chấm hết của observability.
Giống như observability đã phát triển dựa trên nền tảng monitoring ngày càng tinh vi, phân tích bằng LLM rồi cũng sẽ phát triển dựa trên nền tảng observability ngày càng tinh vi.

[ethanhur]

Tôi cũng đang kỳ vọng lĩnh vực Observability sẽ được đổi mới rất nhanh nhờ LLM, nhưng cái tiêu đề này giật tít quá nhé haha

[crawler]

Quảng bá dịch vụ của mình bằng cách nói rằng “ngày tàn đang đến gần” thì cũng hơi ngượng thật...

Cá nhân tôi thì đang kỳ vọng vision llm sẽ phát triển hơn để có thể dùng cho các tác vụ giám sát. Gần đây tôi từng đọc một bài viết của một phụ huynh dùng vlm để kiểm tra xem có điều gì bất thường xảy ra khi con ngủ không, và tôi thấy điều đó rất thú vị.

[GN⁺]

Ý kiến Hacker News

• Có cảm giác chúng ta đang đánh giá quá thấp giá trị của tính quyết định, đồng thời cũng đánh giá thấp cái giá mà tính không quyết định mang lại. Gần đây tôi đã thử một sản phẩm khác với lời chào hàng tương tự, và nó cố liên kết các biểu đồ sự kiện của tôi để làm RCA. Kết quả cuối cùng trông như trang Spurious Correlations — nhìn trực tiếp thì vừa rõ ràng vừa buồn cười
  • Điều cần được biết là dữ liệu chuỗi thời gian thực sự rất dễ dính tương quan giả. Giá trị r² cũng không có nhiều ý nghĩa. Tệ hơn nữa là khi diễn giải biểu đồ bằng mắt thường; nếu dữ liệu thay đổi theo thời gian thì phải dùng các thước đo phù hợp với đặc tính đó
  • Có thể tôi đang hiểu sai ý chính, nhưng ngay cả với ứng dụng dựa trên LLM, nếu thiết kế tốt thì vẫn có thể tạo ra UX mang tính quyết định ở những thời điểm thực sự quan trọng. Khi cần, LLM có thể tạo ra một đặc tả quyết định để thực hiện điều gì đó, rồi ghi lại tác vụ hay hành động đó. Có thể cấu hình để lưu đặc tả cùng với nội dung hội thoại để người dùng có thể chạy lại bất cứ lúc nào, và khi đặc tả thất bại thì AI đề xuất cách sửa. Luồng này khá giống trải nghiệm dùng AI để lập trình. Chỉ là cần thu hẹp miền của đặc tả hơn nữa và suy nghĩ kỹ hơn về cách phục hồi đặc tả bị lỗi. Có thể hiện thực cách tiếp cận này mà không cần bắt người dùng học một ngôn ngữ đặc tả riêng
• Với tư cách là người làm RCA khá nhiều, tôi lo rằng các đồng nghiệp vốn đã dễ ngại ngùng sẽ càng làm mọi thứ tệ hơn khi quá tin vào công cụ đưa ra kết quả sai 10% nhưng với sự tự tin rất cao. Tôi cũng lo rằng khi thực sự không biết điều gì đó, họ sẽ phụ thuộc vào công cụ vì không còn phải công khai nói rằng mình không biết. Sẽ đỡ tệ hơn nếu sau khi công cụ đưa ra kết luận, nó còn tìm dữ liệu phản bác cách diễn giải đó và nói rõ hơn đâu là bằng chứng đáng tin hơn hoặc đâu là phần bất định
  • Phần này có thể được cải thiện đáng kể nếu viết system prompt tốt. Thực tế tôi đã từng tạo custom prompt/hướng dẫn để kéo ra các câu trả lời mặc định chặt chẽ và có tính nghiên cứu hơn từ LLM, và trải nghiệm khá tốt. Prompt tôi dùng trong ChatGPT là: "Ưu tiên thực chất, rõ ràng và chiều sâu. Xem mọi đề xuất, thiết kế và kết luận như giả thuyết để chất vấn sắc bén. Phơi bày sớm các giả định ẩn, đánh đổi và trường hợp thất bại. Bỏ qua lời khen không cần thiết nếu không có cơ sở. Nếu không chắc, hãy nói rõ. Luôn đưa ra góc nhìn thay thế. Chỉ khẳng định mạnh các phát biểu về sự thật khi có trích dẫn hoặc căn cứ vững chắc. Nếu dựa vào suy luận hay thông tin chưa đầy đủ thì phải nói rõ. Ưu tiên độ chính xác hơn sự tự tin." Cấu hình như vậy thực sự cải thiện rất nhiều chất lượng và độ sâu của câu trả lời
• Lịch sử kiểu “New Relic trong cuộc cách mạng Rails, Datadog trong đà trỗi dậy của AWS, Honeycomb dẫn dắt OpenTelemetry” là một cách diễn giải thiên lệch. OpenTelemetry (OTel) hình thành khi OpenCensus do Google khởi xướng và OpenTracing do LightStep khởi xướng chính thức hợp nhất. Nhiều tổ chức như Google, LightStep, Microsoft, Uber cùng tham gia quản trị giai đoạn đầu. Đúng là Honeycomb đã đóng vai trò lớn trong mã nguồn, cộng đồng và thúc đẩy áp dụng kỹ thuật, nhưng nói là “dẫn dắt” thì hơi quá
  • Tôi đang đọc bài này với tư cách người mới triển khai Honeycomb gần đây, và đây thực sự là một công cụ đáng kinh ngạc. Đặc biệt nhờ auto-instrumentation của otel mà chỉ trong vài giờ đã có thể thu được insight. Tính năng dashboard/query cũng cho thấy rõ nó được xây dựng từ một triết lý Observability rất sâu. Cả đội chúng tôi đều bị sốc vì độ hoàn thiện của công cụ. Datadog thì tạo cảm giác tập trung nhiều hơn vào marketing và checklist “observability”
• Nếu gạt phần “lời chào hàng” sang một bên, đây là một trong những ứng dụng mà LLM thực sự có giá trị. Từ trước đến nay monitoring và observability chủ yếu là lãnh địa của SRE ở các doanh nghiệp lớn, còn với tổ chức nhỏ thì rào cản rất cao, ít nhất là từ góc nhìn IT. Việc chọn metric có ý nghĩa, thiết lập heartbeat và baseline vốn đã đòi hỏi thời gian, công cụ chuyên biệt, môi trường phát triển đồ sộ, thậm chí cả hệ thống xác minh thay đổi, nên các đội IT thông thường khó mà làm nổi. Giờ đây nhờ các LLM được huấn luyện trên những công cụ phổ biến nhất, ngay cả các đội IT thiếu ngân sách hoặc năng lực cũng có thể triển khai hệ thống observability “thật sự” dựa trên framework/công cụ mở. Không còn nhất thiết phải phụ thuộc vào các giải pháp đăng ký hào nhoáng. Khi cần dựng dashboard hay thiết lập monitoring thực dụng, LLM thực sự như một ân huệ. Với dân IT biết đọc tài liệu và troubleshooting nhưng không có thời gian đào sâu từng bộ sản phẩm mà CIO thúc đẩy, tính hữu dụng là cực lớn. Nếu cảnh báo PagerDuty còn kèm gợi ý nguyên nhân tối thiểu, thì với SMB/SME đây đúng là một cuộc cách mạng observability
  • Tìm ra metric có ý nghĩa không phải là điểm mạnh của LLM, nhưng heartbeat, baseline và phần còn lại thì từ rất lâu trước đây đã là lĩnh vực mà ConvNet đủ sức tự động hóa. Những băn khoăn về xác minh thay đổi hay kiểm soát độ ổn định khi triển khai lại là vấn đề nằm ngoài phạm vi của công cụ observability
  • Tôi kỳ vọng tác động cực lớn ngay cả với các đội SRE nhỏ. Đội tôi có 2 người quản lý hàng trăm máy chủ bare metal, và khi có sự cố thì quá trình khoanh vùng nguyên nhân cực kỳ căng thẳng. Đến mức tôi từng nghĩ đến chuyện tự làm một công cụ kiểu MCP (Master Control Program). Không ít lần lỗi bùng phát ra sau khi đã âm ỉ rất lâu, và trong những trường hợp như vậy LLM có thể giúp đáng kể
• Tiêu đề có vẻ quá giật gân. Không phải các công cụ observability hiện tại sẽ trở nên vô dụng. Chỉ là thời gian tạo biểu đồ rồi ngồi nhìn chúng có thể sẽ giảm đi. Điều này cũng giống tác động của LLM lên mọi lĩnh vực khác. Đúng là nó giúp bạn làm nhanh hơn những việc vốn đã biết làm, hoặc giúp bạn học cách làm việc đó, nhưng không có nghĩa là nó thay thế hoàn toàn chính kỹ năng ấy
  • “Tăng tốc những việc đã biết làm”, “giúp học cái mới” — hôm nay đây đã là lần thứ hai tôi nghe kết luận đó. Suy luận bằng 2, và nâng hiệu suất của 1 lên mức cực cao, đó là hướng đi năng suất nhất trong tương lai
  • Tiêu đề thì giật gân, nhưng thông điệp thì rõ — hào lũy gia nhập đang ngày càng thấp đi
  • Hiện tượng này được gọi là “hiệu ứng Charity Majors”
• Trong demo họ nói rằng “đây không phải ví dụ dàn dựng. Chúng tôi ném đúng câu hỏi mà trong demo vẫn hỏi người dùng cho LLM agent, và nó tìm ra đáp án ngay mà không cần prompt bổ sung, huấn luyện hay hướng dẫn nào”, nhưng trên thực tế chính kịch bản này đã nằm sẵn trong demo, và đây cũng là trường hợp mà lời giải đã tồn tại. Đúng ra họ nên dùng một ví dụ nhân tạo hơn để chứng minh mô hình có thể khái quát hóa sang tình huống mới không có nguyên xi trong dữ liệu huấn luyện. Khả năng thực tế của LLM đúng là hữu ích, nhưng để đưa ra tuyên bố cực đoan như “sự kết thúc của observability” thì công cụ cần cho thấy năng lực tổng quát hóa
• Tôi không nghĩ đây là “sự kết thúc của observability”. Nhưng các luận điểm trong bài cũng không hoàn toàn vô nghĩa. Rõ ràng có khả năng sẽ xuất hiện một lớp agent AI mới có thể đảm nhận nhiều vai trò khác nhau trong SRE, bao gồm cả RCA. Tuy nhiên, kể cả khi điều đó thành hiện thực thì phần lớn, nếu không muốn nói là toàn bộ, stack observability hiện tại vẫn sẽ cần thiết. Hơn nữa, chừng nào vấn đề ảo giác/độ tin cậy/độ ổn định của LLM chưa được giải quyết tận gốc thì việc phân tích vấn đề chuyên sâu vẫn sẽ cần con người
• Chiến lược kinh doanh kiểu “chỉ cần AI và chút nỗ lực là có thể làm mọi việc mà chuyên gia từng làm” đúng là một chiến lược cực kỳ hấp dẫn. Buồn thay, nếu copy-paste câu này vào 80% startup AI hiện nay thì cũng chẳng có gì lạ
  • Tôi biết đây có vẻ là mỉa mai, nhưng những “chuyên gia làm được việc” đó là nguồn lực <i>cực kỳ</i> đắt đỏ. Nếu việc tự động hóa này thực sự xảy ra thì cũng dễ hiểu vì sao lại có quá nhiều startup AI nửa mùa xuất hiện
• Bài này cho cảm giác như AI đã viết hết. “AI sẽ chấm dứt mô thức này, điều đó đã xảy ra rồi, thậm chí sẽ thay đổi tận gốc cách thiết kế và vận hành hệ thống” — tôi không hiểu việc diễn giải một phần dữ liệu thì liên quan gì đến “sự kết thúc của observability”
• Lập luận kiểu “giờ không cần xem dữ liệu qua biểu đồ và UI nữa” có giới hạn rất thực tế. Khi LLM hoạt động tốt thì đúng là rất tuyệt, nhưng khi nó thất bại thì con người vẫn phải can thiệp và trực tiếp xem biểu đồ cùng các dạng trực quan hóa khác. Biểu đồ hay trực quan hóa vốn đã khó, nhưng việc thu thập dữ liệu thực tế hoặc thiết kế truy vấn phức tạp và cách lưu trữ dữ liệu còn khó hơn nhiều. Chỉ đến khi có trí tuệ nhân tạo thật sự có thể đánh giá gần như hoàn hảo mọi thứ thì observability mới thực sự “biến mất”. Và khi đó, cấu trúc của toàn xã hội chắc cũng sẽ thay đổi hoàn toàn, như một biến chuyển văn hóa lớn lao, dù không phải diệt vong thì cũng là một quá trình chuyển đổi đau đớn. AI sẽ làm thay đổi cuộc chơi của observability là điều có thật. Nó đang diễn ra ngay lúc này, nhưng con đường phía trước vẫn còn dài