Didi の顧客サービス事業は、インデックスデータを中心とした事業運営が強みです。これらの指標の中には、戦略目標を達成するためのOKR指標や、パートナーとの決済のための決済指標を達成するための指標もあり、データの安定性はカスタマーサービス事業全体の運営にとって極めて重要です。
データ障害ガバナンスの構築目標の解釈
着信回線量、キューイング量、ピックアップ率、到達率、その他の指標を含むリアルタイム指標。解決率、クリアランス率、アップグレード率、満足度、サービス品質、その他の指標を含む遅延指標。
過去 2 年間、当社は事業の継続性を確保するために、安定性の構築に多大なエネルギーを投資してきました。全体の構築は 3 つの段階に分かれています。
第 1 段階:障害を中心とした安定性の構築一連のエンジニアリング能力、プロセス メカニズム、および構築方法論が、システム障害を中心に、発生と影響、最終的な障害数と最終的な数の削減を中心に、イベント前、イベント中、イベント後に体系的に導入されています。故障時間が大幅に短縮されます。
第2段階：ビジネス中心の安定構築。ビジネス特性を中心に、ビジネスの実態から出発し、組織横断的な水平専門チームを設置し、ビジネスとテクノロジーの結びつきに存在する安定性の問題を解決し、テクノロジーを実現する。事業継続のために、グローバル最適な を保証します。
第 3 段階:能力開発の標準化. 安定性構築作業の継続的な深化に伴い、組織は安定性チームの作業に対する要件がますます高まっています. 純粋に技術的な安定性作業からセキュリティコンプライアンスをカバーするようにアップグレードされました. コスト削減と効率の向上その他関連する業務内容。スポーツ型の作業投入を避け、安定した作業を低コストで持続可能なものにするために、自動化ツールの改善に注力して効率を向上させ、持続可能な運営メカニズムを構築し、最終的にはチームの安定した作業文化を形成していきます。
昨年、システム安定性構築の第一段階を完了し、リアルタイム指標の保証を形成しました。データ安定性の構築は作業の第 2 フェーズに属し、その作業内容はビジネス特性と密接に関連しており、主にビジネス ラグ指標の作成と使用における安定性の問題を解決します。システムの安定性はデータの安定性の基礎であり、システムの安定性が適切に行われて初めて、データの安定性の基礎が得られます。
データ安定性の構築を適切に行うために、まず次のことを行いました。
データ障害グレーディング基準の策定とデータグレーディングの実施
1,000 を超える指標がありますが、リソースが限られているため、すべてをカバーすることは不可能です。データ障害のグレーディング基準を確立することで、どのような種類のデータをどの程度まで保護する必要があるかが決まります。これは、障害がどのような種類の影響を与えるのか、どのようなレベルが障害の影響に対応するのか、どのような種類の指標の安定性に対する要求が高いのかを明確に定義します。
このステップの後、データ分類のために保存する必要がある指標の種類には、OKR 指標、決済指標、その他の指標が含まれることが明確になりました。その中で、OKR指標は作業効率の側面、サービスの品質の側面、安全の側面、リスクの側面をカバーします。
ターゲットの解体
データインデックスのグレーディング基準を確立したら、データの安定性を確保する方法を検討する必要があります。
安定性の構築には、研究開発、データウェアハウス、データの三者による共同構築が必要であり、三者が共同でビジネスを提供するため、一定割合の障害を相互に共有し、安定性の目標を三者に解体する必要がある、誰もが協力できるように。
明確なプレースタイル
目標を分解した後、目標を達成するための具体的な原則、計画、行動を含め、関連するプレースタイルとリズムを明確にする必要があります。具体的な計画はイベント前、イベント中、イベント後を対象としており、失敗の数とレベルを減らすことを目標としています。対応する方法論は、ターゲット システム、人材の意識、人材の質、システム ツールを中心としています。
技術系の学生の多くはシステムの安定性についてよく理解していますが、データの安定性の構築には原理的にまだ多くの違いがあります。
データ障害に対して最も重要なことは何ですか?
答えは、まず時間です。影響時間には、データ影響の総量とデータ修復期間の2 つのポイントがあります。
システム可用性障害とは異なり、データ障害で最も重要なことは、データを遡及的に修復する時間です。これは、影響を受けたデータを迅速に回復して追跡し、データが使用される前にデータ回復を完了する方法です。
これには、イベント前、イベント中、イベント後にいくつかの保証が必要です。
事前の保証：データの操作やデータベーステーブルの変更を行う前に、研究開発は関連するODSや主要指標に影響を与えるかどうかを把握しており、合理的な評価の後、データ指標への損害の可能性を回避できます。
イベント時の保証: アラームの改善と主要なデータベース テーブル フィールドの詳細な許容範囲を実行します。問題が発生した場合、問題を迅速に発見、特定し、問題を解決するために迅速に介入することができます。早期に発見されれば、影響を受けるデータの量は少なく、修復プロセスは非常に速くなります。
事後保証:すぐに使える修復ツールが用意されているか、データのバックトラッキングを支援するために再利用可能な冗長データと修復スクリプトが保存されています。全体的な障害データのバックトラッキング効率が大幅に向上し、データ タイプの障害の影響がさらに軽減されます。そして失敗のレベルを下げる。
したがって、上記の保証原則に基づいて、準備作業は、イベント前 (3 者間コラボレーション SOP、特別なチェックリスト自動化メカニズム)、プロセス中 (コア データベース テーブル、フィールド監視およびアラーム カバレッジ)、およびイベント後 (データ冗長性計画、迅速な修復テンプレート）は、予防に重点を置き、バックトラッキングの効率を向上させます。
データ障害の評価基準
この部分は現時点では比較的複雑であり、多くの学生からの質問のほとんどがここに表示されますが、障害評価基準を策定することが重要であることは多くの人が知っていますが、実際には、シンプルで理解しやすく実行可能な基準を策定することは困難です。
最初に行うことは、データを分類して、さまざまなレベルのデータにさまざまなレベルのリソース保護を提供できるようにすることです。
インジケーターは、OKR インジケーター、決済インジケーター、および共通インジケーターの 3 つのカテゴリに分類されます。3 種類の指標はデータエラーに対する感度が異なるため、OKR 指標が閾値点に引っかかった場合、その影響は比較的大きく、OKR の達成に影響を及ぼします。決済カテゴリーは主にサプライヤーとの決済です。
障害レベルに影響を与える要因: 主に時間、問題の発見から問題の修復までの時間。
事故による影響日数の計算
データウェアハウス側の特性上、データは時間で区切られており、例えば、ある日のデータは影響を受ける時間が短くても、効率は保証されます。
インジケーターとODSテーブルの関係
この部分は、研究開発の学生が最も多く参加し、データ障害のレベルを軽減するための最も重要な出発点です。
インジケーター システム全体には 1,000 以上のインジケーターがあり、データ血液分析を通じて、保護のために重点を置く必要があるデータベース テーブルとフィールドを見つけることができます。インデックスの血液関係に基づいて、コア ライブラリ テーブルと ODS テーブルのマッピング ドキュメントを見つけます。
研究開発の焦点は、ODS テーブルの前にデータ生成リンクの安定性と信頼性を確保することであり、データ ウェアハウスの学生は、データ使用リンクの安定性と信頼性を重視し、ODS データのバックトラッキング時間をさらに短縮します。
マイニングデータの障害ステータス
上記では、データ安定性構築の原則的な内容をいくつか紹介しましたが、特定の作業については、依然として現状に戻って特定の問題を検討する必要があります。Heshucang と Datamate は歴史的な欠陥の目録を作成しましたが、次の問題がより明らかです。
研究開発における指標とODSに対する注意と理解の欠如
指標とODSテーブルに責任者がいない
研究開発、データ ウェアハウス、データ関係者には効果的なコラボレーション メカニズムが欠けています
重要なインジケーターのアラームが十分に細かくなく、カバー範囲も十分ではありません
障害処理プロセスに SOP ガイダンスが欠如しており、多数の修復エラーややり直しが発生しています
迅速な遡及データ ツールが手元にない
研究開発における指標とODSに対する注意と理解の欠如
これまで、研究開発の学生は主にデータベース レベルのデータに注目し、データがどのように使用されるか、データが保存された後にどのような指標が生成されるかには注意を払っていませんでした。インジケーターの作成にはより多くの注意が払われており、インジケーター生成のためのプリリンクについての理解が不足しており、多くのインジケーター生成ルールの策定は単なる「一方的な言葉」に過ぎません。
研究開発、データ ウェアハウス、データ製品の 3 つの役割を組み合わせると、データ生成プロセスは次のように分解できます。
研究開発側：主にODSに対応するコアデータベーステーブルデータ生成リンクの信頼性に重点を置き、データの正確性を保証し、責任を負います。
データウェアハウス側：ODSデータが異常な場合のバックトラッキングに主に焦点を当て、データ指標生成の信頼性を確保し、責任を負います。
データ面: 指標が正確に生成され、責任を負うかどうかに主に焦点を当てます。
人的リソースが限られているため、初期段階では OKR、決済、リスク指標などの主要な指標を再保険するためにリソースを集中しました。元のシステムの安定性の監視と警報に基づいて、データインデックス次元の監視と警報が強化されています。
指標とODSテーブルに責任者がいない
研究開発者がコアデータベーステーブルとODSに対して責任を負うべきであることを確認した後、ODSを請求する特定の人物を線引きし、責任者を特定することができます。データ作成や利用リンクで発見された指標に問題があった場合、ODSリネージを通じて対応担当者を迅速に見つけてフォローすることができます。
過去には、多くのデータ障害が発生した後、対応する研究開発所有者を見つけるまでに 2 か月かかる場合がありました。現在、責任はその人にあり、問題が発見された後、その日のうちに研究開発の所有者が見つかり、修復計画が作成されます。したがって、人々に責任を割り当てるという問題は単純なように見えますが、その利点は非常に大きいです。
システム所有者にとって、エンジニアリングではシステムの安定性の設計だけでなく、対応するいくつかのコア データベース テーブルとフィールドの安定性の設計も考慮する必要があります。
主要指標モニタリングの対象範囲をさらに改善し、システム所有者の懸念コストを削減するために、プラットフォームは、早期検出と早期介入を実現するためのコアODS指標収集およびモニタリング用の一連の自動化ツールを提供します。
研究開発、データ ウェアハウス、データ関係者には効果的なコラボレーション メカニズムが欠けています
研究開発、データ ウェアハウス、およびデータは異なるチームに属しており、以前は連携が緊密ではなかったため、データ障害の処理時間がある程度長くなってしまいました。共同建設後、三者間の協力メカニズムが明確になり、三者の主要責任者は同じグループに属し、重要な情報はグループ発表に保管されます。研究開発やデータ指標の変更については、社内通信ソフトのロボットを通じて自動通知・連携を実現します。
主要インジケーターのアラームが十分ではない
研究開発前に構成された監視アラームは、システム可用性インジケーターを中心にのみ構成されており、データベース テーブルとフィールド データの精度をカバーする監視次元はありません。
データ ウェアハウスとデータ側の以前の監視アラームは不正確であるか遅すぎます (T+N、N は 30 日の場合があります)。問題の発見が遅すぎると、データの遡及コストが高くなるため、ログウェアハウスとデータ側の監視とアラーム検査を強化し、T+1の達成を目指し、問題をできるだけ早く発見する必要がありますそして問題に迅速に対処します。
システム所有者は、主要なデータベースのテーブルとフィールドを監視し、データが正しくない、不正確、または失われた場合にアラームをトリガーする必要があります。
追加できるアラーム ルールには次のものがありますが、これらに限定されません。
フィールドの非 null チェック
フィールドタイプの変更
DDL の追加および削除フィールドの変更
キーテーブル指標の前年比推移
時刻タイプの形式確認（タイムスタンプまたはyyyy-MM-dd）
システム間の RPC データ一貫性の比較
過去のデータの調整、前年比
フィールドコンテンツのルールが変更され、通常のマッチングが行われます
BCP+ ローコード プラットフォームを通じて、システム所有者はデータベース テーブルのフィールド ルールを入力し、binlog に基づいて監視し、例外が発生した場合にアラームをトリガーします。
TCC のようなインターフェイスを介した主要な指標の調整、タイムリーな検出、およびデータの迅速な修正。原則として、偽陽性は偽陰性よりも優れており、同じ要件がデータ ウェアハウスとデータ側システムにも適用されます。
障害処理プロセスに SOP ガイダンスが欠如しており、エラーの修復とやり直しが発生する
ODS フィールドの問題が複数のインジケーターに影響を与える場合がありますが、一部は ODS インジケーターであり、一部は通常のインジケーターです。
どのインデックスを最初に修復するかは、最終的な障害評価に影響を与える可能性があり、または障害修復前に正確な情報を取得できなかった場合に二次被害が発生する可能性があります。
トラブルシューティングのコラボレーションのための SOP を確立し、社内通信ソフトウェア ロボットと組み合わせて、イベント中およびイベント後の操作ガイダンスをカバーし、修理エラーややり直しの数を減らします。
インジケーター生成リンクが変更された場合 (DDL タイプの操作が開発され、データ側でインジケーター レベルがアップグレードされた場合)、関連する利害関係者に通知する必要があります。
標準的な障害緊急時の基準と手順を整理し、各段階の責任と関係者を明確にする。
迅速な遡及データ ツールが手元にない
データの信頼性を保証するためのいくつかのツールを構築し、いくつかの無関係なリンクの効率保証を改善します。人手に頼る問題や既存の遡及ツールの能力不足をツールの改善で解決します。
データ取得リンクの強化:元の public.log ログ ファイル データ レポート スキームの変換、およびデータが失われず、複製されず、追跡できることを保証するデータ バス (ログブック) の強化が含まれます。
データ再生によりデータ修復効率が向上:コアリンクデータ再生機能を構築リンク内でデータ損失が見つかった場合、データ再生により異常データを迅速に修正し、データ修復効率を向上させます。
番号修復スクリプトを再利用して、間違った番号修復の発生を防ぐことができます。一部の修復番号テンプレートとスクリプトは高頻度のシナリオに保存されており、修復リンクはテンプレートを置き換えて、関連する修復番号スクリプトを再利用して、エラー修復のリスクを軽減できます。修理時間を短縮し、数の効率化を実現します。
上記のプロセス、規範、標準は、ツール自動化の助けを借りて改善され、正確になります。
建設計画と工程
実施前、実施中、実施後の原則
要約すると、データ型障害の場合、イベント前、イベント中、イベント後の主なアクションは次のとおりです。
事前に：どの指標が主要な指標であるか、どのODSテーブルが主要な指標に関連付けられているか、関連するODSテーブルの責任者、およびリンク全体および複数のリンクの協調SOPを明確にし、不確実な状況を決定論的な合意に変えることができます。
継続中: きめ細かい監視とアラーム範囲を適切に実行します。多くのデータ インジケーターは T+N 形式で生成されます。監視とアラームの設定には慣性があり、データが使用されると判断された場合にのみアラームが発行されます。この時点では、障害の影響はすでに発生しています。現在の原則は、「見逃した陰性よりも偽陽性を優先する」ことであるため、ODS ライブラリ テーブルに最も近いシステムは十分に監視されるべきであり、詳細かつ実用的である必要があり、定期的な検査は偶然に行われるべきではありません。
その後：データ障害に関しては、迅速に番号を修復することが最も重要で、「5分損切り、2週間で番号を修復」というケースも多くありますので、ツールを手元に用意しておくことが非常に重要です。この観点から、「ディスク、最適化、構築」の3つのレベルからスタートし、既存のデータ作成・データ処理ツールの改良を「棚卸し」、既存ツールをより便利で使いやすくする「最適化」、「構築」を行います。 「不足しているツールを削除し、手動介入の度合いを減らし、データ回復リンクを短縮し、効率を自動化します。
継続運用中
クリアデータとインジケーターの変更の双方向通知:
データ指標が変化したときに研究開発に通知する
研究開発は、DDL 操作時にデータを通知するなど、データを変更します。
新しい OKR インジケーターが生成され、メールで通知されます
コア インデックス (ODS マッピング ドキュメント) を中心に整理するインデックスを作成します。データ変更やフィールドのオフライン化など、ドキュメントに含まれるキー データベース テーブルのフィールドが変更された場合、操作前にグループ内で同期と公開を行う必要があります。 、および @関連データ クラスメイト よく知られています。
通知がない場合は、フォローアップレビューで業務プロセス標準の問題点が調査され、社内のIMツールロボットがツールレベルの最終ラインとして使用されます。
規則や規制に従わない人を罰する賞罰メカニズムを確立し、良い事例に対して標準プロセスに従う個人には報酬を与える賞罰メカニズムと定期的なレビューを通じて、データ安定性構築の文化的形成を実現します。気がついた。
建設効果
生産と研究、データ ウェアハウス、データ、およびビジネスの共同の取り組みにより、タイムリーな問題の発見、完全なトラブルシューティング、グレーディング基準、障害回復メカニズム、自動化ツール、綿密な運用を通じて、データ障害の数とデータ障害が減少しました。今年の取り扱いは期間が大幅に短縮されました。
故障件数は前年比42%減少
障害修復の適時性は前年比 134% 向上しました
指標に見られる明らかな利点に加えて、隠れた利点もいくつかあります。
完全な仕組み構築により、三者の責任範囲が明確になり、判断、透明性の高い伝達、配分などの問題が規制され、コミュニケーションの効率が向上し、倉庫内の学生の幸福感が向上しました。改善されました。
これは、典型的な障害の処理プロセスを明確にし、主要なリンクと主要な責任者をカバーし、さらなる文化形成と自動化効率の向上のための優れた基盤を提供します。
要約する
これまでの研究開発学生の障害対応の世界観は、システムの安定性保証をベースに構築されており、損失を迅速に阻止することに誰もが慣れており、小さな障害が大きな障害に発展することを防ぐことができます。しかし、この世界観は、データ障害の処理に関してはあまりうまく機能しない可能性があります。
データ障害にはそれぞれ特有の特徴があります。システムの安定性と比較した最も単純な違いは、データ障害発生後のストップロスアクションは、データ障害回復プロセス全体の始まりにすぎないことです (ストップロスは 5 分間、修復には 2 週間かかります)。
データ安定性構築の世界観の 2 番目の部分は冗長性を持たせることです。イベント後のデータ修復のためのデータ冗長性であっても、障害発生後の修復スクリプトの再利用であっても、それは冗長性の一部です。
データ安定性計画は迅速かつ正確である必要があり、二次被害の可能性を軽減する必要があります。そのためには、計画スクリプトが正確で信頼性が高く、定期的にレビューされる必要があります。
障害発生後のデータの遡及修復プロセスが、作業の実際の大きな部分です。この段階の作業負荷は重く、簡単ではありません。多くの肉体労働であり、誰もが惨めになります。標準化されたプロセス + 自動化により、幸福度が向上します。
「平時ではより多くの汗をかき、戦時ではより少ない出血をする」という原則に沿って、次の 4 つの要件があります。
より事前に投資する: 主要なデータ指標に影響を与える可能性のある特定の需要や技術的変更アクションが特定された場合は、運用前に完全な評価を実施するために関連する利害関係者を見つけてください。あまり面倒なことはせず、危険を冒さないでください。 。
グローバルな視点を持つ: データ学習者がインジケーターの生成ルールを決定するとき、視点が非常に限定されている場合があります。対応する値を持つテーブルを見たとき、それを使用しますが、この値が信頼できないことは知りません。これを使用することは保証されず、不必要な技術的負債が発生するため、その後のビジネス システムの継続的な反復が妨げられます。良い方法は、研究開発の学生と座ってよく話し、世界的な観点からこの指標がどこに最も適しているかを確認することです。
解決策は整っています。監視やアラームのメカニズムなどのさまざまな安定性要件を適切に実装する必要があり、コーディングの形で独自のシステム リンクに統合する必要があります。レビューの結果、フィールドは値を持つ必要がある、特定のデータ型に準拠する必要がある、特定の範囲内のフィールドに属している必要があるなど、実装が適切であれば多くの失敗を回避できることがわかりました。非常に簡単にコード化された方法でコードに組み込まれます。多くの場合、実行が不十分なために失敗が繰り返されます。
悲観主義者は正しい:「楽観主義者が成功し、悲観主義者が正しい」ということは誰もが聞いたことがあるでしょう。安定とは、収益を維持することを意味します。プログラム設計においては、「悲観的」な姿勢で考え込むことは悪いことではなく、守りのプログラミングをして目的を達成することは良いことです。