データ資産システムを構築できない SRE は、優れた保守担当者ではありません。

1. データ資産の理解

1. データ資産 - エンタープライズ IT の価値

図

図に示すように、データ資産化が実装されていない場合、データは離散的な状態となり、データの生成と消費が統合されず、データの孤立やメリットゼロが発生しやすくなります。

データ資産化を構築した後、さまざまなチャネルからのデータを統合し、統合されたデータ ソースまたはデータ収集、保存、分析のためのプロセス リンクを構築し、対応するデータ構造、データ関係、および使用を統合します。出口。

運用データが収集および編集されると、独自の意思決定およびビジネス プロセスに使用できるようになります。

2. データ資産 - 運用と保守のシナリオを例にします

図

上の図では、シナリオを例として使用しています。資産のデータ分類を紹介する例。データ資産を理解するには、データ資産の 3 つの要素、つまりデータ型、データ形式、データキャリアの対応関係を理解する必要があります。

• データ タイプ: 運用および保守の特性に関する情報の説明

ビジネス指標レベルでは、SRE はトランザクション時間、トランザクション注文量、およびその他の情報に焦点を当てます。ソフトウェア レベルでは、SRE はユーザーの IP、インターフェイスの呼び出しステータス、その他の情報に注目します。インフラストラクチャ レベルでは、対応するネットワーク パケット損失率、メモリ使用率、または CPU 使用率に注目します。さらに深くなると、SRE は次のようなデータにさらに注目します。変更イベント、パイロット リリースの数、または緊急の変更。

• データ形式: データキャリアにデータが保存される形式

ログ、リレーションシップ、データのさまざまな表現形式に基づいて、対応する保存方法を選択します。監視データなど。たとえば、リレーショナル データベース、永続データベース、メッセージ キュー、ログ ファイルなど。

#データ キャリア: 運用および保守データの保存方法を提供します

3. データ資産 - SRE

# の価値を強化します## Picture取得した運用保守データをもとに、まず後述するCMDBなどの資産ベースのプラットフォームを構築します。これらのプラットフォームを活用することで、大量の運用・保守データを消費シナリオに応じて分解・管理し、資産化を実現します。

さらに、デジタル アセット プラットフォームを使用すると、SLO やキャパシティ管理プラットフォームなど、SRE の安定性に関連するプラットフォームを迅速に確立および改善できます。プラットフォームの確立が成功したら、引き続きデータの潜在的な価値を探索し、SRE が重視する安定性を向上させていきます。

2. データ ガバナンス方法論

1. 運用および保守のデータ標準が直面する問題

図運用 次元データの標準化が直面する問題は、ビッグ データ シナリオにおけるデータ品質の問題と似ており、主にデータ アイランド、低いデータ品質、不明なデータ、不十分なデータ サービス、データを取得するための長い開発時間などが含まれます。

これらの問題により、データ消費シナリオを迅速に繰り返すことが困難になり、ビジネス ニーズを満たすことができなくなります。人材、サーバーリソース、ミドルウェアリソースなどが不足すると、データ標準化構築は壊滅的な影響を及ぼします。

運用保守データは、ログやログ監視などのデータ保存方法が異なるなど、本質的に非標準的なデータです。そして、限られたリソースの中で最大限の精緻化と完全な標準化を行う必要があります。

DataOps、AIOps、その他のモデルやシナリオなど、業界で最近人気のある概念に関しては、成熟した包括的なデータ モデリング手法がまだ不足しています。

2. 運用および保守データのガバナンス モデルを確立する

運用および保守データをデータ資産に移行するには、ガバナンス方法、ガバナンス プロセス、テクノロジー プラットフォームの 3 つの部分に焦点を当てる必要があります。

図1) ガバナンス方法

マスター データ管理: SRE が重点を置くデータを定義して分割します。例えば、ホストやCLPなどのデータをマスターデータとして利用し、ライフサイクル管理を行います。

