DevOps、開発は食べて維持するのですか?



Devops Is Development Eat

640?

著者:マシュー・スケルトン



この記事は、DevOps Times Community HighSchoolから複製されたものです。




ほとんどのチームでは、開発と運用および保守の間に一連の競合とゲームがあります。


一部の人々は、DevOpsの出現により、開発、運用、保守がもはやお互いを愛しなくなったと言います。それ以来、彼らは手を取り合って、コーディングしてバグを見つけて喜んでいます。




しかし、一部の人々は、DevOpsは食べて維持するために考案することであると言います。


この場合、さまざまなチーム構造がDevOpsの開発にどのように影響しますか?


以下をご覧ください、あなたはあなた自身の答えを持っています。


前書き

640?wx_fmt = png


組織でDevOps関連のアクティビティを開始する主な目的は、コストを削減したり、自動化を強化したり、構成管理から何かを推進したりすることではなく、顧客やビジネスへの価値の提供を改善することです。これは、組織ごとに異なるチーム構造が必要になる可能性があることを意味します。効果的な開発と運用および保守の協力を実行するため。


あらすじ

640?wx_fmt = png


どのDevOpsチーム構造またはトポロジが組織に適しているかは、いくつかの要因によって異なります。

  • 組織の製品ポートフォリオ:コンウェイの法則によれば、この場合は独立したチームが少ないため、製品が少ないほどコラボレーションが容易になります。

  • DevとOpsが共通の目標を持っているかどうかにかかわらず、技術的リーダーシップの範囲、強さ、および有効性。

  • 組織には、IT運用および保守部門を「ハードウェアラック」および「構成サーバー」からバリューストリームとの実際の整合性に変更する必要性または能力がありますか。また、ソフトウェアの研究開発チームが運用および保守の要件を真剣に受け止めているかどうか。 。

  • 組織には、現在のO&Mの問題を解決する上で主導権を握る能力またはスキルがありますか。


もちろん、ここで説明するトピックはさまざまなトポロジであり、タイプは、どのモードが適切であるかを評価するのに役立つリファレンスガイドまたはインスピレーションとして使用されます。実際、複数のモデルまたは1つのモデルを別のモデルに変換するのに最適な方法であることがよくあります。


では、DevOpsチーム構造はどのように発展するのでしょうか?明らかに、すべての組織に理想的な構造やチームトポロジはありません。ただし、チーム構造の場合は、いくつかの異なるモデルを参照すると便利です。そのうちのいくつかは、特定の組織により適しています。これらのチーム構造(または「トポロジ」)の長所と短所を調査し、コンウェイの法則を検討することで、組織内のDevOpsプラクティスに最も効果的なチーム構造を決定できます。

これらのDevOpsトポロジのほとんどは、特に他の場所で説明されています。CollabNetのLawrence Sweeneyは、Ben Kepesブログへのコメントでここで説明したアンチタイプB(独立したDevOpsチーム)について話しました。


タイプ3(インフラストラクチャサービスとしての運用と保守)およびタイプ1(開発と運用と保守のコラボレーション)。 DevOpsGuysには12個のDevOpsアンチパターンがリストされており、Jez Humble、Gene Kim、Damon Edwards(および他の多くの人)も同様のことを言っています。ここに3つの「トポロジ」を追加しましたが、これに関連するいくつかの議論(共有操作、DevOps-as-a-Service、および一時的なDevOpsチーム)を見たり聞いたりしていません。


DevOpsアンチタイプ

640?wx_fmt = png


いくつかの悪い習慣を見ると、それらを「アンチタイプ」と呼ぶことができます(たとえば、ユビキタスな「アンチパターン」が普及した後)。
A:開発と運用の分離B:個別のDevOpsチームC:開発には運用と保守は必要ありませんD:ツールチームE:システム管理者F:開発には運用と保守が含まれますG:開発とDBAの分離

アンチタイプA:DevとOpsの分離

