DataOps品質マニフェスト

あらゆる規模、あらゆる技術スタックのデータチームと長年仕事をしてきた結果、当社は、品質はテストからしか生まれないこと、そしてテストすべき品質はデータだけでなくデリバリー全体であることを確信するようになりました。完璧なデータでも、間違ったコード、レポート、モデルを通れば、それはエラーです。お客様にはその違いがわかりません。当社は、データ品質の口うるさい催促役でした。行数を目視で確認し、問題がないことを祈りました。12か月のアセスメントを実施し、文書が一つできただけで何も直りませんでした。誰も開かないダッシュボードを作り、朝9時にお客様から不良データの報告を受けました。当社が求めるのは、あらゆる地点で品質を証明する方法です。キーボードの前のヒーローがいなくても動くテストと、直せる人にそのまま渡せる証拠です。DataOps マニフェストは、品質が最重要だと述べています。Data Journey マニフェストは、お客様が問題を見つけるのは許されないと述べています。本マニフェストは、その両方を実践に移す方法です。

マニフェストに署名する

当社は、仕事を通じて以下のことを重視するようになりました。

希望的観測や手作業のチェックよりも自動テスト
一度きりのプロジェクトよりも継続的な実践
意見よりも測定
手書きのルールよりも自動生成されたテスト
リネージ図よりもテストカバレッジ
最後の検査よりもラインに組み込んだ品質ステーション
上からの義務付けよりも影響力と証拠
いつかの完璧よりも今日の70%

6つのグループに分かれた24の原則と、プラス1。選択すると、その原則に移動します。

1-4

証拠

1

テストしたことしかわからない

希望はテストではありません。ビジネスレビューも、パイプラインが緑で終わったことも、テストではありません。どのテストも確認していないなら、それが正しいかどうかはわかりません。
2

データをテストし、ツールを監視する

品質とは、データ品質にプロセス品質を加えたものです。テーブルが完璧でも、更新が実行されていなければ役に立ちません。ジョブが緑で終わっても、その中の数値については何もわかりません。すべてのツールについて、エラーとタイミングを確認します。
3

手作業のチェックをしない

手作業のチェックは、誰かが思い出したときにしか実行されません。そして午前2時には誰も思い出しません。データは毎日届きます。だから、すべてのテストを、毎回のロードで自動的に実行します。Data Journey マニフェストははっきりと述べています。手作業の品質テストは、疫病のように避けよ、と。
4

基準を決める前に測定する

データをプロファイリングし、テストを作成し、基準がどうあるべきかはベースラインに語らせます。委員会が先に基準を書けば、その後のあらゆる決定が遅れます。テスト結果がなければ、あなたは意見を持つ一人の人間にすぎません。

5-6

人

5

一人から始める

無料ツールを持ったやる気のある一人は、憲章を持った運営委員会に勝ります。口うるさい催促役を見つけ、その人に証拠を渡してください。
6

影響を与えることが仕事

欠陥を見つけた人が、それを生んだシステムを所有していることはまれです。ソースデータは、本来の目的には十分に役立っています。だから、その所有者には変える理由がありません。修正に「はい」と言いやすくすることです。

7-9

テスト

7

テストはプロファイルに書かせる

テーブルごとに何百ものテストを手でコーディングしても、終わることはありません。テストは自動生成し、SQL は、ドメインの専門家だけが知っているビジネスルールのために取っておきます。
8

テストは共有資源

アナリスト、データスチュワード、エンジニア、そしてモデルが、すべて同じルールに触れます。そのうち Git アカウントを持っているのは一人だけです。すべてのテストとすべての結果を、一つの記録用データベースに保管し、人は UI から、コードは API から、モデルは MCP からアクセスできるようにします。正本は一つだけ。すべての変更は Git に送り、差分の確認、レビュー、ロールバックができるようにします。
9

いつかの完璧より今日の70%

動くテストを今日の午後に出荷してください。一回りするごとにデータについて何かを学び、そのたびに基準は良くなります。

