Bài 60 — CI/CD Trends 2026

Mở đầu — vì sao bài này quan trọng

Bạn đã đi hết một hành trình dài: từ khái niệm CI/CD, qua GitHub Actions, GitLab, Jenkins, các chiến lược deployment, security scanning, cho tới observability và tối ưu chi phí. Đây là bài cuối cùng, và tôi muốn dùng nó để kéo bạn ra khỏi "hiện tại" và nhìn về phía trước 12–18 tháng tới.

Vì sao điều này quan trọng? Vì trong nghề DevOps, người tụt hậu không phải là người không biết viết pipeline — mà là người viết pipeline theo cách của năm 2021 trong khi thị trường đã sang trang. Năm 2026 là một thời điểm bản lề. Ba lực lượng lớn đang định hình lại cách chúng ta xây dựng và vận hành pipeline: (1) AI đang chui vào mọi ngóc ngách của quy trình phát triển, (2) áp lực bảo mật chuỗi cung ứng phần mềm (software supply chain) trở nên khắt khe hơn bao giờ hết, và (3) mô hình "platform engineering" đang thay thế tư duy "mỗi team tự lo pipeline của mình".

Bài này không dạy bạn một công cụ cụ thể. Nó giúp bạn định vị bản thân: biết cái gì đang lên, cái gì đang thoái trào, và đặt cược thời gian học tập của mình vào đâu cho đúng. Một mentor giỏi không chỉ dạy bạn hôm nay phải làm gì, mà còn chỉ cho bạn nơi con sóng tiếp theo sẽ vỗ vào bờ.

Khái niệm cốt lõi

1. AI trong CI/CD — từ trợ lý sang tác nhân (agent)

Đây là xu hướng nóng nhất và cũng dễ bị thổi phồng nhất. Hãy tách bạch nó ra thành các lớp cụ thể thay vì nói chung chung "AI vào DevOps".

Sinh pipeline từ ngôn ngữ tự nhiên (Copilot for pipelines). Trước đây bạn phải nhớ cú pháp YAML của GitHub Actions, phân biệt jobs, steps, uses, with. Giờ đây bạn gõ một câu như "tạo workflow build ứng dụng Node 20, chạy test, build Docker image và push lên GHCR khi merge vào main", và công cụ như GitHub Copilot Workspace hay các trợ lý tương tự sinh ra bộ khung YAML hoàn chỉnh. Điều này không thủ tiêu kỹ năng của bạn — nó dịch chuyển kỹ năng từ "gõ cú pháp" sang "biết review, biết cú pháp đó đúng hay sai, biết chỗ nào AI bịa ra một action không tồn tại".

AI code review (Greptile, CodeRabbit, Qodo). Đây là mảng trưởng thành nhất. Các bot này gắn vào Pull Request, đọc diff, hiểu ngữ cảnh cả repo (không chỉ vài dòng thay đổi), và để lại comment: "hàm này có thể null pointer", "bạn quên xử lý lỗi ở đây", "chỗ này lặp logic với module kia". Chúng không thay thế reviewer người mà tăng cường (augment): lọc bớt các lỗi vặt để con người tập trung vào quyết định kiến trúc.

Tự chẩn đoán và tự sửa pipeline lỗi (self-healing). Khi một job đỏ, thay vì kỹ sư mở log dài 2000 dòng đọc thủ công, một AI agent phân tích log, đối chiếu với các lần lỗi trước, gợi ý nguyên nhân ("test flaky do race condition", "hết dung lượng disk trên runner"), thậm chí tự mở PR sửa. Đây là biên giới đang được đẩy mạnh trong 2026.

2. Bảo mật chuỗi cung ứng — SLSA, SBOM và provenance thành mặc định

Sau hàng loạt sự cố như SolarWinds và các vụ package độc hại trên npm, việc "biết chính xác cái gì đã đi vào artifact của bạn" không còn là tùy chọn. Ba từ khóa bạn cần thuộc:

• SBOM (Software Bill of Materials): danh sách nguyên liệu phần mềm — mọi thư viện, version, license có trong build của bạn. Chuẩn phổ biến là CycloneDX và SPDX. Năm 2026, nhiều hợp đồng B2B, đặc biệt khi bán cho khách hàng Mỹ/EU, bắt buộc kèm SBOM.
• SLSA (Supply-chain Levels for Software Artifacts): khung đánh giá mức độ tin cậy của quy trình build, từ level 1 đến 4. Càng cao càng chứng minh được artifact được build từ đúng source, không bị chèn.
• Provenance & ký artifact (Sigstore/cosign): ký số image container để người dùng verify được "image này đúng do pipeline của tôi tạo ra, không ai chèn giữa đường".

