# Build một AI SRE agent bằng Claude Agent SDK để trực sự cố production

[Owain Lewis](https://homus.dev/speakers/owain-lewis) · [Owain Lewis](https://homus.dev/orgs/owain-lewis)

> Owain Lewis build một AI SRE agent bằng Claude Agent SDK: đọc log, metrics, lịch sử deploy, đề xuất rollback có người duyệt, và theo dõi rollout.

Topics: Agents, Software Factory, Workflow

Canonical: https://homus.dev/talks/i-built-a-claude-devops-agent-to-run-my-software-factory

## 1. Dùng AI agent để vận hành phần mềm trong production

Owain Lewis mở đầu video (đăng ngày 05/10/2026) bằng chủ đề chính: dùng AI agent để quản lý và vận hành phần mềm đang chạy trong production. Với anh, đây là một trong những use case thú vị và hấp dẫn nhất của autonomous AI agent, vì theo con số anh đưa ra, chỉ một lần outage có thể làm một doanh nghiệp mất hơn 100.000 đô (con số anh nêu trong video đăng ngày 05/10/2026).

![Owain Lewis trong khung hình, chữ Autonomous AI hiện giữa khung hình](https://homus.dev/photos/l6GpUvPOVpM-0002.jpg)

Khung mở đầu video: Owain trong khung hình, dòng chữ "Autonomous AI" hiện lên giữa màn hình.

Điều hay nhất khi dùng AI agent cho việc này, theo Owain (video đăng ngày 05/10/2026), là chúng gần như "siêu nhân" khi phải lục qua một lượng dữ liệu rất lớn để tìm ra đúng một vấn đề cụ thể trong phần mềm của bạn. Vì vậy trong video, anh sẽ cho xem cách build một hệ thống AI tự động quản lý và giám sát các hệ thống production, dùng Claude Agent SDK. Anh sẽ đi qua architecture rồi demo để người xem thấy nó chạy thực tế ra sao.

Anh tự giới thiệu: anh tên Owain, đã làm software developer suốt 20 năm qua, và theo lời anh trong video đăng ngày 05/10/2026, ngày nào anh cũng build những hệ thống AI tự động kiểu này.

## 2. Một giờ downtime của Amazon tốn bao nhiêu

Để cho thấy vấn đề outage phần mềm nghiêm trọng thế nào, Owain lấy ví dụ một công ty như Amazon, mà anh gọi là trường hợp cực đoan. Nếu Amazon ngừng chạy một tiếng, con số anh đọc trên màn hình là 72,8 triệu đô mỗi giờ (theo kết quả tìm kiếm anh mở trong video đăng ngày 05/10/2026). Anh thấy con số đó thật ra cũng hợp lý nếu nghĩ xem có bao nhiêu người phụ thuộc vào Amazon, bao nhiêu giao dịch và đơn hàng diễn ra trong khoảng thời gian đó khi hệ thống không chạy.

![Trang tìm kiếm Google với AI Overview về chi phí outage của Amazon](https://homus.dev/photos/l6GpUvPOVpM-0043.jpg)

Owain tìm "outage cost amazon" trên Google. Phần AI Overview ghi các sự cố AWS làm Amazon mất ước tính 72,8 triệu đô mỗi giờ, và mục "Historical Benchmark Costs" ghi khoảng 66.240 đến 203.577 đô mỗi phút (số liệu trên màn hình trong video đăng ngày 05/10/2026).

Theo Owain, không chỉ mất doanh thu, công ty còn bị ảnh hưởng tới uy tín. Amazon mà sập thì khách hàng bực mình, và với một công ty cỡ Amazon thì vẫn ổn. Nhưng với một doanh nghiệp nhỏ hơn, anh lấy ví dụ Claude API: nếu nó ngừng chạy quá thường xuyên, bạn bắt đầu mất niềm tin vào công ty đó và dễ chuyển sang một đối thủ mà bạn tin là đáng tin cậy hơn (nhận định của Owain trong video đăng ngày 05/10/2026). Vì vậy, với anh, độ tin cậy (reliability) và uptime là thứ cực kỳ quan trọng với bất kỳ doanh nghiệp phần mềm nào.

Anh chỉ thêm vài con số khác trên màn hình mà anh thấy rất thú vị, và "hơi điên rồ": khoảng 66.000 đến 203.000 đô cho mỗi phút downtime (trên màn hình là 66.240 đến 203.577 đô, theo video đăng ngày 05/10/2026). Với một công ty như Amazon, mức ảnh hưởng đó lớn tới mức khó tin. Với công ty nhỏ hơn, tất nhiên ảnh hưởng ít hơn, nhưng theo Owain vẫn rất đáng kể: một doanh nghiệp bình thường cũng sẽ bị tác động nặng nếu hệ thống phần mềm của họ không chạy được trong một khoảng thời gian dài.

## 3. AI SRE: agent làm người ứng cứu đầu tiên

Ý tưởng đằng sau một AI SRE (site reliability engineer, kỹ sư giữ cho hệ thống chạy ổn định) là bạn có một AI agent đứng ở tuyến đầu, làm người ứng cứu đầu tiên (frontline responder) cho mọi incident hay lỗi production xảy ra với hệ thống phần mềm của bạn. Theo cách Owain mô tả trong video đăng ngày 05/10/2026: giả sử có gì đó hỏng trong production, agent sẽ lập tức bắt đầu điều tra vấn đề, tìm ra cái gì đang sai. Nó sẽ xem log, xem metrics.

![Trang tài liệu AI SRE with Claude, mục What is an AI SRE](https://homus.dev/photos/l6GpUvPOVpM-0203.jpg)

Trang tài liệu "AI SRE with Claude" Owain mở trong video (05/10/2026). Mục "What is an AI SRE?" ghi: AI SRE là một agent dùng công cụ vận hành để điều tra lỗi trong phần mềm đang chạy; agent đọc alert, tìm trong log, kiểm metrics, so các thay đổi gần đây, rồi gom bằng chứng và gợi ý bước kế tiếp.

Agent cũng sẽ xem có lần deploy nào hay thay đổi nào gần đây với hệ thống không. Sau đó nó dùng toàn bộ bằng chứng đó để đi tới một kết luận nào đó, và có thể đưa cho bạn một khuyến nghị nên làm gì (theo mô tả của Owain, video đăng ngày 05/10/2026).

Owain nói thêm: khi chúng ta ngày càng deploy nhiều code bằng AI agent, loại hệ thống này càng trở nên quan trọng hơn rất nhiều. Hãy nghĩ xem chúng ta đang release lên production nhiều code hơn bao nhiêu, mà phần lớn trong đó do AI sinh ra. Vì vậy, theo anh (video đăng ngày 05/10/2026), chúng ta cần những hệ thống an toàn kiểu này trong production: nếu có sai sót, regression, bug hay vấn đề gì với hệ thống, chúng ta cần AI agent giúp mình đi nhanh hơn để xử lý.

## 4. Vòng lặp OODA: observe, orient, decide, act

Một framework thú vị mà Owain rất thích khi nói về AI agent và hệ thống tự động là vòng lặp OODA (video đăng ngày 05/10/2026). Về cơ bản, ta chỉ đang quan sát (observe) điều gì đang diễn ra, tức để ý tới môi trường. Ta định hướng (orient) bằng cách nhìn toàn bộ thông tin và tìm xem mình đang ở đâu. Rồi ta quyết định (decide) nên làm gì, và cuối cùng hành động (act).

Vòng lặp OODA áp vào một agent vận hành, theo cách Owain giải thích: tín hiệu từ môi trường, dùng tool lấy thông tin, diễn giải bằng chứng, quyết định, rồi hành động. Dòng cuối lấy từ trang tài liệu anh mở trong video (05/10/2026): "After acting, observe again to check the result."

Theo Owain (video đăng ngày 05/10/2026), các hệ thống AI agent tự động chạy đúng như vậy. Ta tìm tín hiệu trong môi trường, ví dụ khi có gì đó hỏng thì có một alert đang bắn (firing). Sau đó ta dùng các tool để tìm thông tin mình cần, diễn giải bằng chứng đó, đưa ra một phán đoán (judgment call), quyết định làm gì, rồi hành động. Hành động ở đây thường chỉ có hai lựa chọn: hoặc báo cho một người, hoặc tự sửa cái gì đó.

## 5. Anthropic và Google đang làm gì với ý tưởng này

Owain giới thiệu vài bài viết rất hay anh khuyên nên đọc về chủ đề này. Theo anh (video đăng ngày 05/10/2026), team Anthropic nói nhiều về việc dùng AI agent, hay dùng Claude, làm người ứng cứu đầu tiên khi trực on-call. Anh gọi đó là một ví dụ rất hay: một team có thể đặt câu hỏi cho agent, agent thì liên tục theo dõi những gì đang diễn ra trong production, và anh nói team Anthropic dùng cách này khá nhiều. Bài anh mở là bài blog của Claude "Claude on call: How Claude Tag serves as Anthropic's first responder for CI/CD failures"; bài viết ghi rằng mấy tháng gần đây Claude Tag là người ứng cứu đầu tiên khi có lỗi CI/CD ở Anthropic (đọc ngày 23/10/2026).

Anh cũng mở một bài khác từ Google. Theo Owain, tất cả các công ty lớn lúc quay video (05/10/2026) đều đang nghiêng về ý tưởng để một AI agent làm tuyến phòng thủ đầu tiên trong vận hành. Trong bài của Google có vài ý thú vị, và ý anh thấy đáng chú ý nhất là phần incident management.

Về cơ bản, theo mô tả của Owain dựa trên bài của Google (video đăng ngày 05/10/2026), mỗi khi có incident, một AI agent có thể điều phối những gì đang diễn ra. Nó có thể làm những việc như handoff (trên màn hình: bàn giao giữa các SRE cùng xử lý incident), tạo tài liệu và bản postmortem cho incident, phân tích incident, và cũng có thể điều tra. Trên màn hình là mục "Incident investigation": team SRE của Google cũng đã tạo các agent để điều tra incident, và trong một số trường hợp còn tự giảm thiểu sự cố. Owain tóm lại: agent sẽ điều tra, vẫn chỉ là xem log, xem monitoring, tracing và những thứ tương tự, rồi tìm ra cái agent cho là đang sai trong hệ thống và đưa bạn một khuyến nghị để sửa.

## 6. On-Call Kit của Anthropic: triage prompt và skill

Tiếp theo là một repo mà Owain thấy rất thú vị từ Anthropic: [anthropics/oncall-kit](https://github.com/anthropics/oncall-kit), tức Anthropic On-Call Kit. Nếu bạn muốn xem, theo anh (video đăng ngày 05/10/2026) repo có vài tài nguyên rất hay, trong đó có các skill. Trong repo có một triage prompt và một skill. Bạn có thể lấy cảm hứng từ đó, và đây về cơ bản chính là thứ anh sẽ làm trong video.

![File skills/triage/SKILL.md trong repo anthropics/oncall-kit trên GitHub](https://homus.dev/photos/l6GpUvPOVpM-0503.jpg)

File `skills/triage/SKILL.md` trong repo oncall-kit, như Owain mở trong video (05/10/2026). Mục Procedure: nạp context từ `ONCALL.md`, `STACK.md` và `lessons.md`, rồi phân loại triệu chứng theo bảng (test hỏng, PR kẹt, job không chạy, deploy lỗi) để nạp file reference tương ứng.

Skill đó có mục đích điều tra một alert hay một incident ngay trong channel. Nó là một skill giúp agent tìm cách chẩn đoán và tìm ra cái gì đang sai trong một hệ thống phần mềm. Owain nói bạn có thể lấy nó làm cảm hứng, nhưng tất nhiên bạn sẽ muốn tùy chỉnh cho doanh nghiệp của mình, cho ứng dụng của mình, và bạn cũng phải tự nối tooling của riêng mình vào (lời khuyên của Owain trong video đăng ngày 05/10/2026).

README của repo (đọc ngày 23/10/2026) mô tả kit là bản tham khảo để đưa Claude vào channel incident của team: khi alert bắn, Claude điều tra và đăng chẩn đoán ban đầu, một người quyết định làm gì, và mỗi incident được ghi thêm vào `lessons.md`.

## 7. Kiến trúc: alert, queue, agent và web console

Rồi Owain chuyển sang architecture của thứ anh sẽ build trong video (đăng ngày 05/10/2026). Ý tưởng của hệ thống: bạn có một alert. Khi có gì đó hỏng trong production, ta sinh ra một alert, hoặc một metric hay trigger nào đó sẽ bắn alert. Ví dụ API trả lời chậm, hay có lỗi trong hệ thống, thì sẽ kích hoạt một alert. Ta gửi alert đó vào một queue, rồi chuyển xuống một AI agent.

![Sơ đồ ba tầng: Alert intake, Investigation, Recovery](https://homus.dev/photos/l6GpUvPOVpM-0523.jpg)

Sơ đồ architecture Owain dùng trong video (05/10/2026), ba tầng. Alert intake: Cloud Monitoring phát hiện lỗi, Pub/Sub chuyển alert, Backend lưu và xếp hàng cuộc điều tra. Investigation: Claude Agent SDK gọi Claude qua Vertex AI, các tool MCP chỉ đọc truy vấn log, metrics và lịch sử deploy, Web console hiện kết quả và bằng chứng. Recovery: Operator duyệt một đề xuất rollback cụ thể, Executor kiểm và áp thay đổi được phép, Verification thử checkout trên bản đích.

Trong trường hợp này, Claude Agent SDK lắng nghe queue rồi phản hồi bằng cách điều tra. Agent dùng các tool nó có để tìm trong log, xem metrics, xem lịch sử deploy, cố phân tích xem chuyện gì đang xảy ra trong hệ thống. Sau đó nó gửi kết quả lên một web console (theo cách Owain dựng hệ thống trong video đăng ngày 05/10/2026).

Web console cho phép chúng ta, những người vận hành (operator), thấy chuyện gì thật sự đang diễn ra. Rồi về cơ bản agent sẽ giúp ta khôi phục hệ thống. Theo Owain (video đăng ngày 05/10/2026), có hai hướng: hoặc agent tự hành động bằng cách sửa một thứ gì đó, ví dụ rollback ứng dụng của bạn; hoặc nó hỏi bạn, đưa bạn một khuyến nghị nên làm gì, rồi giúp bạn hành động để sửa.

## 8. Có nên để human in the loop không

Vì vậy, bạn thật sự phải nghĩ xem mình có muốn human in the loop (có người trong vòng lặp) hay không. Với những use case kiểu này, Owain nghĩ nhìn chung bạn nên để có người trong vòng lặp. Lý do anh đưa ra (video đăng ngày 05/10/2026): dù AI agent rất, rất mạnh, chúng thường nhảy tới kết luận sai. Nếu thấy một dữ liệu hay một tín hiệu nào đó, chúng có thể dồn trọng tâm vào tín hiệu đó quá mức (over-index).

Theo Owain, đây thật ra là một trong những lĩnh vực khó nhất để build AI agent nói chung, vì tìm ra lý do một hệ thống bị hỏng thật sự khá phức tạp. Bạn phải xem rất nhiều tín hiệu khác nhau, phải dùng khá nhiều trí tuệ và phán đoán. Nên anh nghĩ cách tốt nhất là kết hợp phán đoán của con người với khả năng scraping của agent, và đó là chỗ bạn có được nhiều đòn bẩy (leverage) nhất từ những hệ thống này (quan điểm của Owain trong video đăng ngày 05/10/2026).

Cách chia việc Owain đề xuất cho các hệ thống quan trọng (video đăng ngày 05/10/2026): agent lo phần tìm và gom dữ liệu, người giữ phần phán đoán và phê duyệt.

## 9. Hai cách dùng agent, và theo dõi một lần deploy

Theo Owain, có thể làm khá nhiều việc với agent này. Cách thứ nhất: agent tự lắng nghe một event rồi hành động. Nếu có gì đó hỏng giữa đêm, agent cứ thế sửa vấn đề cho bạn (cách anh mô tả hệ thống của mình trong video đăng ngày 05/10/2026).

Cách còn lại là dùng agent giống một trợ lý hơn. Bạn có thể hỏi agent những câu như "vì sao checkout đang lỗi, tìm trong log, tìm cho tôi bằng chứng", và việc này sẽ đẩy nhanh việc chẩn đoán. Theo Owain (video đăng ngày 05/10/2026), con người tự xem qua đống thông tin đó mất rất nhiều thời gian; nhớ xem phải nhìn ở đâu, mở dashboard nào, những việc đó cực kỳ tốn thời gian. Agent thì lấy được thông tin cho bạn rất, rất nhanh, nên thời gian phản ứng sẽ ngắn lại.

![Mục Sample prompts với ba khối Investigate, Monitor a deployment và Request recovery](https://homus.dev/photos/l6GpUvPOVpM-0651.jpg)

Mục "Sample prompts" trên trang tài liệu Owain mở (video đăng ngày 05/10/2026): một prompt điều tra, một prompt theo dõi deploy có giới hạn thời gian, và một prompt yêu cầu khôi phục, kèm ghi chú rằng khi bật recovery thì xem lại đích của đề xuất rồi bấm Approve hoặc Deny trong UI.

Ba prompt mẫu trên màn hình, chép nguyên văn:

```
Why is checkout failing? Check the logs and recent changes. Show the evidence and what remains uncertain.
```

```
Watch the next deployment for five minutes. Check checkout success, errors and latency. Investigate any regression and ask me before rolling back.
```

```
Rollback the change.
```

Agent cũng có thể làm những việc như theo dõi lần deploy của bạn. Khi bạn deploy phần mềm, có thể để một AI agent theo dõi lần rollout đó và giám sát trong vài phút. Ta có thể nói: theo dõi lần deploy kế tiếp trong năm phút, tìm lỗi và các lần latency tăng, điều tra mọi regression; nếu có vấn đề thì agent có thể hỏi bạn xem nó có được rollback thay đổi đó không (theo demo của Owain, video đăng ngày 05/10/2026).

Nói cách khác, theo Owain, bạn có thể dùng AI agent để giám sát production, nhưng cũng có thể dùng chúng để giám sát các lần rollout và deploy, và anh thấy điều đó rất, rất mạnh. Rồi nếu muốn rollback một thay đổi, về cơ bản ta chỉ cần bảo agent hành động và làm việc đó (video đăng ngày 05/10/2026).

Owain nói bạn có thể làm những hệ thống này mạnh tới mức nào tùy ý. Bạn có thể cho agent khả năng làm gần như mọi thứ, nhưng bạn phải tự đưa ra phán đoán: mình muốn trao cho các hệ thống agent này bao nhiêu quyền kiểm soát và tự chủ (autonomy) (quan điểm của Owain, video đăng ngày 05/10/2026).

## 10. Triage loop và file lessons.md

Một điều thú vị trong bài viết của team Anthropic là triage loop. Ý tưởng là ta có một on-call agent, tức "on-call Claude", và có thể đưa thông tin vào agent này theo nhiều cách khác nhau. Có thể có nhiều kênh alert khác nhau, như alert từ production. Cũng có thể là con người báo vấn đề: ví dụ trong một channel Slack, bạn muốn bảo agent đi điều tra một chuyện gì đó, như ứng dụng phản hồi chậm hơn, hoặc một khách hàng đang bực và báo một vấn đề. Theo Owain (video đăng ngày 05/10/2026), bạn có thể dùng AI agent để triage những vấn đề đó.

![Sơ đồ Every path lands in the same triage loop trong bài blog của Claude](https://homus.dev/photos/l6GpUvPOVpM-0814.jpg)

Sơ đồ "Every path lands in the same triage loop" trong bài blog của Claude mà Owain mở (video đăng ngày 05/10/2026): ba đường vào (alert channels, một người báo cáo, một incident được mở) cùng đi tới on-call Claude, nơi kiểm tiêu chí trong `oncall.md`; đủ ngưỡng thì gọi người trực (page the on-call), còn chờ được tới sáng thì ghi vào lessons.

Agent có thể đưa ra một trong hai quyết định. Hoặc nó page người trực on-call, tức escalate lên một người để người đó vào sửa. Hoặc nó lưu thông tin đó lại, ghi vào một file `lessons.md`. Owain rất thích ý tưởng này.

Ý tưởng là theo thời gian agent có thể nhận ra một số pattern, như khi bạn gặp cùng một outage hay cùng một root cause nhiều lần, điều mà theo anh rất phổ biến. Thường thì khi một công ty phần mềm gặp outage, theo Owain (video đăng ngày 05/10/2026), đó thường là cùng những chuyện lặp đi lặp lại. Nên khi agent ghi vào file `lessons.md`, agent có được một dạng bộ nhớ lâu dài (persistent memory), và điều đó sẽ cải thiện khả năng agent thật sự chẩn đoán được vấn đề trong production.

Mọi điều kỳ quặc mà công ty bạn có, mọi tribal knowledge về các incident trước đây, bạn có thể lưu vào file `lessons.md`, và agent sẽ giỏi dần lên theo thời gian (theo Owain, video đăng ngày 05/10/2026).

## 11. Demo 1: deploy một bản lỗi vào production

Rồi tới demo. Trạng thái ban đầu: không có alert nào đang bắn, production đang khỏe. Trên màn hình là UI của on-call agent; Owain nói anh tự build một web UI riêng để minh họa các ý tưởng này. Có thể chat với agent, và có thể thấy vài vấn đề trước đây đã được xử lý xong. Lúc này mọi thứ trong production đều ổn (trong demo của video đăng ngày 05/10/2026).

Việc anh sẽ làm trong demo (video đăng ngày 05/10/2026) là deploy một thay đổi lỗi, rồi xem agent theo dõi thay đổi đó và chẩn đoán cái gì sai. Anh đẩy một phiên bản ứng dụng có lỗi lên production, xem AI agent có tự phát hiện được không và có khôi phục được dựa trên những gì nó tìm thấy không. Trong terminal, lệnh anh chạy là:

```
uv run scripts/cloud/demo.py deploy-broken
```

![Production overview của web console on-call với 1 active incident](https://homus.dev/photos/l6GpUvPOVpM-1011.jpg)

Web console "on-call" Owain tự build cho demo (video đăng ngày 05/10/2026): Production overview báo "1 active incident", và incident "SRE demo checkout 5xx" đang ở trạng thái "Needs attention".

Lúc này có một incident đang diễn ra trong production. AI agent đã bắt đầu triage và đang xử lý nó. Vào phần metrics, có thể thấy một đỉnh lỗi khá rõ từ alert. Kéo xuống phần log, có một lỗi cấu hình thanh toán (payment configuration error) đang gây vấn đề; trên màn hình là dòng `PaymentConfigError: payment provider configuration is invalid`. Có khá nhiều traffic và rất nhiều lỗi 500 trong production. Có gì đó đã hỏng, và agent đã bắt đầu điều tra (diễn biến demo trong video đăng ngày 05/10/2026).

Bấm vào incident đang mở, có thể thấy on-call agent đã triage xong và đề xuất bước kế tiếp là rollback thay đổi. Nó đã đi qua log, rút ra mọi thông tin liên quan. Theo Owain (video đăng ngày 05/10/2026), agent kéo ra được dữ liệu giúp bạn chẩn đoán, và điều đó rất, rất hữu ích vì một người tự tìm thông tin này sẽ mất rất lâu: đi qua toàn bộ log, tìm đúng các thông báo lỗi, rất rất tốn thời gian. Anh bảo hãy hình dung chuyện này xảy ra lúc 3 giờ sáng khi bạn đang mệt.

![Trang điều tra SRE demo checkout 5xx với kết luận của on-call agent và cột Evidence](https://homus.dev/photos/l6GpUvPOVpM-1043.jpg)

Kết luận của on-call agent trong demo (05/10/2026): checkout sập hoàn toàn từ khi một revision mới lên, mọi request đều lỗi `PaymentConfigError` (HTTP 500 trên `POST /checkout`), kèm các mục Timing, Impact, Still failing và bước kế tiếp là gửi "rollback the change". Cột Evidence bên phải liệt kê log, số request và các deploy event mà agent đã đọc.

Theo Owain, agent tự tin rollback là cách sửa đúng (demo trong video đăng ngày 05/10/2026). Anh đọc lại lập luận: lỗi bắt đầu đúng lúc traffic chuyển phiên bản, và từ đó không có gì khác thay đổi. Trên màn hình, agent cũng ghi nó không phân biệt được lỗi do image mới hay do một thay đổi cấu hình, vì cả hai cùng đổi và nó không thấy được giá trị biến môi trường.

## 12. Duyệt rollback và nhìn error rate rơi xuống

Khá rõ là cần rollback thay đổi, nên Owain chỉ việc bảo agent làm: "roll back the change". Lúc này agent sẽ đưa ra một yêu cầu phê duyệt (approval). Theo Owain (video đăng ngày 05/10/2026), đây là chỗ bạn cần một dạng human in the loop. Nếu thật sự tự tin, trong vài trường hợp bạn có thể muốn agent tự hành động, nhưng với những việc như rollback phần mềm hay hành động trong production, có một cơ chế phê duyệt là rất, rất hữu ích.

Trên màn hình, đề xuất là rollback từ phiên bản lỗi về phiên bản khỏe đang chạy trước đó, và anh bấm duyệt. Nhìn lại đồ thị, có thể thấy rất rõ error rate đã giảm. Có vẻ rollback đã hoàn tất. Alarm vẫn đang mở, và sẽ mất một lúc để nó hồi phục.

![Google Cloud Monitoring: alert Shop 5xx above 0.2/s for 60s, đồ thị lỗi rơi thẳng xuống sau rollback](https://homus.dev/photos/l6GpUvPOVpM-1203.jpg)

Trang alert "Shop 5xx above 0.2/s for 60s" trên Google Cloud Monitoring trong demo (05/10/2026): đường request lỗi đứng ở khoảng 3/s rồi rơi thẳng xuống dưới ngưỡng 0,2/s sau khi rollback, trong khi alert vẫn hiện "Alert open". Mục Documentation ghi "Human rollback only".

Nhưng theo Owain, nhìn mức giảm error rate khá ngoạn mục này thì có vẻ hệ thống đã quay về trạng thái khỏe, và kết quả trông tốt (kết quả demo trong video đăng ngày 05/10/2026).

## 13. Demo 2: không có gì hỏng, chỉ chậm

Demo kế tiếp là ca khách hàng báo latency cao hơn. Owain có một phiên bản ứng dụng chạy chậm hơn: latency, tức thời gian phản hồi của ứng dụng, đã tăng lên. Nghĩa là với khách hàng mọi thứ chậm hơn, nhưng không có gì thật sự hỏng. Ứng dụng vẫn chạy, chỉ là phản hồi rất, rất chậm.

Việc có thể làm, theo demo của Owain (video đăng ngày 05/10/2026), là mở một cuộc chat với agent rồi cùng điều tra. Ta có thể hỏi những câu như: trong 24 giờ qua phục vụ bao nhiêu request, chia theo mã response, và cho tôi các mốc thời gian cùng mọi giới hạn của số liệu. Owain nói anh chỉ đang triage một chút để xem có tìm ra vì sao ứng dụng đang chậm không.

Cũng có thể làm việc như xem timeline các lần deploy hôm nay, để xem incident có liên quan tới một lần deploy gần đây không (cách Owain dùng agent trong demo, video đăng ngày 05/10/2026). Prompt anh gửi trên màn hình:

```
Build a short timeline of today's deployments, checkout failures and recovery. Name the serving revisions and distinguish observed facts from assumptions.
```

![Kết luận của on-call agent về checkout chậm khoảng 3.000 ms](https://homus.dev/photos/l6GpUvPOVpM-1303.jpg)

Trả lời của on-call agent ở demo thứ hai (video đăng ngày 05/10/2026): checkout chậm từ khi một revision mới được deploy, mỗi request checkout mất khoảng 3.000 ms nhưng vẫn trả 200. Agent ghi nó không tự sửa được vì quyền của nó chỉ đọc (read-only), nhưng bạn có thể bắt đầu một rollback; nguyên nhân (độ tin cậy trung bình-cao) trông giống một độ trễ cố định như setting `LATENCY_MS`.

Có thể thấy on-call agent đã tìm ra checkout bị chậm từ lần deploy gần nhất, và mỗi request mất khoảng 3.000 mili giây (kết quả agent báo trong demo của video đăng ngày 05/10/2026). Việc có thể làm là rollback, giống lần trước. Nhưng Owain nói bạn có thể hình dung nếu đây là một ứng dụng production thật, bạn có thể muốn chọn một hành động khác, như scale API của mình chẳng hạn.

## 14. Bên trong code: runner.py và Claude Agent SDK

Nếu bạn quan tâm, Owain mở codebase của agent. Có nhiều file khác nhau, nhưng file chính là `runner.py`: đây là AI agent thật sự. File này dùng Claude Agent SDK. Theo cách Owain giải thích (video đăng ngày 05/10/2026), Claude Agent SDK cho phép build một agent giống Claude Code: về cơ bản nó dùng nền tảng của Claude Code, nhưng cho phép bạn thêm tool riêng, tùy chỉnh riêng, và viết agent của mình dưới dạng code. Trang tài liệu chính thức (đọc ngày 23/10/2026) mô tả Agent SDK là cung cấp cùng các tool, agent loop và cách quản lý context đứng sau Claude Code, lập trình được bằng Python và TypeScript.

Ở đầu `runner.py` trên màn hình (05/10/2026), file import từ `claude_agent_sdk` các thành phần như `ClaudeAgentOptions`, `ClaudeSDKClient`, `HookMatcher`, `PermissionResultDeny`, `create_sdk_mcp_server` và `tool`, rồi khai báo danh sách tool được phép:

```
TOOL_NAMES = ("read_logs", "read_metrics", "read_revisions", "read_deploy_events")
ALLOWED = [f"mcp__gcp__{name}" for name in TOOL_NAMES]
```

Kèm theo là một hàm `deny_unknown` trả về `PermissionResultDeny` với thông báo rằng chỉ những read tool được duyệt rõ ràng mới được dùng.

![runner.py trong editor với các tool read_metrics, read_revisions, read_deploy_events](https://homus.dev/photos/l6GpUvPOVpM-1343.jpg)

Phần định nghĩa tool trong `runner.py` của Owain (video đăng ngày 05/10/2026): mỗi tool như `read_metrics`, `read_revisions`, `read_deploy_events` được khai báo bằng decorator `@tool` kèm mô tả, ví dụ đọc số request của Cloud Run trong khoảng 5 tới 1440 phút, và đọc mốc thời gian audit của deploy "not secret configs".

Có thể thấy ở đây một loạt tool mà agent dùng được. Agent đọc được log, đọc được metrics, và làm được những việc như xem các deploy event. Theo Owain (video đăng ngày 05/10/2026), bạn thật sự nên nghĩ kỹ về những tool bạn trao cho agent. Ví dụ bạn có thể build một tool để rollback một thay đổi.

Bạn có thể build bất kỳ loại tool nào để giúp agent giảm thiểu hay giải quyết một incident. Nên, theo Owain, chất lượng của agent thường quy về chất lượng của các tool bạn thật sự trao cho chúng (quan điểm của anh trong video đăng ngày 05/10/2026). Điểm hay của việc viết bằng code là bạn có thể rất cẩn thận: bạn đảm bảo được agent chỉ có những quyền cụ thể, và có thể kiểm tra nhiều thứ để chắc rằng các thao tác agent làm là an toàn.

## 15. Kiến trúc tổng thể và việc agent theo dõi rollout

Owain mở lại high-level architecture của thứ anh build, trong file `ARCHITECTURE.md`. Anh nói nó thật ra khá đơn giản, và sơ đồ có lẽ hơi nhỏ để đọc. Ý chung: ta nhận một thông báo, hoặc một alert xảy ra trong hệ thống. Có gì đó hỏng, ta kích hoạt một alert; theo Owain (video đăng ngày 05/10/2026), phần lớn các cloud platform cho phép bạn sinh alert khi có gì đó hỏng. Ta gửi alert đó vào một queue, rồi có một AI agent triage và bắt đầu điều tra vấn đề.

Agent đi tới một kết luận, rồi ghi kết quả ngược vào một database. Còn có một web UI để ta thật sự vào xem chuyện gì đang diễn ra. Ta nói chuyện được với agent, trao đổi qua lại với nó, và theo Owain (video đăng ngày 05/10/2026) điều đó sẽ rất hữu ích khi chẩn đoán vấn đề. Trên màn hình, phần Executive summary của file ghi rằng model chỉ có bốn read tool, và một thay đổi production phải xuất phát từ yêu cầu và phê duyệt rõ ràng của operator.

Kiến trúc tổng thể theo lời Owain (video đăng ngày 05/10/2026): alert vào queue, agent điều tra rồi ghi kết quả vào database, web UI cho người vận hành xem và chat với agent; thêm một nhánh cho agent theo dõi một lần rollout.

Một ý tưởng rất thú vị khác Owain muốn có cho SRE agent này là khả năng để agent theo dõi hay giám sát một lần rollout. Trong một video trước, anh đã nói về các ý tưởng software factory của OpenAI; theo Owain (video đăng ngày 05/10/2026), họ dùng một hệ thống tương tự, về cơ bản là để một agent giám sát rollout. Khi bạn deploy phần mềm, bạn có thể bảo agent giám sát nó: chỉ cần vào console và nói đại loại "watch the next deployment for five minutes". Agent sẽ theo dõi và để ý; nếu có gì hỏng, bạn có thể nói chuyện với agent, hoặc agent có thể hành động để sửa.

Trên màn hình là file `deployment-watch.md` của project, mục "Watch a deployment from chat". File ghi console có thể đặt một lần theo dõi lâu dài, chỉ đọc, cho ứng dụng Cloud Run đã cấu hình, và "There is no automatic rollback". Các lệnh liệt kê trong file (chép từ màn hình, video đăng ngày 05/10/2026):

```
Watch the next deployment for five minutes.

Watch this deployment for five minutes.

Watch the next deployment for five minutes. Check checkout success, errors and latency. Investigate any regression and ask me before rolling back.
```

Owain nghĩ đây là thứ rất hữu ích nếu bạn build phần mềm, nhất là khi build phần mềm ở quy mô lớn: có một agent giám sát các lần rollout là một thứ có thì tốt (nhận định của anh trong video đăng ngày 05/10/2026).

## 16. Vì sao quan trọng, và giới hạn của agent

Owain nghĩ những hệ thống này thật sự quan trọng. Khi chúng ta dùng ngày càng nhiều code do AI sinh ra, khi chúng ta đi nhanh hơn, chúng ta deploy nhiều thay đổi hơn và thường xuyên hơn. Theo anh (video đăng ngày 05/10/2026), có những hệ thống AI như thế này là rất, rất quan trọng. Nếu bạn là doanh nghiệp bán phần mềm, nếu bạn vận hành phần mềm có khách hàng thật, có thứ như thế này sẽ giúp bạn rất nhiều.

Con người giỏi ra quyết định, nhưng đi tìm dữ liệu và thông tin lúc 4 giờ sáng khi đang mệt thì thật ra khá căng thẳng và cực kỳ khó. Nên theo Owain (video đăng ngày 05/10/2026), nếu bạn trao cho các kỹ sư của mình một AI agent giúp họ chẩn đoán nhanh hơn, tìm thông tin và gợi ý các bước kế tiếp, nó sẽ giảm rất mạnh thời gian xử lý xong một incident.

Anh gọi đây là một ví dụ tuyệt vời về một agent mang lại giá trị rất lớn, nhưng nó cũng cho thấy một số giới hạn của AI agent nói chung. Theo Owain (video đăng ngày 05/10/2026), agent thường nhảy tới kết luận, nên bạn phải rất cẩn thận khi dựa quá nhiều vào những gì chúng nói. Thường thì chúng sẽ tìm được thông tin bạn cần, nhưng có thể chúng hiểu sai dữ liệu, hoặc đi tới một kết luận sai.

Vì vậy bạn vẫn phải rất cẩn thận, và theo anh, điều đó cho thấy bạn vẫn cần human in the loop với những hệ thống thật sự quan trọng như thế này. Nhưng nhìn chung, Owain thấy đây là một use case tuyệt vời, và là một trong những ví dụ anh thích nhất về hệ thống AI tự động (quan điểm của anh trong video đăng ngày 05/10/2026).

Anh mời người xem để lại câu hỏi ở phần bình luận, cảm ơn mọi người đã xem và hẹn gặp ở video sau.

## Nguồn và liên kết

- Tên gốc: I Built A Claude DevOps Agent To Run My Software Factory
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=l6GpUvPOVpM](https://www.youtube.com/watch?v=l6GpUvPOVpM)

- Kênh YouTube Owain Lewis (Owain Lewis): [youtube.com/channel/UC08YjBHjjPFu8T1KbHGomnQ](https://www.youtube.com/channel/UC08YjBHjjPFu8T1KbHGomnQ)

- Claude Agent SDK, trang tổng quan trong tài liệu chính thức (đọc ngày 23/10/2026): [code.claude.com/docs/en/agent-sdk/overview](https://code.claude.com/docs/en/agent-sdk/overview)

- Bài blog của Claude "Claude on call: How Claude Tag serves as Anthropic's first responder for CI/CD failures" (đọc ngày 23/10/2026): [claude.com/blog/ai-ci-cd-on-call](https://claude.com/blog/ai-ci-cd-on-call)

- Repo On-Call Kit của Anthropic, có triage skill và `lessons.md` (đọc ngày 23/10/2026): [github.com/anthropics/oncall-kit](https://github.com/anthropics/oncall-kit)

- Bài blog Google Cloud "How Google SRE is using agentic AI to improve operations" (đọc ngày 23/10/2026): [cloud.google.com/blog/products/devops-sre/how-google-sre-is-using-agentic-ai-to-improve-operations](https://cloud.google.com/blog/products/devops-sre/how-google-sre-is-using-agentic-ai-to-improve-operations)

Nguồn: https://homus.dev/talks/i-built-a-claude-devops-agent-to-run-my-software-factory · cập nhật 2026-10-23