AI tối ưu dung lượng Container Registry cho đội DevOps

Bizfly Cloud

3530

06-07-2026

Trong case study mô phỏng này, Bizfly Cloud AI được đặt vào bài toán của một doanh nghiệp SaaS có nhiều nhóm DevOps cùng đẩy image lên Container Registry mỗi ngày, khiến dung lượng tăng liên tục nhưng không ai chắc image nào còn dùng được. Nỗi đau không nằm ở việc thiếu nơi lưu trữ, mà nằm ở chỗ registry đã trở thành một “kho chứa” khó kiểm soát, kéo theo chi phí lưu trữ, rủi ro deploy nhầm image và thời gian rà soát thủ công.

Bối cảnh khách hàng và áp lực cần thay đổi

Khách hàng trong case study là một doanh nghiệp công nghệ vận hành sản phẩm SaaS B2B, có nhiều nhóm phát triển phụ trách các module khác nhau. Mỗi nhóm sử dụng CI/CD để build, test và đẩy container image lên registry trước khi triển khai sang môi trường staging hoặc production. Sau một thời gian mở rộng sản phẩm, số lượng image tăng nhanh hơn khả năng kiểm soát của đội DevOps.

Áp lực bắt đầu xuất hiện khi registry không còn chỉ là nơi lưu trữ artifact kỹ thuật. Nó trở thành một phần quan trọng trong chuỗi phát hành phần mềm. Một image cũ nhưng chưa được gắn trạng thái rõ ràng có thể bị giữ lại quá lâu, trong khi image đang chạy production lại không được đánh dấu đủ chắc chắn để bảo vệ khỏi thao tác xóa nhầm. Thực ra, đây là vấn đề khá quen thuộc khi doanh nghiệp chuyển từ vài service ban đầu sang mô hình nhiều microservice.

Đội CTO và Head of IT muốn tối ưu dung lượng Container Registry nhưng không thể yêu cầu DevOps xóa thủ công từng image. System Admin thì cần giảm áp lực lưu trữ, còn SRE cần đảm bảo việc dọn dẹp không ảnh hưởng đến khả năng rollback. Khi triển khai với dữ liệu phân tán, vấn đề không nằm ở AI trước mà nằm ở cách chuẩn hóa nguồn dữ liệu: tag image, lịch sử deploy, pipeline build và trạng thái runtime thường không nằm cùng một chỗ.

Bài toán lớn khách hàng cần giải quyết

Bài toán của khách hàng không chỉ là “xóa bớt image”. Nếu xử lý đơn giản như vậy, đội vận hành có thể giảm được dung lượng trong ngắn hạn nhưng lại tạo rủi ro cho rollback, audit và bảo mật. Điều khách hàng cần là một quy trình tối ưu dung lượng có kiểm soát, biết image nào còn liên quan đến môi trường đang chạy, image nào chỉ là bản build thử, image nào đã lỗi thời và image nào cần giữ theo chính sách nội bộ. Đây là lý do Bizfly Cloud AI được đưa vào như một lớp phân tích và gợi ý trước khi con người phê duyệt hành động.

Các bài toán chính được xác định trong giai đoạn khảo sát gồm:

• Image cũ tồn tại quá lâu sau mỗi lần build: Pipeline CI/CD tạo ra nhiều image theo commit, branch, tag hoặc bản thử nghiệm. Dữ liệu build nằm ở hệ thống CI/CD, còn dữ liệu lưu trữ nằm ở registry, khiến DevOps khó biết image nào đã hết giá trị sử dụng. Nếu không xử lý, registry phình to dần và chi phí lưu trữ trở thành một khoản khó giải thích với ban quản lý.

• Không phân biệt rõ image đang chạy, image dự phòng và image rác: Một số image từng được deploy lên staging hoặc production nhưng không có nhãn trạng thái thống nhất. SRE cần giữ lại image phục vụ rollback, trong khi System Admin muốn dọn các lớp dữ liệu dư thừa. Nếu không có cơ chế đối chiếu, việc xóa image rất dễ trở thành quyết định cảm tính.

