障害対応の心構え
このドキュメントはインシデント発生前に予防として読んでおくことを想定しています。 緊急時は 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) に主要な人に到達できる電話番号が書かれています。
ここでは主に Kubernetes に deploy されているコンポーネントにおける障害の緊急対応方法を記述します。 これに該当しない Mobile アプリなどは修正にかかるリードタイムが長くなるため分単位のタイムロスを考慮する必要がないためです。
Incident には様々な原因がありえますが、最も多いものの一つに deploy があります。 つまり本番環境に入ったコードの変更に起因するものです。 このような場合は「とにかく早く想定通りに動いていた version に戻す」というアクションが有効です。
kube prod history
この操作でいつどの commit が deploy されたのかを把握することができます。 この中で一つ前のものを deploy してみましょう。 重要なこととしてここの表示され 一つ前とはる必ずしも git における一つ前の commit ではないということです。 複数の Pull Request の merge がまとめて deploy された場合にどれが原因かわからないということもありえるので、 「一つ前の commit」ではなく「一つ前の deployment 状態」に戻す操作が有効なケースが多いでしょう。
一つ前の deployment にしても問題が継続する場合にはもっと古い version を deploy することを検討しましょう。 コードベースを修正するのにはどうしても数分~数十分の時間が必要です。 push された任意の commit に対応する docker image が container registry に push されているので基本的には任意のタイミングの commit の状態に 1 分程度で戻すことができます。 コードの修正を行う前にこれが実現可能かを確認しましょう。
# <commit hash> の状態を deploy する
kube prod deploy <commit hash>
これを行う際は「戻しすぎると他の場所が壊れることがある」という点に注意しましょう。 典型例としては「DB migration が入っているため戻すと DB との整合性が取れないので戻せない」「リリース済みで動作するべき他の機能が未リリースに戻ってしまう」などがあります。
また自動 deploy によりバグがもう一度 deploy されてしまう可能性があるので自動 deploy を止める
lock を行いましょう。# production への deploy を 1h 禁止する
kube prod lock 1h
バグ修正を試みると想定以上の時間がかかったり新たな問題を生んでしまったりすることもあります。 原因の PR が特定 できる場合はその PR の revert ができないかを考えましょう。
基本的には revert の PR の作成は早ければは良いほうが良いです。 古い commit を deploy するという対応が取れない場合、 最速の復旧方法は「Revert の PR を
master に merge せずに deploy する」というアクションになります。 この deploy が可能になるタイミングは Revert を作成してからその PR に対する docker build の作成が完了する時間に依存します。 Revert を過剰に作りすぎることのコストは無視できるので、怪しい PR があったら何よりも早く Revert PR を用意しましょう。障害対応経験が浅いタイミングで実際の障害対応に入ると、 「自分が思っていることはみんなわかっているだろう」と思ってあまり発言をしないこともあるでしょう。 しかし障害対応中は少なからず焦っているので当たり前のことに気づいていないこともあります。思ったことは何でも発言していきましょう。
最終更新 6mo ago