「DevOpsエンジニア」を雇おうとしないのはなぜですか？

持つのアイデアDevOpsチームのエンジニアは、となっている最近非常に人気があり、それは、ただのスロットとDevOpsチームの多くの利点を提供できる人を持っている魅力的なようだ人形のブログで説明したように：

DevOpsプラクティスを使用している組織は、圧倒的に高機能です。2015年のDevOpsのレポートによると、競合他社の最大30倍の頻度でコードを展開し、展開の50％が失敗します。

ただし、これらの改善を試みるDevOpsエンジニアのアイデアに反対する声が多いことに気付きました。

DevOpsの主要な属性について広く合意されていても、「DevOpsエンジニア」という用語をめぐる論争があります。用語自体がDevOpsの価値と矛盾すると言う人もいます。Continuous Deliveryの共著者であるJez Humbleは、DevOpsエンジニアを誰かと呼ぶだけで、devとopsに加えて3番目のサイロを作成できることを指摘しています。 」

このようなブログが提唱する組織の変更とは対照的に、DevOpsエンジニアを雇って「DevOpsを実装」することは、ビジネスにとってそれほど素晴らしい考えではないのはなぜですか？隔離されたDevOpsの役割を持っているだけでは、メリットは無効になりますか？

TL; DR：DevOpsチームを雇ってはいけません

基本的に、採用する最も一般的な3つの役割があります。

1. DevOpsアーキテクト/エバンジェリスト
2. DevOpsエンジニア
3. CI / CDエンジニア

これらの役割は、ソフトウェアエンジニアリング組織を伝統的に構成する6つの重要なソフトウェア開発の役割とは異なります。

1. 製品管理
2. ソフトウェア開発
3. ツール開発
4. セキュリティとコンプライアンス
5. 品質とテスト
6. システム操作（SRE）

3つの役割を1つずつ見て、どのように適合するかを見てみましょう

DevOpsアーキテクトまたはエバンジェリスト

• 理由：道に迷って、遅く、壊れて、どうしたらいいかわからない場合。
• 時期：計画段階のプロセスの開始時。
• 内容：ソフトウェアエンジニアリング組織全体のすべてのマネージャーとリードを導く管理レベルの役割。この担当者は、エンジニアリング組織の高度な機能状態への移行全体を計画します。
• 担当者：ソフトウェアエンジニアリングのVPに直接報告する、理論、管理慣行、文化トピック、および運用に精通したコンサルティングメンバー。

場合によっては、中小企業では、DORAなどのコンサルティング組織を雇って代わりにプロセスを開始することもあります。

DevOpsエンジニア

• なぜ：
  1. チームが上記の機能的役割に沿って編成されている場合、チーム間のギャップを埋め、機能間のレベルの協力を確保する。
  2. チームに含まれる6つの従来の役割のそれぞれを持つ製品指向のチームに組み込むことで、知識のギャップを埋め、新しい実践とツールの実装と採用を支援します。
• 時期：計画を立て、組織の変革が始まり、管理チーム全体が参加します。
• 内容：部門間の協力を可能にし、チームの境界を壊し、チーム内のローカルな最適化が、顧客の要望から顧客の配送までのバリューチェーン全体で高スループットの仕事に対する障壁を作成しないようにします。
• 対象者：ソフトウェア開発とシステム運用の両方のスキルを持つ経験豊富なエンジニア。彼は、DevOpsトランスフォーメーションに関連するベストプラクティス、プロセス、文化の変化に精通している必要があります。

CI / CDエンジニア

• 理由：CI / CDパイプラインの実装を支援するために、ツールチェーンを統合し、会社のより良い仕事を可能にするツールを導入します。
• とき：大規模組織内の移行時には、上記の役割はすでに満たされているが。
• 内容：エンジニア。基本的にはCI / CDパイプラインを設定し、作業のスループットから摩擦を取り除く方法で内部システムの統合を開始できるツールチームの一部です。
• 担当者：ツール、統合プロセス、リリース管理、DevOpsのプラクティスを経験したエンジニア。リリースプロセスでの人間のゲーティングをオートメーションに置き換えていることを理解している人。

