Databricks ứng dụng AI để rút ngắn thời gian xử lý sự cố hệ thống

Trong bài viết trước, chúng tôi đã chia sẻ cách Databricks sử dụng AI để gỡ lỗi hàng ngàn cơ sở dữ liệu. Ở bài viết này, chúng tôi tiếp tục câu chuyện đó bằng cách khám phá cách các kỹ sư của chúng tôi sử dụng AI để vận hành hàng trăm microservices trên hơn 1500 cụm Kubernetes, trải rộng khắp hơn 70 khu vực và ba nền tảng đám mây.

Khi có sự cố xảy ra vào lúc 2 giờ sáng, kỹ sư trực ca cần nhanh chóng trả lời một câu hỏi: Điều gì đã thay đổi?

AI SRE là một tác nhân (agent) gỡ lỗi được hỗ trợ bởi AI, bắt đầu điều tra ngay khi sự cố được kích hoạt. Nó liên kết các tín hiệu từ toàn bộ hệ thống của chúng tôi và hướng dẫn các kỹ sư thực hiện phân tích nguyên nhân gốc rễ.

Trong bài viết này, chúng tôi mô tả hành trình gỡ lỗi đã định hình nên AI SRE, kiến trúc đằng sau nó và các nguyên tắc kỹ thuật mà chúng tôi tuân thủ để tạo ra một hệ thống dựa trên LLM đáng tin cậy trong các tình huống sự cố.

Trước khi có AI SRE: Trải nghiệm lúc 2 giờ sáng

Hãy hình dung một thông báo trực ca điển hình. Một sự cố tăng đột biến độ trễ xảy ra với API hướng tới khách hàng. Kỹ sư thức dậy và bắt đầu quy trình quen thuộc:

Mỗi quy trình làm việc này đều hoạt động tốt khi tách biệt, nhưng quy trình gỡ lỗi, tức là hành động kết nối các tín hiệu giữa chúng, lại hoàn toàn nằm trong tâm trí của kỹ sư. Các kỹ sư giàu kinh nghiệm có thể thực hiện việc này trong vài phút vì họ đã từng thấy mô hình đó trước đây. Các kỹ sư mới hơn có thể mất hàng giờ hoặc phải leo thang vấn đề lên cấp cao hơn.

Công cụ không phải là vấn đề chính. Gánh nặng kết nối các tín hiệu nằm ở kỹ sư trực ca, người đang phải làm việc dưới áp lực của SLA.

Bắt đầu với khách hàng, không phải công nghệ

Chúng tôi không bắt đầu bằng việc xây dựng một tác nhân. Chúng tôi bắt đầu bằng việc quan sát cách mọi người gỡ lỗi.

Trong vài tuần, chúng tôi đã phỏng vấn các kỹ sư trực ca từ hàng chục đội ngũ để lập bản đồ hành trình gỡ lỗi của họ từ đầu đến cuối. Chúng tôi đọc các báo cáo sau sự cố (postmortems) và tài liệu điều tra. Chúng tôi đặt một câu hỏi đơn giản: bạn dành thời gian ở đâu và bạn thường bị mắc kẹt ở đâu?

Ba mô hình xuất hiện một cách nhất quán:

Khi chúng tôi nhận ra gỡ lỗi là một chuỗi các bước điều tra có thể lặp lại, theo sau là sự đánh giá của chuyên gia, thì rõ ràng các tác nhân AI có thể đẩy nhanh công việc này. Nhưng không một đội ngũ nào có thể tự xây dựng một tác nhân hiểu được mọi dịch vụ, tín hiệu và chế độ lỗi. Chúng tôi cần một nền tảng chia sẻ có thể xử lý các khối xây dựng chung như thu thập ngữ cảnh, thực thi công cụ và runbook, đồng thời liên kết các bằng chứng, trong khi vẫn cho phép các đội ngũ mở rộng nó bằng kiến thức vận hành riêng của họ. Câu hỏi đã chuyển từ "Chúng ta có thể tự động hóa việc gỡ lỗi không?" sang "Làm thế nào để cung cấp cho mọi đội ngũ một nền tảng hỗ trợ bởi AI để chẩn đoán và giải quyết vấn đề nhanh chóng, có cơ sở hơn?"

Giới thiệu AI SRE

