80年前の日本もそうだし、今の日本だって変わらん。
何が言いたいかって言うと、
「システム会社も、最新のマネージドサービス、プロダクトを投入することを目的としている」
保守、運用を全く考えていない。
その人員、費用を全く考えていない。
「Snowflakeが速いらしいから使いたい」
「マルチクラウドをやりたい」
「みんなk8s使ってるから使いたい」
それでメンテ対象の種類を増やして、補給(保守)部隊の運用どうすんねん？、と。
どこを押したら何が起こるか、一個一個はその場その場で説明できても、何百、何千とピタゴラスイッチした時何が起こるか？
事故は〜起きるもーのーさー w
何かあるたびに「気をつけてオペレーションする」「二人で実行する」
現場猫2人でやって、何になるんだ？
1 個障害が起きるたびに検知する仕組みを1 個追加する。
目の前の障害のこと(と報告書)しか視野に入ってないから、1ヶ月前に起こった障害の対策と、今日起こった障害の対策の間の整合性とか、全く考えられてない、考えられない。
遅延信管地雷がい〜っ個。
遅延信管地雷がに〜個。
遅延信管地雷がさ〜ん個。
引き継ぎしてから炸裂する。
根本的な対策を仕込む能力がないから、障害通知が増える一方。
真夜中に通知で叩き起こされ、
「データ確認しました。問題ありません」
それが続くと
「その障害通知は問題ない通知」
「その障害通知も問題ない通知」
意味もなく叩き起こされ、通知文面見て寝直すエンジニア。
何もしてないのに疲労が溜まる。
ストレスも溜まる。
そのうち、実は重大障害が発生しているのに、
「問題ありません」
で放置して、翌朝、地獄が広がる。
こんなもんでしょ？ 今時のWebサービスって。
んなわきゃぁない。
おいらの関わるプロダクトで、こんなこと起こったこと、一度もない。
現場に入る前にこうなってても、早期に改善する。
障害を発生させそうな時は早期にユーザーにエラー返すし、一回失敗してもリトライするし。
1処理1処理、そういう仕組みを仕込んでいくんじゃなく、フレームワーク的に展開する。
もちろん、この対策法だと、ちょっと余分に時間がかかる。
けど「こうかは ばつぐんだ！」。
兵站(運用)まで考えるのが、戦略(設計)。