セルフサービスオペレーションとは何か - Damon Edwards氏がDevOps Enterprise Summitで講演

間もなく開催されるDevOps Enterprise Summit in Londonを前に、InfoQはRundeck共同創業者のDamon Edwards氏と席を共にして、“セルフサービスオペレーション”のメリットと実践について議論を交わした。

インタビューの全記録を以下に紹介する。また、Damon Edwards、John Wills両氏による講演“Better, Faster, Cheaper: What Does it Mean for Ops?”に関する詳細が、DevOps Enterprise Summit (DOES) LondonのWebサイトで公開されている。

InfoQ: InfoQへようこそ、Damonさん！London 17で行う予定の講演について、内容を簡単に説明して頂けますか。セッションの参加者は、どのようなことを期待できるのでしょう？

Damon Edwards: John Willsと私は昨年、“Better, Faster, Cheaper, How?”と題して、ハイパフォーマンスな企業が敏速な行動、高品質、低コストの実現に用いているテクニックについて講演しました。これは非常に好評で、DevOps.comから、その年のDevOpsに関する最高のプレゼンテーションにも選出されています。

ですから今年は当然、そのフォローアップをしなければなりません。今年はさらに踏み込んで、こうしたテクニックがオペレーションを変革する様子を見ていきたいと思っています。Johnはインフラストラクチャの変革、特にコンテナ化と不変(immutable)インフラストラクチャのデザインパターンの革新的影響について議論する予定です。私は運用組織の変革と働き方、組織構造のあり方について論じたいと思っています。中でも特に、“セルフサービスオペレーション”という、興味深いデザインパターンに注目するつもりです。

InfoQ: あなたの経験から、既存の企業内管理ないし運用担当チームが“セルフサービスオペレーション”に移行するために必要な、最も大きな変化は何だと思いますか？

Edwards: セルフサービスオペレーションは、一見かなり基本的なものに思えます - 運用タスクを選択して、自動化されたボタンやAPIとして提供すればよいのですから。しかし詳しく調べれば、もっと奥の深いものであることが分かるでしょう。セルフサービスオペレーションは、手順の自動化に対する考え方を根本から変えるものなのです。

自動化手順で重要な点は３つあります - 自動化手順の定義、それを実行する能力、それを管理するセキュリティおよび管理ポリシのコントロールです。従来は、これらのパートは分離不可能な形でオペレーションの範疇に(多くの場合、同じチーム内に)あるものと考えられていました。セルフサービスオペレーションでは、これら重要な部分を分割し、組織内のそれぞれの領域に移行することによって、労働力の最大限の活用、および組織の最大限のアジャイル化を実現します。

例えば従来型の組織において、開発者チームが定義した運用手順を運用担当者が検証し、その開発者チームあるいは他のチームにそれを実施する能力を提供する、という手順を提案すれば、かなり異端だと受け取られるでしょう。セルフサービスオペレーションはそれに挑戦するのです。

InfoQ: セルフサービスオペレーションへの移行前と移行中には、どのようなメトリックないしKPIを追跡するべきでしょうか？成功を判断する上で‘最も重要な指標’は何でしょう？

Edwards: “最も重要な指標”が必要ならば、従来のDevOpsメトリックであるリードタイムを使用するとよいでしょう。コンテキスト提供のリードタイムや、インシデント解決のリードタイムといったものです。リードタイムはビジネスにとって重要ですから、何よりも重視するべきです。

しかしながら、セルフサービスオペレーションによるROIのメリットは、組織のどの部分にいるかによって異なります。運用サポートチームにとってのROIメリットとしては、インシデント対応時間の短縮、エラーや再作業の削減、チームが実施可能な総サポート量の増加、エスカレーションからの応答待ち時間の減少、そして、他のチームに依頼可能な運用サポートタスクの増加などが挙げられます。

運用サポートチーム以外のチームに対するROIメリットには、エスカレーション数の減少、運用タスクの完了待ち時間の削減、不正あるいは問題のある業務移譲に起因する割り込みの削減などがあります。また、組織レベルのROIメリットとしては、サポートコスト全体の削減、市場投入時間の短縮、組織としての能力向上などが指摘できます。

