# 12-02 異常時の初動 演習 実行記録（Phase 5B-2C1） - 実行日時: 2026-09-21 00:20 JST - 実行環境（実測）: macOS 26.6.2 / Node.js v24.18.0（標準機能のみ、追加パッケージなし） - 実行場所: /examples/12-02-incident-response（再現には ../08-04-error-handling/storage_v2.js を使用） - 記録方法: 各コマンドを順に実行し、stdout・stderr・終了コードを整形・省略せずにそのまま記録した。stderr が空の場合は「stderr: （出力なし）」と記す。 - 対象: investigate.js（新規）。障害は 08-04 の説明用の失敗例を再現したもので、実際に発生した障害ではない。失敗ログの at は実行のたびに変わる。 ### 1. `node investigate.js` ```text $ node investigate.js 手順0：08-04 の部分失敗を再現した（説明用）。処理の戻り値: {"success":false,"state":"提出済み","partial":true,"error":"履歴の記録に失敗しました。状態は変更されていますが履歴が残っていません。運用担当者へ連絡してください。"} 手順1：申告（想定例） 依頼者役（佐藤）：「REQ-0003 を提出したら『履歴の記録に失敗しました…運用担当者へ連絡してください』と表示された。一覧では提出済みになっている」 手順2：事実確認（記録を読む） 状態ファイル: REQ-0003 の状態 = 提出済み 履歴ファイル: REQ-0003 の履歴 = 0 件 失敗ログ: 1 件（requestId=REQ-0003, errorType=TypeError, at=2026-09-20T15:20:31.775Z） 手順3：影響範囲 状態が「提出済み」なのに「提出」の履歴が無い依頼: 1 件（REQ-0003） 失敗ログの件数: 1 件 手順4：仮説と切り分け A. 通信が失敗して処理側に届かなかった（08-03 の ECONNREFUSED 型） この仮説なら: 状態は変わらない → 事実: 状態は変わっている → 消える B. 権限や状態の確認で拒否された（08-03 の 403/409 型） この仮説なら: 状態は変わらず、失敗ログも無い → 事実: 状態は変わっている、失敗ログ 1 件 → 消える C. 状態は保存されたが、履歴の書き込みだけ失敗した（08-04 の部分失敗型） この仮説なら: 状態は変わり、履歴は無く、失敗ログがある → 事実: 状態=提出済み、履歴 0 件、失敗ログ 1 件 → 残る 手順5：原因 残った仮説: C。失敗ログの errorType=TypeError、note=「状態は提出済みに変更されたが、履歴の記録に失敗した」と一致 → 履歴の書き込み失敗（08-04 の部分失敗）。状態と履歴が別々に書かれる作り（08-02・08-04）に起因する 手順6：暫定対応（初動） 拡大防止: 同じ症状の依頼が他に 0 件。0 件なら影響は REQ-0003 に限られる。運用担当は失敗ログの増加を監視する 対象依頼: REQ-0003 は「提出済み」だが「提出」の履歴が無い。履歴を補うか、状態を戻すかは運用管理者が決める（このスクリプトは書き換えない） 関係者連絡: 依頼者（佐藤）へ「提出は記録されているが履歴が欠けており確認中」と伝える。総務課長（架空）へ報告 切戻し（11-04）の要否: 配置の版は v0.1.0-sandbox のまま変わっておらず、新版の配置に起因する障害ではない → コードの切戻しは行わない 手順7：恒久対応と残課題 恒久対応の候補: 状態変更と履歴追加を「全部成功か全部取り消し」にする（記事B のトランザクション）。この題材アプリ（JSON ファイル保存）への適用は未決 この記事で回収する範囲: 初動（事実確認・影響範囲・切り分け・暫定対応）まで 残課題: 状態を戻すか履歴を補うかの設計判断（09-04 の残課題2、10-04 の未解決問題）は、この記事でも決めていない ``` stderr: （出力なし） 終了コード: 0