はじめに
こんにちは、サーバサイドエンジニアの中川です。
最近引っ越しをしまして重いものを運んだ関係で腕と肩がバキバキで辛いです。割とギリギリまでバタバタしていたので引っ越しの準備は計画的に行うことを強くお勧めします。
さて、今回はヤプリのインシデント対応の流れについて書いていこうと思います。
インシデントが起きない仕組みづくりは大事ですが、それと同じくらい起きてしまってから素早く復旧させることも大事だと考えています。
そのためにヤプリがやっている工夫や今後の課題などを書いてみるので、有事の際の参考になれば幸いです。
「自社ではこんな工夫をしている！」等あればコメントいただけると泣いて喜びます。
ヤプリのインシデント対応の流れ
ヤプリでのインシデント検知→復旧までの流れは大まかにいって下記です。
1. アラートや不具合報告で検知する。 2. 内容を確認し、インシデントのレベル判定を行い緊急度を判定する。 3. 緊急度に沿ってエンジニアチームへ連携し、緊急度が高い場合は即座に関連するエンジニアがアサインされる。 4. アサインされたエンジニアから事故隊長を決めて、事故隊長指示の元集まったメンバーで関連部署への周知連携や復旧の為の調査を行う。 5. 復旧後は根本原因や事象の詳細を周知共有するとともに、後日再発防止の根本解決の為のポストモーテムを行う。
メンバーはどうやって選定しているのか
2022/12現在、ヤプリには運用保守専任の部隊はおらず、全員がインシデント対応に取り組みます。インシデントの緊急度に応じてなるべく集まれる人全員に集まってもらい、調査コストに合わせて事故隊長がメンバーを選定します。緊急度にもよりますが、できる限り全員が対応できる状況にしておきたい関係で
関連部のドメイン知識を持っているエンジニア数人
+
経験値を得られるように最近入社したメンバーやドメイン知識を持っていないエンジニア数人
ような組み合わせでチームが組まれることが多いです。
事故隊長制度とは
ヤプリのインシデント対応では事故隊長と呼ばれる役割が存在します。 事故隊長の役割は主に下記です。
1. 事象の内部周知、共有を目的とした全体報告用のチャンネルでの報告 2. クライアントへの共有を円滑に進めることを目的としたビジネス職への事象共有 3. 事象の復旧を目的とした旗振り
事故隊長は正確な全体状況の把握、適切な周知や進行、関連部署とのコミュニケーションを主としており、調査や復旧は別に調査エンジニアを立て役割分担をしています。それによって迅速な解決や復旧、連携を実現しています。
ポストモーテムとは
インシデントの復旧後、必ずポストモーテムが開催されます。 ポストモーテムでは
1. インシデントの内容の共有 2. インシデント原因についての深掘り 3. 恒久対応について a. 同じようなことを発生させないための仕組みづくり 4. 今回のインシデントからの学び
などをインシデント対応メンバーについて話し合い、ドキュメントとしてまとめます。
今後の課題
上記の流れで行うインシデント対応ですが、課題もあります。
新しく入ったメンバーが参加しづらい
自分も記事執筆時は入社してまだ8ヶ月程度ですが、入社当時は「入社間もない自分が参加して貢献できるか」と不安でインシデント対応に対する心理的なハードルがありました。
もちろん入社歴に関係なく参加メンバーに対しては都度情報共有はされますし、必要に応じて補足等もしていただけるので参加してもやることがないなんてことはありません。
とはいえどうしても参加する側にはハードルが残っているので、メンバーの勇気に頼ってる点が現状の課題です。
これに対するアプローチとしてインシデント復旧後に有志メンバーでインシデントトレース会という名目で原因調査のやり方などを学ぶ会を行っていたりします。そちらについてもまた機会があれば記事を書こうと思います。
有識者頼りになっている部分がある
ヤプリのシステムは複雑です。それゆえに該当部のドメイン知識を保持している有識者が少ない場合があります。そうすると基本的にインシデント対応メンバーは有志で集まったメンバーですが、個別に招集して該当部について質問させていただく場合があったりします。これに対してもアプローチとして専用のチームを結成し、まずそのチーム内からドメイン知識を獲得することで将来的に冗長化できるように動いているところです。
まとめ
ヤプリでのインシデント対応の流れについてご紹介しました。
インシデント対応については各社それぞれ工夫されてることがあると思いますので、自社の工夫などあれば是非コメントいただければと思います！
ヤプリに興味をもったという方や、もう少し具体的な話が聞いてみたいと思った方はぜひカジュアル面談にお越しください。
