DevOps、SRE、プラットフォームエンジニア、クラウドの役割説明

記事の概要 DevOps の哲学が進化するにつれて、DevOps、サイト信頼性エンジニア (SRE)、クラウド エンジニア、プラットフォーム エンジニアに関連する役割の責任をめぐる曖昧さが増大しています。これらの役割は重複していますが、焦点とスキルには微妙な違いがあります。 DevOps は開発チームと運用チーム間のコラボレーションを重視しますが、SRE はソフトウェア エンジニアリングの実践を運用に適用し、システムの信頼性に重​​点を置きます。クラウド エンジニアはクラウド インフラストラクチャの管理に重点を置き、プラットフォーム エンジニアは社内開発者プラットフォームを作成して開発者にセルフサービス運用機能を提供します。 DevOps 実践における異質性と組織の抵抗により、役割の仕様は依然として不明確です。したがって、採用の際には、期待される役割と組織の背景を明確にすることが重要です。開発者をサポートし、DevOps の可能性を最大限に発揮するには、すべての運用ニーズを確実に満たすことが重要です。

当初考えられていたように、DevOps は一連の実践というよりはむしろ哲学であり、決して役職や役割の指定ではありません。しかし現在、DevOps エンジニア、サイト信頼性エンジニア、クラウド エンジニア、プラットフォーム エンジニアはいずれも需要が高く、これらのスキルは重複しているため、採用担当者は「CI/CD パイプライン、デプロイメント エンジニアリング、クラウド構成、Kubernetes 」などの関連性の低いキーワードを散りばめています。

私が Kubiya.ai を共同設立したとき、私の投資家たちは、求職者から多くの関心を集めているのは、DevOps や SRE、クラウドおよびプラットフォーム エンジニアだけでしょうか?最近、Reddit の投稿からウェビナーに至るまで、採用担当者がこれらの役割を定義する際に、物議を醸しているトピックについて見ていきます。

この記事では、私の考えを紹介しますが、解釈の余地がたくさんあることも認識しています。これは多くの人にとって扇動的なトピックです。では、炎上する危険を承知で、始めましょう!

まず、これらのさまざまな役割の概要を簡単にまとめてみましょう。 、SRE、クラウド、およびプラットフォームの役割

DevOps

DevOps の役割はすべて、チームワークと、より賢く作業するためのツールの使用に関するものであり、開発者と運用担当者を結びつけるものです。リリースを迅速化し、システムの安定性を向上させ、全員が同じ認識を保つようにします。

SRE (サイト信頼性エンジニア)

SRE の役割は、システムの信頼性と一貫性。彼らは、すべてが舞台裏でスムーズに実行されるようにするエンジニアのようなもので、開発者と緊密に連携してプロセスを自動化し、あらゆる問題に迅速に対応します。

# #クラウド エンジニアの役割は、クラウドのアーキテクトのようなもので、クラウド インフラストラクチャのセットアップと管理に重点を置き、AWS や Azure などのツールを使用してクラウド インフラストラクチャの効率性、安全性、コスト効率を確保します。

プラットフォーム エンジニア

プラットフォーム エンジニアの役割は、開発者にとって使いやすいプラットフォームを設計し、保守することです。開発者がアプリケーションを簡単に管理できるようにします。ワークフローの設定からパフォーマンスの監視に至るまで、すべての関係者にとってスムーズなエクスペリエンスを生み出すことが重要です。DevOps の進化と新しい作業慣行

DevOps の実践は、さらに、サービス指向アーキテクチャにより、個別の開発チームが個別のサービスとアプリケーションに独立して作業できるようになり、これまでよりも迅速なプロトタイピングと反復が可能になります。