AI SRE hỗ trợ hai trải nghiệm bổ trợ: phân loại tự động (automatic triage), bắt đầu khi sự cố xảy ra, và điều tra tương tác (interactive investigation), cho phép kỹ sư trực ca khám phá các giả thuyết và yêu cầu thêm bằng chứng.

Phân loại tự động khi sự cố xảy ra

Khi sự cố xảy ra, AI SRE khởi động ngay lập tức trước khi kỹ sư kịp mở máy tính xách tay. Nó khởi chạy ba luồng điều tra song song, thu thập các bằng chứng bổ trợ để đưa ra đánh giá ban đầu:

Kiểm tra sức khỏe nền tảng (Platform health checks) đánh giá môi trường mà dịch vụ đang chạy.

Chỉ riêng điều này đã loại bỏ một lượng lớn các thông tin gây nhiễu, giúp kỹ sư không còn phải mất 30 phút gỡ lỗi mã ứng dụng chỉ để phát hiện ra nguyên nhân gốc rễ là một vấn đề hạ tầng quy mô lớn.

Phân tích cấp dịch vụ (Service-level analysis) lấy các log, số liệu (metrics) và dấu vết (traces) liên quan cho dịch vụ bị ảnh hưởng và các phụ thuộc trực tiếp của nó. Nó kiểm tra các bản triển khai và thay đổi cấu hình gần đây. Nó xác định các điểm bất thường so với hành vi cơ sở của dịch vụ, không chỉ là "CPU cao", mà là "CPU tăng gấp 3 lần lúc 2:47 sáng, trùng với một bản triển khai thay đổi kích thước lô (batch size) trong đường ống xử lý".

Thực thi Runbook là nơi AI SRE đảm nhận vai trò đặc thù của từng đội ngũ. Các đội ngũ mã hóa các quy trình gỡ lỗi của họ như các bước kiểm tra mà một chuyên gia trong lĩnh vực sẽ thực hiện, các ngưỡng họ sẽ theo dõi, các bước giảm thiểu họ sẽ thực hiện. Các đội ngũ có thể chuyển đổi các runbook hiện có của họ thành các runbook tác nhân (agentic runbooks) bằng cách sử dụng các kỹ năng (skills). Những kỹ năng này dựa trên cơ sở mã, dữ liệu quan sát và lịch sử sự cố trước đây để làm cho các runbook chính xác và nhận biết ngữ cảnh tốt hơn. Sau đó, nó thực hiện các bước này thay cho kỹ sư trực ca, thực hiện cùng một cuộc điều tra mà một chuyên gia sẽ làm, nhưng trong vài giây thay vì vài phút.

Vào thời điểm kỹ sư đọc chi tiết sự cố lần đầu tiên, AI SRE đã tập hợp một bản tóm tắt chẩn đoán phong phú: điều gì đã hỏng, điều gì đã thay đổi và runbook của đội ngũ bạn yêu cầu kiểm tra những gì, tất cả các tín hiệu, sự tương quan và các bước tiếp theo đều nằm trong một giao diện duy nhất.

Gỡ lỗi tương tác để điều tra sâu hơn

Không phải cuộc điều tra nào cũng kết thúc bằng phân loại tự động. Đôi khi nguyên nhân gốc rễ rất tinh vi, hoặc kỹ sư muốn khám phá một giả thuyết. Giao diện AI SRE cung cấp một môi trường gỡ lỗi tương tác, nơi các kỹ sư có thể đặt câu hỏi tiếp theo bằng ngôn ngữ tự nhiên, yêu cầu thêm tín hiệu và đi sâu vào các khoảng thời gian hoặc thành phần cụ thể.

Đây là nơi sự kết hợp giữa kiểm tra sức khỏe có cấu trúc và AI hội thoại trở nên mạnh mẽ. Một kỹ sư có thể hỏi: "Có điều gì bất thường về độ trễ của Kafka consumer trong 10 phút trước khi cảnh báo này xuất hiện không?" AI SRE sẽ lấy các số liệu liên quan, chồng lớp chúng lên dòng thời gian sự cố và giải thích những gì nó tìm thấy.

Kiến trúc phân lớp để gỡ lỗi

Thông tin cốt lõi mà chúng tôi rút ra từ các cuộc phỏng vấn khách hàng là gỡ lỗi không phải là một vấn đề đơn lẻ, mà là một chồng các vấn đề, và việc giải quyết chúng đòi hỏi các lớp trừu tượng hóa có chủ đích. Chúng tôi thiết kế AI SRE như một nền tảng phân lớp, nơi mỗi lớp có một trách nhiệm rõ ràng và các lớp bên trên có thể tập trung vào các mối quan tâm ở cấp độ cao hơn.

