私は、DevOpsエンジニアであり、16人のエ​​ンジニアのチームに所属していても、時々一人の軍隊のように感じる苦労について、いくつかの本当に良い点を挙げたDevOpsの人と話をしています。

彼はさまざまな帽子をかぶっていますが、インフラストラクチャの仕事をしている開発チームにいます。彼は、多くの自動化、クラウド、コンテナ化などで働くクールな技術を愛しています。しかし、彼はチームopsで唯一の人であることに苦労していdevます。彼は開発マネージャーに報告しますが、インフラストラクチャマネージャーとより密接に連携します。

これは、私が話す多くのDevOpsプロフェッショナルに当てはまるようです。DevOpsのエンジニアが孤独なオオカミのように感じないようにするために何ができますか？

私が最初に考えたのは、「開発チームで、特に大量の自動化で作業するときに、彼だけがopを行うのはなぜですか？」です。ローンウルフ症候群に対処する機会があると思います。特に開発環境では、コードとしてのインフラストラクチャは負荷を共有するための優れたフレームワークを提供します。運用担当者は、アプリケーションのインフラストラクチャニーズを決定および定義する専門家である必要がありますが、開発者の役割が独立してできる限りのことを行えるプラットフォームを構築できる必要もあります。

チーム内のサイロのように聞こえます。古い習慣は激しく死ぬ。コーダーは、サーバーをスピンアップして強化することに不安を感じるかもしれませんが、純粋なdevopsモデルでは、そうするためのツールが必要です。devopsチームの運用担当者は、アプリ自体のインフラストラクチャを提供する責任を負いませんが、必要なものについての洞察と、アプリ開発者が自分でできる方法についてのガイダンスを提供する必要があります。それはほとんどメタインフラストラクチャモデルです。opsエンジニアは、開発チームから要求があったときにオンデマンドでインフラストラクチャを構築できるインフラストラクチャを構築します。

相談、コミュニケーション、責任の融合は、devopsチームの成功に不可欠です。

最初の欠陥はこの文にあると思います：

彼は開発マネージャーに報告しますが、インフラストラクチャマネージャーとより密接に連携します。

DevOpsは、サイロを取り除くことを目的とした文化的変化です。サイロが残っている場合、このエンジニアはあなたが彼と呼ぶ名前を付けたいものです。運用開発を行うエンジニア、自動化の専門家、インフラストラクチャを自動化する開発者。ただし、このエンジニアはDevOpsエンジニアではありません。
実際、「DevOpsエンジニア」は実際の役割ではなく、共通のチームで作業する開発者、システム管理者、QAテスター、およびアーキテクトを対象とするため、より「シャポー」です。

私がよく目にする問題は、人々がDevOpsの流行語に当てはまり、それを役職と見なしているのに、DevOpsが何であるかを本当に理解していないことです。このようにDevOpsを見ると、彼らはしばしば孤立して孤独を感じ、経営者や組織の賛同がなければ「孤独」であることの失敗や欠点を非難します。

あなたがそれを説明するように、このエンジニアは開発チームでオペレーションを行う唯一の人です。それが彼を「DevOpsエンジニア」にするわけではありません。（それが彼の組織で意味するものは何でも）彼の仕事は "DevOps Engineer"として提示されているが、彼のチームの他の人々はオペレーションに取り組むことを望まないので、彼は孤立して働いています。

正直に言って、常にopsとdevがあります。devopsの背後にある主なアイデアは、devからopsへの製品のハンドオフがないように責任を共有することです。主な目標は、チームにより多くのコラボレーションをもたらすことです。この役割を「DevOpsエンジニア」と呼ぶことは、同じレベルの専門知識で両方を行うことができるという名前で提案することにより、このアイデアを壊しています。

私の意見では、最初に行うべきことは、運用ツールをチームに提示し、ツールに関する基本的な知識を全員に提供し、運用ツールを構成/コーディングする責任をチーム全体に移すことです。この背後にある主なアイデアは、「すべての操作を実行するもの」から「チームへの参照実装をサポートおよび提供するもの」に移行することです。

これは、経営陣の再編成よりも最初のステップとして、より簡単な方法で実行可能なものを提供することにより、他の答えを補完します。

この種の状況におけるDevOpsエンジニアにとって最も重要なことは、（a）管理のコミットメントと（b）必要な予算を獲得することです。両方の詳細については、続きを読んでください...

管理コミットメントを取得

いったんそれが実施されると、そのようなDevOpsエンジニアにとって物事は簡単になります。特に、（あらゆる種類のパーティーからの）抵抗がゲームに登場するたびに。私を信じてください、そのような抵抗があるでしょう、それは次のような挑戦です：

• なぜ変更しなければならないのですか？私はすでにX年間行ったことをやり続けたいと思っています！
• 私が持っている（技術的な）力を失い、あらゆる種類のワークフロー手順を完了して、実稼働で愚かな修正を取得したくないので、5時間（または数日...）ではなく5分かかります。
• ...（ここにさらに12個の箇条書きを追加できます...）。