• Tag image thiếu chuẩn, gây khó truy vết: Có nhóm dùng tag theo phiên bản, có nhóm dùng tag theo commit, có nhóm lại dùng latest hoặc tag tạm. Dữ liệu không đồng nhất khiến việc truy vấn bằng script thủ công kém tin cậy. Hậu quả là DevOps mất thời gian kiểm tra lại nhiều lần trước khi dám đưa ra danh sách image có thể xóa.

• Thiếu báo cáo cho CTO và Head of IT: Dung lượng registry tăng nhưng báo cáo thường chỉ dừng ở con số tổng, không chỉ ra service nào tạo nhiều image nhất, pipeline nào có tỷ lệ build dư thừa cao, hay nhóm nào cần chỉnh lại quy trình. Quản lý vì thế khó đưa ra chính sách retention hợp lý. Nếu không có báo cáo theo ngữ cảnh vận hành, bài toán tối ưu dễ bị đẩy xuống thành việc dọn dẹp kỹ thuật đơn lẻ.

Các bài toán này liên quan chặt với nhau vì chúng cùng xuất phát từ một điểm: doanh nghiệp chưa có bức tranh vòng đời container image từ lúc build, lưu trữ, deploy, rollback cho đến khi hết hạn. Nếu chỉ tối ưu ở registry, dữ liệu sẽ thiếu phần lịch sử CI/CD và trạng thái runtime. Nếu chỉ nhìn từ pipeline, đội vận hành lại không thấy toàn bộ dung lượng đang bị chiếm dụng. Vì vậy, case study này được xử lý như một bài toán quản lý vòng đời image có hỗ trợ AI, không phải một chiến dịch xóa file đơn thuần.

Cách Bizfly Cloud AI được triển khai trong case study này

Bizfly Cloud AI được triển khai như một workflow phân tích dữ liệu registry kết hợp dữ liệu CI/CD và dữ liệu vận hành runtime. Nguồn đầu vào gồm danh sách repository, image tag, digest, thời điểm build, kích thước image, lịch sử push, lịch sử deploy, trạng thái môi trường, thông tin service và quy tắc giữ lại image theo từng nhóm. Với những hệ thống có ticket hoặc change request, dữ liệu phê duyệt release cũng được đưa vào để AI hiểu image nào gắn với lần phát hành quan trọng. Mục tiêu là tạo ra một bản đồ quan hệ giữa image và hoạt động vận hành thực tế.

Trước khi AI xử lý, dữ liệu được chuẩn hóa theo một mô hình thống nhất. Mỗi image cần có các trường tối thiểu như repository, tag, digest, service owner, môi trường liên quan, thời điểm build, lần deploy gần nhất và trạng thái đề xuất. Những tag thiếu chuẩn được gom nhóm bằng quy tắc nhận diện, ví dụ tag theo commit, tag theo branch, tag tạm hoặc tag version. Phần chuẩn hóa này rất quan trọng, vì nếu đầu vào còn lẫn lộn thì AI chỉ có thể đưa ra gợi ý mơ hồ.

AI Agent trong Bizfly Cloud AI xử lý theo ba lớp. Lớp đầu tiên phân loại image theo trạng thái sử dụng: đang chạy, từng chạy gần đây, phục vụ rollback, bản build thử, bản build lỗi hoặc chưa đủ dữ liệu để kết luận. Lớp thứ hai đánh giá mức ưu tiên dọn dẹp dựa trên kích thước, tuổi image, tần suất deploy, quan hệ với release và chính sách retention. Lớp thứ ba tạo khuyến nghị hành động, gồm giữ lại, đưa vào danh sách theo dõi, đề xuất xóa sau phê duyệt hoặc yêu cầu bổ sung dữ liệu.

Đầu ra của workflow không phải là lệnh xóa tự động ngay lập tức. Đội DevOps nhận được danh sách image được phân nhóm kèm lý do đề xuất, SRE nhận được danh sách image cần giữ để rollback, còn CTO hoặc Head of IT có báo cáo tổng hợp theo service, nhóm phát triển và xu hướng tăng dung lượng. Trong thực tế tôi thấy điểm làm đội kỹ thuật yên tâm nhất không phải là AI tìm ra bao nhiêu image rác, mà là AI giải thích được vì sao một image được đề xuất xóa hoặc giữ lại.

