Zuoyebang Nie An: 運用と保守を変革する方法、Zuoyebang の OPaS アイデアを聞く

#第 1 号では、陽清京のボスが多くの興味深い見解を表明しました。 「それは運用と保守に関するものでした。人々に辞めるよう説得するためのガイドです。笑、今回のゲストはさまざまな意見を持っているでしょう。心を開いて、何百もの考え方の流派の意見に耳を傾けて、自分のキャリアとキャリアを築いてください。」人生計画。両方聞けば悟り、信じれば闇という諺にもあるように、自分の耳に都合の良いものだけを聞いてしまうと、深いものは得られない可能性が高いです。思考と衝突、それは残念です。

地に足の着いたハイレベルな「運用・保守フォーラム」の第2回、始めましょう！

ゲスト紹介

今回は、Alibaba、Xiaomi、Didi で働いてきた業界の上級ベテラン、Zuoyebang の運用保守責任者である Nie An 氏をお招きします。 Di と Zuoyebang は 10 年以上の運用、保守、研究開発、管理の経験があります。

要点を簡単に説明

従来の運用保守は、工業製品をサービスに組み立て、ユーザーに届け、サービス運用を維持する役割を担っており、サービスへの依存度が高いのが特徴です。ビジネス
• ドメイン危機: クラウド ネイティブ時代には、パブリック クラウドが広く使用され、マイクロサービス アーキテクチャと DevOps が真に実現され、ツール システムは繁栄し続け、従来の運用と保守の責任は常にアウトソーシングされ、移転され、ドメインの危機が発生
• 組織構造、コラボレーション手法は全員協力からプラットフォームのセルフサービスへと段階的にアップグレードされ、運用保守の主要テーマは水平連携からサービス製品とテクノロジーに変化ミドル プラットフォーム
• 技術的にはセルフサービス プラットフォーム、外部運用および保守サービス機能を介した運用および保守の変革 OPaS (OP as Service) は、オブジェクトとシナリオの 2 つの層に分割されており、基礎となるオブジェクトは同型的に保守されます。 、持続可能な運用および保守アーキテクチャの形成
• ビジネス運用および保守、サービス指向の変革の中核は役割の認識です。運用および保守担当者は、ビジネスに依存する運用上の役割から独立した運用上の役割に自らを調整する必要があります。運用保守サービスプロバイダー。ハイパーサービスの観点から見ると、ビジネス運用保守には大きな可能性があります。
• コンポーネントの運用保守は、コンポーネント自体を制御するものであり、オニオンモデルに従って、純粋な運用保守管理をさらに超えています。つまり、リソースの提供に基づいて、管理プラットフォームを構築し、次にコンポーネント自体の専門分野に深く入り込みます。
• 運用と保守の開発を取り除き、公共の運用と保守センターに焦点を当てたプラットフォームの反復作業を繰り返します。 、テクノロジーとハイレバレッジに特化

運用保守ステージ

インターネットの運用保守は純粋な手作業を経験しており、標準化、プラットフォーム化、デジタルインテリジェンスなどのいくつかの段階があります。以下の図に示されています。その中でも、DevOps はテクノロジー主導の組織変革であり、専門家以外の変革です。

運用と保守の開発履歴から、いくつかの特徴がわかります:

継承。新しい段階では、多くの場合、古い段階の優れた経験を継承および継承し、概念、技術、および組織の革新が行われます。

たとえば、プラットフォーム化は、標準化段階の成果を継承および強化します。 、データ インテリジェント化は、プラットフォーム化の成果を継承し、ビッグ データ技術を導入します。

責任の移転。 DevOps は、運用保守管理モデルの分水嶺です。DevOps 後の運用保守
• 一方で、運用保守の専門化の方向に進み続け、より高度な同形管理を管理する能力を維持します。
• 一方で、運用と保守、研究開発の統合が強調されており、運用と保守の責任は段階的にビジネスの研究開発に移管されています。
• 特定の分野の発展の歴史を学ぶことで、歴史から学び、トレンドを活用することができます。

