DevOps成熟度への実用的なパス

アジャイル方法論は、実際のDevOpsプラクティスなしでは無駄です。 流行語は多くの組織で誤用されました。 あなたがアジャイルチームを成熟させ、DevOpsエンジニアやDevOpsチームを持っていると言うなら、おそらく正しい方向に進んでいないでしょう。 DevOpsは、チーム名や指定ではなく文化です。 CMM(Capability Maturity Model)から手がかりを得るこの試みは、DevOpsの旅と前進のどこに立っているのかを組織が知るのを助けることです。 開発チームと運用チームの間でいくつかのブレインストーミングを使用すると、これを拡張し、組織のニーズに合わせてカスタマイズすることができます。

個人や組織が成長するのに役立つほど悪い数字はありません。

幸せな顧客

CMMとは異なり、これはあなたがどの認証機関にも証明する必要があるモデルではありません。 あなたが得る唯一の証明書はあなたの幸せな顧客か共同経営者からある。 それは自己へモデル反映し、ビジネスが育つのを助ける。 あらゆるITチームのまさに目的は質の支持できる、予想できる配達をすることによって価値を作成することである。

これは、開発者からCxOまでが理解し、関連付けることができる単純なモデルです。

モデルについて説明する前に。 このモデルの必要性を理解する必要があります。 何年も前、Melvin Conwayは彼の論文”委員会はどのように発明しますか?”コンウェイの法則として有名になった論文を思い付いた。

システムを設計する組織(広く定義されている)は、その構造が組織の通信構造のコピーである設計を生成します。

この法律は、ソフトウェアモジュールが機能するためには、複数の人が互いに頻繁に通信しなければならないという推論に基づいています。 したがって、システムのソフトウェアインターフェイス構造は、それを生産した組織の社会的境界を反映し、それを超えて通信がより困難になります。

これが実際のシナリオでソフトウェア開発でどのように機能するかを見てみましょう。 Radhaは、製品の詳細な属性を示すフロントエンド画面を構築しています。 この製品が携帯電話であるとします。 いくつかの一般的な製品の詳細は、色、価格、寸法、評価などです。 新しい規制は、携帯電話のSAR値を表示するようになりました。 彼女が設計した画面は、micro service callで動作します。 彼女はデータチームで働くSunilに話を聞きました。 彼は、彼らが唯一のフラットファイルでデータを送信することができますと述べました。 二つのモジュールの間には明確な切断があります。 これは、すべてのITチームが100%の時間ではなく、大部分の時間に遭遇するシナリオです。 これは単なる設計上の問題です。 問題はより広いです。 他のチームの優先順位があなたのチームがしていることと非常に異なっていれば何か。 あなたの関係者があなたの後ろで動いている間あなたの条件はそれらのための最も低い優先順位であるかもしれない。

DevOpsの実装を成功させるための最初のステップは、組織の変更にオープンにすることです。

組織の変更

成熟度の5つのレベルについて議論しましょう:

  1. 初期:この段階では、チームはサイロで作業し、唯一の、必要性ベースのコラボレーションがあります。 一緒にすべてのチームとの会議では、あなたが”製品”を所有している人に尋ねるなら、あなたは手を上げることはありません。 市場投入までの時間は通常長く、数ヶ月、時には数年になります。 優先順位はチームレベルで設定されますが、製品レベルでは設定されません。 これは、各チームが独自の優先順位を持つことにつながります。 定義されたプロセスがないので、すべての試みは車輪を再発明するようなものです。 これは、品質の問題と長いタイムラインにつながります。 チームは主に手動の展開と手動の介入を行います。 まあ. これは悪い状態ではありません。 これは、開発のほとんどがどのように開始されるかです。

2. 反復可能:チームはまだサイロで作業します。 チーム内にはある程度の自動化があります。 危機がヒットすると、チームは自分のプロセスを定義し、危機が終了するまで続きます。 唯一の良いニュースは、これらのいくつかは、危機が再びヒットしたときに再現可能なプロセスになるこ

3. 定義:これは、中央集権化されたチームでDevOps文化をシードするための良い出発点です。 このチームは、開発チームが使用している様々な技術を理解しており、ツールは現在のニーズに基づいています。 集中化されたチームであるため、各チームが何をしているかを監視することは容易ではないため、いくつかの決定はチームに委ねられて実験します。 中央チームは、通常、専門家で構成され、開発チームは、基本的な理解と知識を持つ一部の人々を持っています。

4. 管理:中央のDevOpsチームが組織のツーリングランドスケープを理解しているため、複数の環境とツールがテストされます。 一貫性のある反復可能なプロセスの後には、複数のチームが続きます。 ツールチェーンは、個人的な選択ではなく、ユースケースに基づいて選択されます。 すべてのプロセスの監視ツールが導入され、チームが意思決定を行うために頻繁に使用されています。

5. 最適化された:

良い指導者の成功は、信者を持たないことによって定義されますが、偉大な指導者を作成する能力によって。

DevOpsの成熟の最終段階は、DevOpsチームを消滅させることです。 これは直感的なカウンターのように見えるかもしれません。 この段階では、DevOpsは別のエンティティではなく、製品開発チームの一部です。 インフラストラクチャをコード、コンテナ、オーケストレーションなどとして使用する。 ゼロ接触配置は達成される。 今、あなたが製品に取り組んでいるすべての人に電話し、製品を所有している人に尋ねると、躊躇せずに自信を持って手を上げることができます。 監視ツールからのデータは、新しいツールセット(インフラストラクチャ、プログラミング言語、テクニックを含む)を選択するために使用されます。 決定は、個人の好みではなくデータに基づいています。 製品チームは、いつでもいつでもコードを展開する準備ができています。 彼らは”ビジネス価値”を愛し、ペットとして扱います。 他のすべては牛として扱われます。

DevOps成熟度モデル。

コメントを残す

メールアドレスが公開されることはありません。