7 best practice về Infrastructure as Code team DevOps cần nắm vững

Phạm Đăng Sa

2216

16-09-2026

Terraform, OpenTofu và AI đang thúc đẩy các team áp dụng IaC đúng cách.

44% tổ chức cho biết họ gặp tình trạng Infrastructure Drift trong môi trường cloud, phần lớn do việc provisioning được thực hiện ngoài quy trình Infrastructure as Code (IaC). Điều này có nghĩa gần một nửa team có cloud resources không còn khớp với cấu hình trong code. Năm 2026, đây không chỉ là vấn đề kỹ thuật mà còn là rủi ro về chi phí và tài chính, đặc biệt khi AI-generated workloads phát triển nhanh và cloud spending được kiểm soát chặt chẽ.

Hệ sinh thái IaC ngày càng trưởng thành và mạnh mẽ, nhưng cũng có nhiều cách để triển khai sai. Terraform BSL, sự phát triển của OpenTofu, AI-generated code thiếu kiểm soát và secrets sprawl đang khiến năm 2026 trở thành thời điểm các team IaC cần tăng cường quản trị và bảo mật.

Bài viết tập trung vào 7 best practices về IaC giúp các team triển khai tự tin hơn và giảm sự cố trong production. Đây là những phương pháp đã được nhiều team engineering tại các công ty tăng trưởng nhanh áp dụng trong thời gian gần đây.

1. Bảo vệ State File như thông tin tối mật

Terraform và OpenTofu state file là nguồn dữ liệu quan trọng phản ánh trạng thái thực tế của hạ tầng. Chúng liên kết code với các cloud resources đã triển khai và có thể chứa secrets, database connection strings và API tokens dưới dạng plaintext.

Do đó, nên sử dụng remote state backend với cơ chế locking để bảo vệ state và tránh các lần apply đồng thời gây lỗi hoặc làm hỏng state. Có thể dùng S3 + DB cho state locking.

Cấu hình remote state và locking khá đơn giản, nhưng cần được triển khai như một yêu cầu bảo mật bắt buộc.

Checklist bảo mật State File

• Sử dụng remote backend (S3, Terraform Cloud hoặc Scalr), không lưu local.

• Bật state locking để tránh các apply đồng thời.

• Mã hóa state khi lưu trữ (at rest); OpenTofu 1.7+ hỗ trợ mã hóa state tích hợp.

• Áp dụng least-privilege IAM cho state bucket; chỉ CI runner cần quyền ghi.

• Bật versioning để có thể khôi phục state về phiên bản ổn định sau khi apply lỗi.

Một practice thường bị xem nhẹ là chia state file theo environment và logical domain. State file quá lớn cho toàn bộ platform sẽ làm tăng blast radius. Nếu state của module database production gặp lỗi, không nên để nó ảnh hưởng đến networking. State file nhỏ và có phạm vi rõ ràng cũng giúp terraform plan nhanh hơn và diff dễ đọc hơn.

2. Không để Plan được Apply nếu chưa có người phê duyệt

Các lệnh terraform apply chạy trực tiếp trên máy local có thể bỏ qua CI pipeline, policy checks, cost estimation và audit trail, làm tăng rủi ro cho hạ tầng.

Nên coi Terraform plan là một artifact bất biến:

• Pipeline tạo plan.

• Con người review và phê duyệt.

• Apply chính binary plan đã được review, không tạo plan mới.

Cách này đảm bảo những gì được review chính là những gì được triển khai, tránh sai lệch giữa plan và deployment.

Chỉ riêng Checkov đã phát hiện trung bình 14 lỗi cấu hình sai với mức độ nghiêm trọng cao trên mỗi 1.000 dòng mã IaC tại các team chưa từng triển khai quét bảo mật. Khi tích hợp công cụ này vào quy trình CI, con số đó sẽ giảm xuống gần bằng 0 chỉ trong vòng một quý.

3. Không hardcode Secrets

Theo báo cáo State of Secrets Sprawl 2026, số secrets bị lộ trong code repository đã tăng 152% từ năm 2021. Đáng chú ý, 64% secrets được xác nhận hợp lệ trong năm 2022 vẫn có thể bị khai thác sau 4 năm.

Nguyên tắc: Không để secrets trong Terraform code, variable files hoặc state outputs.

Quy trình nên áp dụng:

• Dùng Terraform để provision resource, chẳng hạn RDS.

• Lưu secret được tạo vào HashiCorp Vault, AWS Secrets Manager hoặc GCP Secret Manager trong quá trình apply.

