DevOpsって何?<br />(株)paperboy&co.<br />宮下 剛輔<br />2010/5/19<br />
自己紹介<br />宮下 剛輔<br />mizzy, id:MIZZY, gosukenator(twitter, gmail)<br />http://mizzy.org/<br />ペパボで技術責任者というのをやってます<br />インフ...
自己紹介<br />子だくさん<br />4人子供がいます<br />最近の趣味<br />天体撮影<br />二十数年ぶりに再開。当時と勝手が違うので手探り状態<br />MGSPW<br />あまりやれてないですが<br />
お話させていただくことになった経緯<br />
DevOps概要<br />最近(2010年3月ぐらい)DevOpsという言葉をみつけ、それが自分の社内活動の背後にある考えを言語化するのにちょうど良いものである、ということに気づいた<br />ので、自分の考えや今後の方向性を整理するために、...
DevOPSとは?<br />
DevOpsとは?<br />
DevOpsとは?<br />DevOpsは、従来型のシステム管理や調達(ITILを含む)といった、保守的でプロセスを中心に据えた運用からより戦略的でアジャイルな、そして自動化されたアプローチへの転換を表現した言葉である。 http://bui...
DevOpsとは?<br />Dev= Development, Ops = Operations<br />定まった定義、解釈があるわけではないけど、狭義には「開発者と運用者の壁をなくしてビジネスを円滑に進めるためのプラクティス」と自分は解釈...
開発者と運用者の壁<br />It's not my machines, it's your code!/It’s not my code, it’s your machines!<br />開発者と運用者に限らず、異なる役割を持つ職種の人たち...
壁ができる要因<br />方向性の違い<br />守備範囲の違い<br />
方向性の違い<br />開発者の仕事は新しい機能を追加すること<br />運用者の仕事はサイトを速くて安定した状態に保つこと<br />こういった方向性の違いで壁ができるのでは<br />
方向性の違いをどう解消するか<br />「運用者の仕事はサイトを速くて安定した状態に保つこと」という考えは間違い<br />開発者も運用者も、ビジネスを円滑に進めることが役割(開発者、運用者だけに限らないけど)<br />ビジネス要件は常に変化...
守備範囲の違い<br />開発者は開発したアプリケーションが守備範囲<br />運用者はOS、ネットワーク、ミドルウェアといったあたりが守備範囲<br />
守備範囲の違い<br />【名】Silo<br />サイロ、〔家畜飼料・穀物などの〕貯蔵庫、地下ミサイル格納庫<br />窓がないサイロの中にいるように周囲を見ない仕事のやり方、自己中心的なスタイル<br />
守備範囲の違いをどう解消するか<br />実際には、厳密に境界線が引けるものではない、ということを認識する<br />双方からのアプローチが必要な場合が往々にしてある、ということを認識する<br />例)パフォーマンスチューニングではアプリケー...
ここまでのまとめ<br />DevOpsは開発者と運用者の壁をなくすためのプラクティス<br />DevとOpsの壁<br />仕事の方向性の違い<br />仕事の守備範囲の違い<br />DevOpsに重要なこと<br />変化を容易にし変化...
DevOpsの実践<br />
どのようにDevOpsを実践するのか?<br />DevOpsに重要なこと<br />変化を容易にし変化によるリスクを低減する<br />Siloisationの排除<br />具体的には何が必要か?<br />ツール(+スキル)<br />文...
DevとOpsが関わる領域<br />プロビジョニング<br />インフラの立ち上げ<br />インフラ設定<br />アプリケーションデプロイメント<br />モニタリング<br />システム監視<br />metrics(数的指標)の収集/...
プロビジョニング<br />インフラの立ち上げ<br />OSインストール<br />AMIやVMイメージの起動<br />インフラの設定<br />OS<br />ネットワーク<br />ミドルウェア<br />設定済みのAMI、VMイメージ...
OpenSourceProvisioning Toolchain<br />Toolchain = 何らかの目的を達成するためのソフトウェアの集まり<br />OpenSource Provisioning Toolchain=プロビジョニング...
OpenSourceProvisioning Toolchain<br />Bootstrapping<br />AWS, Cobbler, Eucalyptus, Jumpstart, Kickstart, OpenNebula, OpenQ...
いったん整理<br />DevOpsの実践<br />ツール<br />Open Source Provisioning Toolchain<br />文化<br />DevとOpsが絡む領域<br />プロビジョニング<br />インフラの立...
ツールがなぜDevOpsにつながるのか<br />自動化<br />変化を容易にする<br />専門的なスキルを持たなくても実施できる<br />Siloisationの排除<br />変化を正しく行う(リスクを低減)<br />
自動化による変化の容易性とリスクの低減の例<br />テスト環境を本番と同じ環境にし、同じ変化を発生させ、十分にテストができれば、変化も怖くない<br />同じことを楽に確実に行うためのツールによる自動化<br />テストの自動化も安心感を得る...
ツールがなぜDevOpsにつながるのか<br />構成管理(履歴管理)<br />誰がどのような変化を行ったか記録し、変化を可視化する<br />間違った変化をロールバック<br />構成管理は各ツール自身が持っていなくても、テキストベースで設...
構成管理による変化の容易性とリスクの低減の例<br />失敗してもすぐに戻せるとわかっていれば変化も怖くない<br />変化が起きた時に、誰がどんな意図でその変化を起こしたのかがすぐにわかれば、問題発生した際の原因特定が容易<br />適切なコ...
(+スキル)の意味<br />適切なツールを選択し、正しく使いこなすスキル<br />専門的な知識を持たなくても利用できるようにカスタマイズするスキル<br />必要なツールがなければ自分でつくれるスキル<br />DevとOpsが互いにオーバ...
いったん整理<br />DevOpsの実践<br />ツール<br />自動化と構成管理<br />文化<br />DevとOpsが絡む領域<br />プロビジョニング<br />インフラの立ち上げ<br />インフラの設定<br />アプリケ...
モニタリング<br />システム監視<br />稼働監視、リソース監視、アプリケーション監視<br />metricsの収集、可視化<br />キャパシティプランニングなど<br />具体的なツールについては省略<br />主にSiloisat...
モニタリングは誰が行う?<br />Opsだけの仕事になってることが多い?<br />Siloisationに陥りやすい領域?<br />Devの関わりもとても重要<br />稼働監視において、pingやHTTPレベルの監視では気づけない異常も...
モニタリングはDevもOpsもやるべき<br />監視項目をDevとOpsでレビューする<br />Opsがアプリケーション動作の監視ができるよう、Devがアプリの仕様をまとめる<br />Opsがカスタム監視スクリプトを開発するスキルを持つ<...
ここまでのまとめ<br />DevとOpsが関わりあう領域<br />プロビジョニングとモニタリング<br />変化を容易にし、リスクを低減<br />ツールによる自動化と構成管理<br />Silosationの排除<br />互いの領域に踏...
その他にも重要なこと<br />Siloisationの排除には情報共有も大切<br />Wiki, IM, IRC<br />IRC bot でコミットメッセージ、デプロイ情報、アラートなんかを流す<br />構成管理ツールも情報共有の一貫<...
文化<br />DevOpsには文化も重要<br />尊敬<br />信頼<br />失敗とうまくつきあう<br />責めない<br />
尊敬<br />開発者が怠け者だというステレオタイプを捨てる<br />お互いのスキル、意見、経験等に敬意を払う<br />「ノー」とだけ言わない<br />隠し事をしない<br />DevはOpsに対してコードのインパクトを説明する<br /...
信頼<br />Opsは将来の展望についてDevを信頼する<br />Devインフラの変更について議論する時にOpsを信頼する<br />お互いがビジネスのためにベストを尽くしていると信頼する<br />情報をシェアする<br />OpsはDe...
失敗とうまくつきあう<br />失敗は常に起こりうる<br />失敗はしないと思いこんでいると、何かあった時に対応できない<br />失敗に常に備えておく<br />
責めない<br />指をささない<br />誰かを責めてる暇があるなら、復旧に労力を使え<br />Dev: まずいコードを書くとOpsが叩き起こされるということを肝に銘じる<br />Ops:  現在問題になっていることについて、建設的なフィ...
まとめ<br />DevOpsとはDevとOpsの壁を取り払うためのプラクティス<br />ツールと文化によって変化を容易にし、変化によるリスクを低減し、Silosationを排除する<br />ツール<br />自動化と構成管理<br />文...
参考リンク<br />10+ Deploys Per Day: Dev and Ops Cooperation at Flickr<br />http://www.slideshare.net/jallspaw/10-deploys-per-d...
おしまい<br />
Upcoming SlideShare
Loading in...5
×