So sánh hiệu quả trước và sau triển khai

Trước khi triển khai Bizfly Cloud AI, đội DevOps vẫn có thể viết script để lọc image cũ theo ngày tạo hoặc theo tag. Tuy nhiên, cách này thiếu ngữ cảnh vận hành nên không đủ an toàn cho các môi trường có nhiều service và nhiều pipeline. Sau khi triển khai, trọng tâm không còn là “xóa được bao nhiêu” mà là “xóa đúng image, giữ đúng image và giải thích được quyết định”. Bảng dưới đây mô tả thay đổi quan sát được trong quy trình vận hành, không sử dụng số liệu định lượng khi chưa có dữ liệu đo lường thật.

Thay đổi quan trọng nhất trong case study này là đội vận hành không còn xử lý registry như một kho lưu trữ tĩnh. Registry được nhìn như một phần của chuỗi phát hành phần mềm, có liên hệ với build, deploy, rollback và audit. Khi AI gom được các mảnh dữ liệu này lại, quyết định dọn dẹp trở nên có căn cứ hơn. Điều đó tạo ra sự khác biệt lớn, vì một quy trình tối ưu dung lượng chỉ có giá trị khi đội kỹ thuật đủ tin tưởng để áp dụng đều đặn.

Quy trình triển khai Bizfly Cloud AI

Quy trình triển khai được thiết kế theo hướng kiểm soát rủi ro trước, tối ưu sau. Với Container Registry, nếu AI đề xuất sai ở giai đoạn đầu, hậu quả có thể ảnh hưởng đến phát hành phần mềm hoặc khả năng rollback. Vì vậy, giai đoạn POC chỉ nên chạy ở phạm vi hẹp, ưu tiên một số repository hoặc môi trường ít rủi ro. Khi kết quả đã ổn định, doanh nghiệp mới mở rộng sang các nhóm service quan trọng hơn.

1. Khảo sát hiện trạng và xác định bài toán chính. Đội Bizfly Cloud AI cùng khách hàng rà soát cách các nhóm đang build, tag, push và deploy image. Mục tiêu của bước này là xác định vấn đề chính nằm ở dung lượng tăng, tag thiếu chuẩn, thiếu retention policy hay thiếu báo cáo quản trị.

2. Thu thập, làm sạch và phân nhóm dữ liệu đầu vào. Dữ liệu từ Container Registry, CI/CD, lịch sử deploy, ticket release và trạng thái môi trường được gom lại theo từng repository. Những trường thiếu hoặc không đồng nhất như tag, service owner, môi trường và thời điểm deploy được chuẩn hóa trước khi đưa vào workflow AI.

3. Thiết kế AI Agent hoặc workflow theo từng use case con. Workflow được chia thành các nhánh như phát hiện image cũ, nhận diện image dung lượng bất thường, đề xuất retention policy và tạo báo cáo quản trị. Mỗi nhánh có tiêu chí đầu vào, logic xử lý, ngưỡng cảnh báo và dạng đầu ra riêng để tránh gộp mọi thứ vào một mô hình khó kiểm soát.

4. Tích hợp với hệ thống hiện có như CI/CD, ticket, registry và dashboard vận hành. Bizfly Cloud AI không thay thế hệ thống đang dùng mà lấy dữ liệu từ các điểm đã có trong quy trình. Kết quả phân tích có thể được trả về dashboard, ticket phê duyệt hoặc báo cáo định kỳ cho DevOps, SRE và quản lý IT.

5. Chạy thử POC với phạm vi nhỏ. Ở giai đoạn đầu, AI chỉ tạo danh sách đề xuất và không thực hiện hành động xóa tự động. Đội DevOps kiểm tra lại từng nhóm đề xuất để đánh giá độ phù hợp, đặc biệt với image liên quan đến production hoặc rollback.

6. Đo lường, tinh chỉnh và mở rộng triển khai. Sau POC, các tiêu chí phân loại được chỉnh lại theo thực tế vận hành của khách hàng. Khi đội kỹ thuật đã tin vào logic đề xuất, workflow có thể mở rộng sang nhiều repository hơn và kết hợp thêm bước phê duyệt bán tự động.

