Your SlideShare is downloading. ×
夏サミ2013【A1】基礎からわかるDevOps
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

夏サミ2013【A1】基礎からわかるDevOps

5,425
views

Published on

Developers Summit 2013 Summer (2013年8月1日渋谷)の …

Developers Summit 2013 Summer (2013年8月1日渋谷)の
A1セッション「基礎からわかるDevOps」の登壇資料です。

【セッション概要】
最近DevOpsという言葉を頻繁に見かけるようになりましたが、DevOpsとは何なのか?については人によって解釈が異なっており、 もやっとしたバズワードのように感じてしまうというのが現状ではないかと思います。 本セッションでは、DevOpsとは何なのかを明らかにしつつ、DevOpsと密接な関わりのある組織や開発手法や自動化ソリューション、ツール群との関係性をお話しします。

Published in: Technology

0 Comments
34 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,425
On Slideshare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
0
Comments
0
Likes
34
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 基礎からわかるDevOps アマゾンデータサービスジャパン株式会社 吉羽龍太郎 Summit Developers #natsumi #natsumi1A
  • 2. 自己紹介 名前:吉羽龍太郎 • アマゾン データ サービス ジャパン株式会社 • プロフェッショナルサービス事業本部 • シニア・コンサルタント ソーシャル • @ryuzee • www.facebook.com/ryuzee.jp 個人の著作・翻訳
  • 3. このセッションでは開発や運用 における大きな方向性の話をし ます。その理解なくして、自分 が楽だから○○使う!とか開発 チームの人たちが××だ!とか 運用チームが△△だ!とか言う のはお互いのためになりません
  • 4. DevOpsの基礎
  • 5. ビジネス環境の変化 情報化 投資 投資内訳 情報化投資 指数 (2000年= 100) 民間企業 設備投資 民間設備投資 にしめる情報 化投資(%)通信機器 計算機本体 同付属装置 ソフトウェア 1980年 720 258 300 162 5.7 30,997 2.3 1985年 2,204 731 745 728 17.5 42,614 5.2 1990年 6,833 1,100 2,409 3,324 54.2 70,683 9.7 1995年 8,109 2,156 2,558 3,395 64.4 60,304 13.4 2000年 10,668 2,438 2,745 5,485 84.7 64,674 16.5 2005年 12,598 2,170 3,016 7,412 100.0 70,069 18.0 2010年 14,785 3,087 4,155 7,543 117.4 64,174 23.0 総務省「ICTの経済分析に関する調査」(平成23年度版)より引用 金額は単位10億円 企業の設備投資におけるIT投資の割合が20%を超えている 企業の戦略実現のためにITを使うように状況が変化 ITを活用できる企業が厳しい生存競争を勝ち抜くことに
  • 6. Amazonの3つのコアビジネス
  • 7. Amazonの3つのコアビジネス コンシューマ向け ビジネス 1億を超えるアクティブなア カウント 8カ国で展開 : 米国, 英国, ドイツ, 日本, フ ランス, カナダ, 中国, イタリア
  • 8. Amazonの3つのコアビジネス セラー向け ビジネス アマゾンの ウェブサイト上で販売 自社小売ウェブサイトに Amazonの技術を利用 アマゾンフルフィルメント センター(物流センター) の活用 コンシューマ向け ビジネス 1億を超えるアクティブなア カウント 8カ国で展開 : 米国, 英国, ドイツ, 日本, フ ランス, カナダ, 中国, イタリア
  • 9. IT インフラストラクチャ Amazonの3つのコアビジネス セラー向け ビジネス アマゾンの ウェブサイト上で販売 自社小売ウェブサイトに Amazonの技術を利用 アマゾンフルフィルメント センター(物流センター) の活用 コンシューマ向け ビジネス 1億を超えるアクティブなア カウント 8カ国で展開 : 米国, 英国, ドイツ, 日本, フ ランス, カナダ, 中国, イタリア
  • 10. IT インフラストラクチャ Amazonの3つのコアビジネス セラー向け ビジネス アマゾンの ウェブサイト上で販売 自社小売ウェブサイトに Amazonの技術を利用 アマゾンフルフィルメント センター(物流センター) の活用 コンシューマ向け ビジネス 1億を超えるアクティブなア カウント 8カ国で展開 : 米国, 英国, ドイツ, 日本, フ ランス, カナダ, 中国, イタリア スケーラビリティ 高可用性
  • 11. IT インフラストラクチャ Amazonの3つのコアビジネス セラー向け ビジネス アマゾンの ウェブサイト上で販売 自社小売ウェブサイトに Amazonの技術を利用 アマゾンフルフィルメント センター(物流センター) の活用 コンシューマ向け ビジネス 1億を超えるアクティブなア カウント 8カ国で展開 : 米国, 英国, ドイツ, 日本, フ ランス, カナダ, 中国, イタリア スケーラビリティ 高可用性 ITインフラ ビジネス 2006年開始 ウェブスケールでの クラウド基盤の提供 190以上の国において、数十 万に及ぶ登録アカウント
  • 12. Amazonのビジネスモデル
  • 13. ビジネスのためにITを活用!!
  • 14. DevOpsの起源
  • 15. DevOpsの起源 Velocity 2009での当時Flickrに所属 していた2名による発表が起源
  • 16. Dev & ops cooperation
  • 17. 開発者と運用者の壁 開発者は新しい機能をどんどん作る 運用者は安定した運用を提供する ミッションの違い It’s not my business. サイロ化 オーバーヘッド
  • 18. よくある光景 なんでアプリケーション ちゃんと作らないんだ? 運用でなんとかするのが 仕事でしょ?
  • 19. 同じ話は組織のあちこちに このコード書いたのは××さんなので分かりません この作業は××さん担当なので僕のせいじゃないです ○○部門がいつもギリギリに色々指摘するせいで遅くなるんです こっちにも都合というものが… それ規則で決まってるんです
  • 20. サイロ化によるオーバーヘッド 価値を生み 出すのに使 う時間 価値を生み 出すのに使 う時間 価値を生む 際のオー バーヘッド 価値を生む 際のオー バーヘッド Dev Ops 価値を生む作業に時 間を使えていない・ ムダがある! この話はDevとOps間に限らない話!
  • 21. ビジネスは変化する
  • 22. システムの機能の利用割合 Standishの2000年の調査より
  • 23. システムの機能の利用割合 Standishの2000年の調査より
  • 24. 本当に必要なものがわかるか?
  • 25. ビッグバンを避ける
  • 26. フィードバックループ 顧客とビジネスの間のフィードバックループを加速する 顧客の期待に応え続ける
  • 27. フィードバックループの高速化 要求 設計 開発 テスト QA リリース フィード バック メトリク ス ビジネス
  • 28. 9 24 48 61 82 159 2007 2008 2009 2010 2011 2012 AWSのイノベーションのペース
  • 29. DevもOpsもビジネスの成果達成を支える
  • 30. DevOpsとはDevとOpsが ビジネスの成果を 継続的に達成できるように お互いが協力しあう という考え方
  • 31. DevOps is not Framework DevOpsは考え方でプロセスやフレームワークではない 実装は現場によって異なる
  • 32. 文化よるサポート お互いの尊重 お互いの信頼 失敗に対する健全な態度 お互いを非難しない
  • 33. ツールによるサポート インフラ構築自動化 バージョン管理 継続的インテグレーション デプロイ自動化 監視 情報共有 • Wiki、IRC、BTS ダッシュボード このツール群はあくまで代表的なもので、全部必須なわけではない
  • 34. DevOpsは 文化とツールを通じて、 変化に対応し、 変化のリスクを減らす
  • 35. DevOpsは銀の弾丸ではない
  • 36. あるべき姿 価値を生み 出すのに使 う時間 価値を生み 出すのに使 う時間 オーバーヘッド オーバーヘッド Dev Ops ゴールの共有 お互いの協力 ツールの活用 によって価値を生み 出す時間を増やし、 時間効率も改善
  • 37. チームの能力を最大限発揮する
  • 38. DevOps=自動化ではない ただし自動化はリスク低減と アジリティ向上に大きく寄与
  • 39. 開発プロセスとの関係
  • 40. http://www.agilemanifesto.org
  • 41. 41 Agileソフトウェア開発の原則 http://www.agilemanifesto.org/principles.html 12個の原則
  • 42. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • 43. プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対見積もり。 項目の追加はいつでも自由だが実施有無や優 先順位はPOが決める。 開発チーム (6±3人) プロダクトの開発を行う。 製品の成功に向けて最大限 の努力をコミットする スクラムマスター スクラムプロセスがうまく いくようにする。 外部から開発チームを守る プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける ステークホルダー 製品の利用者、出資者、管理職 などの利害関係者。鶏と称す スプリントバックログ そのスプリント期間中に行う タスクのリスト スプリント 最大4週間までのタイムボックス 各スプリントの長さは同一。この間は外部 からの変更を受け入れない スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する レトロスペクティブ スプリントの中での改善事項 を話合い次に繋げる 複 数 回 ス プ リ ン ト を 繰 り 返 す 出荷可能な 製品の増分 スプリント計画会議 プロダクトバックログを再度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項目 をタスクにばらす 完了の定義 何をもって「完了」とするかを 定義したリスト 毎日の繰り返し デイリースクラム 毎日開発チームが以下の3つの質問に答える ・昨日やったこと ・今日やること ・困っていること バーンダウンチャート スプリントタスクの「推定残り時間」を 更新してグラフにプロットする タスク 時間で見 積もり
  • 44. 優先順位をつけて1つづつ確認 1番目にほしい 2番目にほしい 3番目にほしい 4番目にほしい 5番目にほしい ・ ・ ・ 99番目にほしい 100番目にほしい よし頼んだ通りなのでOKです。 完了だ! あれ、ここクリックすると遷移先 が違うね。これは未完了 あ、こうなるのか。頼んだ通りだ から完了だけど、次のスプリント で機能追加しようか! 確認が完了したものから リリースしちゃえばお客 様は喜ぶはずだなぁ…
  • 45. XP – 19個のプラクティス 反復 メタファー 作業空間 ふりかえり テスト駆動開発 ペアプロ リファクタリング コードの 共同所有 継続的インテグ レーション YAGNI 責任 擁護 四半期毎の 見直し ミラー 持続可能な ペース ストーリー作成 リリース計画 受け入れテスト 短期リリース
  • 46. 共通理解 コード レビュー チェックイン ユニット テスト カバレージ ドキュメント セキュリティ 性能 デプロイ などなど 完了の定義を作り、何をもって出荷可能かを定める 定義はビジネス+Dev+Opsで作成 • 自動でチェックできるものを増やせばサイクルタイム短縮 • 開発や運用での知見を定義に反映する
  • 47. 品質の作りこみ 早く見つけて速く直す フェーズ 修正までの時間 要求や設計 5分 コードやユニットテスト 15分 結合テストやシステムテスト 1時間 ベータテスト 2時間 リリース後 1日
  • 48. 継続的デリバリー 繰り返し型の 開発 継続的 インテグレーション 継続的 デプロイ Scrum  要求に順位付け  タイムボックス による制御  検査と適用によ る継続的改善  透明性の確保  自己組織型チー ム  技術的プラク ティスの定義な し Scrum+XP  xUnit等による テスト自動化  テスト駆動開発  コーディング規 約  ペアプロ等  常時出荷可能な 品質を保持  主に技術的プラ クティスから構 成される Lean  Just in Timeで 顧客が必要なも のを必要なとき に。  サイクルタイム を測定し改善す る。  ビジネス活動そ のもの  全体最適
  • 49. フィーチャー単位で完了 コードレビュー チェックイン ユニットテスト カバレッジ ドキュメント 性能 セキュリティ デプロイ 結合テスト 受け入れテスト クロスブラウザ 静的解析 フィーチャー コードレビュー チェックイン ユニットテスト カバレッジ ドキュメント 性能 セキュリティ デプロイ 結合テスト 受け入れテスト クロスブラウザ 静的解析 フィーチャー コードレビュー チェックイン ユニットテスト カバレッジ ドキュメント 性能 セキュリティ デプロイ 結合テスト 受け入れテスト クロスブラウザ 静的解析 フィーチャー コードレビュー チェックイン ユニットテスト カバレッジ ドキュメント 性能 セキュリティ デプロイ 結合テスト 受け入れテスト クロスブラウザ 静的解析 フィーチャー コードレビュー チェックイン ユニットテスト カバレッジ ドキュメント 性能 セキュリティ デプロイ 結合テスト 受け入れテスト クロスブラウザ 静的解析 フィーチャー コードレビュー チェックイン ユニットテスト カバレッジ ドキュメント 性能 セキュリティ デプロイ 結合テスト 受け入れテスト クロスブラウザ 静的解析 フィーチャー コードレビュー チェックイン ユニットテスト カバレッジ ドキュメント 性能 セキュリティ デプロイ 結合テスト 受け入れテスト クロスブラウザ 静的解析 フィーチャー
  • 50. 平均11.6秒ごとにデプロイ 1時間で最大1,079回のデプロイ 1回で平均1万台のホストへデプロイ 最大で3万台のホストへ同時にデプロイ
  • 51. 自動化による時間の使い方の変化 頻繁な変化を人手で行うことは限界がある いままでは手作業に多くの時間を テスト自動化、インフラ構築自動化へ 本質的に価値を生む箇所に時間を使う これは開発だけでなく運用も同じ 品質を作りこみ続ける
  • 52. テスト自動化
  • 53. テスト自動化アンチパターン 頻繁にバージョン管理システムにコミットしない テストコードを書かない テストコードと製品コードを同時にコミットしない 定時ビルドのみでコミットビルドがない・夜間ビルドしかない 帰り際にコミットしてそのままCIの結果を見ずに帰る CIでテストを通すために手作業の準備が必要 メインラインのみで大きなブランチをCI対象にしていない 様々な種類のテストをまとめて行っている ビルドの失敗に気付かない / ビルドに失敗しても放置している ビルドの失敗に気づいても、修正コード以外のコードをコミットする 何も変更していないのにビルドが落ちたり落ちなかったり 頻繁にビルドが失敗するので、失敗するのが普通だと思う CIからの通知メッセージが大量すぎる / CIが落ちても何も通知しない CIサーバのリソースが貧弱 ビルドが肥大化して結果が出るまでに時間がかかる 本番環境やステージング環境と大幅に環境が異なる コードの静的解析をCIで行わずに人手で行う CIサーバがおかしくなったときに直せる人がいない ずっとCIでのチェック内容が変わらない、プロセスが変わらない
  • 54. Infrastructure as Code サーバーの台数が増えると作業に多くの時間がかかる 単純作業の繰り返しになるため間違いを誘発しやすい 手順書やチェックリストが時間の経過とともにメンテ ナンスされない 手順書やチェックリストが正しいかどうか分からない 作業の順番を間違えるとサーバーの状態が変わる このように人手による作業のため間違いやすい さらに間違えたことに気づく仕掛けがないため、ある 日障害という形でその問題が顕在化する
  • 55. Infrastructure as Code コードによるインフラの記述 サーバーの台数が増えても構築に時間がかからない コード=手順書となるのでコードを常にメンテナンスしておけば良い 手順を抜かしたり手順を間違う心配がない 同じコードを動かせば同じサーバーが出来上がる コードで記述されているので再利用が容易である 他のプロジェクトでコードを使いまわすことで無駄を省ける
  • 56. 環境構築自動化
  • 57. クラウドコンピューティング 初期投資不要 利用した分だけの低額な費用 伸縮自在性・柔軟性 速度・アジリティの向上 コアコンピタンスへの集中 ワールドワイド
  • 58. Design for Failure 全てのものが壊れる前提で設計する サーバもアプリケーションも 1か所壊れても動くように 疎結合アーキテクチャー 自動復旧 自動伸縮
  • 59. DevOpsの進め方
  • 60. DevOpsいつやるの? いまでしょ! の前にやることがあります
  • 61. あなたの組織のゴールは?
  • 62. カイゼンすべき箇所はどこなのか? 作りすぎのムダ 手待ちのムダ 運搬のムダ 加工のムダ 在庫のムダ 動作のムダ 不良をつくるムダ Just in Time かんばん ムダ 平準化 アンドン ポカヨケ 自働化 改善 見える化 付加価値を高めない各種現象や結果をムダと呼ぶ
  • 63. 小さく始める いきなり自分たちのプロセスを大きく変えない 一度に沢山変えると変化に耐えられない 小さな取り組みを継続的におこなう 取り組みの成果を確認しつづける 小さな成功を早期から繰り返す 組織やプロセスを着実に成長させる
  • 64. 1日にしてならず
  • 65. じゃあどこから始めるの?
  • 66. 当たり前のことを当たり前に バージョン管理 コーディング規約 コードレビュー テスト自動化 ドキュメント … 基礎なくして応用のテクニックを目指さない まず当たり前のことから当たり前に
  • 67. よくある形
  • 68. 推進役はだれ?
  • 69. 組織づくり 単にDevOps専任組織を作ってもうまくいかない 既存チームにDevOpsという名前をつけても変わらない 全員が同じゴールに向かって進めるか • チームのゴールと個人のゴールが相反したらどうなる? • 人事考課が個人の成果に大きな比重を置きすぎると?
  • 70. 成功を祝う 成功をみんなで祝う!
  • 71. DevOpsは銀の弾丸ではない 大事なことなので2度言いました…
  • 72. 自分の組織にとっての DevOpsとは何なのか?どう なれば成功かを考え、着実に 小さい成功を積み上げる
  • 73. 175を超えるセッション! Gameday! Hackathon! Boot Camp! ラボ! 展示会! パーティー! re:Invent 2013 参加ツアーの申し込みはこちら! http://bit.ly/reinvent2013japan 11月12日 (火) 〜 11月15日 (金) の4日間 ! ラスベガス・ベネチアンホテルで開催! http://bit.ly/reinvent2013 基調講演 日本語同時通訳! 日本専用トラック! 懇親ディナー! シアトルオフィス訪問! ※ツアー参加の特典です。