Họ đang đo gì
Bạn có nghĩ tới khôi phục sau sự cố và tới việc kiểm toán không, hay chỉ tới việc gõ ít lệnh hơn.
Trả lời ngắn~30 giây
Ba lý do lớn hơn tự động hoá. Một: hạ tầng đi qua code review — ai đó nhìn thấy security group vừa mở port 22 ra internet TRƯỚC khi nó tồn tại. Hai: dựng lại được — mất một vùng thì bạn apply sang vùng khác thay vì cố nhớ lại bốn mươi thao tác. Ba: có lịch sử — git blame trả lời được “ai mở cái này và vì sao”, thứ mà console không bao giờ trả lời được.
Giải thích sâu
Điều làm IaC thất bại trong thực tế là drift: ai đó sửa tay trong console lúc đang có sự cố (hợp lý), rồi không đưa ngược vào code (không hợp lý), và lần apply sau xoá mất bản sửa đó. Cách xử lý là chạy plan định kỳ trong CI và cảnh báo khi có khác biệt — biến drift từ một quả bom hẹn giờ thành một thông báo.
Chi tiết vận hành quan trọng nhất là state: file state của Terraform chứa mọi thứ nó quản lý, kể cả một số giá trị nhạy cảm, và hai lần apply song song sẽ làm hỏng nó. Nên state phải nằm ở backend từ xa có KHOÁ (S3 + DynamoDB, hoặc Terraform Cloud), không bao giờ nằm trong git. Đây là câu hỏi phụ gần như chắc chắn, và trả lời sai là dấu hiệu chỉ dùng Terraform một mình chứ chưa dùng trong đội.
Câu hỏi tiếp theo họ sẽ hỏi
?Hạ tầng có cần test không?
Có, ở hai tầng: kiểm tra chính sách trước khi apply (Checkov, OPA — “không bucket nào được public”), và kiểm tra sau khi apply rằng thứ vừa dựng thật sự hoạt động. plan cho bạn thấy sẽ thay đổi gì, nó không cho bạn biết thay đổi đó có đúng không.
Trả lời thế này là mất điểm
- Commit file state vào git. Nó chứa dữ liệu nhạy cảm và không có khoá, nên hai người apply cùng lúc là hỏng.