データSLAの設定と達成のための11ポイント・チェックリスト（SLAテンプレート付き）

いわば、データ・サービス・レベル契約（データSLA）を策定してそれに取り組むには、小規模すぎるチームは存在しないと言われています。データSLAとは何ですか。定量化可能なレベルのサービスを提供するという公約です。サービスとしてのインフラストラクチャ (IaaS) プロバイダーが 99.99% のアップタイムを約束するのと同様、特定の品質のデータを特定のパラメーター内で提供することを約束します。

コミットメントが公に行われることが重要です。（少なくとも会社内では）。公開されることにより、説明責任が向上し、最も重要なことを中心にすべてのチームの連携が強化され、品質をサポートする構造を構築できるようになります。

このガイドでは、独自のデータSLAを確立する方法について説明します。

正式に文書化されたデータSLAにより、非公式なコミットメントが具体的になり、相互に同意できるようになります。すべてのデータ関係には、明示するかどうかにかかわらず、非公式なコミットメントが含まれ、多くの場合、二者間で別々のものについて話し合っていることに気づかずに同意してしまうことがよくあります。

では、データSLAとはいったい何なのでしょうか？それは、会社のWikiやGoogle Docなどの共有スペースに投稿される、通常250～500語のシンプルな書かれた文書です。それには、次の6つの要素が含まれていなければなりません。

• 目的：なぜこのデータSLAが存在するのか？どのような問題が解決されると期待しているのか。また、どのように使用されることを期待しているのか。

• 約束： 他のチームと何を約束しているか？

• 測定：データSLAをどのように測定するのか、誰が測定するのか、SLAの期間は？

• 影響：データ SLA に従わなかった場合、どうなるのか？誰が責任を負い、どのような種類の修復策が利用可能か？

• 条件：見返りに何を期待するのか？あなたの約束にはどのような条件があるか？

• 署名：誰がデータSLAにコミットするのか？

データSLAを作成するときは、意味を変えずに、できるだけ少ない単語で伝えます。これには多くの編集が必要ですが、まずはすべてを一度にざっくりと書き上げて、後で編集しなおすことをお勧めします。その理由は、ページを長く見つめ続けると、作家が「白紙恐怖症」と呼ぶものを作り出し、それを後回しにする可能性があるからです。低品質のドラフトを今すぐ作成してください。待たないでください。

データ・サービス・レベル契約の例は次のとおりです。

この文書の目的は、正確なパラメータ内で高いデータ品質を維持するという、当チームから他チームへの公約を確立することです。私たちの願いは、それによって理解を深め、全員が協力して仕事ができ、チームが相互に説明責任を負うようになることです。

IBMの約束：データ品質スコアは、毎日午前5時00分（東部標準時）までに少なくとも95％のデータ品質スコアで販売データを提供するため、チームは「昨日の売上はどうだったのか」などの質問に答えられます。IBMは1営業日以内にすべてのリクエストを確認し、単純なチケットと複雑なチケットに分類します。単純なリクエストは3営業日以内、複雑なリクエストは2週間以内に解決します。

データ品質は、実行開始時間と実行完了時間、レコード数、レコード数に対するNull値の比率、分布スコアやドリフトスコアなどのデータ配信KPIを、データの鮮度、データの完全性、データの忠実性に関する事前定義された基準と比較することで測定されます。

データSLAを履行しなかった場合、3営業日以内に、当社のチームは謝罪文を公開し、その原因と、それを修正するために講じている具体的な対策を説明します。

この約束を果たすためには、皆様のご協力が必要です。私たちのチームは、データがどのように使用されているかに関するタイムリーな指示、インプット、明確なフィードバック、および複雑な変更依頼については、少なくとも4週間前までの通知を必要としています。

ご質問、ご意見、ご懸念事項はすべてdata-eng@team.comまでお寄せください。

決意を込めて

– データ・エンジニアリング・チーム

SLAを設定したら（あるいは編集中に）、SLA を遵守する前に、実施する必要があるすべてのことについて検討を開始します。

例：

このフレーズからできるだけ曖昧さを排除するようにしてください。具体的かつ明確な言葉で定義してください。私たちの見解では、 高品質な データの定義に使用できる 特性は 4 つ あります。定義したら、その定義について他のチームの同意を得ます。

以下の点を考えてみてください。

• 優れたデータがビジネスにもたらす成果は何でしょうか？
• 優れたデータを定義する固有の特性は何ですか？
• 不良データを定義する特性は何ですか？

追跡するには、パイプラインの一部がダウンしているかどうかを実際に把握できるオブザーバビリティーツールが必要になります。これがなければ、 SLA が満たされていないかどうかを測定するのは非常に困難であり、根本原因を診断するのはさらに困難です。また、エラーを理解するのにも役立つため、はるかに迅速に修正することができます。