従来の運用および保守モデル

従来の運用および保守モデルでは、サービス オブジェクトは基本的に 3 つの層に分割できます。最下層は主にコンピューティング、ネットワーク、ストレージで構成されるハードウェア インフラストラクチャ IaaS、中間層はオペレーティング システム、仮想化テクノロジ、コード フレームワーク、ミドルウェアなどを含むソフトウェア インフラストラクチャ、最上層はビジネスです層、主にアプリケーション サービス。

運用保守の従来の責任は、一連のプロセス、テクノロジー、および方法を通じて工業製品をサービスに組み立て、ユーザーに届けることです。サービスの運用を維持するための

; 通常、安定性、コスト、セキュリティ、効率などの多次元の目標 (運用性) を達成することが求められます。価値を生み出すためには、従来の運用保守はある程度ビジネスに結び付く必要があり、多くの企業は、ビジネスを理解しているかどうかが運用保守担当者の主な評価の 1 つであるとみなします (依存度)。

クラウド コンピューティングとクラウド ネイティブ テクノロジの普及に伴い、従来の運用および保守モデルは多くの課題に直面しています。例えば、＃＃＃

• 企業がパブリッククラウドを利用した後は、IaaS/PaaS、さらにはSaaSも基本的にはサービス指向であり、APIを通じて取得できるため、多くの運用保守構築作業はクラウドベンダーなどの協力を得て完了します。ハードウェア、システム、ネットワーク、データベース、ビッグデータなどについては、元の工場は少量の専門的な選択と統合機能を保持するだけで済みます (アウトソーシング)
• クラウド ネイティブ テクノロジの普及後、マイクロサービス アーキテクチャこれまで専門の運用保守担当者が行っていた業務を大規模に実現できるようになりました。運用は段階的にビジネス研究開発に引き継がれ、配信、変更、監視、キャパシティなどのセルフサービスでの完了が可能になります。運用保守の責任は、大部分はビジネス研究開発に移管 (移管)
• パブリック クラウドとクラウド ネイティブのプロフェッショナルな集約効果オープン ソース システムにより、ツールの見通しが継続的に改善されます。工具によって効率が向上すると、同じポジションで必要な労働力が減ります。工具によって専門能力が蓄積され、オペレータの技術的閾値はますます低くなっています。工具が自動化とインテリジェンスに進化した後は、機械が労働力に取って代わることができます。プラットフォームによる労働力の代替は今も徐々に深まりつつある（代替）

前述したように、インフラストラクチャがパブリッククラウドやクラウドネイティブにアウトソーシングされた後、運用保守の責任はビジネスの研究開発に移管され、プラットフォームは労働専門家に取って代わります。このような傾向と事実に直面して、運用および保守の担当者は何らかの変革を行う必要があります。

組織構造

まず、組織構造について説明します。長期的には、クラウド ネイティブ時代の企業の組織形態は次の部分で構成されます。

トップ エンド ユーザーは、企業の当事者 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

ビジネスの運用と保守 (アプリケーションの運用と保守とも呼ばれる) は、クラウド ネイティブに最も近く、最も大きな影響を受けています。 。仕様策定、プロセス構築、グローバル管理などの従来のチーム間の責任に加えて、事業運営と保守もサービス指向の方向に変革する必要があります。その道筋は次のとおりです:

• まず、役割認識を変える必要があります。価値を生み出すためにビジネスに依存する運用上の役割から独立した価値を持つ運用および保守サービス プロバイダーに調整してください。役割の変更が鍵です

• 組織内で、主な責任を再分割すること。ビジネス R&D はアプリケーションの主な責任者であり、運用と保守はアプリケーションの主な責任者ではなく、プラグインの乳母でもありませんが、アプリケーションの管理機能を提供するものです。ビジネス R&D は運用と保守を使用します。サービスを提供し、それ自体で運用作業を完了する
• 仕組みを構築し、評価システムを再構築します。事業運営および保守部門のパフォーマンスは、もは​​やビジネス チームや事業研究開発と強く結びついておりませんが、主観的な評価をあまり重視せず、技術的評価に重点を置き、サービス指向の運用および保守に重点を置いています。

