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

# Chương 9 · Lộ trình Triển khai

> Lộ trình áp dụng từng giai đoạn, dựa trên bằng chứng: chín mươi ngày đến giá trị đầu tiên, mười hai tháng đến mô hình vận hành mới. Năm nền tảng sẵn sàng, pilot 90 ngày, mở rộng quy mô, và năm cách các dự án bị hủy bỏ.

*Lộ trình áp dụng từng giai đoạn, dựa trên bằng chứng: chín mươi ngày đến giá trị đầu tiên, mười hai tháng đến mô hình vận hành mới.*

## 9.1 Sẵn sàng: những gì agent cần từ bạn

Các agent khuếch đại môi trường mà chúng thừa hưởng. Trước khi triển khai đầu tiên, hãy đánh giá thành thật năm nền tảng:

1. **Quan sát.** Log, số liệu và trace tập trung với phạm vi bao phủ hợp lý. Các agent không thể lập luận trên các tín hiệu không tồn tại.

2. **Kiến trúc truy cập.** Khả năng tạo thông tin xác thực có phạm vi, tồn tại ngắn hạn cho mỗi agent. Nếu mọi thứ chạy trên một khóa admin duy nhất hôm nay, hãy sửa điều đó trước.

3. **Nguồn sự thật.** Infrastructure as code cho các bề mặt agent sẽ chạm vào, dù chỉ một phần. IaC cung cấp cho agent một cơ chế thay đổi an toàn và cho bạn một dấu vết kiểm toán có thể so sánh.

4. **Mục đích được ghi lại.** SLO, runbook, ghi chú kiến trúc — không hoàn hảo là ổn; vắng mặt thì không. Đây trở thành tầng ngữ cảnh của agent.

5. **Chủ sở hữu có trách nhiệm.** Một kỹ sư cấp cao được đặt tên với nhiệm vụ thiết lập chính sách tự chủ và uy tín để đưa vòng trực đi cùng.

## 9.2 Pilot 90 ngày

| Giai đoạn          | Tuần  | Trọng tâm                                                                                                                                                                          | Tiêu chí thoát                                                                                   |
| :----------------- | :---- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------- |
| Baseline & phạm vi | 1–2   | Ghi lại MTTR, khối lượng cảnh báo, số lượng trang, giờ công việc tầm thường. Chọn một lĩnh vực giới hạn (phản hồi sự cố của một sản phẩm, hoặc chi phí đám mây cho một tài khoản). | Baseline đã ký; lĩnh vực có phạm vi; số liệu thành công đã thống nhất                            |
| Quan sát (L0–L1)   | 3–6   | Kết nối dữ liệu đo từ xa và công cụ chỉ đọc. Các agent điều tra mọi sự cố song song với con người; kỹ sư chấm điểm các phân tích.                                                  | ≥70% phân tích nguyên nhân gốc rễ của agent được đánh giá đúng hoặc hữu ích bởi vòng trực        |
| Phê duyệt (L2)     | 7–10  | Các agent đề xuất các biện pháp khắc phục hoàn chỉnh với bằng chứng; con người phê duyệt một chạm. Theo dõi tỷ lệ chấp nhận và rollback.                                           | ≥80% chấp nhận; không có hành động có hại; MTTR cải thiện rõ ràng                                |
| Tốt nghiệp (L3)    | 11–13 | Phê duyệt trước 5–10 lớp hành động an toàn nhất, được lặp lại nhiều nhất. Các agent hành động và thông báo. Xem xét mọi hành động hàng tuần.                                       | Các giải quyết tự chủ đầu tiên trong môi trường thực tế; delta MTTR được ghi lại so với baseline |

Hãy đề kháng sự cám dỗ bắt đầu với vấn đề khó nhất. Công việc của pilot là tạo ra bằng chứng và sự tin tưởng, không phải những hành động anh hùng. Một lĩnh vực nhàm chán với các sự cố thường xuyên, lặp đi lặp lại — khởi động lại Kubernetes, áp lực đĩa, hết hạn chứng chỉ, bất thường chi phí — tạo ra độ tin cậy thống kê nhanh nhất.

> *Hình 9 — Pilot 90 ngày: bốn giai đoạn, mỗi giai đoạn với tiêu chí thoát đã ký trước khi tính tự chủ tốt nghiệp.*