• 一般化されたメタデータ管理: これらのデータは、閉ループ レポート プロセスで CMDB に入力されます。これが一般化されたメタデータ管理です。 CMDB モデルで表され、対応するデータ サポートが上位レベルに提供されます。
• 主要なガバナンス リンク: データ標準、ガバナンスの品質、セキュリティ ベースラインの 3 つの側面に基づいて、ガバナンス リンク全体、つまりデータ標準、品質目標、変更全体のベースライン要件を整理します。
• 2) ガバナンス プロセス

ガバナンス プロセスには、戦略、構築、運用が含まれます。全体の構築という点では、自社の運営を支援するプラットフォームやツールを構築する必要があります。

3) テクノロジー プラットフォーム

テクノロジー プラットフォームを確立する主な目的は、ツールを通じて既存のデータと増分データをサポートすることです。

3. データ ガバナンスの重要な要素に焦点を当てる

データ ガバナンスの重要な要素は、組織の保証、システム構築、プロジェクトの実装、プラットフォームのサポートの 4 つの側面に主に焦点を当てています。

• 組織保証：人材課題を解決するために、メンバーの役割と責任分担を明確にします。専任のデータ ガバナンス チームは、製品、運用、研究開発の 3 つの役割で構成されています。
• システム構築: リソースへのアクセス、リソース開発、リソースデータモデル、その他の仕様など、標準化されたプロセスを構築し、その秩序ある実装を保証する必要があります。
• プロジェクトの実装: 全体的な特別管理の開始 データ ガバナンスは長期的なプロセスであり、単純なキャンペーンではありません。データ品質が標準に著しく達していない場合は、特別チームを設立し、モバイル アプローチを採用してデータ品質の問題を緊急に修復します。ただし、長期的なガバナンス手段を確立するには、データ製品に基づいて対応するガバナンス方法論を出力し、それらを製品化されたプラットフォーム手段に実装して、データ責任者がデータ ガバナンスを実施できるようにする必要があります。
• プラットフォームのサポート: プラットフォームの構築は主に、精密な測定、実行、ガバナンスの効率、その他の側面に焦点を当てています。

3. CMDB プラットフォームの構築

1. CMDB 構成管理ライブラリ

CMDB 構成管理オフィスは主に 4 つの側面に焦点を当てています。構築：基本的な登録技術台帳、詳細な自然属性、自然関係、および資源消費マップ。ビジネスに対応するモデルを階層的に構築し、自動化されたセンシングや標準化されたプロセスを通じて構成ダイナミクスをリアルタイムでプッシュする必要があります。

対応する構成には、コラボレーションを促進するための対応するビジュアル インターフェイスも必要です。最終的に、これらのデータは、APP または対応するオフライン シナリオを介したデータ消費シナリオを促進します。

2. ITIL 時代における CMDB の位置づけ - メタデータ センター

個人的には、CMDB はメタデータ センターであると理解しています。上の図に示すように、構成管理データベース CMDB は、組織、人材、意思決定、権限、プロセスなどに関連するデータをクリーンアップまたは組み立てます。

監視プラットフォーム、電子メール、テキスト メッセージ、運用および保守データベースなど、下位層のドッキング プラットフォームが多数あります。データが集まった後は、上位層（サービス管理層に相当する基盤）にデータが引き渡され、データの出力や、資産管理や構成管理などの一連のサービス、プラットフォームの構築が行われます。

3. 新時代における CMBD の位置づけ - アプリケーション中心

、

アプリケーション中心で組織とプロジェクトの連携を実現人間関係とアプリケーションに拘束されます。

アプリケーションの実行プロセス中に、対応するリソース (サーバー リソース、構成センター、可観測性インジケーターなど) が使用され、企業の組織構造に従って従属関係が形成されます。パースペクティブはマイクロサービス パースペクティブを参照して、リソースとその関係、つまりアプリケーション トポロジや物理トポロジを含むトポロジを形成します。

4. アプリケーション中心の CMDB の利点

図

5. 実行時のアプリケーションとメタデータ センターの関係

図

