Cảm biến thời gian chạy của Hud cắt giảm thời gian phân loại từ 3 giờ xuống còn 10 phút
Cảm biến thời gian chạy của Hud cắt giảm thời gian phân loại từ 3 giờ xuống còn 10 phút
- 12 min read
Cách cảm biến thời gian chạy của Hud giúp giảm thời gian xử lý sự cố từ 3 giờ xuống còn 10 phút
Các nhóm kỹ sư đang tạo ra nhiều mã hơn với các tác nhân AI hơn bao giờ hết. Nhưng họ đang gặp trở ngại khi mã đó đến giai đoạn sản xuất.
Vấn đề không nhất thiết nằm ở bản thân mã do AI tạo ra. Đó là do các công cụ giám sát truyền thống thường gặp khó khăn trong việc cung cấp dữ liệu chi tiết, ở cấp độ chức năng mà các tác nhân AI cần để hiểu mã thực sự hoạt động như thế nào trong môi trường sản xuất phức tạp. Thiếu ngữ cảnh đó, các tác nhân không thể phát hiện sự cố hoặc tạo các bản sửa lỗi có tính đến thực tế sản xuất.
Đây là một thách thức mà startup Hud đang tìm cách giải quyết với việc ra mắt cảm biến mã thời gian chạy của họ vào thứ Tư. Cảm biến mang tên công ty này chạy song song với mã sản xuất, tự động theo dõi cách mọi chức năng hoạt động, giúp các nhà phát triển biết được những gì đang thực sự xảy ra trong quá trình triển khai.
“Mọi nhóm phần mềm xây dựng ở quy mô lớn đều đối mặt với cùng một thách thức cơ bản: xây dựng các sản phẩm chất lượng cao hoạt động tốt trong thế giới thực,” Roee Adler, CEO và người sáng lập Hud, nói với VentureBeat trong một cuộc phỏng vấn độc quyền. “Trong kỷ nguyên mới của phát triển tăng tốc bằng AI, việc không biết mã hoạt động như thế nào trong sản xuất trở thành một phần lớn hơn của thách thức đó.”
Điều mà các nhà phát triển phần mềm đang gặp khó khăn
Những điểm khó khăn mà các nhà phát triển đang gặp phải là khá nhất quán trong các tổ chức kỹ thuật. Moshik Eilon, trưởng nhóm công nghệ của Monday.com, giám sát 130 kỹ sư và mô tả một sự thất vọng quen thuộc với các công cụ giám sát truyền thống.
“Khi bạn nhận được cảnh báo, bạn thường kiểm tra một điểm cuối có tỷ lệ lỗi cao hoặc độ trễ cao, và bạn muốn đi sâu để xem các phụ thuộc hạ nguồn,” Eilon nói với VentureBeat. “Rất nhiều lần đó là ứng dụng thực tế, và sau đó nó là một hộp đen. Bạn chỉ nhận được 80% độ trễ hạ nguồn trên ứng dụng.”
Bước tiếp theo thường liên quan đến công việc điều tra thủ công trên nhiều công cụ. Kiểm tra nhật ký. Liên kết dấu thời gian. Cố gắng tái tạo lại những gì ứng dụng đang làm. Đối với các sự cố mới sâu trong một cơ sở mã lớn, các nhóm thường thiếu dữ liệu chính xác mà họ cần.
Daniel Marashlian, CTO và đồng sáng lập tại Drata, đã thấy các kỹ sư của mình dành hàng giờ cho cái mà ông gọi là “thuế điều tra”. “Họ đã ánh xạ một cảnh báo chung tới một chủ sở hữu mã cụ thể, sau đó đào sâu nhật ký để tái tạo trạng thái của ứng dụng,” Marashlian nói với VentureBeat. “Chúng tôi muốn loại bỏ điều đó để nhóm của chúng tôi có thể tập trung hoàn toàn vào việc sửa chữa thay vì khám phá.”
Kiến trúc của Drata càng làm tăng thêm thách thức. Công ty tích hợp với nhiều dịch vụ bên ngoài để cung cấp tuân thủ tự động, điều này tạo ra các cuộc điều tra phức tạp khi có sự cố phát sinh. Các kỹ sư theo dõi hành vi trên một cơ sở mã rất lớn trải dài trên các mô-đun rủi ro, tuân thủ, tích hợp và báo cáo.
Marashlian xác định ba vấn đề cụ thể đã thúc đẩy Drata đầu tư vào cảm biến thời gian chạy. Vấn đề đầu tiên là chi phí chuyển đổi ngữ cảnh.
“Dữ liệu của chúng tôi bị phân tán, vì vậy các kỹ sư của chúng tôi phải đóng vai trò là cầu nối con người giữa các công cụ không kết nối,” ông nói.
Vấn đề thứ hai, ông lưu ý, là sự mệt mỏi vì cảnh báo. “Khi bạn có một hệ thống phân tán phức tạp, các kênh cảnh báo chung trở thành một luồng nhiễu nền liên tục, cái mà nhóm của chúng tôi mô tả là hiệu ứng ‘ding, ding, ding’ cuối cùng sẽ bị bỏ qua,” Marashlian nói.
Động lực chính thứ ba là nhu cầu tích hợp với chiến lược AI của công ty.
“Một tác nhân AI có thể viết mã, nhưng nó không thể sửa lỗi sản xuất nếu nó không thể nhìn thấy các biến thời gian chạy hoặc nguyên nhân gốc rễ,” Marashlian nói.
Tại sao các APM truyền thống không thể dễ dàng giải quyết vấn đề
Các doanh nghiệp từ lâu đã dựa vào một lớp công cụ và dịch vụ được gọi là Giám sát Hiệu suất Ứng dụng (APM).
Với tốc độ phát triển AI theo tác nhân và quy trình làm việc phát triển hiện đại, cả Monday.com và Drata đều không thể có được khả năng hiển thị cần thiết từ các công cụ APM hiện có.
“Nếu tôi muốn có thông tin này từ Datadog hoặc CoreLogix, tôi sẽ phải nhập vô số nhật ký hoặc vô số spans, và tôi sẽ phải trả rất nhiều tiền,” Eilon nói.
Eilon lưu ý rằng Monday.com đã sử dụng tỷ lệ lấy mẫu rất thấp do các ràng buộc về chi phí. Điều đó có nghĩa là họ thường bỏ lỡ dữ liệu chính xác cần thiết để gỡ lỗi các sự cố.
Các công cụ giám sát hiệu suất ứng dụng truyền thống cũng yêu cầu dự đoán, đây là một vấn đề bởi vì đôi khi nhà phát triển chỉ đơn giản là không biết những gì họ không biết.
“Khả năng quan sát truyền thống yêu cầu bạn phải dự đoán những gì bạn sẽ cần để gỡ lỗi,” Marashlian nói. “Nhưng khi một sự cố mới xuất hiện, đặc biệt là sâu bên trong một cơ sở mã lớn và phức tạp, bạn thường thiếu dữ liệu chính xác mà bạn cần.”
Drata đã đánh giá một số giải pháp trong danh mục kỹ thuật độ tin cậy trang web AI và phản hồi sự cố tự động và không tìm thấy những gì cần thiết.
“Hầu hết các công cụ chúng tôi đánh giá đều xuất sắc trong việc quản lý quy trình sự cố, định tuyến vé, tóm tắt luồng Slack hoặc tương quan biểu đồ,” ông nói. “Nhưng chúng thường dừng lại ở bản thân mã. Chúng có thể cho chúng tôi biết ‘Dịch vụ A bị lỗi’, nhưng chúng không thể cho chúng tôi biết lý do tại sao.”
Một khả năng phổ biến khác trong một số công cụ bao gồm các trình giám sát lỗi như Sentry là khả năng nắm bắt các ngoại lệ. Thách thức, theo Adler, là việc nhận biết các ngoại lệ là tốt, nhưng điều đó không kết nối chúng với tác động kinh doanh hoặc cung cấp ngữ cảnh thực thi mà các tác nhân AI cần để đề xuất các bản sửa lỗi.
Cảm biến thời gian chạy hoạt động khác nhau như thế nào
Cảm biến thời gian chạy đẩy thông minh đến điểm cuối nơi mã thực thi. Cảm biến của Hud chạy dưới dạng SDK tích hợp với một dòng mã duy nhất. Nó nhìn thấy mọi việc thực thi chức năng nhưng chỉ gửi dữ liệu tổng hợp nhẹ trừ khi có sự cố xảy ra.
Khi xảy ra lỗi hoặc chậm trễ, cảm biến sẽ tự động thu thập dữ liệu pháp y sâu bao gồm các tham số HTTP, truy vấn và phản hồi cơ sở dữ liệu, và ngữ cảnh thực thi đầy đủ. Hệ thống thiết lập các đường cơ sở hiệu suất trong vòng một ngày và có thể cảnh báo về cả sự chậm trễ nghiêm trọng và các giá trị ngoại lệ mà giám sát dựa trên phân vị bỏ qua.
“Bây giờ chúng tôi nhận được tất cả thông tin này cho tất cả các chức năng bất kể cấp độ của chúng, ngay cả đối với các gói cơ bản,” Eilon nói. “Đôi khi bạn có thể gặp sự cố rất sâu, và chúng tôi vẫn nhìn thấy nó khá nhanh.”
Nền tảng cung cấp dữ liệu thông qua bốn kênh:
- Ứng dụng web để giám sát và phân tích tập trung
- Tiện ích mở rộng IDE cho VS Code, JetBrains và Cursor hiển thị số liệu sản xuất trực tiếp nơi mã được viết
- Máy chủ MCP cung cấp dữ liệu có cấu trúc cho các tác nhân mã hóa AI
- Hệ thống cảnh báo xác định sự cố mà không cần cấu hình thủ công
Tích hợp máy chủ MCP rất quan trọng cho việc phát triển có sự hỗ trợ của AI. Các kỹ sư của Monday.com hiện đang truy vấn hành vi sản xuất trực tiếp trong Cursor.
“Tôi có thể hỏi Cursor một câu hỏi: Này, tại sao điểm cuối này lại chậm?” Eilon nói. “Khi nó sử dụng Hud MCP, tôi nhận được tất cả các số liệu chi tiết và chức năng này chậm hơn 30% kể từ lần triển khai này. Sau đó, tôi cũng có thể tìm ra nguyên nhân gốc rễ.”
Điều này thay đổi quy trình phản ứng sự cố. Thay vì bắt đầu trong Datadog và đi sâu qua các lớp, các kỹ sư bắt đầu bằng cách yêu cầu một tác nhân AI chẩn đoán sự cố. Tác nhân có quyền truy cập ngay vào dữ liệu sản xuất ở cấp độ chức năng.
Từ sự cố voodoo đến sửa chữa trong vài phút
Sự chuyển đổi từ khả năng lý thuyết sang tác động thực tế trở nên rõ ràng trong cách các nhóm kỹ thuật thực sự sử dụng cảm biến thời gian chạy. Những gì từng mất hàng giờ hoặc ngày điều tra giờ đây được giải quyết trong vài phút.
“Tôi quen với việc có những sự cố voodoo này khi có một đỉnh CPU và bạn không biết nó đến từ đâu,” Eilon nói. “Vài năm trước, tôi đã gặp một sự cố như vậy và tôi phải tự xây dựng công cụ lấy hồ sơ CPU và bản ghi bộ nhớ. Bây giờ tôi chỉ có tất cả dữ liệu chức năng và tôi đã thấy các kỹ sư giải quyết nó rất nhanh.”
Tại Drata, tác động định lượng là rất ấn tượng. Công ty đã xây dựng một lệnh nội bộ /triage mà các kỹ sư hỗ trợ chạy trong trợ lý AI của họ để ngay lập tức xác định nguyên nhân gốc rễ. Công việc phân loại thủ công đã giảm từ khoảng 3 giờ mỗi ngày xuống dưới 10 phút. Thời gian trung bình để giải quyết đã cải thiện khoảng 70%.
Nhóm cũng tạo một báo cáo hàng ngày “Thông báo” về các lỗi sửa nhanh. Bởi vì nguyên nhân gốc rễ đã được ghi lại, các nhà phát triển có thể sửa các sự cố này trong vài phút. Các kỹ sư hỗ trợ hiện đang thực hiện chẩn đoán pháp y mà trước đây yêu cầu một nhà phát triển cao cấp. Lưu lượng vé tăng lên mà không mở rộng nhóm L2.
Công nghệ này phù hợp ở đâu
Cảm biến thời gian chạy chiếm một không gian riêng biệt với các APM truyền thống, những công cụ này vượt trội trong việc giám sát cấp dịch vụ nhưng gặp khó khăn với dữ liệu chức năng chi tiết, hiệu quả về chi phí. Chúng khác với các trình giám sát lỗi thu thập các ngoại lệ mà không có ngữ cảnh kinh doanh.
Các yêu cầu kỹ thuật để hỗ trợ các tác nhân mã hóa AI khác với khả năng quan sát hướng tới con người. Các tác nhân cần dữ liệu có cấu trúc, ở cấp độ chức năng mà chúng có thể suy luận. Chúng không thể phân tích cú pháp và tương quan nhật ký thô như con người làm. Khả năng quan sát truyền thống cũng giả định rằng bạn có thể dự đoán những gì bạn sẽ cần để gỡ lỗi và ghi lại theo đó. Cách tiếp cận đó bị phá vỡ với mã do AI tạo ra, nơi các kỹ sư có thể không hiểu sâu mọi chức năng.
“Tôi nghĩ rằng chúng ta đang bước vào một kỷ nguyên mới của mã do AI tạo ra và câu đố này, câu đố ghép hình của một ngăn xếp mới đang xuất hiện,” Adler nói. “Tôi chỉ không nghĩ rằng ngăn xếp giám sát điện toán đám mây sẽ phù hợp gọn gàng với cách tương lai sẽ như thế nào.”
Điều này có ý nghĩa gì đối với các doanh nghiệp
Đối với các tổ chức đã sử dụng các trợ lý mã hóa AI như GitHub Copilot hoặc Cursor, thông tin tình báo thời gian chạy cung cấp một lớp bảo mật cho việc triển khai sản xuất. Công nghệ này cho phép cái mà Monday.com gọi là “điều tra tác nhân” thay vì nhảy qua các công cụ thủ công.
Ý nghĩa rộng lớn hơn liên quan đến sự tin cậy. “Với mã do AI tạo ra, chúng ta đang nhận được nhiều mã do AI tạo ra hơn, và các kỹ sư bắt đầu không biết tất cả mã đó,” Eilon nói.
Cảm biến thời gian chạy thu hẹp khoảng cách kiến thức đó bằng cách cung cấp ngữ cảnh sản xuất trực tiếp trong IDE nơi mã được viết.
Đối với các doanh nghiệp đang tìm cách mở rộng quy mô tạo mã AI vượt ra ngoài các dự án thí điểm, thông tin tình báo thời gian chạy giải quyết một vấn đề cơ bản. Các tác nhân AI tạo mã dựa trên các giả định về hành vi hệ thống. Môi trường sản xuất rất phức tạp và đáng ngạc nhiên. Dữ liệu hành vi ở cấp độ chức năng được thu thập tự động từ sản xuất cung cấp cho các tác nhân ngữ cảnh cần thiết để tạo mã đáng tin cậy ở quy mô lớn.
Các tổ chức nên đánh giá xem ngăn xếp giám sát hiện có của họ có thể cung cấp một cách hiệu quả về chi phí mức độ chi tiết mà các tác nhân AI yêu cầu hay không. Nếu việc đạt được khả năng hiển thị ở cấp độ chức năng yêu cầu tăng đáng kể chi phí nhập liệu hoặc ghi lại thủ công, cảm biến thời gian chạy có thể cung cấp một kiến trúc bền vững hơn cho các quy trình làm việc phát triển tăng tốc bằng AI đã và đang nổi lên trong ngành.