Một dòng ERROR thực ra không hề nhỏ

Không có lỗi nào chỉ là một dòng chữ màu đỏ.

Giả sử lúc 2 giờ 13 phút sáng, một service đang chạy bình thường bỗng ném ra:

1NullPointerException at OrderService.java:142

Nếu nhìn bằng mắt người bình thường, đây chỉ là vài chục ký tự.

Nhưng phía sau mấy chục ký tự ấy có thể là cả một đoàn tàu vừa trật bánh.

Một request đi vào load balancer, chạy qua API, nhảy sang một service khác, gọi database, chạm Redis, gọi một API thanh toán, nhận về một giá trị kỳ quặc, rồi ở đâu đó trong hàng nghìn dòng code có một anh lập trình viên — rất có thể là chính chúng ta sáu tháng trước — quên kiểm tra null.

Server không biết buồn.

Nó chỉ viết:

1ERROR

rồi tiếp tục sống.

Con người mới là người phải đau khổ.

Kỹ sư nhận alert, mở CloudWatch, tìm đúng log stream, kéo lên vài chục dòng, kéo xuống vài chục dòng, đọc stack trace, mở GitHub, tìm file, tìm dòng code, xem hàm này gọi hàm nào, rồi cố dựng lại trong đầu:

Chuyện quái gì vừa xảy ra?

Đó chính là Root Cause Analysis (RCA).

Monitoring thường trả lời được:

Cái gì đang cháy?

Nhưng RCA phải trả lời một câu khó hơn:

Vì sao nó cháy?

Ngày 7/8/2026, AWS đăng một case study khá thú vị của TReNDS Center về cách họ biến quá trình này thành một pipeline gần như tự động bằng Amazon CloudWatch, Lambda, Amazon Bedrock và Strands Agents SDK. Hệ thống đang được TReNDS sử dụng trong production. (Amazon Web Services, Inc.)

Điều đáng nói không nằm ở việc họ “đưa log cho LLM đọc”.

Nếu chỉ làm thế thì khá chán.

Điểm thú vị là họ cho AI quyền đi điều tra.

Alert và điều tra là hai việc khác nhau

TReNDS, viết tắt của Center for Translational Research in Neuroimaging and Data Science, vận hành nhiều ứng dụng nghiên cứu và API trên Amazon EKS. Log từ các workload được Fluent Bit chuyển vào Amazon CloudWatch. Hạ tầng này đã chạy trên AWS từ năm 2019. (Amazon Web Services, Inc.)

Monitoring của họ vốn không thiếu.

Khi hệ thống lỗi, họ biết.

Nhưng biết một căn nhà đang cháy và biết cái ổ điện nào đã phát tia lửa là hai chuyện rất khác nhau.

Quy trình cũ đại khái như thế này:

 1Alert
 2  ↓
 3Engineer mở CloudWatch
 4  ↓
 5Tìm stack trace
 6  ↓
 7Đọc log trước và sau lỗi
 8  ↓
 9Mở GitHub
10  ↓
11Tìm file liên quan
12  ↓
13Đọc code
14  ↓
15Lần theo execution path
16  ↓
17Đưa ra giả thuyết
18  ↓
19Root Cause

Theo TReNDS, những lỗi tương đối đơn giản cũng có thể mất khoảng 15–30 phút điều tra. Những lỗi liên quan nhiều service có thể lâu hơn đáng kể. (Amazon Web Services, Inc.)

Vấn đề nằm ở chỗ phần lớn 15–30 phút đó không phải lúc nào cũng cần một bộ não thiên tài.

Kỹ sư đang làm những việc rất cơ học:

• lấy thêm log;
• tìm file;
• mở đúng dòng;
• đọc stack trace;
• tìm hàm được gọi;
• tìm error message trong repository;
• nối các mẩu thông tin lại với nhau.

Nói hơi kỳ một chút, chúng ta đang dùng một kỹ sư có nhiều năm kinh nghiệm như một con trỏ chuột biết suy nghĩ.

Và đây là nơi AI Agent bắt đầu hợp lý.

