Closing the Loop on Metrics (Stage 6: Maintain)

1. Những thay đổi: Closing the Loop on Metrics

Trong khi mọi giai đoạn trước đều cần con người khởi xướng, Stage 6: Maintain chuyển trọng tâm sang việc vận hành tự chủ của Claude để khép kín chu trình (closing the loop). Ví dụ, một monitoring agent chạy liên tục có thể dựa vào một bug ticket vừa được tạo để tự động sinh intent.md, rồi dẫn dắt qua các giai đoạn requirements, plan, build, test và review. Stage 6: Maintain chạy headless (không giao diện tương tác), với một confidence gate độc lập giữa các giai đoạn — một deterministic check hoặc một adversarial reviewing agent — quyết định xem kết quả của giai đoạn trước có được tiếp tục chuyển sang giai đoạn sau hay leo thang (escalate) đến con người.

Trong bảo trì truyền thống, đây là giai đoạn thụ động (reactive): mọi ticket hoặc sự cố đều phải chờ con người can thiệp và khởi động lại quy trình. Cảnh báo nổ lúc 3 giờ sáng có thể bị bỏ sót, ticket có thể nằm im trong backlog cho đến khi có người nhận, và các hành động rút ra từ post-mortem có thể không bao giờ đến được codebase nếu sự cố khác phát sinh trước. Ngược lại, với AI-Native SDLC, trigger như vi phạm control bands (dải chỉ số giới hạn vận hành như CPU, tỷ lệ lỗi, độ trễ), một ticket, tin nhắn trong kênh chat, hoặc lịch định kỳ sẽ kích hoạt Claude mà không cần con người trên luồng thực thi. Claude chẩn đoán, chỉ hành động qua gated routes (như khi kết hợp quy trình canary deployment (triển khai thử nghiệm trên tỷ lệ nhỏ lưu lượng thực tế, ví dụ 5%)), và ghi lại phát hiện dưới dạng intent.md để đi qua các giai đoạn tiếp theo. Con người thực hiện incident triage (phân loại và cô lập sự cố sản xuất) và review công việc đó, không còn phải tự tay khởi động quy trình.

Một deterministic script theo dõi live production và kích hoạt Claude khi control band bị vi phạm. Giám sát vi phạm chỉ số là một ví dụ điển hình cho mô hình chu trình chạy tự chủ.

2. Sơ đồ Closing the Loop on Metrics

Quy trình khép chu trình (closing the loop) từ giám sát chỉ số live production về kế hoạch phát triển:

• Deterministic script giám sát chỉ số live production qua rolling baseline.
• Khi xuất hiện breach control bands (dải chỉ số giới hạn vận hành như CPU, tỷ lệ lỗi, độ trễ), script gọi Claude chẩn đoán headless trong container sandbox.
• Claude xuất chẩn đoán thành intent.md đưa vào hàng đợi incident triage (phân loại và cô lập sự cố sản xuất) của on-call engineer hoặc service owner.
• Phê duyệt intent.md để tái khởi động Stage 1 Plan, hoàn tất chu trình khép kín tự chủ (Continuous Loop).

3. Bắt đầu: Cấu hình Control Bands & bands.yaml

Service owner hoặc platform engineer chọn một metric có rolling baseline ổn định, chẳng hạn như tỷ lệ thất bại test CI (ci_test_failure_rate), tỷ lệ lỗi 5xx sau triển khai (post-deploy 5xx rate), hoặc chu kỳ hoàn thành PR (PR cycle time). Các tầng phản ứng (response tiers) được định nghĩa trong cấu hình quản lý phiên bản bands.yaml theo cấu trúc 3-sigma:

metric: ci_test_failure_rate
baseline: rolling_30d
rules: western_electric
tiers:
  1sigma: { action: log }
  2sigma: { action: diagnose,
            tools: "Read,Grep,Bash(gh run view *)" }
  3sigma: { action: propose,
            routes: [pull_request, runbook:rollback-deploy] }

Tầng trigger có thể là một scheduled workflow trong GitHub hoặc GitLab, một webhook từ monitoring stack hiện có, hoặc một cron job trong mạng nội bộ. Claude chạy phi trạng thái (stateless), dưới dạng một bước non-interactive trên CI runner hoặc một service dùng Agent SDK trong sandboxed container. Nhờ tính chất stateless và non-interactive, một chu trình có thể bắt đầu và kết thúc mà không cần bất kỳ ai phải tự tay khởi chạy.

4. Các bước thực thi

Service owner hoặc on-call engineer tiếp nhận hàng đợi và thực hiện incident triage (phân loại và cô lập sự cố sản xuất), điều hướng các phát hiện liên quan sản phẩm đến product owner theo 3 hướng xử lý:

