title: "DevOps & Architecture: Sự giao thoa giữa CI/CD và các chuẩn kiến trúc"
series: "TOGAF Mastery: Kiến trúc sư Doanh nghiệp Chuyên sâu"
part: "Phần 4 — Vận hành kiến trúc cấp chuyên gia (Expert Ops)"
order: 35
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "12 phút"
tags:

• togaf
• devops
• ci-cd
• policy-as-code
• architecture-governance
• enterprise-architecture

DevOps & Architecture: Sự giao thoa giữa CI/CD và các chuẩn kiến trúc

Một buổi chiều thứ Sáu, team platform deploy một microservice mới lên production. Pipeline xanh, test pass, canary release ổn định. Ba tuần sau, trong kỳ Compliance Review định kỳ (bài 20), bạn — với tư cách Chief EA — phát hiện service đó dùng một message broker không nằm trong Technology Reference Model (TRM, bài 17), mở một public endpoint không qua API Gateway chuẩn, và lưu dữ liệu khách hàng ở một region không tuân thủ chính sách data residency. Ba vi phạm kiến trúc, đã chạy production ba tuần, đã có traffic thật, đã có dữ liệu thật.

Đây không phải lỗi của đội dev. Họ không cố tình phá luật — họ đơn giản là không biết luật, hoặc biết nhưng không có cách nào kiểm tra tự động trước khi deploy. Compliance Review theo mô hình cổ điển của TOGAF — một hội đồng ngồi lại, xem xét thiết kế, ký duyệt — hoạt động tốt trong thế giới release theo quý. Nó sụp đổ hoàn toàn trong thế giới release theo giờ. Khi một tổ chức deploy hàng chục lần một ngày, "kiểm tra sau cùng" không còn là governance — nó là khảo cổ học.

Vấn đề không nằm ở việc EA quá chậm hay DevOps quá liều. Vấn đề là hai giá trị này đang chạy trên hai đường ray khác nhau: một bên tối ưu tốc độ feedback loop code, một bên tối ưu tính đúng đắn của cấu trúc hệ thống. Chief EA giỏi không chọn phe. Họ hợp nhất hai đường ray đó thành một — bằng cách biến chuẩn kiến trúc thành thứ máy đọc được, và để chính pipeline CI/CD làm người gác cổng.

Bản chất

Cốt lõi của xung đột DevOps vs. EA nằm ở thời điểm kiểm tra tuân thủ (compliance check point), không phải ở bản chất của tuân thủ. TOGAF's Phase G (Governance, bài 20) đặt kiểm tra tuân thủ ở cuối vòng đời — sau khi kiến trúc đã được thiết kế, đôi khi sau khi đã build xong. Đó là mô hình phù hợp với waterfall, nơi thời gian giữa thiết kế và triển khai được tính bằng tháng.

DevOps đảo ngược giả định thời gian đó. Với CI/CD, thời gian từ commit đến production có thể là vài phút. Nếu compliance check vẫn nằm ở cuối — dạng review thủ công, hội đồng họp định kỳ — thì nó buộc phải tách rời khỏi vòng đời thực tế của code. Kết quả là một trong hai kịch bản tồi tệ: (1) governance trở thành nút thắt cổ chai, đội dev tìm cách né tránh hoặc trì hoãn review để kịp deadline; hoặc (2) governance bị bỏ qua hoàn toàn trong thực tế vận hành, chỉ còn tồn tại trên giấy tờ compliance.

Khái niệm giải quyết xung đột này là Architecture as Code (kiến trúc dưới dạng mã nguồn) và người anh em gần của nó, Policy as Code (chính sách dưới dạng mã nguồn). Ý tưởng cốt lõi: thay vì viết chuẩn kiến trúc dưới dạng tài liệu Word/Confluence mà con người phải đọc và diễn giải, bạn mã hóa các ràng buộc đó thành rule có thể chạy tự động — dưới dạng script, policy engine, hoặc test case — và nhúng chúng trực tiếp vào pipeline CI/CD.

Khi đó, compliance không còn là một giai đoạn (a phase) — nó trở thành một thuộc tính liên tục (a continuous property) của hệ thống, được xác nhận lại ở mỗi lần thay đổi. Đây chính là nguyên lý "shift-left" áp dụng cho governance: dịch chuyển điểm kiểm tra từ cuối vòng đời (Phase G) về càng gần điểm tạo ra thay đổi càng tốt (pull request, build, hoặc thậm chí IDE lúc code).

