サービス規模が大きくなると色々大変そうだ、、、と思いながら読んだ。

みずほ銀行システム障害に学ぶ | 川口耕介のブログ
https://ja.kohsuke.org/softwar...

この件とは別に、そのようなときにどういう対応をしたかという例が参考になった。

Google Docs / wiki の話が出てるが、顔を合わせて対応していても情報を持っているところが限られていることもあり、そこに方々から問い合わせが来ると対応は進まなくなるし。

最近はリモートで諸々対応することが多いので、状況がよく見えていない側というのはあるわけなので、そこをフォローする意味でも Google Docs 的な対応は良さそうなのかもなぁとおもった。

障害対応に限らず、リリース作業も近しいことはできそうな気がする。
テキストチャットだけに頼らず、ビデオ・音声をつないで対応するということも1つなのかもしれないが、、、、
同時に話し始めるとキリなさそうだし。

先日の Fastly の障害の時なども障害が確認できて共有報告は Slack などでしたとして。
そこからどういう風に対応していくかは各社それぞれの判断になるし、そのときに判断できる・対応できる準備があるか、というとまちまち。
外部要因なので見えづらいところはあるにせよ。

1サービスだけの対応であればいいかもしれないが、複数同時に起こった時はどこから対応すべきかという別の問題も発生してくる。

Fastly の件は1時間程度で済んだからいいものの、その1時間の間を待つという選択をした結果の結果オーライなのか、何もできずに結果的に解消したのか、とか。

サービス運営側の意識としてそういうことを考えて備えているか、考えていない、もしくは備えていないの差なんだろうし。
運営をサポートする側も準備するだけの各種リソースがあったかどうか、などなど考えることは多い。
が、喉元過ぎればなんとやら、という気もする。