DevOps についてわかりやすい言葉で話します

DevOpsについて話すとき、要点を理解するのは難しいですか? 私たちはあなたのために、専門家でなくても要点を理解するのに役立つ、生き生きとした例え、印象的な表現、専門家からのアドバイスを集めました。 最終的なボーナスは、Red Hat 従業員自身の DevOps です。

DevOps という用語は 10 年前に生まれ、Twitter のハッシュタグから IT 業界の強力な文化運動へと進化しました。開発者が物事をより迅速に実行し、実験し、反復することを奨励する真の哲学です。 DevOps はデジタル変革の概念と密接に結びついています。 しかし、IT 用語ではよくあることですが、過去 XNUMX 年間で、DevOps 自体について多くの定義、解釈、誤解が生じてきました。

したがって、DevOps に関して、「それはアジャイルと同じですか?」といった質問をよく耳にします。 それともこれは何か特別な方法論なのでしょうか？ それとも「コラボレーション」という言葉の単なる同義語なのでしょうか？

DevOps にはさまざまな概念 (継続的デリバリ、継続的インテグレーション、自動化など) が含まれているため、特にこのテーマに情熱を持っている場合、何が重要かを絞り出すのは困難な場合があります。 ただし、このスキルは、自分のアイデアを上司に伝える場合でも、単に家族や友人に自分の仕事について伝える場合でも、非常に役立ちます。 したがって、今は DevOps の用語のニュアンスを脇に置いて、全体像に焦点を当てましょう。

DevOps とは: 6 つの定義と類似点

私たちは、専門家に DevOps の本質をできるだけ簡単かつ簡潔に説明してもらい、あらゆるレベルの技術知識を持つ読者にその価値が明確になるように依頼しました。 これらの会話の結果に基づいて、DevOps に関するストーリーを構築するのに役立つ、最も印象的な例え話と印象的な定式化を選択しました。

1. DevOps は文化的な運動です

「DevOps は、顧客、クライアント、従業員など、誰かが使い始めるまでソフトウェアは本当の利益をもたらさないということを双方 (ソフトウェア開発者と IT システム運用スペシャリスト) が認識する文化的な運動です」と上級研究員の Eveline Oehrlich 氏は述べています。 DevOps Institute のアナリスト。 「したがって、両当事者は共同してソフトウェアの迅速かつ高品質な配信を保証します。」

2. DevOps は開発者に権限を与えることです。

「DevOps により、開発者はアプリケーションを所有し、実行し、配信を最初から最後まで管理できるようになります。」

「通常、DevOps は、自動化されたプロセスを構築および実装することで、本番環境へのアプリケーションの配信を高速化する方法として話題になります」と、保険会社 Liberty Mutual の DevOps プラットフォーム担当ディレクター、Jai Schniepp 氏は言います。 「しかし私にとって、それはもっと根本的なことなのです。」 DevOps により、開発者はアプリケーションや特定のソフトウェアを所有し、実行し、配信を最初から最後まで管理できるようになります。 DevOps は責任の混乱を排除し、プロセスに参加している全員を自動化された開発者主導のインフラストラクチャに導きます。」

3. DevOps とは、アプリケーションの作成と配信におけるコラボレーションです。

「簡単に言うと、DevOps とは、全員が協力して作業するソフトウェアの制作と配信へのアプローチです」と、BMC の社長兼デジタル ビジネス オートメーション責任者の Gur Staf 氏は述べています。

4. DevOps はパイプラインです

「すべての部品が噛み合って初めてコンベヤの組み立てが可能になります。」

「DevOps を自動車の組み立てラインに例えます」と Gur Staff 氏は続けます。 – アイデアは、すべての部品を事前に設計して作成し、個別に調整することなく組み立てられるようにすることです。 コンベヤの組み立ては、すべての部品が適合する場合にのみ可能です。 エンジンを設計・製作する人は、それをボディやフレームにどのように取り付けるかを考慮する必要があります。 ブレーキを作る人は車輪などのことを考えなければなりません。 ソフトウェアについても同じことが言えるはずです。

ビジネス ロジックやユーザー インターフェイスを作成する開発者は、顧客情報を保存するデータベース、ユーザー データを保護するためのセキュリティ対策、そしてサービスが大規模な、場合によっては数百万ドル規模のユーザーにサービスを提供し始めたときにこれらすべてがどのように機能するかを考える必要があります。 。」

「人々に、自分の仕事だけに集中するのではなく、協力して、他の人がやっている仕事の部分について考えてもらうことは、克服すべき最大の障害です。 これができれば、デジタル変革の大きなチャンスが得られます」と Gur Staff 氏は付け加えます。

