1 つの記事で DevOps を理解します。それでも分からないなら殴ってみろ

DevOps という言葉については、多くの人が知っていると思います。

DevOps は人気のある概念として、近年、主要なテクノロジー コミュニティやメディアの記事に頻繁に登場しています。業界のリーダーたちから非常に注目されており、多くの観客も魅了しています。

[[282028]]

では、DevOps とは何でしょうか?

それは方法だと言う人もいれば、それはツールだと言う人もいれば、それは考えだと言う人もいます。それは哲学だと言う人もいます。

[[282029]]

話せば話すほど、不思議になってきます。神格化されそうな予感！ DevOps は本当にそれほど誇張されているのでしょうか?それは何に使われますか?なぜ業界はそれほどまでにこだわるのでしょうか?

今日の記事では、Xiaozaojun が DevOps についてお話します。

DevOpsの起源

この話は少し長いので、最初から始めましょう。

1940年代に世界初のコンピュータが誕生しました。誕生したその日から、プログラムによって駆動されてきました。プログラムの作成を担当する人は「プログラマー」と呼ばれます。

[[282030]]

プログラマーはコンピューターの達人であり、非常に希少な人材です。当時は、プログラマーになってコンピューターを操作する資格があったのは、高等教育を受け、名門大学を卒業した人だけでした。

人類の技術の継続的な発展により、パソコンやインターネットが次々と登場し、誰もが情報化を受け入れる時代になりました。生産性を向上させるために、オフィスツールとしてコンピューターを使い始める企業が増えています。一般の個人ユーザーも、生活の質を向上させるために、コンピューターを娯楽ツールとして使い始めています。

[[282031]]

こうして、コンピュータプログラムはビジネスになり始めました。プログラムは徐々に「ソフトウェア」へと進化し、最も収益性の高い製品の 1 つになりました。

ソフトウェア業界では、プログラマーは「ソフトウェア開発エンジニア」と呼ばれるより専門的な肩書きを持っており、これは私たちがよく「コーダー」と呼ぶものです。

ソフトウェアの開発は、最初から最終納品まで、通常、計画、コーディング、構築、テスト、リリース、展開、保守という段階で構成されます。

当初、プログラムは比較的単純で、作業量もそれほど多くなかったため、プログラマーは作業のすべての段階を一人で完了することができました。

ソフトウェア業界がますます強力になるにつれて、ソフトウェアの規模も徐々に大きくなっています。ソフトウェアの複雑さは増加し続けています。一人では状況に対処できなくなったとき、洗練された分業が生まれ始めました。

プログラマーの数は増え、仕事の種類も増えています。ソフトウェア開発エンジニアの他に、ソフトウェアテストエンジニアやソフトウェア運用保守エンジニアも存在します。

分業後の従来のソフトウェア開発プロセスは次のようになります。

ソフトウェア開発者は数週間から数か月かけてコードを作成し、その後、そのコードを QA (品質保証) チームに渡してテストを行い、最終リリースを運用チームに渡して展開します。開発、テスト、展開の 3 つの段階すべて。

初期に採用されたソフトウェア配信モデルは「ウォーターフォール モデル」と呼ばれます。

つまり、ウォーターフォール モデルとは、ある段階のすべての作業が完了するまで待ってから次の段階に進むことを意味します。

このモデルは、比較的理想的な条件（ユーザー要件が非常に明確で、開発時間が十分である）のプロジェクトに適しています。誰もが手順に従って、順番に職務を遂行するだけです。

ただし、プロジェクトは一方的に運営することはできません。顧客にはニーズもあります。製品にも問題があり、改善が必要です。

時間が経つにつれて、システムに対するユーザーの要求は増加し続け、同時に、ユーザーが与える期間はますます短くなっています。このような状況では、面倒で時間のかかるウォーターフォール型開発はもはや適切ではないことが誰もが認識しました。

そこで、ソフトウェア開発チームは、有名な「アジャイル開発」という新しい概念を導入しました。

アジャイル開発は2000年頃から世界的に注目を集め始めました。急速に変化する要件に対応できるソフトウェア開発能力です。実際、簡単に言えば、大きなプロジェクトを小さなプロジェクトに、大きな時間ポイントを小さな時間ポイントに変換し、次に次の操作を実行します。

