クラウドネイティブ変革: スケーラブルな進化と文化的思考

[[416383]]

いわゆる変革とは、構造形態、運営モデル、人々の物事に対する概念の根本的な変化のプロセスを指します。

追記：これは私が見たり聞いたり学んだり考えたりしたことの要約です。それが表すシナリオは比較的限定されており、ほとんどのシナリオには適用できない可能性があります。

先週末、「大規模な組織が DevOps 成熟モデルをどのように設計するか」について考えていたとき、なぜ DevOps が変革なのか疑問に思い始めました。アジャイルは変革にもなり得るか？これらは非常に複雑であるため、組織文化と技術的実践に一連の変更が必要になります。だから、私は変革の領域を探求し続けようと思っています。

ある分野で人々の考え方を変えるために、多くの説教、多くの学習、構造的変化（技術的、組織的、またはビジネス的）が必要な場合、それは変革と呼ぶことができます。

そこで、アジャイル変革と DevOps 変革における次のような中核的な変化要因を再考しました。

1. 概念の変化と新しい文化の導入。
2. コラボレーションを改善するために構造を調整します。ここでのアーキテクチャには、テクノロジー、組織、ビジネス、チームが含まれます。
3. 能力センターを構築します。
4. 成熟度ガイダンスは改善し続けています。

そこで、これをクラウドネイティブ変革プロセスに統合しようとしました。実験的と言われていますが、実際はいくつかの企業の要望とクラウド移行のプロセスを組み合わせて改良していきました。たとえば、中規模および大規模組織でマイクロサービス フレームワークを社内で推進し、社内の技術コーチをトレーニングすることで、技術能力センターが形成されます。

0. プラットフォームから始めて、徐々にクラウドに移行する

クラウド ネイティブは、マイクロサービスに似た CloudNative に由来します。マイクロサービスはアーキテクチャスタイルを表しますが、クラウド ネイティブはより抽象的なモデル、つまり概念を表します。そのため、クラウドネイティブ理論の応用に基づき、アーキテクチャを設計する際にはクラウド向けに設計されます。

今日、クラウド ネイティブへの第一歩は、クラウド ネイティブ プラットフォームを採用または構築することです。

1. モデルツール: クラウドプラットフォーム

ここ数年、クラウドネイティブの主流モデルは、Kubernetesをプラットフォームの基盤として利用し、社内PaaSプラットフォームを構築するなど、コンテナ化されたプラットフォームを構築することです。したがって、この些細なプロセスは重要ではありません。

私がこれについて言及する理由は、一部の組織のクラウド プラットフォーム (PaaS) が誤った方向に進んでいるためです。 Kubernetes が普及する前から、インフラストラクチャをコードとして扱う同様の機能を備えた一連の DevOps ツールがすでに市場に存在していました。 「コードとしてのインフラストラクチャ」モデルは、クラウド プラットフォーム構築の中核です。人々は実践からパターンを抽出し、ツールはパターンから洗練され、プラットフォームはツールから構築されます。しかし、プラットフォームを使用する人は、元のモデルを常に忘れてしまいます。このため、一部のクラウド プラットフォーム (PaaS) では、多くの手動構成が必要になります。

2. レガシーインフラストラクチャの近代化

クラウド プラットフォームでは、従来のレガシー インフラストラクチャを削除し、クラウド プラットフォーム (PaaS) に移行する必要があります。

これについては特に言うことはありません。

次のステップは、アプリケーション アーキテクチャを再設計することです。

3. 回復力のあるアーキテクチャの設計 — 必ずしもマイクロサービスは必要ありません

マイクロサービス アーキテクチャはクラウド ネイティブにおける非常に優れたアーキテクチャ パターンですが、マイクロサービスが唯一の答えであるわけではありません。マイクロサービスを分割する方法が多すぎて、多くのシステムが本来持つべき柔軟なアーキテクチャを失ってしまいました。したがって、移行パスとしてマイクロサービスを目指すのはやめてください。私たちが設計すべき方向性は、柔軟なアーキテクチャであるべきです。

回復力のあるアーキテクチャを実現する方法を中心として設計し、コンテナ、サービス メッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API などの関連テクノロジを使用することが、問題を解決する正しい方法です。

これで物語は終わりですか？

1. 概念を変え、新しい文化を導入する

クラウド プラットフォームに移行し、アプリケーションをマイクロサービスに変換するだけです。ほとんどのチームにとって、大きな変化はもたらされず、チームは元のアイデアでシステムの設計と構築を続けました。チームが単にクラウドに移行するだけでは、必要なコア機能の構築に気付かない可能性があります。

クラウド ネイティブで何が変わりましたか?

この質問をもう一度考えてみてください。なぜクラウド ネイティブを選択したのですか?利益の観点から、組織の観点から見ると、次のようになります。

• より良い顧客体験
• 収益の増加と運営コストの削減
• 新製品や新サービスの発売までの待ち時間を大幅に短縮

チームに関しては、2 つの部分に分けることができます。

• プラットフォーム側、つまりインフラストラクチャ レベルから見ると、インフラストラクチャの抽象化が重要です。これは、インフラストラクチャの不変性と使い捨ての性質に関するものでもあります。
• 開発側、つまりプラットフォームを利用する観点からは、アプリケーションがどれだけ弾力性があるかが重要です。

開発者向けサービス

しかし、話はそれほど単純ではありません。プラットフォーム チームがプラットフォームの開発のみに集中すると、「Developer as a Service: 開発者はオンデマンドで利用される」で述べたような一連の現実的なショックに遭遇することになります。