3. Platform Engineering và Internal Developer Platform (IDP)

Xu hướng lớn thứ ba là tổ chức. Thay vì mỗi team tự copy-paste pipeline của nhau (dẫn tới 20 phiên bản khác nhau, không ai bảo trì nổi), các công ty lập một Platform team xây dựng nền tảng nội bộ: golden path, template pipeline chuẩn, developer portal (như Backstage) để dev tự phục vụ. Đây chính là sự trưởng thành của những gì bạn học ở Bài 51 và 58, giờ trở thành dòng chảy chủ đạo.

4. Những dịch chuyển kỹ thuật đáng chú ý khác

• eBPF cho observability pipeline: quan sát sâu hơn mà không cần chèn code.
• WebAssembly (Wasm) cho build/runner: khởi động nhanh, cách ly tốt, đang được thử nghiệm làm môi trường chạy step.
• GitOps thành chuẩn cho CD: Argo CD, Flux — trạng thái mong muốn nằm trong Git, cluster tự đồng bộ.
• Xanh hóa CI (Green CI): đo và tối ưu lượng carbon/điện của pipeline, nối tiếp tư duy tối ưu chi phí ở Bài 50.

Tình huống thực tế

Ví dụ 1 — Tiki áp dụng AI code review để giảm tải cho senior engineer

Giả sử một đội ngũ khoảng 120 kỹ sư tại một sàn thương mại điện tử lớn ở Việt Nam (bối cảnh tương tự Tiki). Trước đây, mỗi PR chờ review trung bình 6 giờ vì đội senior quá tải — họ vừa phải bắt lỗi null, lỗi format, vừa phải suy nghĩ về kiến trúc. Kết quả: lead time (thời gian từ commit đến production) bị kéo dài, dev junior nản vì PR "treo" cả ngày.

Đội platform tích hợp CodeRabbit vào GitHub. Bot tự động review mọi PR trong vòng 2 phút, bắt các lỗi cơ chế (unhandled promise, thiếu kiểm tra input, hardcode secret). Con số sau 3 tháng: thời gian chờ review lần đầu giảm từ 6 giờ xuống dưới 15 phút; số comment "vụn" mà senior phải viết giảm khoảng 40%, giúp họ dồn sức cho các quyết định thiết kế.

Bài học rút ra: AI review không loại bỏ con người. Nó xử lý phần "cơ bắp lặp lại" để con người làm phần "não". Nhưng có một cái bẫy: đội này ban đầu suýt để bot tự động approve PR — điều đó cực kỳ nguy hiểm. Họ nhanh chóng chỉnh lại: bot chỉ comment, con người vẫn là người bấm nút merge cuối cùng.

Ví dụ 2 — Một fintech ở Singapore bị khách hàng ngân hàng yêu cầu SBOM

Một startup fintech ở Đông Nam Á (giả định, quy mô ~40 kỹ sư) bán giải pháp thanh toán cho một ngân hàng lớn. Trong quá trình due diligence bảo mật, phía ngân hàng gửi một câu hỏi ngắn nhưng làm cả đội đứng hình: "Cho chúng tôi SBOM của mỗi release, và chứng minh image container của các bạn có provenance."

Lúc đó pipeline của họ chỉ build và push image, không có gì hơn. Họ có 3 tuần để bổ sung, nếu không sẽ mất hợp đồng trị giá hàng trăm nghìn USD. Đội đã thêm vào pipeline GitHub Actions ba bước: dùng syft sinh SBOM theo chuẩn CycloneDX, dùng grype quét lỗ hổng từ SBOM đó, và dùng cosign ký image cùng attestation provenance. Toàn bộ SBOM được lưu như artifact và đính kèm mỗi release.

Bài học rút ra: Bảo mật chuỗi cung ứng không còn là "chuyện của công ty lớn". Với các đội bán B2B, nó là điều kiện sống còn để ký hợp đồng. Nếu bạn học sẵn syft, cosign, SLSA từ bây giờ, bạn biến một rủi ro mất hợp đồng thành một buổi chiều làm việc.