InfoQ: Rundeckのようなセルフサービスプラットフォームは、Jenkinsやcronような既存ツールを使ってサービスやジョブを起動している運用チームにとって、どのようなものを提供してくれるものなのでしょう？

Edwards: Jenkinとcronとでは方向性がまったく違いますから，この２つは別々に考える必要があります。

まず，JenkinsとRundeskはうまく連携します。実際にJenkinsは，Rundeskで最も多い統合ソフトのひとつです。Jenkinsは基本的に，開発者とビルドエンジニア向けに設計されたビルドツールです。Rundeskは運用担当者のためのオーケストレーションとスケジューリング用のツールとして，ゼロから開発されています。例えば，RundeskがインフラストラクチャやACLポリシ，出力フォーマット，スケジュール機能を知る方法は，すべて企業のオペレーションのニーズを念頭に設計されているのです。

Cronは個々のサーバ上で動作する，シンプルなスケジューリングユーティリティです。Rundeckは単純な集中型スケジューラとしても使えますが，スケジューリングのニーズとしてはワークフローやエラー処理，通知，アクセス管理，負荷管理などが含まれることの方が多いでしょう。これは一般に，コミュニティで“エンタープライズ・ジョブスケジューリング”あるいは“エンタープライズ・ワークロードオートメーション”と考えられているものです。Cronのようなローカルスケジューラを統合するためにRundeckを使っている事例もよく耳にしますが、それよりもControl-MやAutosys、Tidal、UC4といった、従来型のエンタープライズ・ジョブスケジューラの代替として使用する事例の方がやはり一般的ですね。

InfoQ: 要するに、より速く行動することを望む企業組織にとって、DevOpsはどの程度の関連性を持っているのでしょう？あなたの経験から、一般的なエンタープライズにおいて重要なのは、組織的な変革と技術的な変革のどちらのニーズだと思われますか？

Edwards: DevOpsは非常に重要です。企業システムは複雑なので、万能の解決策というものは存在しません。さまざまなテクニックを駆使して、ひとつずつ変えていくしかないのです。DevOpsコミュニティが素晴らしいのは、現場で実際にテストされたテクニックがたくさんあるからです。コミュニティが実証済みのレッスンを受け、それを自分自身の企業に当てはめればよいのです。

もっと正式な定義が必要ならば、The Phoenix Projectとその手引書であるThe DevOps Handbookを勧めない訳にはいきません。組織的な変革と技術的な変革の対比という点に関しては、この２つは密接に関連してはいますが、最終的な成功と失敗を本当の意味で区別しているのは、常に組織的な変革の方です。ここで組織的な変革と言っているのは、ビジネスに価値を提供するために行なう必要のある作業を人々がどのように見て、どのように組織化し、どのように実践するか、ということです。

ツールは行動を変えるのに役立ちますが、最終的に組織の変革に影響を与えることができなければ、以前と同じ問題を新たなツールで再度発生させることにしかなりません。組織の変革に焦点を絞れば、ツールは大した問題ではなくなります。ツールを中心に据えてしまうと、組織の問題を相手とする苦しい戦いを強いられることになるでしょう。

InfoQ: 今日はありがとうございました。InfoQの読者に何か話しておきたいことはありますか？

Edwards: インタビューしてくれてありがとう。ひとつだけ加えたいのは，もしあなたが企業で技術的リーダの役割を - チームリーダであれ，シニアエグゼクティブであれ - 担っているのならば，DevOps Enterprise Summitカンファレンスは大いに役に立つと思います。このカンファレンスはサンフランシスコとロンドンで，毎年開催されています。世界中の大企業の仲間と直接対話して，DevOpsに関する問題の特定や解決についてオープンかつ率直に話し合うことのできる，とても素晴らしいチャンスです。

ただし，私の言うことをただ信じるだけではありません。講演者や参加者のレベルに疑問があれば，過去のビデオを見てください。

DevOps Enterprise Summit Londonカンファレンスは6月5日と6日、QE II Conference Centreで開催される。詳細はIT Revolution EventsのWebサイトを見てほしい。