DevOpsとは何か？包括的な紹介

DevOpsは、どの業界においても企業の生産性を向上させるために人気のあるトレンドです。毎日、多くの企業がこの破壊的なモデルを自社に取り入れようとしています。

DevOpsには、達成すべき1つの主な目標があります：継続的インテグレーションから継続的デリバリーへ。

これにより、開発および運用プロセスが迅速になり、リソースの使用が効率的になります。企業は、顧客消費や内部使用のために、より高品質なソフトウェア製品を生産しながらコストを削減することができます。

この入門記事では、DevOpsの基本概念、ここに至るまでの経緯、ベストプラクティス、主要なトポロジー、およびDevOps環境の最も一般的な利点について説明します。

DevOpsとは何か？

従来、IT業界では、従業員は開発または「Dev」チームに属していました。IT運用または「Ops」として知られる別のチームがITをサポートするために働いていました。

DevチームとOpsチームは、別々のリーダーシップ、責任、および達成すべき目標を持っていました。多くの企業では、チームは別々のフロアで作業し、ほとんどコミュニケーションをとることはありませんでした。この「サイロ」文化は、これらのチーム間のコミュニケーションとコラボレーションを悪化させ、絶対に必要なときだけ架け橋をかけるという厳格な障壁を生んでいました。

DevOpsの大きな組織文化の変革は、このサイロの考え方を破り、DevチームとOpsチームのギャップを埋めました。彼らが行うべきことは：

協力して作業する
責任を共有する
提供するソフトウェアのライフサイクル全体にわたって完全に所有する

現在、DevOpsはIT業界で広く受け入れられており、Amazon、Facebook、Google、Netflix、BMCソフトウェアなどの主要なテクノロジー企業が含まれています。最近では、企業は、ITを超えて組織全体にDevOpsの原則を広める方法を模索しています。

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

継続的デリバリー

DevOpsの発展

2000年以前、ほとんどのIT業界は古典的なウォーターフォールモデルを採用し、ソフトウェア開発のための線形アプローチを取っていました。

開発者は、多くの時間をかけて重いコードを開発し、統合する必要がありました。
サイロで作業していたQAエンジニアや運用チームは、コードをテストするのにもっと多くの時間を費やしました。

その結果、ソフトウェアリリースの間に大きな、時には数年にわたるギャップが生じ、各リリースの間に頻繁にバグ修正やソフトウェアパッチが展開されました。

アジャイルソフトウェアメソッドの確立により、IT業界はソフトウェアを反復的に開発し、頻繁に本番環境にリリースするようになりました。継続的インテグレーション（CI）と継続的デリバリー（CD）は、このモデルでソフトウェアを迅速に提供するために適応された主要な技術の一つです。（これらの概念は後で詳しく見ていきます。）

その結果、DevOpsは開発と運用チーム間の円滑なコラボレーションを促進し、サイクルの各ステップでの協力を可能にしました。したがって、DevOpsはアジャイルメソッドにルーツを持つと言えます。

(DevOpsの歴史について詳しく学ぶ)

DevOps文化

DevOps文化に移行する際、組織は2つの重要な要素を変更する必要があります：

従来の運用方法
マインドセット

一般的に、DevOps文化では、DevチームとOpsチームの両方が頻繁にコミュニケーションを取りながら協力して作業します。

一部の組織では、DevOpsエンジニアが開発と運用の両方の作業を行う場合があります。彼らは、職務の定義された範囲に責任を制限することはありません。むしろ、彼らは常に他のチームと責任を共有し、開発ライフサイクル全体を自分の責任の一部と見なします。

これらのエンジニアは、生産性とサービスの質を向上させ、顧客に最大の価値を提供することを目指しています。

もちろん、DevOpsは単にコミュニケーションとコラボレーションだけではありません。DevOpsのベストプラクティスは、頻繁にソフトウェアをリリースし、最高の品質を確保するのに役立ちます。高い効率を優先することで、DevOpsは手動タスクの自動化に広く使用されるツールの使用を奨励します。

DevOps文化の一般的なプラクティスと関連ツールを見てみましょう。

従来、開発者は手動でコードを更新し、その後手動でテストしていました。