Đừng đưa log cho LLM, hãy đưa cho nó một chiếc kính lúp

Có một cách rất đơn giản để dùng AI cho incident:

1ERROR
2  ↓
3LLM
4  ↓
5"Nguyên nhân có thể là..."

Cách này nhìn rất thông minh trong demo.

Nhưng ở production thì có một vấn đề.

LLM chỉ biết những gì chúng ta đưa vào prompt.

Nếu prompt chỉ có:

1NullPointerException at OrderService.java:142

thì nó cũng giống một bác sĩ chỉ được nghe:

Bệnh nhân đau bụng.

Sau đó phải đoán bệnh.

Có thể đoán đúng.

Cũng có thể bệnh nhân chỉ ăn sáu tô bún bò.

TReNDS chọn kiến trúc khác.

Họ cho model các tool để nó tự đi lấy bằng chứng.

Kiến trúc tổng quát:

 1Application
 2    ↓
 3Amazon EKS
 4    ↓
 5Fluent Bit
 6    ↓
 7CloudWatch Logs
 8    ↓
 9Subscription Filter
10    ↓
11AWS Lambda
12    ↓
13Strands Agent
14    ↓
15Amazon Bedrock
16   ↙        ↘
17Logs       GitHub
18context    source code
19    ↘       ↙
20   Reasoning
21       ↓
22Root Cause Analysis
23       ↓
24Amazon SNS
25       ↓
26Email / Slack

CloudWatch subscription filter theo dõi những pattern như:

1ERROR
2Exception
3FATAL
4CRITICAL

Khi một event phù hợp xuất hiện, dữ liệu được chuyển sang Lambda. Subscription filter của CloudWatch được thiết kế để chuyển các log event phù hợp sang các destination như Lambda hoặc Kinesis gần thời gian thực. (AWS Documentation)

Lambda sau đó khởi chạy một Strands Agent sử dụng model trên Amazon Bedrock.

Nhưng đây mới chỉ là lúc cuộc điều tra bắt đầu.

Agent không phải một prompt dài

Một trong những ý mình thích nhất trong kiến trúc này là họ không cố nhét cả thế giới vào context window.

Agent được cung cấp một số công cụ.

Ví dụ:

1fetch_log_context()
2fetch_source_code()
3search_github_code()

Rồi model tự quyết định lúc nào cần dùng cái gì.

Trong Strands, một Python function bình thường có thể được biến thành tool bằng decorator @tool. Docstring và type hint được dùng để mô tả chức năng cũng như schema tham số cho model. (Strands Agents SDK)

Ví dụ đơn giản:

 1from strands import tool
 2
 3@tool
 4def fetch_source_code(file_path: str, repo: str) -> str:
 5    """
 6    Lấy source code từ repository.
 7
 8    Args:
 9        file_path: đường dẫn file cần đọc
10        repo: repository cần truy cập
11    """
12    ...

Nhìn thì chẳng có gì ghê gớm.

Nhưng sự thay đổi nằm ở quyền chủ động.

Thay vì chương trình viết cứng:

1read_log()
2read_file_a()
3read_file_b()
4search_keyword()

ta nói:

1Đây là lỗi.
2
3Đây là những công cụ anh có.
4
5Điều tra đi.

Model trở thành nơi quyết định bước tiếp theo của quá trình điều tra.

Đây chính là khác biệt giữa một workflow cố định và agentic workflow.

Chiếc đèn pin đầu tiên: lấy thêm log

Một dòng error thường không đủ.

Giả sử log có dạng:

110:21:01 Received payment request
210:21:02 Calling payment gateway
310:21:04 Gateway timeout
410:21:04 Retry failed
510:21:05 payment_response=None
610:21:05 NullPointerException

Nếu chúng ta chỉ gửi dòng cuối:

1NullPointerException

model nhìn thấy cái xác nhưng không nhìn thấy hiện trường.

TReNDS vì thế xây một tool để lấy log xung quanh thời điểm xảy ra lỗi.

Đại khái:

