1. DevOpsって何？(株)paperboy&co.宮下 剛輔2010/5/19

2. 自己紹介宮下 剛輔mizzy, id:MIZZY, gosukenator(twitter, gmail)http://mizzy.org/ペパボで技術責任者というのをやってますインフラからウェブ開発まで幅広くPerl界隈での活動が多いです（最近それほどでもないですが）Puppetについてgihyo.jpで連載したり、SoftwareDesign誌で記事書いたりしました

3. 自己紹介子だくさん4人子供がいます最近の趣味天体撮影二十数年ぶりに再開。当時と勝手が違うので手探り状態MGSPWあまりやれてないですが

4. お話させていただくことになった経緯

5. DevOps概要最近（2010年3月ぐらい）DevOpsという言葉をみつけ、それが自分の社内活動の背後にある考えを言語化するのにちょうど良いものである、ということに気づいたので、自分の考えや今後の方向性を整理するために、詳しく調べて見ることにしたというわけで、自分なりに咀嚼してみたDevOpsについてお話させていただきますといっても、明確な定義があるわけではないため、基本的にはDevOpsムーブメントの大本と思われる、Velocity 2009でのFlickrのJohn Allspaw氏によるプレゼン「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」をベースとしてお話します（あくまでもベースなので、他の資料も参照していたり、自分の考えなんかも盛り込んでいます。）

6. DevOPSとは？

7. DevOpsとは？

8. DevOpsとは？DevOpsは、従来型のシステム管理や調達（ITILを含む）といった、保守的でプロセスを中心に据えた運用からより戦略的でアジャイルな、そして自動化されたアプローチへの転換を表現した言葉である。 http://builder.japan.zdnet.com/news/story/0,3800079086,20411692,00.htm より

9. DevOpsとは？Dev= Development, Ops = Operations定まった定義、解釈があるわけではないけど、狭義には「開発者と運用者の壁をなくしてビジネスを円滑に進めるためのプラクティス」と自分は解釈してるVelocity 2009での「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」というプレゼンが発端？広義には開発者、運用者だけではなく、ヘルプデスク/顧客サポートやマネージャなども含むAgile OperationsやAgileInfrastructureが似たような概念

10. 開発者と運用者の壁It's not my machines, it's your code!/It’s not my code, it’s your machines!開発者と運用者に限らず、異なる役割を持つ職種の人たちの間で、詳細やニュアンスは違えど、多かれ少なかれ、こんな言葉が交わされることがあるのではないでしょうか

11. 壁ができる要因方向性の違い守備範囲の違い

12. 方向性の違い開発者の仕事は新しい機能を追加すること運用者の仕事はサイトを速くて安定した状態に保つことこういった方向性の違いで壁ができるのでは

13. 方向性の違いをどう解消するか「運用者の仕事はサイトを速くて安定した状態に保つこと」という考えは間違い開発者も運用者も、ビジネスを円滑に進めることが役割（開発者、運用者だけに限らないけど）ビジネス要件は常に変化する「速くて安定」に固執すると、変化を受け入れにくくなる要件に合わせて変化することを容易にし、変化によるリスクを低減することが重要

14. 守備範囲の違い開発者は開発したアプリケーションが守備範囲運用者はOS、ネットワーク、ミドルウェアといったあたりが守備範囲

15. 守備範囲の違い【名】Siloサイロ、〔家畜飼料・穀物などの〕貯蔵庫、地下ミサイル格納庫窓がないサイロの中にいるように周囲を見ない仕事のやり方、自己中心的なスタイル

16. 守備範囲の違いをどう解消するか実際には、厳密に境界線が引けるものではない、ということを認識する双方からのアプローチが必要な場合が往々にしてある、ということを認識する例）パフォーマンスチューニングではアプリケーションの観点、ハードウェア、OS、ネットワークリソースの観点、双方が必要Siloisationの排除が重要

17. ここまでのまとめDevOpsは開発者と運用者の壁をなくすためのプラクティスDevとOpsの壁仕事の方向性の違い仕事の守備範囲の違いDevOpsに重要なこと変化を容易にし変化によるリスクを低減するSiloisationの排除

18. DevOpsの実践

19. どのようにDevOpsを実践するのか？DevOpsに重要なこと変化を容易にし変化によるリスクを低減するSiloisationの排除具体的には何が必要か？ツール（＋スキル）文化

20. DevとOpsが関わる領域プロビジョニングインフラの立ち上げインフラ設定アプリケーションデプロイメントモニタリングシステム監視metrics（数的指標）の収集/可視化

21. プロビジョニングインフラの立ち上げOSインストールAMIやVMイメージの起動インフラの設定OSネットワークミドルウェア設定済みのAMI、VMイメージアプリケーションデプロイメント

22. OpenSourceProvisioning ToolchainToolchain ＝ 何らかの目的を達成するためのソフトウェアの集まりOpenSource Provisioning Toolchain＝プロビジョニングを行うためのオープンソースソフトウェアの集まり以下の3つの領域Bootstrapping ConfigurationOrchestration

23. OpenSourceProvisioning ToolchainBootstrappingAWS, Cobbler, Eucalyptus, Jumpstart, Kickstart, OpenNebula, OpenQRM, VMWareConfigurationBCFG, Cfengine, Chef, Puppet, SmartFrogOrchestrationCapistrano, ControlTier, Fabric, Func