Ví dụ 3 — VNG xây Internal Developer Platform để dập tắt "pipeline hỗn loạn"

Hình dung một tập đoàn công nghệ lớn tại Việt Nam (bối cảnh tương tự VNG) với hàng trăm microservice thuộc nhiều product khác nhau. Mỗi team tự viết pipeline riêng: team A dùng Jenkins cũ, team B dùng GitLab CI, team C copy YAML của team B rồi sửa lung tung. Khi có một lỗ hổng bảo mật cần vá trong bước build (ví dụ cần thêm bước quét SAST), họ phải đi sửa 80 pipeline khác nhau — một cơn ác mộng.

Đội platform quyết định xây một IDP dựa trên Backstage làm developer portal, cộng với một bộ reusable pipeline template (nối tiếp Bài 38). Dev mới tạo service chỉ cần chọn template "Golden Path — Java Microservice", và nhận được ngay pipeline chuẩn có sẵn lint, test, SAST, SBOM, deploy GitOps. Khi cần vá bảo mật, platform team chỉ sửa một template, mọi service kế thừa tự động.

Bài học rút ra: Ở quy mô lớn, vấn đề không phải là "pipeline có chạy không" mà là "quản trị được không". Xu hướng 2026 là tập trung hóa cái nền, phân quyền cái ngọn — và đây là cơ hội nghề nghiệp rõ ràng: vai trò Platform Engineer đang được săn đón và trả lương cao.

Hướng dẫn từng bước

Đây là cách bạn tự cập nhật mình theo các xu hướng trên một cách có hệ thống, thay vì chạy theo hype vô định.

Bước 1 — Tự đánh giá pipeline hiện tại theo một "trend checklist". Lấy một pipeline thật bạn đang có và hỏi: Nó đã sinh SBOM chưa? Đã ký artifact chưa? Có AI review gắn vào PR chưa? Nó là bản copy-paste hay kế thừa từ template dùng chung? Ghi điểm mỗi mục 0/1. Bạn sẽ thấy rõ khoảng trống.

Bước 2 — Thử nghiệm AI ở một chỗ ít rủi ro nhất. Đừng bắt đầu bằng self-healing pipeline production. Hãy bật một bot AI review (CodeRabbit/Greptile có bản miễn phí cho repo public) trên một repo phụ. Quan sát trong 2 tuần: nó bắt đúng bao nhiêu, báo nhầm (false positive) bao nhiêu. Học cách "điều chỉnh độ nhạy".

Bước 3 — Thêm một bước supply-chain security vào pipeline demo. Cài syft và chạy syft dir:. -o cyclonedx-json > sbom.json. Sau đó grype sbom:sbom.json để quét lỗ hổng. Chỉ 2 lệnh, bạn đã chạm vào xu hướng bảo mật nóng nhất.

Bước 4 — Ký một container image bằng cosign. Cài cosign, chạy cosign generate-key-pair, rồi cosign sign --key cosign.key <image>. Trải nghiệm việc verify bằng cosign verify. Bạn sẽ hiểu provenance không hề bí ẩn.

Bước 5 — Đọc một golden path thật. Lên GitHub tìm các repo Backstage software template mẫu để thấy "developer self-service" trông ra sao trong thực tế. Hình dung team bạn sẽ dùng nó thế nào.

Bước 6 — Chọn MỘT xu hướng để đi sâu. Đừng ôm hết. Nếu bạn thích code, đi sâu AI/agent. Nếu thích bảo mật, đi sâu SLSA/supply chain. Nếu thích hệ thống và tổ chức, đi sâu Platform Engineering. Chuyên sâu một mũi nhọn có giá trị hơn biết lơ mơ mọi thứ.

Lỗi thường gặp & mẹo

Lỗi 1 — Tin AI mù quáng. Nhiều bạn để AI sinh YAML rồi copy thẳng lên production mà không đọc. AI thường bịa ra tên action không tồn tại, hoặc gắn version @latest gây rủi ro bảo mật. Mẹo: luôn coi output của AI là "bản nháp của một junior" — hữu ích nhưng phải review.

