📑 Mục lục
Bạn đã bao giờ sửa cùng một lỗi hệ thống đến lần thứ ba trong tuần và tự hỏi: “Tại sao máy không tự nhớ việc này?” Với một hệ thống AI chạy thật 24/7, câu hỏi đó không còn xa xỉ. Nếu mọi cảnh báo đều phải đợi người vào xử lý, hệ thống càng lớn càng mệt.
Tuần này, trục build-in-public của Bumbee xoay quanh một bài học thực tế: không phải lỗi nào cũng cần người vào sửa tay. Có những lỗi nên được hệ thống phát hiện, thử phục hồi theo quy tắc, ghi log lại, rồi chỉ gọi người khi vượt quá ngưỡng an toàn.
Vì sao “tự sửa” quan trọng hơn “tự chạy”
Nhiều đội bắt đầu với mục tiêu làm cho AI agent “tự chạy”. Nhưng trong vận hành thật, tự chạy chỉ là tầng đầu. Câu hỏi khó hơn là: khi API chậm, job bị treo, container khởi động lỗi, hoặc dữ liệu tạm chưa sinh kịp, hệ thống phản ứng thế nào?
Bumbee được xây như một hệ thống làm việc thật, không phải một màn trình diễn. Tại thời điểm viết, hệ thống có 65 container dịch vụ đang chạy, 223 thư mục skill, và máy chủ đã up 12 weeks, 1 day, 20 hours, 51 minutes. Những con số này không dùng để khoe quy mô, mà để đặt bối cảnh: càng nhiều dịch vụ và skill, lỗi nhỏ càng dễ xuất hiện.
Một lỗi nhỏ trong một script đơn lẻ chỉ là phiền phức. Cùng lỗi đó nếu nằm trong workflow định kỳ có thể làm kẹt báo cáo hoặc chậm lịch đăng bài. Vì vậy, bài học tuần này là chuyển từ “đợi người sửa” sang “cho hệ thống một vòng phản xạ cơ bản”.
Những lỗi có thể tự sửa
Không phải lỗi nào cũng nên để AI đụng vào. Vùng phù hợp nhất là nhóm lỗi lặp lại, ít rủi ro, có dấu hiệu rõ và có cách khắc phục đã được thử.
1. Tiến trình bị treo
Một tiến trình có thể vẫn còn tồn tại nhưng không làm việc nữa. Với mắt người, nó “đang chạy”. Với hệ thống, nó không tạo log mới, không phản hồi healthcheck, hoặc không hoàn tất job đúng thời gian.
Cách xử lý tốt không phải là đoán mò. Hệ thống cần phân biệt ba trạng thái: chạy bình thường, chậm nhưng còn tiến triển, và treo thật. Khi đủ tín hiệu, hành động hợp lý là khởi động lại đúng phạm vi nhỏ nhất, ghi thời điểm, rồi theo dõi lần chạy sau. Nếu lỗi lặp lại nhiều lần, hệ thống phải báo người.
2. Thiếu dữ liệu tạm thời
Nhiều workflow AI phụ thuộc vào file nháp, hàng đợi, cache hoặc dữ liệu trạng thái. Khi một file tạm chưa sinh kịp, cách xử lý kém là báo lỗi ngay và dừng toàn bộ chuỗi. Cách tốt hơn là retry có giới hạn.
Thay vì thất bại ở lần đọc đầu tiên, hệ thống có thể đợi ngắn, kiểm tra lại, và chỉ báo lỗi sau vài lần không thành công. Loại tự sửa này không hào nhoáng, nhưng giảm nhiều tiếng ồn vận hành.
3. Lệch format giữa các bước
Trong hệ thống có nhiều skill, bước trước thiếu heading, metadata hoặc sai tên trường có thể làm bước sau vỡ. Với lỗi nhẹ, hệ thống có thể chuẩn hóa lại, thêm trường mặc định an toàn, hoặc từ chối phần không hợp lệ nhưng vẫn giữ phần còn dùng được. Điều kiện bắt buộc là log phải ghi rõ đã sửa gì.
4. Lịch chạy và hàng đợi bị kẹt
Một hệ thống nội dung, agent, worker hay báo cáo định kỳ đều gặp bài toán lịch. Job có thể trùng giờ, chạy quá lâu, hoặc bị kẹt phía sau tác vụ khác. Ở mức đơn giản, hệ thống có thể bỏ qua job đã quá hạn, chạy bù job quan trọng, hoặc đánh dấu job cần người duyệt.
Quy trình tự sửa an toàn
Một hệ thống tự sửa tốt bắt đầu bằng quy tắc vận hành rõ.
Phân loại lỗi trước khi hành động
Trước hết cần tách lỗi thành nhóm: lỗi có thể retry, lỗi có thể restart cục bộ, lỗi cần rollback, lỗi phải dừng ngay, và lỗi cần người quyết định. Nếu mọi lỗi đều đi vào một hộp “AI xử lý”, hệ thống sẽ khó đoán.
Với Bumbee, nhóm phù hợp nhất là lỗi lặp lại, tác động nhỏ, có dấu hiệu rõ, và có hành động khắc phục đã được thử nhiều lần. Lỗi liên quan đến auth, proxy, mạng riêng, cấu hình runtime, hoặc dữ liệu nhạy cảm phải được bảo vệ chặt hơn.
Đặt ngưỡng thay vì phản ứng ngay
Một cảnh báo đơn lẻ chưa chắc là sự cố. Có thể đó chỉ là chậm mạng, tài nguyên tăng tạm thời, hoặc job đang xử lý file lớn. Vì vậy, hệ thống cần ngưỡng: lỗi xảy ra bao nhiêu lần, trong bao lâu, ở dịch vụ nào, và có ảnh hưởng đầu ra không.
Ngưỡng giúp giảm báo động giả. Nó cũng giúp người vận hành tin hệ thống hơn, vì không phải mỗi dòng log đỏ đều kéo theo một hành động.
Sửa nhỏ nhất có thể
Nguyên tắc quan trọng nhất: can thiệp càng nhỏ càng tốt. Nếu một worker bị treo, chỉ xử lý worker đó. Nếu một job lỗi, chỉ retry job đó. Nếu một file format sai, chỉ sửa phần có thể xác định chắc chắn.
Trong vận hành thật, “sửa lớn” thường tạo thêm rủi ro. Một hệ thống tốt chứng minh năng lực bằng việc biết dừng đúng lúc.
Luôn để lại log cho người đọc
Tự sửa mà không có log là mất kiểm soát. Log cần trả lời bốn câu hỏi: lỗi gì xảy ra, hệ thống đã thử gì, kết quả ra sao, và có cần người xem lại không.
Đây là lý do build-in-public có giá trị. Khi ghi lại bài học mỗi tuần, Bumbee có thêm một lớp trí nhớ vận hành: lỗi nào đáng tự động hóa, lỗi nào nên giữ cho người quyết định, và lỗi nào chỉ là tiếng ồn.
Khi nào KHÔNG nên dùng
Không nên dùng tự sửa hệ thống khi chưa có log đáng tin. Nếu bạn không biết lỗi đến từ đâu, việc để hệ thống tự can thiệp có thể làm mất dấu nguyên nhân gốc.
Không nên dùng cho credential, thanh toán, phân quyền, dữ liệu khách hàng, cấu hình proxy, Tailscale, nginx, auth, hoặc hạ tầng runtime quan trọng nếu chưa có phê duyệt rõ. Với các vùng này, chẩn đoán trước can thiệp quan trọng hơn tốc độ.
Không nên dùng khi hành động sửa không thể đảo ngược. Xóa dữ liệu, ghi đè cấu hình, thay đổi quyền truy cập, hoặc redeploy toàn bộ hệ thống không phải là “tự sửa lỗi nhỏ”.
Không nên dùng nếu đội chưa thống nhất ai chịu trách nhiệm khi tự động hóa làm sai. AI có thể đề xuất, script có thể chạy, nhưng trách nhiệm vẫn là của người thiết kế hệ thống.
Bumbee học được gì trong tuần này?
Bài học lớn nhất là: tự sửa không bắt đầu từ AI thông minh hơn, mà từ kỷ luật vận hành tốt hơn. Cần healthcheck rõ, log đủ đọc, ngưỡng an toàn, phạm vi can thiệp nhỏ, và quy tắc dừng.
Với 65 container dịch vụ và 223 thư mục skill tại thời điểm viết, Bumbee không thể dựa mãi vào cách vận hành “thấy lỗi thì SSH vào xem”. Cách đó vẫn cần cho sự cố khó, nhưng không nên là phản xạ mặc định cho mọi lỗi nhỏ.
Một hệ thống trưởng thành là hệ thống biết tự xử lý việc nhàm chán, biết báo người khi vượt quyền, và biết để lại dấu vết đủ rõ để tuần sau cả con người lẫn AI đều học được.
Nếu doanh nghiệp của bạn muốn xây một workflow AI có log, ngưỡng an toàn và cơ chế người duyệt trước khi tự động hóa, hãy bắt đầu với dịch vụ tư vấn và POC AI của BitDanceLabels.