1@tool
2def fetch_log_context(
3    log_group: str,
4    log_stream: str,
5    timestamp: int,
6    window_seconds: int = 30
7):
8    ...

Agent có thể lấy khoảng thời gian trước và sau error, ví dụ ±30 giây.

Quan trọng hơn, họ giới hạn truy vấn trong cùng log stream.

Điều đó giúp tránh một nồi lẩu log từ hàng chục container chạy song song.

Khi ấy AI có thể nhìn thấy một chuỗi sự kiện tương đối sạch:

1request
2↓
3warning
4↓
5timeout
6↓
7retry
8↓
9exception

Từ một tấm ảnh chụp cái xác, nó bắt đầu có camera an ninh.

Theo kiến trúc TReNDS, CloudWatch event chứa thông tin logStream, cho phép agent lấy thêm những dòng log của đúng container đã phát sinh lỗi. (Amazon Web Services, Inc.)

Chiếc đèn pin thứ hai: mở source code

Đây mới là đoạn mình thấy đáng học nhất.

Stack trace nói:

1OrderService.java:142

Agent không ngồi tưởng tượng dòng 142 có gì.

Nó gọi:

1fetch_source_code(
2    "src/services/OrderService.java"
3)

Sau đó đọc code thật.

Ví dụ nó tìm thấy:

1PaymentResponse response =
2    paymentGateway.charge(order);
3
4String transactionId =
5    response.getTransactionId();

Trong log trước đó lại có:

1payment_response=None

Bây giờ câu chuyện gần như tự nối lại:

1Payment gateway timeout
2        ↓
3charge() trả null
4        ↓
5response không được kiểm tra
6        ↓
7getTransactionId()
8        ↓
9NullPointerException

Đây không còn là:

AI đoán nguyên nhân lỗi.

Mà gần hơn với:

AI thu thập bằng chứng rồi suy luận nguyên nhân lỗi.

Hai câu nhìn khá giống nhau.

Nhưng về mặt engineering, chúng cách nhau rất xa.

Agent có thể lần theo code như một kỹ sư

Giả sử dòng lỗi nằm ở:

1checkout.py

Agent mở file và thấy:

1payment = process_payment(order)

Nó chưa có câu trả lời.

Nó tiếp tục tìm process_payment().

Sau đó phát hiện:

1return payment_gateway.charge(...)

Nó lại mở implementation của payment_gateway.

Rồi có thể phát hiện bug nằm sâu hơn.

Con đường điều tra lúc này có thể là:

 1Stack trace
 2   ↓
 3checkout.py
 4   ↓
 5process_payment()
 6   ↓
 7payment_gateway.py
 8   ↓
 9retry()
10   ↓
11HTTP timeout
12   ↓
13None
14   ↓
15missing null check

Điểm quan trọng là con đường này không cần được lập trình viên viết trước.

Theo AWS, nếu việc đọc file đầu tiên cho thấy lỗi nằm trong shared utility hoặc dependency khác, agent có thể tiếp tục lần theo chuỗi đó. Nếu stack trace không đủ thông tin, agent cũng có thể tìm error string trong codebase. (Amazon Web Services, Inc.)

Đó là thứ workflow kiểu:

1if error A → làm B
2if error C → làm D

rất khó bao phủ hết.

Production có một tài năng đặc biệt.

Nó luôn tìm ra loại lỗi mà chúng ta chưa viết if.

System Prompt thực ra khá đơn giản

Một điều khác đáng chú ý là system prompt của TReNDS không phải một cuốn kinh dài 14 trang.

Tinh thần của nó chỉ là:

 1Bạn là một Senior Site Reliability Engineer.
 2
 31. Xác định root cause từ stack trace.
 42. Đọc source code liên quan.
 53. Trả về:
 6
 7- Severity
 8- Root cause
 9- Source code liên quan
10- Suggested fix
11- Những vùng khác có thể bị ảnh hưởng

Chiến lược điều tra không bị hard-code.

Prompt quy định:

Tôi muốn kết quả trông như thế nào.

