Patrick Deboisが最初のDevOps Days会議を開催し、「DevOps」という用語を世界に紹介して以来、DevOpsがグローバルな動きのレベルに進化したことは間違いありません。
もちろん、 DevOpsムーブメントには中傷があります。 否定的な意見は、誤った（「DevOpsはシステム管理者の新しい名前」）から無視（「DevOpsは、管理者（Ops）を取り除こうとしている狂った開発者（Dev）にすぎません」または「DevOpsは、開発者のようになりたいと思う狂った管理者））resの表現の前（原則として、論理に従わない引数を使用）。
過去9か月間、私は公開フォーラムとクライアント企業の両方でDevOps運動に対する抵抗を克服しなければなりませんでした。 この間、よくある誤解に気づき始め、DevOpsのアイデアに対する否定的な反応の大部分を助長しているように思えます。 そして今、私はこの一般的な誤解を明確にしようと思います：
DevOpsは技術的な問題ではありません。
テクノロジーは、DevOpsが解決しようとしている問題の解決策を作成する上で重要な役割を果たします。 ただし、定義上、DevOpsはビジネス上の問題です。
ビジネスはDevOpsと何をしなければなりませんか？
どの会社でも基本的なビジネスプロセスは、頭の中で生まれた瞬間からアイデアを取り、それがお金をもたらす場所に持ってくることです。
このビジネスプロセスの内部には、アイデアを実現するために必要なさまざまな種類のさまざまなアクティビティがあります。 これらの活動の一部はテクノロジーによって推進され、一部は人々に依存しています。 この時点で、開発者、テスター、アーキテクト、リリースエンジニア、セキュリティスペシャリスト、サービス関係者などのITがその役割を果たし始めます。全員がこのアイデアを実装する一般的なプロセスで作業の一部を実行します。
しかし、ビジネスプロセスのコンテキストを削除すると、最終的に何が残りますか？ あなたはまだ自分自身で何かをして、自分の人生を生きているたくさんの人々と異なるグループを持っています。 これらのグループ間の非効率、不必要な処理、対立、コミュニケーション不足と戦う本当のインセンティブを失っています。 文字通り、私たちは誰もが自分自身のためである状況を取得します。
ビジネスプロセスのコンテキストを削除すると、他に何が起こるか知っていますか？ 時間が経つにつれて、あなたはあなたの仕事を失います。 ビジネスに仕事をする機会を与えるからこそ、私たちは給料と自分の仕事をする能力を手に入れます。
事業そのものが存在しない場合、またはこの事業がそのアイデアを実現することを許可しない場合、すべての仕事は単なる趣味に過ぎません。 そして、定義上、趣味で報酬を得るのは非常に困難です。
DevOpsの重要なポイントは、ビジネスが市場の原動力に可能な限り迅速、効率的、かつより確実に対応できるようにすることです。 ビジネスがなければ、DevOpsの問題について話す他の理由はなく、それらに対処する意味がありません。
それはアジャイルターゲットのように見えませんか？
DevOpsの目標がアジャイルの目標に似ている場合、それは実際に似ているためです。 しかし、アジャイルとDevOpsは2つの異なるものです。 理想的にはアジャイル開発を構築できますが、それでも多くのDevOps問題があります。 一方、アジャイルの原則に基づいた開発をまったく使用せずに、DevOpsの問題を修正することはできます（ただし、これは非常にまれです）。
アジャイルとDevOpsを、リーン方法論と共通のルーツを共有するが異なるレベルで機能する2つの関連するアイデアとして説明するのが好きです。 アジャイルは1つのIT機能の改善（ソフトウェア配信）に焦点を合わせていますが、DevOpsはすべてのIT機能の相互作用と操作の改善に取り組んでいます（開発から保守までの製品ライフサイクル全体をカバー）。
しかし、DevOpsはクールなツールだと思いましたか？
テクノロジーにより、ほぼすべてのビジネスプロセスをより効率的、スケーラブル、信頼性の高いものにすることができます。 ただし、ツール自体は単なるツールであることを覚えておく必要があります。
このツールを使用して組織を改善できるのと同じ確率で、新しいツールを使用して悪い習慣と古い非稼働プロセスを強化できます。 ツールの使用方法は、サポートするビジネスプロセスに与える影響によって決まります。
DevOpsの問題が何であるか、およびこれらの問題を解消するためにどのようなワークフローの改善が必要であるかを人々が明確に理解している場合、ツールについて話すのは非常に簡単です（明らかでない場合）。
生まれたばかりのDevOpsの動きは主にエンジニアで構成されているため、このような興奮がすぐにツールの議論のどこから来るのかを理解するのは簡単です。 しかし、おそらく、誰もが十分に理解し、これらのツールや他のツールが必要な理由と、通常のPuppet vs.に突入する前にビジネスプロセスの望ましい改善点を理解するために、さらに努力する必要があります。 シェフまたはファイルセントリックvs. パッケージセントリック。
DevOpsがビジネスプロセスに関するものである場合、なぜ「DevOps」と呼ばれるのですか？
私の意見では、DevOpsに関する初期の議論の間違いの1つは、議論されている問題の規模がどれほど大きいかがすぐにはわからなかったということでした。 すでに1年の経験があり、ビジネスの最大の問題の1つである、市場の力にできるだけ早く対応する機会をビジネスに提供する方法に取り組んでいることが明らかになりました。
この会話はどこかで始まることになっており、残念ながら、競合の一般的な問題と、開発者（Dev）と運用（Ops）間のコミュニケーションの欠如について議論することに引き寄せられました。 各企業の組織構造は異なりますが、それにもかかわらず、世界をDev-campとOps-campに似たような形で分けることは非常に簡単であり、したがって、議論のための共通のガイドラインがあります（世界ははるかに複雑であり、黒から遠くと白）。
この似たようなDev / Opsの例では、DevOps方法論の初期の焦点は展開プロセスの改善でした。 また、変更プロセスはIT組織の作業の大部分を占めるため、開始するのは論理的で自然な場所でもありました。
おそらく、パトリックは最初の会議を「BizDevQASecurityOpsCloudUsers Days」または「SolvingABroaderProblemThanAgile Days」と呼ぶべきだったでしょう...しかし、誰かが来るとは思いません。