Chuyển đến nội dung chính
Khi một incident xảy ra trên môi trường production, nhóm của bạn có các runbook—quy trình từng bước cho các sự cố phổ biến như pod restart, database failover hoặc các thao tác scaling. Vấn đề là tìm đúng runbook lúc 3 giờ sáng và thực thi chính xác dưới áp lực. CloudThinker Runbooks lấp đầy khoảng cách đó. Trong quá trình điều tra RCA, các AI agent tự động tìm kiếm trong các nguồn runbook đã kết nối, tìm quy trình phù hợp và thực thi các lệnh khắc phục—với các kiểm soát phê duyệt theo chính sách để con người luôn tham gia vào các thao tác nguy hiểm.
Bảng điều khiển Runbook Sources hiển thị các file upload thủ công và nguồn kết nối GitHub với nút bật/tắt

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

1

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.
2

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.
3

Đá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.
4

Thực thi với phê duyệt

Với các lệnh cần phê duyệt, bạn nhận được thông báo qua email, Slack và trong ứng dụng. Phê duyệt hoặc từ chối trực tiếp từ bất kỳ kênh nào. Các lệnh được phê duyệt sẽ thực thi ngay lập tức.

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.
Hộp thoại Add Runbook Source với tên nguồn, lựa chọn loại nguồn và các trường cấu hình Confluence

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:
  1. Nhấp Add Source trên trang Runbooks
  2. Nhập tên (ví dụ: “SRE Runbooks”)
  3. Chọn Confluence làm loại nguồn
  4. Chọn kết nối Atlassian của bạn (được thiết lập trong Connections > Atlassian)
  5. Tùy chọn giới hạn tìm kiếm theo Space Key cụ thể (ví dụ: SRE)
  6. Thêm Labels để lọc trang (ví dụ: runbook, incident-response)
  7. Nhấp Add Source
Cách agent tìm kiếm: Trong quá trình RCA, agent sử dụng ngôn ngữ truy vấn CQL của Confluence để tìm các trang phù hợp với ngữ cảnh incident trong không gian và bộ lọc nhãn đã cấu hình.

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:
  1. Nhấp Add Source
  2. Chọn GitHub làm loại nguồn
  3. Chọn kết nối GitHub của bạn (được thiết lập trong Connections)
  4. Chọn repository chứa runbook của bạn
  5. Đặt branch (mặc định là main)
  6. Tùy chọn đặt path prefix để giới hạn tìm kiếm (ví dụ: docs/runbooks/)
  7. Cấu hình file patterns để khớp (mặc định là *.md)
  8. Nhấp Add Source
Cách agent tìm kiếm: Agent sử dụng GitHub API để liệt kê và đọc các file khớp với bộ lọc đường dẫn và mẫu, sau đó phân tích nội dung để xác định mức độ liên quan đến incident hiện tại.

GitLab

Quy trình tương tự GitHub, sử dụng kết nối GitLab thay thế. Thiết lập:
  1. Nhấp Add Source
  2. Chọn GitLab làm loại nguồn
  3. Chọn kết nối GitLab của bạn
  4. Chọn repository, branch, path prefixfile patterns
  5. Nhấp Add Source
Cách agent tìm kiếm: Agent sử dụng GitLab API để tìm kiếm và lấy các file khớp từ kho lưu trữ của bạn.

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:
  1. Nhấp Upload Runbook trên trang Runbooks
  2. Kéo và thả các file .md (tối đa 20 file, mỗi file 5 MB)
  3. Chỉnh sửa tên file nếu cần trước khi xác nhận
  4. Nhấp Confirm Upload
Sau khi upload, CloudThinker tự động trích xuất các lệnh ghi (như 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.
Hộp thoại quyền theo từng lệnh hiển thị các lệnh kubectl được trích xuất với dropdown Require Approval riêng cho từng lệnh

Kiểm soát quyền theo từng lệnh cho runbook pod-crashloopbackoff

Cách hoạt động

  1. 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)
  2. Bỏ qua lệnh chỉ đọc: Các lệnh như kubectl get, kubectl describekubectl logs không được trích xuất—agent luôn có thể chạy các lệnh chỉ đọc
  3. 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ềnHành vi
AllowAgent thực thi lệnh ngay lập tức mà không cần phê duyệt từ con người
Require ApprovalAgent 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
DenyAgent 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

  1. 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
  2. Đá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ó
  3. 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ờ
  4. 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
  5. 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
ApprovedCon người đã phê duyệt—các lệnh đang thực thi hoặc đã hoàn thành
RejectedCon 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
CompletedTất cả lệnh đã thực thi thành công
FailedMột hoặc nhiều lệnh gặp lỗi trong quá trình thực thi
SkippedThự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)
Chiến lược quyền:
  • 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)
Chất lượng runbook:
  • 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.