システムのアップグレードイベントには、ある一つの共通点がある。 それは、どのシステムも「重要」で、「たくさんのユーザに利用されて」おり、たとえリプレースという大イベントであっても、「ほとんど止められない」ことである。そもそも利用者の多い重要なシステムだからこそ、高額な更改費用を掛けてより早く安定した基盤にアップグレードしようとしているのであるから、考えてみればこれは当然の要件である。 とは言え、やってはいけないのがダウンタイムの極小化を求めた挙句の短時間一発勝負である。移行の確実性を求めるのであれば、業務の稼働要件には相反する要素となる確認や検証の作業は十分に盛り込む必要がある。移行時の不確定要素は絶対に排除できないという前提に立ち、各ステップで十分な確認とテストの時間を確保したい。さらに、問題があった場合は先行のステップまで戻ってやり直せる余裕もほしい。できればしかるべき長さのパイロット
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く