SAP-C02-103 · セクション 12 / タスク 3.1

既存環境のOperational Excellenceを評価する

現在状態 / 運用プロセス / 手作業 / 障害履歴 / 運用リスク / 改善優先度

既存環境を改善するとき、最初から新しい監視、デプロイ方式、自動化サービスを選ぶのではありません。

まず、現在どのように運用され、どこに手作業・属人化・障害の再発・業務影響があるのかを把握します。

現在状態を把握
↓
運用プロセスを可視化
↓
手作業 / 属人化 / 障害履歴を確認
↓
運用リスクと業務影響を評価
↓
改善優先度を決定
↓
具体的な改善策を後続の設計判断へ渡す

ゴール

このページでは、既存環境のOperational Excellenceを、単なる「運用が大変そう」という感覚ではなく、現在状態と証拠から評価します。

最終的に、

どの運用プロセスに問題があるか
どの手作業がリスクを生んでいるか
どの障害が繰り返されているか
業務へどの程度影響するか
どの改善から着手すべきか

を説明できることがゴールです。

1. 改善策を選ぶ前に現在状態を評価する

既存環境では、すでに運用手順、担当者、監視、変更作業、障害対応などが存在します。

そのため、最初の問いは、

何を導入するか？

ではなく、

現在どのように運用されているか？
どこで期待した成果を満たせていないか？

です。

改善は、現状と目標の差分を明らかにしてから設計します。

2. 現在状態は「構成」だけでなく「運用活動」も含める

Operational Excellenceの評価では、ワークロードの構成だけを見ても不十分です。

評価対象	確認すること
ワークロードの正常性	利用者へ期待した成果を継続して提供できているか
運用活動の正常性	デプロイ、変更、障害対応、定常運用が期待どおりに機能しているか

システムが稼働していても、変更のたびに手作業ミスが起きるなら、運用上の改善対象が存在します。

3. 運用プロセスを開始から完了まで可視化する

運用プロセスは、担当者名だけではなく、入力・判断・作業・確認・完了条件まで一続きで確認します。

要求 / イベント
↓
受付
↓
判断
↓
実作業
↓
確認
↓
完了 / エスカレーション

途中に、担当者しか知らない判断や口頭確認があれば、再現性や引き継ぎに影響します。

4. 手作業は「存在すること」ではなく性質を評価する

手作業があるだけで、直ちに問題とは限りません。

評価するときは、

頻度
作業時間
判断の複雑さ
誤操作の可能性
失敗時の影響
再実行のしやすさ

を確認します。

頻度が低く影響も小さい手作業と、毎日実行され失敗時に本番停止へつながる手作業は、同じ優先度ではありません。

5. 属人化は運用継続性のリスクとして扱う

「詳しい担当者がいる」こと自体は問題ではありません。

問題になるのは、

特定担当者だけが判断できる
特定担当者だけが実行できる
判断根拠が記録されていない
代替担当者が同じ結果を再現できない

状態です。

属人化は、休暇・退職・緊急対応時に運用継続性を下げ、判断のばらつきも生みます。

6. 手順の有無より再現性を確認する

手順書が存在していても、現在の環境と一致していなければ十分ではありません。

評価では、

最新状態か
必要な入力が明確か
判断条件が明確か
完了条件が明確か
別の担当者でも同じ結果になるか

を確認します。

目的は文書の量を増やすことではなく、運用を再現可能にすることです。

7. 障害履歴は「件数」だけでなく繰り返しを確認する

障害履歴からは、単純な発生件数だけではなく、繰り返し現れるパターンを探します。

確認軸	例
発生頻度	同種障害がどの程度繰り返されているか
影響範囲	利用者、業務、データ、運用担当へどこまで影響したか
復旧時間	検知から正常化までどの程度かかったか
再発	以前の対応後も同じ要因が残っていないか
検知方法	利用者申告で初めて判明していないか

繰り返し発生する障害は、個別対応ではなく運用プロセス自体の改善候補として扱います。

8. インシデント後分析から寄与要因を残す

障害対応が終わったら、復旧できたことだけで完了にしません。

インシデント後分析では、

何が起きたか
どの要因が影響したか
なぜ検知 / 対応が遅れたか
何が再発を防げるか
次回の対応をどう改善できるか

を記録します。

個人を責めるのではなく、再現可能な学習材料として運用改善へ戻します。

9. 現在状態には成功している運用も残す

評価は問題探しだけではありません。

現在うまく機能している運用も記録します。

安定している手順
有効なレビュー
短時間で復旧できた判断
事故を防げた確認工程

を残すことで、改善時に有効な仕組みまで壊すことを防げます。

10. 運用リスクは発生可能性と影響を組み合わせて見る

改善候補の優先度を決めるため、運用上の弱点をリスクとして整理します。

発生しやすさ
+
失敗した場合の影響
+
現在の検知 / 復旧能力

を組み合わせて評価します。

数式へ固定するのではなく、組織内で比較可能な基準へそろえることが重要です。

11. 業務影響を技術障害から分離して確認する

同じ技術障害でも、業務上の重要度によって改善優先度は変わります。