• 2 つ目は、運用と保守の変革のための 4 つのステップです。対象を明確にする→抽象的な共通性→プラットフォームを構築する→大規模な運用・保守を実現
• 業務の運用・保守の対象は、まずアプリケーション(サービスとも呼ばれます)であり、そしてアプリケーションの拡張シナリオ（ビジネス視点、企業グローバル視点など）
• 抽象的な共通性が難しさであり、重要なポイントです。多数のアプリケーション、複雑なテクノロジ スタック、および多くのパーソナライズされた機能が存在するため、パーソナライズされたケースに陥ることを避けるために、アプリケーションの共通の管理特性を抽象化する必要があります。厳密に言えば、アプリケーションの共通特性が運用保守管理の対象です
• 構築プラットフォームはアプリケーション管理プラットフォームを指し、大規模な運用保守は持続可能な最終状態です
• 第三に、アプリケーション オブジェクトは同型のままです。サービス機能の構築に加えて、運用保守担当者の主なエネルギーは同型性の維持に投資されるべきです。

運用保守サービス OPaS (OP as Service) は、次の観点から見ると当社の中期的な変革です。提案された目標は大まかな方向性を示しているものの、道筋が欠けており比較的抽象的であった；その後、OPaS は徐々に ICSP IDP の運用保守アーキテクチャに洗練され、その適用範囲は全体に拡張された運用保守チームに明確な道筋と出発点が与えられました。

ハイパーサービスの視点 (ビジネスの運用と保守)

サービス化に加えて、ビジネスの運用と保守もハイパーサービスの視点 (現在はシナリオに名前変更されました) の構築を主導することもできます。クラウド ネイティブにおける DevOps テクノロジ パズルは完全ではありません。アプリケーション コンピューティングの部分が完成しただけであり、他の方向、特に上向きのビジネスの観点、部門の観点、企業の観点などの能力にギャップがあります。これを ## と呼びましょう。 #スーパーサービスの視点。ハイパーサービスの観点から見ると、ビジネスの研究開発担当者は通常、主導権を握る能力や意欲を持っていません。部門長やアーキテクトは自分の部門を担当できますが、職責によって制限されており、全体に拡大するのは難しいと感じています。状況。一方、ハイパーサービスの観点は、比類のない経験、理解、認識上の利点を備えた、従来のビジネス運営と保守の古戦場です。ビジネスの運用と保守は、ハイパーサービスの視点の構築を先導します。これにより、クラウドネイティブ分野のギャップを埋めるだけでなく、ビジネスの運用と保守の専門的な利点を最大限に発揮し、変革の機会を活用することができます。 . 以下に示すように、win-winの選択となります。

スーパー サービスの観点:

デマンド デリバリー: 作業指示センター、オーケストレーション エンジン、実行エンジン
• 変更管理: 5つのキャッチオールルール、集中管理と制御、手配承認、実行承認、サービス検査、変更測定
• 観測測定: からの観測および測定データを集約して表示します。ビジネスの観点、サポートのドリルダウン アプリケーションの粒度までドリルダウン
• #マルチクラウド アーキテクチャ: 測定、ガバナンス、計画、技術システム全体にわたるドリル
#コスト管理: 請求、配分、 FinOps ディレクションのために独立して全社の IT リソースを管理、制御、最適化する
• 標準策定: 全社的な観点からの運用保守仕様の策定、煙突状の繰り返しを避けるためのプロセス実装の監督小規模チームの構築
• etc.
• クラウド ネイティブの下で DevOps テクノロジ パズルを俯瞰すると、機能にギャップがあります。たとえば、CDN などの基本サービスのサポート、オブジェクトストレージ、MQ、EMRは完璧ではなく、2022年時点ではまだ模索段階ですが、運用保守管理の観点からサービスフレームワーク（認証、発見、通信、知覚、フロー制御) は、クラウドネイティブによって管理されている場合でも放射されます。