Hình dạng pilot này hiện là thực tiễn được nhà cung cấp xác nhận, không chỉ là sự thận trọng: hướng dẫn áp dụng đã công bố của AWS cho DevOps Agent — một khu vực, một dịch vụ, chỉ khuyến nghị trong nhiều tuần, sau đó đo MTTR trước khi mở rộng — là các giai đoạn Quan sát và Phê duyệt của lộ trình này trong những từ khác nhau, và các kiểm soát quản trị theo giai đoạn của Azure giả định cùng một tiến trình. Nếu các hyperscaler gắn agent của riêng họ theo cách này trên đám mây của chính họ, một ngân hàng không nên bị thuyết phục bỏ qua điều đó.

## 9.3 Mở rộng quy mô: tháng 4–12

1. **Mở rộng lĩnh vực, không chỉ tính tự chủ.** Thêm các chuyên gia — cơ sở dữ liệu, bảo mật, chi phí — từng cái một, mỗi cái qua cùng thang quan sát → phê duyệt → tốt nghiệp.

2. **Công nghiệp hóa quản trị.** Chuyển chính sách tự chủ từ một tài liệu sang cấu hình được thực thi; thiết lập tầng bảo vệ/giám sát; tích hợp các hành động agent vào quản lý thay đổi với bằng chứng tự động.

3. **Xây dựng hào bộ nhớ.** Quản lý tầng ngữ cảnh một cách có chủ ý: cấu trúc mạng, quy ước, sự cố quá khứ, kiến thức bộ lạc. Đây là nơi triển khai của bạn trở nên hiệu quả một cách bất thường và không thể sao chép.

4. **Tái cơ cấu vòng trực.** Khi tỷ lệ giải quyết tự chủ tăng lên, hợp nhất các vòng trực, chuyển hướng thời gian cấp cao được thu hồi sang kỹ thuật phòng ngừa, và chính thức hóa các vai trò vận hành-agent và chính sách-tự chủ.

5. **Báo cáo liên tục.** Công bố dashboard hàng tháng — xu hướng MTTR, tỷ lệ giải quyết tự chủ, trang được tránh, đô la tiết kiệm — cho kỹ thuật và cho doanh nghiệp. Các chương trình được tài trợ là các chương trình được đo lường.

## 9.4 Cách 40% bị hủy bỏ chết đi

Gartner dự báo hơn 40% dự án AI agentic sẽ bị hủy bỏ vào cuối năm 2027, đặt tên ba kẻ giết chết: chi phí leo thang, giá trị kinh doanh không rõ ràng, và kiểm soát rủi ro không đầy đủ. Trong vận hành cụ thể, những trừu tượng đó có năm dạng cụ thể. Mỗi cái có một giải độc tố đã biết:

1. **Pilot không bao giờ tốt nghiệp.** (Giá trị không rõ ràng.) Chỉ tư vấn mãi mãi cảm thấy an toàn và không chứng minh gì — sau đó kỳ gia hạn đến mà không có delta MTTR nào để trình bày. *Giải độc tố:* tiêu chí tốt nghiệp được ký vào ngày đầu tiên, được tuân thủ đúng lịch trình.

2. **Tính tự chủ trước bằng chứng.** (Kiểm soát rủi ro không đầy đủ.) Một hành động tự chủ tự tin sai lúc 3 giờ sáng tốn nhiều niềm tin hơn một trăm hành động tốt kiếm được. *Giải độc tố:* không bao giờ bỏ qua các bước thang, và để tỷ lệ chấp nhận và rollback — không phải sự nhiệt tình — đặt ra tốc độ.

3. **Sự tràn lan công cụ không có orchestration.** (Chi phí leo thang và giá trị không rõ ràng.) Năm agent điểm rời rạc tái tạo vấn đề swivel-chair với giấy phép thêm (cùng thuế điều phối, một tầng cao hơn, mà §10.3 theo dõi qua các agent đơn đám mây). *Giải độc tố:* một orchestrator, một dấu vết kiểm toán, một dashboard.

4. **Chi tiêu model không giới hạn.** (Chi phí leo thang.) Lập luận frontier trên mọi tín hiệu ồn ào xóa sạch ROI trước lần gia hạn đầu tiên. *Giải độc tố:* cảm nhận hai tầng và theo dõi chi phí per-incident từ ngày đầu tiên.

