はじめに
こんにちは、サーバーサイドエンジニアの中川（@tkdev0728）です。
突然ですが皆さんは自分のコードでインシデントを起こしたことはありますでしょうか？
前提としてインシデントは誰も起こそうとしていないし、起こったものは仕方がないので全力で復旧するのみです。また、決められたレビューフローやリリースフローに従っていた場合、責任の所在は個人ではなく仕組みを作り運用しているチームだと思っています。
とは言ったものの、自分の書いたコードにバグがあった場合は気持ちの面で責任を感じたり焦る部分はあります。
本記事を書いているのが4月なのですが、ちょうど新卒として入社した方も多いと思うので新卒でこれからエンジニアとして活躍しようとしている方の参考になればいいなと思い、万が一インシデントが起きてしまった場合にどう行動すればいいのか自分なりに意識していることを書いてみます。
正解は1つではないと思うので、あくまで一例としてみていただければと思います。
今回話すこと
- マインド面
- インシデント対応時全般で心がけていること
今回話さないこと
- 具体的な技術面
- インシデントを検知するためのアラートなどの仕組み
インシデント対応時全般で心がけていること
とりあえず参加する。参加することに価値がある
大前提としてヤプリではクライアントの利益を最優先に考えて行動しています。そのためインシデントが起きてしまった場合でも機能開発を進めつつ速やかに復旧することが求められます。
機能開発とインシデント対応のバランスを考えて、インシデント参加メンバーは当事者+有識者+場合に応じて有志の必要十分のメンバーで行う体制をとっています。
そのため今の自分はどちらを進めることが求められているのか判断が求められる場合もあります。ヤプリではある程度の人数が集まった段階で各メンバの持ちタスクなどを順番に開示していき、クライアントへの影響や緊急度、スピード感などと照らし合わせて対応するメンバーをきめていきます。
そのため「現在の自分は機能開発を優先するべきだと考えている」ということを周りに伝える意味も兼ねて参加できる時は参加することを意識しています。
参加時に二の足を踏んでしまう理由の1つとして「自分が参加しても役に立つかわからない」というのがあると思います。
確かにドメイン知識が全くない部分に関するインシデントの場合自分にできることは少ないかもしれませんが、そういう場面ではドメイン知識獲得のチャンスだと思っています。詳しくは次の見出しで書きますが少なくともヤプリでは知らないことが理由で怒られることはないのでドメイン知識獲得のチャンスです。
知らないことが罪じゃなく、他の人のリソースをフルに使えるチャンスだから聞く
インシデント対応では何よりもスピードが求められます。そのため普段のチームやベテラン/若手関係なくわかる人、対応できる人がリードしながら対応を進めていきます。
先にも少し書きましたがヤプリでは対応メンバーを選定するにあたって、その機能や部分に詳しいメンバーと、場合に応じて有志の必要十分のメンバーを選定することが多いです。クライアントへの影響や緊急度を考えて人数が必要になった場合など、場合によっては若手メンバーなどドメイン知識がまだあまりないメンバーと一緒に対応することもあります。そのため自分が詳しい分野だった場合は自分主導で対応しますが、そうでない場合はベテランメンバーと一緒に対応することになります。
これが個人的にめちゃくちゃ貴重な機会だと思っていて、復旧後の振り返りの時間などに自分のドメイン知識が薄い部分についてベテランメンバーから直接教えてもらうことができるのでめちゃくちゃ知見が溜まります。普段だったら聞きづらい場面や分野についても次に同じ事象を引き起こさないために聞くという大義名分があるので臆することなく質問できます。
もちろん逆に自分が詳しい分野で若手メンバーと一緒に対応することになった場合、復旧後に他のメンバーの知見獲得のために知っていることや聞かれたことに関しては丁寧に説明することを心がけています。
思考を開示する、思っていることややることをとりあえず書く
スピードが求められる場面なので各々のメンバーが今必要なことを考えて対応を進めます。ただ、次に何をすればいいかわからない場面やこれやっていいのかと思う場面はあると思います。そういう場合に自分が心がけていることは自分の思考ややろうとしていることを書き出して周りに共有することです。
おそらく大抵のインシデント対応の場合情報が散らばらないようにある程度対応用のチャンネルなりスレッドなりを用意すると思います。
そのチャンネルやスレッドは対応者全員が見ているので何か間違っていることや他にやって欲しいことなどがあれば誰かが教えてくれるだろうと思い、判断に迷う場合はそこに自分の思考を書き出すようにしています。
これはアラートなどを最初に確認している時も心掛けていて、例えば他の人と同じ調査を行なっていたら時間の無駄ですし、有識者にとってはもっと違う部分を見て欲しいと思う場面もあるかもしれないので、「〇〇ってエラーだから××を見てみる」であったり、「△△らへんが怪しい気がする」など自分の思っていることを書き出すようにしています。
情報集約用の場に投稿することは場合によってはノイズになって必要な情報の邪魔になることもあるかもしれないので、この辺りはケースバイケースかなと思います。個人的には指摘されたらやめればいいと思います。
反省も後悔も後。まず復旧
自分がインシデントを起こしてしまった場合罪悪感に押しつぶされそうになると思います。
ですがいくら周りに謝り倒しても復旧はしません。インシデントを起こしてしまった以上何よりも復旧させることが最優先なので謝って後悔している暇があるならば手を動かしましょう。修正して再度リリースするのか、切り戻しを行うのかなど復旧手段は色々あると思いますが今回の事象や影響範囲や対応にかかる時間などを考えて何が最適解か考えて行動しましょう。自分が原因である以上自分が一番詳しいはずです。
振り返り（≠反省会）で学びを得る
ヤプリでは復旧後にポストモーテム（振り返り）を行います。ここでやることは振り返りであって反省会ではありません。
どうすればこのインシデントを防げたのか、同じインシデントを2度とおこなさないためにどうすればいいのかなどを振り返り、次に行うべき具体的なアクションを設定して次のタスクに活かしていきます。
反省会といえば後ろ向きでネガティブなイメージがありますが、ここで行うことは振り返りであり前向きな場なのでここで学びを得ることを意識しています。
コードを憎んで人を憎まず
色んな場面で出てくる言葉なので一度は聞いたことある方が多いのではないでしょうか？
有名な言葉だと思うので今更補足はしませんが、たとえコードに問題があったとしてもそれを書いた人に罪はないので間違っても個人を攻撃することはしないように心がけていますし、ヤプリのエンジニア組織としてもこれは特に大事にしているマインドの1つです。
個人ではなくチームの責任
上で書いたことと似ていますが、原因となったコードがコードレビューを通っていて本番に反映されている以上その責任は実装者1人ではなくチーム全体の責任だと思っています。だからこそ実装者1人を悪者にして吊し上げるのではなく、チームとしてなぜレビューで見逃してしまったのか、検証方法に問題はなかったのかなど個人の問題でなくチームの問題として改善策を出すことを意識していますし、振り返りの場でもチームとして仕組みなどで解決する方法を考えています。
実装者よりも冷静に
インシデント対応の原因となるコードを書いたメンバーがいた場合、おそらくそのメンバーは誰よりも慌てているはずです。
だからこそ間違っても個人攻撃したり突き放したりせず、そのメンバーが落ちついて復旧対応にあたれるように冷静になることを意識しています。
最後に
ここまで書きましたがインシデントなんて起きない方が幸せなので色んな意味でここに書いたことが活かされないことを祈っていますw
それでも起きてしまった場合はここに書いたことを思い出して落ちついて行動してください。
あとがき
ヤプリのインシデント対応フローについて詳しく知りたい方やヤプリに興味をもったという方はぜひカジュアル面談にお越しください。
