IaCによって驚くほどの速度で操作を実行できるようになる。この速さにはメリットもデメリットもある。IaCによる実行の即時性は、コードの作成方法によって決まる。操作を完了する前に、管理者に入力を求めるプロンプトを含める組織もある。こうした一時中断は、全てのコードが想定通りに機能していることを確認する安全性チェックになる。これにより、バグや単純なスペルミスなどのうっかりミスの影響が、想定した範囲外に及ばないようチェックできる。

　管理者が一時中断や停止を考えなくても、IaCの自動化機能がコードに含まれる問題やバグを解決する。これは単純なスクリプトから包括的なオーケストレーションに至るまで、どのような形式の自動化でも新しい考え方ではない。だがIaCでは、特にコード更新の影響がIT環境内のどの程度の範囲まで及ぶかが課題になる。スクリプトや他の種類のバッチファイルは影響が及ぶ範囲が限定されるため、予想外の損傷も限られる。

　IaCは課題やエラーの影響が深刻になりやすい。影響が及ぶ範囲が、1つのサーバやアプリケーションで切り離されることがないためだ。不適切なストレージ割り当てはI/Oの問題につながる。ネットワークの構成ミスはパケットの損失を招く。こうしたコード内の1つのバグが、一連のリソースに影響する恐れがある。その影響が瞬く間に全社に広がる恐れもある。

　こうしたドミノ倒しのような影響の広がり方が、スクリプトとは異なるIaCのリスクレベルになる。効率的になるほど、潜在的なリスクも高まる。

　IaCはコードの厳密な管理やテスト、リリースの各プロセスが適切に進行しなければ機能しない。インフラを稼働させる重要性は非常に大きい。IaCを導入する場合、IT部門は綿密な計画を立て、それをドキュメントに落とし込まなければならない。

コードのバリエーションによる複雑性

　IaCのコード開発は、教科書に詳しく載っているようなステップバイステップのプロセスではなく、ビジネスニーズやプロセスに大きく左右される。それはインフラエンジニアがインフラを設計する場合と変わらない。ほぼ同じように機能するコードでも、その内容は開発者ごとに異なる。

　コードが開発者個人に依存しても、コードが特殊であっても、そのコードが機能している間にコードの開発者が退職しない限り、IT部門にとって問題にはならない。だがその開発者がいなくなってしまうと、新しい管理者はなじみのない極めて個人的なコードを理解しなければならなくなる。

　繰り返しになるが、問題になるのは、影響が及ぶ範囲とその影響の程度だ。新しい管理者にとって明らかな問題になるのはコード自体ではない。どちらかといえば、コードの構成とドキュメントだ。最終的に影響が及ぶ範囲を考えると、新しい管理者がコードを本番環境に移す前に、本番環境から隔離されたサンドボックスでテスト運用できる見込みは低い。

　これは属人的な課題のように見えるが、IaCの別の重要な問題を浮き彫りにしている。つまりIaCを始めるなら、従来の既成製品が提供しないような手厚いサポート体制が必要になる。

　こうした課題があるからといって、IaCの導入をためらうことはない。ただし次のような注意が必要だ。

• 多数の製品を利用できる大規模なテスト環境を用意して、管理者やインフラエンジニアがコードをテストできるようにする
• コードの開発と改訂を管理する具体的かつ包括的なルールを作成する
• 徹底したドキュメントを作成し、そのドキュメントを絶えず更新する。複数のスタッフがIaCを担当し、単一障害点を全て取り除くことができるようにする

　IaCには、スタッフの精通度や専門知識が必要なだけでなく、多くのリソースも必要になる。特にドキュメントの作成には時間がかかる。だがこうした要件を満たせば、IaCはSDDCに大混乱をもたらす厄介な存在にはならないだろう。