Các nguyên thủy (Primitives) tạo thành nền tảng: dữ liệu vận hành thô mà mọi cuộc điều tra cuối cùng đều phụ thuộc vào. Các nguyên thủy cho số liệu, cảnh báo, log, thông tin phát hành và mã nguồn đã tồn tại, nhưng việc truy cập chúng trong một sự cố đồng nghĩa với việc phải nhảy qua lại giữa năm công cụ khác nhau với năm ngôn ngữ truy vấn khác nhau. Lớp nguyên thủy không thay thế các hệ thống này; nó công nhận chúng là nguồn sự thật duy nhất.

Lớp API sử dụng các nguyên thủy và cung cấp quyền truy cập đồng nhất, có kiểm soát vào dữ liệu cơ bản. Thay vì để mọi công cụ gỡ lỗi truy vấn trực tiếp vào các nguồn dữ liệu như log hoặc kho lưu trữ số liệu, chúng tôi đã xây dựng các API chuyên biệt: API Quan sát (Observability API), API Triển khai (Deployment API) và API Cảnh báo (Alerts API) xử lý xác thực, giới hạn tốc độ và chuẩn hóa dữ liệu. Đây là lớp biến "hạ tầng thô" thành "hạ tầng có thể gỡ lỗi". Điều này cũng có nghĩa là khi chúng tôi thay thế một hệ thống cơ bản, các công cụ gỡ lỗi bên trên sẽ không bị hỏng.

Công cụ cốt lõi (Core Engine) là nơi trí tuệ tồn tại. Một khung bot cung cấp lớp điều phối để xây dựng các quy trình gỡ lỗi, và công cụ này xử lý cơ chế thực thi song song, tương quan kết quả và tổng hợp dựa trên LLM. Đây là nền tảng mà các bot nội bộ của chúng tôi chạy trên đó, nhưng quan trọng hơn, đây cũng là nền tảng dành cho mọi đội ngũ muốn tự xây dựng bot riêng.

Lớp ứng dụng (Application Layer) là nơi việc gỡ lỗi thực sự diễn ra. Đây là nơi bot phân loại sự cố cấp nền tảng của chúng tôi hoạt động. Đây cũng là nơi các công cụ AI của bên thứ ba có thể kết nối vào, cung cấp các khả năng bổ sung mà chúng tôi không cần phải xây dựng lại mọi thứ từ đầu.

Sự phân tách này cho phép chúng tôi cải thiện khả năng truy cập dữ liệu và điều phối một cách độc lập, đồng thời hỗ trợ cả các quy trình được duy trì tập trung và các runbook do từng đội ngũ sở hữu.

Xây dựng sự tin cậy trong một thế giới không xác định

Việc làm cho một tác nhân dựa trên LLM đủ tin cậy để phản ứng với sự cố, nơi niềm tin là tất cả, đòi hỏi kỹ thuật có chủ đích. Một vài nguyên tắc đã dẫn dắt chúng tôi:

Kiểm tra có cấu trúc trước khi suy luận mở. AI SRE chạy các kiểm tra sức khỏe nền tảng có tính xác định và các bước runbook trước tiên. Lớp LLM tổng hợp và giải thích kết quả, nhưng việc thu thập dữ liệu không được để cho sự phán đoán của mô hình quyết định.

Minh bạch hơn là câu trả lời hộp đen. Mọi kết luận mà AI SRE đưa ra đều liên kết ngược lại với bằng chứng cơ bản: số liệu cụ thể, dòng log, sự khác biệt trong bản triển khai (deploy diff). Các kỹ sư có thể xác minh lý do, thay vì chỉ tin tưởng nó. Điều này là không thể thương lượng vì các kỹ sư trực ca sẽ không hành động dựa trên một khuyến nghị mà họ không thể kiểm chứng.

Suy giảm chức năng một cách an toàn (Graceful degradation). Nếu AI SRE không thể xác định nguyên nhân gốc rễ với sự tự tin, nó sẽ nói rõ điều đó và trình bày các bằng chứng mà nó đã thu thập được, sắp xếp theo mức độ liên quan. Một cuộc điều tra một phần nhưng trung thực về giới hạn của nó sẽ hữu ích hơn nhiều so với một chẩn đoán bị ảo giác.