障害対応の心構え

このドキュメントを読む前に

このドキュメントはインシデント発生前に予防として読んでおくことを想定しています。 緊急時は Incident Response (internal) 及び #war_room (internal) を確認してください。
インシデント対応について Incident Response (internal) がより網羅的かつ真とするドキュメントです。 このドキュメントでは上記のドキュメントの内容を補足する内容として特に new joiner が認識しておくべき情報を抽出/加筆したものです。 もし上のドキュメントとこの章に食い違いが生じる場合は上のドキュメントを真としてこの章を編集してください。

このドキュメントの使い方

各チームで new joiner を受け入れるときにこのドキュメントを一律に共有することで共通認識を得ることを目的にします。 このため主に障害対応経験が少ない人に向けた最低限の心構えを共有するものであり障害対応に関する情報を網羅的にまとめたものでは有りません。
障害対応経験者は障害対応を誰かに任せる場合にはこのドキュメントの内容を把握しているかどうかを確認してください。

そもそもの開発において

本番環境にバグを入れる可能性をゼロにはできないということを受け入れましょう。 もちろん良い設計、テスト、レビューなどでその可能性を下げることが望ましいですが完全にゼロにすることは現実的に不可能です。
Wantedly は失敗を受け入れる文化なので、バグを出すことを恐れて開発スピードを遅くする必要はありません。 テストやレビューを頑張っても不安が消しきれない場合はバグが生じてもユーザー体験が落ちにくい工夫をすると良いでしょう。 例えば「特定の query param があるときだけ新実装が使われる」「まずは社員にだけリリースされるようにする」「何かあったら古い実装に fallback するようにしておく」などの手法があります。
一人で考えるとリスクをすべて自分で背負ってしまう気持ちになることあるので、そういう場合は周りの人を捕まえて一緒にどうするかを考えると建設的に進むことがあります。 失敗が起こることを受け入れ、チームで助け合いながら開発を進めていきましょう。

本番環境に問題が生じた時

まずは過剰反応である可能性を一切忘れて、どんな小さな問題だと思ったとしてもどんな時間であっても大声で人を集めましょう。 自分一人で判断しないことが大事です。 Wantedly のメンバーは必ず協力してくれます。 問題を過小評価しないことがいちばん大事なので、過大評価することを恐れる必要はありません。 具体例として「深夜にたまたま少し挙動がおかしい可能性に気づいた」というような場合にすでに就寝している自分のリーダーを起こす、というようなことがあっても構いません。 仮にそれが誤報であったとしても「勇気を持ってレポートしたこと」は称賛されるべきです。 繰り返しになりますが過剰反応になること一切恐れず、逆に一切過小反応にならないようにしましょう。
また、誰の Pull Request が原因であったとしても Wantedly は失敗を許す文化を持っているので隠す必要はありません。 個人の感性で問題ではないかと思ったらまずまわりに協力を求め、そこで判断の精度を上げつつ、必要ならもっとまわりを巻き込んでいきましょう。
基本的には #war_room (internal) でコメントすると人が集まります。 最終手段として 緊急時の連絡先 (internal) に主要な人に到達できる電話番号が書かれています。

対応で考えること

古い commit を deploy し直す

コードベースを修正するのにはどうしても数分~数十分の時間が必要です。 push された任意の commit に対応する docker image が container registry に push されているので基本的には任意のタイミングの commit の状態に 1 分程度で戻すことができます。 コードの修正を行う前にこれが実現可能かを確認しましょう。
1
# <commit hash> の状態を deploy する
2
kube prod deploy <commit hash>
Copied!
これを行う際は「戻しすぎると他の場所が壊れることがある」という点に注意しましょう。 典型例としては「DB migration が入っているため戻すと DB との整合性が取れないので戻せない」「リリース済みで動作するべき他の機能が未リリースに戻ってしまう」などがあります。
また自動 deploy によりバグがもう一度 deploy されてしまう可能性があるので自動 deploy を止める lock を行いましょう。
1
# production への deploy を 1h 禁止する
2
kube prod lock 1h
Copied!

Revert する

バグ修正を試みると想定以上の時間がかかったり新たな問題を生んでしまったりすることもあります。 原因の PR が特定できる場合はその PR の revert ができないかを考えましょう。

思ったことは何でも言う

障害対応経験が浅いタイミングで実際の障害対応に入ると、 「自分が思っていることはみんなわかっているだろう」と思ってあまり発言をしないこともあるでしょう。 しかし障害対応中は少なからず焦っているので当たり前のことに気づいていないこともあります。思ったことは何でも発言していきましょう。

対応後

Post Mortem

インシデント対応後は post-mortem のを書きます。 詳しくはポストモーテムの取り組みを確認してください。

話を聞きに行きたい

もっと知りたい

最終更新 9d ago