はじめに

日々発生する障害のうち、システムの全体停止はサービス影響が極めて大きいものです。そのため、未然に防止したり、発生したら再発を防がなければならない障害の1つです。

そんな中、こんな障害が起きたとします。本番環境のデータベース接続数が上限に達し、システムが停止し、サービスが提供できなくなる。調査すると、特定の処理が接続を解放していなかったことがわかる。プログラムを修正し、テストで確認し、本番環境へリリースする。「これで再発しないはずだ」——そう考え、ほっとしてシステム運用を続けていたとします。

ところが数ヶ月後、似たような障害が再び起きる。今度は違うプログラム、違う担当者、違う時間帯。それでも障害に至る経緯をたどると、どこか前回と似ている。

なぜでしょうか。

もしかすると、障害を「技術の問題」としてだけ捉えてしまっているからかもしれません。

技術的には正しい対策なのに、なぜ不十分なのか

先の例に戻ってみます。「接続を解放しないバグを直す」こと自体は必要な対策です。技術的な原因が明らかなら、技術的に対応するのは当然のことです。

しかし、ここで分析を終えてしまうと、「なぜその問題が本番環境で発生してしまったのか」という問いが残ります。たとえば、次のような状況だったかもしれません。

• 性能試験の環境と本番環境の条件が十分に一致していなかった
• リリース前の確認項目に、DB接続数という観点そのものがなかった
• リリース後に異常を検知する監視も十分ではなかった

この場合、プログラムを修正するだけでは、問題の一部しか解決していないことになります。「接続を解放しない」という技術的な問題の背後に、「テストプロセスの問題」「リリースプロセスの問題」「監視の問題」が存在している可能性があるからです。

さらに掘り下げると、なぜそのテストが実施されなかったのか、なぜ監視が必要だという認識が共有されなかったのか、なぜ開発・運用の間で確認できなかったのか、という組織上の問題に行き着くこともあります。

つまり、一つの障害の中に、技術・プロセス・組織という複数の問題が重なっていることがあるわけです。これは決して珍しいことではないと筆者は考えています。

障害を「技術・プロセス・組織」の三層で見る

障害の原因を考えるとき、多面的に問題を捉えることが大切です。冒頭の例のように、技術的な要素の一面しか見ない場合は、それ以外の要因を見落としてしまうからです。

このとき、安全工学の世界でよく使われるスイスチーズモデルという考え方が参考になります。一枚のチーズに穴があっても、後ろに何枚も重なっていれば、穴を通り抜けて事故に至ることはありません。事故が起きるのは、たまたま複数の層の穴が一直線に並んでしまったときです。システム障害もこれと同じで、技術という一枚の防御層に穴が開いていたとしても、プロセスや組織という他の層がしっかりしていれば、大事には至らないはずなのです。

少なくとも、次の三つの観点に分けて考えてみると、問題の所在が見えやすくなります。

一つ目は、技術の問題です。プログラムのバグ、設定ミス、性能不足、ネットワーク障害、データ不整合など、システムそのものに存在する問題です。この場合は、プログラムを修正する、設定を変更する、構成を見直す、監視を追加するといった技術的な対策が中心になります。

二つ目は、プロセスの問題です。テストが十分に行われていなかった、リリース手順に確認項目がなかった、障害発生時のエスカレーション基準が決まっていなかった、過去の類似障害の情報が再利用されなかった、といった問題です。これは、個人の技術力だけでは解決しにくい領域です。手順を見直したり、確認ポイントを追加したり、役割分担を明確にしたりする必要があります。

三つ目は、組織の問題です。開発部門と運用部門の連携が弱い、システム担当者と業務部門の間で優先順位が共有されていない、問題が発生しても特定の人に判断が集中する、といった問題です。障害対応を取り巻く課題として、組織間の連携不足、メンバーのスキル不足、関係性の構築不足など、人や組織に関わる問題はいくらでも出てきます。

ここで重要なのは、この三つを完全に別々のものとして扱わないことです。むしろ、技術・プロセス・組織はつながっていると考えたほうが実態に近いからです。

「担当者のミス」で終わらせてはいけない理由

もう一つ、障害対応の振り返りでよく起こるのが、「誰が間違えたのか」に議論が集中することです。

たとえば、本番環境の設定変更を誤り、サービスが停止したとします。「担当者が確認を怠った」という結論になったとしましょう。