Kinh nghiệm thực tế là không nên bắt đầu bằng mục tiêu “xóa càng nhiều càng tốt”. Điểm khó nhất thường nằm ở việc làm rõ image nào còn liên quan đến release, môi trường chạy thật và quy tắc rollback. Cách xử lý hợp lý là dựng lớp dữ liệu trung gian trước, cho AI phân loại và giải thích, rồi mới tính đến tự động hóa. Khi đội DevOps hiểu được logic đề xuất, họ sẽ chủ động đóng góp thêm quy tắc để workflow chính xác hơn.

Kết quả và giá trị doanh nghiệp nhận được

Sau khi triển khai theo phạm vi POC, giá trị đầu tiên khách hàng nhận được là khả năng nhìn thấy registry theo ngữ cảnh vận hành. Thay vì chỉ biết tổng dung lượng đang tăng, đội IT có thể thấy nhóm repository nào tạo nhiều image, image nào lâu không liên quan đến deploy, image nào cần giữ vì liên quan đến rollback. Đây là thay đổi quan trọng, vì quản lý dung lượng không còn là công việc dọn kho định kỳ mà trở thành một phần của quản trị vòng đời phần mềm.

Với DevOps và SRE, lợi ích rõ nhất là giảm thời gian rà soát lặp lại. AI gom dữ liệu từ nhiều nguồn, phân loại image và đưa ra lý do đề xuất, nên kỹ sư không phải kiểm tra thủ công từng tag như trước. Những tình huống cần con người quyết định vẫn được tách riêng, ví dụ image thuộc production, image gắn với release quan trọng hoặc image thiếu dữ liệu để kết luận. Cách làm này giúp đội kỹ thuật giữ được quyền kiểm soát thay vì bị ép tin hoàn toàn vào AI.

Ở góc độ CTO và Head of IT, Bizfly Cloud AI tạo ra một lớp báo cáo có thể dùng để điều chỉnh quy trình. Nếu một nhóm phát triển tạo quá nhiều image thử nghiệm, vấn đề có thể nằm ở pipeline build. Nếu một service liên tục tăng kích thước image, vấn đề có thể nằm ở Dockerfile, dependency hoặc cách đóng gói artifact. Khi các dấu hiệu này được đưa lên thành báo cáo định kỳ, doanh nghiệp có cơ sở mở rộng vận hành mà không phải tăng tương ứng nhân sự chỉ để xử lý việc dọn dẹp thủ công.

AI chưa làm được gì trong case study này

AI chưa thể tự chịu trách nhiệm cho các quyết định quan trọng như xóa image production, thay đổi retention policy bắt buộc hoặc can thiệp vào quy trình rollback. Trong case study này, Bizfly Cloud AI đóng vai trò phân tích, tổng hợp, gợi ý và tự động hóa một phần quy trình chuẩn bị quyết định. Con người vẫn cần kiểm soát các tình huống ngoại lệ, phê duyệt cuối cùng và xử lý những dữ liệu có tác động lớn đến vận hành. Đây là ranh giới cần nói rõ ngay từ đầu để đội kỹ thuật không kỳ vọng sai.

AI cũng cần dữ liệu đầu vào đủ sạch, đủ quyền truy cập và được cập nhật liên tục. Nếu registry thiếu metadata, pipeline không ghi lại lịch sử build hoặc hệ thống deploy không cho biết image nào đang chạy, kết quả phân loại sẽ bị giới hạn. Trong trường hợp này, việc đầu tiên không phải là tăng độ phức tạp của AI mà là chuẩn hóa cách ghi nhận dữ liệu. Khi nền dữ liệu đủ tốt, AI mới có thể đưa ra khuyến nghị có giá trị và có thể kiểm chứng.

FAQ

1. Bizfly Cloud AI có tự động xóa image trong Container Registry không?