継続的インテグレーション（CI）は、開発者が頻繁にコード変更を中央リポジトリにマージするDevOpsのプラクティスです。その後、コードが自動的にビルドされ、自動テストがビルドされたコードに対して実行されます。

これの主な目的は、バグを迅速に特定してソフトウェアの品質を向上させることです。

継続的デリバリー（CD）では、マージされたコード変更が自動的にビルドされ、テスト環境に展開されます。その後、自動テストが展開されたコードに対して実行され、バグを特定し、開発者が事前に修正できるようにします。

通常、コードは段階的に異なるテスト環境に展開され、標準的な自動テスト手順を通じて品質が向上します。その後、本番環境に展開されます。継続的デリバリーは、チームが常に開発準備が整ったコードを持つことを保証します。

Jenkins、Bamboo、Travis、TeamCityなどのCI/CDツールは、これらの作業を自動化するのに役立ちます。

(CI/CDと継続的デプロイメントがフィットするかどうかを探る)

継続的テスト

継続的テストのプラクティスは、開発ライフサイクルのすべての段階で潜在的なリスクを可能な限り早く特定し、エンドユーザーへの影響を最小限に抑えるのに役立ちます。

たとえば、コードがビルドサーバーに展開されると、自動ユニットテストが実行され、コード内のバグが特定されます。ユニットテストが失敗した場合、ビルドは拒否され、フィードバックが開発者に送信され、コードを修正するように指示されます。したがって、ビルドがユニットテストに合格した場合にのみ、コードがQA環境に展開されて機能テストが行われます。

Selenium、Travis、Appiumは、IT業界で人気のある継続的テストツールの一部です。

継続的モニタリング

アプリケーション、インフラストラクチャ、ミドルウェア、ネットワークは、そのパフォーマンス、欠陥、セキュリティおよびコンプライアンスのために継続的に監視されます。問題を特定するために、ほとんどの企業は次のようなメトリクスを監視します：

CPUおよびメモリ使用量
ディスクスペース
顧客の活動
セキュリティポリシー

継続的モニタリングを実践することで、テストから本番環境までの環境の問題について常に警告され、高可用性を確保するのに役立ちます。

人気のある継続的モニタリングツールには、Nagios、Sensu、Prometheusなどがあります。

コードとしてのインフラストラクチャ

コードとしてのインフラストラクチャ（IaC）は、インフラストラクチャ（仮想マシン、ロードバランサー、ネットワークなど）を手動で設定して管理するのではなく、コードを使用して構成および管理するプラクティスです。これは、特にクラウドプラットフォームに移行した組織において、重要なDevOpsプラクティスとなっています。

たとえば、Amazon Web Services（AWS）は、クラウドインフラストラクチャとプログラム的に対話するためのAPIを提供しています。構成を定義するためにコードを使用すると、プロセスを標準化し、迅速にリソースをクラウドに展開することができます。

マイクロサービス

従来のモノリシックアーキテクチャとは異なり、マイクロサービスアーキテクチャでは、単一のアプリケーションが小さなサービスまたはコンポーネントのセットとして構築されます。これらの別々のサービスはそれぞれ独自の機能を持ち、通信は軽量なインターフェースまたはAPIを介して行われます。

DevOps文化で広く採用されているアーキテクチャとして、マイクロサービスは：

異なるコンポーネント内での独立したリソース管理を促進します。
単一障害点を防ぐことにより、システムの可用性を高めます。あるコンポーネントがクラッシュしても他のコンポーネントに影響を与えません。
DevOpsチームが他のコンポーネントに影響を与えることなく、異なる機能を持つ追加のコンポーネントを追加できるようにします。

(マイクロサービスのベストプラクティスを理解する)

DevOpsトポロジー

DevOpsが実践される方法は、組織に大きく依存します。Matthew SkeltonとManual Paisによれば、組織はDevOpsが繁栄するために異なるタイプのトポロジーやチーム構成を採用します。彼らは次のように9つのタイプのトポロジーを定義しています。

DevOpsプラクティス

DevとOpsのコラボレーション

これは、DevとOpsのチームがスムーズに協力する理想的なDevOpsチーム構成です。たとえば：

