“DevOps”という包括的な用語はこの数年でずいぶん成長し、だれにとっても同じ意味を指すようになりました。これは、用語の意味の側の問題というよりも、ソフトウェア デリバリーの自動化の範囲が広がったことが用語に反映されたからなのだと言えます。この成長を支えているのは、現在のソフトウェア デリバリー方法を可能にするツールや手法を管理している運用担当者です。運用担当者の役割は、非常に大きく変化、拡大しています。CircleCI がオンプレミス環境に対応した直近 2 年間でさえもです。運用担当者の業務は多岐にわたっており、開発者が日常的に使用するツール チェーンの管理から、セキュリティ、コスト管理、コンプライアンスについての経営陣の質問に対する回答まで担っています。さらに、目に見えないところでは、回避できない技術的な非難で追い詰められたり、デジタル トランスフォーメーションを実現したいという経営陣からの圧力の高まりに直面していたりするのです。

CircleCI に所属していると、ラッキーなことに、世界中の何千ものチームのパターン、手法、ツールの変化を最前列で見ることができます。このような変化があるからこそ、運用担当者と DevOps 実践者はイノベーションを続け、すばやく対応し、反復可能なプロセスを策定して、優位性を保ち、大惨事を避けることができるのです。

ソフトウェア イノベーションの先頭を走る CircleCI のお客様を調査して判明した、6 つのパターンを以下にご紹介します。

1. プロセスの最優先化: 優秀なチームは常に、ソフトウェア デリバリー パイプラインの標準化と自動化をできる限り進めています。今では、ソフトウェアが戦略的投資の対象であることは、だれもが認めるところです。しかし、そうした投資を進める組織において、ほとんどの開発者は、コード自体を負債 (良くて、すぐに価値が下がる資産) と見なしています。価値の高い資産とは、企業でコードを実際のソフトウェアに変換するために生み出される、反復可能かつスケーリング可能なプロセスです。こうしたプロセスであれば、ソフトウェア デリバリー パイプラインのスループットと品質を高めることができるからです。このようなプロセスでは、有効なソフトウェアのデリバリー、運用効率の管理、新規プロジェクトのコスト効率のよいスピンアップが自動化されています。

2. パイプラインの分散化: トレンドの中心は、一元的なパイプラインから、エッジの権限強化に移り変わっています。企業は開発者に自身のパイプライン ロジックを制御する権限を与えようと努めており、パイプラインを実行するためのリソースを自動的にプロビジョニングして開発者に提供しています。業界をリードする企業では、プロビジョニングが 1 回限りであり個別のセキュリティ管理が必要なスタンドアロンのビルド システムは、保持が許容されなくなっています。運用担当者は自身をボトルネックと見なし、取り除こうと努めています。これに応じ、チームでは、一元的に運用可能でありながら、チームそれぞれにセルフプロビジョニングや自動スケーリングの権限が分散的に付与されるシステムへの移行が進んでいます。

3. 抽象化の多用: DevOps の厄介な問題の多くについて、抽象化がますます進められています。従来、環境の仮想化、インフラストラクチャのオーケストレーション、複雑な一連の処理のスケジュール実行など、一般的な課題に対処するには、手作業による介入や壊れやすいスクリプトが必要でした。現在では、そのような課題をモデル化して確実に自動化できる、Docker、Kubernetes、Terraform といった多数のツールがあります。優秀な IT チームは常に、難解なリスクが表面化する領域を小さくしようとしています。そのため、こうしたチームでは、一般的な課題への対処方法として、特注システムの作成、保守、刷新ではなく、業界標準となっているかベンダーの支持が厚い抽象化が選ばれているのです。パフォーマンスに優れたソフトウェア企業は、同業他社に共通の課題であるシステムのサポートではなく、独自価値の創造にできる限り多くのエネルギーを注いでいます。このような企業は、テキストファイルを記述することで(また独自の構文ではなく一般的な構文で)ツールを利用可能なオープンスタンダードを好んで採用しています。

4. コンプライアンスの継続化: ソフトウェア デリバリー パイプラインの自動化が進展すると、同じ速度感でコンプライアンスを順守しつづけるための労力も増加します。戦略的資産としてソフトウェア デリバリーのスループットに投資している企業は、その投資がビジネス プロセスのボトルネックのせいで阻まれることを望みません。運用担当者は、職務分掌、慎重なセキュリティ キー管理、高可用性、障害対策などの強力な措置を講じて、さまざまな利害関係者を安心させようとしています。中核的な運用モデルに、チームのスループットを損なうことなくそのような気遣いが組み込まれたシステムは成功します。運用担当者にとって最も貴重な資産である、システムの安定性と説明責任が保障されるからです。

5. 自動化の自動化: モノリシック アーキテクチャ離れの傾向によって、運用担当者がサポートしなければならないアクティブなソフトウェア プロジェクトの数が増えています。一方、モノリスを保守する運用担当者でも、サポート対象に他の補助的なシステムが増えつつあります。このように複雑さが爆発的に増加すると、管理と運用のオーバーヘッドによる苦境を回避するために新しい抽象化が必要になります。リポジトリのスピンアップ、さまざまな共通の依存関係の挿入、CI スクリプトの生成、各種インテグレーション ポイントの登録など、それまで手動で行われていたタスクが、スクリプトやツールにより行われるケースが増えています。新しい構想の作成や、既存の構想の維持にかかる負担を軽減することで、チームのソフトウェア イノベーションのスループットに大きな改善が見られるようになります。DevOps 手法ならではの再現性は、チームの成功の大きなカギになります。

6. 可用性と復旧: 本番環境に見合う品質のサービス レベルを備えたシステムとして CI/CD システムを扱う企業が増えています。そのような企業は、適切な DevOps 手法では、実質的にソフトウェア デリバリー パイプラインが本番環境システムになると知っています。なので、システムを結合して単一障害点をすべて取り除こうとしているのです。自動バックアップと復旧、グローバルにフェデレーションされたインフラストラクチャ、ピーク時の需要に応えるスムーズなスケーリングが求められています。そのため、急激なスケーリングに対する懸念と、高い耐久性と復旧性を求める全社的な目標の両面から、投資が進んでいます。

ソフトウェア チームに対する要望は、今後も伸び続けるでしょう。そうしたチームが利用するシステムを管理する運用担当者には、自動化の増加とそれに伴うオーバーヘッドへの対処、チームのアジリティと自主性の向上を可能にするイノベーションの推進、システムのセキュリティ確保とコンプライアンス徹底などの課題が待ち受けており、これらに上手に対処することが期待されます。