先日、オライリー「Infrastructure as Code」の日本語版が発売されました。 www.oreilly.co.jp
副題にある通り「原則とプラクティス」をメインに書かれていて、特定のツールに依存しない内容になっています。 特に1章「課題と原則」は何度も読み直したくなる内容でした。（さらに言うと"1.2.1 Infrastructure as Code の目標" は壁に貼っておきたいような内容）
全体としては 「 予防より復旧 」が重要という印象をうけました。
一通り読んでみましたので、個人的に印象に残ったポイントをまとめます。
1. 大きな変更より小さな変更を日常的にする
- 小さな変更のほうが失敗したときに問題を特定しやすく、戻しやすい。
- 小さな変更のほうが確実に改善でき、モチベーションも保たれる。
2. システムを絶えず変更し、改良しているチームの方が大小の障害に対処できる力を持っている
- "1.6 アンチフラジャイル：「堅牢」を超えて" からの引用。
- 人体と同じように負荷、変更を避けると弱くなる。負荷、変更によって強化される。
3. 正しい設計は継続的に変化していく
- "15.1 発展的なアーキテクチャ" からの引用。
- 完全で「最終的な」設計にたどり着くことはない
4. 高速フィードバック
- 誤りは早く検出、フィードバックさせることが品質を向上させる。
- そのためにはモニタリングが重要。
5. 従来のインフラからマイグレーション時の注意点
- 従来のパターンを当てはめようとすると、かえって複雑になる可能性があるため、今までの概念を破る必要がある。
6. おまけ：初めて聞いた言葉
「構成ドリフト」
- 設定差異のこと。差異があること自体は悪くないが、管理できていなくてはならない。管理できていない差異はオートメーション恐怖症を生み出す。
「スノーフレークサーバー」
- 他と異なるサーバーのこと。なぜ異なるのか分からなかったり、再構築できない状態は問題である。
「システム疲労」
- 時間の経過でインフラが壊れていくこと。要因としては、脆弱性、ストレージの残容量など。
「フェニックス交換」
- ブルー - グリーン 交換の進化形で、Immutable Infrastructure の基礎。
Infrastructure as Code の考え方を知るにとても良い本だと感じました。
