営業時間中の許可された生産メンテナンス
私は最近、小さなスタートアップを経営するようになりました。ほとんどの小さなスタートアップとして、私たちはそれが大丈夫だと思ったとき、私たちは実質的に本番環境でやりたいことをやってきたと思います。人々は注意深く、物事は非常にうまく機能しています。また、クライアントの皆様に大変感謝しておりますので、迅速に解決することができました。
しかし、昨日、管理者が自分でサーバー名を変更し、ソフトウェアを更新して、状況に合わせて変更することにしたという問題が発生しました。開発者に通知されましたが、名前の変更によりメッセージキューシステムが強制終了され、基本的に何時間もシャットダウンされました。これにより、一連のカスケード障害が発生し、メッセージキューをホストしているVMを実際に強制終了し、新しいVMを作成する必要がありました。誰も満足していませんでした。
これは、最初に非実稼働環境で検証する必要があります。
ビジネスの危機的な時期に、本番環境でどのようなメンテナンスが許可されるのか疑問に思いました。しかし、いくら想像するでしょうか？
メンテナンスは、ビジネスシステムに影響を与えない限り、いつでも実行できます。
重大な障害の原因となった問題の場合、問題はそれが実行できなかったということではなく、変更プロセスの通知がないか、管理者がそれに従わなかったということです。名前の変更があったという事実は、サービスの稼働時間の責任者に伝えられませんでした。管理者がサービスの所有者である場合（およびその可能性が非常に高い中小企業の場合）、サービスに影響を与える変更の影響を判断するのが彼の仕事であるため、その役割に対する彼の適合性を調べる必要があります。
テスト環境は問題ありませんが、厳密に維持されない限り、すべての問題を証明することはできません。確かにテストの変更をテストすることはベストプラクティスですが、バックアウト計画に代わるものではありません（これもテストする必要があります）。
最後に、ここで学ぶべきもう1つの教訓は、開発者は管理者ではないということです。あなたが言ったように「開発者は通知された」と私は思う。 「マシン名が変わったらどうなるの？」と聞かれなかったニッケルに賭けます。少なくとも、開発者から、マシン名の変更はアプリに関係がないことを示すメールが届いていました。
間違いから学び、環境の変化を起こす前に、環境の変化の影響を分析するための措置を講じます。
ドキュメントはここで大いに役立ちますが、このタイプの変更がなぜこれほど広範囲に影響を与えるのかを評価しようとします。アプリケーションにハードコーディングされたものはありましたか？システムの機能に改善の余地はありますか？
ホスト名の変更は小さなことではありませんが、完全に壊れるようなことでもありません。