Download as PDF, PPTX
Uploaded byRakuten Group, Inc.
三位一体の自動化で壊せ DevとOpsの壁～アラサーエンジニアの挑戦～
安全で安心なWebサービスの継続的な改善をするために、開発、テスト、運用のサイクルを早いフローで実現する、DevOpsや継続的デリバリー、Infrastructure as Code などの開発手法がコミュニティで提案されています。その一方、企業文化や組織体系のためにうまく導入が進まないケースも多いです。 本セッションでは、楽天のDevとOpsのアラサーエンジニアが、開発・テスト・運用の三位一体の自動化でDevOpsを社内に導入したFearless Changeについてのストーリーをお話しします。 Developers Summit 2016 で発表資料です。 http://event.shoeisha.jp/devsumi/20160218/session/1041/
More Related Content
![[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス](https://cdn.slidesharecdn.com/ss_thumbnails/amazonauroratips-170307140000-thumbnail.jpg?width=640&height=640&fit=bounds)
![[20220126] JAWS-UG 2022初頭までに葬ったAWSアンチパターン大紹介](https://cdn.slidesharecdn.com/ss_thumbnails/20220126-anti-220126190603-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to 三位一体の自動化で壊せ DevとOpsの壁～アラサーエンジニアの挑戦～
三位一体の自動化で壊せ DevとOpsの壁～アラサーエンジニアの挑戦～
- 1. 三位一体の自動化で壊せ DevとOpsの壁 “アラサーエンジニアの挑戦” Feb. 19, 2016 ハッシュタグ:#devsumiC セッションID: 19-C-5 Kotaro Ogino, Takaaki Furukawa Rakuten, inc.
- 2.
- 3.
- 4.
- 5.
- 6. 6 Fearless Change マリリン・マンズ, リンダ・ライジング （著） 川口恭伸 （監訳）,楽天株式会社 ・エバンジェリスト(1) ・外部のお墨付き(12) ・勉強会(25) ・恐れは無用(46) など
- 7.
- 8. 8 2010 - 2012(新人時代) 業務内容： ・サーチプラットフォームの開発 ・開発・テスト・運用すべてやっていた ・CassandraやSolrのテストやパッチ ・テストの自動化も 思い出： ・NoSQLは品質特性が大事 ・しかしまだまだ未成熟な時代 ・僕自身たくさんバグを作った（笑）
- 9.
- 10. 10 2013 (社内外での発表と勉強会の主催) (*1)http://crooz.co.jp/13244 第6回テックヒルズ(*1)での発表 http://www.slideshare.net/kotaroogino/ngauto-tech-hills Tech TalkCI Specialの主催 パターン：勉強会 (25) 相談できる同志(39) 解決策の提案。勉強会で効果を発表 http://d.hatena.ne.jp/hyoshiok/ 20100312#p1
- 11.
- 12.
- 13.
- 14. 14 2014 (仕事の成果のシンポジウムでの発表) JaSST’Tokyo 2014 バグ修正日数を使った評価 http://jasst.jp/symposium/jasst14tokyo/details.html#D2-2 http://www.slideshare.net/kotaroogino/jasst14-tokyo http://www.juse.jp/sqip/symposium/2014/detail/day1/ #session_A1-3 http://www.slideshare.net/kotaroogino/ngauto-s- qip2014presentation20140906 SQiP2014 様々なメトリクスを使った評価 ＊SQiP Best Report Future Award 受賞 パターン：外部のお墨付き(22) 組織にもたらす効果をマネージメント層が理解できる言葉で
- 15.
- 16.
- 17. 17 2014 (挫折) 挫折の内容 ・組織的な評価 ・勉強会のROI 考えたこと ・ヘッドハンターに相談 → 真剣に転職を考える ・人事や執行役員に相談 → 自分の組織を作れと怒られる ・勉強会コミュニティの先輩に相談 →勉強会は”準備できている事が大事” 結論 ・部署移動
- 18. 18 2014 (部署移動) パターン：正式な推進担当者(29) ぼっチームでFearless Changeを再始動 異動して変わったこと ・正式な自動化担当部署 ・担当するプロジェクトが1から20に しかし実質的に何もない状態 自動化要素ある？ やる気 ◯ Jenkins たくさん テスト自動化ツール × アジャイルな文化 × テストエンジニアの自動化スキル ×
- 19.
- 20.
- 21.
- 22.
- 23.
- 24. 24 • 楽天のインフラ § プライベートクラウド主流の文化 § サーバ台数: 30,000+ § 管理する部署: 400+ • 私 § サーバプロビジョニング専門グループに所属 • OSインストール・初期設定 • MWの初期設定 • DNSレコード登録 • etc 楽天のインフラの特徴と私 インフラ DB API API アプリケーション 自動テスト ここ
- 25. 25 Hypervisor: Xen OS Instances: 2,000+ Management features from scratch Hypervisor: KVM Use OpenStack API 2015 Gen3 2012 Gen2 2010 Gen1 Hypervisor: VMware ESXi OS Instances: 20,000+ Management features from scratch 楽天のプライベートクラウドの歴史
- 26. 26 2010 - 2012 課題 • 仮想化によって増加するサーバ台数 • 手順書によるマニュアル作業（コピペマシン） アクション • サーバ構築作業への構成管理ツール導入
- 27. 27 2010 - 2012 • 手順書の作業コストやリスクの説明 • Chef, Puppet, Saltstackを比較し、Chefを採用 • 最初はchef-soloでスモールスタート • 定型作業などの優先度の高いものから順に パターン：エバンジェリスト （1） “新しいアイデアを組織に導入し始めるなら、 情熱を共有するために出来る限りの事をしよう”
- 28. 28 2010 - 2012 アクション • サーバ構築作業への構成管理ツール導入 結果 • 定型作業にかかる工数削減！ 課題 • 仮想化によって増加するサーバ台数 • 手順書によるマニュアル作業（コピペマシン）
- 29. 29 2013 - 2014 課題 • 他部署にChefの導入を推進 アクション • 社内勉強会を開く
- 30. 30 2013 - 2014 § 運用部署向け社内勉強会 § 荻野さんが開催している社内勉強会で発表。 パターン：種をまく（22） “機会のある時に資料(種)をもっていって、 それらを見せる(蒔く)ようにしよう” 運用 運用 サーバ構築専門グループ 開発 運用 運用 開発 開発 開発 開発 開発 開発 開発 開発 開発 開発 開発 開発 開発 開発 開発
- 31.
- 32. 32 • 忙しくて学習できない • スクリプトで自動化した方が早い • 導入実績がまだまだ足りない • サーバ台数とサーバの種類が多い • Chefだけではすべてのインフラ作業をコード化で きない 2013 - 2014 パターン：懐疑派代表（44） “懐疑派代表の意見を活用しよう”
- 33. 33 2013 - 2014 課題 • 他部署にChefの導入を推進 アクション • 社内勉強会を開く 結果 • あまり浸透せず・・・。
- 34. 34 2014 - 2015 課題 • Chefでカバーできない部分のコード化 • Infrastructure as Codeの導入実績 アクション • Chefとは別の構成管理ツール導入 • Devとのコラボレーション
- 35.
- 36. 36 2014 - 2015 パターン：ステップバイステップ（3） “目標に向かって一歩一歩進めていく” ChefとTerraformで コードによるインフラ管理が可能に • Chef: サーバの内側 • Terraform: サーバの外側 • Terraformのプラグイン開発 • VMware vSphere providerはOSSで公 開、Terraform本家にマージされる
- 37. 37 Infrastructure as Codeの重要性 パターン：テイラーメイド（26） “組織のニーズに合わせる” Ops • 組織の業務内容をChef CookbookとTerraform Moduleで抽象化 Dev • 要件に合わせてCookbookやModuleを利用 • インフラ知識がなくてもインフラ作業が可能に
- 38. 38 2014 - 2015 結果 • インフラのコード管理の実績ができた • 抽象化されたコードは組織の壁を越える 課題 • Chefでカバーできない部分のコード化 • Infrastructure as Codeの導入実績 アクション • Chefとは別の構成管理ツール導入 • Devとのコラボレーション
- 39.
- 40.
- 41. 41 アラサーエンジニアパターン ・ チームで成果を出した経験と信頼貯金 ・ 社内事情と業界のトレンドを熟知 ・マネジメント業務に忙殺されていない → チームを越えたFearless Changeの 基盤が整っている
- 42. 42 Dolphin Project:Dev OpsTestのワンチーム Dev Ops Test Automation Business Values Business Requirements
- 43.
- 44. 44 ビジョン：サービスの成長のための Dev, TestとOps SCM 時間 サービスの 成長度 デプロイ デプロイデプロイ SCM テスト テスト テスト ソースコードソースコードソースコード Dev Test テストケーステストケーステストケース SCM デリバリー Ops 構成情報構成情報構成情報 デリバリー デリバリー
- 45. 45 ウェブサービスの持続可能な成長に関する 非機能要件の例 カテゴリ 例 Deliverability ・１週間に１度リリース可能であること Operability ・ログ監視システムより５分以内に 障害の切り分けが可能なこと Testability ・１週間に１度、評価データを 更新可能なこと
- 46.
- 47.
- 48. 48 Dolphinの課題 Dev OpsTest 役割で分割されたチーム 影響 モノリシックなアーキテクチャ インフラ DB レイヤ APIAPI アプリケーション 依存 ウォータースクラムフォール？ Dev Test Ops Dev 役割で分割されたチームの問題点 ・ ビジネスの非機能要件とは無関係に 組織構造によりアーキテクチャやプロセスに制約 ・ 役割を越えた作業に交渉や承認が必要 Test Ops チーム アーキテクチャ 影響 プロセス 自動テスト 影響 影響
- 49. 49 Dolphinで実現したいこと サービスごとのワンチーム ビジネスの非機能要件 サービスごとに分割されたチームの利点 ・ ビジネスの非機能要件に最適なアーキテクチャや プロセスをサービスごとに選択可能 ・ チームがすべての作業を担当可能 チーム アーキテクチャ プロセス 影響 インフラ DB レイヤ API API アプリケーション Dev Test Ops Dev Test Ops 自動テスト ? ? 依存 影響 影響
- 50.
- 51. 51 Dolphinプロジェクトのコンセプト ・Dev, Test Ops三位一体の自動化 -パターン指向自動化 専門性を生かし標準パターンを作成 標準パターンを自動化 -セルフサービス 標準パターンの自動化スクリプトの 実行権限をチームメンバーに付与
- 52.
- 53. 53 Dolphin プロジェクト 特徴 Dev, OpsとTestのワンチーム 課題 サービスごとに非機能要件を実現 コンセプト ・Dev,TestOps三位一体の自動化 -パターン指向自動化 -セルフサービス
- 54. 54 プロビジョニング サーバ情報 テスト結果 CI システム テスト Cookbook TerraformFiles Pull Request Review デプロイメントパイプライン Opsの自動化 開発〜テストの 自動化
- 55. 55 CIとInfrastructure Automationの連携 プロビジョニング サーバ情報 テスト結果 CIシステム テスト Cookbook Terraform Files Pull Request Review OpsDev
- 56.
- 57.
- 58.
- 59. 59 パイロットプロジェクトの成果 0 50 100 150 200 旧チーム体制 Dolphin (hours) 99.40%削減 Dev, Ops,Testの三位一体の自動化により それぞれの自動化の効果を最大化 Build Functional Test Provisioning (Deploy) Non-Functional Test Test Report リードタイム
- 60.
- 61.
- 62.
- 63. 63 まとめ❷：アラサーエンジニアパターン アラサーエンジニアこそ 組織を変えるチャンス！ ・ チームで成果を出した経験と信頼貯金 ・ 社内事情と業界のトレンドを熟知 ・マネジメント業務に忙殺されていない → チームを越えたFearless Changeの 基盤が整っている
- 64.