Trong case study này, Bizfly Cloud AI không được thiết kế để tự động xóa image ngay từ đầu. AI tạo danh sách đề xuất, giải thích lý do và phân nhóm mức độ ưu tiên để DevOps hoặc SRE kiểm tra. Với image liên quan đến production, rollback hoặc release quan trọng, bước phê duyệt của con người vẫn cần được giữ lại. Sau khi quy trình ổn định, doanh nghiệp có thể tự động hóa một phần với những nhóm image rủi ro thấp.

2. Dữ liệu nào cần chuẩn bị trước khi triển khai AI tối ưu dung lượng Registry?

Doanh nghiệp cần chuẩn bị dữ liệu từ Container Registry, CI/CD, lịch sử deploy, thông tin service và quy tắc retention hiện có nếu có. Các trường như repository, tag, digest, thời điểm build, kích thước image và môi trường liên quan rất quan trọng. Nếu dữ liệu đang phân tán, bước đầu tiên là chuẩn hóa lại để AI có đủ ngữ cảnh phân tích. Dữ liệu càng rõ thì khuyến nghị càng dễ kiểm tra và áp dụng.

3. Use case này phù hợp với doanh nghiệp nào?

Use case này phù hợp với doanh nghiệp có nhiều nhóm phát triển, nhiều microservice hoặc tần suất build image cao. Nó cũng phù hợp với đội DevOps đang gặp khó khi kiểm soát image cũ, image thử nghiệm và image phục vụ rollback. Với doanh nghiệp chỉ có rất ít service, quy trình thủ công có thể vẫn đủ trong giai đoạn đầu. Khi quy mô tăng, bài toán registry thường trở nên phức tạp nhanh hơn dự kiến.

4. Giới hạn lớn nhất của AI trong bài toán tối ưu Container Registry là gì?

Giới hạn lớn nhất là AI không thể đoán chính xác trạng thái vận hành nếu dữ liệu không ghi nhận đầy đủ. Ví dụ, nếu một image từng được dùng cho rollback nhưng không có lịch sử deploy hoặc không có ticket release, AI có thể xếp image đó vào nhóm cần kiểm tra thêm. Bizfly Cloud AI có thể giảm tải phân tích, nhưng không thay thế trách nhiệm phê duyệt của đội vận hành. Vì vậy, cơ chế kiểm soát quyền và quy trình review vẫn rất quan trọng.

5. CTO hoặc Head of IT nhận được giá trị gì từ use case này?

CTO và Head of IT không chỉ nhận được danh sách image có thể dọn dẹp. Giá trị lớn hơn là báo cáo cho thấy vì sao dung lượng registry tăng, nhóm nào tạo nhiều image, service nào có dấu hiệu đóng gói chưa tối ưu và policy nào cần chuẩn hóa. Từ đó, quản lý có cơ sở điều chỉnh quy trình build, release và retention. Đây là phần giúp bài toán kỹ thuật kết nối được với quản trị chi phí và rủi ro.

6. Bizfly Cloud AI có thể tích hợp với hệ thống CI/CD hiện có không?

Có thể triển khai theo hướng tích hợp với các nguồn dữ liệu CI/CD, Container Registry, ticket và dashboard vận hành hiện có. Trọng tâm không phải thay thế công cụ đang dùng mà là gom dữ liệu phân tán thành một workflow phân tích có ngữ cảnh. Bizfly Cloud AI xử lý lớp phân loại, khuyến nghị và báo cáo để đội DevOps ra quyết định nhanh hơn. Phạm vi tích hợp cụ thể cần được khảo sát theo hệ thống thực tế của từng doanh nghiệp.

Kết bài

Bài toán tối ưu dung lượng Container Registry không nên được nhìn như việc xóa bớt image cũ. Với doanh nghiệp có nhiều pipeline và nhiều nhóm DevOps, đây là bài toán quản lý vòng đời container image, nơi mỗi quyết định dọn dẹp đều cần liên hệ với build, deploy, rollback và audit.

Bizfly Cloud AI giúp biến bài toán đó thành một quy trình có thể đo lường, có thể giải thích và có thể mở rộng. Khi dữ liệu registry, CI/CD và vận hành được chuẩn hóa, AI không chỉ gợi ý image nào nên giữ hay xóa, mà còn giúp doanh nghiệp nhìn lại cách phần mềm được build và phát hành mỗi ngày.