以前は、ソフトウェア リリースに重点を置いた開発チームと、システムの安定性とセキュリティに重点を置いた独立した独自の運用チームとの間で、従来からの緊張が高まっていました。これは多くの企業が望むペースを妨げます。さらに、開発者は運用要件を常に正しく理解しているわけではなく、運用スタッフはパフォーマンスの問題が発生する前に防ぐことができません。 当初考えられていたように、DevOps は一連の規範的な実践というよりはむしろ哲学であり、あまりにその実践の量と性質についてのコンセンサスさえありません。 「DevOps の 4 つの柱」を挙げる人もいれば、「5 つの柱」を挙げる人、6、7、8、または 9 つの柱を挙げる人もいます。選んでいいですよ。

組織が異なれば、DevOps を実装する方法も異なります (多くの組織はまったく実装しません)。ここで、私たちが陥っている労働基準のジレンマを予測できます。 DevOpsDays の創設者である Patrick Debois 氏は、次のように指摘しています。「定義がないのは良いことでもあり、悪いことでもあります。人々は…今、DevOps が何を意味するのか本当に悩んでいます。しかし一方で、すべてを書き留めていないということは、それがオープンになることを意味します。

DevOps に対する答えは、サイロを打破し、ツール、文化的変革、共有指標を通じてより広範なコラボレーションを促進することです。開発者は自分が構築したものを所有することになり、エンドツーエンドで展開、監視、トラブルシューティングを行うことができます。運用部門は開発者のニーズをよりよく理解し、製品ライフサイクルの早い段階で取り組み、開発者のセルフサービスを促進するための教育、ツール、ガードレールを提供します。

DevOps にないものの 1 つは、ロールの指定です。今日に目を向けると、多くの組織が「DevOps エンジニア」を積極的に採用しています。さらに悪いことに、ポジションを定義するものについてはほとんど知られておらず、求められるスキルセットはポジションごとに大きく異なります。 「サイト信頼性エンジニア」、「プラットフォーム エンジニア」、「クラウド エンジニア」など、関連する重複する役割が、すでに濁った状況を濁らせています。

どうやってここまでたどり着いたのでしょうか?これらの役割の間に実際の違いがある場合、それは何ですか?

新しい IT 役割の出現

DevOps が勢いを増すにつれて、DevOps エコシステム内の役割と責任はますます曖昧になってきています。この曖昧さにより、サイト信頼性エンジニア (SRE)、クラウド エンジニア、プラットフォーム エンジニアなどの関連する役割が出現しました。各キャラクターには独自の焦点とスキルがあります。

SRE は、大規模システムの管理に対する Google のアプローチに触発され、ソフトウェア エンジニアリングの実践と運用を組み合わせて、サービスの信頼性とパフォーマンスを保証します。クラウド エンジニアは、AWS、Azure、Google Cloud などのプラットフォームを活用して、スケーラビリティと効率を最適化するクラウド インフラストラクチャの導入と管理に重点を置いています。一方、プラットフォーム エンジニアは、社内開発者プラットフォームの設計と保守に重点を置き、アプリケーション ライフサイクルの運用面を管理するためのセルフサービス機能を開発者に提供します。

これらの役割には重複部分がありますが、それぞれが異なる専門知識と重点分野を持っています。 SRE は信頼性と復元力を優先し、クラウド エンジニアはクラウド インフラストラクチャの管理に重点を置き、プラットフォーム エンジニアは開発者中心のプラットフォームの作成に重点を置きます。組織がチームを効果的に構成し、ソフトウェア配信パイプラインで DevOps 原則の可能性を最大限に活用するには、これらの役割の微妙な違いを理解することが重要です。

DevOps に対する抵抗と混乱

私の経験では、DevOps 実装の当初のビジョン (つまり、専門化とコラボレーションと共有の間の最適なバランスを達成する) は大きな影響を与えます。は多くの組織にとって課題となっています。