質問リンクで説明されているDevopsエンジニアは、主にsysadminの役割であると主張します。この答えの背景にあるスキルをここで引用します：

登山用具。

• Puppet、Chef、または同等のものを使用した自動化/構成管理に関するLinux / Unix管理経験の豊富なバックグラウンド
• さまざまなオープンソーステクノロジーとクラウドサービスを使用する能力（AWSの経験が必要です）
• SQLおよびMySQLの強力な経験（NoSQLの経験もプラスです。Redisも使用しているためです）
• コードとスクリプトの実用的な理解（PHP、Python、Perl、Ruby）
• 常に利用可能な常時利用可能なサービスのベストプラクティスとIT運用に関する知識

このサンプルジョブの説明では、DevOpsエンジニアは、クラウドベースのインフラストラクチャ、自動化、診断に役立つコードの読み取り、および高可用性の実践とソリューションの認識に慣れているシステム管理者の単なるバズワードです。

この質問に見られるように、これはDevOpsプラクティスとdevとopsの間のサイロ破壊文化に大まかに関連しています。SysadminとDevOps Engineerの違いは何ですか？

システム管理者は、devopsの実践と文化にどれだけ慣れていても、会社の変革を推進するのにふさわしい人物ではないため、良いアイデアではありません。文化の変化を念頭に置いてこの人を雇うのではなく、ツール構成ビューを使用しますが、これはプロセスを壊す助けにはなりません。これは同僚にもひどく受け止められている可能性があり、事前に文化の変更が計画されていない場合は、変更に抵抗するだけです

devopsの獲得に向けた成功パターンについて、@ Jiri Kloudaの答えは、DevOpsエンジニアの許容できる役割についての素晴らしい概要と、それが価値をもたらし成功に役立つ変化のステップを示しています。

この答えはあなたにぴったりではないかもしれないと思いますが、私がしたことはここにあります

私は非常に忙しいeコマーススタートアップで働いている最初の開発者であり、信じられないほどのトラフィックがありました。会社はまだ若く、しばらくの間、私が唯一の技術的な社内リソースになると思います。

これを知って、ゼロシステム管理を行わなければならないような方法でインフラストラクチャを構築することにしました。

クラウドでホストすることにしました。そうすることで、システムのメンテナンスが不要になりました。操り人形の経験があるAWSエンジニアを探しました。一緒に、クラウドフォーメーションのコードとして記述された自動スケーラブルなインフラストラクチャを構築しました。すべての構成ファイルはパペット内でバージョン管理されていました。

これにより、開発者として、このdevopsの役割を引き受けることができました。pythonでコードリリースツールを作成しました。同じスクリプトを使用して、自動スケーリングされた新しいサーバーにアプリケーションをブートストラップしました。

これは非常にうまく機能し、今日、3年後、私はまだシステムメンテナンスを行いません。システム管理者（同じAWSエンジニア）が月に10時間働いており、彼の迷惑にならないように彼のスプリントを構築しようとしています。そのようにして、私は彼の時間を尊重し、できる限り最善の方法で彼のスプリントを管理します。

システムのパフォーマンスが低下している場合は、システムを終了するだけで、別のシステムが代わりに起動します。

この回答が何らかの形であなたに利益をもたらすことを願っています

DevOpsには多種多様な分野が含まれるため、DevOpsエンジニアを雇うべきではありません。すべての取引のジャックを雇うことによって、あなたはどれもマスターを雇わないでしょう。

DevOpsは必然的にチームベースの取り組みであり、1人の個人がチーム全体の期待をサポートすることを期待することはできません。DevOpsの範囲を検討してください。一人ではできません：

• [言語]でロックスター開発者になる
• 必要なすべてのRFCを知って、ネットワーキングの第一人者になる
• システム管理者になる
• エキスパートQAテスターに​​なる
• データベース管理者になる
• ストレージとバックアップに特化
• サイト信頼性エンジニアリングを知る
• 潜在的に他の分野も

