DevOps
DevOps: Why Silos Suck And How To Break Them というエントリをたまたま目にして、「DevOps」という見なれない言葉が出てきたので、気になって調べてみたところ、自分が何となくやっていたことや、今までもやもやと考えていたことに一定の方向性が与えらえた気がしたので、整理してみることにします。
DevOps とは？
簡単に言ってしまうと*「開発者と運用者の間の壁を取り払うためのベストプラクティス」*と言えそうです。
開発者と運用者の間の壁？
Flickr の中の人による 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr という Velocity 2009 でのプレゼンスライドには「Devs versus Ops」という章があり、以下のような言葉が載っていました。
"It's not my machines, it's your code!"
「それは俺のマシンじゃないし、お前のコードだろ」って感じでしょうか。実際、開発者と運用者が明確に分かれている組織では、多かれ少なかれ、また、ニュアンスや詳細は違うでしょうが、こういった言葉が交わされることがあるのではないでしょうか。これは開発者と運用者だけではなく、ウェブ開発者とサーバエンジニア、フロントエンジニアとバックエンドエンジニア、といった形で、明確に役割分担されている組織では起こりうる問題であり、これにより開発がスケジュールから大幅に遅れたり、トラブルがなかなか解決しない、といったような事態を招くこともあるんじゃないかと思います。
また、上記スライドでは以下のような考えを「伝統的な考え」と述べています。
- 開発者の仕事は新しい機能を追加すること
- 運用者の仕事はサイトを速くて安定した状態に保つこと
そして、「運用者の仕事はサイトを速くて安定した状態に保つこと*ではない_'」とし、「ビジネスには変化が必要」であり、'''「安定性をとって変化を捨てる」'''か'_「必要に応じて変化が起こることを許容する」*か、といった選択肢を提示しています。
どうやってその壁を取り除くのか
では、このような開発者と運用者（あるいはウェブ開発者とサーバエンジニアなど、自身の置かれた状況に置き変えてみてください）の壁を取り払うためには、どうすればいいのでしょうか。上で見たように、壁の原因は*「運用者の仕事はサイトを速くて安定した状態に保つこと」 'という伝統的な考えにありそうです。（これは別に運用者が悪い、と言っているわけではありません。）そして、提示された選択肢のうちの後者' 「必要に応じて変化が起こることを許容する」*ことが容易に実現できるようにすることが大事なのではないかと考えられます。これを実現するために重要なことは、
- ツール
- 文化
の2つに分けることができそうです。
ツール
「10+ Deploys Per Day: Dev and Ops Cooperation at Flick」では、ツールとして以下のようなものをあげています。
- インフラの自動化
- 共有されたバージョンコントロール
- ワンステップビルド＆デプロイ
- 機能フラグ
- メトリックの共有
- IRC and IM robots
ひとつひとつの解説は省略しますが、いずれも状態やその変化を記録、可視化し、変更しやすい、あるいは変更をコントロールしやすい環境をつくるためのツール、と言えそうです。
文化
また、文化としては以下のような項目を挙げています。
- 尊敬
- 信頼
- 失敗を許容する
- 責めない
まあこれは、人と協調して仕事をスムーズに進めるためにはどれも重要なことですよね。
以上が DevOps について、自分なりに得たことのまとめです。ツールについては、自分がペパボに入社してから導入や利用促進してきたもの、これから導入したいと思っているものなんかが、軒並み上のリストに含まれていて、DevOps の概念が頭にあったわけではないんですが、思いがけずそういう方向に行こうとしていたんだな、ということがこの言葉に出会うことによって確認できました。（それでエントリのタイトルがあんな感じになってます。）
DevOps 自体まだ定義として固まっているものではないようですし、かなり端折った形でまとめましたので、興味がある方は自分が参考にした以下のURLや、更にそこからのリンクを辿ってみてください。