計画停止除外の99.95%と決済API未監視
小売業D社は、自社ECサイトをオンプレミスからクラウドへ移行した。サービスレベル目標は月間稼働率99.9%、計画停止は除外、測定は外形監視（5分間隔、3回連続失敗で障害判定）である。移行後3か月の実績は99.95%だが、月平均4時間の計画停止があり、停止中もトップページは表示されるが決済APIが失敗する。監視はトップページのHTTP 200のみを見ており、決済APIの異常を検知できない。DBのCPU使用率は平日12時と20時に最大92%に達し、オートスケールは最大4台で上限に張り付く。ピーク時レスポンスは3.8秒、カート離脱率は18%に上昇した。月間セッションは120万、給与日とセール日に集中する。RTOは2時間、RPOは15分と定義されているが、リストア訓練は年1回の書面確認のみである。可用性の測定対象はサイト全体か決済機能かが契約で曖昧で、障害判定の3回連続失敗は最大15分の検知遅れを意味する。経営層は「99.95%なのでSLAは達成」と説明しているが、利用部門からは「決済できない時間が長すぎる」と苦情が来ている。
1. D社の「月間稼働率99.95%なのでSLA達成」という説明は妥当か。測定と解釈の問題点を指摘し、改善策を述べよ。
Read the worked answer
妥当とは言えない。第一に、計画停止をすべて除外すると、決済不能の4時間が稼働率から消える。利用者から見れば決済できない時間は停止であり、除外の妥当性を契約で明確にすべきである。第二に、トップページのHTTP 200だけでは、画面が表示されても決済APIが失敗する状態を検知できない。第三に、5分間隔で3回連続失敗という判定は最大15分の検知遅れを生む。改善は、検索・カート・決済のユーザージャーニー単位で合成監視し、決済成功率とp95レスポンスをSLOに加えること、計画停止は事前通知・時間上限・代替手段を条件に限定すること、可用性と機能可用性を分けて報告することである。99.95%という数字だけで経営層に達成と説明するのは不適切である。
2. 容量・性能改善の優先順位をどのように決めるか。指標と打ち手を述べよ。
Read the worked answer
優先順位は平均値ではなく、売上と顧客行動に直結する決済経路から決める。指標はピーク同時接続数、決済件数/分、p95・p99レスポンス、DB CPU、コネクション数、エラー率、カート離脱率である。最大4台のオートスケール上限は容量の天井であり、給与日・セール前の事前増強と上限引き上げを検討する。DBの92%はボトルネックの可能性が高く、読み取りレプリカ、キャッシュ、非同期処理、インデックス、接続プールを見直す。負荷試験でピークを再現し、改善効果を決済成功率とレスポンスで測る。コスト増は許容範囲を経営と合意する。
3. 監視と復旧訓練の設計をどのように改善するか。
Read the worked answer
監視は階層化する。インフラ監視に加え、決済APIの合成トランザクション、アプリケーション性能監視、決済成功率などのビジネスKPIを組み合わせ、エラーバジェットを消費した時点で警告する。アラートはオンコールの手順書と切り戻し条件に結びつける。復旧訓練は書面確認ではなく、隔離環境への実リストア、DNS切替、データ整合性確認、利用部門への連絡までを四半期に1回実施し、RTOとRPOの実測値を記録する。バックアップの復元可能性、手順書の版管理、連絡先の最新性も確認する。訓練後は是正項目に担当と期限を付け、次回で効果を確認する。