Phát hiện chính
Dynatrace mua Arize với giá 915 triệu USD để nối hoạt động của tác tử AI với dữ liệu ứng dụng, mã nguồn và hạ tầng. Thương vụ giúp kỹ sư điều tra sự cố trong một hệ thống thay vì tách riêng lớp AI, nhưng tỷ lệ chấp nhận mã do Signal tạo cho thấy con người vẫn phải kiểm tra các thay đổi.
Dynatrace hoàn tất thương vụ vào ngày 1 tháng 10, theo The New Stack. Sean O’Dell, giám đốc tiếp thị sản phẩm cấp cao của Dynatrace, giải thích lý do cần hợp nhất dữ liệu: “Chúng ta có thể đặt câu hỏi, có thể dùng ngôn ngữ tự nhiên, có thể có những hệ thống RAG tuyệt vời, có thể thực hiện đánh giá, nhưng cuối cùng thì đó vẫn là một ứng dụng”.
Signal, tác tử hỗ trợ viết mã của Arize, tạo các yêu cầu hợp nhất mã cho trợ lý AI Alyx. Aparna Dhinakaran, đồng sáng lập Arize, cho biết công ty chấp nhận khoảng 65% đến 70% số yêu cầu này. Gần một phần ba số đề xuất vì thế vẫn cần con người phát hiện vấn đề trước khi triển khai.
Nội dung thương vụ: Vì sao Dynatrace mua Arize?
Dynatrace mua Arize để đưa dữ liệu đánh giá mô hình và tác tử AI vào cùng hệ thống với dữ liệu giám sát ứng dụng, hạ tầng và hệ thống cũ. Cách tiếp cận này nhằm giúp đội vận hành xác định cả tác động của sự cố lẫn nguyên nhân kỹ thuật mà không phải chuyển qua nhiều công cụ.
Luận điểm đứng sau thương vụ khá trực tiếp: một ứng dụng AI vẫn là một ứng dụng. Khi ứng dụng gặp sự cố, doanh nghiệp cần biết thiệt hại là gì, còn kỹ sư trực phải tìm được nguyên nhân. Việc theo dõi riêng phần AI và phần mềm bên dưới bằng hai công cụ khiến quá trình điều tra bị chia cắt.
O’Dell trao đổi với The New Stack ngày 25 tháng 9 tại hội nghị WeAreDevelopers ở San Jose, năm ngày trước khi thương vụ hoàn tất. Do Dynatrace đang trong giai đoạn hạn chế công bố thông tin, ông chỉ nói về Arize ở mức khái quát.
Theo O’Dell, đội vận hành phải biết câu trả lời của AI có phù hợp hay không, mô hình có tạo thông tin sai hay không và mỗi hoạt động tốn bao nhiêu. Dynatrace và Arize đã xử lý những câu hỏi này ở các lớp khác nhau. Ứng dụng AI còn nằm trong một hệ sinh thái rộng hơn, nhiều trường hợp bao gồm ứng dụng cũ và máy tính lớn.
Thương vụ thay đổi quy trình gỡ lỗi thế nào?
Việc kết hợp hai nền tảng có thể nối quá trình gỡ lỗi AI với quá trình điều tra mã nguồn, dịch vụ ứng dụng và hạ tầng triển khai. Kỹ sư sẽ không phải dừng việc phân tích trong Arize rồi chuyển sang một tập dấu vết riêng khi nguyên nhân thực sự nằm dưới lớp mô hình.
Trước thương vụ, nhóm kỹ thuật có thể gỡ lỗi phần AI trong Arize. Nếu nguyên nhân nằm ở phần mềm, họ phải chuyển sang các dấu vết riêng để tiếp tục tìm lỗi. Cách làm này đặc biệt bất tiện khi một tác tử AI viết mã phụ thuộc đồng thời vào mô hình, mã nguồn, dịch vụ ứng dụng và hạ tầng triển khai.
Việc mua Arize cũng đưa một nhà cung cấp giám sát AI độc lập từng nhận đầu tư từ Datadog về với Dynatrace. Arize mang theo Phoenix, công cụ có mã nguồn được cung cấp để theo dõi và kiểm thử ứng dụng AI, cùng cộng đồng nhà phát triển sử dụng nó. O’Dell mô tả cộng đồng này là “khó tìm vì lĩnh vực còn quá sớm và quá mới”.
Bluebox và Signal tự động sửa lỗi đến đâu?
Bluebox của Dynatrace và Signal của Arize đều dùng dữ liệu giám sát để đề xuất thay đổi mã. Các công cụ có thể phân tích môi trường vận hành và tạo yêu cầu hợp nhất mã, nhưng không tự chứng minh rằng mọi bản sửa đều chính xác hoặc an toàn để đưa vào hệ thống sản xuất.
Theo O’Dell, Dynatrace giới thiệu Bluebox vào tháng 6. Công cụ đọc mã của một nhóm trên GitHub, GitLab hoặc Bitbucket, đối chiếu mã với dữ liệu trong môi trường vận hành rồi đề xuất bản sửa. Ông tóm tắt đầu ra của quy trình này bằng câu: “Đây là yêu cầu hợp nhất mã của bạn”.
Signal thực hiện vai trò tương tự cho Alyx, trợ lý AI do Arize phát triển. Dhinakaran cho biết Arize chấp nhận khoảng 65% đến 70% số yêu cầu hợp nhất mã do Signal viết. Tỷ lệ này cho thấy xác minh yêu cầu hợp nhất mã chưa thể bị loại khỏi quy trình.
Vì sao con người vẫn phải kiểm tra thay đổi do AI tạo?
Con người vẫn phải kiểm tra vì tác tử AI có thể đề xuất bản sửa mà đội vận hành không nên đưa thẳng vào hệ thống thật. Dữ liệu giám sát giúp tác tử phân tích và tạo mã, nhưng trách nhiệm đánh giá rủi ro, phê duyệt thay đổi và kiểm soát môi trường sản xuất vẫn thuộc về con người.
O’Dell cho rằng nhóm kỹ thuật có thể lùi lại và để Bluebox tự đề xuất cách sửa, nhưng ông vẫn khuyên khách hàng kiểm tra bản sửa trước khi phê duyệt. Quan điểm này phù hợp với cách các đội vận hành quản lý thay đổi trong môi trường sản xuất.
Kiểm soát trước khi triển khai
Ông nhắc lại rằng trong thời kỳ ITIL, một thay đổi tự động có thể đi kèm “1.500 bước kiểm tra và cân bằng”. Các hệ thống hiện nay có khả năng tự phân tích và tạo bản sửa, nhưng yêu cầu kiểm soát không biến mất chỉ vì đầu ra đến từ tác tử AI. Đây cũng là trọng tâm của câu hỏi AI nên được trao bao nhiêu quyền trong vận hành.
“Tôi không tin mọi thứ do chatbot hoặc tác tử của mình tạo ra”, O’Dell nói với The New Stack. “Vậy tại sao bạn lại tin?”
Thương vụ cho thấy Dynatrace đang đặt cược rằng giám sát AI không nên tồn tại như một lớp tách biệt. Dữ liệu về câu trả lời, chi phí và hành vi của tác tử cần được nối với mã nguồn, ứng dụng, hạ tầng và tác động kinh doanh. Tỷ lệ chấp nhận đề xuất của Signal đồng thời cho thấy con người vẫn phải kiểm tra trước khi một thay đổi được đưa vào hệ thống thật.
Hãy theo dõi Sine để cập nhật cách các nền tảng giám sát đang thích nghi với tác tử AI trong môi trường vận hành thực tế.