これらの課題が発生するたびに、DevOpsエンジニアは次のように言う必要があります。

すみません、私はただ仕事をしています...上級管理職からの指示に基づいています。

必要な予算を取得する

必要な予算を取得する効果的な方法は、DevOpsのさまざまなプラクティスの有形および無形のメリットを説明する適切なビジネスケースを作成/提出することです。

以下は、これらのことが起こったいくつかの企業に雇われたSCMコンサルタントとして、私が経験した実際の事例です。SCMはDevOpsの一部にすぎませんが、私が専門知識を持っている分野です...

1.自動化の利点

2人（!!!）のコンピューターオペレーター（入力する予定のコンソールコマンドをもう入力しなかった）からのストライキにより、2つの工場の間の途中で列車を停止する必要がありました（工場のシステムのため）列車が向かう場所では、列車の取り扱いに関する重要なデータは入手できませんでした）。

SCMシステムを実装することにより、多くのオペレータコマンドが自動化されました。

2.ソフトウェアライセンスコストを削減する

一部のソフトウェアベンダーは、（時代遅れの）SCMソフトウェアの年間料金を引き上げることを決定しましたが、管理者は同意しませんでした。そのため、彼らは特別なプロジェクトを作成し、いくつかの代替SCMソフトウェアに置き換えました。

プロジェクトの予算は、支払いを続けたくない年間料金と同じでした。これには、プロジェクトを成功させるために他の大陸（私のような）のエンジニアを派遣することも含まれていました。

3.運用コストを削減する

一部の大手保険会社は、FTPのソフトウェアを使用して、ソフトウェア修正プログラムを全国の約13.000台のミッドレンジコンピューター（AS / 400）に転送していました。1回の転送のコストは約4米ドルでした（1回の転送で13.000 x 4 = 52.000米ドル）。このソフトウェアは、約150人の開発者によって開発/保守された120.000のコンポーネントで構成されていました。1人の開発者がこれらの120.000コンポーネントのいずれかで1（小さな）ミスを犯し、生産に至り、さらに52.000米ドルのコストがかかる緊急の修正が必要になる確率について計算します（転送のみ！）。

適切なSCMシステム（管理されたテスト環境、承認など）を実装することにより、この会社は大幅なコスト削減を達成しました。考えてみてください。SCMシステムが緊急修正を20回だけ転送する必要を防げる場合、52.000 x 20 = 1.040.000 USDのコスト削減になります（SCMシステムを実装するための予算は不要で、ほんの少ししか必要ありませんでした）その量の仕事を成し遂げるために）。

4.利用不能のコストを削減する

上記のケースで十分な説得力がない場合は、主要なクレジットカード会社のシステムが世界中で利用できないと考えてください。私は1秒の利用不能が1.000.000米ドルを要すると言われました。

それはおそらく、非常に長い間、そのような企業が洗練されたDevOpsツールをすでに何十年も使用している理由でもあります。毎秒、彼らはビジネスにいないので、彼らは幸運を犠牲にします。

TL; DR：上級管理職は通常気まぐれで怒りやすいので、物事を徐々に改善しながら、別の視点を得るために心を少し曲げることをお勧めします。

（彼の問題は、主に古典的な操作をしているように見える他のops同僚ではなく、主に嫌がる開発者にあると仮定しています。）

IMOは、DevOpsを使用していても、すべての開発者が本格的なDevOpsの第一人者である必要があることを必ずしも意味しません。ある特定の人々のグループに1人か2人の本当の専門家がいて、残りは多かれ少なかれ一緒にいるのは普通のことです。ワークロードがその人にとって大きすぎない限り、そして彼が自分のサイロを構築する代わりにスクリプトなどで知識をカプセル化することができる限り、それは問題ありません。

起こってはならないことの1つは、DevOpsの人が自動化を行うことです。他のすべての人は、自動化を避けるために全力を尽くします（つまり、CI / CDパイプラインを通過して、環境の1つで手動で作業を行います）。これは、IMOを停止する必要がある主なものです。そのための解決策の1つは、ペットではない方法に非常に力を入れることです。つまり、できる限り早くVMまたはコンテナを容赦なく破棄し、新しいものを継続的にスピンアップします。

第二に、もちろん、誰もが自動化が何をしているのかを知っている必要があり、少なくとも理論的には、おそらくある程度掘り下げて、自動化機械を起動することができます（つまり、すべてがコミット/プッシュから実行され、その後開発者がコミットするときにバックグラウンドで何かが発生するという事実に注意し、非常に最新である必要があります）。CI（/ CD）パイプラインは非常に目に見える必要があり、誰もが常に認識しているものでなければなりません（つまり、開発者がそれを壊したとき）。

第三に、当然の「1人は、」（例えば、用Dockerfile後Dockerfileを作成し、彼は彼の同僚のために卑しい、日常的な作業をしないことに注意する必要があり、その成果物...）。