上の図は、基本的なテスト機能のメタデータ、Paas 関連データ、運用データを上位層に提供する CMDB を示しています ( CIプラットフォーム、CDプラットフォーム、サービス運用プラットフォーム、サービス運用プラットフォーム）のうち、図に示す下位のプラットフォームがサービスリソースサポートプラットフォームを構成します。

この種の構築の利点は、アプリケーションの作成、アプリケーションの実行時間 (ビルド、リリース、拡張、課金)、アプリケーション後のリソースのリサイクルなど、アプリケーションのライフサイクル全体に対する基本的なデータ サポートを提供できることです。オフラインです。

6. CMDB 構築の 4 つの主要な段階

図

上の図は、CMDB 構築の 4 つの主要な段階を示しています。現在、サービス志向からバリュー志向への第4段階のプロセスにあります。

部門指向:

• CMDB システムの有無に関係なく、実際には CMDB 要件があり、構成情報は部門に基づいて維持されます。
• 情報は孤立しており、タイムリーではないため、完全性と正確性は保証できません。

データ指向:

• 全部門が気にするデータと相互関係をCMDB管理に一元管理し、構成管理プロセス体系を構築;
• 消費シナリオが不明確で消費価値にアンバランスが発生そして生産コスト。
• ステーション B のデータ生成コストはそれほど高くありませんが、構築するデータ消費製品が大量にある、またはビジネス側がシーン要件をカスタマイズすることが多く、CMDB をカスタマイズして関与する必要があります。ビジネス側の要求を実現するための開発。 CMDB には 300 を超える OKACI があり、保守が不便です。

シナリオ指向:

• ローカル データの標準化の程度と高精度;
• 単一使用シナリオのため、全体的な消費価値は次のようになります。高くはなく、製造コストは比較的高い。

サービス指向:

• データ提供サービスは、自動化、監視、ワークフロー管理、運用保守分析など、日常の運用管理と制御をサポートします。
• 多様なデータの生産/消費方法を導入し、消費価値と生産コストのバランスを徐々に整えます。

価値志向:

• CMDB は、サービス容量管理や可用性管理などのサービスとビジネス開発を完全にサポートし、IT 運用と保守の基礎となります。
組織のIT管理レベルの向上を積極的に推進します。

7. CMDB モデルの構築方法

図

データ型の定義: ホスト、スイッチなど、アプリケーション、アプリケーション構成ファイル、構成担当者は要求を受け取った後にこれを調査します。
• データ コア属性の定義: ホストを例に挙げると、IP、シリアル番号、コンピューター ルーム、クラウド ベンダーなどのリソースのコア属性をレポートまたは収集する必要があります。
• データ モデルで直接関係を構築します。包含関係、依存関係、実行関係など、リソース間の対応関係を整理して、その後のリソース トポロジの作成を容易にします。たとえば、アプリケーションがあるデータ型を使用し、ホストが別のデータ型を使用する場合、アプリケーションは実行時にホストに依存し、ホストがアプリケーションを形成できます。
• 消費シナリオの確認: 消費シナリオの確認とは、データがどの段階で利用されるのかを確認することを意味します。クラスターのデプロイメントに使用する場合は、アプリケーション ディメンションで関連するデプロイメント、または対応する運用および保守タスクを実行する必要がある場合があります。
• データ仕様の確立: ライフ サイクル (作成、運用、展開まで) は何ですか?プラットフォームはデータステータスの変化をどのように検出しますか?

要約すると、データのライフサイクル全体を開始点として捉え、属性を決定し、関係を明確にし、消費シナリオを明確にし、自動化されたプロセスを使用してデータのリアルタイム性と正確性を確保する必要があります。データ。

1) モデル関係の定義

図

2) CI 関係デモの例

#Picture

3) CMDB 実装フレームワーク