これは、DevとOpsの分離の古典的な「壁を越えて投げる」スタイルです。これは、需要点を早期に抽出でき(DONEは「完全な機能」を意味しますが、本番環境では使用できません)、開発者が操作に関連するコンテキスト情報を持っていないため、ソフトウェアの操作と保守が損なわれることを意味します。とメンテナンス。メンテナンススタッフには、ソフトウェアがオンラインになる前に開発者に参加して問題を解決する時間や動機がありません。

このタイプのトポロジーが良くないことは誰もが知っていますが、少なくともアンチタイプA(開発と運用と保守の分離)が問題であることはわかっているので、似たようなトポロジー構造がたくさんあると思います。

640?wx_fmt = jpeg


アンチタイプB:個別のDevOpsチーム

別のDevOpsチーム(アンチタイプB)は通常、マネージャーまたはエグゼクティブから来て、「このDevOpsのことを少し必要とする」と判断し、「DevOpsチーム」(おそらく「DevOp」と呼ばれる人)を開始します。 DevOpsチームのメンバーはすぐに別のグループを形成し、DevとOpsをこれまで以上に分離しました。これは、「無知なDev」や「恐竜のようなOps」が消去されないように、役割、スキル、ツールセットを守る必要があるためです。

個別のDevOpsチームが実際に意味をなす唯一の状況は、チームが一時的な場合、たとえば12か月または18か月未満であり、その明確な目的は、DevとOpsを近づけて、承認するときに明確にすることです。時間が経つと、このチームは冗長になります。これは私がタイプ5DevOpsトポロジーと呼んでいるものです。

640?wx_fmt = jpeg


アンチタイプC:開発には操作とメンテナンスは必要ありません

このトポロジは、特に新しいプロジェクトやシステムの開始時に、開発者と開発マネージャーの間の無実と傲慢さの組み合わせです。 Opsが廃止されたと仮定すると(「クラウドができましたよね?」)、開発者はO&Mのスキルとアクティビティの複雑さと重要性を大幅に過小評価し、O&Mや余暇には必要ないかもしれないと信じていました。 O&Mが行うことを行うことができます。


このアンチタイプCDevOpsトポロジでは、最終的にタイプ3(IaaSとしてのOps)またはタイプ4(DevOps-as-a-Service)トポロジが必要になる場合があります。彼らのソフトウェアがより深く複雑になるにつれて、O&Mは開発作業を必要とし始めます '(コーディングとしても知られています)'。そのようなチームがO&Mを重要で価値のある分野として認識し、ソフトウェア開発におけるその重要性を認識すれば、多くの苦痛で不必要な(そしてかなり基本的な)O&Mエラーを回避することができます。

640?wx_fmt = jpeg


アンチタイプD:ツールチームとしてのDevOps

現在の開発チーム(ユーザーストーリーの実装)の速度に影響を与えることなく、パイプライン、構成管理、環境管理、およびその他の必要なツールの展開を担当するDevOpsチームが設立されます。同時に、Opsの人々は孤立して作業を続け、開発チームは「アプリケーションを壁に置く」ことを続けています。

この専任チームの結果はツールチェーンの改善に役立つ可能性がありますが、その影響は限定的です。アプリケーション開発のライフサイクルでは、初期の運用と保守の参加とコラボレーションが不足しているため、根本的な問題が依然として存在します。

640?wx_fmt = jpeg


アンチタイプE:変装したSysAdmin

このタイプの反転は、エンジニアリングの成熟度が低い組織で一般的です。彼らは業務を改善し、コストを削減したいと考えていますが、ITをビジネスのコアドライバーと見なすことはできません。 DevOpsの業界での成功は今や明らかであるため、彼らは「DevOpsを実行する」ことも望んでいます。残念ながら、彼らは現在の構造と関係のギャップを反映していませんでしたが、Opsチームに「DevOpsエンジニア」を雇いました。


DevOpsは、SysAdminと呼ばれる役割を再発明したものであり、実際の文化的/組織的な変更は行われていません。平凡な採用担当者は自動化とツールのスキルを備えた候補者のみを探しているため、このタイプの逆転はますます広まっています。残念ながら、対人コミュニケーションスキルは、DevOpsを組織内で成功させることができます。

640?wx_fmt = jpeg


アンチタイプF:O&M組み込み開発チーム