確かに、担当者が確認を怠ったことは事実かもしれません。しかし、それだけでは再発防止につながらない可能性があります。

なぜ確認を怠ったのでしょうか。チェックリストがなかったのではないか。チェックリストはあったものの、確認者が明確になっていなかったのではないか。あるいは、作業時間が極端に短く設定されていたため、確認する余裕がなかったのかもしれません。さらに、そもそも本番環境への変更作業を一人で実施できる運用になっていたこと自体に問題がある可能性もあります。

このように考えていくと、「担当者の注意力を高める」という対策だけでは不十分だとわかります。

これは、安全文化の分野で語られるJust Culture（個人を罰するのではなく、仕組みの欠陥を見つけようとする文化）の考え方にも通じます。もちろん、個人の注意や教育が必要なケースもあります。しかし、「注意してください」「気を付けましょう」だけで再発を防げるのであれば、世の中から同じ障害はもっと早くなくなっているはずです。

人間は必ず間違えます。だからこそ、間違いが起きても重大な障害につながりにくい仕組みを考える必要があるのです。

問題の所在を間違えると対策も外れる

ここで重要になるのが、「どこに問題があるのか」を見極めることです。

同じ「設定変更ミス」という事象でも、対策は一つではありません。設定値を正しくすることは、技術的な対策です。変更前後の確認手順を追加することは、プロセス上の対策です。変更作業を一人に任せず、別の担当者が確認する仕組みにすることは、運用体制の対策です。さらに、開発・運用・業務部門の間で、変更による業務影響を事前に確認する会議体を設けるのであれば、それは組織的な対策といえるでしょう。

どこまで問題を捉えるかによって、打ち手は変わります。逆に言えば、問題の所在を間違えると、対策も外れてしまいます。「技術的な問題だから、システムを直そう」と考えているのに、本当の問題がリリースプロセスにあれば、技術的な修正を繰り返しても同じ種類の障害が発生するかもしれません。

だからこそ、障害の振り返りでは、最初から一つの原因に決めつけないことが大切です。「なぜ障害が起きたのか」だけではなく、「なぜそれを防げなかったのか」「なぜ早く検知できなかったのか」「なぜ適切な人に情報が伝わらなかったのか」と問いを広げてみると、技術的な原因とは別に、プロセスや組織に関する問題が見えてくることがあります。

「組織問題」に振りすぎるのも危険

ここまで読むと、「結局、システム障害の多くは組織問題に起因するのだから、組織を改善すればよい」という考え方が本質的だと感じてしまうのではないでしょうか。確かに、問題を抽象化し、なぜなぜ分析をしていくと、多くの場合、組織や文化に行き着くからです。しかし、これも少し危険です。

技術的な原因が明確なのに、組織論ばかり議論していては、必要な技術対策が遅れてしまいます。データベースの容量不足が原因で障害が起きたのであれば、まず容量を確保することが必要です。そのうえで、なぜ容量不足を事前に検知できなかったのか、容量管理のルールは適切だったのか、担当者や責任者は明確だったのか、と分析を広げていきます。

大切なのは、「技術か組織か」という二択ではありません。技術的な原因に対して技術的な対策を行いながら、その背景にあるプロセスや組織の問題まで必要に応じて掘り下げることです。つまり、問題を一段ずつ深く見ていくことです。たとえ技術的には軽微で、些細な障害だったとしても、プロセスや組織に起因する障害であれば、いつか大きな障害を引き起すかもしれないからです。

次に障害が起きたら立ち止まって問い直す

再発防止策は、原因を見つけて対策を書けば終わり、というものではありません。対策そのものが立派でも、実行まで時間がかかったり、管理不足で実行されなかったり、人の入れ替わりによって形骸化したりすれば、期待した効果は得られません。問題の所在を正しく捉え、実行可能な形に落とし込み、実際に組織の動きが変わったかを確認するところまで含めて、再発防止だと考える必要があります。

次に障害が発生したとき、ぜひ一度、原因分析の途中で立ち止まってみてください。「これは技術の問題だ」と結論を急ぐのではなく、「プロセスには問題がなかったか」「組織としての動きに問題はなかったか」と問い直してみるのです。

そうすると、これまで「また同じような障害が起きた」としか見えていなかった出来事が、「まだ改善できていない仕組みが見つかった」と捉え直せるかもしれません。その問いから始めることが、目の前の障害を直すだけでなく、障害に強い組織をつくるための第一歩になるはずです。