5. DevOps は人材、プロセス、自動化の適切な組み合わせです

DevOps Institute のエグゼクティブ ディレクターである Jayne Groll 氏は、DevOps を説明するために素晴らしい例えを示しました。 彼女の言葉を借りれば、「DevOps は、人材、プロセス、自動化という XNUMX つの主要なカテゴリの材料を含むレシピのようなものです。 これらの要素のほとんどは、リーン、アジャイル、SRE、CI/CD、ITIL、リーダーシップ、文化、ツールなど、他の分野やソースから取得できます。 DevOps の秘密は、他の優れたレシピと同様、これらの材料を適切な割合で組み合わせて、アプリケーションの作成とリリースの速度と効率を高める方法です。」

6. DevOps とは、プログラマーが F1 チームのように働くことです

「レースはスタートからゴールまで計画されているのではなく、逆にゴールからスタートまで計画されているのです。」

「DevOps の取り組みから何を期待できるかについて話すとき、例として NASCAR や Formula 1 レーシング チームを思い浮かべます」と、Red Hat のクラウド プラットフォーム マーケティング担当シニア マネージャーであり、DevOps 風のニュースレターの発行人である Chris Short 氏は言います。 – そのようなチームのリーダーには XNUMX つの目標があります。それは、チームが利用できるリソースと降りかかる課題を考慮して、レースの最後に可能な限り最高の順位を獲得することです。 この場合、レースはスタートからフィニッシュまでではなく、逆にフィニッシュからスタートまで計画されます。 まず、野心的な目標を設定し、それからそれを達成する方法を決定します。 その後、それらはサブタスクに分割され、チームメンバーに委任されます。」

「チームはレース前のXNUMX週間をかけてピットストップを完璧に仕上げます。 彼は、過酷なレース日に備えて体調を維持するために筋力トレーニングと有酸素運動を行っています。 レース中に発生する可能性のある問題を解決するために協力して練習します。 同様に、開発チームは新しいバージョンを頻繁にリリースするスキルを訓練する必要があります。 このようなスキルと適切に機能するセキュリティ システムがあれば、実稼働環境への新しいバージョンのリリースもより頻繁に行われます。 この世界観では、速度の向上は安全性の向上を意味します」とショート氏は言います。

「それは『正しいこと』をすることではありません」とショート氏は付け加えます。「望ましい結果を妨げるものをできる限り排除することが重要です。 リアルタイムで受け取ったフィードバックに基づいてコラボレーションし、適応します。 異常に備えて品質の向上に努め、目標に向けた進捗への影響を最小限に抑えてください。 これがDevOpsの世界で私たちを待っているのです。」

DevOps をスケールする方法: 専門家からの 10 のヒント

ただ、DevOps と大規模 DevOps はまったく別のものです。 XNUMX回目からXNUMX回目までの途中の壁を乗り越える方法をお伝えします。

多くの組織にとって、DevOps への道は簡単かつ楽しく始まります。 情熱を持った小規模なチームが結成され、古いプロセスが新しいプロセスに置き換えられ、最初の成功が生まれるのもそう長くはありません。

残念ながら、これは単なる見せかけの華やかさ、進歩の幻想に過ぎないと、コンサルティング会社ノース・ハイランドのマネージング・ディレクター兼デジタル部門責任者ベン・グリンネル氏は言う。 初期の成功は確かに励みになりますが、組織全体に DevOps を広く導入するという最終目標の達成には役立ちません。

その結果が、「私たち」と「彼ら」の間の分断の文化であることは簡単にわかります。

「多くの場合、組織は、他の企業がその道をたどることができるか、または進んで従うかどうかを考慮せずに、主流の DevOps への道を切り開くと考えて、これらの先駆的なプロジェクトを立ち上げます」と Ben Grinnell 氏は説明します。 – このようなプロジェクトを実施するチームは、通常、他の場所で同様のことをすでに行っているが、組織にとっては初めての、自信に満ちた「バランジアン」から採用されます。 同時に、他の人たちを拘束し続けるルールを破り、破壊するよう奨励されます。 その結果、知識やスキルの伝達を妨げる「私たち」と「彼ら」の文化が形成されることは容易にわかります。」

「そして、この文化的な問題は、DevOps の拡張が難しい理由の XNUMX つにすぎません。 DevOps チームは、急速に成長する IT ファースト企業に特有の技術的課題の増加に直面しています」と Scalyr の創設者兼会長の Steve Newman 氏は述べています。

