島田則幸

Postmortem: 共有フォルダの書き込み遅延（架空事例）

このドキュメントは 公開ポートフォリオ用の架空事例 です。実在の障害ではありません。重大インシデント対応プレイブック（incident-response-playbook.md）と組み合わせて、「型 → 実例」が一通り読める形にしています。

メタ情報

項目	内容
インシデントID	INC-2026-0312
重大度	P2（業務影響あり / 全社停止には至らず）
検知日時	2026-03-12 09:14 JST
収束日時	2026-03-12 11:48 JST
報告者	ヘルプデスク一次受付
対応IC	インフラ運用担当 A
影響範囲	共有フォルダ `\\fs01\Dept-Sales` を利用する営業部 32 名
サービス	ファイルサーバー fs01 (Windows Server 2022)
業務影響	提案資料の保存に最大 90 秒の遅延。提出締切前の混雑時間帯と重なり、4 件で承認フロー遅延が発生

TL;DR

朝の業務開始直後から営業部の共有フォルダで「保存が遅い」という問い合わせが集中。原因は 同部署内ユーザーが Outlook PST ファイルを共有フォルダ直下に置き、同期型バックアップエージェントがそれを毎時フルスキャンしていた ことによる I/O キューの飽和。当日中に PST を個人OneDriveへ退避し、バックアップ対象から PST 拡張子を除外することで根治。再発防止として ポリシー禁止 + ファイル監査ルール + Prometheus による fs01 ディスクキュー監視追加 を実施。

タイムライン

時刻 (JST)	区分	出来事 / 確認内容
09:14	DETECT	ヘルプデスクへ「保存が遅い」の問い合わせ 3 件。一次受付が `Test-NetworkTriage.ps1` を実行、ネットワーク自体は正常と判定
09:18	TRIAGE	別の 2 名から同様問い合わせ。同部署 / 同フォルダに集中していることを確認 → IC を起動し P2 として宣言
09:24	INVESTIGATE	fs01 にリモート接続。`perfmon` で Disk Queue Length 平均 18.4 を確認。通常時の 50 倍
09:31	INVESTIGATE	`Resource Monitor` でディスク高使用プロセスを特定 → バックアップエージェントの I/O が継続
09:38	INVESTIGATE	バックアップエージェントの当日ログを確認 → `\\fs01\Dept-Sales\営業1課\old\backup.pst` (8.7GB) を含むスキャンが進行中
09:42	DECIDE	バックアップジョブを中断ではなく一時停止（中断するとリトライで同事象が再発する判断）。営業部 PM へ状況連絡
09:46	DECIDE	PST 4 ファイル（合計 22GB）を一時的に管理者領域へ退避することを決定。ファイル所有者に Teams で連絡
09:55	RECOVER	PST 退避完了。fs01 の Disk Queue Length は 0.6 まで低下。利用者数名に動作確認を依頼
10:02	RECOVER	営業部から「保存が瞬時に戻った」確認。問い合わせ受付窓口を継続監視へ
10:30	MITIGATE	バックアップエージェントの除外パターンに `.pst` `.ost` を追加し、設定を反映
11:30	MONITOR	1 時間追加の経過観察。Disk Queue Length が継続して 0.5 以下を維持していることを確認
11:48	CLOSE	インシデントクローズ。退避した PST は所有者の OneDrive へ移動し、共有フォルダ側を整理

影響（実数）

指標	値
MTTA (Mean Time To Acknowledge)	4 分（09:14 → 09:18 で IC 起動）
MTTR (Mean Time To Recover)	41 分（09:14 → 09:55 で正常動作確認）
MTTM (Mean Time To Mitigate, 恒久対処まで)	1 時間 16 分（09:14 → 10:30 で除外設定）
影響ユーザー数	32 名
業務遅延が発生した承認フロー件数	4 件
データ損失	なし

5 Whys（根本原因分析）

なぜ共有フォルダの書き込みが遅延したのか？ → fs01 の Disk Queue Length が 18 を超えた ため。
なぜ Disk Queue Length が突発的に上がったのか？ → バックアップエージェントが 22GB の PST ファイル群を含む同期スキャン を実行していたため。
なぜ PST が共有フォルダ直下に置かれていたのか？ → 部門の慣習で「個人 PC が壊れても消えないから」と PST を保存していた。PST を共有領域へ置かない方針が周知されていなかった。
なぜ PST 拡張子が バックアップ対象から除外されていなかった のか？ → 初期構築時の除外パターンが 2023 年から見直されておらず、想定外のファイル種別が累積していた。
なぜこの負荷が事前に検知されなかったのか？ → fs01 の Disk Queue Length / I/O 飽和の継続監視が無く、エンドユーザー問い合わせが事実上の検知トリガーになっていた。

根本原因

直接原因: バックアップエージェントが PST 大容量ファイルをフルスキャンし I/O を飽和させた
構造的原因:
1. 共有領域に置くべきでないファイル種別の ポリシーが明文化されていなかった
2. バックアップ除外パターンの 定期見直しプロセスが無かった
3. ファイルサーバーの I/O 系メトリクスが監視に乗っていなかった

対応（応急 / 恒久）

応急（当日）

PST ファイル 4 本を管理者領域へ退避（→ 利用者の OneDrive へ移動）
バックアップエージェントの除外パターンに *.pst *.ost を追加
営業部に状況と再発防止策の概要を Teams で連絡

恒久（1 週間以内）

ファイル運用ポリシー に「PST / OST を共有領域へ置かない」を明記し、全社ポータルへ掲示
ファイル監査ルール を fs01 に追加：*.pst *.ost の新規作成を週次レポート化
Prometheus / node_exporter に Windows 用エクスポーターを追加し、Disk Queue Length / 平均 I/O 待ちを継続収集
上記メトリクスにアラート（Disk Queue Length > 5 が 10 分継続 = warning, > 15 が 5 分継続 = critical）を設定

中期（1 ヶ月以内）

バックアップ除外パターンの 四半期棚卸し をオフボーディング手順書と同列にカレンダー化
ユーザー教育: PST の代替（Outlook オンライン保存 / OneDrive アーカイブ）を 1 ページの手順書として配布
サーバーごとの I/O ベースライン を 30 日収集し、アラートのしきい値を調整

やってよかったこと（Went Well）

バックアップを中断ではなく一時停止にした判断: 中断していたら同じ事象が次回ジョブで再発していた可能性が高い
利用者の PM へ早期に状況連絡: 「気付いたら直っていた」を避け、PM 側で締切調整が間に合った
問い合わせ初動で Test-NetworkTriage.ps1 を流していたこと: ネットワーク要因を 4 分で除外でき、ファイルサーバー側の調査に集中できた

やるべきだったこと（Want to Improve）

検知がエンドユーザー依存だった: 監視で先に拾うべきだった
問い合わせ受付段階で「同部署集中」をもっと早く可視化したい: 5 分以内に部門別の問い合わせ件数を可視化できる仕組みが欲しい
PST 規約が明文化されていなかった: 「やってはいけないこと」を性善説に依存していた