Tool quy định:

Anh có thể làm gì.

Model quyết định:

Tôi nên làm gì tiếp theo.

Đây là một cách chia trách nhiệm khá đẹp:

 1Prompt
 2→ mục tiêu + luật chơi
 3
 4Tools
 5→ khả năng tác động vào thế giới
 6
 7LLM
 8→ suy luận + lựa chọn hành động
 9
10Code truyền thống
11→ authentication + permission + validation + execution

Một agent production tốt không phải là LLM được quyền làm mọi thứ.

Nó là LLM đứng giữa những cánh cửa rất nhỏ.

Mỗi cánh cửa chỉ mở đúng một việc.

Tại sao tool càng nhỏ càng tốt?

Hãy tưởng tượng ta cho agent một tool:

1execute_anything(command)

Thế là xong.

Agent quyền năng như Thanos.

Và đội security bắt đầu mất ngủ.

Một thiết kế hợp lý hơn là:

1fetch_log_context()
2fetch_source_code()
3search_repository()
4query_metrics()
5get_deployment_info()

Mỗi tool có input rõ ràng.

Mỗi tool có permission rõ ràng.

Agent được tự do suy nghĩ, nhưng khả năng hành động vẫn bị giới hạn bởi hệ thống.

Đây là nguyên tắc rất quan trọng khi đưa agent vào production:

Đừng cố kiểm soát mọi suy nghĩ của model. Hãy kiểm soát những thứ nó có thể chạm vào.

Strands hỗ trợ custom Python functions, MCP server và các loại tool khác để xây lớp khả năng này cho agent. (Strands Agents SDK)

Một incident từ đầu tới cuối

Giả sử lúc 10:21 hệ thống xuất hiện:

1ERROR
2NullPointerException
3OrderService.java:142

Bước 1: CloudWatch bắt được lỗi

Subscription filter phát hiện:

1ERROR

và gửi event sang Lambda.

Bước 2: Lambda giải mã event

CloudWatch gửi payload dạng gzip nén và base64 encode.

Lambda lấy ra:

1log_group
2log_stream
3timestamp
4error_message

Bước 3: Agent bắt đầu điều tra

Model thấy:

1OrderService.java:142

Nó gọi:

1fetch_log_context()

và nhận:

1Payment gateway timeout
2Retry failed
3payment_response=None
4NullPointerException

Bước 4: Agent mở source code

Nó gọi:

1fetch_source_code(
2    "OrderService.java"
3)

và tìm thấy:

1response.getTransactionId()

mà không có kiểm tra response == null.

Bước 5: Agent tìm thêm

Có thể nó search repository và phát hiện:

1RefundService.java:89

cũng có pattern tương tự.

Bước 6: Kết luận

Kết quả gửi về có dạng:

 1Severity: HIGH
 2
 3Root Cause:
 4Payment gateway có thể trả null khi timeout.
 5OrderService không kiểm tra null trước khi
 6gọi getTransactionId().
 7
 8Suggested Fix:
 9Thêm null check và xử lý retry/fallback.
10
11Related Areas:
12RefundService có pattern tương tự.

Bước 7: SNS gửi thông báo

Kết quả cuối cùng có thể được fan-out qua email hoặc Slack. Đây chính là flow production được TReNDS mô tả. (Amazon Web Services, Inc.)

Kỹ sư mở điện thoại lên.

Thay vì:

1PRODUCTION ERROR!!!

họ nhận được:

 1Production lỗi.
 2
 3Nó lỗi ở đây.
 4
 5Khả năng cao vì cái này.
 6
 7Đây là đoạn code.
 8
 9Có thể sửa như thế này.
10
11À, file kia cũng có nguy cơ tương tự.

Alert bỗng nhiên từ một tiếng chuông báo cháy biến thành một anh kỹ sư trực đêm đã chạy xuống tầng hầm xem thử khói phát ra từ đâu.

Từ 30 phút xuống dưới 60 giây