Điều quan trọng cần làm rõ với đội ngũ: Architecture as Code không thay thế vai trò của ARB (Architecture Review Board, bài 31) hay Compliance Review. Nó thay đổi tỷ trọng công việc — những gì có thể kiểm tra máy móc (naming convention, danh sách công nghệ được phép, cấu hình bảo mật cơ bản, dependency version) chuyển sang tự động; những gì cần phán đoán con người (trade-off kiến trúc, đánh giá rủi ro chiến lược, ngoại lệ có lý do chính đáng) vẫn ở lại với ARB. EA không biến mất khỏi vòng lặp — EA chuyển từ vai trò "người kiểm tra thủ công mọi thứ" sang "người thiết kế bộ luật mà máy kiểm tra hộ mình", đồng thời tập trung năng lực con người vào các quyết định thực sự cần tư duy kiến trúc.

Khung & Kỹ thuật áp dụng

Để đưa chuẩn kiến trúc vào pipeline CI/CD một cách có hệ thống, cần bốn thành phần phối hợp: nguồn chuẩn (từ đâu ra rule), cơ chế thực thi (chạy rule ở đâu), phân loại mức độ chặn (fail cứng hay chỉ cảnh báo), và vòng phản hồi (feedback loop) để cập nhật chuẩn.

1. Nguồn của các ràng buộc kiến trúc

Không phải mọi chuẩn kiến trúc đều mã hóa được, và không phải mọi chuẩn cần mã hóa. Hãy phân loại nguồn ràng buộc theo TOGAF domain:

2. Cơ chế thực thi trong pipeline

Kỹ thuật phổ biến, xếp theo điểm chèn trong CI/CD:

• Pre-commit / IDE hook: linter kiến trúc chạy ngay khi dev gõ code (nhanh nhất, feedback tức thời, nhưng dễ bị bypass với --no-verify).
• Pull Request check (CI): policy engine (kiểu Open Policy Agent/OPA, Conftest, hoặc custom script) quét static code, IaC template (Terraform, CloudFormation), Dockerfile, cấu hình Kubernetes — chặn merge nếu vi phạm rule đã định nghĩa.
• Build/Test stage: SAST (Static Application Security Testing), SCA (Software Composition Analysis) kiểm tra dependency có nằm trong TRM approved list và không có lỗ hổng CVE nghiêm trọng.
• Deploy gate: kiểm tra cấu hình runtime (network policy, IAM role, resource tagging) trước khi cho phép rollout — đây là điểm chặn cuối, gần nhất với "Compliance Review" truyền thống nhưng chạy tự động và tức thời.
• Post-deploy drift detection: quét định kỳ hạ tầng đang chạy để phát hiện cấu hình bị thay đổi thủ công (configuration drift) lệch khỏi baseline đã duyệt.

3. Ba mức độ chặn (severity tiering)

Sai lầm thường gặp khi mới triển khai Policy as Code là để mọi rule đều ở mức "block pipeline" — kết quả là đội dev phản kháng, tìm cách qua mặt, hoặc governance bị vô hiệu hóa vì quá nhiều false positive. Nên phân tầng rõ:

4. Vòng phản hồi ngược lên ADM

Đây là phần EA dễ bỏ sót nhất: pipeline không chỉ là nơi thực thi chuẩn, nó còn là nguồn dữ liệu để cập nhật chuẩn. Khi một rule liên tục bị vi phạm bởi nhiều team độc lập, đó thường không phải là "nhiều team làm sai" mà là dấu hiệu chuẩn kiến trúc đã lỗi thời hoặc không thực tế — cần đưa ngược vào Phase H (Change Management, bài 21) để xem xét cập nhật TRM hoặc chuẩn liên quan, thay vì chỉ tiếp tục chặn.

Case thực tế minh hoạ

(Đây là tình huống minh hoạ tổng hợp, không phải case của một công ty cụ thể, không có số liệu thật.)

Một tổ chức tài chính-công nghệ tầm trung vận hành khoảng 40 service trên Kubernetes, với hơn 15 đội phát triển triển khai độc lập nhiều lần mỗi ngày. Compliance Review theo mô hình cổ điển diễn ra mỗi quý: ARB họp, rà soát kiến trúc các service mới, đối chiếu với TRM và chuẩn bảo mật SABSA đã ban hành ở Phase D. Vấn đề nảy sinh liên tục: tại mỗi kỳ review, hội đồng phát hiện hàng loạt vi phạm đã tồn tại từ nhiều tuần đến vài tháng trước đó — dùng thư viện mã hóa không đạt chuẩn, mở port không qua Gateway, secret hardcode trong biến môi trường của container, service không gắn tag ownership khiến không rõ đội nào chịu trách nhiệm khi có sự cố.

