プロンプトと適用範囲
コアダンプはプロセスのアドレス空間のスナップショットです。これには、キー、リクエストボディ、ユーザーデータ、クリアされていないバッファなどが含まれる可能性があります。この質問では、Linuxの診断と本番データのガバナンスをテストします。ダンプを収集できるかどうかと、誰がそれを閲覧できるか、それがどのくらいの期間残るか、そしてクリーンアップがどのように証明されるかを分離して考えます。
面接官が評価している点
- 終了シグナル、journal、カーネルメッセージ、バージョン、およびコアメタデータからの証拠。
- systemd-coredumpの収集、圧縮、ストレージ、および
coredumpctl境界の理解。 - 正確なバイナリ、ライブラリ、デバッグシンボル、およびbuild IDによるシンボル解決。
- コンテンツ、権限、暗号化、保持、容量、およびプライバシーに関する完全な制御。
- 再現、クラッシュメトリクス、削除チェック、およびアクセスレビューを通じた修正後の証明。
推奨される回答の構成
低リスクな証拠から始めます：サービスのステータス、シグナル、journal、カーネルメッセージ、バージョン、およびリソースメトリクス。コアの取得が正当化される場合は、隔離されたインスタンス上で制御されたキャプチャを一時的に有効にし、サイズと数を制限して、専用の暗号化ストレージを使用します。速やかに分析して破棄するか、文書化された保持ジョブによって期限切れにします。
ディープダイブ：クラッシュから修正まで
まず終了原因を特定する
systemctl status、journal、カーネルOOMレコード、終了シグナル、および再起動回数を確認します。SIGSEGV、SIGABRT、およびSIGBUSはそれぞれ異なる手がかりを提供します。exit 137の場合は、まずcgroup OOMの確認をトリガーする必要があります。コアファイルが存在すること自体は、セグメンテーション違反の証拠にはなりません。
シンボル解決の入力を固定する
クラッシュしたインスタンスの正確なバイナリ、共有ライブラリ、デバッグシンボル、およびbuild IDを保持します。これらを信頼できるアーティファクトストアから取得します。情報漏洩リスクを軽減するため、まずスレッド、シグナル、およびスタックを確認し、ヒープやレジスタの検査は必要な場合にのみ行います。
制御された収集を構築する
systemd-coredumpは、ダンプを専用サービスに引き渡し、journalまたは外部ディレクトリに保存できます。ファイルごとおよび全体のクォータ、圧縮、並行性、およびアラートを設定します。極めて機密性の高いサービスの場合は、LimitCORE=0を設定するか、メタデータと制御されたスタックのみを収集し、ロールバックを記録します。
アクセスと保持の境界を確立する
コアストレージを暗号化し、最小権限を付与し、すべてのアクセスを監査します。通常の運用アカウントがダンプをダウンロードすることを許可しないでください。診断期間とポリシーに基づいて保持期間を設定し、自動期限切れと容量アラームを設けます。コマンド、パス、チケットにトークンを含めてはなりません。
証拠をもってクローズする
修正前のクラッシュを再現し、同じ入力で新しいビルドを検証し、クラッシュ率と再起動率を観察します。ダンプ、キャッシュ、バックアップの期限切れを確認し、アクセスレビューを実行します。機密データの削除が証明できない場合、リスクは残ったままになります。
回答例
「シグナル、journal、カーネルOOMレコード、デプロイバージョン、およびcgroupメトリクスを確認し、SIGSEGVとexit 137を区別します。アプリケーションのクラッシュである場合は、隔離されたノードでsystemd-coredumpを一時的に有効にし、ファイルごとおよび合計サイズに上限を設け、build IDに一致するシンボルを使用してヒープの前にスタックを検査します。暗号化されたディレクトリへのアクセスはインシデント対応チームのみに短期間許可され、トークンがチケットに入ることは決してありません。元の入力でリグレッションテストを実施し、クラッシュ率を観察し、ダンプを削除し、journal、バックアップ、および権限を確認します。境界の信頼性を確保できない場合は、完全なダンプを無効にし、制御されたメタデータとスタックのみを保持します。」
よくある失敗パターンと対策
- コアがある＝SIGSEGVと決めつける → シグナル、OOM、cgroup、デプロイの証拠を検証する。
- 本番環境にツールを直接インストールする → 一致するアーティファクトと隔離された分析環境を使用する。
- ディスク容量の話だけで終始する → クォータ、保持、暗号化、クリーンアップを含める。
- ダンプを通常のログのように扱う → 最小権限、一時アクセス、独立した監査を適用する。
- サービス復旧時点で対応を終了する → 再現、クラッシュ率、削除、バックアップ、アクセスを検証する。
評価ルーブリックとセルフチェック
強力な回答には、終了の証拠、build IDとシンボル、systemd-coredumpの境界、収集スイッチ、クォータ、暗号化、アクセス制御、保持と削除、データの最小化、ロールバック、および修正後のメトリクスが含まれます。
確認項目：原因を証明できますか？分析ファイルはビルドと一致していますか？誰がアクセスできますか？どのくらいの期間保持されますか？トークンがログに含まれないようにどう防ぎますか？修正とクリーンアップは何をもって証明されますか？
フォローアップと発展的トピック
コアダンプを完全に無効化すべきなのはどのような場合ですか？
アドレス空間の機密性が非常に高く、信頼できる隔離、暗号化、アクセス制御、クリーンアップを確立できない場合は、完全なダンプを無効にします。シグナル、スレッドスタック、または最小限の診断証拠を保持し、失われた診断能力を記録します。
1台のマシンのみがクラッシュした場合、リスクをどのように軽減しますか？
まずメタデータと制御されたスタックを収集し、そのインスタンスと短い期間に制限します。完全なダンプが必要な場合は、自動期限切れ、ワンタイム認証、およびアップロード後のローカルコピーの即時削除を使用します。
誤ったシンボル解決を避けるにはどうすればよいですか？
バイナリ、ライブラリ、およびシンボルのbuild ID、チェックサム、アーティファクトマニフェストを検証します。一致しない場合はスタックを不確定としてマークし、類似したリリースから推測して結論を出さないようにします。
ダンプがすでにバックアップに含まれている場合はどうしますか？
バックアップを別のデータドメインとして扱います。オブジェクトのバージョンと期限切れを追跡し、復元アクセスを制限し、消去プロセスがバックアップインデックスとローテーションジョブをカバーするようにします。承認された例外と最新のクリーンアップ時間を記録します。