Kế hoạch khôi phục sự cố cho AI Agent cần chuẩn bị gì?

Mọi AI Agent chạy trong môi trường thật rồi sẽ gặp sự cố: dịch vụ mô hình ngôn ngữ chậm bất thường, API của phần mềm kho đổi định dạng, một lần cập nhật tài liệu khiến agent trả lời sai chính sách. Câu hỏi không phải có xảy ra hay không, mà là khi xảy ra thì doanh nghiệp mất bao lâu để quay về trạng thái an toàn.

Nhiều đội dự án chỉ chuẩn bị sao lưu cơ sở dữ liệu và coi như đã đủ. Với AI Agent, phần khó khôi phục thường nằm ở chỗ khác: cấu hình prompt, kho kiến thức đúng phiên bản, danh sách công cụ và quyền, cùng những thao tác ghi đang dở dang lúc sự cố xảy ra.

Bài viết trình bày một kế hoạch khôi phục gồm những phần nào, ai làm gì trong những giờ đầu, và cách diễn tập để kế hoạch không chỉ nằm trên giấy.

1. Bản chất của khôi phục sự cố AI Agent

Kế hoạch khôi phục trả lời ba câu hỏi: làm sao chặn thiệt hại ngay, làm sao giữ công việc chạy trong lúc sửa, và làm sao đưa agent về trạng thái đã biết là đúng. Khác với một website, agent có thể gây hại ngay cả khi vẫn đang chạy, chẳng hạn tiếp tục tạo phiếu trùng hoặc hứa với khách một chính sách đã hết hiệu lực. Vì vậy nút dừng quan trọng không kém khả năng khôi phục.

Mỗi mức việc có cách khôi phục riêng. Với hỏi đáp, thường chỉ cần đưa kho kiến thức và prompt về phiên bản trước. Với tra cứu thời gian thực, khi hệ thống nguồn lỗi, agent nên báo không lấy được dữ liệu và ghi nhận yêu cầu, thay vì trả lời bằng dữ liệu cũ. Với thao tác ghi, phải xác định được những bản ghi nào đã tạo trong khoảng sự cố, cái nào trùng, cái nào dở, để đối soát và sửa. Cách các thao tác này đi qua CRM, ERP được mô tả ở bài tích hợp AI Agent với CRM, ERP và API.

2. Các thành phần của kế hoạch khôi phục

1. Phân loại sự cố

Phân loại theo kiểu lỗi giúp chọn đúng cách xử lý: agent không phản hồi, tích hợp lỗi, agent trả lời sai hàng loạt, thao tác ghi sai, hay nghi ngờ lộ dữ liệu. Mỗi loại có người xử lý và bước đầu tiên khác nhau. Ví dụ, khi nghi lộ dữ liệu thì phải báo bộ phận an toàn thông tin trước khi sửa bất cứ thứ gì, để giữ nguyên dấu vết điều tra.

2. Dừng khẩn cấp

Cần một cách tắt agent, hoặc tắt riêng từng công cụ, mà không phải sửa mã hay triển khai lại. Thường đó là công tắc trong cấu hình: tắt quyền ghi nhưng vẫn giữ hỏi đáp, hoặc tắt hẳn agent trên một kênh và hiện thông báo thay thế. Người được bấm công tắc phải được chỉ định từ trước, và mỗi lần bấm đều được ghi nhật ký.

3. Sao lưu cấu hình

Bản sao lưu phải gồm prompt, danh sách công cụ và tham số, phân quyền, cấu hình kênh, phiên bản mô hình và kho kiến thức theo từng lần cập nhật. Tất cả nên được quản lý phiên bản để biết chính xác trước sự cố agent đang chạy bản nào. Nếu kho kiến thức chỉ giữ bản mới nhất, việc quay lại đúng trạng thái hôm qua gần như không làm được.

4. Chuyển quy trình thủ công

Trong lúc agent dừng, công việc vẫn phải chạy. Kế hoạch cần ghi ai nhận yêu cầu thay agent, qua kênh nào, ghi nhận bằng mẫu nào, và khi agent chạy lại thì các yêu cầu làm tay được nhập ngược vào hệ thống ra sao. Nhân viên đã quen để agent làm thường quên quy trình cũ, nên phần này cần viết thành vài bước ngắn và được thử lại định kỳ.

5. RTO

RTO là thời gian tối đa doanh nghiệp chấp nhận để một chức năng quay lại hoạt động. Nên đặt riêng cho từng chức năng: phần tiếp nhận đơn có thể cần quay lại nhanh hơn phần trả lời câu hỏi chung, hoặc ngược lại tùy quy trình. Mục tiêu này nên khớp với cam kết trong SLA cho AI Agent, và chỉ đáng tin khi đã đo được thời gian khôi phục thật trong diễn tập.

