チームの開発者を説得して、「あなたはそれを構築し、あなたはそれを実行する」ことを受け入れることができますか？

チームの開発者を説得して、「あなたはそれを構築し、あなたはそれを実行する」ことを受け入れることができますか？それにより、私はヴェルナー・フォーゲルスからのこの引用を念頭に置いています：

開発者に操作上の責任を与えることにより、顧客と技術の両方の観点から、サービスの品質が大幅に向上しました。従来のモデルでは、開発と運用を分離する壁にソフトウェアを持ち込み、それを捨てて忘れます。Amazonではありません。それを構築し、実行します。これにより、開発者はソフトウェアの日々の運用に触れることができます。また、顧客との日々の接触にもつながります。この顧客フィードバックループは、サービスの品質を向上させるために不可欠です。

私は具体的に次のような開発者のセットを考えています：

• オペレーション関連のタスクについてはほとんど/まったく言及せずに、開発者の役割に雇われました。
• 伝統的にopsチームに「壁を越えてコードを投げる」。
• 従来、9〜5の勤務スケジュールがあり、特に通常の営業時間外は、「ポケットベルの義務」、災害復旧への参加、事後分析などに積極的に敵対しています。（注：これについては非常にまれな停止しか考えていません。このチームのワークロードに営業時間外のカスタマーサポートを追加することは提案していません。）
• 現在、アプリケーションの監視または警告の作成/サポートについては責任を負いません。

新しいクラウドマイクロサービスを急速に開発しているチームがいて、これらのサービスをopsチームに引き渡すのが次第に深い知識を得られないために最適ではないようになっているとしますそれらを効果的に管理および監視するために必要なサービス。「構築して実行する」ことは、タスクが各担当チームメンバーに委任される可能性があるため、このチームにとってはうまく機能します。そのため、このチームは、インフラストラクチャの設計、サービスの監視/アラートツール、および（非常にまれに）停止イベントへの対応に参加し始めました。

実世界の例に裏付けられた方法論に特に興味があります。これが他の職場でどのように正常に実装されたか、そしてこれを実装する際に従うべき標準的な手順がある場合はどうですか？回答をサポートできる記事へのリンクは非常に役立ちます。

最も簡単な方法は、パフォーマンスの目標を変更して、信頼性とコードの提供をベースにすることだと思います。会社は両方なくして成功することはできないので、それを売ります。彼らがパフォーマンス目標を達成するための最良の方法は、運用に関与することです。

最終的には、これが会社が成功するための最善の方法であるため、彼らが成功するために彼らを納得させる必要があります。それは難しいことであり、最初から参加することは期待できません。彼らも値で販売する必要があります。

ビジネス文化に影響を与えることになると、おそらく最もよく知られている方法は、よく知られている「カエルをoilでる」方法です。開発者としてこれらのタスクをゆっくりと導入する必要があります。なぜなら、私自身（開発者として）は、この新しい責任を一度に抱えることにalkするからです。

まず、通常の営業時間内にのみ実行される1つまたは2つの新しいタスクを導入することから始めます。彼らはdevopの実行方法を学ぶ必要がありますが、これは（この時点までの）コードのみのdevの学習プロセスであり、ある程度の監督が必要な場合があります。彼らはまた、あなたが9-5に慣れていると言っているので、彼らは彼らのワークライフバランスを変えるという考えに敵対するでしょう。この時点で、後で使用するために新しいプロセスにデータを記録します（それらにこのコードを書いてもらうと、データは常に役立ちます）。

導入する新しいdevops-yタスクがなくなったら（最初、2番目、および4番目の箇条書きはほぼ完了します）、導入した最初のタスクを標準作業時間外に実行する候補として持ち込みます。あなたはこれにいくらかの反発を見るかもしれません、そしてあなたがこれをどれほど強く押し、そして5で終わらせる文化がどれほど重く染み込んでいるかによって、いくらかの消耗さえ見るかもしれません。これを防ぐために、データが標準時間を超える作業はまれであり、極端な状況でのみ発生し、ビジネスと顧客の両方に大きな利益をもたらすという考えをサポートすることを願っています。データがこれをサポートしていない場合は、この選択の結果に対処する準備ができているはずです。

