リモートチームでシステム障害に立ち向かう対応フローを作って運用してみた
ソフトウェア開発をやっていると避けては通れないのがシステム障害。 ソフトウェア開発チームは障害を0に限りなく近づけるために頑張っていても、時折起きてしまうのが現実ですよね。 起きてほしくないシステム障害ではありますが、システム障害はチームが強くなる機会だと捉えています。 この記事では、障害対応フローの紹介と説明と、運用してみて良かったことについて紹介していこうと思います。
背景
初めに背景を軽く紹介すると、私がスクラムマスターを務めているプロジェクトで、システム障害の根本対応が本質的解決になっていなかったことが原因で、同じ問題を繰り返してしまったことがありました。これを受けて障害対応フローを再整備して、障害に強くナレッジが溜まりやすい仕組みを作ることに挑戦してみました。 プロジェクトはWebアプリ、API、モバイルアプリがあります。開発チームは以下の5名で構成されています。
エンジニアの技術レベルは高いため、私は障害発生時にファシリテーターとして振る舞うようにしています。
また、タイトルにもある通り、このチームはリモートで構成されていて、メンバーは日本各地バラバラに点在しています。 そのため、Slack や Google Hangout などのツールを駆使して一緒に働いています。 リモートならではの困り事もありますが、リモートだろうがオフィスだろうが大筋はそれほど変わりないと思います。
それでは、実際の対応フローを時系列に沿って紹介していきます。
【認知】障害発生！戦いの始まり
発生してしまいました。システムトラブル。 スクラムマスターは即座に Slack で障害が発生した旨を通知して、 Google Hangout に開発メンバーを招集します。
落ち込んでいる人もいれば、慌てている人もいるかもしれません。 一呼吸置いてから、明るいトーンで「お疲れ様です！」と挨拶をして始めましょう。
スクラムマスターは以下の障害対応フローテンプレートをコピペした issue を起票し、チームみんなでこれを見ながら対応に当たります。 ここまで終わったら認知フェーズは完了です。
# 認知
- [ ] Slack の #general に @channel で事故が発生している旨をアナウンス（実施者: 事故に気付いた人）
- [ ] スクラムマスターは障害対応チケットを起票（実施者: スクラムマスター）
- [ ] DS 部屋に集合（対象: 開発メンバー）
# 判断
- [ ] 問題の階層の認識を合わせながら、対応の方針を検討（以下のフォーマットに沿って原因分析すること）
事象: 何が起こっているのかを正確に把握する
問題: それによって誰がどう困るのかを確認する
原因: なぜそれが発生してしまうのかを検討する
解決策: 以上を踏まえてどういった施策を行うか決定する
- [ ] チェックポイントの確認
- [ ] [事象] みんなの目で確かに確認しましたか？ 再現しない問題に対処するのは鳩に豆鉄砲です。
- [ ] [問題] それは本当に対処しなければならない問題ですか？ 実は誰も困らないかも？
- [ ] [原因] 原因は確かですか？ 仮説に過ぎないなら検証してから次に進みましょう。
- [ ] [解決策] 問題の先送りになっていませんか？ 怪しいようならもっと根本的な原因から考え直しましょう。
- [ ] 事象・問題・原因・解決策を障害対応issueにコメントとして投稿する
- [ ] 解決策に対してチーム内で合意形成する
# 操作
- [ ] 対応コードを書く
- [ ] 対応コードのレビューを行う（コンソール操作は画面共有で確認しながら実施する）
- [ ] リリースチケットを発行する
-> 以降はリリースフローに準拠して作業を実施する。
【判断】認識を合わせながら必要十分な戦略を
『怪しそうなところを速攻修正して hotfix ！』 これは危ないパターンです。ついつい解決策に走りたくなるのは自然なことだと思います。 しかし、はやる気持ちを抑えて事象・問題・原因・解決策の順に、メンバーで認識を合わせながら障害対応を進めていきます。
事象: 何が起こっているのかを正確に把握する
いわゆる再現確認です。 再現確認は自分の手を動かし、自分の目で確認するのが一番です。 機種依存や環境依存など、みんなの手元で再現できない場合は、再現できる人の画面共有をしてみんなで確認するようにします。
なかなか再現しないと『レアケース』ということで優先度を下げたくなってきます。 しかし、開発者からすればたくさんの利用者のうちの1人かもしれませんが、障害の影響を受けた利用者にとっては目の前で起こっていることがユーザー体験の全てです。 場合によっては困っている人にヒヤリングをしたり、そばで見せてもらったりして、なんとか手がかりを探していきましょう。
問題: それによって誰がどう困るのかを確認する
再現確認ができたら、一体何が問題なのか確認します。
「◯◯機能の利用中にアプリが先に進まない」というように、システムをベースに考えるのではなく、 「◯◯したいユーザーが△△することができない。」というように、どんな利用者がどんな時に困るのかを整理します。
こうすることによって、問題のクリティカル度をよりユーザー視点で判断することができます。 場合によってはただの操作ミスであって対応の必要がないこともあります。（利用者の操作ミスを誘発してしまうシステムにも改善の余地があります。しかし、「やらなくてはならないタスク」ではなく、「やった方が良いタスク」なので、チームで定められた場所に起票しておきましょう。）
原因: なぜそれが発生してしまうのかを検討する
続いては問題の原因を特定していきます。 ここでは目の前で起きている事象の原因を探っていきます。 事象と問題の認識が揃っていると、メンバーから「◯◯が原因ではないか？」といった仮説が上がってきます。 ここで上がったものは『仮説』に過ぎません。検証されて始めて『原因』になります。 検証すると、空振りに終わるパターンは意外と多くあります。 原因さえしっかりと特定したら、あと一息です！
解決策: 以上を踏まえてどういった施策を行うか決定する
原因さえ特定されれば、解決策は色々と出てくるはずです。 あくまで障害対応なので、スピーディーに対応できる必要十分な解決策を選択していきましょう。
【操作】いよいよシステムに執刀！
ついにシステムに手を入れていきます。 事象・問題・原因・解決策の認識があっていれば、やることは明確になっているはずです。 システムに手を入れる時も、必ず複数人で対応に当たるようにします。 ソースコードに手を入れる場合は画面共有をしながらペアプロをしたりコードレビューを行うようにします。 コンソールで作業をする時は、画面共有をしながら互いに確認しながら操作を行っていきます。
一次対応完了！ ナレッジ共有や根本対応のための振り返り
一次対応お疲れさまでした。 ここからはもう一度、障害の内容の振り返りをするのと、根本対応について話し合っていきます。 振り返りは以下のテンプレートに沿って行っています。 開発チーム以外への情報共有にも使えるので、丁寧に書いていきましょう。
## 事象 - ○○が□□になった ## 経緯 - yyyy/mm/dd HH:MM: ○○発生 - yyyy/mm/dd HH:MM: □□に連絡 ## 影響範囲 - ◯◯なユーザーが△△を利用できなくなった ## 原因 - ○○が□□だったため ## 一次対応 - □□を△△に変更 ## 根本原因 - ○○を確認するしくみが無かった ## 根本対応 - ○○しなくていいようにする
一次対応で事象・問題・原因・解決策についてしっかりと話し合っておくと、 最後の根本原因や根本対応のディスカッションが驚くほどスムーズに進みます。 ここの根本原因こそが『チームの弱み』であるため、根本対応を行うことこそが『チームを強くすること』だと私は考えています。
導入してみてのチームの変化
このフローを３ヶ月ほどチームで運用してみました。 運用してみて良かったこととして、元の課題であった障害の対応不良を防げるようになった他にも2つチームに変化があったように感じます。
1つ目は、障害対応の時間がワイワイと楽しくなり（こう書くと不謹慎に見えますが・・・）、かつ、対応時間が短くなりました。 強敵なボスに作戦を立てながらパーティーで立ち向かうような感覚です。少数の人が頭を抱えて対応するよりも良いことだと思います。
2つ目は、チームの障害に対する意識が高まりました。私達のチームでは2ヶ月ごとにチーム及び個人の目標設定をしているのですが、障害の根本対応に関連する目標を掲げるメンバーがいたりするなど、メンバーの行動にも変化が現れているように感じます。
まとめ
この記事では私たちのチームの障害対応フローの紹介と、フローを導入してのチームの変化について紹介しました。 障害は無いに越したことは無いですが、今後も発生してしまった時は強いチームを作る好機として捉えて行きたいと思います。
