責任回避の文化は対処のしようがない

昔のことであるが、私は本番で障害を起こしたことがある。

開発中のソースをSTGにアップしたら、なぜか本番に適用された。

慌ててソースを戻して事なきを得たが、その後の社内は大揉め。

原因は単純で、引き継ぎ資料の不備だった。

当時いた会社では、新規開発部隊と保守開発部隊が分かれていた。保守側は、運用しながら追加開発やリリースを担当する形。

しかも当時は、今みたいなCI/CDも未成熟。バージョン管理ツールはあったが、リリースは手順書ベースの手作業だった。

最初は「開発 → STG環境」向けに手順書が作られていたのだが、後から本番環境が追加された際に、どうもコピペミスが発生したらしい。

結果、STG向けの接続先が本番になっていた。

当然、「いや引き継ぎ資料がおかしいだろ」という話になる。

ところが新規開発側からは、

「事前に本番にアクセスしてログ確認しない奴が悪い」

みたいな空気が出てきて、現場はかなり険悪になった記憶がある。

もちろん、今振り返れば「本番での事前確認をしておけば防げた」も正しい。

ただ、それ以前に問題だったのは文化の方だった。

新規開発側は「作ったから後よろしく」

保守側は「聞いてない」

しかも厄介なのが、新規開発と保守開発は元々別会社で、合併というか、実質買収された経緯がある。人の交流も少なく、お互いにあまり良い感情を持っていなかった。

本来なら、しばらくの期間はお互いの部署から人を出して共同運用しておけば、こんな単純ミスは起きなかったはずだがそれができなかったわけ。

こうなると、もう個別の安全対策では追いつかない。

チェックリストを増やしても、手順を厳しくしても、レビューを追加しても、

根本に「相手に押し付ける文化」がある限り、必ずどこかで事故る。

大規模障害というのは、技術的なミス単体ではなく、

こういう人間側の問題が積み重なった結果として、表に出てくる。

今はCI/CDもIaCも当たり前になり、手順書のコピペミスで本番が吹き飛ぶようなことは、確かに減った。

ただ、現場を見ていて思うのは、問題そのものは消えていないということ。姿を変えて、別の場所で同じことが起きているだけだ。

「Terraformの権限設定、相手のチームがやると思ってた」

「CIに乗せたから、後はSREでよろしく」

「ドキュメントはConfluenceに置いたので読んでおいて」

道具が変わっただけで、構造はあの頃と何も変わっていない。

技術で解決できるのは「ミスの起きやすさ」までで、「相手の仕事への関心のなさ」までは直せない。

だから、システムを設計するときに最初に見るべきなのは、アーキテクチャ図でもパイプラインでもなく、

それを動かす人たちが、お互いの仕事を自分ごととして話せているかどうか、だと思っている。

そこさえ崩れていなければ、たいていの事故は事前に潰せる。

逆に、そこが崩れていたら、どんな立派な仕組みを入れても、遅かれ早かれ同じ穴が開く。

結局、私たちが向き合うべき相手は、ツールでも手順書でもなく、ずっと「隣の席の人との距離」なのだと思う。