5. **Coi đó là mua công cụ.** (Cả ba.) Khoảng cách thử nghiệm-đến-thực-tế từ Chương 1 là khoảng cách mô hình vận hành, không phải khoảng cách công nghệ. *Giải độc tố:* ngân sách cho những thay đổi vai trò, công việc chính sách và thang tin tưởng — không chỉ giấy phép.

## 9.5 Khi nào không nên triển khai: những lý do loại trừ trung thực

Trước khi triển khai, bạn đặt một baseline sẵn sàng vào vị trí; phần này là người bạn đồng hành khó hơn của nó: các trường hợp mà câu trả lời trung thực là phải chờ. Một cuốn sách yêu cầu người mua không tin vào bất kỳ ai không thể nói không với họ nên có thể nói điều đó về danh mục của chính nó. Mỗi lý do loại trừ dưới đây là lý do để sửa chữa điều gì đó trước, không phải là bản án vĩnh viễn — nhưng triển khai qua bất kỳ cái nào trong số chúng sẽ mua lấy một sự thất vọng tốn kém.

1. **Bạn không có tín hiệu để lập luận.** Nếu khả năng quan sát thưa thớt hoặc phân mảnh — không có log, số liệu hoặc trace tập trung qua lĩnh vực mục tiêu — agent không có gì để lập luận từ đó, và sẽ tự tin lập luận từ nhiễu. Hãy sửa khả năng quan sát trước; một agent khuếch đại môi trường mà nó thừa hưởng, và khuếch đại một điểm mù tạo ra một điểm mù tự tin.

2. **Mọi thứ chạy trên một thông tin xác thực admin dùng chung.** Nếu bạn không thể tạo thông tin xác thực có phạm vi, tồn tại ngắn hạn cho mỗi agent, bạn không thể giới hạn bán kính nổ của agent hoặc kiềm chế một agent bị xâm phạm. Cho đến khi truy cập quyền tối thiểu là thực tế, hành động tự chủ là rủi ro không thể chấp nhận bất kể agent tốt đến đâu.

3. **Không ai sở hữu chính sách tự chủ.** Nếu không có kỹ sư cấp cao được đặt tên với thẩm quyền thiết lập chính sách tự chủ và vị thế để dẫn dắt nhóm trực, chương trình sẽ đình trệ ở chế độ tư vấn hoặc lao vào hành động không được quản trị. Chủ sở hữu là điều kiện tiên quyết, không phải là vai trò cần lấp đầy sau.

4. **Quản lý thay đổi không thể chứa thay đổi do máy khởi xướng.** Nếu quy trình thay đổi của bạn không có đường dẫn cho thay đổi do máy khởi xướng, được con người phê duyệt với dấu vết kiểm toán, các hành động agent sẽ vượt qua quản trị — không thể chấp nhận trong môi trường được quản lý — hoặc bị chặn hoàn toàn. Hãy giải quyết câu hỏi quy trình trước, không phải trong khi triển khai.

5. **Mục tiêu đầu tiên là hệ thống quan trọng nhất, ít đảo ngược nhất của bạn.** Bắt đầu trên đường dẫn cốt lõi với các hành động không thể đảo ngược đảo ngược thang tin tưởng. Nếu lĩnh vực pilot duy nhất có sẵn là lĩnh vực mà một hành động sai là thảm họa và không thể phục hồi, hãy chờ cho đến khi một lĩnh vực giới hạn, có thể đảo ngược có sẵn — hoặc cố tình tạo ra một lĩnh vực. Công việc của pilot là bằng chứng, không phải anh hùng.

Cũng có một lý do loại trừ về thời gian không liên quan gì đến sự sẵn sàng: nếu tổ chức không thể tài trợ cho sự thay đổi mô hình vận hành — thiết kế lại vai trò, công việc chính sách, thang tin tưởng — và chỉ mua giấy phép, nó sẽ rơi vào 40% bị hủy bỏ của §9.4 dù cơ sở hạ tầng của nó sẵn sàng đến đâu. Công nghệ không phải là yếu tố quyết định. Sự sẵn sàng chạy chương trình như một sự chuyển đổi thay vì mua công cụ mới là yếu tố quyết định.