クラウドコンピューティング時代の DevOps について知らないこと

この記事では、DevOps を高レベルで素早く理解し、文化を変えるための実践方法を紹介します。 DevOps の目標と、DevOps の概念の基盤を築くために組織管理からのサポートを得る方法について説明します。アプリケーションライフサイクル管理をシンプルかつ効率的にする基本的な DevOps プラクティスを紹介します。

[[283202]]

DevOps はフレームワークでも、ツールでも、テクノロジーでもないことを理解することが重要です。それは組織の文化とより関係があります。 DevOps は、組織内で事前定義されたプロセスを使用し、自動化ツールを活用して日常業務の効率化と手作業の削減を図るアプローチでもあります。

DevOps の重要性を理解するために、この記事では以下のトピックについて説明します。

• DevOps の必要性;
• DevOps 文化を育成する方法。
• PPT（人、プロセス、テクノロジー）の重要性。
• DevOps がツールだけの問題ではない理由
• DevOps 評価の質問。

1.1 DevOpsの必要性

すべての偉大な夢は夢想家から始まります。あなたには星を目指して世界を変える強さ、忍耐力、情熱があることを常に忘れないでください。

変化は人生の法則であり、それは組織にも当てはまります。組織や個人が過去または既存のモデル、文化、または慣行のみに注目すると、将来のベストプラクティスを見逃してしまうことになります。ダイナミックな IT の世界では、技術革新のペースに遅れずについていかなければなりません。

ジョージ・バーナード・ショーの有名な言葉を挙げてみましょう。

変化がなければ進歩はありません。自分の考えを変えなければ、何も変えることはできません。

現在、私たちはアプリケーションライフサイクル管理へのアプローチの変更に注力しています。重要なのは、この変更が本当に必要かどうかです。私たちは本当に変化の苦痛を経験する必要があるのでしょうか?

答えはイエスです。

こうしたビジネスや文化の変化は強制することはできないと言う人もいるかもしれません。

同意する。

図 1-1 を参考にして、現代のアプリケーション ライフサイクル管理において組織が直面する問題点を理解しましょう。

図1-1

ビジネスにおけるパターンの変化と競争環境を考慮すると、アプリケーション ライフサイクル管理の改善が最優先事項となります。

現代のアプリケーションライフサイクル管理を改善するために役立つ要素は何でしょうか?

はい、クラウド コンピューティングはゲームチェンジャーであり、多くの画期的なソリューションとイノベーションへの扉を開きました。クラウド コンピューティングの本当の意味と、DevOps や自動化などの用語が企業で果たす重要な役割について理解しましょう。

1.1.1 クラウドコンピューティングの概要

クラウド コンピューティングは、コンピューティング革命における次の論理的なステップです。従来のデータ センターや仮想化からハイブリッド環境、プライベート クラウド、パブリック クラウド、ハイブリッド クラウド サービスに至るまで、クラウド コンピューティングは、マルチテナントまたは専用のコンピューティング リソース (コンピューティング、ストレージ、ネットワークなど) をクラウド コンシューマーにオンデマンドで提供するコンピューティングの一種です。クラウド コンピューティングには、さまざまなクラウド展開モデルやクラウド サービス モデルなど、さまざまな種類があります。最も重要なのは、使った分だけ支払うという価格モデルです。

クラウド展開モデルは、クラウド リソースを展開する方法です。

1) プライベート クラウド: プライベート クラウドは、特定の組織専用のファイアウォールの背後にあるオンプレミスのクラウド リソースで構成されます。

2) パブリッククラウド: パブリッククラウドは、すべての組織や個人が利用できるクラウドリソースで構成されます。

3) ハイブリッド クラウド: ハイブリッド クラウドは、同様の関心や同様の種類の要件を持つ組織のグループが利用できるクラウド リソースで構成されます。

4) コミュニティ クラウド: コミュニティ クラウドは、2 つ以上の展開モデルを組み合わせたクラウド リソースで構成されます。

クラウド サービス モデルは、さまざまな種類の顧客 (個人、小規模組織、大規模企業) にクラウド リソースが提供される方法を説明します。