でもデータと、まだ、開発者がコードを警告/モニタリングを書く（彼らはなるので、持っている方が簡単かもしれdevの OPSが、依然として主にDEV）とフロントラインのサポートなどの代替OPSチーム保つ（いくつかの他のものが提案されています）。私が言ったように、小さな変更はバックラッシュを避けるために重要です。開発者の市場は現在すでに強いので、特にすでに開発者のスキルがある場合は、標準時間を超えて開発者の仕事を統合するのは難しいでしょう。買い手責任負担！

特にDevOpsの外を見ると、大規模な（っぽい）エンタープライズ環境について話している場合、SAFe方法論はこの種の動作を促進するかなり良い方法を持っています。

基本的には、いくつかの重要な段階に要約されます。

• プロジェクトはリリーストレインとして開始されます。意図（および資金提供者の期待）は、長期にわたって実行されることです。私は何年も話していますが、これは「3か月間チームを立ち上げてから立ち止まる」ビジネスではありません。

• プロジェクトの過程で、リリーストレインは必然的に、新たに実現されたビジネスチャンスに基づく新しいプロジェクト要件と、メンテナンススタイル作業の継続的な税の両方として、より多くの人々を集めます。

• ほとんどの場合、列車は最初の増分を100％プロジェクト/変更チームとして実行し、2番目の増分は作業の実行に一定の時間を割り当てます。3番目の増分管理は、彼らが問題を抱えようとしていることを認識し、チームを追加してRunオーバーフローを処理しようとします。

• プロジェクトチームがメンテナンス作業にとどまることなくプロジェクトの成果を出し続けることができ、列車に参加する新しいチームがすぐに100％サポートチームになることは期待されず、代わりに処理される予定だった変更作業のかなりの部分を、デフォルトで構築している製品を所有しているデリバリーチームで終わることになります。それらがすぐに実行チームであることに気付く必要はありません。代わりに、日々の活動にゆっくりと統合されます。

このモデルに明らかに弱点があるのは、ビジネスの価格設定です。一般的に、変更リソースに対して実行リソースよりも多くの支払いを期待しています。通常、主要ベンダーとの実行契約は固定価格であり、その目的は継続的な改善でコストを節約することです。

そうは言っても、リリースチームの一部として立ち上がった変更チームが単に継続的な改善を提供することを考えるのはそれほど難しいことではありません。新しいプロジェクトの提供に集中し、「通常のビジネス」作業にあまり関心を持たない能力を向上させる何かを構築または実行できる場合、それはバックログに記録され、優先順位付けされますリリーストレイン。

私見You build it, you run itは文字通りとるべきではありません。始めに-それはほとんど罰のように聞こえます;）

ソフトウェア開発プロセス（実稼働環境など）で使用されるツールまたはツールセットを長期間にわたって合理的にサポートできるのは、1人の個人または小さな開発者チームですらありません。そこに行って、それをやった:)

サポートの義務は、ツール（セット）の顧客ベースが拡大するにつれて拡大する傾向があります。これらの任務を独占的に引き受ける場合、開発チームは最終的にほとんどのサポートを行うことになり、今後の開発のための時間はほとんど/まったく残りません。事実上行き止まり-そのような環境で何人の開発者が回り続けたいですか？

開発チームのメンバーに対するサポート業務への長期的なエクスポージャーのフラストレーション、ストレス、およびその他の影響を防ぐには、プロのサポートチームの第1ラインを持つことが重要です。

もちろん、第1ラインのサポートチームは、直接カバーできない問題については、開発者チーム（ここでも、個人ではなくチーム）にフォールバックします。はい、最初は難しいかもしれませんが、状況は良くなります。それはコラボレーションでなければなりません-それはDevOpsの目的の一部です。

これは最終的に会社の規模と構造に依存します。あなたの会社が参加できる3つの段階があります：

1. スタートアップステージ（150人未満のエンジニア）。もちろん、開発者は独自のソフトウェアを実行する必要があります。誰もがスタートアップでそうしています。運用チームさえいない場合もありますが、たとえそれを行ったとしても、それは小さく、進行の速度が非常に速いため、他のチームでそれを実行するのに十分な速さで他のチームで実行するために必要な知識を渡す方法がありません成功する。