Theo TReNDS, sau khi triển khai hệ thống, thời gian investigation giảm từ khoảng 15–30 phút xuống dưới 60 giây. (Amazon Web Services, Inc.)

Đây là con số đáng chú ý.

Nhưng mình nghĩ điều quan trọng hơn không phải:

130 phút → 1 phút

Mà là bản chất của 29 phút biến mất.

Trước đây:

1Engineer
2├── tìm log
3├── tìm context
4├── tìm source
5├── đọc file
6├── search repository
7└── nối thông tin

Sau này:

 1Agent
 2├── tìm log
 3├── tìm context
 4├── tìm source
 5├── đọc file
 6├── search repository
 7└── nối thông tin
 8
 9Engineer
10└── kiểm tra kết luận

Con người được đẩy lên một tầng abstraction cao hơn.

Giống compiler đã giải phóng chúng ta khỏi việc tự viết assembly cho từng phép cộng.

Agent không nhất thiết thay kỹ sư SRE.

Nó lấy bớt phần đi bộ giữa các hệ thống ra khỏi công việc của SRE.

Nhưng có một vấn đề rất đời thường: cùng một lỗi có thể la hét 10.000 lần

Production có một thói quen xấu.

Một bug xảy ra không nhất thiết gửi một error.

Nó có thể gửi:

1ERROR
2ERROR
3ERROR
4ERROR
5ERROR
6ERROR
7...

Nếu mỗi ERROR gọi một LLM Agent, chúng ta vừa phát minh ra một cỗ máy đổi exception thành hóa đơn.

TReNDS giải quyết chuyện này bằng deduplication sử dụng DynamoDB: sau release, nếu cùng code path tiếp tục tạo ra error lặp lại, chỉ occurrence đầu tiên cần kích hoạt phân tích; các lần sau được lọc đi. (Amazon Web Services, Inc.)

Ý tưởng này cực kỳ quan trọng.

Agentic architecture không nên là:

1Event
2→ LLM

Mà nên gần với:

 1Event
 2   ↓
 3Filter
 4   ↓
 5Normalize
 6   ↓
 7Fingerprint
 8   ↓
 9Deduplicate
10   ↓
11Priority
12   ↓
13Agent

Không phải mọi tiếng động trong nhà đều cần gọi Sherlock Holmes.

Có lúc chỉ là con mèo làm rơi cái muỗng.

Có thể fingerprint lỗi như thế nào?

Giả sử hệ thống nhận:

1NullPointerException
2OrderService.java:142
3request_id=abc123
4user_id=7788

và vài giây sau:

1NullPointerException
2OrderService.java:142
3request_id=def456
4user_id=9981

Request khác nhau.

User khác nhau.

Nhưng về bản chất có thể cùng một lỗi.

Ta có thể normalize thành:

1NullPointerException
2OrderService.java:142

rồi tạo fingerprint:

1import hashlib
2
3def incident_fingerprint(error_type, file, line):
4    text = f"{error_type}:{file}:{line}"
5    return hashlib.sha256(text.encode()).hexdigest()

Sau đó:

1fingerprint
2    ↓
3DynamoDB / Redis
4    ↓
5đã phân tích?
6 ┌──┴──┐
7yes    no
8 ↓      ↓
9skip   Agent

Trong production thực tế chắc chắn phức tạp hơn.

Nhưng ý chính vẫn vậy:

AI đắt nhất khi chúng ta bắt nó suy nghĩ lại thứ nó vừa suy nghĩ xong.

Không phải error nào cũng cần Sonnet

TReNDS cũng thử nhiều model khác nhau trên Amazon Bedrock và đánh giá chúng dựa trên các tiêu chí như khả năng reasoning về code, độ tin cậy khi sử dụng tool, latency và chi phí. Họ chọn Claude Sonnet làm model chính cho workload này. (Amazon Web Services, Inc.)

Nhưng phần thú vị hơn nằm ở hướng phát triển tiếp theo.

Không nhất thiết:

1mọi lỗi
2   ↓
3model mạnh

Ta có thể làm:

