2026年5月31日、午前9時8分。スマートフォンにGitHub Actionsからアラートが来た。「dxgame.jp — HTTP 200以外を検知」。その日、研修が予定されていた。
何が起きたか
サーバーにSSHで接続した。ログを確認する。エラーログに「SIGTERM」が繰り返し表示されていた。プロセスが強制終了されていた。SIGTERMは「終了してください」というシグナルだ。通常はsystemdがサービスを停止・再起動するときに送る。しかしサービスはrestart=alwaysで設定しているはずだ。なぜ自動で復旧していないのか。
根本原因の特定
AIにログを貼り付けて状況を説明した。AIが指摘したのは「RestartSec（再起動待機時間）の設定」だった。再起動試行が短時間に集中すると、systemdのStartLimitBurst（一定時間内の再起動上限回数）を超えて、自動再起動が停止する——これが原因だった。
対応と恒久対策
まず手動で4つのサービスを全て再起動した。午前12時42分、全サービスが正常復帰した。3時間34分の障害だった。恒久対策として、全4サービスのRestart=always設定を強化した。RestartSecとStartLimitBurstの設定を見直し、自動復旧の信頼性を上げた。
死活監視システムが機能した
このとき、5分ごとに動くGitHub Actions死活監視が役に立った。研修開始前にアラートが来たことで、参加者が繋がる前に対応できた。「研修中の本番障害＝仕事の失敗」——この絶対条件が、事前の監視システムへの投資を正当化する。死活監視の構築に1時間かけたコストは、この1回の対応で十分に回収できた。
障害対応の時系列と具体的な復旧手順
SIGTERM事件の対応を、時系列で記録しておく。この記録は次の障害対応の参考になる。
09:08 ― GitHub Actionsアラート受信。「dxgame.jp — HTTP 502」。スマートフォンへのメール通知で気づく。
09:11 ― SSHでEC2に接続。まず全4サービスの状態を確認。systemctl status dxgame dxgame-team dxgame-staging dxgame-staging-team。4サービス全てが「failed」状態。
09:14 ― ジャーナルログを確認。journalctl -u dxgame -n 100 --no-pager。SIGTERMで終了した記録、その後の再起動試行が6回、StartLimitBurstに達して自動再起動が停止している記録を確認。
09:22 ― AIにログを貼り付けて状況を説明。「SIGTERMが繰り返し発生しているが原因が不明。systemdの再起動が停止している」。AIの回答：「StartLimitBurstとStartLimitIntervalSecの設定を確認してください。再起動試行が短時間に集中するとsystemdがあきらめます。RestartSecを5秒以上に設定することで次回以降の問題を防げます」。
09:31 ― 4サービスを手動で順番に再起動。systemctl reset-failed dxgame && systemctl start dxgameを4サービス分実行。
09:45 ― 全4サービスが正常起動。dxgame.jp・team.dxgame.jpともに200レスポンスを確認。
12:42 ― 本番研修開始。参加者は一切の影響を受けなかった。
恒久対策の内容：全4サービスのsystemdユニットファイルを修正。RestartSec=10（再起動待機10秒）、StartLimitIntervalSec=120（2分間の監視窓）、StartLimitBurst=3（2分以内に3回まで再起動試行）を追加。
障害から学んだ最大の教訓は「死活監視があったから研修前に気づけた」ことだ。監視なしなら参加者が繋がろうとした時点で初めて発覚する。
*次回は「35項目全PASSの自動テストをAIと作った」*
障害が「人生の不成功」に直結するという緊張感
この障害対応を振り返るたびに思う。「研修の本番で本当に繋がらなかったら」という仮定だ。
12社が集まる研修で、システムが動かない。ファシリテーターが赤面する。参加者が「せっかく来たのに」という顔をする。主催者が謝罪する。このシナリオは「単なるトラブル」ではなく、信頼の喪失だ。仕事の失敗は、次の仕事の機会を減らす。
だから死活監視を作った。自動テストを作った。ステージング環境を作った。本番への直接編集を禁止した。これらは全て「本番で絶対に止まらないために」という一点に向けた投資だ。技術的な緊張感が、研修の品質を守っている。
*シンプルシステム株式会社 代表 伊藤勝彦*