クラウド サービス モデルには、クラウド顧客またはエンド ユーザーがアクセスして制御できる仮想マシンの純粋なインフラストラクチャ (IaaS) が含まれます。クラウド サービス プロバイダーは、ランタイム サービスを提供して、アプリケーションの実行に必要なすべてのソフトウェアのインストールと構成のためのプラットフォーム (PaaS) を提供および管理します。クラウド サービス プロバイダーはアプリケーション全体を提供し、インフラストラクチャとプラットフォームの Software as a Service (SaaS) を担当します。

近年、さまざまなサービスモデルが登場していますが、IaaS、PaaS、SaaSは、図1-2に示すように、米国国立標準技術研究所（NIST）の定義に基づいています。

クラウド コンピューティングには、マルチテナント、電気やガスに似た従量課金モデル、コンピューティング、ストレージ、ネットワーク リソースの利用率を高めるためのオンデマンド セルフサービスとリソース プーリング、必要に応じてリソースを自動的に拡張および縮小するための迅速なスケーリング、課金のための測定可能なサービスなど、いくつかの重要な機能があります。

長年にわたり、さまざまなクラウド展開モデルの使用は、ユースケースに応じて変化してきました。当初、パブリック クラウドは重要でないアプリケーションに使用され、プライベート クラウドはセキュリティが懸念される重要なアプリケーションに使用されていました。ハイブリッド クラウドとパブリック クラウドの使用は、時間の経過とともに、またクラウド サービス プロバイダーが提供するサービスに対する経験と信頼とともに進化します。同様に、さまざまなクラウド サービス モデルの使用は、ユースケースと柔軟性によって異なります。初期の頃は IaaS が最も人気がありましたが、その後、自動スケーリング、複数言語のサポート、エンドツーエンドのアプリケーション ライフサイクル管理ツールのサポートなど、その成熟度と使いやすさにより、PaaS が普及しました。

図1-2

1.1.2 DevOpsの概要

DevOps とは、開発チームと IT 運用チーム間のコラボレーションを可能にし、アプリケーション ライフサイクルを現在よりも効率的に管理できる組織文化、プロセス、テクノロジを開発することです (図 1-3 を参照)。職場では、類似の問題や課題から再利用可能な解決策を見つけるためにパターンを探す傾向があります。

図1-3

数年後、成功した実験や失敗した実験、ベストプラクティス、自動化スクリプト、構成管理ツール、方法論は、DevOps 文化の不可欠な部分になりました。

DevOps は、設計方法、開発方法、テスト方法、インストール方法、環境管理方法、構成管理方法、アプリケーションの展開方法、フィードバック収集方法、コード改善方法、イノベーション方法の定義に役立ちます。

DevOps プラクティスを採用することで得られる明らかなメリットをいくつか紹介します。

DevOps は、開発チームと運用チームを効率的に統合する一連のイノベーションです。これらの方法には、継続的なビルド統合、継続的なテスト、クラウド リソースの割り当て、継続的な配信、継続的な展開、継続的な監視、継続的なフィードバック、継続的な改善、継続的なイノベーションが含まれ、アジャイル手法の要件に応じてアプリケーションをより迅速に提供できます。文化の発展は一夜にして達成できるものではありません。時間がかかります。しかし、DevOps とは何かについての概念的な混乱がまだ残っています。多くの場合、個別の継続的インテグレーションまたは構成管理プラクティスは DevOps プラクティスと見なされます。これは盲人が象に触れるようなものです。図1-4に示すように、誰もが自分が触れる部分を象全体とみなします。

図1-4

ただし、DevOps には開発チームと運用チームだけが関与するわけではありません。テスト チーム、ビジネス アナリスト、ビルド エンジニア、自動化チーム、クラウド チーム、その他多くの関係者を既存の文化の進化に関与させます。

DevOps と組織文化はそれほど違いはありません。彼らは共通の価値観と行動特性を共有しており、新しいテクノロジーとツールに合わせて考え方とプロセスを調整する必要があります。

開発チームと運用チームが直面する課題

いくつかの現実的な課題により、DevOps は上昇傾向にあり、あらゆる情報技術関連の議論でホットな話題となっています。

開発チームが直面する課題

開発者は、新しいテクノロジーや問題解決の新しい方法を採用することに熱心です。しかし、彼らは多くの課題に直面しています。

競争の激しい市場では、期限内に納品しなければならないというプレッシャーが生じます。

本番環境に対応したコード管理と新機能の実装を担当する必要があります。

