はじめに

こんにちは。ソホビービー株式会社の新人エンジニアのU.N.です。
今回は、私が経験した「個人システムにおける長期ダウンタイム」の事後検証（ポストモーテム）レポートを共有します。

本題に入る前に、そもそも「ポストモーテム（Post-mortem）」とは何か、なぜエンジニアは障害のたびにわざわざ記録を残すのか、について少し触れておきます。

ポストモーテムとは？

ポストモーテムは、直訳すると「死後」を意味するラテン語ですが、IT業界（特にSREの文脈）においては「障害事後検証」を指します。システム障害やインシデントが収束した後に、その経緯や原因を振り返り、ドキュメントとしてまとめるプロセスのことです。

なぜポストモーテムを書くのか？

私たちがインシデントの記録を残す目的は、主に以下の3点です。

• ・根本原因（Root Cause）の特定： 表面的な症状ではなく、「なぜシステムが停止したのか」という真の原因を深掘りするため。
• ・再発防止とシステムの堅牢化： 同じ障害を繰り返さないよう、具体的なアクションアイテム（次なる打ち手）を策定するため。
• ・チームへの知見の共有： 個人の経験や失敗をドキュメント化し、組織全体の「学び」へと昇華させるため。

そして、ポストモーテムにおいて最も重要な大原則が「ブレームレス（非難しない）」であることです。障害を起こした「人」を責めるのではなく、障害を防げなかった「システムやプロセス」の欠陥に目を向けることで、初めて建設的な改善が可能になります。

……さて、前置きが長くなりました。
今回のレポートにおけるターゲットシステムは、他でもない「私自身の身体」です。

ポストモーテム・レポート本編

2025年11月、インフルエンザとウイルス性胃腸炎により、私は有給休暇を使い果たすという深刻なリソース枯渇状態に陥りました。この経験から得た教訓を、自己システム安定稼働のためのプレイブックV2.0として公開します。

1. インシデント詳細とインパクト（Impact Analysis）

■ インシデント概要

• 発生事象: インフルエンザA型（39.9℃の高熱）およびウイルス性胃腸炎の連続罹患。
• ダウンタイム期間: 2025年11月14日(金) 午後 ～ 11月22日(土)
• 実質停止日数: 8.5日間。仕事復帰は11月25日(火)から。

■ クリティカルな二次被害（リソース枯渇）

• リソース枯渇: 11月13日時点の有給残6.0日から、5.5日を消費し、現在の残高は0.5日。予備リソースがほぼ消失し、次回インシデントに対する脆弱性が極大化。
• システム連携失敗: 2泊3日の沖縄社員旅行（重要イベント）に不参加。外部システム（チームビルディング）との重要なデータ同期（楽しい旅の思い出共有）に失敗。

2. ダウンタイム長期化の原因分析（Root Cause Analysis: RCA）

ダウンタイムの長期化とリソース枯渇を引き起こした根本原因は、以下の3点に集約されます。

RCA 1：初期アラート（倦怠感）の無視

11月14日朝の初期症状を無視し出社を継続した結果、異常検出からアクションまでの MTTD (Mean Time To Detect) が長期化。これが重症化を招き、システムの緊急シャットダウンに至りました。

RCA 2：リソース計画の不備（キャパシティプランニングの失敗）

有給休暇を「緊急時バッファ」として確保するという意識が希薄でした。予期せぬ障害に耐えうるリソースの予約（キャパシティプランニング）が不足していたため、長期ダウンタイムによりリソースが完全に枯渇しました。

RCA 3：不適切なリカバリー戦略

復帰への焦りから、完治前に無理な行動を取り、回復を遅延させた可能性があります。システム復旧には、医師の診断による 「サービス再開許可」 を待つというフェイルセーフな戦略が不可欠です。

3. 次回インシデント対応 プレイブック V2.0 への改訂

長期化を防ぎ、リソース枯渇を避けるための具体的な行動指針を策定します。

4. 恒久対策と結論

この経験から得た最大の教訓は、技術的なスキルアップ以前に「自己システム（健康）」の安定稼働が、チームへの最大の貢献であるということです。

今後は、シーズン前のワクチン接種や日常的な手洗い・うがいといった「プロアクティブなシステムメンテナンス」を徹底し、このプレイブック V2.0に基づき、個人システムのメンテナンスとリソース管理を遂行します。

業務をサポートいただいたチームの皆様に深く感謝申し上げます。