• Ứng dụng lấy secret khi runtime thông qua SDK hoặc sidecar injection.

• Không dùng terraform output để expose secrets vì dữ liệu có thể xuất hiện trên stdout và bị ghi vào log.

Với OpenTofu 1.7+, có thể sử dụng native state encryption với AES-256-GCM hoặc PBKDF2 để mã hóa state khi lưu trữ, giúp bảo vệ cả metadata có thể chứa secrets.

4. Duy trì phát hiện Drift liên tục, thay vì theo từng đợt

Drift sẽ xảy ra. Nhà phát triển có thể đăng nhập console và tự điều chỉnh Auto Scaling Group. Hệ thống tự động có thể thay đổi một security group rule. Nhà cung cấp cloud có thể âm thầm cập nhật cấu hình mặc định của một managed service. Dù nguyên nhân là gì, kết quả vẫn giống nhau: hạ tầng thực tế không còn khớp với code. Nếu không được phát hiện, lần chạy terraform plan tiếp theo có thể yêu cầu destroy rồi recreate một resource đang phục vụ production.

Giải pháp năm 2026 không phải là hy vọng không ai thay đổi trên console, mà là biến việc phát hiện drift thành một quy trình liên tục và tự động, có khả năng xử lý. Các công cụ như Driftctl, module drift của Infracost, cùng các tính năng tích hợp trong Spacelift và env0 có thể chạy terraform plan theo lịch trên state và cảnh báo hoặc tự động khắc phục khi phát hiện sai lệch.

Thực hành phát hiện Drift

• Chạy terraform plan mỗi đêm trên tất cả môi trường; coi mọi drift là sự cố P2.

• Dùng OPA (Open Policy Agent) để xác định drift nào có thể tự động khắc phục và drift nào cần con người xem xét.

• Gắn tag managed-by: terraform cho mọi cloud resource; resource không có tag này được xem là nằm ngoài quy trình quản lý bằng Terraform.

• Năm 2026, tự động khắc phục drift, không chỉ phát hiện, đã trở thành yêu cầu cơ bản. Nếu công cụ chỉ cảnh báo, nên nâng cấp.

5. Versioning cho Module là bắt buộc - hay hợp đồng API

Nếu team vẫn tham chiếu các Terraform module dùng chung thông qua branch Git như ?ref=main, chỉ cần một lần refactor là có thể dẫn đến lỗi dây chuyền trên nhiều môi trường. Module là một API, vì vậy module cần được version, publish và sử dụng thông qua các semantic version được cố định.

Cách tiếp cận phù hợp ở quy mô lớn trong năm nay là đưa module vào một registry riêng (private module registry của HashiCorp, module registry của Spacelift hoặc registry dựa trên Git thông qua Terramate). Mỗi lần merge vào repository của module sẽ kích hoạt CI pipeline chạy terraform validate, tflint và bộ test bằng Terratest hoặc framework terraform test tích hợp từ Terraform 1.6 / OpenTofu 1.6. Nếu build đạt, một tag semver mới sẽ được publish. Các module được sử dụng phải tham chiếu rõ ràng đến version cụ thể.

Hãy thêm các validation blocks vào các biến đầu vào của module. Một biến được khai báo với kiểu `string` và dự kiến nhận giá trị là dải CIDR cần được kiểm tra bằng biểu thức chính quy (regex). Hãy phát hiện lỗi sớm ngay ở giai đoạn lập kế hoạch (plan time), thay vì đợi đến giai đoạn triển khai (apply time), lúc đó một dải CIDR không hợp lệ có thể dẫn đến tình trạng VPC chỉ được triển khai một phần.

6. GitOps là lớp quản trị - nếu không sử dụng, bạn không thực sự có cơ chế quản trị

GitOps đã chuyển từ một thành phần đáng chú ý thành tiêu chuẩn vận hành cơ bản vào năm 2026. Định nghĩa khá đơn giản: Git là nguồn sự thật duy nhất cho toàn bộ trạng thái hạ tầng, mọi thay đổi đối với hạ tầng đều được thực hiện thông qua pull request (PR), và không ai được trực tiếp áp dụng thay đổi lên production nếu không có quy trình phê duyệt được ghi nhận qua PR. Nếu cloud của bạn vẫn có thể được thay đổi kha khá bên ngoài Git, thì đó chưa phải là governance, mà chỉ là kỳ vọng.

