Q1 — 単一選択あるサービスでは必要なメトリクスとログがすでに収集されており、ダッシュボードを確認すれば重大な異常を即座に判断できる。しかし担当者がダッシュボードを開くまで異常に気付けず、夜間の対応開始が遅れている。将来的には復旧処理の自動化も検討している。最初に不足している運用能力として最も適切なものはどれか。
A. 本番環境へ小さな変更を段階的に投入する能力
B. 異常を適切な担当者や対応フローへ通知する能力
C. 実行中サーバーの望ましい構成を維持する能力
D. 地域障害を想定して復旧手順を演習する能力
答えと解説
答え:B
観測情報と異常判定は成立しています。自動化より前に、異常を行動につなげるアラートが不足しています。
Q2 — 単一選択複数のサーバーで手作業による設定変更が繰り返され、その構成差が原因で毎月障害が発生している。障害発生後は正確に通知され、担当者が検証済みの同じ修復操作を実施している。運用チームは修復操作の完全自動化を提案している。最初に優先すべき改善はどれか。
A. 障害通知後の修復操作をすべて自動実行する
B. 復旧担当者への通知経路を追加する
C. 望ましい構成を管理し、構成差の発生自体を抑える
D. 地域障害を想定した復旧演習を実施する
答えと解説
答え:C
手作業の復旧は結果側です。障害を繰り返し発生させている構成差という原因側を先に改善します。
Q3 — 単一選択あるシステムでは、大規模な本番リリースが失敗すると担当者が各サーバーへ緊急の手作業変更を行って復旧している。その変更が後から構成差として残り、次の障害原因にもなっている。運用チームは構成差の自動修正だけを導入する案を出している。再発を減らすための改善順序として最も適切なものはどれか。
A. 変更投入と切り戻しを安全にした上で、稼働中の構成状態も管理する
B. 構成差だけを自動修正し、現在のリリース方式はそのまま維持する
C. 障害通知を増やした後、リリース失敗時の手作業変更を継続する
D. 障害演習を先に増やし、構成差と変更投入の問題は後から対応する
答えと解説
答え:A
構成差は問題ですが、その上流にはリリース失敗と緊急の手作業変更があります。原因側のデプロイ改善と、その後の構成状態維持を組み合わせます。
Q4 — 単一選択障害発生時の復旧操作を自動化する計画がある。しかし現在は、通常の負荷上昇と障害状態を安定して区別できず、自動復旧後に正常状態へ戻ったことを確認する指標も存在しない。最初に行うべき改善はどれか。
A. 自動復旧を先に導入し、誤動作した場合だけ人が停止する
B. 復旧演習を増やし、自動復旧の代わりに人の判断へ統一する
C. デプロイ方式を変更し、障害判定とは独立してリリースを改善する
D. 障害判定と復旧結果を確認できる観測情報を整備する
答えと解説
答え:D
自動化が依存する判定能力が成立していません。まず正しい入力と結果確認を可能にします。
Q5 — 単一選択企業には地域障害向けの復旧設計、復旧手順、自動フェイルオーバー機能がある。通常の障害では監視と通知も正常に動作している。しかし、地域全体を失った状況を実際に想定したことがなく、復旧開始の判断、関係部署への連絡、業務再開の判断は実運用で確認されていない。次に必要な改善として最も適切なものはどれか。
A. 監視データを長期保存し、障害後の調査能力を高める
B. 障害演習を実施し、判断・連絡・復旧手順を検証する
C. 定型的な日常運用を自動化し、人的作業を削減する
D. 構成状態を定期確認し、サーバー間の設定差を修正する
答えと解説
答え:B
復旧方式は存在していますが、人・プロセス・技術を含む復旧能力が実際に成立するか未確認です。
Q6 — 単一選択あるシステムでは、障害を検出するための情報が不足しており、担当者への通知もなく、障害が判明した後は検証済みの同じ復旧作業を人が実施している。将来的に定型障害を自動復旧したい。改善の進め方として最も適切なものはどれか。
A. 自動化 → 構成管理 → モニタリング / ログ記録
B. アラート → 自動化 → モニタリング / ログ記録
C. モニタリング / ログ記録 → アラート → 自動化
D. 障害演習 → デプロイ改善 → 自動化
答えと解説
答え:C
自動化が依存する情報と通知経路を先に成立させます。