オニオン モデル (クラウド サービス、ミドルウェア、ビッグ データの運用および保守)

クラウド サービス、ミドルウェア、ビッグ データ、およびその他の運用および保守オブジェクトのテクノロジー スタックは、専門的に集中されています。変革を実装する際、運用および保守担当者はオニオン モデルに従うことができます。

最初の段階はリソースの配信に基づいており、元の運用および保守オブジェクトをリソース エンティティに変換し、上流への配信を確実に行います。サービス機能を強化し、仕事の価値の最終ラインを確立します。

第 2 段階では、リソース エンティティのライフ サイクルを管理し、自分自身を解放するための管理プラットフォームの構築に多大なエネルギーを投資します。 -サービス ToC と分離の実現
• 3 番目の段階は、コンポーネント自体の専門分野に深く入り込み、アーキテクチャ、コード、パフォーマンス、運用、保守などのあらゆる側面から専門性を向上させることです。このステップが達成されると、運用保守者は単なる管理者ではなく、この分野のサービスの専門家になります。
• オニオン モデルは、データベース、ビッグデータ、ミドルウェアなどの立場で最初に検証され、その後、それが引き継がれてクラウドサービスに利用され、こちらも成功を収めました。例えば、当社のクラウドサービス運用保守チームであるCloudOpsチームは、オニオンモデルに基づいた変革を実現していますが、その詳細は以下のとおりです

このチームの対象となるのは、Tencent、Alibabaに分散する様々なクラウドサービスです。 、Baidu およびその他のクラウド ベンダー

2 年前、当社はビジネスの迅速な発展 (リソースの提供) をサポートするために、さまざまな手動方法でマシン、ストレージ、その他のリソースを提供しました (リソースの提供)。マシン、帯域幅、オブジェクト ストレージ、CDN などのクラウド サービスのライフ サイクルを管理するためのマルチクラウド管理プラットフォームの構築を開始します。このプロセスにおいて、CloudOps 管理プラットフォームは、社内のセカンダリ クラウド サービス プロバイダー ICSP (プラットフォーム機能) への変換に成功しました。
• 次に、パブリック クラウド製品の学習、認識、理解を強化していきます。
• 運用保守ミドルプラットフォーム（運用保守開発）
• 事業運営として、この分野（コンポーネントそのもの）におけるさらなる専門性の確立を目指します保守、コンポーネント運用保守、システム運用保守（リソースネットワーククラウドサービス）などの役割が開発作業に参加するようになり、運用保守開発DevOpsチームのスペースが徐々に少なくなり、分業化が進んだ変革の過程では不明でした。組織構造と技術アーキテクチャのアップグレードの予測を参照して、OpDev の位置付けを再調整しました。OpDev は、開発のアウトソーシングや運用保守担当者の従属ではなく、独自の独立したサービスを持つ必要があります。その結果、元の運用保守プラットフォームは 2 つの部分に分割され、1 つの部分は機能の反復に重点が置かれ再利用できず、IDP リソース コンソール、ICSP シナリオ管理ツール、他の部分はパブリック機能であり、以下に示すように、運用および保守のミドル プラットフォームが統合アカウント IAM、作業指示オーケストレーション エンジン、モニタリング インジケーター コレクターなどの OpDev を担当するものとして抽象化されています。

運用保守センターは、元の運用保守プラットフォームのサブセットです。ドメイン知識を再構築する必要はありません。ドメイン抽象モデリングをやり直す必要があり、コード品質に対する要件が比較的高くなります (基本コンポーネントと同じ) ). これこそが、子供向けの OpDev の強みです。責任が集中化され軽減されるにつれて、OpDev はスリム化とより高いレバレッジを同時に達成する必要があります。

いくつかの教訓

以下を含む当社の変革の教訓を簡単に共有します。

