• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
DevOpsって何?
 

DevOpsって何?

on

  • 18,842 views

 

Statistics

Views

Total Views
18,842
Views on SlideShare
18,437
Embed Views
405

Actions

Likes
45
Downloads
176
Comments
0

13 Embeds 405

http://www.slideshare.net 244
http://coderwall.com 97
http://s.deeeki.com 26
http://paper.li 13
https://twimg0-a.akamaihd.net 5
http://logpi.jp 5
https://si0.twimg.com 3
https://twitter.com 3
https://www.chatwork.com 3
http://twitter.com 2
http://webcache.googleusercontent.com 2
http://linyo.ws 1
http://rssc.dokoda.jp 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    DevOpsって何? DevOpsって何? Presentation Transcript

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