現状評価: 現在 CMDB プラットフォームはありますか?このプラットフォームはどの程度確立されていますか?このデータの品質は何ですか?組織構造や技術構造はどのようなものですか?今後の立ち上げプロセス中に必要となるリソースのステータスはどうなっていますか?
• プロジェクトの開始: 開始時に、CI モデルとアクセス リソースの関係、その後の使用シナリオ、データ ソース、および CI 利害関係者を定義する必要があります。
• データのインスタンス化: データのインスタンス化の検出を実行すると、テスト環境が構築され、CI モデルまたはインスタンス化されたデータがインポートされます。
• データ検証: UG 環境では、データのレポートと実際の出力を比較して、データ品質が基準を満たしているかどうかを確認します。データ品質が基準に達したら、本番環境のデータの状態を検出するために本番環境を構築する必要があります。
• データ シナリオ消費: データが本番環境に投入された後、データ消費シナリオを確認する必要があり、運用プラットフォームまたは SRE プラットフォームに接続する必要があります。

4) 最初の標準化

最初の標準化とは、実装前のすべての事項が標準化を中心に構築されることを意味します。これらには、計画要件、プロセス要件、組織要件、プラットフォーム要件などのいくつかの強力な要件が含まれます。

仕様要件:

CMDB プラットフォームの役割と他のビジネス システム間の関係を明確に定義します。
• リソース管理プロセス、責任者、およびリソース管理プロセスを明確に定義します。責任 プラットフォーム;
• リソースと逸脱管理方法のベースライン標準を明確に定義します;
• サービス ビジネス シナリオの観点から構成管理機能を計画および構築します。

プロセス要件:

• リソースのステータスを正確に反映できます;
• すべてのリソース情報とリソース間の関係を完全に含めることができます;
• 唯一の信頼できるグローバル データ ソース;
• ユーザーとシステムは、データを便利に、タイムリーに、効率的に取得できます。

組織要件:

• 統一された構成管理機能を構築する組織を確立します;
• 各ビジネス チームは、構成の使用と改善に対して明確な責任を負います;
• 構成管理の議論、最適化、要件の収集のためのメカニズムを形成します。

プラットフォーム要件:

• 自動構成検出と自動メンテナンスを段階的に実現;
• リソースのステータスと構成変更のリアルタイム追跡;
• モデルは柔軟で、ビジネス ニーズに応じてリアルタイムで拡張および調整できます。
• 構成の視覚化により、リソースの問題の分析と迅速な特定がサポートされます。

5) 閉ループ データ ライフ サイクルを作成する

まず、アプリケーションの属性を決定します。アプリケーションの属性には、アプリケーションの中国語名と英語名、アプリケーション レベル、一意の ID、属性のビジネスおよびビジネス ドメインなどが含まれます。属性の内容は主に個人の定義に依存します。アプリケーションを定義した後、アプリケーションは他の CI との関係を持つ可能性があるため、さらに分類する必要があります。

2 番目に、アプリケーションのプロパティの責任者を明確にします。アプリケーションには、対応する責任者、研究開発、SRE などが存在します。アプリケーションの構成と変更のレビューを確実にするために、アプリケーションの構築、リリース、変更、およびユーザーに関するその他のアクションに対応するプロセスが用意されています。

最後に、スケジュールされた収集タスクを実行して、アプリケーションの最終的なデータの正確性を確認します。

6) 構成の自動検出と更新を促進する

上図で言及されている「リソース」は、サーバー リソースなど、従来の意味でのリソースです。これらのリソースは特定の方法で収集され、最終的にリソース管理プラットフォームに報告されます。

• 手動メンテナンス シナリオを排除するための完全な構成収集機能を構築します。
• リソースとアプリケーションの構成情報を自動的に検出します。
• ドッキング プロセス、管理プラットフォーム、および機器を取得します。構成ステータスをリアルタイムに更新する;
• リソース構成と使用仕様を確立し、CMDB を介してコンプライアンスチェックを実施する;
• 構成消費クローズドループの実現を促進し、消費を通じてデータの信頼性を自動的に維持するフィードバック。

以上がデータ資産システムを構築できない SRE は、優れた保守担当者ではありません。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。