2. 中規模ビジネス（150人を超えるエンジニアが、単一の運用チーム）。この段階で、会社の解約率が高くなり始めます。ソフトウェアを構築するエンジニアは、それを実行するために必ずしも固執する必要はありません。皆さんはもう誰も知らないので、誰もが効果的にコミュニケーションを取ることは困難です。それは混乱に変わり始めます。この段階では、すべてのチームがソフトウェアを運用可能にする必要があるが、必ずしも運用する必要のないGoogleモデルに移行したいと考えています。彼らは最初にそれを操作しますが、ソフトウェアの構築の大部分は、操作チームが実行にサインオンできるほど負荷が小さいポイントまで操作コストを削減することです。その場合にのみ、完了と見なされます。

3. 複数のビジネスユニットを持つ大企業（それぞれに独自のオペレーションチームがあります）：この段階で、すべてのチームが独自のサービスを開発および運用するAmazonモデルに戻ることができます。各ビジネスユニットは、全員がお互いを理解できるように十分に小さくする必要があるため、約150人のエンジニアがいて、それぞれを基本的にスタートアップとして運営しています。Amazonには、各AWSサービスが多かれ少なかれ別々に動作しており、それらに対して機能します。

あなたの会社がどの段階にあるか、および/またはそれに移行しているかを把握し、それに応じて行動する必要があります。「万能」ソリューションはありません。

これに対する私の考えは（もし私がそのような命令に直面した場合、またはあなたがそれを呼ぶものなら何でも）、 " What else would you expect?!?!"のようなものになるでしょう。なぜなら、誤って：

• それなしでは生きられない
• 私は自分の（犬の）食べ物を食べるのが大好きです。

もう少し説明しましょう...

私のビジネス/趣味/情熱はscmで、より具体的にはメインフレーム環境です。そして、（顧客のニーズに合わせてものを微調整するために）私がどこに行っても、私が課す最初の要件は（私の契約で）、私たちが実装するシステムに対して行われた調整は、まったく同じシステムを介して行われるということです。そして、そうすることで（本当、それは数時間、最大で半日かかる）、それからこれらの利点を得ることができます（不完全なリスト）：

• システムを稼働させるために行ったことはほとんど文書化しません。質問がある場合は、システムに照会するだけです（そして、お客様にシステムの照会方法を私の助けなしで教えます）。
• Xか月/年で（新しいリリースにアップグレードするために）呼ばれたら、私は以前に「私」が何をしていたかを知りたい（覚えている）（そして私が信頼する唯一のことは、システムが私に言うこと、を思い出させます）。
• サイトで特定のことを行う方法（命名規則を覚えるのは難しい）について、または「システム」に必要な権限を付与するように説得するために、顧客に一度だけ尋ねる必要があります（私ではなく...）。
• あなたはしているcontinuously生産に...独自のシステムをQA-テスト。自分自身でバグ、論理エラー、または機能の欠落（およびそうでないもの）が発生する可能性があります。そして、それらはできるだけ早く対処するように非常に動機付けられています...例えば、より生産的になります。
• ...そして、もしあなたが望むなら、私はさらに多くの理由を追加することができます...

ただし、自宅でこれを試す前に、避けるべきいくつかの落とし穴に注意してください。

• あなたがしたい誰もが（企業の管理者/所有者？別名）のみ1「例外」はパーティーを台無しに可能性があるため、あなたがあなたのシステムを信頼することができると思うだろう（、（システムを使用）パーティーに参加したが、その後誰かが何かをしましたシステムに確認/使用せずに）。それらのケースは発見するのに数日かかるかもしれません...
• 新しいユーザーは、この（新しい）システムを使用すると、（以前に使用したものと比較して）仕事を完了するのに時間がかかることに不満を感じるかもしれません。そして、それが理にかなっているところならどこでも、彼らは仕事を終えるのが遅い理由を言い訳として使うでしょう。その時点で、プロジェクト/システムが非難される可能性があるため、上位管理者があなたをカバーする方がよいでしょう。
• 自分のシステムと、ニーズに合わせてシステムを構成する方法を知っていることを確認してください。サンプルとして（私の場合）：運用環境を使用して実験環境に配信するようにシステムを構成しますが、その逆ではありません...過去に起こったことを見てきました...テストシステムを使用（悪用）して、高度に保護された環境に配信します。