[[282035]]

DevOps でよく登場する 2 つの単語があります。CI と CD です。 CI は継続的インテグレーションの略で、CD は継続的デリバリーや継続的デプロイメントなど複数の英語用語に対応します。

婉曲的に「連続」と呼んでいますが、実際は「加速-繰り返し-加速-繰り返し…」という感じです。

より理解しやすいように絵を描いてみましょう:

アジャイル開発により、開発チームの作業効率が大幅に向上し、バージョン更新も高速化されました。

「更新速度が速ければリスクも大きくなるのでは？」と考える人も多いかもしれません。

実際にはそうではありません。

アジャイル開発により、問題をより早く発見し、製品をより早くユーザーに提供し、チームがユーザーからのフィードバックをより早く取得してより早く対応できるようになります。さらに、DevOps の小さなステップと速いペースのアプローチによってもたらされるバージョン変更は比較的小さく、リスクも小さくなります (下の図を参照)。たとえ問題が起こったとしても、解決するのは比較的簡単です。

アジャイル開発によりソフトウェア開発の効率やバージョンアップのスピードは大幅に向上しましたが、その効果は開発段階に限られています。研究開発スタッフは、運用と保守の面が依然として固いブロックであり、それが新たなボトルネックになっていることを発見しました。

運用保守エンジニアは開発エンジニアとは全く異なる思考ロジックを持っています。運用保守チームのモットーは非常にシンプルです。「安定性が何よりも優先される」運用と保守の中心的な要件は、問題を回避することです。

問題が発生する可能性が最も高いのはいつですか?問題は、変更が発生したときに発生する可能性が最も高くなります。そのため、運用や保守は「変化」に対して非常に抵抗力があります。

その結果、両者の間に紛争が勃発した。

[[282039]]

今回、当社の DevOps が華々しくデビューします。

DevOps とは何ですか?

DevOps という言葉は、実際には Development と Operations という言葉を組み合わせたものです。英語の発音は /de'vɒps/ で、「de'vɒps」に似ています。

[[282040]]

Wikipedia による DevOps の定義は次のとおりです。

DevOps は、開発、技術運用、品質保証 (QA) 部門間のコミュニケーション、コラボレーション、統合を促進する一連のプロセス、方法、システムの総称です。

この位置付けは少し抽象的ですが、理解するのは難しくありません。いずれにせよ、これは特定のソフトウェア、ツール、またはプラットフォームの名前ではありません。

目標の観点から見ると、DevOps は、開発者と運用保守担当者間のコミュニケーションと協力を向上させ、自動化されたプロセスを通じてソフトウェアプロセス全体をより高速かつ信頼性の高いものにすることです。

壁破壊ツール

多くの人は、いわゆる DevOps は Dev+Ops に過ぎないと考えているかもしれません。 2 つのチームを統合するか、運用と保守を開発に割り当てるだけで完了です。それは単純で粗雑です。

この見解は誤りであることに注意してください。これは、近年 DevOps の実装が困難になっている主な理由でもあります。

DevOps を本当に実装したい場合、まず最初に必要なのは考え方を変えること、つまり「洗脳」することです。運用・保守担当者だけでなく、開発担当者も清潔にする必要があります。従業員は浄化する必要があり、リーダーはさらに浄化する必要があります。

DevOps は組織構造の変更だけでなく、企業文化や考え方の変更でもあります。意識が変わらなければ、社員を集めても火花は生まれません。

洗脳に加えて、プロセス全体の規範と標準が DevOps の考え方に従って再編成されます。

DevOps プロセスでは、プロジェクト開発中に運用保守担当者が開発プロセスに介入し、開発者が使用するシステム アーキテクチャと技術ルートを理解し、適切な運用保守計画を策定します。開発者は、運用・保守の初期段階からシステム導入に参加し、システム導入の最適化提案も行います。

DevOps の導入により、開発担当者と運用保守担当者間のコミュニケーションが促進され、相互理解が深まります。

考え方やプロセスを変えながら、DevOps を完全に実装したいのであれば、ソフトウェアとプラットフォームのサポートが不可欠です。

