先日、あるサービスから「メンテナンス作業をするので数時間(ブログなどに)アクセスできなくなる」という旨の連絡がありました。
で、そのメンテナンスの日になりました。
が、再開予定時間になっても使用できないままで、提供側の経過報告もほとんどなく…結局、想定の時間を大幅に過ぎてから復旧しました。
1ユーザとしては無料利用とは言え、「残念やなぁ」と気持ちがあったのですが、それ以上に、SEとして…日常業務の「サーバ運用」やサーバ移行作業などの経験から…その経過に興味を持ちました。
今回のメンテナンスがどのような内容か…サーバ移行なのかネットワークの増強なのかなど…は分かりません。
が、この手の作業にはほぼ必ずと言って良いほど「移行手順書(計画書)」の類が作られるはずです。
そこには…
・どのような手順をどのような順番で行うのか？
・それぞれ確認すべき項目は何か？
・タイムスケジュール
…などが記述されているものです。
特にタイムスケジュールは不特定多数向けのインターネットサービスなので、割と厳しめに設定されているはずです。
また、切り戻しポイント…ある時間までにある条件が満たされていなければ、移行を中止する…が設定されていると思います。
＃メンテナンスの作業によっては設定できないこともありますが。
そして、「移行手順書(計画書)」に基づいてのリハーサルも行っていると思います。
で、これらの準備をした上で、本番のメンテナンス作業のプロセスでどこでどんなことがあって、そこでどんな判断の結果、想定外の長いサービス中断となってしまったのか？というのにとても興味があります。
こういう失敗事例は、(社内でも)なかなか分析されず、結果として次に活かされないことが多いように思います。
「やっちゃったわぁ」的な現場SEの経験をもっと共有でき、活かすことができれば、顧客に対して良いサービスを提供できるのにと思いました。
＃「やっちゃったわぁ」の当事者の方々は大変だったとは思いますが。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
コメント