6. RPO

RPO là lượng dữ liệu tối đa có thể mất, tính bằng khoảng thời gian kể từ lần sao lưu gần nhất. Với agent, cần xét riêng lịch sử hội thoại, hàng đợi yêu cầu chưa xử lý và các thay đổi trong kho kiến thức. Hàng đợi yêu cầu của khách thường là phần không được phép mất, nên cần lưu bền ngay khi nhận, trước khi agent bắt đầu xử lý.

7. Truyền thông

Chuẩn bị sẵn mẫu thông báo cho từng đối tượng: khách trên kênh chat, nhân viên nội bộ, ban lãnh đạo. Thông báo cho khách nên ngắn gọn, nói dịch vụ đang tạm gián đoạn và đưa kênh liên hệ thay thế, không đoán thời điểm khắc phục. Cần một người duy nhất cập nhật tình hình để tránh mỗi bộ phận nói một kiểu.

8. Diễn tập

Diễn tập là cách duy nhất biết kế hoạch có chạy được không. Có thể bắt đầu bằng diễn tập trên bàn, cả nhóm đi qua kịch bản bằng lời, rồi tiến tới diễn tập thật trong môi trường thử: tắt một API, khôi phục kho kiến thức từ bản sao lưu, bật lại agent. Sau mỗi lần, ghi lại chỗ vướng và sửa kế hoạch ngay.

3. Quy trình xây dựng kế hoạch thực tế

Bước 1: Xác định phạm vi và kết quả cần đo

Liệt kê các chức năng của agent, hệ thống mà mỗi chức năng phụ thuộc và hậu quả khi chức năng đó ngừng. Từ đó đặt RTO, RPO cho từng chức năng. Đầu ra là bảng đánh giá tác động do người sở hữu nghiệp vụ và IT cùng duyệt.

Bước 2: Chuẩn hóa dữ liệu cùng quyền truy cập

Kiểm kê mọi thứ cần sao lưu, nơi lưu, tần suất và người có quyền khôi phục. Tách quyền: người vận hành hằng ngày không nhất thiết được xóa bản sao lưu. Đầu ra là danh mục sao lưu kèm ngày thử khôi phục gần nhất, do đội kỹ thuật ký xác nhận.

Bước 3: Thiết kế tích hợp ngoại lệ và phê duyệt

Thiết kế hành vi của agent khi từng phụ thuộc lỗi: tắt công cụ đó, báo khách, đưa yêu cầu vào hàng đợi. Viết kịch bản đối soát cho các thao tác ghi dở dang và quy định ai duyệt việc bật lại agent sau sự cố. Bật lại cần người nghiệp vụ xác nhận, không chỉ dựa vào việc kỹ thuật thấy hệ thống đã chạy.

Bước 4: Kiểm thử vận hành rồi cải thiện theo log

Chạy diễn tập theo lịch, đo thời gian thật từ lúc phát hiện đến lúc khôi phục và so với RTO. Dùng nhật ký để dựng lại dòng thời gian của sự cố, tìm chỗ chậm: cảnh báo đến muộn, không liên lạc được người trực, hay bản sao lưu thiếu một thành phần. Mỗi lần diễn tập kết thúc bằng danh sách việc cần sửa có người phụ trách.

4. Ví dụ giả định

Khi API chính lỗi, hệ thống chuyển sang ghi nhận yêu cầu và nhân viên xử lý thủ công thay vì tiếp tục tạo kết quả không xác minh.

Ca kiểm thử rút ra từ đây: giả lập API trả lỗi đúng lúc agent đang tạo đơn. Kết quả mong đợi là đơn không bị tạo nửa vời, yêu cầu của khách nằm trong hàng đợi ở trạng thái chờ, khách nhận thông báo yêu cầu đã được ghi nhận và nhân viên trực nhận cảnh báo. Khi API chạy lại, cần thử tiếp bước xử lý hàng đợi để chắc nó không tạo đơn trùng với những đơn nhân viên đã nhập tay trong lúc chờ.

5. Rủi ro và giới hạn

• Không tự động hóa khi dữ liệu hoặc thẩm quyền chưa rõ
• Giới hạn quyền đọc ghi theo nhu cầu tối thiểu
• Giữ người phụ trách cho ngoại lệ và quyết định quan trọng
• Theo dõi log và kiểm thử lại sau mỗi thay đổi