Puppet の 2021 年の DevOps 状況レポートによると、自分が「高度に開発された」DevOps 実践者であると考えている回答者はわずか 18% でした。 DevOps トポロジ チームが説明しているように、これらの利点の一部は特殊な状況から生まれます。たとえば、Netflix や Facebook のような組織はおそらく単一の Web ベース製品を使用しているため、製品ストリーム間の差異が減少し、開発者と運用スタッフのさらなる分離が余儀なくされています。

Google の SRE チーム (詳細は後ほど!) など、厳格なコラボレーション条件と標準を課すところもあります。彼らは、システムのパフォーマンスを損なうソフトウェアを拒否する権限も持っています。

DevOps 開発の下位レベルに属する多くの人々は、変化に対する組織の抵抗、スキル不足、自動化の欠如、またはレガシー アーキテクチャが原因で、DevOps の可能性を完全に実現するのに苦労しています。したがって、このグループは、DevOps トポロジで説明されている DevOps の「アンチタイプ」のいくつかを含む、DevOps の実装に対してさまざまな異なるアプローチを採用する予定です。

多くの人にとって、開発と運用は依然としてサイロ化されています。他の人にとって、DevOps は開発内に位置し、デプロイメント パイプラインや構成管理などを担当するツール チームになりますが、運用からは分離されたままになります。他の人にとって、DevOps は SysAdmin の単純な再発明であり、DevOps エンジニアは拡張されたスキルを期待されて運用チームに雇用されますが、実際の文化的な変化は起こりません。

パブリック クラウドの使用が急速に普及したことにより、セルフサービス DevOps アプローチの可能性に対する信頼も高まりました。しかし、オンデマンドでインフラストラクチャをプロビジョニングおよびプロビジョニングできることは、開発者がアプリケーションとサービスをエンドツーエンドで展開して実行できるようにすることとは程遠いです。残念ながら、すべての組織がこのことを理解しているわけではないため、多くの組織の自動化はインフラストラクチャの自動化と構成管理のレベルで停滞しています。

DevOps には非常に多くの異なる形態があるため、DevOps の役割の仕様が明確に定義されていないのも不思議ではありません。ある組織にとって、これは最も狭い意味でのデプロイメント エンジニアリングと同義であり、おそらく CI/CD パイプラインを作成するだけであるかもしれませんが、その一方で、インフラストラクチャを作成する能力を備えた本質的に運用の再発明である可能性があります。 、展開の自動化と内部ツール。他の人にとっては、中間のグレーの色合いになる可能性があるため、ここでは DevOps の職務の目まぐるしいリストを示します。

SRE、クラウド エンジニア、プラットフォーム エンジニアの役割

したがって、採用組織に応じて、DevOps エンジニアは完全にデプロイメントに重点を置いたエンジニアになることも、より最新のシステム管理者になることもできます。

他の関連する役割 (SRE、クラウド エンジニア、プラットフォーム エンジニア) についてはどうですか?それぞれについての私の考えは次のとおりです。

サイト信頼性エンジニア

SRE の概念は、Google の Ben Treynor によって導入され、彼はそれを次のように説明しました。運用をソフトウェアの問題として扱い、ソフトウェア エンジニアを配置します。」そのアイデアは、人々が運用スキルとソフトウェア開発スキルを組み合わせて、実稼働システムを設計および実行できるようにすることです。

サイト信頼性エンジニア (SRE) は、ソフトウェア エンジニアリングの実践と運用責任を組み合わせて、システムとサービスの信頼性、拡張性、パフォーマンスを保証します。彼らは、インフラストラクチャの管理と監視、ソフトウェアの展開、インシデントへのプロアクティブな対応を行うための自動化ソリューションの設計と実装を専門としています。 SRE は開発チームと緊密に連携して、信頼性基準を確立および施行し、サービス レベル目標 (SLO) を定義し、イノベーションとシステムの安定性のバランスをとるためのエラー バジェット設定などの実践を実施します。彼らの目標は、継続的な改善と反復を通じて、実稼働環境の可用性と回復力を高く保つことです。

