目次

第0章　Webアプリケーションの運用の理想と現実

0.1　業務向けWebアプリの開発スタート

• 0.1.1　クラウドでシステム構築する際の問題解決
• 0.1.2　QCDSの決定とウォーターフォールモデル
• 0.1.3　クラウドにすべきか、オンプレミスにすべきか

0.2　理想の業務システム

• 0.2.1　変化に対応するシステムが理想

0.3　本書で取り上げるシステムのアーキテクチャ

• 0.3.1　AWSアーキテクチャ
• 0.3.2　各種環境の解説
• 0.3.3　Infrastructure as Codeの必要性

0.4　開発チーム・基盤チーム・デリバリーチームの役割

0.5　本書の読み進め方

• 0.5.1　IaCは魔法の杖か
• 0.5.2　運用改善のサイクルを作る

第1章　本番リリースをすると、なぜか問題発生

1.1　本番システムをリリースするときに問題が起こるのはなぜか

1.2　リリース作業時トラブルの実際

• 1.2.1　テストでは問題なし。しかし本番環境で動作不良？

1.3　リリース作業に向けたプロセス

• 1.3.1　［1］リリース計画の作成
• 1.3.2　［2］各チームの作業項目の整理
• 1.3.3　［3］手順書の作成
• 1.3.4　［4］リハーサルの実施

1.4　リリース作業でのエラー発生

• 1.4.1　再デプロイの実施、動作確認終了まで3時間超過
• 1.4.2　一難去ってまた一難
• 1.4.3　手探りで原因の切り分け

1.5　ECS構築時のトラブル

1.6　AWSの設定構築の落とし穴

• 1.6.1　原因［その1］「 大量の設定パラメータと頻繁な変更？」
• 1.6.2　原因［その2］「 クラウド運用とアプリケーション運用が絡みあう？」
• 1.6.3　原因［その3］「 チーム間の連携の不備？」

1.7　まとめ

第2章　IaCの導入による問題解決

2.1　AWS CDKの導入

• 2.1.1　AWSの設定値情報を振り返る
• 2.1.2　AWSの構成管理
• 2.1.3　AWSの設定値の管理の難しさ
• 2.1.4　IaCを使った改善活動

2.2　AWSを管理するためのドキュメントの整理

• 2.2.1　システム概要図
• 2.2.2　アーキテクチャ図
• 2.2.3　プロトコル図
• 2.2.4　基本設計書
• 2.2.5　パラメータシートや管理台帳

2.3　リリース手順の標準化

• 2.3.1　作業項目の洗い出し
• 2.3.2　作業項目の整理
• 2.3.3　例外的な処理から対応策を準備する

2.4　変更発生に即時更新するために

2.5　IaCによる構成管理とは

• 2.5.1　IaCの利用例
• 2.5.2　CloudFormationとAWS CDK
• 2.5.3　IaC導入の観点①
• 2.5.4　IaC導入の観点②

2.6　リリース手順のIaC化の実際

2.7　運用ルールの検討と決定

• 2.7.1　リリースの判断基準
• 2.7.2　IaCの運用

第3章　障害対応が遅れる根本原因

3.1　なぜ障害対応が遅れてしまうのか

3.2　場当たり的なトラブル対応でおざなり運用

• 3.2.1　問題の勃発

3.3　障害復旧が大幅に遅延した理由とは

• 3.3.1　後回しの運用設計

3.4　障害と対応項目の洗い出し方

• 3.4.1　対応プロセスの定義の仕方
• 3.4.2　懸念材料と検討方法

3.5　ログの分析による対応の迅速化

• 3.5.1　ログ分析の準備

第4章　無視されるシステムアラートを見直す

4.1　なぜアラートが軽視されるのか

• 4.1.1　アラート設定の2つの落とし穴

4.2　アラートのオオカミ少年問題

• 4.2.1　アラートの発生

4.3　アラートの見直し

• 4.3.1　念のため設定の陥穽――無駄なのか有用なのか
• 4.3.2　アラートの隠蔽――障害修正の先送り
• 4.3.3　困難な問題の切り分け――多面的な原因のため修正箇所がわからない

4.4　アラート設計の基本

4.5　障害発生のリスクをベースにアラート設計を見直す

• 4.5.1　アラートとインシデントの現状分析
• 4.5.2　既存アラートの課題抽出
• 4.5.3　モニタリング手法の再検討

4.6　アラートの定期的評価と改善

• 4.6.1　アラートかノイズか見極めるには
• 4.6.2　重要度の見直し・設定
• 4.6.3　アラートに対してのアクション定義

第5章　効率化という名の属人化による弊害

5.1　属人化で生まれる負のスパイラル

5.2　1人に集中するトラブル対応

• 5.2.1　トラブルシュート体制作り
• 5.2.2　負のスパイラルの発生

5.3　実は理解されていなかったシステムの勘所

• 5.3.1　振り返りミーティングでわかったこと
• 5.3.2　知見共有の大切さ

5.4　孤独な担当者にしないために――関係者のコミュニケーション

5.5　アプリのトレーニング環境の構築

• 5.5.1　プレイグラウンドの導入
• 5.5.2　プレイグラウンドから本番環境へ

5.6　暗黙知の減らし方

5.7　ポストモーテムの実施

• 5.7.1　タイムラインの整理
• 5.7.2　振り返りの意義
• 5.7.3　振り返りのポイント

5.8　開発部の風通しをよくするには

第5章　IaCコードの良い育て方・悪い育て方

6.1　インフラをコードとして管理するメリット

• 6.1.1　インフラの効率化を推進するために必要なこと

6.2　本末転倒のIaC導入による問題発生

• 6.2.1　エラー発生の原因調査と設計の見直し

6.3　AWS設定値が原因で変更がロック

• 6.3.1　スタック内での参照
• 6.3.2　クロススタック参照

6.4　CloudFormationのサービスの仕様

• 6.4.1　スタックのデプロイ

6.5　CDK/CloudFormationのアンチパターン

• 6.5.1　①過度なスタック分割
• 6.5.2　②IaCと手動作業の混在による構成ドリフト
• 6.5.3　③相互参照の多用

6.6　CDKのコードの書き方

• 6.6.1　縦方向の依存方向を一方向にする
• 6.6.2　環境変数による疎結合な設計

6.7　IaCで管理した方がいいものとしなくてもよいもの

• 6.7.1　インフラの上で動作するアプリケーション
• 6.7.2　IAMリソースやVPCリソース、WAF等のセキュリティ統制にかかわるリソース
• 6.7.3　SES、Route53、Certificate Managerなど、DNSレコードの登録を伴うサービス
• 6.7.4　機密情報の管理に関わるリソース
• 6.7.5　システム運用に応じて頻繁に変更が入る可能性があるリソース

第7章　ISO/IEC：27017規格への対応

7.1　ISO/IEC 27017とIaC

7.2　ISO/IEC：27017規格とは何か？

• 7.2.1　ISO認証とは？
• 7.2.2　ISO27001(ISMS)とISO27017

7.3　規格をとるか、それとも運用をとるか？

• 7.3.1　内部監査で発覚したIaCの問題点
• 7.3.2　IaC運用の中止の危機

7.4　業務システム成長のトレードオフ

7.5　中期的な将来を見据えた運用設計

7.6　IaCの利便性とセキュリティのトレードオフ

• 7.6.1　IaC運用におけるアクセス統制
• 7.6.2　AWS Configによる変更検知

7.7　懸念される事柄

• 7.7.1　IaCコード品質の維持
• 7.7.2　教育

7.8　全社的なナレッジにする方法