DevOpsって何？

DevOpsって何？,[object Object],(株)paperboy&co.,[object Object],宮下剛輔,[object Object],2010/5/19,[object Object]

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

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

お話させていただくことになった経緯,[object Object]

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

DevOPSとは？,[object Object]

DevOpsとは？,[object Object]

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

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

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

壁ができる要因,[object Object],方向性の違い,[object Object],守備範囲の違い,[object Object]

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

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

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

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

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

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

DevOpsの実践,[object Object]

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

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

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

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

OpenSourceProvisioning Toolchain,[object Object],Bootstrapping,[object Object],AWS, Cobbler, Eucalyptus, Jumpstart, Kickstart, OpenNebula, OpenQRM, VMWare,[object Object],Configuration,[object Object],BCFG, Cfengine, Chef, Puppet, SmartFrog,[object Object],Orchestration,[object Object],Capistrano, ControlTier, Fabric, Func,[object Object]

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

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

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

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

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

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

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

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

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

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

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

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

文化,[object Object],DevOpsには文化も重要,[object Object],尊敬,[object Object],信頼,[object Object],失敗とうまくつきあう,[object Object],責めない,[object Object]

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

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

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

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

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

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

DevOpsって何？

DevOpsって何？

Recommended

More Related Content

What's hot

What's hot(20)

Similar to DevOpsって何？

Similar to DevOpsって何？(20)

More from Gosuke Miyashita

More from Gosuke Miyashita(20)

Recently uploaded

Recently uploaded(7)

DevOpsって何？