Rủi ro lớn trong lúc khôi phục là chạy lại các thao tác ghi mà không kiểm tra, dẫn tới đơn trùng hoặc thông báo gửi hai lần cho khách. Mọi thao tác ghi cần có mã chống lặp để việc chạy lại an toàn. Rủi ro khác là người khôi phục dùng quyền quá rộng khi đang gấp; nên có tài khoản khẩn cấp giới hạn thời gian và được ghi nhật ký. Bản sao lưu cũng chứa dữ liệu khách hàng nên phải được bảo vệ như dữ liệu gốc.

6. Phân chia trách nhiệm vận hành

Khi sự cố xảy ra, người trực kỹ thuật chịu trách nhiệm phát hiện, dừng agent hoặc công cụ bị lỗi và bắt đầu khôi phục. Trưởng bộ phận nghiệp vụ, như quản lý chăm sóc khách hàng hay kho vận, kích hoạt quy trình thủ công và điều phối nhân viên. Một người phụ trách truyền thông cập nhật tình hình cho khách và nội bộ. Nếu sự cố có thể liên quan dữ liệu cá nhân, bộ phận an toàn thông tin tham gia ngay từ đầu.

Sau sự cố, nên có một buổi rà soát không đổ lỗi: chuyện gì đã xảy ra, vì sao phát hiện sớm hay muộn, kế hoạch chạy tốt ở đâu và vướng ở đâu. Kết quả được ghi thành việc cần sửa có người phụ trách, cập nhật vào kế hoạch khôi phục và đưa vào kịch bản diễn tập lần sau.

7. Chỉ số nên theo dõi

• Tỷ lệ hoàn thành đúng theo tiêu chí đã duyệt
• Tỷ lệ từ chối đúng và chuyển người phụ trách
• Lỗi tích hợp, độ trễ và số thao tác phải sửa
• Chi phí cùng tác động kinh doanh của quy trình

Với khôi phục sự cố, các chỉ số hữu ích nhất là thời gian phát hiện, thời gian chặn được thiệt hại và thời gian khôi phục, đặt cạnh mục tiêu đã đề ra. Nên theo dõi thêm số yêu cầu phải xử lý tay, số bản ghi phải đối soát sau mỗi sự cố và số lần diễn tập đạt mục tiêu. Những con số này cho biết kế hoạch đang mạnh lên thật hay chỉ được cập nhật trên giấy.

8. Checklist trước khi vận hành

• Nguồn dữ liệu và chủ sở hữu đã xác nhận
• Quyền đọc ghi đã thử với nhiều vai trò
• Có phương án khi hệ thống lỗi hoặc thiếu dữ liệu
• Có log, phê duyệt và cơ chế chống thao tác trùng
• Có bộ kiểm thử hồi quy và người vận hành

9. Câu hỏi thường gặp

Có cần kế hoạch khôi phục sự cố ngay khi AI Agent mới chạy thật không? Có, ít nhất ở phần cơ bản: công tắc dừng khẩn cấp, người trực, quy trình thủ công và bản sao lưu cấu hình. Các mục tiêu RTO, RPO và lịch diễn tập có thể hoàn thiện dần khi đã có số liệu vận hành.

Nên bắt đầu lập kế hoạch khôi phục sự cố từ đâu? Bắt đầu từ công tắc dừng và quy trình thủ công cho chức năng quan trọng nhất của agent. Hai thứ này giới hạn được thiệt hại ngay cả khi các phần khác của kế hoạch chưa hoàn chỉnh.

Ai được quyết định bật lại AI Agent sau sự cố? Nên là người sở hữu nghiệp vụ, sau khi đội kỹ thuật xác nhận nguyên nhân đã được xử lý và bộ kiểm thử liên quan đã chạy lại. Nếu sự cố có thao tác ghi sai, cần đối soát xong dữ liệu bị ảnh hưởng trước khi bật lại quyền ghi.

Bao lâu nên diễn tập khôi phục sự cố một lần? Tùy mức quan trọng của agent và tần suất thay đổi hệ thống. Tối thiểu nên diễn tập sau mỗi thay đổi lớn về tích hợp, mô hình hoặc hạ tầng, và theo lịch mà người sở hữu nghiệp vụ và IT đã thống nhất.

Kết luận

Kế hoạch khôi phục sự cố cho AI Agent không chỉ là một bản sao lưu. Nó gồm cách dừng agent ngay lập tức, cách giữ công việc chạy bằng tay, cách quay về cấu hình đúng và cách đối soát những gì agent đã ghi trong lúc lỗi. Kế hoạch chỉ đáng tin khi đã được diễn tập và sửa sau mỗi lần thử.

Trao đổi với Naventic để rà soát phương án dự phòng cho quy trình đang tự động hóa. Đọc thêm: AI Workflow Automation.