24. いったん整理DevOpsの実践ツールOpen Source Provisioning Toolchain文化DevとOpsが絡む領域プロビジョニングインフラの立ち上げインフラの設定アプリケーションデプロイメントモニタリング

25. ツールがなぜDevOpsにつながるのか自動化変化を容易にする専門的なスキルを持たなくても実施できるSiloisationの排除変化を正しく行う（リスクを低減）

26. 自動化による変化の容易性とリスクの低減の例テスト環境を本番と同じ環境にし、同じ変化を発生させ、十分にテストができれば、変化も怖くない同じことを楽に確実に行うためのツールによる自動化テストの自動化も安心感を得るためにはとても大事テストの自動化もDevOpsの文脈で語ることができる

27. ツールがなぜDevOpsにつながるのか構成管理（履歴管理）誰がどのような変化を行ったか記録し、変化を可視化する間違った変化をロールバック構成管理は各ツール自身が持っていなくても、テキストベースで設定できるものであれば、Subversionなどの構成管理ツールが利用できる

28. 構成管理による変化の容易性とリスクの低減の例失敗してもすぐに戻せるとわかっていれば変化も怖くない変化が起きた時に、誰がどんな意図でその変化を起こしたのかがすぐにわかれば、問題発生した際の原因特定が容易適切なコミットメッセージを残すことも大切ただし間違いを起こした人を責めてはいけない（後述する文化的な話）

29. （＋スキル）の意味適切なツールを選択し、正しく使いこなすスキル専門的な知識を持たなくても利用できるようにカスタマイズするスキル必要なツールがなければ自分でつくれるスキルDevとOpsが互いにオーバーラップするスキルを持つこともSiloisation排除に有効

30. いったん整理DevOpsの実践ツール自動化と構成管理文化DevとOpsが絡む領域プロビジョニングインフラの立ち上げインフラの設定アプリケーションデプロイメントモニタリング

31. モニタリングシステム監視稼働監視、リソース監視、アプリケーション監視metricsの収集、可視化キャパシティプランニングなど具体的なツールについては省略主にSiloisationにフォーカスします

32. モニタリングは誰が行う？Opsだけの仕事になってることが多い？Siloisationに陥りやすい領域？Devの関わりもとても重要稼働監視において、pingやHTTPレベルの監視では気づけない異常もあるリソース監視においてCPUやメモリの情報を監視しても、アプリケーション側の動きと結びつけられないと原因の調査は難しいアプリケーション側の視点から得られるものも多いのでは？情報共有はとても大事

33. モニタリングはDevもOpsもやるべき監視項目をDevとOpsでレビューするOpsがアプリケーション動作の監視ができるよう、Devがアプリの仕様をまとめるOpsがカスタム監視スクリプトを開発するスキルを持つDevはそのサポートを行う逆にDevが監視スクリプトを書くOpsはそのサポートを行う

34. ここまでのまとめDevとOpsが関わりあう領域プロビジョニングとモニタリング変化を容易にし、リスクを低減ツールによる自動化と構成管理Silosationの排除互いの領域に踏み込む互いにオーバーラップしたスキルを持つ互いのスキルを補い合う

35. その他にも重要なことSiloisationの排除には情報共有も大切Wiki, IM, IRCIRC bot でコミットメッセージ、デプロイ情報、アラートなんかを流す構成管理ツールも情報共有の一貫DevとOpsだけにとらわれないヘルプデスク/サポート、マネージャーなど、同じ考えが適用できるはず先に挙げたツール以外にも重要なものユニットテストとか

36. 文化DevOpsには文化も重要尊敬信頼失敗とうまくつきあう責めない

37. 尊敬開発者が怠け者だというステレオタイプを捨てるお互いのスキル、意見、経験等に敬意を払う「ノー」とだけ言わない隠し事をしないDevはOpsに対してコードのインパクトを説明する数値指標がどのように変わるか？それはなぜか？リスクは何か？問題の早期発見には何を見ればいいのか？もちろん事前の洗い出しが必要

38. 信頼Opsは将来の展望についてDevを信頼するDevインフラの変更について議論する時にOpsを信頼するお互いがビジネスのためにベストを尽くしていると信頼する情報をシェアするOpsはDevを信頼してシステムへのアクセスを許可すべき

39. 失敗とうまくつきあう失敗は常に起こりうる失敗はしないと思いこんでいると、何かあった時に対応できない失敗に常に備えておく

40. 責めない指をささない誰かを責めてる暇があるなら、復旧に労力を使えDev: まずいコードを書くとOpsが叩き起こされるということを肝に銘じるOps: 現在問題になっていることについて、建設的なフィードバックをDevに提供する

41. まとめDevOpsとはDevとOpsの壁を取り払うためのプラクティスツールと文化によって変化を容易にし、変化によるリスクを低減し、Silosationを排除するツール自動化と構成管理文化尊敬信頼失敗とうまくつきあう責めない

42. 参考リンク10+ Deploys Per Day: Dev and Ops Cooperation at Flickrhttp://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickrDevOps: Why Silos Suck And How To Break Themhttp://www.agileweboperations.com/devops-why-silos-suck-and-how-to-break-them/What Is This Devops Thing, Anyway?http://www.jedi.be/blog/2010/02/12/what-is-this-devops-thing-anyway/Provisioning Toolchainhttp://en.oreilly.com/velocity-mar2010/public/schedule/detail/14180

43. おしまい