• 変革と保守主義の間には妥協点があります。従来の運用保守からサービス プロバイダーへの変革は一夜にして起こるものではなく、従業員全員が移行するわけでもなく、必ず誰かが残ることになります (現在の技術レベルは約 73%)。リソースが集中すると、バックエンド担当者はより多くの価値リターンを得ることができます。
• 研究開発能力の差別化の勾配。子供靴の運営・保守から開発までの能力にはばらつきがあり、ビジネスニーズの反復から出発し、品質を確保するために設計と受け入れを厳密に管理し、工学理論を意識的に補完し、優れた操作性と優れた機能を備えていなければなりません。クリーンな基盤となる
• プラットフォームだけが唯一の選択肢ではありません。プラットフォームはサービス機能を実現する最も強力な方法ですが、それが唯一の方法ではありません。組織、文化、規範、プロセス、プラットフォームはすべて必須です（ただし移転コストは若干高くなります）
• 運用保守管理の対象を明確にします。運用と保守、特にアプリケーションの運用と保守では、管理対象はアプリケーションそのものではなく、アプリケーションの共通特性です。アプリケーションの共通特性が多ければ多いほど、アプリケーションの運用と保守の価値は大きくなります (レバレッジ)
• 組織的な保証を無視することはできません。組織構造は主要な生産力です。CTO は変化を生み出し、明確な目標を持ち、主な責任の明確化、独立した受け入れ機関の設立、測定とガバナンスのサイクルなどの明確な役割分担を持たなければなりません。運用と保守の変革に対する組織の保証
• 警戒心 純粋なプロジェクト思考。短期的に価値を爆発させて達成感を得るには、運用と保守は依然としていくつかのプロジェクトに参加する必要がありますが、人々は簡単に気を失い価値がゼロになるため、意識的な設計目標とサービスの蓄積が必要ですプロジェクト プロセス中の能力
• 緊急対応よりも予防​​の方が効果的です。建築分野では安定性の問題を解決する必要があり、緊急時の対応よりも予防​​の方が効果的です。 MTBF の延長を優先し、次に MTTR の短縮を優先します

---

以下は追加コンテンツであり、この記事の核心ではありません。

デマンド デリバリーの進化

パブリック クラウドであっても、内部 K8S プラットフォームであっても、デマンド デリバリー操作は数多くあります。このタイプの ToM (ToManager) 配信プラットフォームには必要な制約が欠けていることが多く、経験豊富なユーザーのみが利用できます。

分業の最適化と効率の向上を図るため、運用保守管理プレーンの ToC (ToRD) を「作業指示の手配と承認」を通じて実装することができ、ワークフロー/作業指示自体が高度に統合されます。運用および保守管理のベスト プラクティスに組み込まれており、研究開発に安全に公開できます。これは、運用および保守能力のサービス化にとって重要な方向性です。セルフサービス配信の進化の道筋は次のとおりです。

現在、要件から技術的ソリューションまでのコミュニケーション リンクをセルフサービスで実現することは比較的困難です。将来的にはさらに多くの試みが必要です。

限界点の規模の運用とメンテナンス

大規模な運用と保守の経済学の本質は限界費用であり、これは「運用と保守管理の限界コストの減少と限界コストの増加」の相互作用です。同型メンテナンスのコスト」。下図に示すように、運用保守対象数が少ない場合はプラットフォームの構築や手作業などの運用保守管理コストが大半を占めますが、運用保守対象数が増加すると同型保守が発生します。が主なコストを構成し、限界の転換点は技術やコンセプト、その他の環境要因によって影響されます。

クラウド ネイティブ テクノロジにより、同型性維持の困難さが軽減され (同型性維持曲線の右シフトが促進され)、運用および保守サービスの機能が向上します (運用保守管理曲線が下方にシフトすることにより、運用保守担当者がより多くの運用保守対象をより低コストで管理できるようになり、生産効率が大幅に向上します。

以上がZuoyebang Nie An: 運用と保守を変革する方法、Zuoyebang の OPaS アイデアを聞くの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。