本セッションの登壇者
セッション動画
「インシデント対応を改善しよう」というタイトルで発表させていただきます。MerpayとMercoinでSREチームをやっている高木と申します。
本日見ていただいている方はSRE、あるいはインフラ担当者が多いのかなと思うんですけれど、インシデント対応はやっていますか？ SRE、あるいはSREに限らず開発者の方も、何かしらサービスをリリースして運用するとなるとインシデント対応はどこかで必ず経験するのではないかと思います。
本日のテーマとしては、そのインシデント対応をどうやって改善できるかを紹介したいと思います。もちろん自分もそうですが、インシデント対応はやらなくて済むならやりたくない。とはいえSREをやっていく以上避けられないので、どうすればよりよいインシデント対応ができるか、あるいは少し先回りしてどうやったらインシデントを減らすことができるか、そんなことを紹介したいと思います。タイトルはわかりやすく「インシデント対応を改善しよう」にしましたが、対応自体を改善する話に加えて、インシデントの管理を改善する話もしたいと思います。
簡単に自己紹介をします。今、MerpayのSREでエンジニアリングマネージャーとテックリードみたいな役割をやっています。Merpayに入社してから5年程度、サービスをリリースしてからは4年程度たちました。今年、Mercoinというサービスもリリースして、金融系のサービスのSREとして5年近くやっています。今、自分のチームは合計12人でサービスの運用をしています。金融系のサービスというのがポイントでもありまして、お客様はもちろんですが、いろいろなパートナーさんがいる中で金融系、特にお金を扱うので、なるべくインシデントを起こしてはいけないというサービスの性質があります。加えてインシデントが起きた時には社外の人にも、どういう理由でこのインシデントが発生して、どういう再発防止策を社内でやってますということを共有するので、インシデントをきちんと管理して再発を防ぐというのが会社としても重要な仕事となっています。
インシデント対応は「振り返り」を大切に
はじめに前提として、インシデントって何だっけというのを改めて考えてみます。予期せず提供してるサービスが利用できなくなったり、あるいは機能が提供できない状態のことを今回はインシデントと言っています。いわゆるメンテナンスなどは、サービス提供はできませんがインシデントには含みません。インシデント対応というのはインシデントが起きた時にそれを解決するための仕組みだったり、あるいはその被害を減らしたり、解決をより早くする、準備や事後対応みたいな取り組みも含めて、インシデント対応と呼んでいます。
なぜ改善したいかと言うと、やはりインシデントの数を減らしたいということがあります。再発防止をちゃんとしてインシデントを減らすのが重要です。もう1つは、インシデントの影響を減らすことです。いくら防いでも必ずインシデントは起きてしまうので、そういう時になるべく早く気付いてなるべく早く解決するというのも重要になってきます。そんなインシデント改善のためのアクションとして、今回は4つにまとめて紹介します。
インシデント対応はいろいろなサービスでやっていると思うんですけど、経験上よくある問題としては、振り返りが行われないというのがあるかなと思います。インシデントが起きて、みんなでなんとか直して解決して、よし大丈夫だと、もうとりあえず再発もしてないのでこれでいいだろうということで、原因とか今後は起きないことを確認せずに、とりあえず日々の仕事に戻ってしまうみたいなことはわりとよくある話でしょう。また、ちゃんと振り返りをして、今後は起きないような対策は決まっても、それが優先度も上がらずチケットが放置されてなかなか対応されないパターンもあるのではないかと思います。
そういった状態を改善していくために一番重要なこととして最初にお伝えしたいのは、振り返りを行う、ポストモーテムと呼びますけれど、これが一番重要かなと思っています。チームでインシデントを振り返って、いつインシデントが発生して、いつ気付いて、いつ修復したかといったタイムラインや、どのようなサービスで何人ぐらいのお客様に影響が出たのかという影響範囲、アプリケーションの実装が悪かったのか、インフラの問題だったのかといった発生原因もちゃんと分析して、解決方法も、暫定対応はこうやって対応できたけど今後再発防止するためにはこういうことが必要ではないかとか、そういった振り返りをチームで行って、それを記録として残しておくのが一番重要です。
それができたら次に重要なのが、いろんなインシデントが起きる中でちゃんと対応がされているのか、振り返りがされてるのかを社内でトラッキングすることです。いろいろなインシデントが起きる中で、レポートを書いて、それを誰かが取りまとめて管理して、再発防止がされているかなどをトラッキングして、振り返りがまだのインシデントに対して振り返りをお願いしたりといったアクションをしていくのも大事です。
忘れがちだが恒久対応はマスト、計測と分析で集合知に
振り返りがされて管理ができたら、次に、再発防止策と恒久対応を必ず実施するということが重要です。自分が思う恒久対応は2つあって、1つはいわゆる再発防止のための仕組みです。ただバグを直しましただけではなくて、こういうテストを書くことで今後はもう起きないようになりますよとか、あるいは問題に気付くのが遅くなったので監視設定でこういう監視を追加してもっと早く気付けるようにしますよ、対応方法が決まってなかったので決めてドキュメントにしてチームに共有しますよ、といった、今後につながる対応を明確にして共有するということもやっています。今、Merpayではインシデントレポートの中で再発防止策を書いてもらって、それをマネージャーやSREチームがレビューして、これで本当によいかを管理しています。
次にやりたいことは、インシデント対応を計測することです。インシデントが発生してから復旧するまでの時間というのが一番わかりやすい指標かなと思うんですけど、このタイムラインをちゃんと記録しておくことで、今回のインシデントが何分ぐらい続いたのか、もっと早く気付いてもっと早く治せなかったかなどを分析して、会社としての目標を決めたりもできるようになります。ここに書いてあるMTTRは発生してから修復するまでの時間の平均値ですが、このような値を指標に使うのが一般的だと思います。
レポートを書いて個別のインシデントを整理した後で、分析というのも重要になってきます。いろいろ分析項目があると思いますが、深刻度や発生原因、アプリケーション実装の変更が悪かったのか、あるいはオペレーションのミスだったのか、あるいはクラウドやサードパーティの障害だったのかという原因を分類したり、担当チームを含めいろいろな項目を分類して分析することで、組織全体でどういうところでインシデントが多く起こっているのかがわかるので、重点的に組織として改善すべき領域や、その優先度を決めることができるようになります。
社内に広く共有して改善に活かす
最後に、そうやって分析したインシデントをただ担当チームだけが知っているのはもったいないので、それをなるべく会社内に共有するというのも社内でやっています。インシデント対応というのは結構つらい経験ではあるんですけど、今後の改善のチャンスでもあるので、たとえば他のチームのミスも自分のチームで知ることで、「これは自分たちも対応しておこう」みたいに未然に塞ぐことができます。今、社内ではインシデントの中でも特徴的だったものを社内に共有するための自由参加の共有会みたいなものを開いたり、定期的にインシデントのサマリーレポートを作って、どういうところの障害が多かったかなどレポートを共有したりする取り組みもやっています。
まとめとしては、インシデント対応を改善していく中で一番重要なこととしては、振り返りがあります。振り返りを行ってそれが次の改善に生きることで、インシデントを減らしたり、よりよい改善ができるようになったりすると思います。これはSREのプラクティスでもあるんですけど、SREだけでは完結しない取り組みですので、開発者、あるいはエンジニア以外の組織も巻き込んで改善する文化を作っていきましょう。
おまけとして、こういった取り組みをやるにあたって自分たちは最初スプレッドシートやいわゆるチケット管理システムみたいなものから始めましたが、最近はいろいろ便利なものもあるので、こういうツールを導入すると、今言ったようなプラクティスが比較的始めやすいと思います。
