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 Toolchain Toolchain ＝ 何らかの目的を達成するためのソフトウェアの集まり OpenSource Provisioning Toolchain＝プロビジョニングを行うためのオープンソースソフトウェアの集まり 以下の3つの領域 Bootstrapping Configuration Orchestration

23. OpenSourceProvisioning Toolchain Bootstrapping AWS, Cobbler, Eucalyptus, Jumpstart, Kickstart, OpenNebula, OpenQRM, VMWare Configuration BCFG, Cfengine, Chef, Puppet, SmartFrog Orchestration Capistrano, 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, IRC IRC 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 Flickr http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr DevOps: Why Silos Suck And How To Break Them http://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 Toolchain http://en.oreilly.com/velocity-mar2010/public/schedule/detail/14180

43. おしまい