開発者は、必要に応じて運用チームからのタスクを真剣に受け取り、彼らの意見を受け入れます。
運用チームは、開発チームが日常的に実行するタスクを十分に理解します。

完全に共有されたOpsの責任

FacebookやNetflixで実施されているこのトポロジーは、Devチームに運用チームが統合されています。開発者と運用チームの間にはわずかな分離しか見られません。

これは、ウェブベースの単一アプリケーションを持つ企業に最も適しています。

インフラストラクチャとしてのサービス

このトポロジーは、クラウドプラットフォームにホストされている異なるまたは複数のサービスを持つ組織に適していますが、依然として変わる可能性の低い従来のIT運用部門があります。彼らのOpsチームは、インフラストラクチャとしてのサービス（IaaS）に似ています。

外部サービスとしてのDevOps

一部の組織では、専門知識が不足しているか、別の運用チームを持つ余裕がない場合があります。ここでは、開発チームがソフトウェアの運用面の責任を管理できるサービスプロバイダーからサポートを受けることができます。

有効期限付きのDevOpsチーム

この構造は、一時的なチームとして機能し、DevとOpsのチームを一緒に持ってくることに取り組みます。その一時的なチームは、事前に定義された目標を達成した後に廃止されます。

DevOpsの擁護チーム

このトポロジーは、分裂する傾向のあるチームに最も適しています。擁護チームは、開発と運用のグループを促進し、彼らが関与し続け、DevOpsプラクティスについて常に認識させる役割を果たします。

SREチーム

Googleで採用されているこのトポロジーは、サイト信頼性エンジニアリング（SRE）チームで構成されています。開発者は、ソフトウェアが基準を満たしていることを証明する必要があり、基準を満たさない場合はSREチームがそれを拒否できます。

(SREとOpsチームを比較する)

コンテナ駆動のコラボレーション

コンテナ化は、アプリケーションのデプロイメントとランタイム要件をコンテナにカプセル化するプラクティスです。これにより、DevとOpsチームの間のいくつかのコラボレーション依存関係が取り除かれます。

この構造は、堅牢なエンジニアリング文化を持つ組織に適しています。

(コードとコンテナの管理について学ぶ)

DevとDBAのコラボレーション

複数のアプリケーションが大規模な中央データベースに接続されている組織の中には、このトポロジーを試みたところもあります。この構造は、DBAとDevチームの両方におけるDBA専門職が統合され、両者のギャップを埋めるのに役立ちます。

DevOpsの主な利点

DevOps文化を受け入れる組織は、ソフトウェア提供プロセスの多くの側面で改善を見ています。

チーム間のコミュニケーションとコラボレーションの向上
組織の効率と生産性の向上
ソフトウェアリリースの速度の増加
顧客満足度の最大化（顧客は今、高品質のソフトウェアを受け取ります）
脅威やインシデントの早期検出により、システムの可用性と信頼性を確保
チーム間で異なるアイデアを共有することによるイノベーションの促進

このビデオでは、BMCソフトウェアの製品エンジニアリング担当VP、David Rizzo氏とソリューションアーキテクトのDavid Kennedy氏が、CompuwareがどのようにDevOpsに進化し、イノベーションを高め、エスケープした欠陥を減らし、MTTRを改善したかを共有します。

DevOpsはビジネスモデルを超えて

その抽象的な性質により、DevOpsを数文で定義することは困難です。前述のように、DevOpsは単なるビジネスモデルではなく、ソフトウェア開発と運用プロセスを統合し、自動化して単一の統一されたワークフローにする文化的変革です。これは、高品質なソフトウェアの迅速なリリースに焦点を当て、顧客の要件を満たすことに重点を置いています。

DevOpsは、ソフトウェア開発ライフサイクルの各ステップに定義されたベストプラクティスを統合することによって、その優れた成果を達成します。組織は、DevOpsにおいて最も適したチームのトポロジーを特定し、長期的に努力する必要があります。

正しく受け入れられた場合、DevOps文化は組織にとって成功するソフトウェアリリースのための巨大な利点をもたらすことができます。

ワークフローオーケストレーション

メインフレーム簡素化

人気の目的地

DevOpsとは何か？包括的な紹介