Lỗi 2 — Chạy theo hype, bỏ nền tảng. Có bạn học ngay "AI self-healing pipeline" trong khi chưa nắm vững caching, secrets hay rollback. Mẹo: xu hướng chỉ có giá trị khi đặt trên nền vững. Đừng lợp mái khi chưa có móng.

Lỗi 3 — Coi SBOM là "file cho có". Sinh SBOM rồi vứt xó, không quét, không lưu theo từng release. Mẹo: SBOM chỉ có ý nghĩa khi (a) được quét lỗ hổng và (b) truy vết được về đúng release — để khi có CVE mới, bạn biết ngay release nào dính.

Lỗi 4 — Để AI agent có quyền ghi vào production. Cấp cho một AI agent quyền tự merge hoặc tự deploy là mở toang cửa cho thảm họa. Mẹo: áp dụng nguyên tắc least-privilege và luôn có "human in the loop" ở các bước không thể đảo ngược.

Lỗi 5 — Xây IDP quá tham vọng ngay từ đầu. Nhiều đội cố xây một platform "làm được mọi thứ" trong 6 tháng rồi chẳng ai dùng. Mẹo: bắt đầu bằng một golden path duy nhất cho use case phổ biến nhất, để dev thật dùng thật, rồi mở rộng dần.

Mẹo tổng quát: Hãy phân biệt "xu hướng bền vững" (supply-chain security, platform engineering, GitOps) với "xu hướng thời điểm" (một tool AI cụ thể có thể biến mất sau 1 năm). Đầu tư kỹ năng vào cái bền, chỉ thử nghiệm cái thời điểm.

Bài tập thực hành

• Trend audit: Lấy một pipeline thật (hoặc pipeline demo bạn từng làm trong khóa này). Chấm điểm theo checklist ở Bước 1 (SBOM, ký artifact, AI review, template dùng chung). Viết ra 3 việc cụ thể để nâng điểm.

• Supply chain mini-lab: Trên một dự án Node hoặc Java bất kỳ, thêm vào pipeline GitHub Actions/GitLab CI hai bước: sinh SBOM bằng syft và quét bằng grype. Chụp lại kết quả, đếm xem có bao nhiêu lỗ hổng mức High/Critical.

• Thử AI review: Bật CodeRabbit hoặc Greptile trên một repo public của bạn. Tạo một PR có chủ đích lỗi (ví dụ quên xử lý null). Ghi lại: bot có bắt được không, bắt đúng đến đâu, có báo nhầm gì không.

• Ký image: Dùng cosign ký một Docker image nhỏ và verify lại. Viết 3–4 câu giải thích với đồng nghiệp: "provenance là gì và vì sao khách hàng cần nó".

• Bài luận định hướng nghề (quan trọng nhất): Viết nửa trang trả lời: Trong 3 nhóm — AI/agent, Supply-chain security, Platform engineering — bạn chọn đi sâu nhánh nào trong 12 tháng tới, vì sao, và 3 bước học tập cụ thể đầu tiên là gì?

Tóm tắt

Chúng ta khép lại khóa học bằng một cái nhìn về tương lai gần. Ba lực định hình CI/CD năm 2026 là: AI đang dịch từ trợ lý sang tác nhân (sinh pipeline, review code, tự chẩn đoán lỗi) nhưng luôn cần con người ở vòng cuối; bảo mật chuỗi cung ứng (SBOM, SLSA, provenance với syft/grype/cosign) trở thành điều kiện bắt buộc để bán B2B, không còn là tùy chọn; và platform engineering với Internal Developer Platform, golden path, developer portal đang thay thế mô hình mỗi team tự lo pipeline.

Ba câu chuyện thực tế — AI review giảm tải cho đội tại một sàn TMĐT, một fintech phải bổ sung SBOM để giữ hợp đồng ngân hàng, và một tập đoàn lớn xây IDP để dập tắt hỗn loạn pipeline — cho thấy các xu hướng này không viển vông mà đang gõ cửa ngay tại Việt Nam và Đông Nam Á.

Lời khuyên cuối của tôi: đừng cố ôm hết mọi xu hướng. Hãy giữ nền tảng thật vững (những gì bạn đã học suốt 59 bài), rồi chọn một mũi nhọn để đi sâu. Trong nghề này, người thắng không phải người biết nhiều thứ hời hợt, mà là người biết nền tảng chắc và cưỡi đúng một con sóng. Chúc bạn đi xa. Hẹn gặp lại trong production.