| « 2006年9月11日 | 2006年9月12日の投稿 |
2006年9月13日 » |
システム運用に携わって一番大変なことは何でしょうか？
日々の障害アラート、ユーザ部門からのクレーム、上からのコスト削減圧力・・・人によって様々だと思いますが、私が一番大変だと思うのは「サービスの追加リリース」です。
ただのサービスリリースではありません。運用中のシステムに対するサービスの追加リリースです。しかも、大規模なケース。
新しいサービスをリリースする場合、関連部署に調整を行い、業務スケジュールの合間を掻い潜って切替時間を確保し、綿密な切替計画を立案し、万全のシフトを組んで、ようやく新サービスをリリースできるのです。
大抵の場合、システム停止を伴いますから、どうしても週末や大型連休の間に行うことになりますから、切替に参加する人の負担は、肉体的にも精神的にも結構キツイです。サービスリリースが連続すると、家庭崩壊の憂き目を経験する人もいます。以前のプロジェクトでは、奥さんが包丁を振り回す事態に発展した人もいました。
でも、本当に大変なのはこの後なのです。
システムの切り替え中に障害が発生した場合、データの切り戻しが必要になります。当然、切替前にシステムのバックアップを取りますから、それからリストアすれば良いのですが、ごく稀にバックアップが失敗していることがあるのです。
見掛け上は正常にバックアップが完了しているのに、実はデータ破損が発生していたということが分かった時、どうなると思いますか？
時間が止まるんですよ。
皆、何も考えられなくなって、瞬間ですが頭が真っ白になります。まさに、今まで歩んできた道が全て崩れ去った感じです。
勿論、バックアップデータが破損していた場合の復旧シナリオというのは、事前に計画で考えておくのですが、仮に復旧させたとしても、そこから切替直前までデータを最新化するのはかなりの手間を要します。
何より、せっかくここまで進んできたのに今更引き返したくないという心理が多くの人に働きますから、後戻りすべきかどうかを逡巡してしまいます。先に進めず、かといって後にも引けない、まさにのっぴきならない事態です。
こんな事態、遭遇したくはないですけど、システム運用に携わる方なら、常に最悪の事態への対処方法を頭の片隅で考えておくと良いかと思います。
ちなみに、先ほどのケースですが、奇跡的に障害が復旧して無事に新サービスをリリースできました。
| « 2006年9月11日 | 2006年9月12日の投稿 |
2006年9月13日 » |
顧客に“ワォ！”という体験を提供――ザッポスに学ぶ企業文化の確立
ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
悩んだときの、自己啓発書の触れ方
考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
なんて素敵にフェイスブック
部下を叱る2つのポイント
第6回 幸せの創造こそ、ビジネスの使命