上記の一部には、Windowsシステム管理者対Linux / Unixシステム管理者など、サブ分野もあります。または、複数のコーディング言語を使用している場合があります。

誰もおそらくこのすべての専門家になることはできません。つまり、DevOpsエンジニアに広告を出す場合、DevOpsチームの最も弱い領域がネットワーキングである場合、ネットワーキングスペシャリストの必要性を宣伝することはあまりうまくいきません。DevOps チームに。個人がDevOpsチームの特定の役割にピジョンホールされるべきではありませんが、DevOpsの範囲内にスペシャリストまたはサブジェクトマターエキスパート（SME）がいないふりをすることで、チームを傷つけます。DevOpsチームのすべての役割が同じであるようなサイロ化からふりをするまで、振り子を一方の端からもう一方の端に振り回すと、同じくらい多くの問題が発生する可能性があります。

チームメンバーに複数の分野でクロストレーニングを行うことは（特に重複する分野では）良いことですが、このような幅広い知識を習得できると期待することは、単に練習ではありません。

これは、DevOpsのすべての側面を知っていると言う人は、おそらくあなたに嘘をついていることを意味します。「DevOpsエンジニア」ではなく、DevOpsチームで働いている分野で最も弱い分野の専門家を雇います。

ASOSで実装するとき、私はこの正確な挑戦を受けました。私たちの目標は、自給自足のチームを持つことです。そのため、専用の役割を持つことはアンチパターンになりますが、私たちは現実の世界に住んでいます。そこに着く。

私たちがしたことは：

• DevOpsエンジニアの任期を失います。DevOpsは役職ではなく、私たち全員がすべきことです。

• 彼らをチームに展開しましたが、3人に1人しかいなかったため、彼らは行動することはできませんでしたが、チームが自分自身を改善し、自分の問題を解決するためのコンピテンシーと見なさなければなりませんでした（ガイダンス付き）

• コンピテンシーセンターとして機能し、企業の考慮事項（すべてのチームに影響を与えるもの）を処理するための中央機能も維持しました。

進化するにつれてこのモデルを確認しますが、私たちにとってはこれまでのところ効果的に機能しています

多くのことが考慮されているように思われるので、これに対する決定的な答えを得ることができるとは思わない。

• 会社がDevOpsプラクティスにどのように参加しているか
• 会社が提供するアプリケーションまたはサービスの種類
• あなたの会社の構造

ポジションのインタビューを終えたばかりで、DevOpsエンジニアという肩書きになりましたが、私がやっていることのいくつかはシステム管理者の仕事です。これは、会社の規模とアプリケーションの賢明な管理対象の性質のために、どうしても必要ありません。私がインタビューしたポジションの中には同じような肩書きを持っていたものがあり、彼らは経験が賢明な開発側の人をもっと探していました。彼らは、自動化を行うシステム管理者ではなく、コードの記述を増やすことを期待していました。SREは人気を博しているタイトルであるように思われるので、これが道のりかもしれません。私は自分が最後の仕事としてシステム管理者および自動化エンジニアとして働いていました。なぜなら、私は一部の時間にansibleとchef stackを書いていたからです。同社はかなり良いdevopsモデルを採用しており、全員が参加していて、開発者はopsと一緒に働いていましたが、彼らの将来はそうではなかったと思います。

私はこのポジションにいるので、いくつかの自動化で警shoeを鳴らそうとしていますが、解決しなければならない人々の問題があります。人々が行き来し、ワークフローの一部は、他の誰かがそのように設計したために設計されたものであり、人々の働き方に合うためではありません。

ですから、基本的には、職務内容を把握し、何らかの形で支払いに縛られたり、どちらかが適切な種類の人々を引き付けると思わない限り、タイトルについてあまり心配する必要はないと思います。

DevOpsの意味に関心があり、「1つの真の道」に従う場合。DevOpsエンジニアを雇うべきではありません。オートメーションエンジニア、デプロイメントエンジニア、プラットフォームアーキテクト、または必要なことを行う他の多くの役割を雇う必要があります。

真のDevOpsプラクティショナーであることがあなたにとって重要でない場合は、好きな名前で呼び出すことができます。