データSLAを北極星指標、つまりすべての人を導くフォーカル・ポイントのように扱うことができます。しかし、その中にはもちろん多くの複雑な要素が隠れており、その上流と下流で何が起こっているかを把握するためには KPIを追跡する必要があります。

ここでは、いくつかの具体的な推奨事項を紹介します。

1. 自動テストを設定して、4 つの次元でデータ品質を監視する
   • 本番環境前のテストデータ
   • 各段階でのテスト：完全性、異常
2. 問題を発見し、対応し、解決する能力を測定
   • 発見までの時間
   • 解決までの時間
   • アセットあたりのインシデント
3. すべての問題の直接原因と根本原因を文書化する
   • データ・パートナーが配信できなかった
   • タイムアウト
   • ジョブがキューで滞留
   • 予期せぬ変化
   • 権限の問題
   • ランタイムエラー
   • スケジュールの変更

あなたがコミットすることには注意してください。どこにいても、すべてに備えることはできません。99.999%の稼働率を保証するSLAでは、ダウンタイムが年間でわずか5分であることを意味します。そのためには、より多くの人数、可視性、冗長性を高め、24時間体制で働く従業員が必要になるでしょう。

おそらく、JiraやServiceNowなどのチケット発行ツールが必要になるでしょう。データ・ユーザーはチケットを作成し、チームはチケットを追跡し、あなたはそれらのチケットの性質を理解することができるため、長期的な修正を考え、問題領域を特定することができます。

公開データSLA文書に明記しなくても、データ・ソースとパイプラインの所有者を定義してください。何か問題が発生した場合、最終的な責任を負うのは彼らです。また、彼らの休暇や退職の際の対応についても明記してください。

Slackなどのチーム・メッセージング・アプリや、PagerDutyなどのインシデント管理システムに投稿するようにアラートを設定します。そのアラートにインシデントの詳細を多く含めるほど、より速く診断できます。このようなアラートは、他に誰が参加する必要があるか、あるいは分析をどこから始めるべきかを早期に教えてくれます。（IBM Databand はこれらのアラートを送信し、有用な洞察とコンテキストを追加できます。)

データ・コンシューマーが ダッシュボード上のテーブルが壊れていると話したとします。どのように確認して対応しますか？インシデントが発生したときに、これを書き出すことで、誰もが他の誰かが対処してくれるだろうと思い込み、結局誰も行動を起こさないという傍観者問題に陥るのを防ぐことができます。

チームの規模や世界中への分散状況によっては、これを非常に真剣に受け止め、緊急対応者がインシデント指揮官と呼ぶ人を任命することもできるでしょう。その人がインシデントの CEO となり、他の全員を指揮します。（これにより、協調的な対応が実現し、複数の人が同じ問題に取り組むのを避けることができます。）

可能であれば、ユーザーのダッシュボードにアラート・パネルを作成して、システムのステータスを伝えられるようにします。何か問題が発生した場合は、「停止が発生しています。解決までの推定時間は次のとおりです」と記載できます。これにより、すべてのデータ コンシューマーから繰り返し行われるアラートが分散され、実際に対応できるようになります。

アラート・パネルを作成できない場合は、少なくとも各チームに連絡可能な責任者を指定し、その人が他のチーム全員に伝えるようにしてください。

データ・コンシューマーがデータをどのように使用しているか（およびデータを使用しているかどうか）を監視します。正式または非公式に定期的に調査を実施して、そのデータに対する信頼性を測定し、提案を募ります。興味のあるコンシューマーには、ロードマップの内容を伝えます。

定期的な保守期間を設定して、チームで故障の理由をレビューし、改善策をブレインストーミングします。なぜそれらの問題が発生する可能性があるのかを問い、欠陥のない事後分析を実施し、調査結果を文書化し、修正プログラムを割り当て、どのように機能したかを監視します。

ここで理解したら、データSLAの編集と修正を行う準備が整いました。それを会社のWikiや他の場所で公開し、全員のコミットメントを確認し、自らもそれに従います。

データSLAは、自分自身とチームの誠実さを保つのに役立ちます。これは他者への公約として表現されているものの、実際には双方向の契約であり、特定のパラメーター内でデータを提供することに同意しますが、その代わりに人々の参加と彼らの理解が必要です。

データ・エンジニアリングでは多くの問題が生じる可能性があり、その多くはコミュニケーションミスが原因です。SLAを文書化することは、すべてを明確にするのに非常に役立ち、最終的な目標である組織内でのデータの信頼性を高めることができます。

データの健全性の問題を毎回早期に発見し、データSLAの不履行による損失を阻止します。高度なアラート機能と異常検知機能を活用してエンジニアを支援し、品質の問題を未然に防ぐ方法を学びます。さらなる詳細については、今すぐデモを予約してください。