組織は独立した運用および保守チームを望んでいないため、開発チームはインフラストラクチャ、管理環境、および監視を担当します。ただし、このプロジェクト主導または製品主導のアプローチは、これらのプロジェクトがリソースに制約があることを意味し、優先順位によって操作方法が貧弱になり、ソリューションが半完成になります。


このアンチタイプでは、組織は効果的なIT運用に必要な重要性とスキルを認識していません。

640?wx_fmt = jpeg


アンチタイプG:開発およびDBAの分離

これは、複数のレガシーシステムが同じコアデータセットに依存している中規模から大規模の企業で顕著であるアンチタイプA(開発と運用および保守の分離)の形式です。これらのデータベースはビジネスにとって重要であるため、多くの場合、ビジネスエリアの専任のDBAチームが、メンテナンス、パフォーマンス調整、およびディザスタリカバリを担当します。これは理解できますが、問題は、このチームがデータベース変更のポータルになると、小規模で頻繁な展開(DevOpsと継続的デリバリーの中心的な信条)の障害になるということです。

さらに、アンチタイプAの運用と保守と同様に、DBAチームはアプリケーション開発の初期段階に関与していなかったため、データの問題(移行、パフォーマンスなど)が配信サイクルの後半で発見されました。複数のアプリケーションデータベースをサポートすることの過負荷と相まって、最終的な結果は継続的な「消火活動」と展開の圧力です。

640?wx_fmt = jpeg


DevOpsチームトポロジ

640?wx_fmt = png


アンチタイプの反対側に立って、DevOpsに適したいくつかのトポロジを検討します。

1:開発とO&Mコラボレーション2:共有O&M 3:インフラストラクチャサービスとしてのO&M 4:DevOps-as-a-Service 5:一時的なDevOpsチーム6:DevOpsエバンジェリストチーム7:SREチーム8:コンテナドライバー9 :データベース機能


タイプ1:開発と運用および保守とのコラボレーション

これがDevOpsの「喜びの国」です。開発チームと運用チームの間のスムーズなコラボレーションです。すべてのメジャーが必要ですが、共有する必要もあります。多くの独立した開発チームが存在する可能性があり、それぞれが個別のまたは半独立した製品スタックに取り組んでいます。


つまり、このタイプ1モデルを確立するにはかなりの組織変更が必要であり、技術管理チームで非常に競争力があります。開発者と運用部門は、明確な表現と明確で合理的な共通の目標(「高品質の配信、変化を受け入れる」など)を持っている必要があります。運用および保守担当者は、開発者とペアを組み、テスト駆動コーディングスキルとGitツールを習得する必要があります。開発では、運用および保守機能の要件を真剣に受け止め、ログに参加して達成する運用および保守担当者を見つける必要があります。現在の状況からこの状態まで、これらすべてはかなりの文化的変化を必要とします。

640?wx_fmt = jpeg

タイプ1の適応性:テクノロジー主導の組織。
有効ポテンシャル:高い


タイプ2:完全に共有されたO&Mの責任

運用保守担当者が製品開発チームに統合されている場合、タイプ2のトポロジーが見られます。 DevとOpsの分離はほとんどなく、誰もが共通の目標を非常に重要視しています。これはタイプ1の形式(開発と運用および保守のコラボレーション)ですが、いくつかの特別な機能があります。


NetflixやFacebookなどの組織は、このタイプ2トポロジを実装したWebベースの製品を効果的に実装していますが、純粋に製品の観点からは、予算の制約と複数のコンテキストの切り替えがあるため、あまり適用できない可能性があると思います。製品ライン。これにより、DevとOpsがさらに分離される可能性があります(たとえば、タイプ1モデルに戻る)。このトポロジは、明白または目に見える運用および保守チームがないため、「NoOps」と呼ばれることもあります(ただし、Netflix NoOpsはタイプ3(IaaSとしてのOps)の場合もあります)。

640?wx_fmt = jpeg

タイプ2の適応性:組織には、単純なWebベースの製品またはサービスしかありません。
有効ポテンシャル:高い


タイプ3:インフラストラクチャサービスとしての運用と保守