リリース サイクルは長いことが多いため、開発チームはアプリケーションの展開が最終的に行われる前に仮定を立てる必要があります。この場合、ステージング環境または本番環境での展開中に発生する問題を修正するのにさらに時間がかかります。

運用チームが直面する課題

運用チームは安定性が必要なため、リソースの変更、新しいテクノロジー、新しいアプローチに対して常に慎重です。しかし、彼らは多くの課題にも直面しています。

リソース競合: 増大するリソース需要の処理が困難になります。

再設計または調整: アプリケーションを本番環境で実行するために必要です。

診断と修正: アプリケーションの展開が外部から分離された状態で、問題を診断して修正する必要があります。

ITチームが直面する課題

IT チームは、各チームに運用に必要なリソースを提供します。

インフラストラクチャのプロビジョニング: 適切なインストール パッケージを使用してインフラストラクチャとランタイム環境を提供します。

構成管理: ツールやテクノロジーが利用可能になったときに、既存のインフラストラクチャまたはソフトウェア パッケージをアップグレードします。

開発チームと運用チームが直面しているすべての課題を考慮すると、既存のプロセスを改善し、自動化ツールを使用してプロセスを効率化し、人々の考え方を変えるにはどうすればよいでしょうか。次のセクションでは、効率性と有効性を向上させるために組織内で DevOps 文化を育成する方法を学びます。

1.2 DevOps文化を育む方法

非効率的な見積もり、市場投入までの時間の長さ、その他の問題により、ウォーターフォール モデルからアジャイル モデルへの変更が行われました。文化的進化は、決まった時間枠があるプロセスでも、一夜にして完了できるプロセスでもありません。これは、他のフェーズに依存せずに完了できる、段階的なプロセスになります。

クラウド プロビジョニングを使用せずに継続的インテグレーションを実装することも、構成管理を実装せずにクラウド プロビジョニングを実装することもできます。 DevOps プラクティスなしで継続的なテストを実現することもできます。図 1-5 は、DevOps プラクティスを実装するさまざまな段階を示しています。

図1-5

1.2.1 アジャイル開発

アジャイル開発またはアジャイルベースの方法論は、権限を分散し、相互作用を促進し、動作するソフトウェアを評価し、顧客とのコラボレーション（フィードバックを使用して次のステップを改善）し、変更に効率的に対応するアプリケーション構築に役立ちます。

アジャイル開発の最も魅力的な利点の 1 つは、短期間での継続的な配信 (アジャイル用語では「スプリント」と呼ばれます) です。したがって、アプリケーション開発、技術の進歩、破壊的イノベーション、および方法論に対するアジャイルなアプローチにより、開発チームと運用チームの間に溝が生じています。

1.2.2 デブオプス

DevOps は、開発チームと運用チーム間のパートナーシップを構築することで、このギャップを埋めようとします。 DevOps アクティビティでは、ソフトウェア開発者と IT 運用の間のコミュニケーション、コラボレーション、統合を重視します。

DevOps は、自動化とオーケストレーションを通じてプロセスを改善することでコラボレーションを促進し、それを容易にします。言い換えれば、DevOps は本質的に、アジャイル活動の継続的な開発目標を継続的なインテグレーションとリリースに拡張します。 DevOps は、クラウド ソリューションの力を活用するアジャイル プラクティスとプロセスの組み合わせです。アジャイル開発およびテスト方法論は、アプリケーションの継続的な統合、開発、構築、展開、テスト、リリースの目標を達成するのに役立ちます。

ビルド自動化

ビルド自動化 Gradle、Apache Ant、Apache Maven などのビルド自動化ツールを使用すると、アプリケーション ビルドを作成できます。

自動ビルド プロセスには、ソース コードをクラス ファイルまたはバイナリ ファイルにコンパイルする、サード パーティ ライブラリ ファイル参照を提供する、構成ファイル パスを提供する、クラス ファイルまたはバイナリ ファイルをパッケージ ファイルにパッケージ化する、自動テスト ケースを実行する、ローカル マシンまたはリモート マシンにパッケージ ファイルを展開する、パッケージ ファイル作成における手作業を削減するなどのアクティビティが含まれます。

継続的インテグレーション

簡単に言うと、継続的インテグレーション (CI) とは、開発者によるすべてのチェックインが次のいずれかの方法を使用して検証されるソフトウェア エンジニアリングのプラクティスです。

