12.1 Từ cuộc hội thoại đến nhiệm vụ thường trực
Hầu hết các triển khai hiện nay đều mang tính hội thoại. Một kỹ sư mở phiên, đặt câu hỏi, phê duyệt và đóng tab. Cách này vẫn dùng được, nhưng bị giới hạn ở sự chú ý của con người: agent chỉ làm việc khi có người theo dõi. Đơn vị phá bỏ giới hạn đó là nhiệm vụ: một mục tiêu thường trực với trigger riêng, một tập hành động được phép có giới hạn, và một bước xác minh được tích hợp sẵn trong vòng lặp. “Giúp tôi với Kubernetes” không phải là nhiệm vụ. Những điều sau mới là nhiệm vụ:- Review mọi pull request về tác động đến hạ tầng.
- Giữ lỗ hổng của image dưới một ngưỡng đã đặt.
- Giữ dịch vụ này đạt SLO.
Chat không biến mất. Chat trở thành nơi xử lý ngoại lệ: nơi bạn chất vấn công việc của nhiệm vụ, không phải nơi công việc diễn ra.
12.2 Nhiệm vụ theo chiều dọc: tự chủ nhờ phạm vi hẹp
Chương 7 cho thấy với bài toán giải quyết sự cố mở, agent trên các model hiện tại giải quyết khoảng một trong bảy kịch bản benchmark SRE. Điều đó không có nghĩa phải nhiều năm nữa mới có tự chủ. Điều đó có nghĩa là quyền tự chủ được giành theo từng nhiệm vụ, và nhiệm vụ càng hẹp càng giành được sớm. Thu hẹp mục tiêu, giới hạn hành động và làm cho khâu xác minh rẻ, thì chính những model đó trở nên đủ chuẩn production vì harness có thể kiểm tra công việc của chúng.
Cột cuối cùng là cột quan trọng. Mỗi nhiệm vụ khép lại bằng một bước kiểm tra mà máy tự chạy: quét lại, plan-diff, cổng CI, probe SLO, một dòng trên hóa đơn. Điều đó cho bạn quy tắc nâng cấp trong một câu:
Nhiệm vụ giành được quyền tự chủ khi xác minh rẻ hơn giám sát.
12.3 Kỹ sư đứng trên vòng lặp, không nằm trong vòng lặp
“Human in the loop” che giấu một mức trần. Nếu một người phải nhấn đồng ý cho mọi hành động, thì bạn chỉ tạo ra một kỹ sư chậm hơn. Phê duyệt từng hành động là một giai đoạn, không phải đích đến. Đích đến là “on the loop”: kỹ sư đặt các cơ chế kiểm soát và xử lý những gì cơ chế kiểm soát không thể quyết định.
Việc nâng cấp diễn ra theo từng nhiệm vụ và dựa trên bằng chứng, giống như cách bạn đưa mã lên production. Nhiệm vụ bắt đầu ở chế độ chỉ đọc. Tiếp theo, nhiệm vụ đề xuất thay đổi để con người phê duyệt. Sau đó, các hành động cụ thể, đảo ngược được chạy không cần giám sát trong phạm vi chính sách. Mỗi bước cần điểm đánh giá đạt và lịch sử sự cố sạch (các cổng trong Chương 7), và một nhiệm vụ có thể bị hạ cấp theo cùng cách.
Việc giám sát không còn là một cuộc họp mà trở thành một control plane gồm chính sách, ngân sách, hàng đợi và màn hình kiểm toán. Giám sát mười nhiệm vụ theo cách này là một công việc bán thời gian. Làm mười nhiệm vụ đó bằng tay là mười công việc.
12.4 Năm điều kiện, nói thẳng
Tương lai này có điều kiện. Mỗi điều kiện là một chương của cuốn sách này. Dùng bảng này làm bước kiểm tra mức độ sẵn sàng trước khi để bất kỳ nhiệm vụ nào chạy không giám sát.
Các nhóm đáp ứng đủ cả năm vận hành bằng ý định cộng ngoại lệ. Các nhóm không đáp ứng điều nào sẽ nhận ra “tự động” chỉ là một cái nhãn.
12.5 Xây dựng tương lai
Sự chuyển đổi đến từng nhiệm vụ một, theo thứ tự đại khái như sau:- Code review chạy không giám sát trước tiên, dưới dạng bình luận tư vấn, vì việc xác minh gần như miễn phí.
- Nhiệm vụ chi phí theo sau, vì mọi hành động đều đảo ngược được.
- Bảo mật và ứng phó sự cố được nâng cấp từng lớp lỗi một. Hỗ trợ mỗi lần nâng cấp bằng một golden set (Chương 7) và ba tháng kiểm tra mẫu sạch.
Trong thực tế: nhiệm vụ trên CloudThinkerCloudThinker chạy các nhiệm vụ này trên một tập kết nối dùng chung, một hệ thống Approvals và một nhật ký kiểm toán.
Thang nâng cấp trong cài đặt
Mọi thao tác ghi đều qua Rule của bạn trước, rồi đến Approval mode, dù Rule chỉ quyết định khi CloudThinker bật Rule enforcement cho workspace của bạn. Automation mặc định là Auto · Rules + AI · Refuse: Rule quyết định trước, sau đó AI judgment cho phép thao tác ghi an toàn mà không Rule nào bao phủ, và bất cứ thứ gì vẫn chưa được quyết định sẽ bị từ chối, vì có thể không ai trực tuyến để trả lời. Xem bốn lựa chọn Auto.Các cơ chế kiểm soát on-the-loop
Audit Logs và giới hạn credit cần gói Scale, Scale Plus hoặc Enterprise.