チームが直面している問題は、より良いサービス、より快適な体験を提供すること、さまざまなチームをサポートする手間を回避することなど、オープンソース プロジェクトのジレンマと非常によく似ています。

プラットフォーム チームは、社内のオープン ソースや開発者の運用を採用するなど、問題解決へのアプローチを変更する必要があります。

スケーラブルで弾力性のあるアーキテクチャ設計

組織内では、さまざまなチームのレベルが異なり、チームの能力やビジネス シナリオの単純さによって制限される場合があります。したがって、こうしたアーキテクチャの調整に直面すると、事態は極めて混乱することになります。

クラウドネイティブのシナリオでは、これは技術的なベースラインを確立することと同等であり、すべてのチームがこのベースラインに到達する必要があります。しかし現実には、ほとんどのビジネス チームにはそのような能力とエネルギーがありません。能力と比較すると、エネルギーと時間は大きな問題です。

そのため、組織的な視点では、アジャイル変革を進める際にはアジャイルコーチを活用したり、DevOps変革を進める際にはDevOpsコーチ/エンジニアを導入するなど、大規模な技術力向上を支援する仕組みづくりが必要です。

2. 組織内のコラボレーションを改善する

モデルの観点から見ると、クラウド ネイティブ変革は、組織のコラボレーション方法の変更も意味します。規模的には、開発同士のコラボレーションということになります。 DevOps 変革ほど広範な組織的影響はありません。

DevOps >> 開発 + 運用

DevOps 運動の当初の目的は、開発と運用の間の障壁を打ち破り、両者のコラボレーションを促進することでした。国内のさまざまな標準規格の出現と成熟に伴い、私たちはこれを「ビジネス+開発+運用・保守の連携を意味するBizDevOps」と定義しています。

DevOps の動きにより、組織はより合理化されます。少なくともコラボレーションの点では、標準化され、ツール化されています。

したがって、クラウド ネイティブの成功も DevOps に基づいて構築される必要があります。開発 + 運用および保守が一緒に PaaS プラットフォームを構築し、ビジネス + 開発活動をサポートするために使用されます。

社内開発者経験: PaaS 開発 + ビジネス開発

PaaS プラットフォームが登場すると、プラットフォーム開発 (PaaS Dev) とビジネス開発 (Biz Dev) の連携が重要になります。

コラボレーションの方法を改善するには、開発者エクスペリエンスの設計に重点を置く必要があります。これは、コラボレーションの方法におけるもう 1 つの変更です。開発者エクスペリエンス指標に基づいてコラボレーションを最適化することも、行う必要があるもう 1 つの変更です。

3. 技術能力センターを構築する

ほとんどの組織が犯す間違いは、社内に技術コミュニティを構築していないことだと私は思います。技術コミュニティを構築することで、組織の技術資産を統合できます。理由の一つは、部門間の競争であると考えられます。クラウドネイティブ時代において、クラウドネイティブ関連の知識をどのように共有するかという問題は非常に緊急なものとなっています。

知識体系の蓄積

Wiki は開発チームが知識を蓄積するための手段です。組織では、同じ知識が異なるチームに分散している場合があります。

従来のモードでは、これは問題ではありません。クラウドネイティブ時代においては、この問題はさらに顕著になります。したがって、PaaS プラットフォーム チームは、率先してナレッジ ベースの確立を開始する必要があります。他の人の問題解決を支援するだけでなく、自分の応答時間も短縮できます。

社内技術コミュニティ

社内の技術コミュニティは、Tw が技術力を構築するために使用する方法の 1 つです。特定の分野でビジネスチャンスが生まれたときに、それをサポートするのに十分な能力を備えている可能性があります。ほとんどの組織にとって、これは非常に効果的なアプローチです。

これに加えて、組織は次のことも考慮する必要があります。

• コミュニティサポートと運営システム
• KPI報酬メカニズム

それでも、部門の壁が社内の技術コミュニティを制限しているのではないかと疑問に思っていました。

テクニカルコンピテンスセンター

クラウド ネイティブのコンテキストでは、これは関連する PaaS プラットフォームと開発者がパターン、ブループリント、テクノロジー、コード サンプルについて共同作業できるようにすることです。上記の 2 つの方法と比較すると、技術力の向上に重点を置いたチームになることは、より困難な作業です。

興味深いことに、このモデルは技術的な雰囲気を持つ多数の企業に採用されており、さまざまなチームのスキル向上を支援するために一連の社内技術コーチを採用しています。

4. 成熟度が継続的な改善を導く

成熟度モデルは、もう 1 つの興味深い標準化モデルです。これは、組織がどのように効率的に機能するか、言い換えれば、組織がどのように社会という巨大な輪の一部となるかを指示するために使用されます。

成熟度は、私たちが規模を拡大する方法を導くために今でも利用しています。この点については、前回の記事「中規模および大規模組織向けの DevOps 成熟度モデル」ですでに一連の設計紹介を行っています。大規模な組織の場合、重要なのは、業界の一般的なモデルに基づいて独自のモデルをさらに改善することです。

他の

スペースが限られているため、記事の内容の多くは詳細には説明されません〜。

追記：うっかり書き間違えたようですが、タイトルから大体の内容は分かりますよ～。

参考文献:

• 「CNCF クラウド ネイティブ定義 v1.0」
• DevOps文化: 変革の方法
• IQ不足の問題をどう解決するか？
• デジタル技術戦略: 開発者エクスペリエンス - 社内ツールの「ラストマイル」

この記事はWeChatの公開アカウント「phodal」から転載したもので、以下のQRコードからフォローできます。この記事を転載する場合は、phodal の公開アカウントにご連絡ください。