2025/12/11,2026/01/12 A55_migration_checklist.zip ------ ポイント ・問い合わせ窓口の一本化、横断体制 ・当日チェックリスト＋簡易FAQ ・ダッシュボードによる監視 AWS 特にデータベース(RDS) ・業務部門に一次切り分け体制をお願いする ・負荷・接続・FW・DNSの原因切り分け。ネットワークの熟練者のアサイン ・アプリベンダー、インフラベンダーとの連絡系統の整備 ・専用チャットの準備。専用電話番号は重大なものだけ。担当者に分散しないこと ・問い合わせフォーム（チケット）　無くても運用できるが、時系列と分析が残るため翌日の原因分析に効く ・当日朝のチェックリストを事前準備 Webサーバ稼働、各アプリケーションのホームが表示されること、DB接続の正常、認証の正常、 ファイルアップロード⇒保存処理の正常、外部I/F メール送信等の正常、バッチ処理の正常 ・インシデント分類ルールを決めておく 最高：全ユーザー影響、高：業務単位での重大影響、中：一部ユーザーへの業務支障、低：問合せ、使い方の問題 ・当日のログを取れる体制の事前準備 各サーバのCPU,mem,connection,アプリケーションログ、エラーログ、DB負荷、net遅延、ログイン/認証系監査ログ ・起きた障害のユーザー向け説明資料のテンプレートを用意しておけ ・旧環境での動作も多くの利用者に事前に確認頂く。サーバ移行のお知らせを見たから久々使ってみようかみたいな人を事前にできる限り減らせ （サーバ移行を機会に使い始めた方のトラブル報告⇒旧環境でも発生していたかどうか区別できない） ・多い問合せ…ログイン関連、画面真っ白、権限がない、ファイル操作、印刷の問題など ・移行当日は利用を避けてもらうのがいいのか・逆にできる限り多くの操作を早めに一通り確認してもらうのがいいのか ------ ・体制は一次窓口、二次対応者、指揮統制の階層型 ・司令部 ・想定FAQ ⇒認証方法は以前と同じですか？＋お気に入りのリンクが開きません！が問合せの二大巨頭。しつこく事前に案内しろ ⇒旧システムは使えますか？データは全て移行済ですか？以前見れていたはずのデータが見れません！ 　移行漏れではないですか？も多い質問。確認するために聞き返すテンプレを用意しておけ ⇒画面が遅いです。今後もずっとこの状態でしょうか？も多い質問。分析して適切に処置する等、想定回答を事前に統一しておけ ⇒久しぶりに使う人にも注意。以前○○ができたはずですが？も多い質問。対応時間をひきずられずに詳しい人に振れ ・システムの重要度や依存関係によって初動オープンする時間帯を変える⇒問題発生時の影響範囲を限定 ・ユーザー向け説明動画も効果的 ・移行1週間前から毎日リマインド　しつこく　事前のユーザー教育が重要 ・物理的司令部として会議室を設ける場合 複数の大型ディスプレイにシステム監視画面(AWS)、課題管理、タイムラインなどを表示 共同作業端末も ホワイトボードや模造紙 ・IT部門の職場が隔離されていれば、通常の職場が司令部でもいい。 ただし大型ディスプレイやホワイトボードが置けて全員が同じ状況を見れること ・担当者個人への電話やチャットでのユーザー問合せは拒否すると事前に通知すべき。文面案 ------ 「システム移行当日(○月○日)は、お問い合わせ窓口を一本化します。 個人への直接の電話・メール・チャットはご遠慮ください。必ず以下の窓口にご連絡をお願いします。 【当日専用窓口】 電話: 内線XXXX(ヘルプデスク) メール: migration-support@xxx.co.jp 社内チャット: #system-migration-support 窓口での受付により、迅速かつ確実な対応を行います。ご理解とご協力をお願いいたします。」 ------- ・聞きやすい人にユーザー問合せが集中するのを避ける ・チャットのステータスを対応不可にしたり、「専用窓口にお願いします」などのメッセージを貼ってもいい ・電話は不在転送にしてもいい。とにかく個人宛のユーザー問合せを封鎖しろ ------ 監視内容 ・AWSクラウドサービス全体の安定状況 ・プロセス監視…Apache,Tomcat,AUTO,WebとRDSとの通信 ・リソース監視…Webサーバ/バッチサーバのCPU/メモリ/ディスク ・Web…TomcatのWebapp起動、セッション数、JVM空きメモリ ・メインメニューURL監視 ・TomcatログのOOME監視 ★ELBの監視 - HTTPCode_ELB_504_Count - fields elb_status_code, target_processing_time | filter elb_status_code = 504 and target_processing_time >= 120 | stats count() by bin(5m) ★メインメニューログインログ、利用ログ（人数）監視 ・DB…CPU負荷、接続数/プロセス数、SQL負荷/待機/ロック ・OSのsyslog(messages) ・ログ監視…Oracleアラート、Apacheエラーログ、Tomcat/Apache起動停止ログ、AUTOD1/D2実行ログ ・パフォーマンス…画面応答は目視、＋AUTO実行ログ(log0) ・帳票稼働状況…RS,SVF ・AUTO稼働状況…inque,abend 監視しない ・Tomcatのログ詳細は各アプリケーションで見てくれ（アップロード、ダウンロード系統など） ・メール送信ログ⇒常時監視はしない。必要時調査はできます ・ファイアウォール拒否ログ(VPCフローログ)⇒常時監視はしない。AWSが履歴を取っている ・ネットワーク帯域負荷系統、DNS系統 ・FTPサーバ(送信、受信とも) ・EFSアクセス/マウント状況⇒lsで見れれば正常と判断して ・バックアップ監視⇒常時監視はしない。AWSが履歴を取っている ------ （以上）