データセンター運用（データセンター運用の実務経験）

データセンター運用の実務経験

データミドルプラットフォームをうまく運用するには、運用担当者、ビジネス担当者、開発チームなどと切り離すことはできません。その核心は、データミドルプラットフォームの価値実現を中心に、運用のあらゆる側面を推進することです。ここでは、実際の導入プロセスで蓄積された経験と教訓をいくつか紹介しますので、参考にしてください。

データミドルプラットフォームの運用プロセスは、複数の部門の連携・協力を必要とするため、単一部門で開始すると対応が困難となり、結局は棚上げになってしまうケースが多くあります。したがって、各部門の担当者が行動を起こす前に、データセンターに対する統一された正しい理解を伝えることが最も重要です。

データセンターのコア資産部分に関して、まず全部門に明確にしておくべきことは、あらゆるものがデータで記録、表現、表示できることです。ビジネスの開発、評価、最適化のすべてにおいて、データ レコードがあるかどうかを考慮し、分析、表示、レポートにデータを使用する必要があります。データは、企業の経営課題や経営状況を客観的に評価できる唯一の指標です。誰もがデータの結果を尊重し、データ指標をガイドとして使用して問題を説明し、データ主導の運用を実践するアプローチを形成する必要があります。データに対する認識を全員の心に根付かせることによってのみ、その後の協調行動においてできるだけ早く合意に達し、不必要な論争や試行錯誤のコストを回避することができます。

第二に、データ、データ テクノロジー、データ資産、データ プラットフォームが問題を解決する能力を持っていることを誰もが正しく理解する必要があることを明確にすることが重要です。これらは単なるリソース、ツール、および機能です。最終的に、価値を生み出すには、組織の力を通じて、柔軟かつ持続的に、そして十分に活用されなければなりません。したがって、データ プラットフォームはすべてのビジネス上の問題を解決できるわけではなく、クラウド コンピューティング、ビッグ データ、人工知能の代替としての役割を過度に神話化すべきではありません。企業が考えるべきことは、データ プラットフォームを購入したり構築したりすることで自動的に問題が解決することを期待するのではなく、これらの高度なテクノロジーを自社のビジネスや経営にどのように適用するかということです。

最後に、データ資産の運用に関連する役職に就くすべての人は、自分の職務上の責任と他の役職の責任を明確に理解している必要があります。技術担当者の職務は、運用・保守プラットフォームの構築、データ資産の開発・生成、データサービスとデータアプリケーションの安定性の保証を提供することです。しかし、ビジネスの観点から問題について考えることも学ばなければなりません。技術者が開発した結果は、ビジネス担当者が使用した場合にのみ役立ちます。そうしないと、倉庫に山積みになってしまい、長い時間が経ってから処分することになります。ビジネス担当者の職務は、データ要件を提案し、データ資産を最大限に活用し、タイムリーに最適化のフィードバックを提供することです。一方、ビジネス担当者はデータテクノロジーの能力の限界を理解し、データがすべての問題を解決できると想定することはできない。

すぐに問題を解決できます。同時に、技術者と一定レベルのコミュニケーションが取れるように、データ理論も学ぶ必要があります。

データの視点を確立するプロセス全体において、企業の組織構造は上から下までそれを注意し、認識し、実行する必要があります。多くの実践を通じて、データ資産の運用プロセスには多くの新しい作業が伴い、作業負荷も小さくないことがわかりました。そのため、現場のスタッフが自発的に協力することは難しく、抵抗や拒否反応が出ることもあります。そのため、企業のCEO、CTO、CIOなどの上級管理職から、企業の中核経営層、中間管理職、第一線の従業員に至るまで、認識と統一意識を確立する必要があります。データ作業に付けられる重要度は、実行とよりよく連携するために、作業目標および作業パフォーマンスと関連付ける必要があります。

前述のように、異なる種類の業務は相互に理解し、互いのビジネス知識を統合する必要があります。ただし、ある段階で優先順位の判断や優先選択を行う必要がある場合は、純粋なビジネスニーズではなくシナリオを優先順位付けすることをお勧めします。シナリオ分析はビジネスニーズから生まれますが、ニーズは抽象化する必要があります。科学技術は生産力ですが、生産に役立つことが前提条件です。生産に役立たない科学技術は、教科書に載っている理論的な知識にすぎません。したがって、すべてのデータの収集、クリーニング、処理、およびサービス指向のプロセスには、ビジネス ニーズに基づいてシナリオを抽象化し、最終的にビジネス上の問題を解決するという明確な目的が必要です。

したがって、データ技術者は、必要なシナリオ要件を抽象化しながら、既存の一般的なデータ作業に基づいて、ビジネス知識、ビジネス担当者、およびビジネス運用に関する理解を深める必要があります。データ資産が価値があるかどうかは、それがビジネスで使用されているかどうかによってのみ判断できます。企業がそれらを活用できるかどうかは、ビジネス担当者自身の学習のみに依存するのではなく、データの概念、データ機能、およびデータ製品を、ビジネス担当者が理解して操作できる方法とレベルに変換することによって決まります。