技術上の事象	確認する業務影響
定期バッチ失敗	締め処理、請求、配送などの業務期限へ影響するか
管理画面の一時停止	顧客影響か、社内担当者だけの影響か
手動復旧が必要	夜間呼び出し、対応人数、復旧遅延へつながるか

技術的な重大度だけでなく、事業成果への影響を評価します。

12. 改善優先度は「痛みが大きい順」だけで決めない

改善候補は、業務影響だけでなく、リスク低減効果と実行可能性も含めて比較します。

業務影響
+
運用リスク
+
期待できるリスク低減
+
実施コスト / 難易度
+
依存関係

これにより、効果が大きく実行可能な改善を先に着手できます。

13. 高頻度・高影響・繰り返しを優先候補として見る

例えば、次の2つの候補があるとします。

候補	頻度	業務影響	特徴
A	年1回	小	復旧手順が明確
B	毎週	大	特定担当者の手作業で復旧

他の条件が同等なら、Bはより高い運用リスクを持つため優先候補になります。

14. 改善候補には担当者と期待する成果を持たせる

「改善する」だけでは追跡できません。

候補ごとに、

対象
担当者
現在状態
期待する成果
優先度
確認時期

を明確にします。

ここで決めるのは改善対象と優先度であり、具体的なAWSサービスや実装方式は後続の設計判断で選びます。

15. AWS Well-Architected Toolで現在状態をレビューする

AWS Well-Architected Toolを使うと、Well-Architected Frameworkの質問に沿ってワークロードをレビューし、現在の設計・運用上の懸念を整理できます。

重要なのは、ツールを開くだけではなく、

現在の実態
+
レビュー回答
+
補足情報
+
改善対象

を対応付けることです。

16. マイルストーンで現在状態の変化を追跡する

AWS Well-Architected Toolでは、レビューのマイルストーンを保存して、ある時点の状態を記録できます。

初回レビュー
↓
現在状態を記録
↓
改善を実施
↓
次回レビュー
↓
状態変化を比較

これにより、「改善したつもり」ではなく、レビュー時点の変化を追跡できます。

17. 改善計画とリスク項目を優先度へつなげる

AWS Well-Architected Toolのレビューでは、改善計画や高リスク / 中リスクの項目を、現在状態を整理する材料として利用できます。

ただし、ツール上の表示だけで最終優先度を自動決定するのではなく、

レビュー結果
+
障害履歴
+
手作業 / 属人化
+
業務影響
+
組織の制約

を組み合わせて判断します。

18. 代表的なアンチパターン

アンチパターン	なぜ問題か
現在状態を確認せず、最初から改善サービスを選ぶ	原因と改善策が対応せず、優先度も説明できない
障害件数だけで優先順位を決める	業務影響、再発性、復旧負荷を見落とす
手順書があるため属人化はないと判断する	判断条件や再現性が欠けている可能性がある
`AWS Well-Architected Toolが自動ですべての運用問題を発見する`	レビュー回答には実態把握が必要であり、障害履歴や運用現場の証拠と組み合わせて評価する必要がある
高リスク項目の件数だけで改善順序を決める	業務影響や依存関係を含む組織側の優先度が反映されない

19. SAP-C02での判断フロー

既存環境を改善したい
        ↓

現在状態を把握できている？
        ↓
構成だけでなく
運用活動も確認
        ↓

運用プロセスを可視化
        ↓
入力 / 判断 / 作業 / 確認 / 完了
        ↓

手作業 / 属人化はある？
        ↓
頻度 / 複雑さ / 誤操作 / 影響を確認
        ↓

障害履歴を確認
        ↓
頻度 / 影響 / 復旧時間 / 再発 / 検知
        ↓

運用リスクを整理
        ↓

業務影響を確認
        ↓

改善候補を比較
        ↓
業務影響
運用リスク
リスク低減
実施コスト
依存関係
        ↓

改善優先度を決定
        ↓

必要に応じて
AWS Well-Architected Toolで
レビュー / マイルストーン / 改善計画を記録
        ↓

具体的な改善策の設計へ進む

まとめ

既存環境のOperational Excellenceを改善するときは、具体策を先に選びません。

まず、

現在状態
運用プロセス
手作業
属人化
障害履歴

から、運用上の弱点を事実として把握します。

次に、

運用リスク
+
業務影響
+
期待できるリスク低減
+
実行可能性

を比較して改善優先度を決定します。

AWS Well-Architected Toolは、レビュー、マイルストーン、改善計画などを通じて現在状態と変化を追跡するために利用できます。

最終的には、

何が問題か
↓
なぜ優先するか
↓
何を改善対象とするか

を説明できる状態にし、具体的な改善設計へ進みます。

主要AWS公式資料

AWS Certified Solutions Architect - Professional SAP-C02 Exam Guide — Task 3.1
AWS Well-Architected Framework — Operational Excellence Pillar
OPS08 — Utilize workload observability
OPS09 — Understand operations health
OPS11 — Evolve operations
AWS Well-Architected Tool — Reviewing a workload
AWS Well-Architected Tool — Milestones
AWS Well-Architected Tool — Improvement plan