こんにちは！ エムスリーエンジニアリンググループ、 SRE チームの平岡(@uhtter)です。 こちらは エムスリー Advent Calendar 2022 の15日目の記事になります。
SRE が担当するの重要なタスクの1つに、インシデント対応があります。 インシデント対応では、システム・サービスの可用性・継続性を損なう問題（インシデント）が発生した際、それをアラートとして受け取り、問題を解消してすみやかにサービスが継続できる状態に復旧します。 SRE 本 でも、 SRE として配属された新人がまず目指すべきは「オンコール業務（≒インシデント対応）をこなせるようになること」と示唆されていますし、それをサポートする組織的なプロセスやトレーニングの方法が数多く紹介されています。 それらを踏まえても、インシデント対応の重要性については改めて問うべくもないでしょう。
エムスリーでは、2000年の創業以来、様々なサービスを長期に渡って開発・運用してきました。 私（平岡）が入社したのは 2018 年で、エムスリーの 20 年超の歴史の中では短い期間ではありますが、その中で経験してきたことを踏まえまして、 エムスリーのサービスで問題が発生した際のインシデント対応がどのように変化してきたかの変遷と、今後の展望について述べたいと思います。
インシデント対応の3つの段階（レベル）
インシデント対応は、「システム・サービスの継続性を損なう問題（インシデント）が発生した際、それを検出したアラートを受け取り、問題を解消してすみやかにサービスを継続できる状態に復旧する」という一連のプロセスです。 この記事では、インシデント対応の成熟段階として以下3つのレベルを仮定して説明します。
- レベル1: 素朴なインシデント対応
- 「問題を検出する→伝える→対応する」というシンプルなプロセスを実装する段階。
- レベル2: 認知負荷の軽減
- ビジネスのスケールに伴い、シンプルなプロセスの積み重ねが量的な負荷として認識される段階。
- レベル3: インシデント対応の暗黙知化を防ぐ
- サービスの長期運用に伴い、時間軸上で散発的なインシデントが発生する中で、対応方法の暗黙知化がネックになっていく段階。
これらの3段階は、一般論として論じられているものではなく、あくまでエムスリーの SRE チームに所属する中で個人的に体感したイメージに基づいています。 実際の業務プロセスの変遷に明確な段階分けは必ずしもなく、グラデーション的に変化していくことも多いかと思いますが、今回はわかりやすさを優先したいと思います。
以降でそれぞれの段階について具体的に説明していきます。
レベル1: 素朴なインシデント対応
インシデント対応のプロセスを単純化すると、「システム・サービスで発生した問題を検出し、それを人に伝え、人が対応する」という3ステップで説明できると思います。 ここでは、それぞれのステップをどう実装するかについて簡単に考えてみます。
一番最初の「システム・サービスで発生した問題*1を検出する」というステップについては、システム・サービスの健全性を監視する方法として一般的な方法が知られているため、それに従って実装することが多いかと思います。 例えば、定期的なヘルスチェックを行ったり、システムのメトリクス収集、リクエストのレスポンスタイムの記録などがよく行われるかと思います。
次の「（問題を）人に伝える」というステップは、言わば人とシステムとの間のインターフェースの話ですので、明確な正解はないと思いますが、例えばメールやSMSを使ったり、Slack などのチャットツールを使うなどして実装できると思います。 SRE の文脈では、複数種類の伝達方法を用意して優先度付けを行ったり、避難経路を用意することでインシデント対応プロセス自体の継続性を考えることもあると思います。
最後の「（人が、問題に）対応する」というステップは、問題の原因を特定し、それを取り除き、解決を確認する、という人間が主体となるステップになります。 プロセスの中で最もケースバイケースで不安定なステップですが、初期段階では「状況を見て対処する」というファジーな方針を定めるに留めるのが一般的なのではないかと思います。
これら3ステップが揃うことで、インシデント対応のプロセスの一連を実現できます。
レベル2: 認知負荷の軽減
レベル1の段階では、1つあるいは少数のシステム・サービスの範囲でインシデント対応を行う上でよく機能するかと思います。 ただし、企業としてビジネスが（喜ばしくも）成長し、多数のシステム・サービスが並立するようになってくると、質の異なる問題が顕在化してきます。 それは、システム・サービスが増えると、問題が発生する頻度が増え、人にそれが伝達される（＝アラートの）機会が必然的に増える、ということです。
システム・サービスの数に単純比例するのではなく、サービス間の依存関係に依って、1箇所で発生した問題から爆発的な数のアラートが発生することもしばしば起きます。 人にとってアラートは「できるだけ早く対応しなければならないもの」という前提があるため、認知負荷が極端に高い状態になります。 この状況が頻発すると、人間側が対応に追われ、疲弊してしまう（アラート疲れ）ことに繋がります。 こういったアラート疲れへの対策として、インシデント対応の「質を下げずに量を減らす」ための対策が求められます。
例えば、エムスリーの SRE チームで行っているアラート疲れの対策として、以下のようなものが挙げられます。
- はじめに素朴に実装した結果存在しがちな、対応が不要なアラートを抑制する。
- 外部のサービスに依存する問題など、根本的な対応が困難なアラートは通知の頻度を落とす。
- 「どのシステム・サービスの」「どの種類のアラートに」「誰が対応できるか」を見直すことで、アラートの交通整理を行う。
2022年、 SRE チームでは上記のような細々とした対策を「アラートの棚卸し」として定期的に行ってきました。 地道な作業の繰り返しでしたが、最近ようやく認知負荷が軽減してきた実感を得られるようになってきたと感じています。
レベル3: インシデント対応の暗黙知化を防ぐ
インシデント対応における「（人が、問題に）対応する」というステップは、対応する人の知識と経験に依存するタスクです。 システム・サービスの初期段階から運用に携わってきた人は、必然的に知識量・経験値が多くなるため、対応の効率も良くなります。 対して、後から参画したメンバーは知識も経験も少なくなるため、少なからず対応に苦慮することになります。
長期的に運用に携わってきた人が持っている知識を暗黙知のままにしておくことにはリスクを伴います。 サービスの運用が長期に渡ると、初期のメンバーが居なくなったり、居なくならなくとも昔のことを忘れてしまいます。 昔に稼働したサービスを構成する技術スタックは、パブリックに検索して得られる情報量も減るため、一度失った知識を再び得ることは容易ではありません。 この状況を避けるために、知識の暗黙知化を避け、明文化された形式知としておくことは極めて重要です。
SRE のプラクティスでは、こういった問題への対応として仕組み（機械的なシステム or 組織的なプロセス）で対応するべきとされます。 インシデント対応における知識の暗黙知化を避けるためには、 ポストモーテム を残す方法がよく知られています。 エムスリーにおいても、インシデントの発生時にポストモーテムを残す取り組みが実践されています。
SRE チームでは、サービスの継続性に関わるような重大なインシデントが発生した際にポストモーテムを作成することにしています。 重大インシデントの発生直後では調査状況の共有に役立ち、解決後は次回発生時のプレイブックとして参照できるため、とても有用な情報源になっていると感じます。
一方で、日々発生する非重大なインシデント（サービスの継続性に直接影響しない、ともするとアラートの削減対象とも見做せるような問題）については、対応作業を記録する厳密なルール、仕組みはありませんでした*2。 先に挙げた認知負荷の問題は、日々発生する非重大なインシデントでも起き得ますし、重大 or 非重大の判断自体が暗黙知になってしまう、ということも大いに有り得ます。 そのため、非重大なインシデントの対応作業についても、記録しておくことに意義があります。
現在 SRE チームでは、日々の非重大なインシデントも含めたインシデント管理の仕組みの導入検討を進めています。 PagerDuty などのインシデント管理機能を有する SaaS を活用する等、アラートの伝達手段も含めた見直しを、来年に向けて行っていく予定です。 今後も続いていくサービスの長期運用に耐えられる仕組みとして、新たなインシデント対応プロセスを考えていきたいと思っています。
私たちが目指すこと
エムスリーでは、過去から現在まで挑戦的にサービスの企画・開発を行ってきた結果、長期に渡り運用が継続しているサービスと、新しく生まれたばかりのサービスの両方が並立しています。 そういった環境の中で、個人に依存しない、継続性の高いインシデント対応プロセスを構築していくことは容易ではなかったように思います。 一方で、サービスが長期的に運用されていくと、開発の初期から参画していたメンバーに頼らずとも回る仕組みが求められ、継続性の高いインシデント対応プロセスの需要は、逆に高まっているように感じます。 インシデント対応プロセスは、システム・サービスを取り巻く仕組みであると同時に人・組織を巻き込んだ仕組みであるため、その改善はチャレンジしがいのあるテーマだと感じています。 エムスリーの SRE チームの一員として、エムスリーのサービスが今後も運用を継続していけるよう、インシデント対応プロセスの改善に取り組んでいきたいと思います。
We are hiring!
というわけで、エムスリーのエンジニアリンググループでは、多種多様なシステム・サービスの開発・運用に継続的に取り組んでいただけるエンジニアの皆さんをお待ちしています。 SRE メンバーについては、全体に横断的に関わるコア SRE と、個別のサービスの運用改善に注力できるチーム SRE の双方で絶賛募集中です。 取り組みがいのある課題に積極的にチャレンジできる環境だと思いますので、興味を持たれた方はぜひ応募してみて下さい！
