インシデント（障害対応）

📖 もうちょい詳しく

何が新しいの？

インシデントは、サービスにふだんと違う支障が出た「できごと」のことです。たとえばサイトが開かない、決済が通らない、表示がとても遅い、といった状態を指します。新しい技術というより、現場で長く使われてきた言葉です。

どうやって動いてるの？

多くの現場では、まず異常に気づくしくみ（監視）が知らせを出します。次に担当者が状況を確かめ、原因をしぼり込み、まず止血（応急の復旧）をして、あとから根っこの原因を直します。だれが何を、いつしたのかを記録に残しながら進めることが多いです。

何ができるの？

インシデントとして扱うことで、ばらばらの「困った」をきちんと共有し、対応の優先度を決められます。記録が残るので、同じことが起きたときに早く対処でき、再発を防ぐ手がかりにもなります。

🌱 身近なたとえ

お店の停電で例えると、まず「電気が消えた」という事象そのものがインシデントです。店員はあわてず非常灯をつけて営業を続けつつ（応急の復旧）、ブレーカーを確認して原因を直します。あとで「いつ・なぜ落ちたか」をメモに残し、次に備えるところまでが一連の対応です。

✅ まず覚えるポイント

• インシデントは「支障が出たできごと」そのものを指します。
• 対応のゴールは、まず素早く元に戻すこと（復旧）です。
• 原因の特定より、利用者への影響を止めるほうが先になることが多いです。
• だれが何をしたかの記録が、あとでとても役に立ちます。
• 落ち着いたあとに原因を直し、再発を防ぐところまで含みます。

🧭 よくある勘違い

インシデントとバグは同じもの？

近いですが、視点が違います。バグはプログラムの間違いという「原因」寄りの言葉で、インシデントは利用者に支障が出た「できごと」寄りの言葉です。設定ミスやアクセス集中など、バグ以外が引き金のインシデントもあります。

まず原因を完全に突き止めるべき？

そうとは限りません。原因をすべて理解する前に、まずサービスを使える状態へ戻すことを優先する場面が多いです。深い原因の調査は、影響が落ち着いてから落ち着いて進めるのが一般的です。

🧩 関連して覚えると楽な言葉

• SLA: サービスの品質をどこまで守るかを取り決めた約束のことです。
• 監視（モニタリング）: 異常を自動で見張って、早く気づくためのしくみです。
• ポストモーテム: 対応後にふり返り、再発を防ぐためにまとめる記録です。
• オンコール: 障害にすぐ対応できるよう、担当者が当番制で待機しておくしくみです。

🏁 ひとことでまとめ

ふだん通りに動かなくなった事象に気づき、素早く立て直し、記録して次に活かす一連の流れが「インシデント対応」です。