10.1 Một vòng lặp, năm núm điều chỉnh
Năm tham số quyết định cách một agent hành xử trong một lĩnh vực. Chúng là một phần của harness, thứ mà Chương 7 đã cho thấy đóng góp cho kết quả production nhiều hơn mô hình trần. Hàng cuối là kết quả cộng dồn của năm tham số đó.
Dùng bảng này làm checklist review thiết kế. Nếu bạn không điền được một ô cho môi trường của mình, agent cũng không làm được.
10.2 Độ phức tạp: trụ cột mà pager phải trả lời
Ứng phó sự cố là trường hợp khó nhất trong cuốn sách này. Câu hỏi là mở (“vì sao checkout chậm?”), hệ thống đang lỗi trong khi bạn điều tra, và chứng minh một bản sửa nghĩa là probe một service đang chạy, không phải đọc hóa đơn. Đó là lý do kết quả benchmark trong Chương 7 yếu nhất ở đây, và vì sao trụ cột này giành quyền tự chủ chậm. Bốn quy tắc rút ra từ đó.- Chẩn đoán chính là sản phẩm. Theo dõi tần suất kỹ sư on-call chấp nhận nguyên nhân gốc của agent. Con số đó mở khóa mọi thứ khác.
- Sửa nguyên nhân, không sửa triệu chứng. Chương 7 cho thấy agent vượt qua bài kiểm thử khắc phục bằng vòng lặp restart. Trên production, hãy escalate mọi bản sửa không dẫn chiếu một nguyên nhân đã chẩn đoán, hoặc lặp lại ngay trong cửa sổ cooldown của bản sửa đó.
- Hành động qua runbook. Runbook có kiểm tra trước, các bước có kiểu và kiểm tra sau biến một hành động mở thành hành động có giới hạn và audit được.
- Đo theo baseline của chính bạn. Theo dõi thay đổi MTTR, tỷ lệ chấp nhận chẩn đoán, tỷ lệ escalate và tỷ lệ sự cố lặp lại. Con số cuối cho bạn biết incident memory (Chương 2) có đang học hay không.
10.3 Chi phí: nơi quyền tự chủ được giành nhanh nhất
Lĩnh vực chi phí thì ngược lại hoàn toàn. Xác minh gần như miễn phí, vì hóa đơn hoặc đã thay đổi hoặc chưa. Phần lớn hành động hoàn tác được gọn gàng: bạn có thể resize instance trở lại, khôi phục volume từ snapshot, hoặc bật lại lịch chạy. Bằng chứng rẻ cộng hành động đảo ngược được chính là bài kiểm tra nâng cấp mà Chương 12 chính thức hóa, nên chi phí thường là lĩnh vực đầu tiên nơi agent tự hành động và báo cho bạn sau. Ba cái bẫy vẫn cần được xử lý về mặt kỹ thuật.10.4 Bảo mật: rủi ro cao nhất, ranh giới rõ nhất
Bảo mật có khoảng cách lớn nhất giữa đọc và ghi. Phía đọc là khối lượng công việc lớn, lặp lại, với chi phí xác minh rẻ: triage phát hiện, kiểm tra một lỗ hổng có thực sự khai thác được trong môi trường của bạn không, và thu thập bằng chứng. Hãy tự động hóa phía đọc trước. Phía ghi (vá lỗi, cách ly workload, thu hồi thông tin xác thực, thay đổi IAM) có phạm vi ảnh hưởng tệ nhất trong cuốn sách này. Cách ly quá rộng là sự cố ngừng dịch vụ tự gây ra, và một thay đổi IAM sai có thể khóa luôn những người ứng phó của bạn. Chạy cơ chế phê duyệt của Chương 6 ở mức nghiêm ngặt nhất tại đây. Mặc định để các hành động thực thi phải hỏi người phê duyệt (Manual, hoặc Rule Ask first), rồi nới lỏng dần, mỗi lần một nhóm hành động hẹp. Hai thói quen quan trọng nhất trong lĩnh vực này.- Sửa trong code, không sửa trong console. Nếu IaC quản lý tài nguyên, bản sửa trên console sẽ bị lần apply tiếp theo hoàn tác và phát hiện quay lại. Đề xuất thay đổi vào nguồn IaC và để CI làm cổng xác minh.
- Giữ bằng chứng luôn cập nhật, không phải dựng lại. Snapshot cấu hình, review quyền truy cập và bản ghi thay đổi đều chỉ đọc và dễ xác minh. Thu thập chúng liên tục giúp tránh cảnh vội vã trước audit, và đây thường là bản triển khai dễ được phê duyệt nhất.
10.5 Một harness, ba gói
Với mỗi lĩnh vực, bạn thay đổi bốn thứ: gói công cụ, gói ngữ cảnh, chính sách mặc định và bộ đánh giá. Giữ chung bản thân harness: một policy engine, một nơi phê duyệt, một kho trace, một phương pháp đánh giá. Anti-pattern là mỗi lĩnh vực một sản phẩm riêng, mỗi sản phẩm có console, quyền và audit trail riêng. Cách làm này tái tạo vấn đề “swivel-chair” ở tầng cao hơn và nhân ba bề mặt tấn công từ Chương 5. Tệ hơn, cách làm này che giấu các trường hợp xuyên lĩnh vực, như một thay đổi chi phí gây ra sự cố, hoặc một phát hiện bảo mật do thay đổi mà agent độ tin cậy đã thực hiện.Trong thực tế: một nền tảng, ba moduleCloudThinker ánh xạ các trụ cột này thành các module dùng chung một bộ kết nối, một hệ thống Approvals và một audit log.
Mọi thao tác ghi, trong bất kỳ module nào, đều đi qua cùng các Rule và cùng Approval mode Manual hoặc Auto, nên bạn chỉ đặt chính sách một lần. Một ngoại lệ: Apply fix và Fix all findings của Review commit vào nhánh nguồn khi có người nhấn, mà không đi qua Approvals.