システム障害に対するエンジニアの心構え 〜その障害の損失、何人分の年収？〜
こんにちは、エンジニアリングマネージャー(EM)のMJです。
僕はこれまで複数のベンチャー上場企業でテックリードやEMのキャリアを歩んできまして、多くのシステム障害を出しましたし、マネジメントもしてきました。
数々の障害に直面してきて、自身や対応したメンバーのことを振り返ると、障害と向き合う姿勢や意識で、エンジニアとしての技術力や応用力が大きく成長すると感じています。
この記事では、システム障害に対してどんな観点で向き合うべきかを書いてみようと思います。
なぜ、障害は出してはいけないのか
自分の書いたコードで障害が出たなら恥ずかしいから、チームメンバーに迷惑がかかるから、とかそういうレベルではないです。
もちろん「ユーザーに迷惑がかかるから」というのは理由としてありますが、本当の理由はその先です。
システムが停止したら、ユーザーが利用できなくなり、機会損失による利益減少で事業の存続が危ぶまれる可能性あります。だから、障害は出してはいけないのです。
あなたのシステムが止まったら損失額はいくら？
障害が起きてしまったら、大小関わらず影響範囲や損失額を把握すべきと考えています。
レポートラインに報告するためでもありますが、障害の自分ごと化の意識の醸成という側面が強いです。自分が出した障害がどれだけの影響を与えたのかを直視することは、エンジニアとしての成長に繋がります。
どんなエラーが出ていたか、停止時間はどれくらいだったか、何が原因だったのかなど、把握しなくてはいけないことはたくさんありますが、最優先で把握すべきは障害による事業損失です。
損失額の計算
以下は例です。
1時間、基幹システムが停止して、100件できたはずの商談がゼロに。成約率は20%で1件あたり粗利が50万円の場合は、1000万円の損失
1時間、ECサイトが停止して該当時間の平均売上は500万円だった場合は、そのままそれが損失
1時間、1万企業が利用するSaaSが停止し、0.5%のユーザーが不安を感じ解約。利用料は平均10万円だった場合の損失は50 * 10万 * 12ヶ月 = 6000万円/年
ゲームの詫び石だって、例えば1000円分のガチャをユーザーに無償で配ることになるので、配布した分の売上機会損失になりますね。
数字上で見るだけだと「大きい額だな」とか「まぁそんなもんか」くらいにしか思わないかもしれませんが、自分が出した障害の損失を目の当たりにすると本当に血の気が引きます。
損失額の価値
たとえば1000万円の損失を出してしまったとしましょう。その1000万円の価値を考えたことがありますか？
実は意外と「1000万円の損失を出してしまった」という事実があっても、その重大さにピンとこない人もいます。会社の事業規模が大きければ大きいほど、そうなるかもしれません。金銭感覚のズレは少なからず生じるでしょう。
とはいえ1000万円です。日本の年収の中央値は約400万円ですから2.5人分の年収に値します。これが吹き飛びます。本来生まれていたはずのお金が吹き飛び流通しなくなるんですから、立派な経済損失です。
損失を生む障害はそれだけ重く受け止めて、障害を出さない努力を怠ってはいけないんです。
損失額が計算できない？
開発・運営しているものの中には、直接的な利益を生まないシステム、間接的なサポートをするシステムなど、停止しても損失額を計算するのが難しいものもあるでしょう。と、思いきや、多くのその類のシステムは間接的なKPIを生み、結果的に利益につながっています。
例えば業界トレンドを営業メンバーに配信するシステムが停止したとしても、商談には影響ないかもしれません。しかし、商談の中で発生したトレンドについての話題でうまく会話ができず、信用を獲得できなかったため成約できなかったという影響を出してしまった可能性はあります。
担当するシステムは、止まった時にどんな事業影響を及ぼすのかを把握しておきましょう。
Webサイトだって止まってしまったら、広告費をかけていた場合はそれが無駄になります。他にも(これはアーキテクチャ面に多大な課題がありますが)SPOFとなって他の連携サービスに影響を及ぼしているかもしれません。
損失額が計算できないとしても、出てしまった障害によりどんな影響が出てしまったのか、測りえる数字で把握することが大切です。障害の影響を数字でちゃんと見てますか？
なぜ、損失を把握しなくてはいけないのか
損失額の把握は、自分ごと化のための大切な行動ですが、他にも理由があります。損失を出すことで、改めて担当するシステムの利用価値を再認識することができます。
仮に全停止したとして、その損失が大きかった場合は「提供価値が高いシステム」であると言えます。精度の高い運用を心がけなくてはいけません。
逆に、完全停止したにも関わらず損失が小さかった場合は「提供価値がまだ低いシステム」であるとも言えます。価値の創出や活用の見直しなどが必要です。
価値あるシステムを責任感を持って運用する
担当するシステムの価値を知らなければ、システムへの愛着や責任感が薄れていきます。そうなると当然、障害への意識が下がっていきますし、そのための取り組みなどもなくなっていってしまいます。
身の回りのものでも、価値を感じないものを僕らは雑に扱いがちです。雑に扱うものはいつまでたっても雑に扱い続けます。
逆に価値を感じているものに対して、僕らはとても丁寧に扱います。丁寧に扱っているうちに、こだわりも増え、扱い方のノウハウも増え、扱いが上手くなっていきます。
話を戻すと、システムの価値を知らないと、システムに対しての責任感が強くならず、結果的に品質が上がっていきません。品質が上がらないということは技術力も上がっていないということだと僕は思います。それはプロフェッショナルとは言えないと思うんです。
障害の心構え
損失を考えると障害に対する心構えが変わってきます。
完全停止するような障害じゃなければ「まぁいいか」じゃないです。あなたが出した障害が小さかったのはたまたまで、エンバグする箇所によってはサービス全停止も全然ありえます。慢心や怠慢は障害のもとです。
しかし、完全に障害を防ぐことは残念ながら不可能です。とはいえ、損失を最小限にする方法を考え抜き、行動をすることが大切な心構えです。
万が一、サービスが停止してしまっても、影響規模を小さくする方法はなにか、停止時間を最小限にするにはどうしたらいいのかなど、対策を講じて日々運用すべきです。
再発防止の心構え
再発防止の仕組みづくりも重要です。
障害を出してしまったら、それを再発させないためにどうするかを検討しますが、コード修正や根性論で終わらせないでください。
なぜ間違ったコードがリリースされてしまったのか、なぜオペレーションを間違ってしまったのか、なぜ修正が遅れてしまったのか、なぜ誰も気付けなかったのか、など問わなければいけないポイントがたくさんあります。
課題のあったポイントそれぞれで再発防止のための仕組み化ができないかを考え抜くのが、大切な心構えです。
まとめ
システム障害は悪です。何も良いことはありません。起こさない努力を怠ってはいけません。それでも起きてしまうのが障害ですが、そこから多くのことを学ばなければなりません。
損失額や事業数値への影響を僕らはもっと知るべきなのです。そしてシステムの価値を再認識し、より安全でユーザーに喜ばれる品質に上げていくのが、プロフェッショナルだと思うわけです。
この記事で、少しでもあなたに役立つヒントをお届けできたなら嬉しいです。
ではでは。MJでした〜。