もしもZennの障害がSIerで発生したら

Zennのサービスが1時間ほど止まった障害についてCatnoseさんからの説明の記事が出ていた。

障害への対応スピードが素晴らしく早い上に、修正案もしっかりと考えられており、さらには障害から得られた知見を社会のために広く公開する姿勢はエンジニアとして見習いたい。

Catnoseさんに心から敬意を表します。

Zennで発生した障害の原因と行なった対策のまとめ

さて、他方を上げて片方を下げるのはネットのお作法としては良くないが、SIerマンとしては

「もしもZennの障害がSIerで起こっていたら」

を考えずにはいられない。

まず、 サービスが重い || 動かない 障害が発生した場合、以下のような手順で障害対応が領域展開されていく。

このような膨大かつ煩雑な手順を追って障害対応が行われるため、Zennのように「3時間で問題を解決して復旧」というようなスピード感では仕事が進まない。

Zennの20倍くらいの人数で大騒ぎして、たくさん会議をして、たくさん報告して、船頭多くして船が山に登っていく。

たとえば今回のZennの障害では

「オートスケールの設定をケチっていたのが原因の一つ」

と紹介されているが、このような「オートスケール設定を見直す対応」がSIerで必要になった場合、まずインフラを管理している部署の人たちに相談して、設定変更作業を依頼しなければならない。

依頼と調整だけで1日以上かかってしまう。

さらに言うと、SIerでは

「VercelのPayloadを超えていた部分をCSR（クライアントサイトレンダリング）に変更」

みたいな対応を素早く行うことはできない。

「動いているものには触るな！」がSIerの原則なので、ソースコードの修正を伴う対応は複数回の会議を通してプロジェクトマネージャーに承認をもらわなければならない。

テストは絶対に自動化されていないため、ソースコードを少しでもいじるたびに目視でExcelの項目を埋めるためのテストをこなさなければならない。

もちろんテストのエビデンスはスクリーンショットだ。

画面のスクリーンショットなどをExcelに貼り付けていく。

リリースには当然承認が必要である。

リリースするために報告書を書いて、レビューを受けて、今度は「リリース担当チーム」にリリース作業を依頼する。

この作業には以下のような人々が登場する。

人数が多ければ多いほど報告にかけるコストは膨れ上がり、SIerではエンジニアではない人が多数登場するため、コミュニケーションのコストが非常に高い。

こうやって小さなことで大げさにして疲労と工数とストレスが大爆発してしまうのがSIerの障害対応の特徴である。

テストを自動化する文化がないため改修のコストが高く、モジュール間の結合度が高いため少しの改修のために膨大テストをしなければならない。

リリースも当然自動化されておらず（自前ツールでの中途半端な自動化はある）、いちいち人間が作業をして、確認していく。

開発に関係ないご意見番が大量に発生して、知ったかぶりな連中がドヤ顔で好き放題言ってくる。

意見は言うが問題の解決には全く役に立たない老人たちの「ありがたい指摘」をメンバー全員が「ははーっ」と聞いて、議事録に書き、「指摘にきちんと対応したこと」をあとで報告しなければならない。

私は長年SIerで働いてきたが、社内の偉い人のレビューや指摘がシステム開発に実際に役に立った記憶はない。

しかしながら、偉い人のご意見を聞くためのレビューに業務時間の多くを取られるのもSIerの仕事の現実だ。

だから私は何度でも言うよ。

ソフトウェア開発がやりたいなら、SIerで働くのはやめなさい。

政治がやりたいならSIerに行きなさい。

SIerの何がやばいの？中の人がリアルな事情を語ってみる