DevOpsと自動化の違いは何ですか？

だれかがDevOpsを実行するときはいつでも、展開などの自動化が主な目的だと思います

しかし、自動化はどこで終わり、DevOpsはどこから始まるのでしょうか？

DevOpsの大きな部分は、非常に頻繁にリリースできるようにすることです。これには、自動ビルド、自動テストなどが含まれます。その目標を達成するには、DevOpsが効率を上げるために自動化を使用する必要があると言えます。

次に、DevOpsと自動化の関係を示します。DevOpsは単なる自動化ではなく、他にもあります。逆に、自動化は「DevOpsの人々」だけに使用されるわけではありません。DevOpsが登場する前に、ITで多くの自動化が行われていました。

上記の図をすべてDevOpsであると見なしたり、これがすべて自動化であることを考慮しないでください。これは、2つの概念がどのように関連しているかを読者が想像できるようにすることです。

自動化はDevOpsの重要な属性ですが、完全な話ではありません。質問は、「タイムボクシングとスクラムの違いは何ですか？」のようなものです。

DevOpsでは、「文化」、「動き」、「方法論」と呼ばれ、それらの説明が正確であっても、それを理解するのに十分ではないあらゆる種類のものが聞こえます。簡単に言えば、DevOpsは、ソフトウェアプロジェクトの管理/制御/ステアリングにおける新しいフィードバックループを可能にするアジャイル手法、自動化、および仮想化の合流点に関するものです。

アグレッシブな自動化により、長時間を要して人為的エラーの影響を受けやすいものが、問題なく迅速に発生します。その結果、より頻繁にそれらを行う傾向があります。これの主な例は、「実稼働環境へのデプロイ」です。以前は、大量の作業を保存し、「何かがうまくいかなかった」場合に備えて時間外に展開していました。しかし今では、「何かがおかしくなる」可能性が劇的に減り、何かがおかしいときの影響が非常に小さくなるように、変更を1日に数回展開できます。

この繰り返し可能なプロセスが整ったら、「パイプライン」として認識し始めます。要件が入り、本番環境にデプロイされたコードが出てきます。このパイプラインに沿ってすべてを自動化します-テスト、ドキュメンテーション、マージ、デプロイ、その他のテストなど。 これは、DevOpsをオートメーションよりも優れたものにする管理方法論（パイプラインに注意を払ったもの）です。

その自動化が整ったら、フィードバックループが開始されます。サイクルタイムなどの測定を開始し、以前に推定で推測しようとしたことを把握できるようにします。自動化/継続的配信を困難にするアーキテクチャに関するものは、自動化/継続的配信を容易にする代替のアーキテクチャパターンに置き換えられる傾向があります（このいくつかの優れた例は、「Evolutionary Databases」という本に記載されています。 ）。

Jenkins、Check、Puppet、Ansible、Vagrant、AWS、またはそれをサポートする他のツールについて話すことなく、この説明を提供できたことに注意してください。これは、「方法論」のような大規模な流行語が意味するものです。最終的には、ツールのセットを置き換えることができます...私たちが残しているのは、自動化とパイプラインへのフォーカスによって可能になるコア管理の原則です。

DevOpsは本当に文化的な変化です-これは、運用と開発の間の従来の障壁を克服することを目的としています（そして実際にQAとビジネスの他の部分でも！）。アイデアは、部門の「サイロ」を持たずに、他のチームと直接連携して、より迅速かつ効率的に物事を成し遂げることができるということです。

制約を取り除き、プロセスを合理化することがすべてです。反復可能なプロセスを使用すると制約を取り除くことができるため、自動化はこれに大きく影響します。たとえば：opsの誰かが手動でリリースプロセスを実行してコードを環境に送り出す必要がある場合、邪魔になる可能性のあることが2つあります。1つはopsに誰かがデプロイを自由に行う必要があることです。 2つ目は、手作業でエラーが発生しやすいため、リリースプロセスの信頼性が低いことです。

DevOpsには自動化が含まれていますが、それはその一部にすぎません。DevOpsは、組織のさまざまな部分の間のサイロを細分化して完全なバリューストリームを提供する文化的変化です。ビジネス、開発、品質保証、インフラストラクチャ、セキュリティ、運用などがすべて連携して、エンドユーザーである人に価値を提供する文化を提供します。DevOpsはツールではありません。購入することはできません。文化を変える必要があります。

