
Bảng điều khiển Runbook Sources với các file upload thủ công và các kho lưu trữ đã kết nối
Cách hoạt động của runbook
Kết nối nguồn của bạn
Liên kết các kho lưu trữ runbook hiện có của bạn—Confluence, GitHub, GitLab—hoặc upload trực tiếp các file markdown.
Agent tìm kiếm trong quá trình RCA
Khi một incident kích hoạt Phân tích nguyên nhân gốc rễ, AI agent tìm kiếm trong các nguồn đã kết nối để tìm runbook phù hợp dựa trên ngữ cảnh incident và các dịch vụ bị ảnh hưởng.
Đánh giá chính sách
Trước khi thực thi bất kỳ lệnh nào, hệ thống đánh giá chính sách phê duyệt của workspace. Tùy theo chính sách, các lệnh có thể được tự động thực thi, xếp hàng chờ phê duyệt hoặc bị chặn.
Kết nối nguồn runbook
Điều hướng đến Deep Response Engine > Runbooks để quản lý nguồn của bạn. CloudThinker hỗ trợ bốn loại nguồn, mỗi loại phù hợp với các quy trình làm việc khác nhau.
Thêm nguồn runbook mới với cấu hình Confluence
Confluence
Kết nối cơ sở tri thức Confluence để cho phép agent tìm kiếm các trang wiki về quy trình vận hành. Thiết lập:- Nhấp Add Source trên trang Runbooks
- Nhập tên (ví dụ: “SRE Runbooks”)
- Chọn Confluence làm loại nguồn
- Chọn kết nối Atlassian của bạn (được thiết lập trong Connections > Atlassian)
- Tùy chọn giới hạn tìm kiếm theo Space Key cụ thể (ví dụ:
SRE) - Thêm Labels để lọc trang (ví dụ:
runbook,incident-response) - Nhấp Add Source
GitHub
Trỏ agent đến một kho lưu trữ GitHub chứa các file markdown runbook của bạn. Thiết lập:- Nhấp Add Source
- Chọn GitHub làm loại nguồn
- Chọn kết nối GitHub của bạn (được thiết lập trong Connections)
- Chọn repository chứa runbook của bạn
- Đặt branch (mặc định là
main) - Tùy chọn đặt path prefix để giới hạn tìm kiếm (ví dụ:
docs/runbooks/) - Cấu hình file patterns để khớp (mặc định là
*.md) - Nhấp Add Source
GitLab
Quy trình tương tự GitHub, sử dụng kết nối GitLab thay thế. Thiết lập:- Nhấp Add Source
- Chọn GitLab làm loại nguồn
- Chọn kết nối GitLab của bạn
- Chọn repository, branch, path prefix và file patterns
- Nhấp Add Source
Upload thủ công
Upload trực tiếp các file markdown runbook khi quy trình của bạn không được lưu trữ trong hệ thống bên ngoài. Thiết lập:- Nhấp Upload Runbook trên trang Runbooks
- Kéo và thả các file
.md(tối đa 20 file, mỗi file 5 MB) - Chỉnh sửa tên file nếu cần trước khi xác nhận
- Nhấp Confirm Upload
kubectl apply, các mutation của aws, helm install) từ các code block trong file markdown. Các lệnh được trích xuất này trở thành cơ sở cho quyền theo từng lệnh.
Quyền theo từng lệnh
Runbook thủ công mở khóa một tính năng an toàn độc đáo: kiểm soát quyền theo từng lệnh. Khi bạn upload một file markdown, AI của CloudThinker đọc qua các code block và trích xuất mọi lệnh ghi/thay đổi—cho bạn kiểm soát chi tiết những gì agent có thể thực thi tự động.
Kiểm soát quyền theo từng lệnh cho runbook pod-crashloopbackoff
Cách hoạt động
- Trích xuất tự động: Sau khi upload, hệ thống phân tích tất cả code block và xác định các lệnh shell thay đổi cơ sở hạ tầng (ví dụ:
kubectl set resources,kubectl rollout restart,kubectl delete) - Bỏ qua lệnh chỉ đọc: Các lệnh như
kubectl get,kubectl describevàkubectl logskhông được trích xuất—agent luôn có thể chạy các lệnh chỉ đọc - Mỗi lệnh nhận một quyền: Mỗi lệnh ghi được trích xuất bắt đầu với Require Approval theo mặc định
Các mức quyền
| Quyền | Hành vi |
|---|---|
| Allow | Agent thực thi lệnh ngay lập tức mà không cần phê duyệt từ con người |
| Require Approval | Agent yêu cầu phê duyệt trước khi thực thi. Bạn được thông báo qua email, Slack và trong ứng dụng |
| Deny | Agent không thể thực thi lệnh này |
Quản lý lệnh
Từ hộp thoại chi tiết runbook:- Đặt tất cả quyền cùng lúc: Sử dụng dropdown “Set all to…” để thay đổi hàng loạt tất cả lệnh sang Allow, Require Approval hoặc Deny
- Thay đổi quyền từng lệnh: Nhấp vào dropdown bên cạnh bất kỳ lệnh nào để điều chỉnh mức quyền
- Thêm lệnh: Nhập mẫu lệnh mới và nhấn Enter để thêm vào danh sách
- Xóa lệnh: Nhấp vào biểu tượng xóa để xóa lệnh khỏi chính sách
- Xem lệnh đầy đủ: Nhấp vào mũi tên mở rộng để xem lệnh nhiều dòng hoặc lệnh dài ở dạng đầy đủ
Quyền theo từng lệnh hiện có sẵn cho runbook được upload thủ công. Với các nguồn bên ngoài (Confluence, GitHub, GitLab), tất cả lệnh yêu cầu phê duyệt theo mặc định. Kiểm soát theo từng lệnh cho các nguồn bên ngoài sẽ sớm ra mắt.
Quy trình phê duyệt
Khi agent tìm thấy runbook phù hợp trong quá trình RCA và chính sách yêu cầu phê duyệt, quy trình sau sẽ xảy ra:Luồng phê duyệt
- Agent phát hiện runbook: Trong quá trình điều tra, agent tìm kiếm trong các nguồn và xác định quy trình phù hợp
- Đánh giá chính sách: Hệ thống kiểm tra các chính sách phê duyệt của workspace với runbook và các lệnh của nó
- Gửi thông báo: Nếu cần phê duyệt, bạn nhận được thông báo trên tất cả các kênh đã cấu hình:
- Email: Tiêu đề runbook, liên kết nguồn và lý do chính sách
- Slack: Thông báo tương tác với ngữ cảnh incident
- Trong ứng dụng: Badge trên incident hiển thị các phê duyệt đang chờ
- Bạn phê duyệt hoặc từ chối: Nhấp Approve để cho phép agent tiếp tục, hoặc Reject để chặn thực thi
- Agent tiếp tục: Khi được phê duyệt, agent thực thi các lệnh runbook. Khi bị từ chối, agent tiếp tục điều tra mà không thực thi
Trạng thái phê duyệt
| Trạng thái | Ý nghĩa |
|---|---|
| Pending | Đang chờ phê duyệt từ con người—agent đang tạm dừng ở bước này |
| Approved | Con người đã phê duyệt—các lệnh đang thực thi hoặc đã hoàn thành |
| Rejected | Con người đã từ chối—agent đã bỏ qua runbook này và tiếp tục điều tra |
Trạng thái thực thi
Sau khi phê duyệt, mỗi lần thực thi theo dõi kết quả:| Trạng thái | Ý nghĩa |
|---|---|
| Not Started | Đã được phê duyệt nhưng các lệnh chưa chạy |
| Completed | Tất cả lệnh đã thực thi thành công |
| Failed | Một hoặc nhiều lệnh gặp lỗi trong quá trình thực thi |
| Skipped | Thực thi bị bỏ qua (ví dụ: phê duyệt đã hết hạn hoặc bị thay thế) |
Xem lịch sử thực thi
Chuyển sang tab Execution History trên trang Runbooks để xem tất cả lần thực thi runbook qua các incident. Bạn có thể:- Tìm kiếm theo tiêu đề runbook
- Xem quyết định chính sách, trạng thái phê duyệt và kết quả thực thi
- Theo dõi runbook nào được sử dụng cho incident nào
Thực tiễn tốt nhất
Tổ chức nguồn:- Đặt tên nguồn mô tả rõ ràng (ví dụ: “K8s Emergency Runbooks”, “Database Failover Procedures”)
- Sử dụng path prefix và file pattern để giữ tìm kiếm có trọng tâm và nhanh chóng
- Với Confluence, sử dụng nhãn để phân loại runbook theo lĩnh vực (ví dụ:
kubernetes,database,networking)
- Bắt đầu với Require Approval cho tất cả lệnh (mặc định) cho đến khi bạn xây dựng được sự tin tưởng
- Dần dần chuyển các lệnh đã được kiểm tra kỹ và ít rủi ro sang Allow (ví dụ: thao tác scaling, thu thập log)
- Giữ các lệnh phá hủy (delete, drop, force) ở Require Approval vĩnh viễn
- Sử dụng Deny cho các lệnh không bao giờ nên được tự động hóa (ví dụ: xóa database production)
- Viết runbook bằng markdown với code block rõ ràng sử dụng gợi ý ngôn ngữ shell (
```bash) - Dùng một lệnh mỗi dòng để có kết quả trích xuất tốt nhất
- Bao gồm ngữ cảnh về thời điểm sử dụng mỗi quy trình—agent dùng thông tin này để khớp runbook với incident
- Giữ runbook tập trung: một quy trình mỗi file hoạt động tốt hơn một tài liệu duy nhất bao quát tất cả
Bước tiếp theo
Phân tích nguyên nhân gốc rễ
Tìm hiểu cách AI agent điều tra incident và thời điểm runbook được kích hoạt trong quy trình phân tích.
Chính sách phê duyệt
Cấu hình chính sách phê duyệt cấp workspace kiểm soát những gì agent có thể thực thi tự động.