現在、DevOpsをサポートするソフトウェアは数多く存在します。スペースが限られているため、一つ一つ紹介することはしません。そうは言っても、DevOps が今これほど注目されているのも、こうしたソフトウェアやプラットフォームのおかげであり、そこから収益を得るチャンスがあるのです。

DevOpsエコシステムにおける多彩なツール

上記の重要な要素のうち、テクノロジー（ツールとプラットフォーム）の実装が最も簡単で、次にプロセス、そして考え方の変化が最も困難です。

つまり、DevOps は企業の技術力だけでなく、経営レベルや企業文化もテストするのです。

前述のウォーターフォール開発とアジャイル開発を比較すると、DevOps は開発段階に限定されず、ソフトウェアライフサイクル全体にわたって実行されることが明確にわかります。

次の図は、DevOps の位置付けとその価値をより明確に示しています。

DevOpsの現状

DevOps という言葉は、2009 年にベルギーのゲントで開催された最初の DevOpsDays カンファレンスに由来しています。Twitter での普及を促進するために、DevOpsDays は DevOps に短縮されました。

現在、DevOpsは急速な成長段階にあります。 DevOps は、特に大企業で広く普及しています。

2018 年の調査によると、回答者の 74% が DevOps を採用しており、前年の 66% から増加しています。

企業の規模が大きくなるほど、DevOps が好まれるようになります。 Adobe、Amazon、Apple、Airbnb、Ebay、Etsy、Facebook、LinkedIn、Netflix、NASA、Starbucks、Walmart、Sony などの企業が DevOps を採用しています。

今日では、DevOps はソフトウェア エンジニアリングとほぼ同義になっています。

DevOps の急速な発展に伴い、関連専門家の給与も上昇しています。

調査によると、米国のDevOpsエンジニアの平均年収は13万ドルで、中国の平均年収も40万～50万ドルの範囲にある。能力が高ければ年収100万を稼ぐことも珍しくありません。

採用ウェブサイトからのデータ

給与の急激な増加により、IT エンジニアの間で学習と認定の波も起こっています。

現在最も人気のある DevOps 認定資格は、EXIN DevOps Master と EXIN DevOps Professional です。これらの認定資格のトレーニング料金は安くはありませんが、それでも多くの人が熱心に申し込んでいます。

EXIN DevOps 認定システム

DevOps と仮想化、コンテナ、マイクロサービス

クラウド コンピューティング技術は近年急速に進歩しており、仮想化、コンテナー、マイクロサービスなどの概念は誰もがよく知っているはずです。これらの概念について言及するときに、DevOps についても言及することがあります。

それらの間のつながりは何ですか?

実はとても簡単です。

想像できると思いますが、作業を細かい部分に分割する場合、大きな鉄片を加工する方が便利ではないでしょうか?それとも、一つずつ処理する方が便利ですか?

分割した後の方が明らかに便利になります。

いわゆる「マイクロサービス」とは、元々ブラックボックス化された製品全体を、複数のサービスを提供する全体から、異なるサービスを提供する複数の個別製品に分割（分離）することです。次の図に示すように:

モノリシック → マイクロサービス

マイクロサービス アーキテクチャでは、開発、テスト、デプロイメント、反復など、担当するモジュールをさまざまなエンジニアが処理できます。

仮想化は、実際にはアジャイルなクラウド コンピューティング サービスです。ハードウェアの観点からシステムを複数のシステムに「分割」し、システムを相互に分離して、マイクロサービスに利便性を提供します。

コンテナはさらに徹底的です。異なるオペレーティング システムに分割されるのではなく、オペレーティング システム上の異なる「実行環境」(コンテナー) に分割されます。使用するリソースが少なくなり、展開も速くなります。

わかりますか？仮想化とコンテナは、実際には DevOps に適した前提条件を提供します。開発環境とデプロイメント環境をより適切に分離できるため、お互いへの影響を軽減できます。

これは、DevOps が 2009 年には普及していなかったのに、現在ではますます普及しつつある主な理由の 1 つでもあります。

最後の言葉

世の中の格闘技はスピード以外は無敵です。

時間が経つにつれて、顧客の需要は急速に変化し、市場の方向性を予測することは困難です。企業が生き残りたいのであれば、スピードを上げなければなりません。従業員として、より長期的なビジョンを持ち、より寛容にならなければなりません。