「プル」メカニズム: スケジュールされた時間に自動ビルドを実行します。

「プッシュ」メカニズム: 変更がリポジトリに保存されると、自動ビルドが実行されます。

このステップの後、ソース コード リポジトリ内の最新の変更に対して単体テストが実行されます。継続的インテグレーションは、開発者がコードの整合性を検証するために、1 日に数回 Git や SVN などのコード リポジトリにコードを統合する必要がある、一般的な DevOps アプローチです。

自動ビルドによって各チェックインが検証され、チームは問題を早期に検出できるようになります。

CI (さらには CD) は、企業の同期された DevOps アーカイブのベースラインです。組織内で CI と CD を適切に実装しなければ、DevOps を実装することはできません。

クラウドプロビジョニング

この章の前半では、クラウド コンピューティングの基礎について紹介しました。クラウド プロビジョニングにより、Infrastructure as Code (IAC) への扉が開かれ、手動介入を必要とするプロセスの大部分が自動化されるため、プロセス全体が非常に効率的になります。

従量課金制の課金モデルにより、大規模な組織だけでなく、中小規模の組織や個人にとっても必要なリソースをより手頃な価格で利用できるようになります。

クラウド プロビジョニングにより、コストとメンテナンスの観点から、以前はリソースの制約により組織のさらなる成長が妨げられていた箇所の改善と革新が促進されます。インフラストラクチャ リソースの俊敏性を確保したら、アプリケーションの実行に必要なパッケージのインストールと構成を自動化することを検討できます。

構成管理

構成管理 (CM) システム、具体的にはサーバー ランタイム環境の変更。市場で入手可能な多くのツールを使用して構成管理を実装できます。人気のあるツールには、Chef、Puppet、Ansible、Salt などがあります。

同じ構成で複数のサーバーを管理する必要がある例を考えてみましょう。

たとえば、各サーバーに Tomcat をインストールする必要があります。すべてのサーバーのポートを変更したり、特定のソフトウェア パッケージを更新したり、特定のユーザーに権限を付与したりする必要がある場合はどうすればよいでしょうか?このような状況での変更はすべて手動で行う必要があり、エラーが発生しやすいプロセスとなります。すべてのサーバーが同じ構成を使用するため、自動化を活用できます。

継続的デリバリー

継続的デリバリーと継続的デプロイメントは同じ意味で使用される用語です。ただし、両者の間には若干の違いがあります。

継続的デリバリーは、あらゆる環境にアプリケーションを自動的にデプロイし、継続的なフィードバックを提供して品質を向上させるプロセスです。継続的デリバリーと継続的デプロイメントにおける自動化へのアプローチは変わりません。ただし、承認プロセスやその他の細かい詳細は変更される可能性があります。

継続的なテストと展開

継続的テストは、機能テスト、パフォーマンス テスト、セキュリティ テストなどを含む、エンドツーエンドのアプリケーション ライフサイクル管理プロセスにおける非常に重要な段階です。

Selenium、Appium、Apache JMeter、その他多くのツールを同じ目的で使用できます。一方、継続的デプロイメントとは、最新の変更を本番環境にアプリケーションをデプロイすることです。

継続的な監視

継続的な監視はエンドツーエンドの配信パイプラインのバックボーンであり、オープンソースの監視ツールはアイスクリームスクープのヘッドのようなものです。

図 1-6 に示すように、すべてのプロセスの透明性を確保するには、ほぼすべての段階で監視を設定することが非常に望ましいです。これにより、障害のトラブルシューティングも迅速に行えます。監視は十分に検討された計画に基づいて実施する必要があります。

図1-6は連続方式の全体のプロセスを説明しています。

これは段階的なアプローチであり、各フェーズの自動化を必ずしも一度に完了する必要はないことを理解する必要があります。一度に 1 つの DevOps プラクティスを選択し、それを実装してその利点を理解してから、別の DevOps プラクティスを実装する方が効果的です。

このようにして、組織文化の変更とアプリケーション ライフサイクル管理からの手作業の排除によってもたらされる改善を安全に評価できます。

図1-6

1.3 PPTの重要性 - 人、プロセス、テクノロジー

PPT はどの組織でも重要な言葉です。待って！ PowerPoint プレゼンテーションについて話しているのではありません。ここでは、人、プロセス、ツール/テクノロジーに焦点を当てます。組織の文化を変える際に、なぜこれらの要素が重要なのかを理解しましょう。

