最近よく聞く「DevOps」とは何でしょうか。
この言葉が最初に使われたのは、2009年に Flickr の中の人が「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」発表した資料の中に書かれていたようです。DevOps とは考え方・概念的なことなので説明を聞いた人の立場によって異なり、決まった方法（これをやれば DevOps のメリットが享受）というわけではないようです。
DevOps は、Dev=Developer(開発)と Ops=Operation(運用)を合わせた造語です。
アジャイル開発やスクラム開発、継続的インテグレーション、継続的デリバリー等の方法論の1つとして注目されています。
すべては、「ビジネス(サービス)のために継続的に結果を出す」や「世の中の変化に対し、柔軟にスピーディに対応するための方法」と理解しています。
開発と運用
Flickr の中の人の発表資料によると、大規模に成長した Flickr サービスにおいて1日に10回のリリースが可能であり、そのためにはDevとOpsが協力し開発と運用のプロフェッショナル同士が高い目標を達成していることがわかります。
開発と運用の役割分担を見てみると、
開発
- 要求を実現する開発力
- 顧客の不満を解消するための改修
- 顧客の声に耳を傾け、新機能を追加
- パフォーマンス改善
- 顧客がファンになる機能を開発
等のサービスを自分たちで開発しているという自負と自信があります。 開発がスピード感を持って顧客の声に対応し、求められるサービスを提供しているから成り立っていると考えることができます。
では、運用の役割を見ると
運用
- サービスは24時間の安定稼働、そのための管理
- 安全であり、安定したインフラ
- サービス停止させないための努力
- セキュリティ重視の方針
- 顧客が安心できるサービスレベル
等を実現するために可能な限り計画と安全性を重視した考えになります。また、顧客に対して安心して使えるサービスを24時間提供しているという自負があります。
運用が安全性と安定性を重視して運用しているから、顧客にサービスを提供し続けることができると考えることができます。
開発と運用の対立
顧客に対する最高のサービス、ビジネスを成功させる、という目指している点は同じなのに業務の違いからシステムに対する考えが異なり、開発部門と運用部門は対立してしまいます。
開発は常に新しい機能を追加していきたい、改善していきたいと思いながら運用やインフラのスピード感の遅さにイライラします。運用は常に安定したサービスを提供するために最善を尽くしているが自社の開発部隊は安定したサービスを提供するという意味を分かってくれないと嘆きます。
これは、開発と運用だけに言えることではなく、営業と工場などでも同様です。一例ですが、
営業は自分たちが顧客に売るから売上げが上がりみんなを養うことができる。 顧客の要求に応えるために工場は努力すべきだ。と考え、工場は品質を担保した 良い製品を製造するために計画しているが、営業にかき回されてしまい計画通り に行かない、工場の製品があるから営業は仕事ができるのだろう。と考えます。
よく聞く対立が開発と運用にも存在します。最初に書いた、 「ビジネス(サービス)のために継続的に結果を出す」や「世の中の変化に対し、柔軟にスピーディに対応するための方法」ビジネスの要求を実現するためには、開発部門による変化(新機能の開発とリリース)を受け入れ、運用部門による安定(サービス停止のリスク)のために生まれた概念がDevOpsとなります。
DevOpsはDevとOpsが協力し同じ目的に向かっていくための「行動と習慣」を自社に導入するための「文化とツール(群)」を指します。DevOpsにおいて、多くの開発方法論と同じでツールは重要ではありません。チームの全員がプロフェッショナルとしてお互いに「尊敬と信頼」を持つという文化がとても大切です。
最後に Flickr の中の人によるスライドではDevとOpsが継続的な成果を出すために必要なツール群と文化は簡単にできることではない、とありますが Flickr の例として参考にある点が多いです。
ツール群
- 自動化されたインフラ(Chef, Puppet, AWS, IaaS)
- 共有されたバージョン管理システム
- 1クリック自動ビルドとデプロイ
- A/Bテストや不測の事態におけるオフスイッチ リーンスタートアップに類する実験的な試みが可能な状態。
- サービスの数値、ログ、表を共有
- IRC:チームやすべての工程における議事録やチャットログを共有
文化
- チームが尊敬し合う
- チームが信頼し合う
- トラブルに対する柔軟な対応
- お互いに非難しない