SAP-C02-110 · セクション 12 / タスク 3.1
Operational Issueから改善戦略を選択する
モニタリング / アラート / 自動化 / デプロイ / 構成管理 / 障害演習 / 改善戦略の選択
既存環境を改善するとき、最初に考えるべきことは「どのAWSサービスを追加するか」ではありません。
同じ「障害対応が遅い」という現象でも、
- 異常を判断する情報が足りない
- 異常は分かるが担当者へ届かない
- 通知後の定型作業を人が繰り返している
- 構成差そのものが障害を生み続けている
では、選択すべき改善戦略が異なります。
重要なのは、
運用上の問題
↓
どこで期待する運用が止まっているか
↓
改善方針を分ける決定打
↓
改善戦略の順で考えることです。
ゴール
運用上の問題を読み取り、
- 問題が発生している運用段階を特定する
- 表面的な症状ではなく決定打を見つける
- 適切な改善戦略を選択する
- 複数の改善が必要な場合に前提関係を判断する
- 原因側と結果側を区別して改善順序を決める
ことを目指します。
1. 改善戦略を分ける6つの決定打
個々の仕組みではなく、まず問題の位置を確認します。
| 運用上の問題 | 決定打 | 主な改善戦略 |
|---|---|---|
| 状態や原因を判断できない | 必要な情報がない、関連付けられない | モニタリング / ログ記録 |
| 状態は判断できるが必要な人へ届かない | 異常を認識しても行動につながらない | アラート |
| アラート後に同じ対応を繰り返す | 既知で反復可能な対応を人が実施 | 自動化 |
| 変更投入時に障害や大きな影響が発生する | 問題がリリースと強く関連する | デプロイ改善 |
| 稼働後に期待する設定からずれる | 構成状態を維持できない | 構成管理 |
| 復旧計画が実際に機能するか分からない | 復旧能力が未検証 | 障害演習 |
この表を暗記するのではなく、シナリオの中からどの行に該当する事実があるかを探します。
2. モニタリング・アラート・自動化を一括りにしない
障害対応の流れは、大きく次のように分けられます。
状態を観測
↓
異常を判定
↓
必要な人や仕組みへ知らせる
↓
対応を実行
↓
結果を確認問題がどこにあるかで改善策が変わります。
情報自体が不足
何が起きているか判断できないなら、モニタリングやログ記録が不足しています。
情報はあるが行動につながらない
ダッシュボードを見れば異常は分かる
しかし
担当者が確認するまで気付かないなら、主な不足はアラートです。
アラートは成立している
異常を正しく通知
↓
担当者が毎回同じ復旧操作なら、次に検討するのは自動化です。
したがって、
判断できない
→ モニタリング / ログ記録
判断できるが届けられない
→ アラート
通知後の既知対応を人が繰り返す
→ 自動化と分離します。
3. 症状ではなく「止まっている場所」を見る
例えば、
復旧が遅いという情報だけでは改善戦略を決められません。
ケースA
障害発生
↓
原因を判断できない
↓
調査に時間問題は観測側です。
ケースB
障害発生
↓
ダッシュボードには即座に反映
↓
誰も確認していない問題は通知側です。
ケースC
障害発生
↓
即座に通知
↓
担当者が毎回同じ復旧手順を実施問題は対応側です。
結果がすべて「復旧が遅い」でも、改善する場所は異なります。
4. 最終的に実現したい状態より前提を先に見る
ある企業が、
障害を完全自動修復したいと考えているとします。
しかし現在、
正常状態と異常状態を安定して区別できないのであれば、自動修復を先に導入するのは適切ではありません。
必要なのは、
観測可能にする
↓
異常判定を成立させる
↓
必要な通知を成立させる
↓
対応を自動化するという流れです。
試験では、最終目標ではなく、その改善を安全に成立させる前提が整っているかを確認します。
5. 原因側と結果側を区別する
複数の運用上の問題は、独立しているとは限りません。
例えば、
手作業で設定変更
↓
サーバー間で構成差
↓
障害
↓
担当者が手作業で復旧という環境があります。
ここで復旧作業だけを自動化しても、
構成差
↓
障害という原因は残ります。
この場合は、
原因
構成状態を維持できない
結果
障害が発生し復旧作業が必要と分けます。
上流の構成管理を改善すれば、下流の復旧作業そのものを減らせる可能性があります。
改善候補が複数あるときは、どの問題が他の問題を発生させているかを確認します。
6. デプロイと構成管理は「いつ差が生まれるか」で分ける
設定やアプリケーションの不整合があっても、改善対象は同じとは限りません。
リリース直後から問題
→ デプロイ過程を確認
正常にリリース
↓
運用中の個別変更で徐々に差
→ 構成管理を確認決定打は、問題が変更投入時に生まれたのか、稼働中に生まれたのかです。
単に「設定が違う」「障害が起きた」という言葉だけで判断しません。
7. 復旧手段の存在と復旧能力は別
次のような環境を考えます。
復旧計画
あり
復旧手順
あり
フェイルオーバー方式
ありこれだけでは、
実際に復旧開始を判断できるか
必要な人へ連絡できるか
担当者が正しく行動できるか
正常性を確認できるかは分かりません。
技術や手順が設計されていても、復旧能力そのものが未検証なら、障害演習が改善候補になります。
重要なのは、新しい復旧方式を学び直すことではありません。
設計済み
しかし
実際に成立するか未確認という決定打です。
8. 複数の改善戦略が必要な場合
実際の環境では、1つの改善だけで問題が解決しないことがあります。
例えば、
障害状態を判定できない
通知もない
復旧操作も手動なら、最終的には複数の改善が必要です。
しかし、
自動化
↓
アラート
↓
モニタリングとはしません。
自動化が依存する情報から先に整えます。
モニタリング / ログ記録
↓
アラート
↓
自動化というように、後段の仕組みが必要とする前提から改善するのが基本です。
9. 改善順序では前提関係も確認する
複数の改善候補がある場合、個々の改善効果だけで順序を決めるとは限りません。
例えば、自動修復による効果が大きくても、異常を正しく判定できなければ安全に実行できません。
効果の大きい改善
+
その改善に必要な前提
↓
着手順序を決定後段の仕組みが依存する能力が不足している場合は、前提となる改善を先に行います。
10. 改善後に確認すべきこと
改善策を導入しただけでは完了ではありません。
元の問題に対して、
何が改善したら成功なのかを確認します。
| 改善戦略 | 確認する結果の例 |
|---|---|
| モニタリング / ログ記録 | 状態や原因を判断できるようになったか |
| アラート | 必要な異常を適切な人や仕組みへ届けられるか |
| 自動化 | 人手による待ち時間や人的ミスが減ったか |
| デプロイ改善 | 変更失敗時の影響や復旧時間が減ったか |
| 構成管理 | 意図しない構成差の再発が減ったか |
| 障害演習 | 未確認だった判断・連絡・手順を検証できたか |
評価する対象は、導入したAWSサービスの数ではなく、元の運用上の問題が改善したかです。
11. 混同しやすい判断
| 状況 | すぐ選びたくなる改善 | 実際に確認すること |
|---|---|---|
| 復旧が遅い | 自動化 | どの段階で時間を失っているか |
| 障害に気付くのが遅い | モニタリング追加 | 情報不足か、通知不足か |
| 設定差がある | デプロイ改善 | 差がいつ発生しているか |
| 手作業が多い | すべて自動化 | 原因を生んでいる上流問題がないか |
| 復旧計画がある | 対応済みと判断 | 実際に検証済みか |
12. アンチパターン
サービス名から選ぶ
CloudWatchがあるからCloudWatch
Systems ManagerがあるからAutomationとは判断しません。
先に運用上の問題を特定します。
症状だけで選ぶ
障害が多い
復旧が遅い
手作業が多いだけでは不十分です。
問題が生まれている位置を確認します。
下流だけを自動化する
原因が残ったまま復旧処理だけ自動化すると、障害そのものは発生し続けます。
前提がない状態で自動化する
正しい判定条件がない処理を自動化すると、誤った対応まで自動化する可能性があります。
導入したことで完了とする
改善後は、元の問題が実際に減ったか確認します。
13. SAP-C02での判断手順
問題文では、次の順序で考えます。
1. 何が起きているか
↓
2. どの運用段階で問題が発生しているか
↓
3. 決定打を確認
情報がない
→ モニタリング / ログ記録
情報はあるが届かない
→ アラート
通知後の既知作業を繰り返す
→ 自動化
変更投入時に問題
→ デプロイ改善
稼働中に構成差
→ 構成管理
復旧能力が未検証
→ 障害演習
↓
4. 他の問題の原因になっていないか
↓
5. 前提となる改善が必要か
↓
6. 適切な改善戦略を選択選択肢に具体的なAWSサービスが書かれていても、不足している運用能力と一致しているかから判断します。
まとめ
運用上の問題を改善するときは、
問題
↓
決定打
↓
改善戦略の順で考えます。
特に、
判断できない
→ モニタリング / ログ記録
判断できるが届かない
→ アラート
通知後の既知対応を人が繰り返す
→ 自動化
変更投入時に問題
→ デプロイ改善
稼働中に構成差
→ 構成管理
復旧能力が未検証
→ 障害演習を区別します。
複数の問題がある場合は、
原因側
前提となる能力
下流への影響を確認し、適切な順序で改善します。