1                    ┌→ known / simple → model nhỏ
2ERROR → classifier ─┤
3                    └→ complex / novel → model mạnh

Ví dụ:

1Connection timeout
2Known pattern
3Confidence = 0.99

không nhất thiết phải triệu hồi một model reasoning lớn.

Trong khi:

1race condition
2+
33 services
4+
5distributed transaction
6+
76 files

lại là chuyện khác.

TReNDS cho biết họ đang nghiên cứu chiến lược tiered model: lỗi đơn giản có thể đi qua model nhẹ hơn, còn lỗi mới hoặc phức tạp được chuyển sang Sonnet để phân tích sâu hơn. (Amazon Web Services, Inc.)

Đây cũng là một pattern đáng nhớ khi triển khai LLM:

Model routing thường quan trọng không kém model selection.

Amazon Bedrock hiện cung cấp nhiều foundation model thông qua một lớp dịch vụ chung, vì vậy kiến trúc ứng dụng có thể thay đổi model mà không phải viết lại toàn bộ hệ thống agent. Danh sách model và khả năng hỗ trợ vẫn tiếp tục thay đổi theo thời gian. (AWS Documentation)

Bước tiếp theo sẽ là Runbook

Hãy tưởng tượng agent phát hiện:

1Redis connection exhausted

Source code giúp nó hiểu lỗi.

Log giúp nó hiểu chuyện gì vừa xảy ra.

Nhưng trong công ty thường còn một thứ khác:

1runbooks/
2├── redis-connection-exhausted.md
3├── database-lag.md
4├── payment-timeout.md
5└── kubernetes-oom.md

Đây là ký ức của tổ chức.

Một kỹ sư lâu năm gặp lỗi Redis có thể nói:

À lỗi này năm ngoái từng dính rồi. Đừng restart bừa. Kiểm tra connection pool trước.

Người mới thì không biết.

AI cũng không biết.

Trừ khi ta cho nó đọc.

TReNDS vì thế đang nghiên cứu kết nối Amazon Bedrock Knowledge Bases với runbook nội bộ và các incident report cũ. (Amazon Web Services, Inc.)

Lúc đó hệ thống bắt đầu có ba loại trí nhớ:

1Logs
2→ chuyện vừa xảy ra
3
4Source code
5→ hệ thống hiện đang hoạt động thế nào
6
7Runbook + incidents
8→ chúng ta từng học được gì

Khi ba thứ này gặp nhau, RCA mới thực sự thú vị.

Và rồi đến GitHub Issue, thậm chí Pull Request

Con đường tiếp theo gần như tự nhiên:

 1Detect
 2↓
 3Investigate
 4↓
 5Root Cause
 6↓
 7Suggest Fix
 8↓
 9Create Issue
10↓
11Create PR
12↓
13Test
14↓
15Human Review
16↓
17Merge

TReNDS cho biết họ cũng đang hướng tới việc tự động tạo GitHub issue và pull request khi agent xác định được một cách sửa tiềm năng. (Amazon Web Services, Inc.)

Nghe đến đây rất dễ bị phấn khích rồi nối tiếp:

1Agent tự merge
2↓
3Agent tự deploy
4↓
5Agent tự phá production lần hai

Thôi.

Ta nên phân biệt rất rõ:

1Read

và:

1Write

Một agent chỉ có quyền:

1read logs
2read metrics
3read source

có blast radius tương đối thấp.

Agent có quyền:

1modify code
2merge PR
3restart pod
4rollback deployment
5change database

là một sinh vật hoàn toàn khác.

Càng tiến gần hệ thống production, mỗi bước nên có permission, policy, validation và human approval tương ứng.

AI có thể rất thông minh.

Nhưng DROP TABLE vẫn chạy ở tốc độ của database, không chạy ở tốc độ suy nghĩ của AI.

Nếu tự xây một hệ thống tương tự, mình sẽ chia thành 6 lớp

Mô hình TReNDS khá gọn. Nhưng nếu triển khai ở một hệ thống lớn, mình sẽ nghĩ về nó theo sáu lớp.

