Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

290

14

章 継続性とダイナミックインフラストラクチャ

チェックを作っても無駄だ、なぜなら、定義上その問題は二度と起きないからだと言う人もいる。しか

し、現実には、フィックスはいつも動くとは限らず、関連する問題を解決しないことがある。そして、

以前のインシデントのことを知らない善意のチームメンバーがもとに戻してしまう場合さえある。

14.4.4.3

　

モ ニタリング 駆 動 開 発

そこで、本番環境の問題をフィックスするためのワークフローは、次のようになるだろう。

1. エンドユーザーのためにサーバーを復旧する。

2. 問題を検出するモニタリングチェックを作り、問題を再現してチェックが機能することを証明す

る自動テストを作る。

3. 問題に対するフィックスを作る。

4. これらすべて（フィックス、テスト、モニタリング）を VCS にコミットし、それらがパイプライン

を進んで本番システムに組み込まれることを確認する。

これがインフラストラクチャ版の TDD（テスト駆動開発）である。

14.5

　

セ キュリティ

あらゆるITシステムの設計と実装には、セキュリティが織り込まれていなければならない。

Infrastructure as Codeは、システムを繰り返し、確実に、透過的に構築し、検証することによって、

システムが十分に保護されるようなプラットフォームとして使うことができる。しかし、システムのプ

ロビジョニングと管理のために使われるオートメーションとその基礎となるプログラマブルインフラス

トラクチャプ ...