サービスの信頼性 サービス レベル アグリーメント (SLA) の定義は、ソフトウェアが導入を承認される前に、ソフトウェアが厳格な運用基準を満たしていることを示す事前の証拠を開発チームが提供できるようにするために重要です。さらに、SRE は、開発者がこの目的で使用できる標準化された CI/CD パイプラインやクラウド インフラストラクチャ プラットフォームの設計と運用など、インフラストラクチャ システムのスケーラビリティと保守性を高めるよう努めています。

ご覧のとおり、これは一部の人々による DevOps エンジニアの定義とかなり重複しています。したがって、違いについて考える 1 つの方法は次のとおりです。対照的に、DevOps の本来の目的はリリース速度を向上させることでしたが、SRE の目標は、システムのサイズと製品の複雑さが増大する中で、より信頼性の高いシステムを構築することです。つまり、ある意味、二人は真ん中で出会ったのです。

クラウド エンジニア

クラウド機能が成長し続けるにつれて、一部の組織ではクラウド エンジニア専用の役割を作成しています。同様に、厳格なルールはありませんが、クラウド エンジニアは通常、クラウド インフラストラクチャの展開と管理に重点を置き、クラウド ネイティブ アプリケーションの環境を構築する方法を知っています。彼らは AWS/Azure/Google Cloud Platform の専門家になります。 DevOps エンジニアの責任との重複の程度に応じて、Terraform、Kubernetes などにも精通している場合もあります。

さらに、クラウド エンジニアは、クラウド テクノロジの専門知識を活用して、スケーラブルで弾力性のあるクラウド アーキテクチャを設計、実装、保守し、クラウド環境でアプリケーションとシステムが効率的かつ安全に実行されるようにします。クラウド エンジニアは、組織にとってクラウド コンピューティングの利点を最大化するために、自動化、監視、コスト最適化戦略に取り組むこともできます。

クラウドの導入が進むにつれて、クラウド エンジニアの役割には、以前はインフラストラクチャ エンジニアとして知られていたものが含まれるようになり、当初はクラウドとオンプレミスのインフラストラクチャ管理に重点が置かれています。

プラットフォーム エンジニア

内部開発者プラットフォーム (IDP) は、開発者の生産性とシステム制御および安定性のバランスを取るという課題に対する最新のソリューションとして登場しました。プラットフォーム エンジニアは、CI/CD ワークフロー、コンテナのオーケストレーション、アラート、可観測性など、アプリケーション ライフサイクル全体の運用面を独立して管理できるセルフサービス機能を開発者に提供するために IDP を設計および保守します。

多くの開発者は、少なくとも従来の意味では、操作をまったく行いたくないのです。開発者はクリエイティブなアーティストとして、インフラストラクチャがどのように機能するかについて心配したくありません。したがって、プラットフォームを、標準やプロセスを強制するのではなく、魅力的なセルフサービス開発者エクスペリエンスを作成することで制御を可能にする製品として見なすことが重要です。

曖昧さ回避: 役割への期待の明確化

それでは、これらすべてのさまざまな役割の候補者はどこにいるのでしょうか?おそらく現時点では (少なくとも DevOps の実装方法がより一般的になるまでは)、唯一の現実的な答えは、面接で必要なことをすべて質問し、期待される役割と雇用される組織の背景を明確にすることです。

採用担当者は、さまざまな理由から、広く網を張り、求人情報に人気のキーワードを埋め込むことにするかもしれません。しかし、最終的には、候補者の経験と能力に関する詳細が、面接プロセスや推薦者との会話の中で明らかになる必要があります。

私の意見では、あなたが DevOps、プラットフォーム エンジニア、クラウド エンジニア、さらには SRE であっても、開発者の運用ニーズをすべてサポートすることは、開発者が次善の製品の作成に集中できるようにするのに役立ちます。

以上がDevOps、SRE、プラットフォームエンジニア、クラウドの役割説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。