10-13

スコアと行動

10

重要なものをスコア化する

FAX 番号の列のために行動を変える人はいません。お客様が気にかける要素をスコア化し、お客様ごとに別のスコアを作ります。
11

すべてのスコアはテストにさかのぼる

修正への道筋がないスコアは、ただのノイズです。ダッシュボードのすべての数値は、問題を示し、修正を証明するテストにさかのぼれるようにします。
12

行動しやすくする

すべてのダッシュボードには、名前のあるお客様と、データを直せる名前のある担当者がいます。問題、その影響、再現方法、変更すべき点を、その人がすでに使っているチケットシステムで渡してください。
13

トレンドラインを残す

一つのスコアは意見にすぎません。上司がすでに見ている KPI に結びついた6か月分のスコアは、予算になります。まずは二つの数値から始めます。本番環境でのエラー数と、変更を出荷するまでの時間です。もっと余地がほしいと頼むときに指し示すのが、このトレンドです。

14-19

実践

14

エラーを愛する

欠陥の一つひとつが、データやプロセスについて何かを教えてくれます。品質サークルで一緒に振り返り、欠陥を生んだ工程を直します。責めるのは工程であり、人ではありません。
15

納品条件をテストにする

データコントラクトとは、双方が合意したテストの集まりです。実行できる条件は、実行できない約束に勝ります。
16

移行を証明する

移行とは、新しいシステムが古いシステムと同じ真実を保持しているという約束です。両方をテストし、行数から列の値まで、それを証明します。
17

ノイズを減らす

誰も信頼しないアラートは、アラートがないよりも悪いものです。失敗が意味を持つまで、すべてのテストを調整し、対処できる人に送ります。毎晩発報するものは格下げします。ミュートは決してしません。
18

本番環境でも責任を持つ

デプロイは仕事の途中であり、終わりではありません。誰かがラインを見張ります。その誰かとは、あなたです。
19

エージェントが書いたものをテストする

エージェントは数秒で変換処理を出荷しますが、パイプラインのことは何も覚えていません。修正チケットやカスタム SQL の下書きはエージェントに任せてください。それ以外にエージェントが触れたものはすべて、テストが確認するまでは未テストです。

20-24

あらゆる地点で品質を証明する

20

テストは… ソースで

ソースが目的に適していることを、テーブルごと、列ごとに証明します。ソースを所有しているのはあなたではありません。だから、あなたの証拠は、所有者を説得できるものでなければなりません。
21

テストは… 取り込み時に

すべてのテーブルについて、鮮度、量、スキーマの変更、ドリフトを監視します。6,000のテーブルを手作業で監視することはできません。異常検知ならできます。
22

テストは… 本番環境で

すべてのレイヤーの間に仕掛け線を張り、欠陥が見つかったらアンドンを引いてラインを止めます。すべての失敗が停止に値するわけではありません。どれで止め、どれで警告するかを事前に決めておきます。誰かが調べている間、本番環境は最後に正常だったデータで動き続けます。
23

テストは… 開発環境で

デプロイする前に、今日のコードを、昨日の本番データのクローンまたはスライスに対して実行します。列名を変えたら、どの下流レポートを壊したかを赤いランプが教えてくれるべきです。ここで見つけたバグの修正コストは、お客様が見つけた場合の100分の1です。
24

テストは… どこでも、毎回、自動で

一つの NULL チェックが、四つの場所で四つの役割を果たします。一つでも省けば、その失敗を見逃します。すべてのテーブル、すべての列、すべてのツール、そしてお客様が読むすべての数値をカバーします。手作業のテストはしません。

DataOps を品質から始める

DataOps マニフェストには18の原則がありますが、月曜日にそのすべてを採用する人はいません。まずは自動データテストから始めてください。最も安価なステップであり、お客様が最初に効果を実感するステップです。オーケストレーション、CI/CD、オブザーバビリティは、どれもデータが正しいかどうかを知ることに依存しています。