こんにちは、サーバーサイドグループのマネージャーの鬼木です。
今回は今年から取り組み始めたサーバーサイドグループで行っているインシデント改善の取り組みについて紹介します。
弊社では今後のサービス拡大に向けて、新規開発だけでなく保守面の強化も進めています。その一環として、今年からサーバーサイドグループ内でインシデント対応の改善を目的とした委員会1を立ち上げ、活動を行ってきました。現在は委員会は5名で運営しています。
今回はこの取り組みや、ヤプリでの改善活動の流れについて紹介します。
委員会の目的
委員会設立にあたり、その活動目的を「インシデント改善を永続的に行う文化の醸成」としました。
発足時にヤプリの保守強化を進めるためにどういったアプローチを取るのが効果的かといった観点で今後の活動内容を模索していました。初めはシステムの特定部分の保守性や信頼性を向上させることで全体的なインシデントの影響を大きく抑えられる部分があればと思い模索していましたが、過去のインシデントの原因は多様で、局所的な対応で大きな効果を得られるケースは少ないことがわかりました。
しかし、ポストモーテム後の根本的解決のためのシステム改善のようなインシデント後の改善にしっかり向き合い、継続することで1～2年後にはインシデント件数の削減が見込めたり、また個々のエンジニアやチームとしてインシデント改善の意識の向上ができれば長期的にインシデントに強い組織を作っていくことができると考え、この目的を設定するに至りました。
具体的なアクション
具体的な取り組みとしては、ポストモーテムで出たネクストアクション（根本的解決のためのシステム改善）がどの程度行われたかを定量的に測れるようにし、それを目標に落とし込んでネクストアクションの実施を推進していくことにしました。
弊社のインシデント対応後のフローとしては、ポストモーテムを実施し、ネクストアクションがあればそれをチケット化して取り組んでいます。優先度の高いチケットの消化は行われていたため完全に滞っていたわけではありませんが、メインのPJでの開発業務の傍らでの保守業務（ポストモーテムのネクストアクション以外も含む）となるため着手できていないものも多く改善の余地があったこと、この課題解消を通して前述のインシデント改善を永続的に行う文化の醸成という目的に繋げていければと思い、まずこの活動にフォーカスしていくことにしました。
この委員会発足をきっかけによりインシデント改善について学んでいますが、インシデントフローの整備やインシデント分析といったいくつかのインシデント改善領域の中でポストモーテムからのシステム改善の重要性について説かれていることも多く、発足から半年以上経った今、改めて組織として重点的に取り組んでいくことに価値がある部分だと感じています。
実際の取り組み
目標設定
弊社ではOKRを用いて四半期ごとにKRを設定しています。
今回は前述のポストモーテムから出たネクストアクションのチケットにポイントを付け、クォーターごとにXXポイントを実施するという目標としました。 ポイント制のKRはよくある目標設定ですが意識している部分があり、目標設定はあえて余裕を持たせたものを設定しています。
前述の通りメインのPJでの開発業務の傍らでの保守業務となる前提の元、インシデント改善を永続的に行う文化の醸成という目的を達成するため重要なのは継続性だと考え、短期的な多くのネクストアクションの消化よりも長期的に持続可能な目標ラインに設定しています。
またヤプリ全体の保守活動という点で見ると、ビジネスサイドからの改善要望やエンジニアの自発的なシステム改善といったその他の推進したい改善活動も数多くあるため、この会の目的を達成しつつ他の改善も行っていきたいという意味でもこのような目標設定ラインにしています。
委員会の取り組み
委員会の取り組みとして定例を週に1回、1時間行っています。直近でポストモーテムが複数開催された場合に備えて長めに時間を取っていますが、議題がない時や少ない時は早めに解散するか、スキップすることもあります。
会の流れとしては以下のような形で行っています。
- ポストモーテムの背景や原因の認識をそろえる
- ポストモーテムで出たネクストアクションのチケットの確認、整理
- チケットにポイントを付ける
1. ポストモーテムの背景や原因の認識をそろえる
まず直近実施されたポストモーテムのドキュメントを確認し、背景や原因の認識を揃えます。 原因はポストモーテムドキュメントに書かれていますが、2,3の作業を行うために背景・原因を深掘りするのが大事なためこの作業に10~30分ほど要することが多いです。
わからない部分の疑問解消を行うことに加えて、これはどういう仕組みだったら起きなかったのかなど対象のインシデントに対する解像度を上げていき、時には「このインシデントって他のサービスでも起こる可能性があるよね」などざっくばらんに話しながら理解を深めていきます。
このインシデントを深掘りしていくことも重要なプロセスと捉えています。 ポストモーテムの意義には同じ事故を2度と起こさない、というものだけでなく、インシデントで起こった内容を共有してチームや個人での知見にするということもあり、長期的に見てチームにとって重要な財産となるためこの能動的にインシデントから学んでいくプロセスを重視しています。
実際、DBのDead lockやネットワーク越しの更新処理によるデータ不整合など、ヤプリのような大規模サービスではインシデントから学ぶことで知識として知っていたものが技術として身についていくものもあるため、個々のエンジニアの技術力向上にも寄与できる部分だと考えています。
※ 弊社では以下のようなポストモーテムドキュメントのテンプレートを使用しています
2. ポストモーテムで出たネクストアクションのチケットの確認、整理
ポストモーテムの背景や原因の認識をそろったあとはポストモーテムで出たネクストアクションのチケットの確認、整理を行います。
会の発足時にネクストアクションのチケットの消化率を上げるために消化率が高くなかったことの原因分析を行いましたが、チケット作成者の主観に偏った説明になってしまいそのインシデントを経験してない人にとってわかりやすいものになっていなかったり、1チケットの粒度が大きく簡単に着手できないようなものになっているということがありました。
インシデント改善を行う文化の定着に重きを置いた際に委員会が行えるアクションとして、行うことにモチベーションが上がる環境を作る、行うにあたってネガティブな要素を排除するということができると考えました。（前提として、文化の定着を目的としているため強制ではなく能動的な改善チケットの実施を目指しています）
例えば弊社ではYappdate Dayという月に2日間普段所属しているプロジェクト以外の改善活動を行う日があり、その際にビジネスサイドからの改善要望チケットなどいくつかのチケットのレコメンドを行いますが、期限付き以外は任意で着手していく形になるので実装内容が抽象的なチケットや粒度の大きいものは着手されないことが多い一方で、内容が具体的かつ粒度の小さいものは着手しやすいものとなるため、チケットのdescriptionを事前知識なしでも理解できるというラインを指標にしてチケットの整理を行っています。またこの整理していく作業も委員会メンバーにとっては参加してないチケットのdescriptionを書くことが1と合わせて過去のインシデントの内容理解にもつながっています。
Yappdate Dayは月に2日間連日で行うため集中しやすいですが、逆に2日間で終わらないとこの期間にやっていた作業に戻ってきた時のコンテキストスイッチのコストにもつながるため、チケットを細分化して説明も明瞭にすることでこの期間に集中して終わらせられるような形にし、インシデント改善が進みやすい環境づくりを行っています。
※ チケットの例
3. チケットにポイントを付ける
チケット分割後は、ポイント付けを行います。プランニングポーカーアプリ（plapo.net）を使い、フィボナッチ数列でポイントを付けます。会の発足時に特定のチケットに対してポイントを付けたので、そのチケットとの比較で新しいチケットのポイント付けを行っています。
ここではスムーズに全員近いポイントがつくこともあれば、大きく異なる場合もあります。 異なる場合はそのチケットの実作業の認識にズレがあるということが多いので会話してその認識のズレを合わせていきます。
まだ対象の作業に関する知見がないメンバーにとっては技術的な考慮が足りてなかったという部分がズレになることもありますし、逆に在籍期間が長いメンバーにとってはドメイン知識がない前提での部分を考慮できてなかったり、慣れてない実装者にとってレガシーな部分でテストが書きづらい、動作検証しづらいなどの部分を考慮できていなかったりするので様々なメンバーで議論することで発見が多い時間になっていると感じます。
このポイント付けを終えて、インシデントの課題からネクストアクションまで一気通貫して理解・説明できるようになるので全てのプロセスで解像度を上げていくことを意識しています。
そして整理したチケットをサーバーチームの定例で共有するなどして前述のYappdate Dayなどで対応していく流れになります。
補足：ポイントの正確性について
ポイント制の目標設定で往々にして出てくる議題の１つとして、ポイントの正確性をどの程度担保するか、という観点があるかと思います。
ポイントの正確性を重視するため指標を作成するなどのアプローチもありますが、この会ではあえてそれをやらずにプランニングポーカーでのポイント付けにしています。
このインシデント改善委員会の取り組みで重要なのは継続性のため、運営委員会自体のコスト削減も重要だと考えています。
ストレッチな目標設定のケースではポイントの正確性が重要になってくるので結果としてシビアにポイントを付けなければならなくなり、チケットのポイント付けに必要以上の工数見積もり行う必要が出てくるなど委員会の運営コストも高くなってしまいますが、今回は前述の通り最低限の改善を長く続けていこうという前提の元の余裕を持った目標設定にすることでポイントの正確性がシビアになりすぎないようにも設計しています。
シビアにポイントをつけていく方が良い場合もありますが、継続性を重視したサブプロジェクトや改善活動ではこのように目的に合わせて目標設定・コントロールするのも社内全体の開発をバランス良く行っていくという意味で大事なことだと思っています。
振り返り
うまくいったこと
1. 今まで未着手だった多くのチケットを消化することができた
実際に実施したチケット数は、今年の始めからのポストモーテムから作成したネクストアクションチケット59件のうち、合計42件のチケットを消化することができました。対応していた期間が偏ることもなく継続した改善活動が実施できていたと思いますし、毎クォーターサーバーチーム全体の3分の1から半数ほどのメンバーが対応するなど、消化数だけでなくチームとして対応することができたと思います。
2. 「インシデントで起こった内容を共有してチームや個人での知見にする」の体現
前述の「インシデントで起こった内容を共有してチームや個人での知見にする」について、こちらはすぐに事故対応力が上がるものではありませんが、過去に確認したポストモーテムの内容が関連したアラート対応などで委員会の活動を生かして対応できたというようなケースも徐々に出始めてきました。これだけでも成果にはなりますが、さらに長く続けていくことでこのような自分が関わっていないインシデントから学んで対応できるケースも増えていくのではないかとイメージすることができました。
※ 実際の対応例（アラート検知から対応優先度判定まで行ったケース）
3. 委員会の運営コストが低く保つことができた
前述のポイントの正確性についての部分で触れた部分で、委員会自体の運営コスト削減も重要なことだと考えていました。実際、定例の準備コストなども含めて運営コストは低く設計できており、今後も通常業務を行いながらもこの委員会を長く続けていくことができそうと感じています。
今後行っていきたいこと
ある程度の期間インシデント改善に向き合っていると、インシデントの知見共有やアラート設定などの開発以外の改善活動も出てくるようになりました。前述の通りインシデントの知見共有もアラート対応に繋がるなど大事なことだと感じているので、こういったアクションもポイントの対象にしていくなど、インシデント改善活動の輪が広がっていくような仕組みづくりを行っていきたいと感じています。
また、9ヶ月継続的に改善活動を行うことができましたが活動目的である「インシデント改善を永続的に行う文化の醸成」を達成できたかについては期間によっては対応メンバーが偏ることもあり、まだまだ発展途上と考えているので引き続きこの目標を重視しながら仕組みの再構築などを行っていきたいと思います。
最後に
ヤプリではメインのプロジェクトの開発に加え、今回ご紹介したような改善活動も行っています。
この記事を読んで弊社に興味を持たれた方はぜひカジュアル面談にお越しください！
- ヤプリではメインプロジェクトほどの規模感ではないが何かしらの組織的な活動を推進したい時にサブプロジェクト的に編成 or 有志でメンバーを募ってチームを作り、活動するということがあり、これを委員会と呼んでいます。実はこのYappli Tech Blogに関してもテックブログ委員会があり、公開する前にレビューを行ったり社内で直近公開されたテックブログを共有して盛り上げるなど、テックブログを書くことを推進するための活動をしています。↩