DevOpsって何?

18,474

Published on

Published in: Technology
0 Comments
58 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
18,474
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
195
Comments
0
Likes
58
Embeds 0
No embeds

No notes for slide

DevOpsって何?

  1. 1. DevOpsって何?<br />(株)paperboy&co.<br />宮下 剛輔<br />2010/5/19<br />
  2. 2. 自己紹介<br />宮下 剛輔<br />mizzy, id:MIZZY, gosukenator(twitter, gmail)<br />http://mizzy.org/<br />ペパボで技術責任者というのをやってます<br />インフラからウェブ開発まで幅広く<br />Perl界隈での活動が多いです(最近それほどでもないですが)<br />Puppetについてgihyo.jpで連載したり、SoftwareDesign誌で記事書いたりしました<br />
  3. 3. 自己紹介<br />子だくさん<br />4人子供がいます<br />最近の趣味<br />天体撮影<br />二十数年ぶりに再開。当時と勝手が違うので手探り状態<br />MGSPW<br />あまりやれてないですが<br />
  4. 4. お話させていただくことになった経緯<br />
  5. 5. DevOps概要<br />最近(2010年3月ぐらい)DevOpsという言葉をみつけ、それが自分の社内活動の背後にある考えを言語化するのにちょうど良いものである、ということに気づいた<br />ので、自分の考えや今後の方向性を整理するために、詳しく調べて見ることにした<br />というわけで、自分なりに咀嚼してみたDevOpsについてお話させていただきます<br />といっても、明確な定義があるわけではないため、基本的にはDevOpsムーブメントの大本と思われる、Velocity 2009でのFlickrのJohn Allspaw氏によるプレゼン「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」をベースとしてお話します(あくまでもベースなので、他の資料も参照していたり、自分の考えなんかも盛り込んでいます。)<br />
  6. 6. DevOPSとは?<br />
  7. 7. DevOpsとは?<br />
  8. 8. DevOpsとは?<br />DevOpsは、従来型のシステム管理や調達(ITILを含む)といった、保守的でプロセスを中心に据えた運用からより戦略的でアジャイルな、そして自動化されたアプローチへの転換を表現した言葉である。 http://builder.japan.zdnet.com/news/story/0,3800079086,20411692,00.htm より<br />
  9. 9. DevOpsとは?<br />Dev= Development, Ops = Operations<br />定まった定義、解釈があるわけではないけど、狭義には「開発者と運用者の壁をなくしてビジネスを円滑に進めるためのプラクティス」と自分は解釈してる<br />Velocity 2009での「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」というプレゼンが発端?<br />広義には開発者、運用者だけではなく、ヘルプデスク/顧客サポートやマネージャなども含む<br />Agile OperationsやAgileInfrastructureが似たような概念<br />
  10. 10. 開発者と運用者の壁<br />It's not my machines, it's your code!/It’s not my code, it’s your machines!<br />開発者と運用者に限らず、異なる役割を持つ職種の人たちの間で、詳細やニュアンスは違えど、多かれ少なかれ、こんな言葉が交わされることがあるのではないでしょうか<br />
  11. 11. 壁ができる要因<br />方向性の違い<br />守備範囲の違い<br />
  12. 12. 方向性の違い<br />開発者の仕事は新しい機能を追加すること<br />運用者の仕事はサイトを速くて安定した状態に保つこと<br />こういった方向性の違いで壁ができるのでは<br />
  13. 13. 方向性の違いをどう解消するか<br />「運用者の仕事はサイトを速くて安定した状態に保つこと」という考えは間違い<br />開発者も運用者も、ビジネスを円滑に進めることが役割(開発者、運用者だけに限らないけど)<br />ビジネス要件は常に変化する<br />「速くて安定」に固執すると、変化を受け入れにくくなる<br />要件に合わせて変化することを容易にし、変化によるリスクを低減することが重要<br />
  14. 14. 守備範囲の違い<br />開発者は開発したアプリケーションが守備範囲<br />運用者はOS、ネットワーク、ミドルウェアといったあたりが守備範囲<br />
  15. 15. 守備範囲の違い<br />【名】Silo<br />サイロ、〔家畜飼料・穀物などの〕貯蔵庫、地下ミサイル格納庫<br />窓がないサイロの中にいるように周囲を見ない仕事のやり方、自己中心的なスタイル<br />
  16. 16. 守備範囲の違いをどう解消するか<br />実際には、厳密に境界線が引けるものではない、ということを認識する<br />双方からのアプローチが必要な場合が往々にしてある、ということを認識する<br />例)パフォーマンスチューニングではアプリケーションの観点、ハードウェア、OS、ネットワークリソースの観点、双方が必要<br />Siloisationの排除が重要<br />
  17. 17. ここまでのまとめ<br />DevOpsは開発者と運用者の壁をなくすためのプラクティス<br />DevとOpsの壁<br />仕事の方向性の違い<br />仕事の守備範囲の違い<br />DevOpsに重要なこと<br />変化を容易にし変化によるリスクを低減する<br />Siloisationの排除<br />
  18. 18. DevOpsの実践<br />
  19. 19. どのようにDevOpsを実践するのか?<br />DevOpsに重要なこと<br />変化を容易にし変化によるリスクを低減する<br />Siloisationの排除<br />具体的には何が必要か?<br />ツール(+スキル)<br />文化<br />
  20. 20. DevとOpsが関わる領域<br />プロビジョニング<br />インフラの立ち上げ<br />インフラ設定<br />アプリケーションデプロイメント<br />モニタリング<br />システム監視<br />metrics(数的指標)の収集/可視化<br />
  21. 21. プロビジョニング<br />インフラの立ち上げ<br />OSインストール<br />AMIやVMイメージの起動<br />インフラの設定<br />OS<br />ネットワーク<br />ミドルウェア<br />設定済みのAMI、VMイメージ<br />アプリケーションデプロイメント<br />
  22. 22. OpenSourceProvisioning Toolchain<br />Toolchain = 何らかの目的を達成するためのソフトウェアの集まり<br />OpenSource Provisioning Toolchain=プロビジョニングを行うためのオープンソースソフトウェアの集まり<br />以下の3つの領域<br />Bootstrapping <br />Configuration<br />Orchestration<br />
  23. 23. OpenSourceProvisioning Toolchain<br />Bootstrapping<br />AWS, Cobbler, Eucalyptus, Jumpstart, Kickstart, OpenNebula, OpenQRM, VMWare<br />Configuration<br />BCFG, Cfengine, Chef, Puppet, SmartFrog<br />Orchestration<br />Capistrano, ControlTier, Fabric, Func<br />
  24. 24. いったん整理<br />DevOpsの実践<br />ツール<br />Open Source Provisioning Toolchain<br />文化<br />DevとOpsが絡む領域<br />プロビジョニング<br />インフラの立ち上げ<br />インフラの設定<br />アプリケーションデプロイメント<br />モニタリング<br />
  25. 25. ツールがなぜDevOpsにつながるのか<br />自動化<br />変化を容易にする<br />専門的なスキルを持たなくても実施できる<br />Siloisationの排除<br />変化を正しく行う(リスクを低減)<br />
  26. 26. 自動化による変化の容易性とリスクの低減の例<br />テスト環境を本番と同じ環境にし、同じ変化を発生させ、十分にテストができれば、変化も怖くない<br />同じことを楽に確実に行うためのツールによる自動化<br />テストの自動化も安心感を得るためにはとても大事<br />テストの自動化もDevOpsの文脈で語ることができる<br />
  27. 27. ツールがなぜDevOpsにつながるのか<br />構成管理(履歴管理)<br />誰がどのような変化を行ったか記録し、変化を可視化する<br />間違った変化をロールバック<br />構成管理は各ツール自身が持っていなくても、テキストベースで設定できるものであれば、Subversionなどの構成管理ツールが利用できる<br />
  28. 28. 構成管理による変化の容易性とリスクの低減の例<br />失敗してもすぐに戻せるとわかっていれば変化も怖くない<br />変化が起きた時に、誰がどんな意図でその変化を起こしたのかがすぐにわかれば、問題発生した際の原因特定が容易<br />適切なコミットメッセージを残すことも大切<br />ただし間違いを起こした人を責めてはいけない(後述する文化的な話)<br />
  29. 29. (+スキル)の意味<br />適切なツールを選択し、正しく使いこなすスキル<br />専門的な知識を持たなくても利用できるようにカスタマイズするスキル<br />必要なツールがなければ自分でつくれるスキル<br />DevとOpsが互いにオーバーラップするスキルを持つこともSiloisation排除に有効<br />
  30. 30. いったん整理<br />DevOpsの実践<br />ツール<br />自動化と構成管理<br />文化<br />DevとOpsが絡む領域<br />プロビジョニング<br />インフラの立ち上げ<br />インフラの設定<br />アプリケーションデプロイメント<br />モニタリング<br />
  31. 31. モニタリング<br />システム監視<br />稼働監視、リソース監視、アプリケーション監視<br />metricsの収集、可視化<br />キャパシティプランニングなど<br />具体的なツールについては省略<br />主にSiloisationにフォーカスします<br />
  32. 32. モニタリングは誰が行う?<br />Opsだけの仕事になってることが多い?<br />Siloisationに陥りやすい領域?<br />Devの関わりもとても重要<br />稼働監視において、pingやHTTPレベルの監視では気づけない異常もある<br />リソース監視においてCPUやメモリの情報を監視しても、アプリケーション側の動きと結びつけられないと原因の調査は難しい<br />アプリケーション側の視点から得られるものも多いのでは?<br />情報共有はとても大事<br />
  33. 33. モニタリングはDevもOpsもやるべき<br />監視項目をDevとOpsでレビューする<br />Opsがアプリケーション動作の監視ができるよう、Devがアプリの仕様をまとめる<br />Opsがカスタム監視スクリプトを開発するスキルを持つ<br />Devはそのサポートを行う<br />逆にDevが監視スクリプトを書く<br />Opsはそのサポートを行う<br />
  34. 34. ここまでのまとめ<br />DevとOpsが関わりあう領域<br />プロビジョニングとモニタリング<br />変化を容易にし、リスクを低減<br />ツールによる自動化と構成管理<br />Silosationの排除<br />互いの領域に踏み込む<br />互いにオーバーラップしたスキルを持つ<br />互いのスキルを補い合う<br />
  35. 35. その他にも重要なこと<br />Siloisationの排除には情報共有も大切<br />Wiki, IM, IRC<br />IRC bot でコミットメッセージ、デプロイ情報、アラートなんかを流す<br />構成管理ツールも情報共有の一貫<br />DevとOpsだけにとらわれない<br />ヘルプデスク/サポート、マネージャーなど、同じ考えが適用できるはず<br />先に挙げたツール以外にも重要なもの<br />ユニットテストとか<br />
  36. 36. 文化<br />DevOpsには文化も重要<br />尊敬<br />信頼<br />失敗とうまくつきあう<br />責めない<br />
  37. 37. 尊敬<br />開発者が怠け者だというステレオタイプを捨てる<br />お互いのスキル、意見、経験等に敬意を払う<br />「ノー」とだけ言わない<br />隠し事をしない<br />DevはOpsに対してコードのインパクトを説明する<br />数値指標がどのように変わるか?それはなぜか?<br />リスクは何か?<br />問題の早期発見には何を見ればいいのか?<br />もちろん事前の洗い出しが必要<br />
  38. 38. 信頼<br />Opsは将来の展望についてDevを信頼する<br />Devインフラの変更について議論する時にOpsを信頼する<br />お互いがビジネスのためにベストを尽くしていると信頼する<br />情報をシェアする<br />OpsはDevを信頼してシステムへのアクセスを許可すべき<br />
  39. 39. 失敗とうまくつきあう<br />失敗は常に起こりうる<br />失敗はしないと思いこんでいると、何かあった時に対応できない<br />失敗に常に備えておく<br />
  40. 40. 責めない<br />指をささない<br />誰かを責めてる暇があるなら、復旧に労力を使え<br />Dev: まずいコードを書くとOpsが叩き起こされるということを肝に銘じる<br />Ops: 現在問題になっていることについて、建設的なフィードバックをDevに提供する<br />
  41. 41. まとめ<br />DevOpsとはDevとOpsの壁を取り払うためのプラクティス<br />ツールと文化によって変化を容易にし、変化によるリスクを低減し、Silosationを排除する<br />ツール<br />自動化と構成管理<br />文化<br />尊敬<br />信頼<br />失敗とうまくつきあう<br />責めない<br />
  42. 42. 参考リンク<br />10+ Deploys Per Day: Dev and Ops Cooperation at Flickr<br />http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr<br />DevOps: Why Silos Suck And How To Break Them<br />http://www.agileweboperations.com/devops-why-silos-suck-and-how-to-break-them/<br />What Is This Devops Thing, Anyway?<br />http://www.jedi.be/blog/2010/02/12/what-is-this-devops-thing-anyway/<br />Provisioning Toolchain<br />http://en.oreilly.com/velocity-mar2010/public/schedule/detail/14180<br />
  43. 43. おしまい<br />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×