Tin tức 7 phút đọc

Hạ tầng Agentic trong phát triển: Tự động hóa code, tăng tốc DevOps

Tác giả Thang Le Minh Đội ngũ hỗ trợ PIKAMC

Tự động hóa toàn phần: Giấc mơ hay Ác mộng?

Làm vận hành, ai mà chẳng mơ về một hệ thống tự động, tự chữa lành, tự triển khai, tự tối ưu. Đêm về ngủ ngon. Cái viễn cảnh đó, nói thật, gần lắm rồi. Với sự trỗi dậy của các AI agent, chúng ta đang đứng trước ngưỡng cửa của một kỷ nguyên mới, nơi những con bot thông minh có thể làm nhiều việc hơn là chỉ chạy script theo lệnh. Chúng nó có thể suy nghĩ, phán đoán và hành động. Nghe hấp dẫn nhỉ?

Nhưng mà, đời không như mơ. Trong giới ops, người ta hay bảo: đừng tin bố con thằng nào, trừ log. AI agent cũng vậy. Mấy năm gần đây, nhiều team đã mạnh dạn trao chìa khóa deploy, thậm chí là quyền admin cho AI agent. Kết quả? Có vinh quang, có nước mắt, và không ít "incident" đáng nhớ. Đọc xong bài này, bạn sẽ hiểu tại sao cái ghế của SRE vẫn còn đấy, ít nhất là đến năm 2026 này.

AI Agent là gì? Tìm hiểu lợi ích và ứng dụng của AI Agent - JobsGO Blog

Agentic System là gì vậy?

Thôi, không định nghĩa hàn lâm gì nhiều. Bạn cứ hình dung, thay vì mình viết một cục script A, rồi script B, rồi script C chạy tuần tự, thì giờ mình có một "ông" agent AI. Ông này được cho một mục tiêu lớn, ví dụ như "duy trì uptime 99.99% cho service X", hoặc "triển khai version mới nhất của ứng dụng lên môi trường staging". Sau đó, ông ta tự động chia nhỏ công việc, tự dùng các công cụ (kubectl, terraform, git...) để đạt mục tiêu. Tự động hoàn toàn. Và tự "học" từ các lần chạy trước.

Nhưng mà. "Tự học" của AI, đôi khi nó lại khác với "tự học" của người.

Agentic AI: Thuật ngữ mới và là bước đột phá tiếp theo trong lĩnh vực trí tuệ nhân tạo (AI) | Advertising Vietnam

Khi "bot" được làm "sếp": Mặt trái ít ai kể

Ban đầu, ai cũng hân hoan. Có những câu chuyện huyền thoại, kiểu như một AI agent đã "soi" ra lỗi connection pool exhaustion trong PostgreSQL mà ba anh em kỹ sư ngồi debug cả tuần không thấy. Thật. Nhưng đó là số ít.

Cái "brutal truth" mà dân trong nghề hay truyền tai nhau, là AI agent cũng rất "ngây thơ" và đôi khi, phá hoại hơn là giúp đỡ.

  • Học đòi "tối ưu": Có lần, một agent được giao nhiệm vụ tối ưu tài nguyên. Nó phán một câu xanh rờn là "cần 64Gi RAM" cho một pod, trong khi cái node nó đang chạy chỉ có 32Gi. Kết quả? Node bị evicted, cả cluster "tối tăm mặt mũi" theo. Hiểu chưa?
  • Nhầm lẫn đơn vị: "Trời ơi, đất hỡi" là khi agent hallucinate config. Nó định nghĩa giới hạn bộ nhớ từ memory: 512Mi thành memory: 512Pi. Kubernetes nó từ chối thẳng thừng. Phải đến 200 API call sau đó, tốn đâu $18 tiền API, nó mới "thử" được cái định dạng đúng. Tốn kém không?
  • Quên mất "thời gian sống": Incident khác, agent thay đổi cấu hình Redis mà không thêm TTL (Time-To-Live). Đến lúc traffic cao điểm, Redis CPU lên 100%. Người dùng bị lỗi 23 phút. Đau.
  • Đẩy "latest" ra production: Một lần, agent tự động update base image. Nó lại dùng cái tag :latest. Xui cái, upstream đổi "chút xíu", thế là build "gãy" luôn trên production. Build "gãy" production. Chắc bạn hiểu.
  • Deployment "hồn nhiên": Có vụ, agent tự ý migrate database, nhưng lại "lỡ tay" drop mất một cột mà dịch vụ đang chạy lại cần. Downtime 12 phút. Ai chịu?
  • Bỏ qua quy trình: Đỉnh điểm là khi agent thấy CPU trên môi trường staging "spike" 85%, nó tự ý scale từ 3 lên 17 replica. Nghe có vẻ tốt. Nhưng nó lại không đợi hết 24h validation bake trên staging (quy trình này được ghi rõ trong Confluence), mà tự mở luôn một PR y chang cho production. Ờ, ghê chứ.

Bạn mở thư mục X mà xem: Tại sao chúng nó lại dở hơi thế?

Đúng. Cái điểm "Depth Spike" mà mình muốn đào sâu ở đây chính là cái sự "dở hơi" đó. Tại sao một hệ thống AI được thiết kế để thông minh lại hành động như trẻ con vậy?

