移行切り替えフェーズで考えること

主なタスク

• ①移行対象一覧（表）と②移行計画書（図）と③移行手順書（表）を作成する

  • 図と表をいったりきたりで、漏れをなくす
    • ←はじめから詳細に作り過ぎない（でも詳細に作ることで見える課題もある）

• ①移行対象一覧

  • まず、関係者ときっちり認識合わせをする
    • FIXさせる。合意を取る。

• ②移行計画書：関係する人への説明用（＝概要）

  • 結局、いつ使えないのか、どこを使えばいいのか

• ③移行手順書：作業者用（＝詳細）

  • 事前に移行リハで検証し、ログも残しておいて本番に備える
  • 検証内容
    • 技術的に可能か
    • どれくらい時間がかかるか

気を付けること

• メンバーの統率（巻き込み、教育）

  • -> チームを跨いだ総力戦になるので、早めに巻き込んでおく
  • 連絡先一覧
    • 日別、昼夜別に、誰に連絡すればよいか
  • 連絡フロー
    • エスカレーションフロー
  • 昼勤と夜勤の連携
  • 移行作業の事前トランスファー

• 移行手順書の作り込み

  • -> 何があっても、作業者に判断をさせない（機械的に実施できる）手順書を作る
  • 切り戻し基準、切り戻し手順、再実施のスケジュール
  • 各タスクの依存関係を明確に
  • どの手順とどの手順が対応しているのか（どこでLB止めて、どこで起動する？）
  • 開始時間と所要時間から、終了時間を関数で計算
  • 関係各社への連絡も手順の一つ
  • いろんな人がメンテするので、履歴管理（更新履歴シート？）
  • 早めのレビュー（特に関係各社）
  • 手順書の読み合わせは全員で集まって実施
  • 移行手順書から派生する各手順書も誰がレビューしたかをチェック
  • リハ手順書と本手順書が別れる場合、修正結果が反映できているかもチェック
  • 移行リハの課題を洗い出し切って、手順書に落とすorチェックリスト化

（追記）データ移行実施時の振り返り

• AWS CLIをdocker runで利用した
  • aliasの設定が必要
    • bashで実行する時にaliasのオプションが必要
  • dockerからマウントできる位置にファイルを移動
• ログが乱立しがち
  • 動作確認用の命名規則も含めて最初に計画する
  • やり直し用も
    • でかいデータだと、一発で成功しない。途中から実行する事になる。その時に、スクリプトをcpするか、ファイル名をどうするか
• 何時何分まで移行に使えるか確認
• 見積もり大事
  • 最初の見積もり
  • 移行し始めて見積もり
  • 見積もりのためのツール（excel）は組んでおく
    • だんだん正確に見積れるようになる。更新していく
• リハは大事
  • コマンドが動くか
    • コマンド動作確認
    • 権限
    • 実行ユーザも大事
  • サンプルで時間見積もり
• いざという時のために移行の優先度は細かく設定（合意）しておいた方が良い
  • ギリギリの戦いになった時に何を捨てるか
  • 最初から、ワーストケースを想定する
• SSDディスクの空きがなく、zip化できない
  • zip化してるのと、s3に送信しているのと、hddから送るの混ざってきたから、漏れないようにきっちり整理しつつスクリプト流し直す
• s3送信処理が一斉に謎の停止した（プロセスは残っていた）
• Glacier移行のライフサイクル設定を間違えて改廃してしまった
• mnt先、シンボリックリンク先もzip化してしまった
• シェルのプロセスだけでなく、子のプロセスも殺す
• シェルが動かなかった
  • シェルをcpして実行したら動いた
  • sudo su でrootになって実行したら動いた
    • リダイレクトするログの権限？
• zipが権限エラーでスカってないか確認
  • ファイルサイズチェック
• シェルがなぜか一瞬で終わった
  • AWSのクレデンシャルが読み込めない
    • 実行ユーザを変えたから、クレデンシャルファイルを読み込めなかった
  • ファイルパスの指定ミス
    • スクリプト修正する時は横展開
• 計画と違う作業をしたときは、とにかく記録しておく
  • 作業者の役割分担大事
• 帯域が思ったより出ない
  • 朝と昼間と夜で違う？