Cách xử lý truyền thống là "phạt nguội": lập danh sách vi phạm, giao lại cho đội dev khắc phục sau, tạo backlog kỹ thuật (architecture debt — bài 32) chồng chất. Vấn đề của cách này không chỉ là chậm, mà là rủi ro đã hiện thực hóa: dữ liệu đã chạy qua kênh không an toàn trong suốt thời gian chưa bị phát hiện.

Chief EA của tổ chức, cùng với platform engineering team, chuyển hướng tiếp cận. Thay vì coi Compliance Review là điểm phát hiện, họ coi nó là điểm thiết kế lại luật chơi. Ba nhóm chuẩn được ưu tiên mã hóa hóa trước — chọn theo mức độ rủi ro cao và khả năng kiểm tra tự động cao: (1) danh sách thư viện mã hóa/bảo mật bắt buộc từ SABSA baseline, (2) quy tắc bắt buộc mọi ingress phải đi qua API Gateway chuẩn, (3) bắt buộc secret phải lấy từ secret manager, cấm hardcode. Các rule này được viết dưới dạng policy engine chạy ở PR check và deploy gate, với mức "Block" cho toàn bộ ba nhóm vì đây là rủi ro bảo mật trực tiếp.

Điểm mấu chốt về mặt tổ chức không nằm ở công cụ — nó nằm ở việc ARB dịch chuyển vai trò: từ "người phát hiện vi phạm sau khi đã xảy ra" sang "người định nghĩa luật chơi trước khi code được viết". Compliance Review định kỳ không biến mất, nhưng nội dung của nó thay đổi hẳn: thay vì rà từng service tìm lỗi cấu hình cơ bản, hội đồng dành thời gian cho các quyết định thực sự cần phán đoán — đánh giá ngoại lệ có lý do chính đáng, xem xét pattern kiến trúc mới, và quan trọng nhất là rà soát xem những rule tự động có đang phản ánh đúng thực tế công nghệ hay đã lỗi thời.

Kết quả định tính được ghi nhận sau một chu kỳ vận hành: số lượng vi phạm kiến trúc phát hiện muộn — tức là những vi phạm chỉ được biết đến tại kỳ Compliance Review, sau khi đã chạy production một thời gian — giảm rõ rệt, vì phần lớn vi phạm thuộc ba nhóm rủi ro cao nói trên giờ bị chặn ngay tại PR hoặc deploy gate, trước khi có cơ hội chạm production. Đồng thời, thời lượng Compliance Review được rút ngắn và tập trung hơn vào các quyết định kiến trúc có giá trị cao, thay vì việc kiểm tra cấu hình lặp đi lặp lại.

📐 Template/Artifact áp dụng ngay

Architecture Guardrail Catalog — bảng ánh xạ từ chuẩn kiến trúc sang kiểm tra tự động, dùng làm tài liệu sống (living artifact) giữa EA team và Platform/DevOps team. Nên review và cập nhật mỗi quý, đồng bộ với chu kỳ Phase G.

Cách dùng: mỗi rule mới được đề xuất trước tiên vào mức Advise (chỉ log, không chặn) trong 2-4 tuần để đo tỷ lệ false positive và mức độ ảnh hưởng thực tế lên các team, sau đó mới nâng lên Warn rồi Block theo lộ trình đã thông báo trước — tránh gây sốc pipeline cho toàn tổ chức trong một lần.

🎯 Góc nhìn Chief EA

Nếu một rule kiến trúc không thể diễn đạt thành điều kiện pass/fail rõ ràng, liệu nó có đang che giấu một quyết định thiết kế mơ hồ chưa từng được làm rõ?

Bao nhiêu phần trăm nội dung của kỳ Compliance Review gần nhất lẽ ra đã có thể bị chặn tự động ở PR — và tại sao nó vẫn phải chờ đến hội đồng?

Khi một guardrail tự động bị đội dev liên tục xin ngoại lệ, mình đang bảo vệ một chuẩn đúng đắn, hay đang bám một quy tắc đã lỗi thời với thực tế công nghệ?

Ai là người có quyền sửa rule trong policy engine — nếu câu trả lời là "chỉ EA", liệu guardrail có đang trở thành nút thắt cổ chai mới, đội lốt tự động hóa?

🔗 Bài viết liên quan

• Giai đoạn G: Governance & Compliance Review — mô hình Compliance Review cổ điển mà Architecture as Code đang tái định hình.
• Giai đoạn D: Technology Reference Model — nguồn chuẩn công nghệ để mã hóa thành policy tự động trong pipeline.

Bài trước: Agile Architecture · Bài tiếp theo: AI Governance