サービス概要

Linux システムの不定期ハング・クラッシュ診断は、本番環境で最も原因を特定しにくい障害を対象とします。サーバーがときどき突然フリーズして到達不能になる、再起動コマンドが何も反応しない、業務が数分間だけ極端に遅くなって自然に回復する——しかもログに空白があり、再起動後は正常で、数日〜数週間後にまた起きる、といった類です。当社は「とりあえず再起動」ではなく、「現場の保護 → 証跡の保全 → タイムライン復元 → カーネルレベル解析 → 再現検証 → 根本原因の是正」という手順で、偶発事象を説明可能・検証可能・予防可能な結論に変えます。RHEL / CentOS / Rocky / AlmaLinux、Ubuntu / Debian、Fedora、openSUSE / SLES などの主要ディストリビューションに加え、銀河麒麟 V10・中标麒麟、統信 UOS、openEuler などの信創 OS、および鯤鵬・飛騰・海光・兆芯・龍芯などの国産 CPU に対応し、物理サーバー・仮想マシン・プライベートクラウド・コンテナホストを対象とします。

典型的な症状の分類

これらは互いに偽装し合います。「自動再起動」の正体がカーネル panic であったり、「完全フリーズ」の正体が NFS マウントのハングだけであったりします。まずタイムラインで現象を位置づけ、その後に取得すべき証跡を決定します。

なぜ「不定期」は難しいのか

• 再現しない：数日〜数週間に 1 回しか起きず、人がログインした頃には障害は終わっているため、張り付き監視のコストに見合いません。
• 現場が破壊される：最初の反応が再起動になりがちですが、再起動はカーネルリングバッファ、メモリ上のプロセススタック、未書き込みログを消し、唯一の証跡を失わせます。
• ログの空白：クラッシュ瞬間はディスクへ書き込む余裕がなく、journalctl には起動と前回起動終了の間の空白だけが残ります。
• 取得機能が既定で無効：本番機の多くで kdump、pstore、シリアルログ、NMI watchdog が無効で、まれなクラッシュ時には何も残りません。
• メトリクスが粗い：5 分平均の CPU は 10 秒の飽和を均し、障害ウィンドウで実際に起きたことを見失わせます。
• 信創環境の適応レイヤー：国産 CPU のマイクロコード、専用ドライバ、ベンダーカスタムカーネル、グラフィックス／デスクトップサービスが重なり、一般的な切り分け結論をそのまま適用できません。

したがって当社の第一原則は「システムに触れる前に現場を保全する」です。証跡が固まるまで、再起動もアップグレードもパラメータ変更もログ削除も行いません。

診断アプローチ：保全・取得・検証

結論は必ず閉じます。疑わしい根本原因を見つけたら、テスト環境で同じ負荷または SysRq トリガーで再現し、「一度に 1 変数だけ」を変更して修正効果を検証し、本番で十分な期間観察して再発しないことを確認します。

根本原因の分類

対応ディストリビューションと信創プラットフォーム

方法論は同じでも、ツールのパス、シンボル包の入手先、ベンダーサポート窓口はディストリビューションごとに異なります。当社は汎用チュートリアルではなく、実環境でそのまま実行できる証跡取得コマンドリストを提出します。

サービス内容と実施フロー

• Step 1 · 現場保護と情報収集：障害タイムライン、症状分類、構成トポロジー、変更履歴を確認。証跡完了まで再起動・設定変更を禁止し、カーネル・ドライバ・ファームウェア・ハードウェア情報を記録。
• Step 2 · 証跡取得機能の整備：kdump と crashkernel の設定・検証、pstore / ramoops と永続 journal の有効化、NMI watchdog と hung task / soft lockup panic の設定、シリアルまたは IPMI SOL / netconsole の疎通、秒単位メトリクスとカーネルサンプリングの導入。
• Step 3 · 証跡の固定とタイムライン復元：前回起動ログ、カーネルリングバッファ、BMC / SEL イベント、監視曲線、リリース記録をエクスポートし、分〜秒単位の障害タイムラインを作成。
• Step 4 · カーネルレベル解析と原因特定：crash で vmcore を解析（log、bt、ps、CPU 別スタック、ロック、モジュール）、perf と eBPF サンプリング、指標と変更の相関から仮説を逐次除外して根本原因を確定。
• Step 5 · 再現検証と是正：テスト環境で同一負荷または SysRq トリガーにより再現し、「一度に 1 変数だけ」で修正（カーネル、ドライバ、パラメータ、ハードウェア、設定、クォータ、マウント方針）を検証してから段階適用。
• Step 6 · 納品と再発防止：根本原因報告・証跡パッケージ・是正方案を提出し、監視アラート・ウォッチドッグ・ダンプ機能を補完。変更回帰チェックと定期訓練を提案し、知識移管を実施。

代表的な診断シナリオ

以下は実際の故障形態ごとに整理した代表的な適用例で、証跡の取り方と是正の考え方を示すものです。特定の顧客事例を示すものではありません。

