Review tác động Terraform plan bằng AI trước khi apply
Dùng AI để biến Terraform plan thành checklist review có ngữ cảnh vận hành trước khi apply, đồng thời giữ Terraform và người chịu trách nhiệm ở vai trò quyết định cuối cùng.
Một thay đổi IaC chỉ vài dòng trong PR vẫn có thể tạo ra tác động lớn khi apply. Vì vậy, đọc cấu hình là chưa đủ: team cần review cả Terraform plan — bản mô tả những gì Terraform dự kiến thực hiện với hạ tầng.
AI không thay Terraform tính toán thay đổi, cũng không nên là người phê duyệt. Vai trò phù hợp hơn là đọc plan theo ngữ cảnh vận hành, nêu câu hỏi cần xác minh và biến output dài thành checklist rõ ràng trước apply.
Với DevOps, SRE và platform engineer, cách làm này giúp review IaC nhất quán hơn, đặc biệt khi plan dài, module lồng nhau hoặc thay đổi diễn ra sau một incident.
Terraform plan thực sự cho biết điều gì?
Khi tạo plan theo chế độ mặc định, Terraform sẽ:
Đọc trạng thái hiện tại của các đối tượng remote đang tồn tại để cập nhật state.
So sánh cấu hình hiện tại với state trước đó.
Đề xuất các hành động để đưa đối tượng remote khớp với cấu hình.
Quan trọng: terraform plan không thực thi thay đổi. Đây là vị trí phù hợp để đưa AI vào quy trình review: Terraform đã tính tác động, nhưng pipeline chưa apply.
Có hai dạng plan cần phân biệt:
Speculative plan: chạy terraform plan không kèm -out. Plan này hữu ích để kiểm tra tác động trước khi gửi PR hoặc code review.
Plan lưu ra file: dùng -out=FILE. File plan sau đó có thể được truyền cho terraform apply, nên phù hợp với automation.
Terraform lưu ý rằng speculative plan có thể không còn phản ánh đúng trạng thái hệ thống tại thời điểm apply, vì target system có thể thay đổi trong lúc chờ review. Do đó, AI có thể review plan ở giai đoạn PR, nhưng team vẫn nên kiểm tra lại plan cuối ngay trước apply.
> AI là lớp hỗ trợ đặt câu hỏi. Terraform là nguồn tính toán thay đổi. Người chịu trách nhiệm hệ thống vẫn quyết định có apply hay không.
Workflow: tạo plan, AI review, rồi xác nhận trước apply
Bắt đầu từ thư mục chứa cấu hình root module:
bash
terraform plan -out=<plan-file>
Để có dữ liệu máy đọc được, xuất plan bằng:
bash
terraform show -json <plan-file>
terraform show có thể hiển thị plan hoặc state. Khi dùng -json với plan file, đầu ra bao gồm biểu diễn JSON của plan, cấu hình và current state, phù hợp cho parser nội bộ hoặc bước AI review có cấu trúc.
Lưu ý: để xem plan bằng terraform show -json, plan đó phải được tạo không dùng -refresh=false.
Một luồng CI/CD thực tế có thể gồm:
Chạy plan trong CI với backend, workspace và quyền truy cập phù hợp.
Lưu plan artifact để phục vụ bước apply.
Xuất dữ liệu cần review từ plan và lọc theo chính sách nội bộ.
Đưa phần đã lọc vào AI để phân loại thay đổi và tạo câu hỏi review.
Đối chiếu kết quả AI với plan dạng người đọc được và bối cảnh service.
Tạo hoặc kiểm tra lại plan cuối nếu đã có thời gian chờ review hoặc có khả năng thay đổi ngoài Terraform.
Chỉ apply khi người chịu trách nhiệm xác nhận checklist.
Không nên để AI tự chạy Terraform hoặc tự có quyền cloud. AI chỉ nên nhận dữ liệu đã được kiểm soát và trả về báo cáo review.
Đừng đưa nguyên plan JSON vào công cụ AI công cộng
Tài liệu Terraform cảnh báo rằng terraform show -json có thể hiển thị sensitive values trong state dưới dạng plain text.
Vì vậy, trước khi gửi dữ liệu sang AI, cần lọc theo chính sách của tổ chức. Đặc biệt, không đưa secret, token hoặc thông tin nhạy cảm vào chatbot công cộng hay dịch vụ AI chưa được phê duyệt.
Mục tiêu không phải là gửi toàn bộ plan. Mục tiêu là gửi đủ thông tin để AI hỗ trợ review mà không làm lộ dữ liệu nhạy cảm.
Prompt để AI tạo checklist thay vì “phê duyệt”
Prompt “plan này có an toàn không?” thường tạo ra câu trả lời mơ hồ. Thay vào đó, hãy yêu cầu AI tách rõ điều quan sát được, điều cần xác minh và giới hạn của plan.
Mẫu prompt:
text
Bạn là reviewer Terraform cho môi trường <environment>.
Dựa CHỈ trên Terraform plan đã được lọc bên dưới, hãy tạo báo cáo review.
Không suy đoán tài nguyên, cấu hình hoặc thay đổi không có trong input.
Ngữ cảnh dịch vụ:
Service/owner: <service-owner>
Mức độ quan trọng: <criticality>
Cửa sổ thay đổi: <change-window>
Phụ thuộc đáng chú ý: <dependencies>
Incident hoặc thay đổi thủ công gần đây: <incident-context>
Yêu cầu:
Liệt kê các thay đổi thể hiện trong plan.
Đánh dấu những thay đổi cần owner xác nhận trước apply.
Nêu các câu hỏi về tác động vận hành, phụ thuộc và khả năng khôi phục.
Phân biệt rõ:
Quan sát từ plan
Rủi ro cần xác minh
Điều không thể kết luận từ plan
Trả về checklist GO/NO-GO cho người review.
Không tự quyết định GO.
Plan đã lọc:
<sanitized-plan-json-or-text>
Điểm quan trọng là AI không được biến giả định thành sự thật. Nếu plan không thể hiện rõ tác động đến workload, traffic hoặc monitoring, câu trả lời đúng phải là: cần xác minh thêm.
Walkthrough: từ plan artifact đến checklist có người chịu trách nhiệm
Giả sử một PR thay đổi hạ tầng của <service-name>.
Pipeline tạo plan artifact:
bash
terraform plan -out=<plan-file>
Job review xuất dữ liệu có cấu trúc:
bash
terraform show -json <plan-file>
Sau khi lọc dữ liệu nhạy cảm, pipeline hoặc reviewer đưa phần cần thiết vào AI cùng bối cảnh service.
Một báo cáo review hữu ích nên có dạng:
Quan sát từ plan: plan thể hiện thay đổi tại <resource-address>.
Rủi ro cần xác minh: thay đổi này có thể cần kiểm tra tác động đến thành phần phụ thuộc.
Câu hỏi cho owner: thay đổi có nằm trong phạm vi dự kiến không? Có cần cửa sổ bảo trì không?
Điều chưa thể kết luận: plan không tự cho biết sức khỏe workload, lưu lượng thực tế hay chỉ số lỗi sau apply.
Checklist: owner xác nhận mục đích; reviewer xác nhận phạm vi; người vận hành xác nhận monitoring và phương án xử lý nếu có vấn đề.
Giá trị của AI nằm ở việc khiến các câu hỏi vận hành xuất hiện đều đặn, thay vì phụ thuộc hoàn toàn vào kinh nghiệm của từng reviewer.
Dùng refresh-only để đối chiếu thay đổi ngoài Terraform
Sau incident, team đôi khi phải thay đổi trực tiếp remote object để khôi phục dịch vụ. Khi đó, Terraform state có thể không còn phản ánh đúng những gì đang tồn tại.
Terraform có chế độ refresh-only:
bash
terraform plan -refresh-only
Chế độ này tạo plan chỉ nhằm cập nhật Terraform state và output cấp root module để khớp với thay đổi đã xảy ra trên remote objects. Đây là lựa chọn phù hợp khi cần đối chiếu lại bản ghi Terraform sau thay đổi ngoài quy trình thông thường.
AI có thể hỗ trợ đặt câu hỏi trong bước này:
Thay đổi nào cần owner xác nhận?
Thay đổi nào có thể liên quan đến incident vừa xảy ra?
Thay đổi nào chưa có giải thích?
Quyết định tiếp theo là ghi nhận thay đổi, cập nhật cấu hình hay điều tra thêm?
Tuy nhiên, refresh-only không tự quyết định thay đổi ngoài Terraform có nên được giữ lại trong cấu hình hay không. Quyết định đó vẫn thuộc về owner và quy trình vận hành của team.
Ngoài ra, tránh dùng -refresh=false khi mục tiêu là review rủi ro production. Tùy chọn này bỏ qua việc đồng bộ state với remote objects trước khi kiểm tra thay đổi, và Terraform cảnh báo plan khi đó có thể không đầy đủ hoặc không chính xác.
Các hàng rào không nên bỏ qua
AI review chỉ có ích khi đứng sau các kiểm soát kỹ thuật và quy trình rõ ràng:
Không đưa secrets vào AI. terraform show -json có thể hiển thị sensitive values dạng plain text.
Không cho AI tự apply. AI chỉ tạo báo cáo; approval phải nằm trong CI/CD controls và quy trình change management.
Không dựa vào speculative plan cũ. Cần kiểm tra lại plan cuối trước apply nếu hệ thống có thể đã thay đổi.
Không bỏ human review. Plan không thay thế observability, dependency map, runbook hay hiểu biết về workload.
Không coi AI là nguồn sự thật. AI phải nêu rõ điều nào quan sát được từ input và điều nào cần xác minh thêm.
Checklist trước apply
[ ] Plan cuối được tạo từ phiên bản code đã review.
[ ] Plan được kiểm tra lại trước apply nếu có thời gian chờ hoặc thay đổi ngoài Terraform.
[ ] Dữ liệu gửi vào AI đã được lọc thông tin nhạy cảm.
[ ] AI đã nêu các thay đổi và câu hỏi cần owner xác nhận.
[ ] Owner đã xác nhận phạm vi và mục đích thay đổi.
[ ] Monitoring, phương án xử lý sự cố và người chịu trách nhiệm đã sẵn sàng.
AI không làm Terraform plan an toàn một cách tự động. Nhưng khi được đặt đúng vị trí trong pipeline, nó có thể biến một output khó đọc thành danh sách câu hỏi vận hành cụ thể — trước khi thay đổi chạm vào production.