本記事は、Lancers（ランサーズ） Advent Calendar 2024 の7日目の記事です。
Webサービス/アプリにおいて障害が発生すると、ユーザーさんに深刻な影響を及ぼし、ビジネスにとってもリスクとなる可能性があります。
発生させたくないものではありますが、発生してしまった場合、どのようなフロー・役割分担で解決に至っていますか？
ランサーズでは、現行の障害対応フローに関していくつか課題があり、CRE・SREチームを中心に見直しを行っています。
障害対応フローにおける課題
- 管理プロセスの課題
- 最終的に誰が意思決定するのかフローが煩雑
- 旗振りが機能しているようで機能していない（仕組みとして整い切れていない）
- 役割と責任の課題
- アサイン先が不明なものがある、軽微な考慮漏れ・仕様不備の場合にボール浮きがち
- 対応フローが属人化している（それぞれの裁量に任されている）
- コミュニケーションの課題
- 今具体的に何が起きているのかが把握しづらい
今回の記事では、1と2に関する改善案をまとめていきます。
改善後フロー案（アップデート中）
インシデントコマンダーが旗振り役として機能するよう、指示系統の中心に定義しました。
現状では私がインシデントコマンダーの役割を担っています。
以下、いくつかのポイントでフローを説明していきます。
速報レベル付けと障害対応フローのスコープに関して
ランサーズではS/A/B/C/Dで障害レベル付けを行っています。（Sが一番高い）
緊急度と重要度が高いS/Aを障害対応フローの対象とすることにしました。
影響範囲が比較的軽微で改善要望レベルのB以下はGitHubでIssue化してbacklog管理下におき、担当者の判断で対応となります。
役割分担に関して
今まで明確に決めていなかったことが、ボールが宙に浮いてしまったりふわっとさせる要因になってしまっていたな…と思います。
今回、下記分類で担当を決めることでアサイン先が明確になるのはそれぞれの領域でユーザー価値提供をするうえでもよいことだと思っています。
基盤：Aさん+Bさん
WEB：進行中のPJTはPJTリーダー、それ以外はCREチーム
アプリ：Cさん
会計：Dさん
デザイン・UI/UX：Eさん
仕様不備：PdM（Fさん+Gさん）
さいごに
障害発生時こそ冷静な対応が必要で、予め備えておくことが少しでも早い解決につながると考えています。
実際に運用するなかで改善ポイントがでてくるかと思いますが、ひとつずつ向き合い、磨いていければと思っています。
Lancers では、一緒に働けるメンバーを募集しています！
https://recruit.jobcan.jp/lancers01/list/all/all