三位一体の自動化で壊せ DevとOpsの壁～アラサーエンジニアの挑戦～
27 likes8,558 views
安全で安心なWebサービスの継続的な改善をするために、开発、テスト、運用のサイクルを早いフローで実現する、DevOpsや継続的デリバリー、Infrastructure as Code などの开発手法がコミュニティで提案されています。その一方、企業文化や組織体系のためにうまく導入が進まないケースも多いです。 本セッションでは、楽天のDevとOpsのアラサーエンジニアが、开発?テスト?運用の三位一体の自動化でDevOpsを社内に導入したFearless Changeについてのストーリーをお話しします。 Developers Summit 2016 で発表資料です。 http://event.shoeisha.jp/devsumi/20160218/session/1041/
![[AWS EXpert Online for JAWS-UG 18] 見せてやるよ、Step Functions の本気ってやつをな](https://cdn.slidesharecdn.com/ss_thumbnails/awsxon18howfarstepfunctionsgo-211124111849-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Similar to 三位一体の自動化で壊せ DevとOpsの壁～アラサーエンジニアの挑戦～ (20)
![[REV UP] あなたならどう使う？最新Azureレシピ for LINE Platform](https://cdn.slidesharecdn.com/ss_thumbnails/azureforlpfrevup2020-201114074337-thumbnail.jpg?width=560&fit=bounds)
More from Rakuten Group, Inc. (20)
Recently uploaded (8)
![ElasticsearchでSPLADEする [Search Engineering Tech Talk 2025 Winter]](https://cdn.slidesharecdn.com/ss_thumbnails/searchtech-250228102455-ddc5ce09-thumbnail.jpg?width=560&fit=bounds)
三位一体の自動化で壊せ DevとOpsの壁～アラサーエンジニアの挑戦～
- 1. 三位一体の自動化で壊せ DevとOpsの壁? “アラサーエンジニアの挑戦” Feb. 19, 2016 ハッシュタグ: #devsumiC セッションID: 19-C-5 Kotaro Ogino, Takaaki Furukawa Rakuten, inc.
- 6. 6 Fearless Change マリリン?マンズ, リンダ?ライジング （著） 川口恭伸 （監訳）, 楽天株式会社 ?エバンジェリスト(1) ?外部のお墨付き(12) ?勉強会(25) ?恐れは無用(46) など
- 8. 8 2010 - 2012 (新人時代) 業務内容： ?サーチプラットフォームの开発 ?开発?テスト?運用すべてやっていた ?CassandraやSolrのテストやパッチ ?テストの自動化も 思い出： ?NoSQLは品質特性が大事 ?しかしまだまだ未成熟な時代 ?僕自身たくさんバグを作った（笑）
- 10. 10 2013 (社内外での発表と勉強会の主催) (*1)http://crooz.co.jp/13244 第6回テックヒルズ(*1)での発表 http://www.slideshare.net/kotaroogino/ngauto-tech-hills Tech Talk CI Specialの主催 パターン：勉強会 (25) 相談できる同志(39) 解決策の提案。勉強会で効果を発表 http://d.hatena.ne.jp/hyoshiok/ 20100312#p1
- 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 SQiP 2014 様々なメトリクスを使った評価 ＊SQiP Best Report Future Award 受賞 パターン：外部のお墨付き(22) 組織にもたらす効果をマネージメント層が理解できる言葉で
- 16. 16 2014 挫折
- 17. 17 2014 (挫折) 挫折の内容 ?組織的な評価 ?勉強会のROI 考えたこと ?ヘッドハンターに相談 → 真剣に転職を考える ?人事や執行役員に相談 → 自分の組織を作れと怒られる ?勉強会コミュニティの先輩に相談 →勉強会は”準備できている事が大事” 結論 ?部署移動
- 18. 18 2014 (部署移動) パターン：正式な推進担当者(29) ぼっチームでFearless Changeを再始動 異動して変わったこと ?正式な自動化担当部署 ?担当するプロジェクトが1から20に しかし実質的に何もない状態 自動化要素 ある？ やる気 ? Jenkins たくさん テスト自動化ツール × アジャイルな文化 × テストエンジニアの自動化スキル ×
- 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. 31 2014 挫折
- 32. 32 ?? 忙しくて学習できない ?? スクリプトで自動化した方が早い ?? 導入実績がまだまだ足りない ?? サーバ台数とサーバの種類が多い ?? Chefだけではすべてのインフラ作業をコード化で きない 2013 - 2014 パターン：懐疑派代表（44） “懐疑派代表の意見を活用しよう”
- 33. 33 2013 - 2014 課題 ?? 他部署にChefの導入を推進 アクション ?? 社内勉強会を開く 結果 ?? あまり浸透せず???。
- 34. 34 2014 - 2015 課題 ?? Chefでカバーできない部分のコード化 ?? Infrastructure as Codeの導入実績 アクション ?? Chefとは別の構成管理ツール導入 ?? Devとのコラボレーション
- 35. 35 2014 - 2015
- 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とのコラボレーション
- 41. 41 アラサーエンジニアパターン ? チームで成果を出した経験と信頼貯金 ? 社内事情と業界のトレンドを熟知 ? マネジメント業務に忙殺されていない → チームを越えたFearless Changeの 基盤が整っている
- 42. 42 Dolphin Project:Dev Ops Testのワンチーム Dev Ops Test Automation Business Values Business Requirements
- 44. 44 ビジョン：サービスの成長のための? Dev, TestとOps SCM 時間 サービスの 成長度 デプロイ デプロイ デプロイ SCM テスト テスト テスト ソースコードソースコードソースコード Dev Test テストケーステストケーステストケース SCM デリバリー Ops 構成情報構成情報構成情報 デリバリー デリバリー
- 45. 45 ウェブサービスの持続可能な成長に関する? 非機能要件の例 カテゴリ 例 Deliverability ?１週間に１度リリース可能であること Operability ?ログ監視システムより５分以内に 障害の切り分けが可能なこと Testability ?１週間に１度、評価データを 更新可能なこと
- 47. 47 コンウェイの法則：? チーム体制とアーキテクチャ インフラ DB API API アプリケーション 自動テスト アーキテクチャー レイヤーごとに共通化 チーム レイヤーに対応した チーム
- 48. 48 Dolphinの課題 Dev OpsTest 役割で分割されたチーム 影響 モノリシックなアーキテクチャ インフラ DB レイヤ API API アプリケーション 依存 ウォータースクラムフォール？ Dev Test Ops Dev 役割で分割されたチームの問題点 ? ビジネスの非機能要件とは無関係に 組織構造によりアーキテクチャやプロセスに制約 ? 役割を越えた作業に交渉や承認が必要 Test Ops チーム アーキテクチャ 影響 プロセス 自動テスト 影響 影響
- 49. 49 Dolphinで実現したいこと サービスごとのワンチーム ビジネスの非機能要件 サービスごとに分割されたチームの利点 ? ビジネスの非機能要件に最適なアーキテクチャや プロセスをサービスごとに選択可能 ? チームがすべての作業を担当可能 チーム アーキテクチャ プロセス 影響 インフラ DB レイヤ API API アプリケーション Dev Test Ops Dev Test Ops 自動テスト ? ? 依存 影響 影響
- 51. 51 Dolphinプロジェクトのコンセプト ?Dev, Test Ops三位一体の自動化 -パターン指向自動化 専門性を生かし標準パターンを作成 標準パターンを自動化 -セルフサービス 標準パターンの自動化スクリプトの 実行権限をチームメンバーに付与
- 53. 53 Dolphin プロジェクト 特徴 Dev, OpsとTestのワンチーム 課題 サービスごとに非機能要件を実現 コンセプト ?Dev,Test Ops三位一体の自動化 -パターン指向自動化 -セルフサービス
- 54. 54 プロビジョニング サーバ情報 テスト結果 CI システム テスト Cookbook Terraform Files Pull Request Review デプロイメントパイプライン Opsの自動化 开発?テストの 自動化
- 55. 55 CIとInfrastructure ? Automationの連携 プロビジョニング サーバ情報 テスト結果 CI システム テスト Cookbook Terraform Files Pull Request Review OpsDev
- 56. 56 Deployment Pipeline in CI
- 59. 59 パイロットプロジェクトの成果 0 50 100 150 200 旧チーム体制 Dolphin (hours) 99.40%削減 Dev, Ops, Testの三位一体の自動化により それぞれの自動化の効果を最大化 Build Functional Test Provisioning (Deploy) Non-Functional Test Test Report リードタイム
- 61. 61 まとめ
- 63. 63 まとめ?：アラサーエンジニアパターン アラサーエンジニアこそ 組織を変えるチャンス！ ? チームで成果を出した経験と信頼貯金 ? 社内事情と業界のトレンドを熟知 ? マネジメント業務に忙殺されていない → チームを越えたFearless Changeの 基盤が整っている