自動化はDevOpsの重要な部分であり、品質の高い配信速度を実現します。展開プロセスの自動化は、多くの人が最初に注目する分野の1つであり、迅速に価値を獲得し、展開の時間を短縮するだけでなくプロセスを標準化して削除することで高い投資回収率を実現する最良の方法の1つですエラー。

私は2セントを追加したいと思います：
1）自動化：
     最近私たちが向かっている何か。プロセス全体ではなくても、ピースを自動化することが望ましい方法である必要性が高まっています。このアプローチにより、ユーザー（開発者）は、必要に応じてカスタマイズできるとともに、固定ステップを使用する柔軟性が得られます。
     このアプローチの利点は、開発者が個々のプロセスを結び付けながら、必要な部分を自動化できることです。自動化ステップを細かくすればするほど、制御が向上します。
     また、ロボットオートメーション、SOPオートメーション（サービス業界向け）、レポートオートメーション（Splunkなど）などのスペースのオートメーション用のツールが多数あります
。2）DevOps：
     現在の世界から予想される配信品質と適時性の状態を考えると、ソフトウェア配信プロセスの自動化を拡張する必要があります。これを可能にし、可能な限り迅速に顧客に価値を提供するために、DevOpsは自動化ツールに広く依存しています。
     このアプローチの利点は、個々のステップを自動化して企業全体で一貫性を実現できる一方で、オーケストレーション全体をそのプロジェクトに必要なプロセスに合わせて変更できることです。
     デプロイ用のChef、Dockerfile経由のDocker、ビルド用のMavenなどの個々の自動化ツール（ある意味）は、おそらくJenkinsを介して結び付けられ、同時に必要なソリューションを提供すると同時に、実装または使用に必要な時間を短縮できます。 。
これが、あなたがすでに持っているかもしれない思考プロセスに価値を加えるのに役立つことを願っています。

編集：プロセスとツール-DevOpsの3つの側面のうち2つについて説明したことを忘れていました。他の人が述べたように、3番目の等しく重要な側面は人です。これと自動化の間に想定する主な違いの1つは、DevOpsに抵抗するよりも頻繁に自動化を吸収する傾向があるということです。これは、DevOps自体の性質によるものだと感じています。通常、自動化は、物事をより簡単にすることに関連している一方で、DevOpsは快適な方法を変えていると感じています。

DevOpsの動きは、CAMSと略される4つの主要な領域で構成されています。

1. 文化
2. オートメーション
3. 測定
4. 共有する

ここで、元の定義ポスト 2010年からは。

各領域には、一般に受け入れられているいくつかのツール、プロセス、およびプラクティスがありますが、ベストプラクティスの主題は明確に定義されていませんが、ほとんどの場合、従うべきいくつかのグッドプラクティスがあります。

自動化自体はもう少し広いテーマですが、DevOpsのコンテキストでは、対象範囲のほんの一部にすぎません。私たちは文化をリードしていることに注意してください。ただし、この分野に慣れていない多くのDevOpsプラクティショナーは、しばしば自分の危険を見落とし、直接自動化にスキップします。

自動化とDevOpsは無関係です。DevOpsは、サイトまたはサービスの開発者がすべてそのサイトまたはサービスのオペレーターである複合エンジニアリングに似ています。この小説はなぜですか？私の経験では、ネットワークブリップよりもエキサイティングなことが起こったときにOpsチームが最初にしたことは、Devチームに電話することでした。なぜそうしたのですか？Opsチームが行ったのは、開発者の電話番号のリストを監視して保持することでした。

自動化については何も言っていないことに注意してください。

自動化とは、成功を繰り返すことです。ステップa、b、cを実行し、プロセスXが常に機能する場合、ステップa、b、cは自動化の良い候補です。それから、私はもっとお金を稼ぐことをするために、手動プロセスであったものに時間を使うことができます。自動化は簡単なときに成功します。新しいリリースを展開し、統合テストを実行し、ボルトにナットを締め、データをバックアップし、クレジットとデビットのバランスをとることなどは、人でもロボットでも手順が繰り返されるため、すべて自動化の優れた候補です。

注：新しいのは、開発者もオペレーターであるということです。別のグループはありません。私の場合の協力はまれでした。トラブルシューティングガイド（別名TSG）に何も記載されていない場合は、電話が保証されています。私の経験では、バックホーの場合、Opsが最初のコールでした。サービス間の問題は、操舵室の外にありました。