5. Cấu trúc mẫu sự cố & sinh intent.md

Khi breach control band ở mức 3σ, Agent viết bản chẩn đoán của mình dưới dạng tệp intent.md theo đúng định dạng của Stage 1: Plan:

• Bất thường và bằng chứng (Anomaly & Evidence): Mô tả hiện tượng bất thường của metric, bằng chứng dữ liệu, mốc thời gian và độ lệch chuẩn.
• Kết quả kỳ vọng (Proposed Outcome): Mục tiêu đề xuất để khắc phục sự cố và đưa chỉ số trở lại baseline.
• Hệ thống bị ảnh hưởng (Affected Systems): Danh sách dịch vụ, cơ sở dữ liệu hoặc thành phần bị tác động.
• Câu hỏi mở (Open Questions): Bất kỳ vấn đề nào chưa rõ ràng cần làm rõ với kỹ sư hoặc product owner.

Từ đây, phát hiện (finding) sẽ đi qua pipeline phát triển như mọi công việc khác (Requirements, Design, Plan, Build, Test, Review Gate), tự động viết lại intent.md tiếp theo để khép chu trình.

6. Hỗ trợ On-call với Claude Tag

Sự cố cũng có thể đến qua các kênh giao tiếp trong công việc như Slack hoặc Microsoft Teams (ví dụ: một tin nhắn lúc 22h đêm yêu cầu sửa gấp trong kênh incident) và có thể được xử lý ngay lập tức. Claude Tag (public beta hiện có trên Slack) đưa Claude trở thành một thành viên trong các kênh đó với danh tính riêng, giúp mỗi sự cố mới đều có một người phản hồi đầu tiên (first responder), và bản thân phản hồi đó trở thành một phần của chu trình và bộ nhớ cho các sự cố sau.

Cuộc hội thoại và tri thức doanh nghiệp được lưu giữ ngay trong kênh, nơi bất kỳ ai cũng có thể định hướng và thúc đẩy hành động xử lý. Mọi thành viên trong nhóm đều có thể kiểm chứng giả thuyết, khám phá phương án mới và điều tra theo thời gian thực; lịch sử kênh chat đóng vai trò tăng cường tính minh bạch và lưu vết kiểm toán. Thông qua quyền truy cập MCP, Claude xác minh metric đã trở lại baseline bình thường, xác nhận trong thread và tự động viết post-mortem vào tệp bài học (lessons file) được quản lý phiên bản trong Git để các đợt điều tra trong tương lai có thể tham chiếu.

Sự cố không phải là công việc duy nhất mà Claude Tag tiếp nhận. Khi được tag vào một ticket qua MCP hoặc được yêu cầu trực tiếp trong kênh chat, Claude thực hiện phân loại công việc theo cùng cơ chế: bản sửa lỗi nhỏ, có ranh giới rõ ràng (well-bounded fix) sẽ được gửi thẳng dưới dạng PR qua review gate; còn bất kỳ công việc nào lớn hơn sẽ được soạn thảo thành intent.md cho Stage 1: Plan, thời điểm mà chu trình bắt đầu tự nuôi dưỡng chính nó.

7. Kiểm soát & Đo lường

Ranh giới giữa các tầng phản ứng (tier boundaries) được thực thi nghiêm ngặt từ cấu hình quản lý phiên bản trong Git, kết hợp quyền hạn (permissions) và managed settings để từ chối quyền truy cập trực tiếp vào live production. Các lượt gọi (invocations), phát hiện (findings) và quyết định triage đều được ghi log đầy đủ kèm timestamp. Service owner thực hiện triage và phê duyệt các phát hiện; các thay đổi phát sinh đều phải đi qua PR review gate thông thường; và các runbook mà agent được phép kích hoạt đều phải được phê duyệt trước.

Các ví dụ điển hình (Examples)

• CI test failure rate vi phạm 3σ: Agent tự động cách ly bài kiểm thử chập chờn (quarantine flaky test) hoặc mở một PR revert, và PR review gate sẽ quyết định phê duyệt.
• Post-deploy 5xx rate vi phạm 3σ khi có đợt triển khai trong cửa sổ thời gian: (Chẳng hạn trong đợt canary deployment (triển khai thử nghiệm trên tỷ lệ nhỏ lưu lượng thực tế, ví dụ 5%)), Agent tự động kích hoạt pipeline rollback hiện có qua rollback gate (chốt chặn tự động revert khi vượt ngưỡng lỗi).
• PR cycle time vi phạm quy tắc trôi dạt (drift rule): Agent lập một báo cáo phân tích gửi ban lãnh đạo kỹ thuật (engineering leadership) — minh chứng rằng khung kiểm soát (harness) vận hành hiệu quả cho cả chỉ số quy trình (process metrics) lẫn chỉ số live production.