IT運用および保守部門で非常に伝統的な組織の場合、変更を迅速に受け入れることはできません。パブリッククラウド(Amazon EC2、Rackspace、Azureなど)ですべてのアプリケーションを実行する組織の場合、アプリケーションのデプロイと運用機能を提供するだけでよい弾力性のあるインフラストラクチャチームとして運用と保守を使用できます。したがって、内部運用チームは、AmazonEC2またはサービスとしてのインフラストラクチャと直接同等です。


Dev内のチーム(おそらく仮想チーム)は、運用および保守機能、インジケーター、監視、サーバー構成などの専門知識のソースとして機能し、IaaSチームとほとんど通信する可能性があります。ただし、このチームは、TDD、CI、反復型開発、人事ガイダンスなどの標準的な手法に従った開発チームです。


IaaSトポロジには、実装を容易にする潜在的な効果(Ops担当者との直接コラボレーション)があり、タイプ1(開発と運用のコラボレーション)を後で試すよりも早く価値を得ることができます。

640?wx_fmt = jpeg

タイプ3の適応性:さまざまな異なる製品とサービスを備えた組織、従来の運用および保守部門、またはそれらのアプリケーションが完全にパブリッククラウドで実行されています。
有効ポテンシャル:中


タイプ4:外部サービスとしてのDevOps

一部の組織、特に小規模な組織では、ソフトウェア運用を主導するための資金、経験、またはスタッフがいない場合があります。開発チームは、Rackspaceなどのサービスプロバイダーと連絡を取り、テスト環境の確立とインフラストラクチャと監視の自動化を支援し、ソフトウェア開発サイクル中に実装されるさまざまな運用機能に関するアドバイスを提供する場合があります。 DevOps-as-a-Servicedと呼ぶことができるのは、自動化、監視、構成管理の目的と実装を理解している小さな組織またはチームであり、ビジネスが発展し、従業員が増えるにつれて(IaaSとして)カテゴリ3に移行する可能性があります。運用)または最初のタイプ(開発と運用および保守のコラボレーション)モードです。

640?wx_fmt = jpeg

タイプ4の適応性:運用経験がほとんどない小規模なチームまたは組織。
有効ポテンシャル:中


タイプ5:有効期限のあるDevOpsチーム

有効期限のあるDevOpsチーム(タイプ5)はアンチタイプB(DevOps Team Silo)のように見えますが、その意図と寿命は完全に異なります。この暫定チームのタスクは、DevとOpsを近づけることです。理想的な目標は、タイプ1(開発と運用のコラボレーション)またはタイプ2(完全に共有された運用責任)モデルに直面し、最終的には廃止することです。アドホックグループのメンバーは、Dev-speakとOps-talkの間で「翻訳」し、Opsチームのスタンドアップミーティングやかんばんなどのクレイジーなアイデアを紹介し、ロードバランサー、管理NIC、オフロードSSLなどの「汚い」詳細を検討します。開発チーム。十分な数の人々がDevとOpsを組み合わせる価値を認識し始めた場合、暫定チームはその目標を達成するための真の機会を得ることができます。展開環境と本番環境の長期的な分析と診断の責任を暫定チーム。それ以外の場合は、DevOpsチームの分離(アンチタイプB)になる可能性があります。

640?wx_fmt = jpeg

タイプ5の適応性:運用経験がほとんどない小規模なチームまたは組織。
有効ポテンシャル:低から中


タイプ6:DevOpsの「エバンジェリスト」チーム

DevとOpsの間に大きなギャップ(または大きなギャップの傾向)がある組織では、DevとOps間のコミュニケーションを維持するために「促進」するDevOpsチームを持つことが効果的です。これはタイプ5(有効期限付きのDevOpsチーム)バージョンですが、DevOpsチームには、継続的にDevチームとOpsチーム間のコラボレーションと協力を促進する特定の責任があります。このチームのメンバーは、DevOpsの実践に対する認識を広めるのに役立つため、「DevOps説教者」と呼ばれることもあります。


「DevOpsチーム」の目標は、組織の残りの部分を有効にすることによってビジネスを実現することです。 — Twitter:EricMinick

