インシデント対応

SRE Lounge Hiroshima #1 〜インシデント対応を語ろう〜
にて飛び入り発表したスライドです。

Transcript

1. インシデント対応 SRE Lounge Hiroshima #1 〜インシデント対応を語ろう〜 Akira345
2. インシデント対応の原則 • 事実の記録と共有 • 時刻・状況・操作ログを必ず残す • 「推測」より「事実」を優先 • 精緻な調査より 初動のスピード • お客様との信頼関係 • 黙っていて悪化するより勘違いでしたの方がまだ マシ •障害は必ず起きる！！！
3. 全体フロー（概要） • 準備（連絡経路・保守範囲の確認） • 検知・分析（事実収集・影響推定） • 一次報告（事実ベースで迅速に） • 対応・復旧（優先度判断・調査・対処） • 事後対応（原因分析・再発防止）
4. 検知・分析（初動） • 障害発生の把握と記録 • 影響範囲の推定 • 本番／ステージング／開発 • この段階では具体的なサブシステムまで調べない • 影響対象の推定 • 社内／顧客企業／顧客の顧客(エンドユーザ) • 影響時間の推定 • すでに影響中か • これから影響が出るか（遅延・波及）
5. 一次報告（最速で） • 目的：関係者の認識を揃える • わかっている「事実」 • わかっていない点 • 影響の可能性 • 次の報告予定時刻 ※ 調査に時間をかけすぎない
6. 対応・復旧 • 関係者を集め、優先度を決定 • 復旧優先か、証拠保全優先か • ロールバック／再起動などの緊急手段の可否 • 顧客調整・リスケ判断 • 後日対応に回すタスクの切り分け • 意思決定者、対応者、顧客調整する人を分ける
7. 事後対応 • 原因分析（技術・運用・コミュニケーション） • 再発防止策の策定 • コード修正 • データ整合性の回復 • 手順書・運用改善 • イレギュラーな手段で対応した場合、忘れず開発・ス テージングへの反映
8. ケース別の判断ポイント • 本番障害 • 原則：復旧優先 • ただし攻撃が疑われる時は証拠保全とのバランス • 再起動するとログが消えるとか • インフラ障害 • 再起動・フェイルオーバーなど復旧優先 • 外部からの攻撃 • ログ保全・スナップショット取得 • アクセス遮断の判断 • 正常なアクセスも遮断する可能性→外部連携停止など • 影響度判定 • 影響ユーザ数・売上影響・法的リスク（個人情報など）
9. ケース別の判断ポイント • ステージング／検証環境: • 原則: サービス影響は限定的なので、原因究明・再現性確保を優先 • ただし本番リリース直前なら、本番への影響（リリース可否）を最 優先で評価 • 開発環境: • 原則: インシデントとしての対応なし • ただし「本番データをコピーしているか」「個人情報が含まれていないか」は確 認（ごく稀に開発環境に本番データを入れて漏洩インシデントがある） • ポイント: • ログや証跡を残す習慣をここで作っておくと、本番障害時の対応訓練 になる
10. 影響範囲の判定 • 社内のみ影響: • 例: 社内管理画面の障害、社内バッチの遅延 • 判断: 顧客影響はないが、他タスクへの波及（作業遅延、締切）を評価し、上長・関 係部署への共有を早めに実施 • 顧客企業に影響: • 例: 顧客担当者が使う業務システムの障害 • 判断: • 顧客側の業務停止度合い（代替手段の有無） • 顧客側の「対外説明」が必要になりそうか（顧客の顧客がいるか） • 顧客の顧客（エンドユーザ）に影響: • 例: ECサイト、会員サイト、一般ユーザ向けアプリの障害 • 判断: • 障害の公表・お知らせが必要か • 法令・ガイドライン（個人情報、決済など）に抵触しないか
11. 影響範囲の判定 • すでに影響が出ているケース: • 例: 「今まさにサービスが落ちている」「処理が止まっている」 • 行動: • 影響範囲のラフな推定 → 緊急度判定 → 一次報告を最速で出す • 「何がわかっていて、何がまだ不明か」を明示する • これから影響が出そうなケース（遅延・リスケ系）: • 例: バッチ遅延で翌朝の帳票が間に合わない可能性 • 行動: • 影響発生までの残り時間と、対処に必要な時間を見積もる • 代替案（手作業、部分的な出力、優先度付け）をセットで提案
12. 復旧手段の選定 • アプリケーション障害（バグ・設定ミスなど） • ロールバック、設定戻し、一時的な機能停止などでの復旧が現実的 • 一時対応でコードやデータをいじった場合は、必ず開発・ステージングに反映し、 差分をドキュメント化 • インフラ障害（サーバ、ネットワーク、ストレージなど） • 再起動・フェイルオーバー・スケールアウトなど、復旧優先の判断が多い • 復旧後に、監視・キャパシティ・構成管理の見直しを再発防止として整理 • 外部からの攻撃・不正アクセスの疑い • 証拠保全の重要度が高いケース • ログ保全、スナップショット取得、アクセス遮断などを「復旧」とどう両立させる かを事前に方針化しておくとよいが現実は・・・ • 運用ミス・手順逸脱 • 手順書・チェックリスト・権限設計の見直し • 「個人のミス」ではなく「仕組みとして防げるか」を考える！
13. 連絡不能時の対応 • 上司・顧客担当と連絡がつかない場合 • 自身の権限でできる範囲を明確化しておく • ロールバックまではOK。先方未承認で本番DB直更新は NGなど • 次のエスカレーション先へ連絡 • 緊急時は復旧可能性の高い手段を実施 • IP遮断、ロールバック、サーバ再起動など • 実施することで想定されるリスクを天秤にかける • 実施した操作および結果は「必ず記録」と「事後報告」
14. まとめ • 事実と記録: • 障害検知時刻、誰が何を見て何をしたか、時系列で記録 • ログ・画面・証跡の保全（後から「言った/言わない」を避ける） • 影響評価（範囲・対象・時間）: • どの環境か: 本番／ステージング／開発 • 誰に影響か: 自社／顧客企業／顧客の顧客（エンドユーザ） • いつ影響するか: すでに影響中か／これから影響しそうか／作業遅延・他タスクへの 波及 • コミュニケーションとエスカレーション: • 事実ベースで「暫定報告」を早く出す（精緻さよりスピード） • 連絡経路が詰まったら、自身の権限内で「上位・別経路」にエスカレーション • 復旧 vs 証拠保全・原因究明の優先度判断: • サービス継続が最優先か、攻撃・不正アクセスなどで証拠保全を優先すべきか • 復旧のための一時対応（ロールバック、再起動、データ変更など）を後で必ず開 発・ステージングに反映 • 障害のないシステムは存在しない