Lớp 1: Detection

Nguồn có thể là:

• application log;
• Kubernetes event;
• Prometheus alert;
• OpenTelemetry trace;
• database alert;
• message queue;
• API gateway;
• infrastructure metric.

Mục tiêu chỉ là:

1Có chuyện bất thường.

Đừng bắt LLM làm việc mà regex, threshold hoặc anomaly detector đã làm tốt.

Lớp 2: Incident normalization

Biến:

110.000 log lines

thành:

1Incident
2{
3    service,
4    error_type,
5    timestamp,
6    deployment,
7    stacktrace,
8    fingerprint
9}

Đây là bước rất hay bị bỏ quên.

Garbage in, Sherlock Holmes cũng khó điều tra.

Lớp 3: Context retrieval

Agent có thể lấy:

 1logs
 2traces
 3metrics
 4source code
 5deployment diff
 6Git history
 7recent PR
 8config
 9feature flags
10runbooks
11past incidents

RCA càng tốt khi evidence càng tốt.

Lớp 4: Reasoning

Đây mới là chỗ dành cho model.

Nhiệm vụ:

1evidence
2   ↓
3hypothesis
4   ↓
5cross-check
6   ↓
7root cause

LLM nên được khuyến khích phân biệt:

1Observed evidence
2Likely cause
3Confidence
4Missing evidence
5Suggested action

Thay vì phán như thánh:

1Chắc chắn lỗi do Redis.

Lớp 5: Action

Ban đầu chỉ:

1Slack
2Email
3Ticket

Sau đó mới cân nhắc:

1Create issue
2Create PR
3Rollback
4Restart

Quyền càng mạnh, guardrail càng phải dày.

Lớp 6: Learning

Sau khi kỹ sư xác nhận:

1Agent đúng / sai

hãy lưu lại.

Sau vài nghìn incident, dữ liệu này trở thành một tài sản rất giá trị để:

• đánh giá model;
• cải thiện prompt;
• cải thiện tool;
• xây routing;
• tìm lỗi lặp;
• đo confidence;
• tạo incident knowledge base.

Nếu không có feedback loop, agent sẽ mãi mãi là một nhân viên mới đi làm ngày đầu.

Một thứ mình sẽ thêm: trace

Kiến trúc TReNDS tập trung nhiều vào log stream và source code.

Nhưng trong microservice lớn, mình sẽ muốn agent nhìn thêm distributed tracing.

Ví dụ:

 1mobile
 2  ↓
 3API gateway
 4  ↓
 5order-service
 6  ↓
 7payment-service
 8  ↓
 9fraud-service
10  ↓
11database

Một request có thể chạy qua năm service.

Nếu chỉ nhìn từng log stream, ta giống như đứng ở năm căn phòng khác nhau và nghe người trong phòng kể lại.

Trace ID biến chúng thành một câu chuyện duy nhất:

1trace_id = 12345

Agent có thể đi:

 1ERROR
 2↓
 3trace_id
 4↓
 5toàn bộ spans
 6↓
 7span có latency bất thường
 8↓
 9service liên quan
10↓
11logs
12↓
13source code

Lúc ấy RCA không còn là:

1Log → Code

mà trở thành:

 1Log
 2 + Trace
 3 + Metric
 4 + Code
 5 + Deployment
 6 + Runbook
 7 + Incident history
 8        ↓
 9      Agent
10        ↓
11 Root Cause hypothesis

Đây mới là hình dạng mà mình nghĩ các hệ thống observability có AI sẽ dần tiến tới.

Điều đáng học nhất không phải Amazon Bedrock

Nếu bỏ hết tên sản phẩm ra, kiến trúc TReNDS còn lại:

 1Event
 2↓
 3Filter
 4↓
 5Agent
 6↓
 7Tools
 8↓
 9Evidence
10↓
11Reasoning
12↓
13Structured Result

Chúng ta hoàn toàn có thể thay:

1CloudWatch

bằng Elasticsearch, Loki hay OpenSearch.

Thay:

1Bedrock

bằng một model nội bộ.