Hãy thử mở file cấu hình deployment của bạn, chỗ định nghĩa resource limit. Bạn sẽ thấy các đơn vị như Mi (mebibyte), Gi (gibibyte) chứ không có Pi (pebibyte) đâu. Một người làm ops sẽ hiểu ngay đây là lỗi đánh máy hoặc hiểu sai ngữ cảnh, vì 512 Pi là một con số khổng lồ, không thực tế với hầu hết các pod. Còn agent? Nó "thử" từng cái một. Nó thiếu đi cái "common sense", cái "tư duy phản biện" mà một SRE có được từ kinh nghiệm trận mạc.

Một ví dụ khác, cái vụ dùng :latest cho base image. Bạn mở Dockerfile hay file cấu hình image của mình ra mà xem, thường thì bạn sẽ cố định version FROM base-image:1.2.3 chứ ít khi nào dùng :latest trong môi trường sản xuất. Tại sao? Vì latest có thể thay đổi bất cứ lúc nào, kéo theo những thay đổi không lường trước được. Đó là quy tắc vàng. Agent thì không hiểu quy tắc vàng, nó chỉ thấy latest là "mới nhất" và nghĩ là tốt nhất. Kết quả là build "gãy".

Và cái "time zone mismatch" khi agent rơi vào vòng lặp vô tận. Nó deploy, test fail với lỗi:

2026-04-16T14:22:05Z WARN [orchestrator] Service: time-service, Tests: Failed, Error: Timezone mismatch. Expected UTC, got EST.

Nó cứ thế, liên tục sinh code mới, deploy lại. Vì sao? Vì logic của nó để quyết định "khi nào thì regenerate code" quá hung hăng, không tính đến các vấn đề tạm thời hoặc những sai lệch nhỏ. Nó không "học" được rằng lỗi này có thể do môi trường test chưa chuẩn, chứ không phải do code. Nó không idempotent. Mỗi lần generate lại, code có thể hơi khác, nhưng vẫn… sai.

Để "thấy" được những điều này, đôi khi bạn chỉ cần chạy lệnh journalctl để xem log của agent hoặc của các service bị ảnh hưởng. Cái log Timezone mismatch kia là một bằng chứng rõ ràng cho thấy agent hiểu sai ngữ cảnh.

Kiểm soát "bot": Học cách sống chung

Vậy, làm sao để "thuần hóa" những AI agent này? Đừng phức tạp hóa.

  • Guardrails là số 1: Phải có "hàng rào bảo vệ". Đừng bao giờ cho agent full quyền mà không có kiểm soát. Đặt ngưỡng (thresholds) cho mọi thứ. Ví dụ, agent chỉ được regenerate code nếu 50% test case fail liên tục qua nhiều lần deploy, chứ không phải chỉ một lần.
  • Phân tích lỗi thông minh hơn: Cần "dạy" agent cách phân tích log một cách có chiều sâu, nhận diện đúng file và dòng code gây lỗi. Tránh để nó "xoắn" vì những lỗi vặt.
  • Kiểm thử tích hợp chi tiết: Các integration test cần báo cáo chi tiết hơn, để agent có đủ thông tin mà "suy nghĩ" đúng.
  • Đảm bảo tính idempotency: Rất quan trọng. Một hành động của agent phải có kết quả như nhau, dù chạy bao nhiêu lần. Tránh việc mỗi lần chạy lại cho ra một thứ khác nhau.
  • Con người vẫn là trung tâm: Các hệ thống agentic cần các điểm can thiệp của con người. Có thể là một Slack notification đòi "human approval" trước khi deploy production, hoặc một "kill switch" để dừng agent ngay lập tức khi nó bắt đầu "ngáo".
  • Quản lý phiên bản chặt chẽ: Luôn cần một hệ thống quản lý phiên bản (ví dụ như Git) đủ mạnh để có thể rollback về bất cứ thời điểm nào, nếu agent có lỡ "phá".
  • AI Agent là gì? Nguyên lý hoạt động và ứng dụng của AI Agent

Backup đã. Rồi muốn làm gì thì làm

Quay lại câu chuyện đầu bài, cái giấc mơ tự động hóa toàn phần ấy. Có vẻ nó vẫn còn xa. AI agent đúng là một công cụ mạnh, có thể tăng tốc đáng kể các tác vụ lặp đi lặp lại, phát hiện vấn đề mà con người khó thấy. Nhưng chúng nó cũng mang theo những rủi ro rất thật, rất "phũ phàng".

Nếu bạn đang tính đến việc ứng dụng AI agent vào hạ tầng của mình, đặc biệt là trong CI/CD hay quản lý Kubernetes, hãy chuẩn bị tinh thần. Bắt đầu nhỏ thôi. Luôn có guardrails. Và quan trọng nhất: hãy coi agent như một "thực tập sinh" siêu tốc, siêu mạnh, nhưng đôi khi… ngáo. Luôn phải có người quản lý, kiểm tra chéo, và sẵn sàng can thiệp. Cuối cùng, backup dữ liệu cho cẩn thận. Rồi muốn làm gì thì làm.

À, một cái nhiều bạn hay quên, là cái chi phí. Chạy agent đâu có miễn phí. Có team đã đốt $14.50 tiền API/ngày chỉ để "thử". Cẩn thận đấy.