どうも、SREチームのリーダーを務めておりますkoskohei( @hukuroukk )と申します。
普段は SRE チームのマネジメント、また施策の実施をメンバー同様行いつつ、組織の横断的な課題のために自分に鞭を打ちながら日々奔走しております。鞭はそこまで痛くないやつを使っています。自分に甘いので。
さて、今回ブログには直近行っていましたインシデントレスポンス改善の取り組みについて紹介しようと思い筆をとりました。もしよければお付き合いください。
サービスの信頼性を損なう時はどんな時か。
サイト信頼性エンジニアリング（SRE）において、以下記事でも語られていることですが、現状のサービスの信頼性を把握し、その時点で信頼性を向上させる必要があるのかを判断するためには SLI、SLA、SLOを定義、追跡をする必要があります。
SRE の基本（2021 年版）: SLI、SLA、SLO の比較 | Google Cloud 公式ブログ
これらの値、特にSLOやSLAに関しては企業として遵守することが非常に重要ですが、適正な値を継続して保つためには健全なアプリケーション開発はもちろん、インフラストラクチャの可用性などサービスの開発の一連の流れの中で考慮しなければならない技術的な要素は多く存在します。
では、この SLO や SLAを欠損させるものは何なのか、それは予期せぬインシデントです(当たり前なことですいません)。 インシデントの発生原因は選定、利用している技術要素によって千差万別であり、それぞれの発生原因に即した適切なアプローチをしない限り、収束しませんし再発を招くこととなります。これにより SLO の欠損を大きくし、また同じ事象での欠損を繰り返します。
故に次のアクションを検討するポストモーテムを含めたインシデントレスポンスの一連の流れはSLO、SLAの遵守において非常に重要です。
hacomonoでのインシデントレスポンスの課題
hacomonoでは急速に利用ユーザーが増え、そして企業規模の拡大により開発する機能の数、スピードが上がり、インシデントの数は相対的に増え、hacomono内でも課題となっていました。
インシデント発生原因のプロダクトに関する対策については、それぞれの開発チームにて適宜検討、進行されていましたが、現状のインシデントレスポンスには以下の課題がありました。
1．インシデント増加に伴うインシデントレスポンスの記録業務の負荷増加
インシデントが相対的に増加したことにより、hacomonoではインシデントレポートを作成するのですが、記録内容の多さから人と時間のリソースを消費させられていました。
これによりそれぞれの持つ通常業務にも影響を与え、よりポストモーテムにも時間を割きづらい状況になりつつあり、インシデントという改善のチャンスを掴み損ねる可能性が高まっていました。
2．インシデントコマンダーの担当者やインシデント調査者のアサイン偏りを受けた知見の偏り
インシデントコマンダーとはインシデントレスポンスにおける指揮を取る役割です。発生中の意思決定や調査担当者のアサイン、対応情報の収集…などインシデントを解決するための重要なタスクを担っています。インシデントコマンダーについては PagerDuty さんの以下記事をぜひご確認ください。
インシデントコマンダーとは？ 〜現代のIT運用には必須！その役割と理由〜|インシデント管理プラットフォーム│PagerDuty
このインシデントコマンダーはどの組織でもありがちだとは思いますが判断することが多く、自分にその裁量があるのか？と感じてしまい、なかなか自ら担当する！と名乗りあげることにハードルが高くなりがちになります。そのため、hacomonoでもリーダー、マネージャーで構成された横断組織(PSIRT)で担当者をアサインしていたのですが、通常業務の兼ね合いなどでこれにも偏りが生まれ、ノウハウが偏りがちな状況に陥っていました。
故に、一部の人間だけがインシデントコマンダーをやるのではなく、よりインシデントに近いプロダクト関係者でもインシデントコマンダーをやれる、やっていい文化づくりの構築が必要でした。
3．インシデントの課題箇所分析のための情報の不足
現状のインシデント発生後のレポートにはタイムラインがあるのですが、これに検知、原因特定、解消などそれぞれのフェイズまでかかった時間やどの顧客が利用しているどの機能かの情報が分析可能なレベルで残っていませんでした。
例えば、SLOのことを配慮すると検知、原因特定、解消までの各フェイズに要した時間によってはそれぞれアプローチ方法が異なります。検知に時間がかかっているのであればモニタリング、アラートは十分だったのか？の観点での検討が必要となり、原因特定までの時間がかかるのであればログの情報や調査方法は適切だったのか？の観点が必要となるように適したアプローチの選定が必要です。
このように、どこで時間を取られていたかを関係者各位が一目瞭然に理解できるようにすることで、ポストモーテムでの方針決定、アクション出しも効率的に行え、より適切なアクションへ導くことが可能となるような、そして結果的にSLOの損失を防ぎやすいインシデントレスポンスの構築を目指す必要がありました。
課題に対するアプローチ
これらの課題に対して以下のアプローチを実施しています。
- Waroomの利用によるインシデントレスポンスの記録業務全般の負担軽減
- インシデント訓練、研修の実施と各チームでインシデントレスポンスを開始できる体制づくり
- 個々のインシデント分析情報の提供
Waroomの利用によるインシデントレスポンスの記録業務全般の負担軽減
Waroom はインシデントレスポンスを改善することを目的としたインシデントマネジメントサービスです。
hacomonoでは以前インシデントレスポンス用のSlackAppを作成し、この一連の流れをできるよう開発運用していたのですが、機能面においてもWaroomの方が優秀かつ、メンテコストの面からも解放されるため、それらの解決を含めた目的で選定しました。
Waroom | つらいインシデント対応を楽に、学びに、そしてゼロに。
機能としては様々あるのですが、特に強力と感じているのがインシデントの Slack のやりとりから設定したプロンプトに基づいたインシデントレポートを作成してくれる点とランブックといういわゆる対応ステップをステップバイステップでSlack上で進められる機能です。
これにより、煩わしいインシデントタイムライン(xx:xx 対応開始 のような記録)の作成からエンジニアが解放されるとともに、今まで用意していたインシデントレスポンス用の対応チェックリストもなくすことができました。
このようなチェックリストは確かに有用であることもあるのですが、インシデントのような慌てるようなイベントの場合、やり忘れや適切なタイミングでのチェックができないことが多発していました。そのため、これらの機能は重宝しています。
他にもポストモーテムの自動作成機能、CloudWatchやDatadogといったアラートから自動でインシデントとして起票してくれる機能、Githubの最近のデプロイ履歴をインシデントと関連づけて表示してくれるような機能もありますので、同じような悩みをもってらっしゃる方はぜひ検討されると良いと思います。
インシデント訓練、研修の実施と各チームでインシデントレスポンスを開始できる体制づくり
こちらはちょっと泥臭いといいますか、技術的な解決方法ではないのですが、インシデントレスポンス改善を行うにあたって、各チームでインシデントコマンダー、そしてインシデントレスポンスの体制が組めるようマニュアルの整備、インシデント訓練、そして e-learningによるインシデントコマンダー研修を用意しました。
インシデント訓練に関しては以下の流れに沿って、ツールの使い方や報告の仕方などの一連の流れを学ぶことができるトレーニングになっています。このトレーニングは各チームごとに開催しており、これによって各チームごとにインシデントレスポンスを進めていくことを自覚してもらっていました。
こちらもe-learningでいいんじゃないか、という話もあるのですがやはり訓練でしか得られない栄養があるといっても過言ではないくらいインシデント訓練は重要に感じています。
リアルタイムでできる質問、その時々の微妙な判断の迷いなどを質問できるのでインシデント訓練の最も大きな目的である”インシデントを恐れず対応できるよう前提知識を畳み込む”という意味ではやはり実開催の方が効果は高い気がしております。
ただこのまま人数も増えてくることも考えると現実的ではなくリソースに余裕がある時にしかできないため、できる限り実開催、リソースには厳しい場合は e-learningといった形式にはなってきそうです。
インシデントコマンダー研修については先述の通り e-learning で学習、ナレッジテストができるトレーニングです。インシデントコマンダーは一般的にインシデントレスポンスを指揮する人と理解されていると思いますが、その役割に求める具体的なアクションは意外と明瞭じゃなかったりします。これはhacomonoでも起こっていて、それを実態と紐づけることでインシデントコマンダーのハードルを下げる取り組みの一つとしてこちらを提供しています。
個々のインシデント分析情報の提供
ちょっとこちらはまだ試験運用段階なのですが、課題に挙げていた情報不足による方針の迷いを防ぐために、例としては以下のような検知から原因特定、原因特定から解消までの時間を可視化できるようにしています。
出し方としてはこちらもWaroomのプロンプトで原因特定時間などをプロント設定で出すようにしてもらい、それをNotion Chartで描画することで社員であれば見れる状況にしています。
今後このようなデータをはじめとしたインシデントの傾向をつかみつつ、ポストモーテムを行うような文化を定着することによってより原因に即したアプローチが出てくることを期待したいと思っています。
なお、Waroomにもインサイト機能がありまして、こちらで要件が満たせる場合こちらを使ったほうが楽なので検討するのがいいと思います。
インシデントを分析する
最後に
今回 hacomono のインシデントレスポンスの改善について書かせていただきました。
インシデントレスポンスの課題は仕組みで解決するものもあるのですが、それぞれのメンバーの意識改革なども含め文化的な側面も大いにあると活動を通して感じています。そのためおろそかにするとプロダクトの信頼性を徐々に蝕んでいくとともにメンバーのモチベーション、やる気にも影響が出てくると思いますので、今後も継続して改善を進めていきたいなと改めて感じました。
hacomono SREチームでは信頼性を俯瞰的にみてアプローチをしていますので、興味がある方はぜひカジュアル面談をご希望ください。
カジュアル面談 / 株式会社hacomono
hacomonoは先日資金調達について発表を行い、採用イベントを実施します。興味がある方はぜひご参加ください！
株式会社hacomonoでは一緒に働く仲間を募集しています。
エンジニア採用サイトや採用ウィッシュリストもぜひご覧ください！
