初期の話になりますが、私たちがかつて、最初のdevopsdaysイベントをヨーロッパで開催した時、コミュニティの一角は運用をおもなバックグラウンドとして持つ人たちが占めていて、ダウンタイムの削減やデプロイメントの短期化、プラットフォーム安定性の改善など、彼らの業務を改善する方法が語られていました。
今回紹介するのは、過去10年間のDevOpsの進化を取り上げた、成功と問題点を含む短い物語(本当の戦争物語を含む)です。
イノベータによるDevとOpsのコラボレーションの採用
2009年頃、私たちの多くは、開発チームが投げ捨てるように渡した使い物にならないアーティファクトを、運用担当者がなんとかしてくれることを期待する、という状況にありました。バージョン管理にコミットした後のことは気にも留めない開発者たちの後始末に疲れ果てていたのです。
それと同時に、学校で教えてくれるようなマニュアル操作は、もはや私たちのニーズに合うようにスケールアップできなくなっていました。仮想化によって企業は、数台の物理サーバを所有する状況から、数百の仮想マシンを管理する状況へと移り変わりました。この初期のdevopsdaysで議論されたのは、インフラストラクチャ・アズ・コード、ビルドの自動化、管理やメトリックスの改善や、アジャイルやオープンソース、クラウドのパワーをいかに活用するか、といった話題でした。
その一方で、コミュニティの別の部分は、開発の迅速化という目標の上で、管理部門をボトルネックとして見る開発者たちによって占められていました。彼らが必要としたのは、よりよいプラットフォームであり、レスポンスタイムの高速化であり、スケーラビリティの向上だったのです。
どちらのグループも、目指すべき道がコラボレーションであることは認識していました。開発者は、自分たちのニーズを運用担当者たちと事前に打ち合わせなければ、必要とするプラットフォームを手にすることはできません。同じように運用側も、自分たちの要求を開発者たちと事前に打ち合わせなければ、実稼働時の運用が容易なアーティファクトを得ることはできないのです。そのためにサイロは破壊され、橋が築かれました。組織全体からさまざまなスキルを持った人たちが集まり、クロスファンクショナルなチームとして作業するようになったのです。すべての人たちに対するソフトウェアデリバリがより継続的に、よりスムーズになりました。DevOpsが実現したのです。
仕事のやり方を変えたアーリーアダプタたち
これら初期のdevops実践者の成功を目の当たりにした人たちは、自分たちも同じように作業できないか、もっと速いデリバリができないか、もっと安定したプラットフォームを構築できないか、と考え始めました。
ここに最初の"DevOps変革"が始まりました。大企業が、自分たちもあの"クール"な連中のようになりたい、と思うようになったのです。アジリティとデリバリのスピードが自分たちのビジネスラインにおける重大事である、と考える企業もあれば、すでに"devopsを実践"している格好いい連中をとにかく雇いたい、と思う企業もありました。
改革の必要性を認識したこれらの大企業が、最初の第一歩を踏み出したのです。しかし、変化することは難しく、"DevOps変革"に成功したという主張の多くは、実際には期待に応えるものではありませんでした。現場のチームの仕事の方法は、基本的に何も変わらなかったのです。
企業にはそれぞれ独自の課題があり、独自の歴史があります。ですから、幸福に向かうために必要な道程も、それぞれ違うものになります。しかしながら、私がいつも驚かされるのは、変革を望む多くの企業が — 今になってもなお — 運用担当者をその変革プランに組み入れていないことです。運用担当者を議論から取り残したままで、どうして"DevOpsを実践"できるのでしょう？ DevOpsの"Ops"はどこに行ってしまったのでしょうか？
企業を"よりDevOps"にするために私が最初に行った仕事は、150人規模のSaaSプラットフォーム企業の支援でした。その会社は当時、サービスへの機能のデプロイとスタックの運用に大きな問題を抱えていました。あまりに急成長したために、インフラストラクチャとデプロイメントのコントロールを失っていたのです。皆がお互いを責め合うという、カオスな状態でした。そこで最初に行ったのは、運用担当者たちにインフラストラクチャ・アズ・コードと継続的デリバリについて教えることでした。プロセスの後半になれば、ビジネスアプリケーションの継続的デリバリを達成するために、運用チームが開発チームのサポートを行う任を負わなければいけないと分かっていたからです。
運用担当者がCI/CDの基本を理解して、開発者と同じツールを使い始めたことによって、共通の認識が生まれました。デリバリに必要なもの、すなわち、アーティファクトはどうあるべきか、デプロイメントにはどのようなステージが関わるのか、開発者のツーリング選択がどのように役立つのか、といったことを、運用側がより深く理解できるようになったのです。開発側と運用側とのギャップは埋まったか、あるいは少なくとも狭くはなりました。同じことばを話し、同じツールを使うことで、(よりよい)コラボレーションと理解の文化への大きな一歩を踏み出したのです。
制約を明らかにしたアーリーマジョリティ
私が経験した次の大規模な案件では、運用担当者は参加していませんでした。この企業では、開発者の観点から見た運用の意味さえ明確ではありませんでした。ある人がコードを書くと、別の人がビジネス的な視点から(カタログに新製品として加える、というように)、そのアプリケーションを"運用"していたのです。この2つのスキルセットをひとつのチームにすることが、彼らの言うDevOpsでした。ですが、高度に技術的な運用面での責務を負う人は誰もいないままだったのです。技術的な観点から運用担当者として認められるエンジニアを最終的に見つけ出すまでに、1年半を要しました。
運用知識の豊富なこの人物は、運用環境のトラブル対応で"あまりにも多忙"だったため、DevOps転換に関する作業に加わっていなかったのです。彼はぉなじグループに所属していましたが、別の建物で違う法人向けの仕事をしていました。モチベーションを失っていて、会社を辞める寸前でした。その企業はそんな状況でも、"DevOps"を実践している、と主張していたのです。
このケースで私たちの選択した行動は、作業フローで事実上のボトルネックになっていた多くのエキスパートたちをラインから外す、ということでした("The Phenix Project"の読者ならば、ここで"Brent"特性を連想することでしょう)。彼らには、インフラストラクチャ・アズ・コードで必要な新たなコンポーネントを、スクラムアプローチで開発する作業を依頼しました。通常業務の同僚に邪魔されないようにするため、彼らを別の都市に移動させることまで行いました。数ヶ月後、彼らは以前のチームに再度合流したのですが、その時にはまったく新しい仕事のやり方を身に付けていたのです。最年長のUnixシステム管理者でさも、運用システムを手作業でホットフィックスする方法ではなく、インフラストラクチャ・アズ・コードを説くアジャイルエバンジェリストになっていました。
ツールを過度に重視したレイトマジョリティ
私が最近コーチングに参加した案件は、大規模な金融機関を対象としたものでした。DevOps変革のヘルスチェックを行うために参画した私が最初に聞いたのは、運用担当者との対話が許されていないという、多数のDevOpsコーチたちの声でした。運用は別会社に任されていて、その会社がDevOpsへの転換に関与していないためだ、と言うのです。
そこで上部管理職と掛け合ったのですが、他国にある本部が決定したことなので覆すことはできない、お手上げ状態だ、という返答でした。苦肉の策として彼らが中央に設置した"DevOpsチーム"は、運用の経験も開発の経験もなく、実稼働環境へのアクセスもできないものでした。この新チームが企業全体を対象とした継続的デリバリパイプラインを構築し、開発チームがテスト環境まですべてをデプロイできるようにした上で、運用担当者にそれを引き継ぎ、すべて手動で運用環境にデプロイする、という計画でした。
このアプローチの成果は、誰も利用することのないツーリングスタックでした。開発者のニーズに合わなかったのです。加えて、サービスをデプロイするために、開発者が手作業でチケットを作成して運用担当者にデプロイを依頼しなければならない、という状況はそのままでした。多くの人たちが職を離れる決意をしました。その中には、この体制下では真のDevOps変革を実現できないということを理解していた、先程の上部管理職も含まれていました。
この(あるいは他の)変革のケースで学んだのは、ツーリングの導入だけでは成果を上げられない、ということと、すべての人たちがプロセスに参加する必要がある、ということです。運用担当者(Ops)を変革に取り込まなければ、DevとOpsのギャップを埋めることは叶わず、時間の浪費と熱意の喪失が起きるだけなのです。
"私のツールでは動作する、後は運用の問題だ"
DevOps導入に関わる問題は、組織的なものばかりとは限りません。ツーリングに問題があることも少なくないのです。すべてのツールが役に立つとは限りません。
これまで私は、Xというツールを使用しているから自分たちはDevOpsを実践しているのだ、と主張する企業を多く見てきました。ですが、詳細に調べると、そのXというツールは開発者を支援するだけで、結果的に運用面での複雑性を隠蔽してしまうことが少なくないのです。Xツールを管理する方法についての議論から取り残されがちな社内運用チームは、ここでもフラストレーションを募らせることになります。 そして再び"Dev(開発)対Ops(運用)"の構図に陥ってしまい、開発チーム(と管理者層)は運用担当者が障害になっている、と主張するようになります。彼らにとってXツールは簡単に使えるものかも知れませんが、監視やセキュリティ、バックアップ、スケーリング、メトリックス、ネットワークなど、運用チームが対処する必要のある非機能要件がまったく考慮されていないのです。
残念なことに、この悲惨なパターンにマッチするツールの数は増えています。過去10年間のDevOpsの中で、状況は"私のマシンでは動作する、後は運用の問題だ"から、"私のツールでは動作する、後は運用の問題だ"に変わりました。これでは、DevOpsというよりもDev-oopsです。を"クラウドネイティブ"と呼んでいる人もいます。
運用担当者に開発者と同じツールセットを与えて、同じパターンを使用するようにすれば、共通の言語を持つことができて、よりよい相互理解ができるようになります。ツールの適切な使用は、組織内のコラボレーションを改善するための豊潤な基盤となるのです。ただし、ツールの選択が別々に行われて、それぞれのチームが別々に運用するようなことになれば、チーム間のギャップはさらに広がってしまうかも知れません。
結論
進歩はしているものの、多くの企業においてDevOpsはいまだ初期段階にあります。開発品質の向上、トランクベース開発などのコアプラクティス導入、テストシナリオなど、いずれにおいてもそうです。
開発と運用のコラボレーション、異なるスキルセットの組み合わせよる短期かつ安全なデリバリと運用の実現、といったDevOpsの基本的根拠は、多くの企業においていまだ無視されることが少なくありません。
すべての人々が参加すべきだと言われて10年が経ちましたから、DevOps変革にはDevだけではない、Opsもその議論とロードマップに含まれるのだ、と誰もが思うでしょう。残念なことに、それはまだ事実ではありません。
次の10年で、この問題が正されることを切に願っています！
著者について
Kris Buytaert氏はLinuxおよびオープンソースのコンサルタントを長く続けています。DevOps運動の火付け役のひとりで、現在はInuitsで業務を行っています。国際的なカンファレンスの講演や運営に数多く携わっており、この分野に関するさまざまな書籍、論文、記事を著しています。氏は高可用性やスケーラビリティ、仮想化、大規模インフラストラクチャ管理プロジェクトを特に重視した、開発者と運用担当者のギャップの橋渡しに多くの時間を費やす一方で、10階テスト(10th floor test)に耐え得るインフラストラクチャ — 現代的に言えばクラウド — の構築を試みつつ、DevOpsの考え方を積極的に広めようとしています！"Everything is a Freaking DNS Problem"と題された氏のブログがこちらにあります。