#第 1 号では、陽清京のボスが多くの興味深い見解を表明しました。 「それは運用と保守に関するものでした。人々に辞めるよう説得するためのガイドです。笑、今回のゲストはさまざまな意見を持っているでしょう。心を開いて、何百もの考え方の流派の意見に耳を傾けて、自分のキャリアとキャリアを築いてください。」人生計画。両方聞けば悟り、信じれば闇という諺にもあるように、自分の耳に都合の良いものだけを聞いてしまうと、深いものは得られない可能性が高いです。思考と衝突、それは残念です。ゲスト紹介今回は、Alibaba、Xiaomi、Didi で働いてきた業界の上級ベテラン、Zuoyebang の運用保守責任者である Nie An 氏をお招きします。 Di と Zuoyebang は 10 年以上の運用、保守、研究開発、管理の経験があります。 要点を簡単に説明地に足の着いたハイレベルな「運用・保守フォーラム」の第2回、始めましょう!
運用保守の従来の責任は、一連のプロセス、テクノロジー、および方法を通じて工業製品をサービスに組み立て、ユーザーに届けることです。サービスの運用を維持するための
; 通常、安定性、コスト、セキュリティ、効率などの多次元の目標 (運用性) を達成することが求められます。価値を生み出すためには、従来の運用保守はある程度ビジネスに結び付く必要があり、多くの企業は、ビジネスを理解しているかどうかが運用保守担当者の主な評価の 1 つであるとみなします (依存度)。クラウド コンピューティングとクラウド ネイティブ テクノロジの普及に伴い、従来の運用および保守モデルは多くの課題に直面しています。例えば、###
前述したように、インフラストラクチャがパブリッククラウドやクラウドネイティブにアウトソーシングされた後、運用保守の責任はビジネスの研究開発に移管され、プラットフォームは労働専門家に取って代わります。このような傾向と事実に直面して、運用および保守の担当者は何らかの変革を行う必要があります。
まず、組織構造について説明します。長期的には、クラウド ネイティブ時代の企業の組織形態は次の部分で構成されます。
トップ エンド ユーザーは、企業の当事者 A 顧客も、潜在的な営利グループです。ビジネスチームはエンドユーザーを担当し、その役割には製品、ビジネス、マーケティング、マーケティングなどが含まれます。ビジネスの研究開発はビジネスチームに直接サービスを提供し、主に SaaS アプリケーション/サービスを提供します。プラットフォームの研究開発は、ビジネスの研究開発に役立ち、さまざまな PaaS 機能を提供し、クラウド ベンダーをカプセル化します。また、コスト運用の FinOps、効率化運用の EP、管理チームの IT など、機能横断的な組織もいくつか存在します。
新しい組織構造では、全員が自分の仕事を行い、エンド ユーザーに適切にサービスを提供することが最終的な目標となります。ビジネスチームはビジネス価値を重視し、研究開発システムはサービス品質を重視します。情報技術の進歩に伴い、現在部門横断型組織が担っている機能は徐々にプラットフォーム研究開発チームに分解され、組織コラボレーションの主な方法は全員によるコラボレーションからプラットフォームのセルフサービスにアップグレードされます。運用と保守には、次のような新しい仕事の目標があります: 運用と保守の主なテーマは、水平方向の連携ではなく、管理プラットフォーム、リソースおよびテクノロジー センターです。運用と保守は、高度なテクノロジを活用し、ビジネスに力を与え、企業の改善を支援する必要があります。運用効率。。
技術アーキテクチャ 運用と保守の変革。目標は、運用と保守の管理を上位レベルのチームに提供することです。セルフサービスプラットフォームサービス、その本質は運用保守サービスOPaS(OP as Service)です。運用保守作業は、内容の違いにより、下図に示すようにオブジェクト管理とシーン管理の2つに分類できます。 オブジェクト管理は、オブジェクトの運用と保守、およびライフサイクル管理プラットフォームの構築を中心とした垂直モデルです。運用・保守対象は、IaaSリソース(マシン、ネットワーク、ストレージ、クラウドサービス)、PaaSコンポーネント(データベース、キャッシュ、MQ、ゲートウェイ)、SaaSアプリケーション(ビジネスミドルプラットフォーム、ビジネスアプリケーション)、サービスフレームワーク(ランタイム、コード フレームワーク、ネーム サービスなど)およびその他の側面では、企業ごとに分類の粒度が異なります。オブジェクトの各タイプには独立した管理プラットフォーム (チムニー) があります。管理プラットフォームの機能は、運用および保守オブジェクトのライフサイクル全体をカバーする必要があります。主要な段階には、モデリング (メタデータ)、配信/変更、監視/測定、オフラインが含まれます、など、パブリッククラウドとは異なる管理機能も同様です。オブジェクト管理の目標は、垂直方向に完全なクラウド製品を生産し、社内クラウド プラットフォーム ICSP を構築することです。 シナリオ管理は、運用および保守のシナリオに従って、さまざまな運用および保守オブジェクトのライフサイクル段階を管理する水平モードです。配信/変更、監視/測定、マルチクラウド、コストなどを含む運用および保守シナリオの分類は、ビジネスの研究開発の作業習慣に非常に近く、いくつかの高頻度シナリオをカバーしており、類似しています。さまざまな会社で。各タイプの運用および保守シナリオには、作業指示センター、データ センター、FinOps プラットフォームなどの独立したシナリオ管理プラットフォームがあります。シナリオ管理はオブジェクト管理に基づいており、シナリオ管理プラットフォームはモデルの統合、データの集約、管理および制御 API の統合などによって運用および保守オブジェクトを管理します。シーン管理の目標は、セルフサービスのビジネス管理機能を提供し、内部開発者プラットフォーム IDP を構築することです。 運用保守オブジェクトを生成する一般的な方法としては、自社調査、オープンソース構築、外部調達(パブリッククラウド)などが挙げられます。各運用および保守オブジェクトは、前例のない規模と複雑さで、さまざまなカテゴリ、クラスター、インスタンスなどにさらに細分化できます。運用保守対象の管理特性の同型性を維持することによってのみ、大規模かつ低コストで運用保守サービスを構築・保守することができ、大規模な運用保守が実現できる(技術レバレッジ効果)。運用および保守オブジェクトの構成は、運用および保守アーキテクチャ全体の基礎となります。同形保守は、すべての特性ではなく、運用および保守オブジェクトの管理特性を対象としています。同型性を維持する方法は、増分の制御、在庫の修復、分裂の防止です。以下の図に示すように、プラットフォームは、需要と制御の増分を提供し、在庫を修復するための測定を通じてガバナンスを推進し、標準化されたサービス フレームワークを通じて技術システムの大規模な分裂を防ぐために使用されます。プラットフォームとメトリクスは仕様に厳密に従っています。仕様にはメトリクスやプラットフォームも必要であり、改善のための質問を入力すると、これら 3 つは相互に補完します。仕様はサービス仕様(サービスガバナンスに相当)、管理仕様(運用保守管理に相当)、その他に分けられます。
同型性は維持され、明確な責任を持つ組織的な分業に依存しています。例えば、運用保守は管理に重点を置き、ビジネスツールを取り除いて現状ガバナンス、アラーム対応、CDなどのビジネス研究開発に戻す一方、ビジネス研究開発はサービスの非ビジネスロジックを取り除いてビジネス実装に焦点を当てる。サービス ディスカバリやトラフィック制御などの実装。インフラストラクチャは、サービス フレームワークなどのミドルエンド機能に焦点を当て、管理機能を取り除き、デマンド デリバリなどの運用および保守に引き渡します。チェンジコントロールなど文化の影響は無視できず、運用とアーキテクチャはコンセプトをアウトプットし、個別のニーズには SLA を約束しない、標準アプリケーションにはすぐに使用できる観察機能を提供するなど、コミュニケーションとガイダンスを通じてユーザーの習慣を育みます。
運用保守オブジェクトの同型保守と運用保守サービス指向技術システムの上向きサポートに基づいて、以下の図に示すような持続可能な運用保守アーキテクチャが形成されます。現在の技術レベルでは、セルフサービス プラットフォームに基づいた運用保守サービスでニーズの 70% を解決できますが、残りの 30% では依然として需要の伝達、問題のトラブルシューティング、結果の受け入れ、ポリシーの遵守などの手作業が必要です。技術やコンセプトの進歩により、運用保守サービスの割合はさらに高まると考えられます。
注: この記事のサービス フレームワークには、N 年前のコード フレームワークとコード ライブラリの両方に加え、現在一般的なマイクロサービス ガバナンスも含まれています。移行期、ネーミングが急務です。
ビジネスの運用と保守 (アプリケーションの運用と保守とも呼ばれる) は、クラウド ネイティブに最も近く、最も大きな影響を受けています。 。仕様策定、プロセス構築、グローバル管理などの従来のチーム間の責任に加えて、事業運営と保守もサービス指向の方向に変革する必要があります。その道筋は次のとおりです:
運用保守サービス OPaS (OP as Service) は、次の観点から見ると当社の中期的な変革です。提案された目標は大まかな方向性を示しているものの、道筋が欠けており比較的抽象的であった;その後、OPaS は徐々に ICSP IDP の運用保守アーキテクチャに洗練され、その適用範囲は全体に拡張された運用保守チームに明確な道筋と出発点が与えられました。
サービス化に加えて、ビジネスの運用と保守もハイパーサービスの視点 (現在はシナリオに名前変更されました) の構築を主導することもできます。クラウド ネイティブにおける DevOps テクノロジ パズルは完全ではありません。アプリケーション コンピューティングの部分が完成しただけであり、他の方向、特に上向きのビジネスの観点、部門の観点、企業の観点などの能力にギャップがあります。これを ## と呼びましょう。 #スーパーサービスの視点。ハイパーサービスの観点から見ると、ビジネスの研究開発担当者は通常、主導権を握る能力や意欲を持っていません。部門長やアーキテクトは自分の部門を担当できますが、職責によって制限されており、全体に拡大するのは難しいと感じています。状況。一方、ハイパーサービスの観点は、比類のない経験、理解、認識上の利点を備えた、従来のビジネス運営と保守の古戦場です。ビジネスの運用と保守は、ハイパーサービスの視点の構築を先導します。これにより、クラウドネイティブ分野のギャップを埋めるだけでなく、ビジネスの運用と保守の専門的な利点を最大限に発揮し、変革の機会を活用することができます。 . 以下に示すように、win-winの選択となります。
スーパー サービスの観点:このチームの対象となるのは、Tencent、Alibabaに分散する様々なクラウドサービスです。 、Baidu およびその他のクラウド ベンダー
運用保守センターは、元の運用保守プラットフォームのサブセットです。ドメイン知識を再構築する必要はありません。ドメイン抽象モデリングをやり直す必要があり、コード品質に対する要件が比較的高くなります (基本コンポーネントと同じ) ). これこそが、子供向けの OpDev の強みです。責任が集中化され軽減されるにつれて、OpDev はスリム化とより高いレバレッジを同時に達成する必要があります。
以下を含む当社の変革の教訓を簡単に共有します。
以下は追加コンテンツであり、この記事の核心ではありません。
パブリック クラウドであっても、内部 K8S プラットフォームであっても、デマンド デリバリー操作は数多くあります。このタイプの ToM (ToManager) 配信プラットフォームには必要な制約が欠けていることが多く、経験豊富なユーザーのみが利用できます。
分業の最適化と効率の向上を図るため、運用保守管理プレーンの ToC (ToRD) を「作業指示の手配と承認」を通じて実装することができ、ワークフロー/作業指示自体が高度に統合されます。運用および保守管理のベスト プラクティスに組み込まれており、研究開発に安全に公開できます。これは、運用および保守能力のサービス化にとって重要な方向性です。セルフサービス配信の進化の道筋は次のとおりです。
現在、要件から技術的ソリューションまでのコミュニケーション リンクをセルフサービスで実現することは比較的困難です。将来的にはさらに多くの試みが必要です。
大規模な運用と保守の経済学の本質は限界費用であり、これは「運用と保守管理の限界コストの減少と限界コストの増加」の相互作用です。同型メンテナンスのコスト」。下図に示すように、運用保守対象数が少ない場合はプラットフォームの構築や手作業などの運用保守管理コストが大半を占めますが、運用保守対象数が増加すると同型保守が発生します。が主なコストを構成し、限界の転換点は技術やコンセプト、その他の環境要因によって影響されます。
クラウド ネイティブ テクノロジにより、同型性維持の困難さが軽減され (同型性維持曲線の右シフトが促進され)、運用および保守サービスの機能が向上します (運用保守管理曲線が下方にシフトすることにより、運用保守担当者がより多くの運用保守対象をより低コストで管理できるようになり、生産効率が大幅に向上します。
以上がZuoyebang Nie An: 運用と保守を変革する方法、Zuoyebang の OPaS アイデアを聞くの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。