0から始めるインシデントマネジメント -導入編-
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、インシデントマネジメントを導入する目的や、最初に制定する３つの要素について提示する記事になります。
インシデントマネジメントをスムーズに行うためのツール・具体的なワークフローや課題解決の手法の紹介は別途案内します。
はじめにインシデントマネジメントの目的1. MTTR(平均障害復旧時間)の短縮2. インシデント発生回数の低減3. ユーザ満足度低減の抑制導入編1. インシデントオーナーの確立2. インシデントコマンダーの確立3. トリアージの決定終わりに
はじめに
日々システムを運用する中で、我々は多くのアラートと向き合います。
システムや組織の規模が小さい場合は対応できていた問題も、システムと組織がスケールされていくと共に以下のような多くの課題が発生します。
- 担当者不在のシステムが常にアラートを出している
- 特定の開発者がアラート対応をしており、属人化が進行している
- 過去発生したインシデントの再発率が高い
- ユーザへ大きな影響を与えるインシデントが発生した際の対応フローが決定されておらず、復旧に多くの時間を要する
- ユーザアナウンスの必要有無の判断基準が設定されておらず、都度上長の判断が必要
- 監視の設定漏れがあり、ユーザ問い合わせ経由で障害に気づく
これらの課題は結果として障害復旧を遅らせる要因となり、結果ユーザ視点からのサービスへの信頼を損なう結果となります。
このような課題を解決するためにインシデントマネジメントを行います。
以降では、これら問題を解決するためのイントロダクションとしてAmebaでの事例も交えながら何をすべきかをお話しします。
インシデントマネジメントの目的
SRGは弊社メディアサービスの各事業に対してインシデントマネジメントを行っており、Amebaにおいても上記課題を解決するための活動を推進しています。ここでは、主に以下の3点をインシデントマネジメントの目的としています。
- MTTR(平均障害復旧時間)の短縮
- インシデント発生回数の低減
- ユーザ満足度低減の抑制
1. MTTR(平均障害復旧時間)の短縮
システムが故障、または問題が発生したタイミングから復旧するまでにかかった時間の平均を指します。
インシデント対応における運用サイクルを継続的に改善することで障害発生から復旧までの時間を短縮させるのが目的です。
2. インシデント発生回数の低減
Postmortemなどを行い、インシデント発生に繋がる種を事前に排除することでインシデント自体の発生を低減させる事が目的です。
3. ユーザ満足度低減の抑制
サービスが利用できない状況であるにも関わらず、サービスサイドから何のアナウンスもなく数時間経過してしまうとユーザはそのサービスを信頼しなくなります。ここではインシデント発生時におけるユーザへのコミュニケーションを最適化する事でサービスに対する信頼性低下を抑制させることを目的とします。
これらの目的を達成するために具体的に何をすれば良いかを以降で説明します。
導入編
- インシデントオーナーの確立
- インシデントコマンダーの確立
- トリアージの決定
1. インシデントオーナーの確立
インシデントオーナーは「事業へのインシデントマネジメント文化の導入と継続的な改善に責任を負う」ロールです。
インシデントマネジメントは導入後の定量的な効果測定が非常に困難であるため、全ての組織に対して簡単に導入できるかといえばそうではありません。特に課題が拡大していないような小規模の組織である場合、リソース投資の対象になりにくいため、インシデントオーナーは事業の状態を加味した上で導入する必要があります。
また、導入が決定した後もMTTR(平均障害復旧時間)という言葉があるように、インシデントマネジメントにおいては継続的な改善が重要となります。必要であればMTTAを計測することでデータ収集を行ったり、メンバーと共に文化醸成に対する戦略を策定するなど、中長期的な目標を掲げてチームを牽引する人物が必要です。
2. インシデントコマンダーの確立
インシデントコマンダー（以後：IC）とは「インシデントの解決に責任を負う」ロールです。
一部ケースを除き、基本的にICは復旧作業は行わず、関係各所へのコミュニケーションやメンバーへの作業指示に徹します。
特に規模が大きいインシデントほどICの役割は重要になるため、普段から軽微なインシデントをICとして体験するためにローテーションを組むと良いでしょう。
- インシデントの収束まで責任を負う
- システム復旧に関する意思決定
- 関係各所へのコミュニケーション
- 復旧対応チーム・連絡網(slack chなど)の立ち上げ
- 作業メンバーへの指示
- Postmortemの作成
インシデントオーナーとの違いはインシデント発生時にのみ確立されるポジションであり、あくまでも点のロールになります。
インシデントマネジメントサイクルが問題なく機能しているかどうかといった継続的な改善については責任を負いません。
3. トリアージの決定
発生したインシデントの「対応優先順位を決定するため」にトリアージ(Severity)を決定します。
トリアージを設定することで、インシデントが複数発生した場合の対応優先順位の決定や、第三者視点(事業責任者など)でのインシデントの重要度の把握・インシデント対応フローの策定/体制構築などがしやすくなります。
Amebaでは以下のようにSEV1 - SEV5でトリアージを決定しており、各レベルによって対応・体制が異なります。
例えば、SEV3以上のインシデントにおいてはスタッフブログを経由したユーザへの障害報告が義務付けられており、そのためにユーザコミュニケーションを含めた対応をICが対応を行います。(※AmebaではSRE観点でいうところのコミュニケーションコマンダーは設定していません。複雑なユーザーコミュニケーションを要するサービスでない場合は必要ないと思われます。)
これにより、影響度が大きいインシデントが発生した場合にエンジニアは復旧作業のみに集中する事が可能となります。
逆にSEV4以下のインシデントに関してはワークフローが複雑でないため、エンジニアがICとして復旧対応に責任を負う事となります。
注意すべきはSEVの判断はICに頼っても良いという点です。
SEV判断が遅れると障害復旧自体も遅れます。必要であればSEV判断をICに気軽に依頼できるような空気作りが重要です。
終わりに
今回はインシデントマネジメント導入において必須となる3項目を提示しました。
次回は具体的なワークフローや課題解決の手法などを案内します。
参考に以前SRE関連のイベントでお話ししたスライドを貼っておきます！
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。
