設問と適用コンテキスト
日次の fact_order_settlements データセットは、12のソースシステムから約1,000万件の注文イベントを処理します。財務部門は07:00 UTCに締め処理を開始します。現在、オーケストレーターはジョブが完了したかどうかのみを報告するため、正常終了（green）の実行であっても、遅延したパーティションの公開、1つのソースの欠落、注文バージョンの重複、またはソース合計値との不一致が発生する可能性があります。
データ品質SLOとそれを強制するコントロールを設計してください。ソースシステムは、ソース、通貨、業務日付ごとのレコード数と総額を含むコントロールマニフェストを提供します。未加工イベントは30日間再再生可能であり、修正データは24時間届く可能性があり、2つのコンシューマーで異なるニーズがあります。財務部門は認定済みデータを必要とし、アナリストは明確にマークされた暫定ビューを使用できます。
SLI、目標値、ルールの配置、リリースゲート、オーナーシップ、アラートルティング、エラーバジェットアクション、インシデント復旧、およびロールアウトの検証を網羅してください。1,000万件のイベント、12のソース、締切時間、保持期間、および提案される目標値は面接用の前提条件です。本番環境の目標値には、コンシューマーとの合意と過去の計測値が必要です。これは、データプロダクトに対する運用可能な品質契約が中核となるため、data の問題です。この取り組みはインシデントの前から始まり、認定とポリシーの見直しを通じて継続します。
面接官が評価しているポイント
第1に、候補者が「高品質なデータ」を観察可能なコンシューマーの成果に変換できるかどうかです。鮮度、完全性、妥当性、整合性、正確性、一意性は、それぞれ異なる障害モードを表します。1つの複合的な品質スコアでは、合格したいくつかのチェックの背後に、許容できない重複が隠れてしまう可能性があります。
第2に、候補者が信頼できる分母を選択できるかどうかです。今日の行数と昨日の行数を比較することは大きな異常を検出できますが、完全性を証明することはできません。ソースマニフェスト、変更ログのオフセット範囲、または独立して管理された台帳が、本来到着すべきデータのより強力な証拠を提供します。
第3に、候補者がSLIの仕様とその実装を分離できるかどうかです。「財務部門が締め処理前に認定済みデータを受け取る」ことは成果を表します。スケジューラーの完了時間を測定することは実装の測定であり、公開、カタログ、権限、およびダウンストリームの読み取り障害を見逃します。優れた回答は、コンシューマーの境界近くで測定し、死角を文書化します。
第4に、各障害が所定のアクションを引き起こすかどうかです。ハードインバリアント（絶対的な不変条件）には、公開ブロックまたは隔離が必要です。警告にはオーナーとレビューパスが必要です。ページャーの発報は、緊急のコンシューマー影響を表す必要があります。「失敗したすべてのルールでアラートを送信する」ことは、設計作業をオンコールエンジニアに転嫁し、ノイズを生み出します。
最後に、候補者がオーナーシップを実行可能なものにできるかどうかです。プロデューサー、プラットフォームエンジニア、データセットオーナー、および財務部門は責任を共有する場合がありますが、各ルール、インシデント、および承認には、直接責任を持つ1人のオーナーとエスカレーションパスが依然として必要です。
回答前の明確化のための質問
- 財務部門にとって「準備完了」とは何を意味するか？ 締め処理に07:00の認定データが必要な場合、最後の変換が終了した時点ではなく、財務部門が認定バージョンをクエリできる時点を測定します。プレビューが有用な場合は、別のステータスと契約の下で公開します。
- 完全性と正確性を定義する独立した証拠は何か？ ソースマニフェストは件数と金額の照合をサポートします。それがない場合は、オフセット、ソーススナップショット、または台帳合計を使用し、統計的なボリュームチェックは証明ではなく異常検知として位置付けます。
- ビジネスキーと更新モデルは何か？ 一意性は
(source_id, order_id, version)に適用される場合があり、最新のビジネス状態では注文ごとに1つの有効バージョンが必要になる場合があります。遅延修正は、チェックと認証ライフサイクルの両方を変更します。 - どの障害が機能縮小を許容し、どの障害がブロックしなければならないか？ キーの欠落、バージョンの重複、または台帳の不一致は締め処理を破損させる可能性があり、認証をブロックする必要があります。オプションのマーケティング属性は隔離し、認定された財務フィールドの処理は継続できます。
- SLOウィンドウ内にいくつの品質イベントが存在するか？ 日次パイプラインでは、月間99.9%の有意義な目標を設定するには観測数が少なすぎます。59回の適時な認証など、ローリング60営業日の目標であれば、理解しやすい粒度になります。
- 失敗したゲートを免除（ウェイバー）できるのは誰か？ 例外には、承認者、影響を受けるコンシューマー、有効期限、理由、および監査記録が必要です。オンコールエンジニアがインシデント中に財務契約を独断で再定義してはなりません。
- どのような復旧が可能か？ 30日間のRAWデータ再再生は決定論的な再構築をサポートします。ソースの履歴が可変または不完全な場合、復旧と証拠の要件を変更する必要があります。
30秒の回答フレームワーク
「私は財務部門の意思決定から逆算し、認定された鮮度、マニフェスト照合、ビジネスキーの完全性、妥当性、一意性に対する個別のSLIを定義します。認定テーブルをコンシューマーの境界で測定し、ゼロトレランス（許容度ゼロ）の財務インバリアントとバジェット管理された適時性を明確に分離します。
スキーマチェックはデプロイ前、行チェックは取り込み時、ビジネスチェックは変換後、そしてエンドツーエンドの照合によって認証をゲーティングします。財務部門はバージョニングされた認定ビューのみを読み取り、アナリストは明示された暫定ビューを選択利用できます。各ルールにはアクション、オーナー、ランブックが紐づきます。1つのソースで契約をカナリア検証し、検出結果を既知のインシデントと比較して誤検知を調整し、再再生をリハーサルした上で、鮮度目標が枯渇した際には合意されたエラーバジェットポリシーに基づいてエンジニアリングの優先順位を変更します。」
ステップごとの詳細解説
ステップ1: データプロダクトとコンシューマーの成果を定義する
可能なすべてのチェックのカタログではなく、認定された決済データセットに対する1つの契約を作成します。データセットのバージョン、業務日付、コンシューマー、オーナー、認証期限、修正ポリシー、および監査のために保持される証拠を明記します。2つのコンシューマーモードを明示する必要があります。
preliminary: 早期に利用可能、宣言された遅延ソースを含む可能性あり、財務締め処理には絶対に使用不可。certified: 指定されたバージョンに対して不変、すべてのハードゲートを通過、マニフェストおよび品質結果IDを保持。superseded: 以前の証拠を検出可能な状態に保ちつつ、修正バージョンによって置き換え。
この状態モデルにより、正常終了したオーケストレーションステータスが意図しないビジネス保証になってしまうことを防ぎます。財務部門は certified のみをクエリし、探索的なコンシューマーは財務契約を損なうことなく、確実性と引き換えに鮮度を得ることができます。
ステップ2: 各SLIを適格イベントに対する良好イベントとして記述する
コンシューマーから見える成果と定義された単位を使用します。このシナリオにおける初期の鮮度SLIは以下の通りです。
freshness_sli =
business-day partitions certified and queryable by 06:30 UTC
/ eligible business-day partitions
starting_slo = at least 59 good partitions in a rolling 60-business-day windowこの閾値は、財務の締め処理の30分前のバッファを残し、サンプルの期間内で1回の遅延認証を許容します。どちらの値も、財務部門と交渉し、過去の実績と照らし合わせて検証すべき前提条件です。バージョンが読み取り可能であることを確認するコンシューマークエリまたはカタログ状態から測定します。スケジューラーの完了タイムスタンプは単なる診断シグナルにすぎません。
他のディメンションにも独自の成功基準を設定します。
- 完全性: 期待されるすべてのソースマニフェストが存在し、レコード数とクリティカルキーのカバレッジが照合されていること。
- 一意性: 認定パーティション内に
(source_id, order_id, version)の重複タプルがゼロであること。 - 妥当性: 必要なキーが存在し、契約で管理されたフィールドが許可された型、ドメイン、範囲を使用していること。
- 整合性: 集計前に、ソース、通貨、業務日付ごとに件数と金額が照合されていること。
- 修正の適時性: 受理された修正が、合意されたウィンドウ内に新しく認定されたバージョンになること。
正確性を内部のデータ形状から推測することはより困難です。妥当で一意な金額であっても、誤っている可能性があります。ソース管理された合計値、台帳照合、サンプリングによるビジネスレビュー、およびダウンストリームの成果チェックは、フォーマットルールよりも強力な証拠を提供します。
ステップ3: ハードインバリアント、SLO、診断を意図的に選択する
アクションを理解しやすく保つために、3つのクラスに分類します。
- ハードインバリアント: ビジネスキーの欠落、バージョンの重複、照合されない財務合計など、違反があると認証をブロックするもの。
- バジェット化された目標: 認証期限や修正の所要時間など、文書化されたポリシーの範囲内で一時的な未達が許容されるもの。
- 診断: 前日比20%のボリューム変化など、調査には役立つがコンシューマーの成功を定義しないシグナル。
単にエラーバジェットの計算式に合わせるためだけに、ハードな正確性要件を「許容される不正行」に変換しないでください。1つの高額注文の重複は、何千もの無害なオプション項目のNULL値よりも重要になる可能性があります。各目標とその結果を分離して管理してください。ダッシュボードの総合スコアは傾向を要約できますが、ブロックルールを無効化することはできません。
ステップ4: 最も早い有用な境界にチェックを配置する
プロデューサーおよび変換のCIで、スキーマ互換性と契約のサンプルを実行します。取り込み時には、パース可能性、必須エンベロープフィールド、ソースの識別、オフセットの連続性、および冪等性を検証し、特定可能な不正レコードを理由コード付きで隔離します。変換後は、ビジネスキー、参照関係、バージョン選択、通貨ルール、およびソースレベルのスライスをテストします。公開時には、マニフェストと台帳の照合を実行し、認定された正確なバージョンがクエリ可能であることを確認します。
同じルールをすべての場所で実行する必要はありません。5つのフィクスチャを使用した非NULL単体テストはコードパスを検証しますが、本番ソースについてはほとんど何も語りません。本番環境の集計は障害を検出できますが、中間コンシューマーを保護するには遅すぎる可能性があります。変更前の安価な防止チェック、データが入ってくる運用チェック、そして約束が消費されるエンドツーエンドのチェックを適切に配置します。
以下は、特定の製品のスキーマではなく、ツールに依存しない説明用の疑似YAMLです。
dataset: finance.fact_order_settlements
owner: finance-data
consumer: daily-close
certification_deadline_utc: "06:30"
rules:
- name: required_business_key
dimension: completeness
scope: row
pass_ratio: 1.0
action: block_and_quarantine
- name: unique_order_version
dimension: uniqueness
scope: [source_id, order_id, version]
pass_ratio: 1.0
action: block_certification
- name: source_manifest_reconciliation
dimension: consistency
scope: [source_id, currency, business_date]
pass_ratio: 1.0
action: block_certification_and_page_ownerステップ5: 独立した照合を使用し、結果をスライスする
受信した集計データを、何も配信しなかったソースを含む、期待されるすべてのマニフェスト行と結合（JOIN）します。受信データ側からのLEFT JOINのみでは、欠落したソースが見えなくなります。精度の低下を招く変換を行う前に、元の通貨で件数と金額を比較します。マニフェストID、ソースウォーターマーク、変換バージョン、テーブルスナップショット、およびルール結果を一緒に記録します。
障害をソース、リージョン、通貨、イベントタイプ、パイプラインステージごとにスライスします。全体の合格率が99.99%であっても、小規模ソースの完全な停止が隠れてしまうことがあります。逆に、1つの既知の遅延ソースによって、取り込み、変換、公開から同一のページャー発報が連鎖してはなりません。最初に対処可能な壊れた境界にルーティングし、診断情報を保持しながら派生アラートを抑制します。
過去の傾向バンドはボリューム異常検知に有用ですが、季節性、プロモーション、新設されたソースによって正当に変動することがあります。独立したコントロール合計によって損失が確認されるまでは、異常を調査すべき証拠として扱います。
ステップ6: ゲート、例外、オーナーシップを実行可能にする
各ルールは、重大度、アクション、直接オーナー、バックアップオーナー、エスカレーション先、ランブック、および最大確認時間を宣言する必要があります。実用的な分担は以下の通りです。
- ソーススキーマまたはマニフェストの失敗: プロデューサーが修正を所有し、取り込みオーナーが影響を封じ込める。
- トランスポート、重複排除、またはオーケストレーションの失敗: データプラットフォームが復旧を所有する。
- セマンティック変換または照合の失敗: データセットオーナーが診断と再構築を所有する。
- ビジネス定義の相違: 財務データスチュワードが、監査可能な変更レビューを通じて契約を決定する。
ウェイバー（適用免除）は、明示的に縮小された新しいバージョンを作成するか、データセットを暫定状態に維持します。誰が承認したか、なぜビジネスがリスクを受け入れるか、影響を受けるコンシューマー、および例外の期限を記録します。失敗した結果を上書きしたり、認定エイリアスを未検証のパーティションに密かに向けたりしてはなりません。
ステップ7: 意思決定を変えるエラーバジェットポリシーを定義する
鮮度SLOの例では、1回の遅延パーティションがローリング60営業日のバジェットになります。消費状況とバーンレートを追跡します。1日の遅延でバジェット全体を消費します。誤った認定財務パーティションは、残りの鮮度バジェットに関係なくインシデントポリシーをトリガーします。
未達が発生する前にアクションについて合意しておきます。バーンレートの予測により、唯一許容されている未達のリスクがあることが示された場合、最大の原因をレビューし、復旧能力を検証します。バジェット枯渇時には、リスクの高いパイプライン変更を一時停止し、信頼性向上作業を優先し、オーナーが承認した終了基準を要求します。このポリシーにより、SLOは意思決定ツールへと変わります。結果が伴わないダッシュボードは単なるレポートにすぎません。
検知結果がコンシューマーのインシデントと相関しない場合や、ページャーの適合率が低い場合は、SLIを見直します。測定を財務部門の近くに移動するか、不足しているスライスを追加するか、ノイズの多い診断を緩和します。運用のノイズを鎮めるためにハードインバリアントを緩めてはなりません。実装またはルーティングを修正してください。
ステップ8: カナリアリリース、復旧リハーサル、カバレッジの実証
1つのソースと代表的な14〜30日間の過去データウィンドウに対して、ゲートをかけずにルールをシャドウ評価します。制御された障害を注入します。ソースの除外、注文バージョンの重複、スキーマの破壊、公開の遅延、行数を維持した金額の変更などです。期待されるルール、オーナー、ランブックが1回だけアクティブになることを確認します。
次に、低リスクの1つのソースにゲートを適用し、ソースの重要度に応じて拡張し、最後に認証を保護します。受け入れ基準には、注入された障害の検出カバレッジ、誤った認定パーティションの排除、抑制された誤報率、コンシューマーが読み取れる証拠、未加工イベントからの決定論的再再生、および財務の締め切り前の復旧が含まれます。ルールのコストを測定し、正確性が許す限り変更されたパーティションのみをスキャンします。定期的に自らの期限に遅れる品質システムは、パイプラインそのものを損ないます。
ロールアウト後、コンシューマーが手動で発見したインシデントと、影響を生み出さなかったアラートをレビューします。これら2つの集合から、カバレッジの不足と精度の低さが明らかになります。契約の変更はデータモデルとともにバージョニングし、プロデューサーとコンシューマーのレビューを義務付け、すべての認証に使用された正確なルールセットを保持します。
高品質な回答例
「私は財務部門の観点からサービスを定義します。特定の決済パーティションが認証され、クエリ可能で、照合され、締め処理前に利用可能であることです。DAGの完了は単なる診断情報であるため、公開されたバージョンをプローブし、そのマニフェスト、スナップショット、コードバージョン、および品質結果を保持します。
鮮度については、ローリング60営業日のウィンドウで06:30までに59回の認証パーティションを提供することを提案し、これを財務部門および過去のパフォーマンスと照らし合わせて調整します。正確性には個別のハードゲートを設けます。すべてのソースマニフェストが到着すること、件数と元通貨の金額がソースおよび業務日付ごとに照合されること、必須のビジネスキーが完全であること、そして (source_id, order_id, version) が一意であることを必須とします。これらを平均化して、1つのブロックすべき障害の通過を許してしまうようなスコアには決してしません。
チェックは複数の境界で実行されます。CIは互換性のないスキーマおよび変換ケースを捕捉します。取り込み処理ではエンベロープ、オフセット、冪等性をチェックし、特定可能な障害を隔離します。変換処理ではセマンティックルールと参照整合性ルールをチェックします。公開処理では独立した照合を実行し、正確なバージョンが読み取り可能であることを確認します。財務部門は認定エイリアスのみを受け取り、アナリストはソースと品質のステータスが付与された暫定ビューを使用できます。
失敗したすべてのルールは、アクションと1人のオーナーに対応付けられます。プロデューサーは壊れたソース契約に対処し、プラットフォームチームはトランスポートを処理し、データセットオーナーは変換と認証を処理します。ウェイバーは時間制限があり、コンシューマーから可視化され、財務スチュワードによって承認されます。誤った認定パーティションは、鮮度バジェットが残っていてもインシデントとして扱われます。
過去のパーティション上でルールをシャドウ実行し、ソース欠落、キー重複、スキーマ破壊、遅延、件数は同一で金額が誤っている障害を注入した後、1つのソースにゲートを適用します。検出、ルーティング、再再生、誤報率、ルールの実行時間が受け入れ基準を満たした場合にのみ適用範囲を広げます。唯一許容されている遅延日数が消費された場合、合意されたポリシーに従って、終了基準が満たされるまで開発リソースを機能開発から信頼性向上へとシフトします。」
よくある間違い
- ジョブの成功のみを監視する → 完了したジョブが不完全または読み取り不能なデータを公開する可能性があります → コンシューマーの境界で認定オブジェクトを測定します。
- 昨日の行数を完全性の証明として使用する → 正当な需要の変化とサイレントなソース損失の見分けがつきません → マニフェスト、オフセット、スナップショット、または別の管理された合計値と照合します。
- すべてのチェックを1つのスコアに集約する → 合格した多くのオプションルールが、1つの壊れた財務インバリアントを覆い隠す可能性があります → すべての重要なディメンションに独自の閾値とアクションを設定します。
- 月間1回の日次イベントに対して99.9%を設定する → 分母がその精度を表現できません → 意味のある粒度を持つウィンドウと単位を選択します。
- すべての不正行にエラーバジェットを与える → 行数はビジネス価値と厳格な整合性を無視します → ゼロトレランスのインバリアントは、バジェット管理される適時性の外側に配置します。
- 失敗したすべてのルールでページャーを発報する → 1つのソース障害が、対応不能なアラートの連鎖を引き起こします → オーナーが割り当てられた最初の境界で発報し、ダウンストリームの派生アラートを抑制します。
- オンコールが独断でゲートを免除できるようにする → コンシューマーがリスクを評価できなくなり、監査証拠が失われます → 承認され、期限があり、コンシューマーに見える例外を使用します。
- ハッピーパスのみをテストする → チームは締め処理中に復旧が非決定的であることに気づくことになります → 強制適用前に、代表的な障害を注入し、再再生をリハーサルします。
- 実行ごとに高コストなフルテーブルスキャンを追加する → 品質チェックが、本来保護すべき鮮度のマージンを消費してしまいます → 安全な場合は、増分チェックと定期的な完全照合を組み合わせて使用します。
フォローアップ質問と回答例
フォローアップ1: ソースがマニフェストを提供できない場合はどうしますか？
独立性の高さに基づいて代替手段を順位付けします。ソーススナップショット、データベースのログシーケンス範囲、ブローカーオフセット、チェックサム付きのファイルインベントリ、および個別に作成された台帳は、ターゲットテーブル自体の行数よりも強力です。過去の傾向バンドを使用して異常を検出し、完全性を証明できないことを開示した上で、クリティカルなソースについてはマニフェストまたはコントロール合計の提供をプロデューサー契約の一部とします。
フォローアップ2: 財務部門が永久に遅延パーティションをゼロにすることを要求した場合はどうしますか？
暗黙の100%目標は信頼性作業の優先順位付けメカニズムを失わせ、運用上維持できない可能性があります。その要求に近づけるために必要な冗長性、再再生時間、ソース依存関係、およびコストを数値化します。財務的な正確性をハードゲートとして維持しつつ、測定可能な鮮度目標とより厳しい努力目標を提示し、対応ポリシーについてビジネス、エンジニアリング、運用の間で明示的な合意を得ます。
フォローアップ3: パーティションが認定された後に修正が発生した場合、どのように対処しますか？
不変な新しい認証バージョンを作成し、それを以前のバージョンおよび修正マニフェストとリンクさせ、影響を受けるすべての照合ルールを再実行し、承認後にのみ認定エイリアスをアトミックに切り替えます。監査のために古い証拠を保持します。元の鮮度SLIは既知のエラーがどれだけ迅速に修復されたかを説明できないため、修正の所要時間は別途測定します。
フォローアップ4: 数百のデータセットにわたるアラート疲れをどのように防ぎますか？
コンシューマーへの影響によってデータセットを階層化し、ページャー発報の前に直接オーナーの存在を義務付け、実用的なSLO脅威またはハードゲート障害に対してのみページャーを発報します。関連するルール障害を最も早い破損依存関係の下にグループ化し、警告をレビューキューにルーティングし、定期的に発報内容と実際のコンシューマーインシデントを比較します。適合率が一貫して低いルールは廃止または再設計します。
フォローアップ5: ストリーミングパイプラインでは何が変わりますか？
1日1回の認証機会を、イベント時間ウィンドウまたはコンシューマー分（consumer minutes）に置き換えます。イベント時間からクエリ可能な状態までの鮮度、クローズされたウォーターマークまたはソースオフセットからの完全性、および遅延イベントに対する修正動作を定義します。データを即座に隔離しなければならないレコード単位またはキー単位の厳格なインバリアントを維持しながら、短時間および長時間のウィンドウにわたるバーンレートアラートを使用します。
フォローアップ6: データ品質ツールをどのように評価しますか？
機能の数ではなく、契約への適合性から始めます。行および集計ルール、複合キーの一意性、増分実行、失敗レコードの証拠、バージョニングされた結果、オーケストレーションゲート、オーナーシップメタデータ、API、アラートルティング、および本番規模でのコストを検証します。各候補ツールに対して障害注入テストスイートを実行します。洗練されたダッシュボードであっても、エンドツーエンドの照合の欠如や強制力のないリリースゲートを補うことはできません。