ビジネス担当者がデータ資産を理解し、確認できるようになるには、まずデータ アプリケーション ケースを成功に導くための運用チームと技術チームの支援が必要です。これにより、データ使用の完全なクローズド ループ プロセスを理解し、データ価値の威力を実感し、データ資産に対する関心と信頼を育むことができます。

ビジネス担当者にデータ資産を自ら表示、選択、使用する方法を教える場合でも、技術チームがデータ資産をビジネス用のデータ アプリケーション システムに直接カプセル化する場合であっても、最終的な目標は、ビジネス担当者がデータ アプリケーションを効果的に実践できるようにすることです。運用担当者は、トレーニング、コンサルティング、典型的なケースの運用などを通じて、ビジネス担当者がデータ資産の役割を個人的に理解し、継続的な使用に関心を抱くことができるように、データの適用によるビジネス効率や収益の向上を支援する必要があります。そうして初めて、すべてのビジネス プロセスが徐々にデータに結び付けられ、データを使用する作業習慣が身に付くようになります。最初からデータドライブを完全に切り替える必要はありません

このアプローチは、実装するには負担が大きすぎて時間がかかりすぎることが多く、ビジネス担当者に多くのトレーニングと変革を必要とし、熱意と自発性の育成にはつながりません。データ資産を真に運用するには、行政命令や技術蓄積だけに頼ることはできません。重要なのは、ビジネス担当者がデータ資産を学習し、積極的に活用できるようにすることです。

ミドルプラットフォームの運用においては、データ管理部門（以下、「データ部門」という）と業務部門の2つの中核連携部門が存在します。緊密に調整された協力関係により、中間プラットフォームの価値を最大化できますが、そうでない場合は行き詰まりにつながる可能性があります。データ資産の最適化プロセスを例にとると、以前は、企業におけるデータ資産の最適化の責任部門はデータ部門であり、データ部門がデータ資産の最適化の反復を開始していました。この最適化の反復がデータ処理、生産、研究開発の範囲に限定されている場合、データ部門はそれを推進し、効果的に完了することができます。しかし、最適化の反復に、元のデータ収集部分やデータ資産の使用状況のフィードバックなどの部分が含まれる場合、業務部門の協力が必要になるため、作業の遂行が困難になります。さらに、データ資産の使用プロセスに関する情報が不足しているため、データ部門がデータ資産の品質を管理および最適化したいと思っても、どこから始めればよいかわからない場合があります。したがって、資産最適化の最も適切な推進者は事業部門であるはずです。ビジネス担当者がデータ資産の安定供給やより高品質なデータ資産を緊急に必要とする場合にのみ、データ技術サポート チームに自発的に働きかけ、データ資産の最適化を共同で完了させます。そして、データの使用状況を追跡し、データの使用状況に関する情報フィードバックを提供し、新しいデータのニーズを整理する作業を完了するために協力します。

もう 1 つの重要な考慮事項は、企業ではビジネス部門が企業の収益センターであることが多く、データ部門が企業のコスト センターであることが多いため、ビジネス部門の発言力がより大きくなるということです。資産最適化プロセスに人員投入、機器調達、リソース割り当てなどの問題が含まれる場合、ビジネス部門はより広範囲の割り当て権限を持ちます。

したがって、ミドルプラットフォームの仕組みを最適化するプロセスにおいて、各部門の熱意を結集し、緊密に連携するために、ミドルプラットフォーム運用チームは、リソースを割り当てて価値を促進するための一連の運用メカニズムを設計し、企業のすべての部門がデータミドルプラットフォームの最適化の結果に対して共同で責任を負えるようにする必要があります。

ビジネス、製品、研究開発、データチーム間の協力の図

ビジネス チームは、対応する製品チームに特定の要件を提示します。要件を分析した後、製品チームはビジネス プロセスを整理し、要件をビジネス側の要件とデータ側の要件に分解します。前者は、データ自体とはあまり関係のない、プロセス関連、情報アーキテクチャ関連、フロントエンドのプレゼンテーションに関する要件を指します。一方、後者は、どのようなデータ結果を表示することが期待されるか、どのように統計を行うか、どのようなデータモデルを構築するかなど、データ自体にのみ依存する要件を指します。 Alibaba のマーチャントデータ製品プラットフォームである Business Advisor の最初のバージョンの計画を例にとると、店舗のトラフィック、製品、取引など、ビジネス チェーン全体のデータをマーチャントに提供することが目標です。このために、Business Advisor の製品マネージャーは、ユーザー操作プロセスの設計、機能モジュールの分割、フロントエンドのプレゼンテーションとインタラクションをビジネス側の要件と見なしています。同時に、ストアの UV と PV 情報、どのような粒度でカウントするか、どのような頻度で更新するか、どのような次元で UV と PV をスクリーニングできるかなど、各データ テーブルに必要なデータ結果、データ定義、データ操作がデータ側の要件とみなされます。

--「データセンター」より抜粋