「現代世界では、サービスは必要が生じるとすぐに変化します。 新しい機能を常に実装し実装するのは素晴らしいことですが、このプロセスを調整し、発生する問題を排除するのは本当に頭の痛い問題だと Steve Newman 氏は付け加えます。 – 非常に急成長している組織では、部門横断型チームのエンジニアは、変化とそれが生み出す依存関係レベルのカスケード効果に対する可視性を維持するのに苦労しています。 さらに、エンジニアはこの機会を奪われると不満を抱き、その結果、発生する問題の本質を理解することがさらに困難になります。」

上記のような課題を克服し、大規模な組織での DevOps の大量導入に移行するにはどうすればよいでしょうか? たとえ最終的な目標がソフトウェア開発サイクルとビジネスプロセスをスピードアップすることであっても、専門家は忍耐を勧めます。

1. 文化の変化には時間がかかることを忘れないでください。

DevOps Institute エグゼクティブ ディレクター、Jayne Groll 氏: 「私の意見では、DevOps の拡大はアジャイル開発と同じように漸進的かつ反復的であるべきです (そして同様に文化に触れるべきです)。 アジャイルと DevOps は小規模チームを重視します。 しかし、これらのチームの数が増え統合が進むにつれて、新しい働き方を採用する人が増え、その結果、大規模な文化的変革が起こります。」

2. プラットフォームの計画と選択に十分な時間を費やす

Perfecto のリード テクニカル エバンジェリスト、Eran Kinsbruner 氏は次のように述べています。 「スケーリングを機能させるには、DevOps チームはまず従来のプロセス、ツール、スキルを組み合わせる方法を学び、その後、DevOps の各段階をゆっくりと育成し、安定させる必要があります。 すべては、ユーザー ストーリーとバリュー ストリームを慎重に計画することから始まり、その後、トランク ベースの開発や、コードの分岐とマージに最適なその他のアプローチを使用してソフトウェアとバージョン管理を作成します。」

「その後、統合とテストの段階が始まりますが、そこでは自動化のためのスケーラブルなプラットフォームがすでに必要とされています。 ここで、DevOps チームにとって、スキル レベルとプロジェクトの最終目標に合った適切なプラットフォームを選択することが重要になります。

次のフェーズは本番環境へのデプロイメントで、これはオーケストレーション ツールとコンテナーを使用して完全に自動化する必要があります。 DevOps のすべての段階 (運用シミュレーター、QA 環境、実際の運用環境) で仮想化環境を用意し、関連する結論を得るためにテストには常に最新のデータのみを使用することが重要です。 分析はスマートであり、迅速かつ実用的なフィードバックでビッグデータを処理できなければなりません。」

3. 責任から罪悪感を取り除きます。

RedHat エバンジェリスト、ゴードン・ハフ: 「実験を許可し奨励するシステムと雰囲気を作り出すことで、アジャイル ソフトウェア開発におけるいわゆる成功の失敗が許容されます。 これは、失敗の責任を他の人が負わないという意味ではありません。 実際、「責任がある」ということはもはや「事故を引き起こす」という意味ではないので、誰が責任を負っているのかを特定することはさらに容易になります。 つまり、責任の本質が質的に変化するのである。 混乱の程度、アプローチ、生産プロセス、インセンティブという 4 つの要素が重要になります。」 (これらの要素について詳しくは、Gordon Huff の記事「DevOps のレッスン: 健全な実験の XNUMX つの側面」を参照してください。)

4. 進むべき道を切り開く

コンサルティング会社ノース・ハイランドのマネージング・ディレクター兼デジタル部門責任者、ベン・グリンネル氏は次のように述べています。 「規模を達成するには、先駆的なプロジェクトとともに「パスクリアリング」プログラムを立ち上げることをお勧めします。 このプログラムの目標は、DevOps の先駆者が残した古いルールなどのゴミを一掃し、進むべき道を明確にすることです。」

「新しい働き方の成功を広く祝うことにより、先駆者グループをはるかに超えたコミュニケーションを通じて人々に組織的なサポートと勢いを与えます。 次の DevOps プロジェクトの波に携わっていて、初めて DevOps を使用することに不安を感じている人々をコーチします。 そして、これらの人々は開拓者とは大きく異なるということを忘れないでください。」

5. ツールの民主化

Scalyrの創設者兼会長であるスティーブ・ニューマン氏は次のように述べています。 「ツールは人々から隠されるべきではなく、時間をかけて誰でも比較的簡単に習得できるものでなければなりません。 ログをクエリできる権限が、ツールの使用が「認定された」 XNUMX 人に制限されている場合、非常に大規模なコンピューティング環境であっても、問題を処理できる人員は常に最大 XNUMX 人になります。 言い換えれば、ここには重大な（ビジネス上の）結果につながる可能性のあるボトルネックがあるのです。」