シナリオ 1 · 金融系ホストが数週間ごとにランダムフリーズ

• 現象：基幹ホストが不定期に到達不能になり、遠隔の強制リセットでしか復旧しない。再起動後は正常で、ログには障害時刻の空白だけが残る。
• 証跡：コールドブートを禁止し、crashkernel メモリを予約して kdump を有効化、NMI watchdog と panic 時ダンプを設定。次回発生時に vmcore を取得し crash の log / bt を確認、シリアル / IPMI SOL の画面記録と突き合わせ。
• 根本原因：バックトレースから、サードパーティ製 NIC ドライバが割り込み処理中に soft lockup を起こしていると判明。当該カーネルにおけるそのドライバ版本の既知回帰だった。
• 結果：ドライバを更新しベンダー検証済みカーネルに固定、ウォッチドッグとアラートを追加。2 業務サイクル連続で再発なし。

シナリオ 2 · reboot がハングし電源断しか手段がない

• 現象：再起動コマンド後に「サービス停止中」で長時間停止し、SSH も切れて強制電源断が必要。オフピークのバッチ処理の後に起きやすい。
• 証跡：ハング中に Magic SysRq でタスクスタックを出力し、D 状態プロセス、マウントポイント、systemd stop job のタイムアウトを確認。共有ストレージ側とマルチパスのログを遡及。
• 根本原因：NFS のハードマウントがサーバー異常時に到達不能となり、プロセスが割り込み不可のスリープに入って kill -9 でも終了できず、シャットダウンが収束しなかった。
• 結果：評価の上でマウントタイムアウトとソフトマウント方針を適用し、重要な依存を分離。適切な TimeoutStopSec とハードウェアウォッチドッグを設定し、再起動は正常に完了。

シナリオ 3 · 信創プラットフォームの断続的な停止

• 現象：銀河麒麟 V10、統信 UOS、openEuler が混在するクラスタで、毎日数回数百ミリ秒の停顿が発生。汎用 x86 環境では再現しない。
• 証跡：プラットフォーム別にカーネルと専用ドライバの版本、UEFI ファームウェア、表示サービスログを照合。PSI、cgroup cpu.stat のスロットリングカウンタ、off-CPU サンプリングを取得し、ベンダー適合リストと比較。
• 根本原因：コンテナの CPU クォータが平均負荷基準で設定されており周期的なスロットリング停顿を起こしていたことに加え、当該国産 CPU 上である専用ドライバの適応不具合が重なっていた。
• 結果：クォータ再設定とスレッドプール最適化、ベンダーのドライバパッチと OS アップグレードを適用して停顿は解消。ディストリビューション横断の統一メトリクスベースラインも整備。

シナリオ 4 · ログ空白を伴う理由不明の自動再起動

• 現象：クラウドホストが予告なく再起動することがあり、journalctl では 2 つの SYSTEM_BOOT の間に SYSTEM_SHUTDOWN が存在せず、監視には短い接続断だけが記録される。
• 証跡：pstore / ramoops でクラッシュ前のカーネルログを保持し、前回起動ログ、IPMI SEL、クラウドのシリアルコンソール記録をエクスポート。kernel.panic、ウォッチドッグ、温度イベントを確認。
• 根本原因：訂正可能なメモリ ECC エラーが増加しつつ MCE ハードウェアエラーが発生、訂正不能エラーに至ってファームウェアがリセットしていた。
• 結果：故障 DIMM を特定して交換し、BMC と BIOS ファームウェアを更新。ECC / MCE アラートとトレンド監視を追加し、その後の計画外再起動は発生していません。

成果物

• 根本原因解析報告：症状分類、証跡チェーン、除外プロセス、最終結論。
• イベントタイムライン：障害ウィンドウ内のシステムログ、メトリクス、ハードウェアイベント、業務変更を揃えたビュー。
• 証跡パッケージ：vmcore / crash 解析記録、ログエクスポート、性能サンプリングとフレームグラフ、使用したコマンドリスト。
• 是正・強化方案：カーネル、ドライバ、パラメータ、ハードウェア、マウント方針、リソースクォータに関する具体策と変更手順。
• 証跡取得の設定：kdump、pstore、NMI watchdog、シリアル / netconsole、秒単位監視とアラートルール。
• 再発防止と知識移管：変更回帰チェック項目、定期訓練、社内切り分け手順書。

当社を選ぶ理由

• Linux 技術サービスに約 20 年、数万社への支援実績。カーネル級・ハードウェア級の難障害に精通。
• RHEL / Debian / SUSE 系に加え、銀河麒麟、統信 UOS、openEuler などの信創プラットフォームと国産 CPU 環境での実戦経験。
• 証跡主義：現場を保全してから着手し、再現と変数分離で結論を検証。経験による推測や繰り返しの再起動に頼りません。
• シニアエンジニアによる 24 時間 365 日の技術サポート、突然のフリーズにも迅速に対応。
• 標準化されたプロセス、明確な見積り、規律ある納品、そして再利用可能な社内切り分け能力の定着。