1.3.1 人々

ジャック・クランフィールドの言葉を引用します。

周囲で何が起こっても、成功した人は常に人生を前向きに捉えます。彼らは過去の失敗ではなく過去の成功に目を向け、生活の中で他のことに気を取られるのではなく、目標に近づくための次の行動に焦点を当てます。

なぜ人は重要なのでしょうか?これは興味深い質問です。一言で答えるなら、「私たちは文化を変えようとしているからです」です。

だから何？

人はあらゆる文化の重要な部分であり、人だけが文化の変化を推進したり、新しいプロセスに適応したり、新しいプロセスを定義し、新しいツールやテクノロジーを学んだりするために自分自身を変えたりすることができます。

これを変換方程式を使って理解してみましょう。

Wikipedia によると、デイビッド・グライヒャーは 1960 年代初頭に変化の方程式を作り出したそうです。キャシー・ダネミラーは 1980 年にこの方程式を完成させました。この方程式は、組織変更イニシアチブの成功確率に影響を与える相対的な強みを評価するためのモデルを提供します。

Gleicher の (オリジナル) バージョンは、C = (ABD) >X です。ここで、C = 変化、A = 現状への不満、B = 望ましい状態、D = 望ましい状態を達成するための実際的な手順、X = 変化のコストです。

Dannemiller のバージョン: D×V×F>R。組織の変化が起こるためには、D、V、F が存在する必要があります。D = 現状への不満、V = 可能な目標のビジョン、F = ビジョンを達成するために実行できる最初のいくつかの具体的なステップ。これら 3 つの要素の積が R (抵抗) より大きい場合、変更は成功する可能性が高くなります。

本質的に、この公式は、既存の業務やプロセスに対する不満、新しいトレンド、テクノロジー、市場ソリューションにおけるイノベーションのビジョン、そしてそのビジョンを実現するための具体的なステップが必要であると述べています。

「変化の公式」の詳細については、Wikipedia のページをご覧ください: https://en.wikipedia.org/wiki/Formula_for_change#cite_note-myth-1

経験の共有として、新しい文化に適応できるように人々を訓練することは非常に重要であり、忍耐を必要とするゲームだと思います。人々の考え方を一夜にして変えることはできません。文化を変える前に、まず理解する必要があります。

業界では、文化の変化は DevOps の知識や DevOps エンジニアから始まるとよく見受けられますが、理想的には、これらを「輸入」するのではなく、既存の環境を徐々に変えていき、その中で人々をトレーニングして抵抗を抑制していく必要があります。専用の DevOps チームは必要ありません。必要なのは、開発者、テスト チーム、自動化実装者、クラウドまたはインフラストラクチャ チーム間のコミュニケーションとコラボレーションの強化です。

全員がお互いの問題点を理解することは、重要なステップです。私がこれまで働いてきた組織では、新しいテクノロジー、イノベーション、文化を管理するために Center of Excellence (COE) を設置するのが一般的でした。自動化の実装者および DevOps チームの一員として、私たちは孤立した「サイロ」のメンバーではなく、ファシリテーターの役割のみを果たす必要があります。

1.3.2 プロセス

トム・ピーターズはかつてこう言いました。

ほぼすべての品質改善は、設計、製造、レイアウト、プロセス、手順の簡素化から生まれます。

文化の発展においては、品質が極めて重要です。作業を正しく完了し、プロジェクトを標準化して、操作の順序、制約、ルールなどが明確に定義され、成功を測定できるようにするためのプロセスと戦略が必要です。

以下のタスクの手順を確立する必要があります。

アジャイル計画。

リソースの計画と割り当て。

構成管理。

自動化で使用されるクラウド リソースやその他のツールへのロールベースのアクセス制御。

プログラミング言語の静的コード分析ルール。

テスト方法とツール。

リリース管理。

これらのプロセスは、DevOps 文化の開発の成功を測定するためにも重要です。

1.3.3 テクノロジー

スティーブ・ジョブズは有名な言葉を残しています。

テクノロジーは重要ではありません。大切なのは、人々に対する信頼です。彼らは優秀で賢く、ツールを与えれば素晴らしいことを成し遂げられるのです。

