はじめに
タイトルの通りですが、運用って意外に難しいですよね。
仕事でも個人でもサービスを作りあげる事は何度もあるのに、
それでもこんな事ありませんか？
- 必死で没頭して熱中してローンチしたら、あれこれ運用するのどうするんだ...？
- ローンチしちゃったから走りながら設定変える辛い...いや無理かも..
- ローンチしたはいいけどデータの更新とか誰がどうやってやるんだ... サービスの開始的な言葉はローンチ/サービスイン/カットオーバーなど適宜置き換えてもらえれば
システムの運用を事前に設計するのって難しいなーと思っていたところで
この本を見かけて読んでみたので、自分用に整理したメモです。
読んだ本
もくじ
- 移行フェーズ
- 6.1.移行とは
「書籍のメモ」をつづっていきますが
「自分の感想」には「※ hogehoge」という形で記載しています。
読んだ感想
この章では運用設計の範疇ではないが、運用と関わりが深い移行について解説されています。
移行については、情報をあまり見た事がなかったのでこうして本にまとめられているのはありがたいです。
6.1.移行とは
移行について
- 移行とは
- 完成したシステムを、
利用者が利用できるように新システムに切り替えること- 運用設計の範疇ではなくプロジェクト全体の範疇
- ただし、移行後に運用開始のため運用設計が深く関わる
- 導入するシステムの種類
- 新システムの追加
- 新たな作業や業務が発生する
- 事前説明やユーザ教育が必要
- 既存システム更改の場合
- データを引き継ぐ場合、デグレや移行時間の確保が必要
- 平行運用期間を設ける場合、最新データの扱いの検討が必要
- 移行の方法
- 一括移行
- 全体のシステム停止が可能な場合や複雑で段階移行の影響が読めない場合に採用
- 移行コスト、手間、時間は最小
- コンティジェンシープランの考え方が簡単
- すべての利用者に影響があるためリスクは高い
- 段階移行
- 全体でシステム停止できな場合、データが多く一括移行できない場合に採用
- 移行中は新旧2つのシステム運用が発生する
- 移行コスト、手間、時間はやや高い
- コンティジェンシープランの考え方はやや複雑
- 移行した利用者へのみ影響があるためリスクはやや少ない
- 平行運用
- 現行システムと新システムの互換性が重要な場合に採用
- 移行コスト、手間、時間は高い
- コンティジェンシープランの考え方は複雑
- 新システムに問題があっても、旧システムが利用できるためリスクはほぼない
移行の実施
- 移行計画書
- 移行概要
- 移行期間
- 移行時の業務制限
- 他システムへの影響
- 新業務の開始時期
- 失敗時の影響
- 切り戻し方針
- 移行対象
- 対象データ
- 移行先
- ネットワークの切り替え有無
- 移行後の設備
- 移行ツール
- 移行中の影響
- 利用者への影響
- データへの影響
- 運用への影響
- 移行テスト
- リハーサル実施方針
- リハーサル時期
- リハーサル体制
- リハーサルスケジュール
- 移行スケジュール
- 移行スケジュール
- 15分〜30分単位で作成し、タスクの依存関係をはっきりさせる
- 問題がある場合のコンティジェンシープラン発動判断基準も決める
- ユーザの利用スケジュール
- ユーザの教育スケジュール
- 移行体制
- 当日の体制
- 移行継続判断を実施するリーダを決める事が重要
- 移行前後の運用体制
- ユーザ教育の体制
- リハーサルの体制
移行時の注意事項
移行に関するトラブルの影響判断を行うため、各チームのリーダクラスがアサインされている事が望ましい
- 移行全体の判断を行う
- 問題管理と進捗管理を行う
- トラブルの影響判断を行う
- 状況整理、関係者に定期的に周知を行う
移行がうまくいかないと、プロジェクト全体が失敗した雰囲気になる。 綺麗なドキュメント、しっかりしたテストがあっても、移行が失敗すると台無しになる場合も。
おわりに
移行計画や移行実施って意外にむずかしく、
どんなにテストをしていても移行を雑にやるとすぐ障害につながったりするので個人的には大事にしているフェーズです。
終わりよければすべて良しとはよく言った物で、
終わりがダメでダメな感じ...という事にならないように気をつけたいものです＼(＾o＾)／
紹介
