スムーズなインシデント対応を実現するための仕組み化
はじめに
みなさんこんにちは！
ワンキャリアでSREを担当しています渡邉(X：PWatanabeMiki)です！
現在私は「ONE CAREER CLOUD 採用管理」の開発チームのSREを主に担当しています。今回はワンキャリアで実践しているスムーズなインシデント対応を実現するための仕組み化を紹介しようと思います。
みなさんは「インシデントマネジメント」と聞いて何を思い浮かべますか？
一般的には、インシデントが発生した時に迅速に対応できるような体制や仕組みを指すことが多いと思います。しかし、実のところインシデントマネジメントには、インシデント発生時だけでなくインシデントを未然に防いだり再発防止のために振り返る仕組みも含まれています。
本記事では、以前開催されたLT会の登壇で使用した資料も交えてワンキャリアがインシデント前、インシデント中、インシデント後で行っている取り組みや仕組みを紹介します。
(LT会で登壇した時の資料はこちら)
インシデント前
まずは、インシデントが起こる前についてご紹介します。ワンキャリアでは、インフラアラートを緊急度別で分岐させています。また、SLO監視と正常監視で異常を素早く検知できる仕組みを採用しています。元々課題として、異常の検知や対応に着手するまでに時間がかかるという問題がありました。原因は、特定のアラートが飛んできても何をすれば良いかわからなかったり、そもそも不要なアラートがあってエンジニアの監視負荷が大きかったためです。
そこで一度アラート運用を見直し、ユーザーへの影響度を基準にアラートを外形監視と死活監視に分岐させました。外形監視は、リアルタイムでユーザーがサービスを使えなくなっている状態なので緊急で対応します。インフラリソースの逼迫やアプリケーションコンテナの死活監視は別のチャンネルに分けてアラートがきたら24時間以内に対応します。これらのアラートは必ずしもリアルタイムでユーザー影響が出ているわけではないので外形監視アラートとは分けて対応方針も違います。これによりアラート別の対応方針が明確になり、異常が発生してもスムーズに対応に移れるようになりました。
インシデント発生時
次は、インシデントが起きたときの体制についてです。発生したインシデントへの対応力を強化するため、曖昧になってしまっていたインシデント発生時の復旧対応手順とルール、コミュニケーションフローを見直し、明確化しました。その改善によって効率性が高まり、インシデント発生後もスムーズに復旧できるようになりました。
まず、手始めに復旧作業を担当するエンジニアの役割を明確にしました。
役割はコマンダーとサポーターの2つです。インシデントに関わるプロダクトのエンジニアがコマンダー、SREがサポーターとなり手分けして復旧作業を行います。具体的な役割と流れは以下のようになっています。
サポーター：
コマンダーが障害報告中にシステムの状態を確認する
インフラメトリクス、DBの状態、リクエスト数など
システムの状態を確認したらコマンダーに報告する
コマンダーの作業の一連をサービスが復旧するまで記録する
コマンダー：
関連メンバーに報告
サポーターからの報告を元に実際のサービス復旧作業方針を意思決定する
復旧作業を実施する
リリースのロールバックやサーバーの増強など
このように、復旧作業時に役割と手順を明確にすることで焦らずにインシデント対応ができるようになりました。
ステークホルダーへのインシデント報告を迅速化するために実施したこととして、コミュニケーションフローの明確化があげられます。
インシデント発生時は、迅速かつ適切なステークホルダーへの報告が不可欠です。そこで前もってステークホルダーへのコミュニケーションフローを作成し、インシデント発生時も円滑にコミュニケーションが取れるようにしました。
加えてコミュニケーションフローだけでなく、インシデントの報告用Slackワークフローを作成し報告すべきことが分散しないための報告テンプレートも整備しました。
インシデント発生後
最後に、インシデント発生後について軽くご紹介します。
ワンキャリアではサービスが復旧したら終わりではなく、ポストモーテムという振り返りをしています。
ワンキャリアで使用しているポストモーテムのテンプレートでは、「インシデントの原因は何か？」「誰がいつ何をしたか？」を記録し、「再発を防止するにはどうすれば良いか？」「恒久対応として誰がいつまでに何をやるか？」などをチームで議論します。
起きてしまったことは仕方がないかもしれませんが、インシデントの失敗から学んで同じ失敗を繰り返さないようにすることが大切です。
ポストモーテムではインシデントの原因や再発防止案などを話し合いますが、ここで重要なのは、メンバーを責めずにみんなで仕組みや体制を改善していくことです。誰かの誤操作によるインシデントもあるかもしれませんが、それでもそのメンバーを責めず、誤操作を起こさないように仕組みを改善することに着目すべきだと思います。
今後の展望
これまで、インシデント対応を迅速に行うための仕組みについてご紹介してきました。これらの取り組みにより、以前よりインシデントマネジメントが改善されましたが、まだまだ取り組むべき課題もあります。
例えば、システムの復旧作業が属人化していることも課題の1つです。現状ではシステムを復旧するエンジニアが限られているため、そのエンジニアが不在時のインシデントのリスクが高くなってしまいます。この課題を解決するためにも今後の展望として定期的にインシデント対応訓練を実施し、インシデント対応ができるエンジニアを増やしていきたいです。また、ポストモーテムの記録をいろんなチームにシェアすることでインシデント対応に関する知見のシェアを促進していきたいです。
最後に
いかがでしたか？
ワンキャリアで実施しているインシデントマネジメントの取り組みが１つでも参考になれば嬉しいです。まだまだ課題があるので引き続き改善に向けて取り組んでいきます！
▼ワンキャリアのエンジニア組織のことを知りたい方はまずこちら
▼カジュアル面談を希望の方はこちら
▼エンジニア求人票