テクノロジーは、人々や組織がアイデアを生み出し、革新し、文化を変えるのに役立ちます。テクノロジーがなければ、日常的な業務を自動化してスピードと効率性を達成することは困難です。クラウド コンピューティング、構成管理ツール、ビルド パイプラインは、リソースのプロビジョニング、ランタイム環境のインストール、オーケストレーションに役立ちます。アプリケーション ライフサイクル管理のさまざまな側面を大幅に高速化します。

1.4 DevOps がツールだけの問題ではない理由

はい、ツールは何も意味しません。組織文化の変化においてツールは重要な要素ではありません。理由は簡単です。使用するテクノロジーに関係なく、継続的インテグレーション、クラウド プロビジョニング、構成管理、継続的デリバリー、継続的デプロイメント、継続的モニタリングなどを実装する必要があります。

各カテゴリ内では異なるツール セットが利用可能ですが、すべてのツールは同様の操作を実行します。ツールによって操作の実行方法は異なりますが、結果は同じです。表 1-1 に、カテゴリ別にリストされたツールをいくつか示します。

表1-1

さまざまな運用作業のさまざまな段階で使用されるさまざまなツールを見てみましょう。これは、図 1-7 に示すように、さまざまな組織の環境の数や DevOps プラクティスによって異なる場合があります。

図1-7

さまざまな DevOps ベストプラクティスに基づいてツールを分類する必要がある場合は、オープンソースと商用に分類できます。表1-2にいくつかの例を示します。

表1-2

1.5 DevOps評価の質問

DevOps は文化であり、私たちはそれをすでに知っています。ただし、自動化を実装し、プロセスと文化を開発する前に、組織文化の現状を理解し、新しいプロセスや自動化ツールを導入する必要があるかどうかを理解する必要があります。

私たちに必要なのは文化を輸入することではなく、既存の文化をより効率的にすることだということを、私たちは明確に認識しなければなりません。

特定のアプリケーションに基づいて、質問のカテゴリを作成し、回答を導き出します。

以下に質問の例をいくつか示します。

1. アジャイル原則に従っていますか?

2. ソースコードリポジトリを使用していますか?

3. 静的コード分析ツールを使用していますか?

4. ビルド自動化ツールを使用していますか?

5. オンプレミスまたはクラウドベースのインフラストラクチャを使用していますか?

6. 構成管理ツール、アプリケーション パッケージをインストールするためのスクリプト、またはランタイム環境を使用していますか?

7. 運用環境と非運用環境でアプリケーションをデプロイするために自動化スクリプトを使用していますか?

8. アプリケーション ライフサイクル管理にオーケストレーション ツールまたはスクリプトを使用していますか?

9. 機能テスト、負荷テスト、セキュリティ テスト、モバイル テストに自動化ツールを使用していますか?

10. アプリケーションおよびインフラストラクチャの監視ツールを使用していますか?

質問が準備できたら、回答を準備し、上記の質問に対する各回答に基づいて成績を決定します。

フレームワークを柔軟に保ち、どのカテゴリの問題が変更されても自動的に管理できるようにします。

評価後、回答をキャプチャして全体的な評価を計算するために、さまざまな条件とインテリジェンスがフレームワークに導入されます。

各分類の最終評価を作成し、最終評価に基づいてさまざまな種類のグラフを作成して、理解しやすくします。ここで注目すべきは、アプリケーション ライフサイクル管理のさまざまな分野における組織の専門知識です。これにより、評価フレームワークに新たな次元がもたらされ、インテリジェンスが追加され、効率が向上します。

1.6 まとめ

この記事では、この本が達成するいくつかの目標を示しました。継続的インテグレーション、クラウド環境でのリソースプロビジョニング、構成管理、継続的デリバリー、継続的デプロイメント、継続的モニタリングについて説明しました。

設計目標はビジョンを明確にするための第一歩です。

クラウド コンピューティングがイノベーションに対する考え方をどのように変え、それが実行可能な選択肢になったかを見てきました。また、DevOps の必要性とさまざまな DevOps プラクティスについても簡単に説明しました。組織の既存の文化を変えるプロセスでは、人、プロセス、テクノロジーも重要です。私たちはそれらの重要性を指摘しようと努めています。ツールは重要ですが、それだけではありません。あらゆるツールセットを活用でき、文化を変えるのに特定のツールセットは必要ありません。また、文化的な変化の道のりに役立つ DevOps 評価フレームワークについても簡単に説明しました。