障害対応時の心構え

エクストーンの豊田です。Webサービスを運用しているとアプリケーションの不具合や過負荷等でサービスが正常に行えなくなり、その際は迅速な対応が求められます。今回は障害の対応時に自分が心がけていることをいくつか紹介したいと思います。なお、普段自分は以下のようなポジションでお仕事をしています。

  • Webサービスの開発責任者
  • Webサービスのインフラ管理担当
  • Webサービスの開発メンバー

平常心

自分のミスのせいでサービスが止まってしまったり、不具合が発生したりすると、どうしてもメンタルとしては慌てたり落ち込んだり焦ったりすることもあると思います。ある程度は人間なので仕方ないのですが、サービス運用している以上確率的に障害は発生するものだと割り切って、淡々と目の前の課題を解決していくようにしましょう。焦っても問題は解決しませんので、コーヒーでも入れるといいかと思います。

また、もしあなたが対応を指示する側ならば障害対応を実施する人を焦らせないようにしましょう。障害の原因を突き止め、解決するための情報収集を行い、対応する人と二人三脚で問題を乗り越える意識が大切です。

情報共有

とはいえ自分が落ち着いても、サービスの運用責任者やステークホルダーはどのような状況でサービスが正常に行えなくなり、いつ復旧するのかという情報が欲しくてやきもきしているでしょう。そういう状況は最終的に自分を焦らせる材料になってしまうので、彼らに対して適切に情報を共有し、一緒に問題を乗り越えていくという意識を持つことが大事です。

障害の原因を調査しているときに他の人にいちいち「いまどういう状況?」とか「いつ復旧するの?」とか聞かれるのはストレスなので、時間を決めて「何時何分に状況を共有します」と伝えておいて、集中して調査する時間を確保するといいかと思います。

情報を共有する場合、以下の内容を伝えるようにしています。

  • 調査内容
  • 障害の発生時刻
  • 原因
  • 影響範囲
  • 修正方法
  • 修正完了見込み時間

これを分かる範囲で共有するようにします。定時報告は大事。

誰かに隣にいてもらう

障害の原因調査についてはどうしても平常心でいられないこともあり、視野が狭くなってしまうこともあるので、あまり一人で立ち向かおうとしないことが大事です。自分の場合は調査中に思いついたことは全部口に出すようにして、隣にいる人に適当に拾ってもらったりすることが多いです。リモートワークをしている場合でも、ボイスチャットなどで繋がることが有効です。

役割分担

上の話にも関連することですが、障害対応は一人でやらない方がいいという話をしましたが、具体的に手伝ってくれる人がいるなら明確に役割分担をするといいと思います。

  • 原因を調査する担当
  • 不具合回避策を考える担当
  • 影響範囲の把握を行う担当
  • 定時報告を行う担当
  • なんか口頭で色々聞いてくる人をブロックする担当

障害対応中の開発者は120%くらいの集中力で物事を考えたりログを漁ったりしているので、集中力を妨げるような事象などからどうやって遠ざけるかを考えて、その場にいる人の間で適切に役割分担が出来るといいです。

影響範囲を早めに洗い出す

例えばアプリケーションの不具合でデータに不整合が発生するようなケースの場合、不具合を修正したとしてもデータの不整合は残ったままなので、不具合によって生じた影響をいち早く把握し適切に事後対応を行う必要があります。

影響範囲の大きさや重要さによって、サービス側が取るべき対応が変わりますしその意思決定は早めに行わないとサービス自体の信頼を損なうことにも繋がります。不具合の原因を見つけたら早く直してしまいたいという気持ちはあると思いますが、まずは影響範囲の把握に努めるようにします。ただし、影響範囲の拡大を防ぐために早く対応を行い、その後改めて確実に影響範囲を把握する、という選択をする必要がある場合もありますので、優先順位はケースバイケースで決めていくといいと思います。

後生に伝える

サービスの障害は多くの場合、その実装時に想定していなかった自体によって発生することがほとんどです。逆に言えば、想定していれば防ぐことが出来るものが多いです。そのため、障害のレポートはこれからサービスを運用していく開発者にとって重要なナレッジとなりますので、適切に障害レポートを作成し、何故このような障害が発生したのか、どのように解決したのか、どうすれば回避できたのか、を残すことが大事です。

もちろん後生に伝える前に、サービスのステークホルダーに対して適切な報告書を共有する必要があります。その場合、当然ながら再発防止策を求められることになりますが、ここは真面目に考えましょう。間違っても「気をつける」とか「ダブルチェックする」といった、お気持ちで解決するような再発防止策を書かないようにしましょう。

おわりに

サービスの障害というものは必ず発生するもので、事前に想定できなかった以上、その発生は誰か個人の責任では無く、チーム全体の責任です。なので、その解決もチームで一丸となって取り組む必要があります。誰が原因か、ではなく何が原因か、にフォーカスする必要があり、不必要な犯人捜しは問題解決にとって何の利益にもならないどころか、邪魔になります。

往々にして障害というものはより多く利用されているから発覚する、ということも言えるかと思います。サービスとしては障害が発生するくらいには利用者がいる、とポジティブに受けて止めてもいいのかもしれませんね。