第4に、DevOps担当者が作成するソリューションは、当然ながら、測定可能な方法で過去の手動によるアプローチよりも実際に優れている必要があります。その場合、彼が彼の改善を示すことが可能であるべきです; つまり、すべての人にとって物事が容易になる方法、またはパイプの後半の段階でバグを導入することが不可能であるように見える方法を実証します。彼はします。可能であれば、それは彼のチームのブラウンバッグセッションと多くの福音宣教を必要とします。

明らかに、このような消極的な環境では、おそらく完全に自動化されたCDソリューションや、トランクベースの開発にはすぐには届かないでしょう。しかし、私は選ばれることについてあまり心配しません。彼は専門家であり、仕事をうまくやっていれば、チーム全体が非常に徐々に良くなります。

そして最後に、長年の苦労の末、同僚との目に見える改善が見られない場合、他の道を探すことが常に可能です（会社の内外で）。DevOpsのすべての経験を彼のベルトの下で持つことは、最近の仕事を探すための優れた基盤です...

ここでは、文化としてのDevOpsについて話している多くの素晴らしい回答、管理と連携する方法についての提案、DevOpsチームまたはエンジニアのやるべきことの定義を支援しています。それぞれが素晴らしいと思うし、多くの答えの実際の説明は100％正しいかもしれませんが、それでもお互いに非常に異なっているか、完全にあいまいです...それはDevOpsです！

この答えは、経験から見た私の唯一の視点であり、規範やベストプラクティスを示すものではないかもしれません...

しかし、DevOpsの同僚が不平を言っているのは、特に文化的な考え方ではなく、DevOpsエンジニアの役割を任命されたときに、DevOpsを困難かつ困難にしているものの性質です。

個人的に、私は好きで、私はまだ貴重な貢献をするだけでなく、自分自身を助けるために他の人を説得しながら、自分の限界を設定してもらうため、一匹狼であること、それによって私を助け、内訳は、ITがサイロ。

一部のサイロはそのまま残りますが、大丈夫です。DevOpsの使命は、それを回避し、そのサイロをできるだけ取るに足らないか見えないようにすることです。

同僚がDevOpsエンジニアであることを好まないことに気付いている、または気付いていない可能性があります。

比較的言えば、devopsの概念は新しく、私の意見ではまだ定義されています。現在、devopsエンジニアの役割を果たしています。私にとってこれは、開発チームと運用チームの両方が使用するツールとプロセスを促進および開発し、会社の収益を生み出す製品に集中できるようにすることを意味します。運用チームと開発チームは、必要に応じて独自のサーバーを起動します。製品のCIを接続し、プロセスが適切であることを確認し、改善/自動化できるプロセスを探します。私は、営業から倉庫、開発者および運用（QAおよびリリースマネージャー）まで、すべての部門と会って、彼らが何をしているか、どのようにプロセスを改善できるかを確認します。

私にとって、DevOpsとは、ソフトウェアシステムの開発と運用が、開発チームと運用チームを分離するのではなく、1つのチームの責任になることを意味します。これは双方向の通りです。最高のチームは、1つの分野の専門家であり、いくつかの関連分野に精通している「T型」の人々で構成されています。

• Opsの経験を持つチームメンバーは、ベストを尽くす（例：Ops）こと、ベストを尽くすことの基礎（例：Ops）を他の人に教え、関連分野の仕事を学習して行うこと（例：開発タスク）が期待されます。
• 開発経験のあるチームメンバーは、ベストを尽くす（開発）、他の人にベストの基本を教える（開発）、関連分野での仕事を学ぶ（Opsタスク）ことが期待されます。

そのため、DevOpsエンジニアが孤独な気分にならないように、インフラストラクチャの設計方法のエキスパートであることを認めつつ、システムの実行方法を開発者に教えてください。

彼が最初から高レベルのアーキテクチャに関与して、彼の専門の懸念を紹介できるようにします。（DevOpsを導入する前は、アーキテクチャ図面は常に、ロードバランサーや冗長サーバーなどの「ささいなこと」につやがありました。現在、そのようなことは最初のスケッチの一部です。）

チームに冗長性を構築し、「ドラッジ」ジョブを公平に分散させるために、開発者が日常の日常的なOpsタスクのいくつかを行うことを期待します。

実行するOpsのようなタスクがない場合は、Devの努力に貢献することを期待してください。私が知っているDevOpsの中には、データベースが彼らの専門分野の自然な拡張であり、それを一般化できるかどうか分からないものがあるようです。

DevOpsのエンジニアが孤独なオオカミのように感じないようにするために何ができますか？

言い換えするには- DevOpsチームのエンジニアが何ができるか、自分自身を / 彼女自身は一匹狼のように少ないと感じますか？

文化と管理のサポートの欠如は、方程式の一部にすぎません。他の部分は、私の意見では、DevOpsの知識は複雑なコンテキストを指すことが多く、実際の例を参照することが重要であると考えています。

したがって-孤独なオオカミのように感じないでください。こちらのようなDevOpsコミュニティまたはツール固有のグループとGitHubに参加してください-少なくともあなたは唯一のオオカミではないという気持ちです;-)