Thay:

1Strands

bằng framework agent khác hoặc một vòng tool calling tự viết.

Thay:

1SNS

bằng Kafka, Slack webhook hay hệ thống notification riêng.

Phần mềm có thể thay.

Pattern vẫn còn nguyên.

Và đó mới là thứ đáng học.

Từ observability sang investigability

Ngày xưa chúng ta xây monitoring để máy tính nói:

Tôi đang đau.

Sau đó observability cố giúp kỹ sư hỏi:

Đau ở đâu?

Agentic RCA tiến thêm một bước:

Tôi đang đau ở đây. Tôi đã xem log, kiểm tra trace, mở đoạn code liên quan và đây là ba nguyên nhân có khả năng nhất.

Đó là một thay đổi khá lớn.

Máy tính trước đây chỉ để lại dấu chân.

Con người đi theo dấu chân.

Bây giờ chúng ta đang xây những hệ thống có thể tự quay lại nhìn dấu chân của chính mình.

Nó đọc những electron vừa chạy qua CPU.

Đọc những byte vừa rơi xuống log.

Lần ngược những function call được viết từ vài tháng trước.

Mở repository.

So sánh bằng chứng.

Rồi vài chục giây sau gửi cho một con người đang uống cà phê:

1Tôi nghĩ tôi biết mình vừa chết vì sao.

Nghe hơi ngáo.

Nhưng về mặt kỹ thuật, nó chỉ là:

1tool calling
2+
3context retrieval
4+
5reasoning

Xong thuật toán, quá dễ.

Phần khó vẫn như mọi hệ thống production khác:

• dữ liệu có sạch không;
• log có đủ context không;
• trace có nối được không;
• source code có đúng version đang deploy không;
• tool có permission quá rộng không;
• incident có deduplicate không;
• model sai thì ai kiểm tra;
• agent được phép hành động đến đâu.

LLM không làm những câu hỏi này biến mất.

Nó chỉ khiến chúng trở nên quan trọng hơn.

Tổng kết

Case study của TReNDS cho thấy một hướng ứng dụng AI Agent rất thực tế: không tạo thêm một chatbot nữa, mà cắm agent vào đúng nơi con người đang phải làm những thao tác lặp đi lặp lại giữa nhiều hệ thống.

Kiến trúc cốt lõi khá đơn giản:

 1Production error
 2↓
 3Detect
 4↓
 5Collect evidence
 6↓
 7Read logs
 8↓
 9Read code
10↓
11Reason
12↓
13Root Cause
14↓
15Suggested fix
16↓
17Human

Theo TReNDS, pipeline này đã giúp giảm thời gian investigation từ khoảng 15–30 phút xuống dưới 60 giây trong workload của họ. (Amazon Web Services, Inc.)

Nhưng có lẽ bài học đáng nhớ hơn là:

Agent không trở nên hữu ích chỉ vì model thông minh. Nó trở nên hữu ích khi được đặt cạnh đúng dữ liệu và được trao đúng công cụ.

Một LLM đứng một mình chỉ có thể nói.

Một LLM có log, source code, trace, runbook và những tool nhỏ được kiểm soát chặt chẽ bắt đầu có thể điều tra.

Và có lẽ đây mới là một trong những nơi AI Agent thực sự phù hợp với production: không thay người kỹ sư quyết định mọi thứ, mà chạy trước vài bước, bật đèn pin, mở đúng cánh cửa và chỉ cho chúng ta xem nơi nào đang có khói.

Cảm ơn các bạn đã quan tâm và theo dõi bài viết, hẹn gặp lại ở các bài viết tiếp theo.

Tham khảo

• AWS Machine Learning Blog — How TReNDS automates root-cause analysis with Amazon Bedrock. (Amazon Web Services, Inc.)
• Amazon CloudWatch — Subscription Filters documentation. (AWS Documentation)
• Strands Agents — Tools Overview và Custom Tools. (Strands Agents SDK)
• Amazon Bedrock — Model availability và supported foundation models. (AWS Documentation)