AI xử lý sự cố: Kỹ sư có đang mất kết nối với hệ thống của chính mình?
Bài viết phân tích nghịch lý của tự động hóa trong vận hành hệ thống: khi AI ngày càng xử lý tốt các sự cố thường quy, kỹ sư sẽ có ít cơ hội thực hành và phát triển trực giác vận hành. Tác giả đề xuất giải pháp mô phỏng sự cố như một hình thức huấn luyện bắt buộc, giúp đội ngũ kỹ sư duy trì kỹ năng xử lý tình huống phức tạp và hiếm gặp.
AI xử lý sự cố: Kỹ sư có đang mất kết nối với hệ thống của chính mình?
Trong bối cảnh các công cụ AI ngày càng thông minh, việc chúng đảm nhận vai trò xử lý sự cố vận hành là điều tất yếu. Nhưng liệu sự tiện lợi này có đang âm thầm bào mòn kỹ năng và trực giác của chính những kỹ sư là con người? Bài viết này sẽ phân tích nghịch lý của tự động hóa và đề xuất một giải pháp đầy hứa hẹn: mô phỏng sự cố.
Khi còn là một SRE tại LinkedIn vào năm 2012, tôi đã thiết kế một hệ thống có khả năng tự phục hồi và học hỏi từ các sự cố trước đó. Khả năng của AI thời bấy giờ còn rất hạn chế so với hiện tại, và dự án đó chỉ dừng lại ở mức nguyên mẫu. Nhưng giờ đây, điều đó đã trở thành hiện thực.
Những công cụ AI này có thể làm mọi thứ: kiểm tra cảnh báo, đưa ra giả thuyết, truy vấn dữ liệu giám sát, đối chiếu các bản triển khai gần đây, thậm chí tự động khắc phục sự cố. Dù tôi rất trân trọng sự phát triển này, tôi vẫn có một mối quan tâm lớn: chúng ta đang mất dần kết nối với hệ thống của chính mình.
Những công cụ này càng xử lý tốt các sự cố thường quy, thì các kỹ sư con người càng có ít cơ hội được thực hành. Và khi một sự cố nghiêm trọng, phức tạp xảy ra mà tự động hóa không thể giải quyết, các kỹ sư ứng trực sẽ rơi vào tình thế khó khăn.
Tự động hóa để lại cho con người những sự cố khó khăn nhất
Các công cụ hỗ trợ xử lý sự cố bằng AI này, thường được gọi là "AI SRE" – một thuật ngữ mà tôi không thực sự thích – rất tuyệt vời ở nhiều khía cạnh. Chúng đặc biệt hữu ích khi xử lý một sự cố định kỳ vào ban đêm, giúp bạn không phải thức giấc giữa đêm vì một vấn đề về dung lượng.
Vấn đề nằm ở chỗ, các sự cố thường quy cũng chính là cách mà các kỹ sư ứng trực "an toàn" phát triển trực giác về cách hệ thống của họ hoạt động và gặp trục trặc. Khi AI gặp phải một sự cố khó, chưa từng thấy và không thể tự giải quyết, các kỹ sư sẽ phải tiếp quản với lượng thực hành ít hơn nhiều so với trước đây.
Nhà nghiên cứu về yếu tố con người, Lisanne Bainbridge, đã mô tả nghịch lý này trong bài báo nổi tiếng năm 1983 của bà, "The Ironies of Automation". Bà giải thích rằng tự động hóa làm giảm cơ hội thực hành các công việc thường quy của người vận hành, trong khi vẫn để họ chịu trách nhiệm với những tình huống mới và bất thường. Bà lập luận rằng, do đó, người vận hành cần phải có kỹ năng cao hơn và được đào tạo nhiều hơn trước khi có tự động hóa.
Trong những năm tới, tôi dự đoán rằng MTTR (thời gian khắc phục trung bình) cho hầu hết các sự cố sẽ giảm xuống – nhờ có sự hỗ trợ của AI – nhưng thời gian giải quyết cho các sự cố phức tạp sẽ tăng vọt, bởi các kỹ sư ứng trực đã mất liên lạc với hệ thống của họ và gặp khó khăn trong việc điều tra.
Mô phỏng sự cố giúp kỹ sư duy trì kỹ năng xử lý tình huống phức tạp
Ngành hàng không huấn luyện phi công cho những sự cố hiếm gặp
Chúng ta có thể tìm kiếm nguồn cảm hứng từ ngành hàng không.
Hệ thống tự động trên máy bay xử lý phần lớn việc lái, nhưng phi công vẫn phải chịu trách nhiệm với những tình huống mà tự động hóa không thể quản lý: hỏng động cơ, thiết bị đo đạc không đáng tin cậy, hủy cất cánh, chòng chành (stall) và các điều kiện bất thường khác.
Những sự kiện này cực kỳ hiếm. Ví dụ, động cơ tuabin hiện đại có tỷ lệ dừng giữa chuyến bay chưa đến 1 trên 100.000 giờ bay. Nói cách khác, hiếm đến mức một phi công thương mại có thể trải qua toàn bộ sự nghiệp mà không gặp phải một sự cố nào ngoài buồng tập lái mô phỏng.
Nhưng khi sự cố xảy ra, phi công phải phản ứng nhanh chóng và chính xác. Ví dụ, trong chuyến bay 235 của TransAsia Airways, cánh quạt của động cơ phải tự động chuyển sang chế độ feather ngay sau khi cất cánh. Dù máy bay được thiết kế để có thể tiếp tục bay bằng động cơ trái, phi hành đoàn đã xác định sai vấn đề. Máy bay đã chòng chành và rơi chỉ 117 giây sau cảnh báo đầu tiên.
Các phi công hàng không thường xuyên trở lại buồng tập lái mô phỏng để diễn tập các tình huống khẩn cấp hiếm gặp. Theo quy định của FAA Hoa Kỳ, cơ trưởng phải hoàn thành khóa đào tạo định kỳ hoặc bài kiểm tra trình độ sáu tháng một lần, bao gồm các tình huống như hỏng động cơ khi cất cánh.
Mặc dù hầu hết các sự cố phần mềm không đe dọa đến tính mạng, nhưng đó không phải là lý do để chúng ta không hoàn thiện kỹ năng của mình. Hóa ra, chính công nghệ tạo ra vấn đề cũng có thể giúp chúng ta giải quyết nó.
Ngành phần mềm cần các trình mô phỏng sự cố
Tại Rootly, nơi tôi đang làm việc, chúng tôi đã hợp tác với Uptime Labs để áp dụng ý tưởng này thông qua các mô phỏng sự cố thực tế. Các kỹ sư sẽ ngồi vào vị trí chỉ huy ứng phó trong một sự cố gián đoạn thương mại điện tử được mô phỏng, sử dụng các công cụ quan sát trong khi phối hợp với các bên liên quan do LLM đóng vai trên Slack.
Kết quả thật sự rất sống động. Bạn phải điều tra xem điều gì đang xảy ra, đồng thời giữ cho quá trình ứng phó được tổ chức tốt và đối phó với các câu hỏi của CEO cũng như bộ phận hỗ trợ khách hàng. Bạn có cơ hội thực hành các kỹ năng quan trọng trong một sự cố: xử lý thông tin không đầy đủ, giao tiếp rõ ràng, điều phối mọi người, và thực sự điều hành quá trình ứng phó.
AI cũng có thể giúp duy trì các kỹ năng này
Nhưng nếu sử dụng AI như một huấn luyện viên thì sao? Các kỹ sư ứng trực có thể yêu cầu một tác nhân AI giải thích các bước nó đã thực hiện, các tín hiệu nó đã xem xét và bằng chứng đằng sau chẩn đoán của nó.
Tuy nhiên, giải thích và quan sát không thể thay thế cho thực hành. Bạn có thể học được vài điều khi xem Serena Williams chơi tennis, nhưng bạn chỉ học được tennis khi bước lên sân đấu, và xử lý sự cố cũng vậy.
Tôi đã dành hơn một nửa thập kỷ sự nghiệp của mình để xây dựng một trường dạy kỹ thuật phần mềm dựa trên phương pháp giáo dục tiến bộ: học bằng việc làm. Trường học trực tiếp, nhưng không có giáo viên; học viên làm việc trên các dự án thay vì nghe giảng. Khi Dropbox nhận xét rằng các sinh viên tốt nghiệp mà họ tuyển dụng vẫn còn quá thiếu kinh nghiệm xử lý sự cố, tôi đã tạo ra các dự án đưa cho sinh viên một hệ thống bị hỏng và yêu cầu họ chẩn đoán và sửa chữa nó. Đối với hầu hết các kỹ năng thực hành, tôi tin rằng giáo dục dựa trên thực hành vượt trội hơn rất nhiều so với giảng dạy thụ động.
Thực hành trên hệ thống mô phỏng giúp kỹ sư sẵn sàng trước mọi sự cố
Mô phỏng sự cố nên là một phần của quy trình sẵn sàng ứng trực
Khi các mô hình ngôn ngữ lớn (LLM) xử lý ngày càng nhiều công việc của chúng ta, các đội ngũ kỹ thuật có nguy cơ tích lũy "khoản nợ hiểu biết": một khoảng cách ngày càng lớn giữa cách hệ thống của họ hoạt động và mức độ hiểu biết thực sự của các kỹ sư ứng trực.
Các kỹ sư nên thường xuyên tương tác với hệ thống mà họ đang trông coi, xử lý các sự cố không quen thuộc, thực hành làm việc dưới áp lực, và diễn tập sự phối hợp cùng giao tiếp cần thiết trong một sự cố nghiêm trọng (SEV0). Các bài tập bàn giấy (tabletop exercises) và kỹ thuật hỗn loạn (chaos engineering) không phải là mới, nhưng việc thực hành lại càng trở nên quan trọng hơn trong kỷ nguyên LLM.
Nhà nghiên cứu Bainbridge khuyến nghị nên cho người vận hành thường xuyên điều khiển trực tiếp và sử dụng mô phỏng để ngăn chặn sự mai một kỹ năng. Đó chính là sự mỉa mai của tự động hóa: nó càng thành công, thì con người càng ít được chuẩn bị cho khoảnh khắc nó thất bại.
AI SRE xử lý sự cố tự động ngày càng phổ biến
Sylvain Kalache là Trưởng nhóm AI Labs và DevRel tại Rootly. Ông từng là SRE tại LinkedIn và là đồng sáng lập trường Holberton School.