Đối với IaC, điều này có nghĩa là sử dụng các công cụ như Atlantis, Spacelift hoặc env0 làm lớp trung gian giữa Git repository và cloud provider. Developer tạo một PR, hệ thống tự động chạy terraform plan và đưa diff vào phần comment của PR, một thành viên khác review và phê duyệt, sau đó hệ thống tự động thực hiện apply. Đơn giản, có thể kiểm tra và có thể rollback.

Điểm đáng chú ý trong năm 2026 là: 71% các cloud team cho biết công cụ GenAI đang làm tăng khối lượng IaC được tạo ra, nhưng 63% trong cùng nhóm cho rằng hạ tầng do AI tạo ra khó quản trị hơn code do kỹ sư viết. Giải pháp không phải là cấm sử dụng AI trong IaC. Thay vào đó, cần biến pipeline GitOps thành điểm kiểm soát bắt buộc mà mọi thay đổi — do con người hay AI tạo ra — đều phải đi qua.

Áp dụng các policy OPA trong pipeline. Yêu cầu hai người review đối với những thay đổi liên quan đến networking, IAM hoặc data resources. Con người vẫn tham gia vào quy trình; chỉ là họ dành thời gian review diff thay vì viết phần code lặp lại.

7. Chọn công cụ IaC có chủ đích — Quyết định giữa Terraform và OpenTofu không còn đơn giản

Tháng 12/2024, IBM hoàn tất thương vụ mua lại HashiCorp trị giá 6,4 tỷ USD. Terraform sử dụng Business Source License (BSL), vốn hạn chế một số hình thức sử dụng trong các sản phẩm cạnh tranh. Trong khi đó, OpenTofu — fork của Terraform do Linux Foundation hỗ trợ và phát hành theo MPL 2.0 — đang dần được áp dụng rộng rãi hơn. Tính đến Q1/2026, OpenTofu đạt 12% mức độ sử dụng trong cộng đồng IaC, với 27% team đang cân nhắc chuyển đổi.

OpenTofu tương thích về chức năng với Terraform đến bộ tính năng 1.5 và bổ sung một số khả năng như mã hóa state, cải thiện quy trình phát triển provider và quy trình RFC minh bạch hơn.

Terraform vs. OpenTofu - Có thể cân nhắc:

• Chọn Terraform nếu: đang sử dụng HCP Terraform/Terraform Cloud, phụ thuộc vào Sentinel hoặc có hợp đồng hỗ trợ doanh nghiệp với IBM.

• Chọn OpenTofu nếu: sử dụng bản open-source và không phụ thuộc HCP, cần mã hóa state hoặc ưu tiên hệ sinh thái OSS.

• Kết hợp cả hai: duy trì Terraform cho các môi trường cũ phụ thuộc HCP và dùng OpenTofu cho các dự án mới.

• Dù chọn công cụ nào: nên cố định phiên bản provider trong required_providers và phiên bản công cụ trong required_version để việc chuyển đổi sau này dễ dàng hơn.

Nếu đang cân nhắc Pulumi, cần lưu ý đây là một hướng tiếp cận khác. Pulumi sử dụng các ngôn ngữ lập trình phổ biến như TypeScript, Python và Go, phù hợp với team cần xử lý logic phức tạp. Tuy nhiên, Pulumi không phải lựa chọn thay thế trực tiếp cho Terraform/OpenTofu, vì mô hình IaC khác nhau và quá trình chuyển đổi cần tính đến công sức migration.

Tóm lại: IaC là kỷ luật, không còn là side task

Infrastructure as Code (IaC) từng chỉ giúp giảm việc thao tác thủ công trên cloud. Nhưng đến năm 2026, IaC đã trở thành nền tảng cho bảo mật, quản lý chi phí, compliance và khả năng khôi phục sự cố.

Các team làm tốt thường không cần gì quá phức tạp: họ bảo vệ state file, quản lý mọi thay đổi qua pull request, tích hợp Checkov vào CI, version hóa module, kiểm tra drift định kỳ và chọn Terraform hoặc OpenTofu dựa trên yêu cầu thực tế.

Ngược lại, những team còn xem nhẹ IaC có thể gặp rủi ro lớn chỉ từ một lần terraform apply sai hoặc một file secrets bị lộ.

Đừng chờ đến sprint sau. Hãy chọn một trong 7 practices và triển khai ngay trong tuần này. IaC hygiene tích lũy theo thời gian — và thường chỉ thấy giá trị rõ nhất khi bạn thực sự cần infrastructure ổn định.