640?wx_fmt = jpeg

タイプ6の適応性:開発と運用の傾向が散在している組織。タイプBの危険に注意してください。
有効ポテンシャル:中〜高


タイプ7:SREチーム(Googleモデル)

DevOpsは、開発チームが定期的に勤務会議に出席することを推奨することがよくありますが、これは必須ではありません。実際、一部の組織(Googleを含む)は、開発からソフトウェア(サイト信頼性エンジニアリング(SRE))チームの明示的な「スイッチ」を実行するチームまで、異なるモデルを実行しています。このモデルでは、開発チームはSREチームにテスト証拠(ログ、インジケーターなど)を提供する必要があります。これは、ソフトウェアに十分な標準があり、SREチームによってサポートされていることを示します。


最も重要なことは、SREチームは、運用と保守が標準以下のソフトウェアを拒否し、開発者にコードを本番環境に移行する前に改善するように要求できることです。 DevとSREの間のコラボレーションは、運用および保守の標準で行われますが、SREチームがコードに満足すると、(開発チームではなく)本番環境でコードをサポートします。

640?wx_fmt = jpeg

タイプ7の適応性:タイプ7は、高度なエンジニアリングと組織の成熟度を備えた組織にのみ適しています。 SRE / Opsチームに「JFDI」の展開が通知された場合は、アンチタイプAを返すように注意してください。
有効ポテンシャル:低から高


タイプ8:コンテナ主導のコラボレーション

アプリケーションのデプロイとランタイムの要件をコンテナーにパッケージ化することで、コンテナーはDevとOps間のコラボレーションを必要としなくなります。このように、コンテナは開発、運用、保守の責任の限界です。優れたエンジニアリング文化があれば、コンテナ主導のコラボレーションモデルはうまく機能しますが、開発者がO&Mが考慮する必要のある事項のいくつかを無視し始めた場合、このモデルは「私たちと彼ら」との戦いに変わる可能性があります。

640?wx_fmt = jpeg

タイプ8の適応性:コンテナは非常にうまく機能しますが、アンチタイプAに注意してください。運用チームは、開発者が発行したものをすべて実行することが期待されています。
有効ポテンシャル:中〜高


タイプ9:開発とDBAのコラボレーション

Dev-DBAのギャップを埋めるために、一部の組織はタイプ9と同様のデータベース機能を試し、DBAチームのデータベース機能はDevチームのデータベース機能(または専門家)に見合ったものになっています。これは、データベースの開発中心のビュー(本質的にアプリケーションである仮想永続ストレージ)とデータベースのDBA中心のビュー(スマートで豊富なビジネス価値のソース)の間の変換に役立つようです。

640?wx_fmt = jpeg

タイプ9の適応性:1つ以上の大規模な中央データベースに接続された複数のアプリケーションを持つ組織に適用されます。
有効ポテンシャル:中


思い出してください: 「正しい」チームトポロジを持つ組織はありませんが、いくつかの「悪い」トポロジがあります。

640?wx_fmt = other

クラウドコンピューティングの無料コースが始まります 、5日間の運用と保守の古典的なコースを無料で学ぶことができます。最終的には、クラウドの運用と保守の才能がどのような種類の技術を習得する必要がありますか。開発の将来の見通しは何ですか。業界のリーダーをフォローして、次のことを確認してください。記事の最後をクリックしてください「元のテキストを読む」または下のQRコードを長押ししますただ無料コースに登録する無料学習と反撃の機会をつかむ2019〜

640?wx_fmt = png

PS:編集者から送られてきた無料ギフトパッケージを忘れずにチェックしてください〜

メリット| 10,000以上のPPTテンプレートが無料で入手できるのを待っています!無条件コレクション!

送信無料| 1,000セット以上の履歴書テンプレートが無料で利用でき、履歴書作成チュートリアルが含まれています!

フリーカラー| 「シェルスクリプト100ケース」の電子書籍は無料で入手でき、操作とメンテナンスに必要な乾物です。

640? 640

▼▼クリック【オリジナルを読む]、5日間の無料運用および保守コース、まもなくオープン!