🛡️

障害対応を一人のヒーロー'だけ'に押し付けるのを辞めるためにしたこと

2024/03/22に公開

はじめに

障害対応をマネージャーとして関わっていると、一部の頼もしいテックリードが障害という困難を乗り越えて解決してくれる事象をポジティブな気持ちのみではみていられません。
ヒーローはいつでも障害時に駆けつけてくれて、解決してくれるばかりではありません。
ヒーローは、いつしか障害という困難を押し付けられて孤独になりヴィランに堕ちてしまったり、去って二度と戻ってこないこともあるでしょう。
今回は、こういった望まない未来にならないように取り組んだことを振り返ってみたいと思います。

過去の失敗

私の経験として、これらのヒーローに頼り切った状態を放置した結果、以下のような経験をしました。

1. 開発プロセスが厳格になり過ぎてしまった

一人のヒーローに依存しすぎた末、ヒーローは開発の責任者になり過去の障害の遺恨から品質の鬼となりました。その結果、経営と対立するほどに開発リリースに時間がかかるようになりました。 開発プロセスにおけるレビュー厳格化などの対応が行われるようになり、レビューが終わらず、開発者のモチベーションが下がり、結果として品質が下がる、開発スピードは遅いという悪循環に陥りました。

2. ライフワークバランスが崩壊し退職してしまう

一部のヒーローに依存している状態を放置した結果、適切な休みを与えられず適切な待遇で応えられないという状況になり不満が爆発しヒーローは退職してしまいました。 優秀なエンジニアを失うことになり大きな損害を被りました。

心構え

障害対応を行える人間は技術的に優れた一部の人間であることがどのような環境でも多いのではないでしょうか。そういった人々はとても頼もしくありますが、真面目でモラルも高く、負担をたくさん背負いやすいです。ともすれば損な役回りになりがちです。
そんな彼らをヒーローと称した場合、

障害に対して組織で向き合っていくんだということをメッセージや行動(仕組みづくり)として態度に表しておくことが大事です。
そうすることで、障害対応する以外の人間の当事者意識を生み出し、組織で対応できるように変化していきます。

障害フロー・体制・役割を整理しよう

障害フローを作る

障害が発生したときのフローを作成しよう。
フローを作成することで体制(顧客・パートナー・サポート・営業・開発・保守運用エンジニア)を整理でき、それぞれの役割間での受け渡しの問題点を見つけることができます。
また、フローに起こせない部分は問題が潜んでいるので問題を浮き彫りにできます。
すでにある場合は、定期的に棚卸し改善していくことが大事です。

各役割が担う仕事を整理しよう

フローを整理することで障害が発生した際の役割が明確になってきます。
各役割の人間が行う行動、責任範囲などを書き出しておきます。
障害という緊急時で一人一人が混乱で指示がないと動けないといったときに、ここへ立ち返ることで障害の際に何もできないといったことを避けられます。

設定しておくと非常に助かるこんな役割

  • 書記→記録を作る
    • 障害が発生した初期段階から起きたことを事実ベースでまとめておけると社内の情報共有・顧客へのお知らせ・振り返り などあらゆる場面で役に立ちます。状況把握が早くなります。
  • テスト担当者→障害対応のためのテストを行う
    • 障害を素早く解決するためにテストが蔑ろにされ、さらなる障害を引き起こしたりします。焦らず障害対応するためにもテスト担当者は控えておいて、安心して対応できる環境を整えたいです。対応を行う人間の心理的な負担を軽減できます。

みんなのものにしよう

整理されたフローや役割などは各責任者に共有し認知してもらい協力してもらうようにネゴしておく。声が届きづらい立場にある人がいるようであれば、それなりの職責の人間に働きかけてもらうのも手です。

障害が発生した後はポストモーテムをしよう

振り返りは大事です。一定規模以上の障害が発生した際は、原則ポストモーテムを実施するようにしました。主催は様々ですが起点はQAチームに行ってもらっています、品質に責任を持つという意味合いです。
ポストモーテムを実施することによって、改善が進み常に進化していることを実感します。

ポストモーテムについては、
https://www.oreilly.co.jp/books/9784873117911/
15章 ポストモーテム(postmortem)の文化 失敗からの学び に詳しく書いてあります。

ポストモーテムをする動機

社内の人間に伝えたい持ってほしい思いとして、

それでも上手くいかないことは発生する

過去の事例としては、いち早く障害には気づいていたが障害を判定する基準が無く初動が遅れたことがありました。問題が発覚した時点では、大きな問題ではないと判断して通常のフローで対応を行っていたが通常のスピードで対応したせいで被害が拡大しました。
そのため、ポストモーテムの実施の後に、障害を判定する基準を作成し(これが難しい)、改善を進めました。このサイクルは、終わりがないものとして継続しています。

なぜサイクルは終わらないのか、それは組織は目標を立てて達成を目指しますが、目標を達成したら次のより高い目標を設定するからです。商いをしている限り、目標はアップデートされ続け、組織はそれに伴い成長し続けます。

まとめ

ヒーローがいるということは、ともすれば悪がいるということです。
悪=障害を発生させない、発生しても速やかに解決する、といった取り組みが大事です。
ポーストモーテムの文化によって継続的な改善が施され、現在の体制・仕組みが構築されました。
そのプロセスによって、メンバー一人一人の意識・スキル・責任が高まりヒーローに頼らない組織となってきています。

弊社の監視を担っているチームでは輪読で「入門 監視 モンダンナモニタリングのためのデザインパターン」を読んでいますが、3章のアラート、オンコール、インシデント管理のデザインパターンが図らずも弊社の取り組みと重なる部分が多く自分たちの取り組みをポジティブに追認できています。
https://www.oreilly.co.jp/books/9784873118642/
振り返り・ネクストアクション・人を責めずに仕組みを責めるといった形で今後も継続して進化していきたいと思います。

ソーシャルデータバンク テックブログ

Discussion