「再起動したら直った」で終わらせない｜対処後に確認する手順
障害の連絡が来て、ログを見て、とりあえずサービスを再起動する。すると、症状がスッと消える——。 保守運用をしていると、この「再起動したら直った」に何度も助けられますよね。ひとまず止まっていたものが動き出して、ほっとする。でも同時に、心のどこかで「これ、本当に直ったのかな」「また再発しないかな」と落ち着かない。あの、片づいたようで片づいていない感じ。地味に消耗します。
その落ち着かなさは、あなたが慎重だからです。再起動は「状態をリセットする」対処であって、原因を消す対処とは限りません。だから「症状が消えた」と「原因が直った」は、分けて確かめる必要があります。
この記事では、再起動で症状が消えたあと、それが「本当に直った」のか「一時的に隠れただけ」なのかを確かめる順番を一緒に整理します。難しい追加ツールは要りません。元の再現手順・監視・ログを、落ち着いた順番で見ていくだけです。
結論：再起動で症状が消えても、次の3つだけは確認してから「対応済み」にします。①元の症状がもう出ないか（できれば報告時と同じ手順・条件で確かめる）②監視とログが平常値に戻り、エラーが止まったか③すぐ再発しないか（少し時間をおいてもう一度見る）。そのうえで、再起動で消えてしまう前に手がかり（プロセスの状態・メモリ・ログ）を取れたかを思い返し、原因が未特定なら「暫定対応」と記録して、再発監視と後日の調査をToDoに残します。
再起動の効き方は、原因（メモリリーク・コネクション枯渇・ディスク・一時的な高負荷など）で大きく変わります。順番と考え方を出発点に、自分の現場の症状に置き換えて使ってください。
何が起きているか：再起動は「時計を巻き戻す」対処
再起動がよく効くのは、多くの不調が「時間とともに何かが溜まって起きる」からです。メモリの使用量、開いたままの接続、たまったキャッシュやログ——こうしたものが、再起動でいったんゼロに戻ります。だから症状は消えます。でも、溜まる仕組みそのものが残っていれば、時間が経てばまた溜まります。
- 症状が消える＝原因が消える、ではない：再起動は「今たまっているもの」を流すだけで、「たまる原因」には触れていないことがあります。
- 「直った」の正体があいまいになりやすい：再起動と同時に、たまたまアクセスの山が過ぎた、バッチが終わった、ということもあります。再起動が効いたのか、時間が解決したのかを取り違えると、次に同じことが起きたとき打つ手を誤ります。
- 手がかりが一緒に消える：再起動すると、落ちる寸前のメモリ使用量や、詰まっていた接続の様子といった「原因の証拠」も消えます。急いで再起動したくなるときほど、あとで原因を追えなくなりがちです。
つまり必要なのは「再起動して終わり」ではなく、消えたのが症状だけなのか、原因までなのかを見分ける目です。次から、その確かめ方を順番に見ていきます。
再起動のあとに確かめる4つのステップ
大事なのは、「見た目が動いた」で止めず、一段ずつ確かめることです。全部そろえば「解決」、途中までなら「暫定対応」。その線引きがはっきりするだけで、報告も、その後の備えもぐっと楽になります。
① 元の症状が、もう出ないかを確かめる
まず確かめるのは、コードやログではなく、報告された症状そのものです。ここを飛ばして「プロセスが起動したからOK」にすると、ユーザー側ではまだ困っている、というすれ違いが起きます。
- 報告時と同じ手順でなぞる：「特定の画面が開けない」「この操作でエラー」など、報告された再現手順があるなら、その通りに操作して、もう起きないことを自分の目で確かめます。
- そもそも再現できていたかを思い出す：再起動の前に一度でも症状を再現できていたか。再現できていなかった場合、「再起動で直った」のか「たまたま今は出ないだけ」なのか、判断がつきません。
- 自分だけでなく、実際の経路でも見る：可能なら、報告してくれた人や実際の利用に近い条件でも確認します。
ここで症状がぶり返すなら、再起動では足りていません。原因はもっと奥にあります。症状が出ないなら、次の②で「数字とログ」でも裏を取ります。
ここで一呼吸。「再起動で消えた」だけで報告を閉じたくなる気持ちは自然です。でも、報告時の手順でもう一度確かめられたなら、それはもう十分ていねいな対応です。
② 監視とログが「平常」に戻ったかを見る
症状が見た目で消えても、内側がまだ苦しそうなことがあります。ここでは数字（監視）とログで裏を取ります。
- 主要な指標が平常値に戻ったか：CPU・メモリ・接続数・応答時間など、ふだんの平常値（ベースライン）と比べて、落ち着いた範囲に戻っているかを見ます。再起動直後だけ低くて、じわじわ上がり続けているなら要注意です。
- エラーログが止まったか：直前まで出ていたエラーが、再起動後に出なくなったかを直近のログで確認します。「起動はしたがエラーは出続けている」なら、まだ直っていません。
- 依存する先・後続の処理も見る：再起動したサービスにつながる周辺（バッチ、連携先、キュー処理など）が、詰まりを解消できているかも確認します。
見た目・症状（①）と、数字・ログ（②）の両方が落ち着いて、はじめて「今は正常」と言えます。片方だけだと、まだ判断は早いです。
③ すぐ再発しないかを、少し時間をおいて見る
再起動の効果が「時計を巻き戻しただけ」なら、時間が経つとまた同じところに戻っていきます。だから、その場だけでなく、少し時間をおいて再確認します。
- 上がり方の傾きを見る：メモリやディスク、接続数が、再起動後にまた同じペースで増えていないか。増え続けているなら、原因は残ったままです。
- 再発しやすいタイミングを意識する：夜間バッチのあと、アクセスが増える時間帯、月初など、前回症状が出た状況を思い出し、その前後を気にかけておきます。
- 「様子見」の期限を決める：いつまで見て問題なければ落ち着いたと見なすか、自分の中で目安を持っておくと、いつまでも不安を引きずらずに済みます。
ここまでで再発の気配がなければ、対応としてはかなり安定しています。もし増え続けるなら、それは④の「原因はまだ残っている」というサインです。
④ 原因は特定できたか、証拠は残せたかを振り返る
最後に、いちばん大事な問いです。「なぜ起きたか」が分かっているか。ここが未特定なら、その対応は「直した」ではなく「暫定でしのいだ」です。どちらも立派な仕事ですが、記録の仕方が変わります。
- 再起動前に手がかりを取れたか：メモリ使用量、プロセスの状態、詰まっていた接続、直前のログ——再起動で消える前に、少しでも記録やスクリーンショットを残せていたか。次に同じことが起きたとき、これが調査の出発点になります。
- 原因が分かっているか、仮説どまりか：「メモリリークっぽい」「特定処理で接続が返っていないかも」など、仮説があるだけでも次につながります。分からないなら「未特定」と正直に書きます。
- 暫定か恒久かを言葉にする：原因を直したなら恒久対応。再起動でしのいだだけなら暫定対応。この2つを分けて記録し、暫定なら「再発監視」と「後日の原因調査」をToDoに残します。
原因がすぐ分からなくても、責める必要はありません。急な障害で、まず止血（再起動）を選んだのは正しい判断です。大事なのは、「暫定でしのいだ」と分かる形で残しておくこと。それが、次に再発したときの自分や、引き継ぐ人を助けます。
具体例：「プロセスが落ちたので再起動したら直った」
よくある一件を、順番に確かめてみます。
- ①症状：「特定の処理が途中で止まる」という報告。再起動後に同じ操作をなぞると、今度は最後まで通った。症状は消えている。
- ②監視・ログ：エラーログは再起動後に止まった。ただしメモリ使用量を見ると、再起動直後は低いものの、じわじわ上がり続けている。
- ③再発：1時間ほど様子を見ると、メモリの傾きが前回落ちる前と同じペース。このままだと、また数日で同じ状態に戻りそうだと分かる。
- ④原因：再起動前に「落ちる寸前のメモリ使用量」をメモしておいたおかげで、特定の処理でメモリが解放されていない疑いに当たりをつけられた。原因の修正はこれから。
この時点での正しい報告は「再起動で復旧（暫定対応）。メモリリークの疑いがあり、恒久対応は別途調査」です。もし②③を飛ばして「再起動で直りました」で閉じていたら、数日後にまた同じ障害が起き、しかも今度は手がかりゼロから調べ直すことになっていました。「まだ上がり続けている」という一段の確認が、次の自分を救ったわけです。
影響：確かめる順番を持つと、何が変わるか
再起動後の確認手順を1枚持っておくと、対応そのものより先に、再発の不意打ちと、報告のあいまいさが減ります。
- 「直った」と思い込む前に、「症状が消えただけかも」と一度立ち止まれる。
- 監視の傾きを見る癖がつき、再発を「起きてから」ではなく「起きる前」に気づける。
- 「暫定」か「解決」かをはっきり書けるので、上司や引き継ぎ先に正しく伝わる。
- 再起動前に手がかりを残す習慣がつき、次に同じ障害が来ても調査の出発点がある。
逆に、毎回「再起動で直った」で閉じていると、同じ障害が忘れたころに再発し、そのたびにゼロから調べ直す消耗が続きます。順番は、未来の自分の時間を守る道具でもあります。
明日やること：再起動する前に「1行メモ」を残すと決める
立派な手順書は要りません。明日できる、いちばん小さな一歩はこれです。
- 次に障害で再起動するときは、押す前に「症状・時刻・そのときの数字（メモリや接続数など見えるもの）」を1行だけメモする。
- 再起動後、報告時と同じ手順で症状が消えたかを自分の目で確かめる。
- 監視で主要な指標が平常に戻ったかと、エラーログが止まったかを見る。
- 少し時間をおいて、数字がまた同じペースで増えていないかをもう一度見る。
- 原因が未特定なら、記録に「暫定対応」と書き、「再発監視」と「後日調査」をToDoに残す。
全部を完璧にやる必要はありません。まずは1の「再起動する前の1行メモ」だけでも、次に再発したときの調査が、まるで違う楽さになります。
再起動後の確認チェックリスト
対処のあと、「対応済み」にしてよいかを見る項目です。コピーして、自分のメモに当ててみてください。全部を毎回そろえる必要はありません。
まず外せない最低ラインはこの3つです。急いでいても、ここだけは押さえます。
- 【最低ライン】報告された症状が、同じ手順・条件でもう出ないことを確かめたか
- 【最低ライン】監視の主要指標が平常値に戻り、エラーログが止まったか
- 【最低ライン】少し時間をおいて、すぐ再発しないことを確かめたか
次の項目は、原因を残さず片づけたいとき・報告や引き継ぎに使うときに追加で確認します。当てはまらなければ飛ばして大丈夫です。
- 再起動する前に、症状・時刻・そのときの数字を1行でも記録できたか
- メモリ・接続数・ディスクなどが、また同じペースで増えていないか見たか
- 依存する周辺（バッチ・連携先・後続処理）も正常に戻ったか確認したか
- 原因を特定できたか、それとも仮説どまり・未特定かを正直に書いたか
- 「暫定対応」か「恒久対応」かを分けて記録したか
- 暫定なら、再発監視と後日の原因調査をToDoに残したか
全部に○が付かなくても大丈夫です。最低ラインの3つ、とくに「同じ手順で症状が消えたか」さえ押さえられれば、「直ったつもり」で報告を閉じて後から慌てるより、ずっと確かな一歩になります。
よければ、こちらも
再起動で止血したあとの確認は、落ち着いて動くための「順番」があるほど楽になります。溜まって起きる不調の見方と、対応を記録に残す型をセットにしておくと、次の「また落ちた」がだいぶ軽くなります。
- メモリ不足でプロセスが落ちる｜OOMの兆候と一次対処：再起動で消えがちな「メモリが溜まって落ちる」タイプの見つけ方と、慌てないための一次対処をまとめています。
- ポストモーテムの書き方｜障害を責めずに再発防止へつなげる：「暫定でしのいだ」障害を、次に活きる記録に変えるための振り返りの型です。
- 障害の第一報テンプレート｜何を・誰に・どの順で伝えるか：再起動で復旧したときの「暫定か解決か」を、相手に誤解なく伝えるための第一報の型です。
「再起動したら直った」が落ち着かないのは、症状が消えても原因が見えないからです。でも、症状・監視・再発・原因の順に一段ずつ確かめると決めるだけで、その霧はかなり晴れます。多くの場合、あなたの対応は正しくて、ただ「今は暫定かもしれない」と正直に残しておけばいいだけです。 今日は、次に再起動する前の「1行メモ」を決めるところからで十分です。その1行が、次の「また落ちた」を、不意打ちではなく想定内に変えてくれます。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。