> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Runbooks
> Kết nối runbook vận hành của nhóm để các AI agent có thể tìm kiếm và thực thi các bước khắc phục sự cố trong quá trình xử lý incident
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](/vi/guide/incident/root-cause-analysis), 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 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
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.
Khi một incident kích hoạt [Phân tích nguyên nhân gốc rễ](/vi/guide/incident/root-cause-analysis), 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.
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](/vi/guide/approval) 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.
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.
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](/vi/guide/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](/vi/guide/connections/overview))
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 prefix** và **file 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).
***
## 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
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 describe` và `kubectl 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ề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
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 |
| **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`)
**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
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.
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.