6. チームワークに理想的な環境を作り出す

ITV の共通プラットフォーム責任者、トム・クラーク氏は次のように述べています。 「何でもできますが、一度にすべてを行うことはできません。 したがって、大きな目標を設定し、小さなことから始めて、迅速な繰り返しで前進してください。 時間が経つにつれて、あなたは物事を成し遂げるという評判が高まり、他の人もあなたの方法を使いたがるようになります。 非常に効果的なチームを構築することについて心配する必要はありません。 その代わりに、人々に理想的な労働条件を提供すれば、効率は後からついてきます。」

7. コンウェイの法則とカンバンボードを忘れないでください

CollabNetVersionOne のソフトウェア デリバリーおよび DevOps 戦略担当ディレクター、Logan Daigle 氏は次のように述べています。 「コンウェイの法則の結果を理解することが重要です。 私の大雑把な言い換えでは、この法律は、私たちが作成する製品と、DevOps を含むそのために使用するプロセスは、私たちの組織と同じ方法で構造化されることが判明すると述べています。」

「組織内に多くのサイロがあり、ソフトウェアの計画、構築、リリース時に管理者の手が何度も変わる場合、スケーリングの効果はゼロになるか、短期間しか持続しません。 組織が市場を重視して資金提供される製品を中心に部門横断的なチームを構築すれば、成功の可能性は劇的に高まります。」

「スケーリングのもう XNUMX つの重要な側面は、すべての進行中の作業 (WIP、作業中) をカンバン ボードに表示することです。 組織にこれらのことを人々が確認できる場所があると、コラボレーションが大幅に促進され、規模の拡大にプラスの影響を及ぼします。」

8. 古い傷跡を探す

DevOps コンサルタントであり、『Team Topologies』の共著者である Manuel Pais 氏は次のように述べています。 「DevOps プラクティスを Dev と Ops 自体を超えて取り上げ、他の機能に適用しようとすることは、最適なアプローチとは言いがたいです。 これは確かに（手動制御の自動化などにより）ある程度の影響を及ぼしますが、提供とフィードバックのプロセスを理解することから始めれば、さらに多くのことを達成できるでしょう。」

「組織の IT システムに古い傷跡がある場合、つまり過去のインシデントの結果として実装されたものの、(製品、テクノロジー、またはプロセスの変更により) 関連性を失った手順や管理メカニズムがある場合、それらは確実に除去する必要があります。非効率または不必要なプロセスを自動化するのではなく、円滑化する必要があります。」

9. DevOps オプションを増やさない

Eggplant オペレーションディレクター、アンソニー・エドワーズ氏: 「DevOps は非常に曖昧な用語なので、最終的には各チームが独自のバージョンの DevOps を作成することになります。 そして、組織に突然、うまく連携できない 20 種類の DevOps が導入された場合、これほど悪いことはありません。 XNUMX つの開発チームがそれぞれ、開発と製品管理の間に独自の特別なインターフェイスを持つことは不可能です。 また、製品が実稼働シミュレーターに転送されたときのフィードバックの処理について、独自の期待を持たせる必要もありません。 そうしないと、DevOps を拡張することはできません。」

10. DevOps のビジネス価値を説く

Scalyrの創設者兼会長であるスティーブ・ニューマン氏は次のように述べています。 「DevOpsの価値を認識するよう努めてください。 自分の活動の利点について学び、遠慮なく話してください。 DevOps は時間とお金を驚くほど節約します (ダウンタイムが減り、平均復旧時間が短縮されることを考えてください)。DevOps チームは、ビジネスの成功に対するこれらの取り組みの重要性をたゆまぬ強調 (そして説教) する必要があります。 こうすることで、支持者の輪を広げ、組織内での DevOps の影響力を高めることができます。」

ボーナス

На レッドハットフォーラムロシア 当社独自の DevOps は 13 月 XNUMX 日に登場します。はい、Red Hat はソフトウェア メーカーとして、独自の DevOps チームと実践を持っています。

組織全体の他のグループ向けに内部自動化サービスを開発しているエンジニアの Mark Birger が、純粋なロシア語で自身のストーリーを語ります。Red Hat DevOps チームが、Ansible によって管理されている Hat Virtualization 仮想環境からアプリケーションを本格的なコンテナ形式に移行した方法について説明します。 OpenShift プラットフォーム。

しかし、それだけではありません。

組織がワークロードをコンテナに移行すると、従来のアプリケーション監視方法が機能しなくなる可能性があります。 XNUMX 番目の講演では、ログ記録方法を変更する動機を説明し、最新のログ記録と監視方法に至るまでの道のりの続きを示します。

出所： habr.com