三位一体の自動化で壊せ DevとOpsの壁～アラサーエンジニアの挑戦～

三位一体の自動化で壊せ DevとOpsの壁～アラサーエンジニアの挑戦～

1. 1. 三位一体の自動化で壊せ DevとOpsの壁
 “アラサーエンジニアの挑戦” Feb. 19, 2016 ハッシュタグ: #devsumiC セッションID: 19-C-5 Kotaro Ogino, Takaaki Furukawa Rakuten, inc.
2. 2. 2 楽天のDevとOps Dev Ops 越えられない壁
3. 3. 3 コンウェイの法則：チーム体制とアーキテクチャ インフラ DB API API アプリケーション 自動テスト アーキテクチャー レイヤーごとに共通化 チーム レイヤーに対応した チーム
4. 4. 4 お持ち帰り頂きたいこと：DevTestOps自動化パターン Context -共通化されたアーキテクチャ -レイヤーごとのチーム -サービスの堅実な成長 Problem -スタートアップ的なスピード感を阻害 -組織を越えた協働の不足 Solution -開発、テスト、運用三位一体の自動化 インフラ DB レイヤ API API アプリケーション 自動テスト アーキテクチャ上の レイヤーとチーム
5. 5. 5 DevとOpsのエンジニアそれぞれが この壁を自動化によって壊す Fearless Changeのストーリー
6. 6. 6 Fearless Change マリリン・マンズ, リンダ・ライジング　（著） 川口恭伸　（監訳）, 楽天株式会社 ・エバンジェリスト(1) ・外部のお墨付き(12) ・勉強会(25) ・恐れは無用(46) など
7. 7. 7 Fearless Change Side Dev
8. 8. 8 2010 - 2012 (新人時代) 業務内容： ・サーチプラットフォームの開発 ・開発・テスト・運用すべてやっていた ・CassandraやSolrのテストやパッチ ・テストの自動化も 思い出： ・NoSQLは品質特性が大事 ・しかしまだまだ未成熟な時代 ・僕自身たくさんバグを作った（笑）
9. 9. 9 2013 (Fearless Changeの始まり) 課題 ・開発の片手間でのテスト自動化 ・信頼性・再現性などに問題 アクション ・テスト自動化に専任。勉強会など ・本業以外の学習
10. 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
11. 11. 11 2013 (本業以外の学習) XP祭り クラウドとの出会い DevLOVE パターン：種をまく(22) 本業以外の学習
12. 12. 12 2013 (Fearless Changeの始まり) 課題 ・開発の片手間でのテスト自動化 ・信頼性・再現性などに問題 結果 ・仲間ができた ・テスト自動化以外の知見 アクション ・テスト自動化に専任。勉強会など ・本業以外の学習
13. 13. 13 2014 (個人の価値から組織の価値へ) 課題 ・エンジニア個人ではなく組織にもたらす価値 ・勉強会のROI アクション ・仕事の成果のシンポジウムでの発表 ・Fearless Changeの継続的な共有 ・部署移動
14. 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) 組織にもたらす効果をマネージメント層が理解できる言葉で
15. 15. 15 2014 (Fearless Changeの継続的な共有) パターン：体験談の共有(32)　著名人を招く(27) インフラ自動化、運用効率化などのFearless Changeの共有
16. 16. 16 2014 挫折
17. 17. 17 2014 (挫折) 挫折の内容 ・組織的な評価 ・勉強会のROI 考えたこと ・ヘッドハンターに相談 　→ 真剣に転職を考える ・人事や執行役員に相談 → 自分の組織を作れと怒られる ・勉強会コミュニティの先輩に相談 　 →勉強会は”準備できている事が大事” 結論 ・部署移動
18. 18. 18 2014 (部署移動) パターン：正式な推進担当者(29) ぼっチームでFearless Changeを再始動 異動して変わったこと ・正式な自動化担当部署 ・担当するプロジェクトが1から20に しかし実質的に何もない状態 自動化要素 ある？ やる気 ◯ Jenkins たくさん テスト自動化ツール × アジャイルな文化 × テストエンジニアの自動化スキル ×
19. 19. 19 2015 (チーム作り) 課題 ・1プロジェクトから20プロジェクトへ ・テストだけでなく、開発や運用も自動化 アクション ・テストエンジニアのスキルと地位向上 ・チームを越える
20. 20. 20 2015 (テストエンジニアのスキルと地位向上) http://kokotatata.hatenablog.com/entry/2015/05/06/190029 http://kokotatata.hatenablog.com/entry/2015/05/23/214208 楽天テクノロジーカンファレンス システムテスト自動化カンファレンス パターン：グループのアイデンティティー(13) ブログに色々書いたり、カンファレンスで発表してみたり
21. 21. 21 2015 （チームを越える） パターン：みんなを巻き込む(33) DevやOpsを巻き込んで欲しいとの依頼が色々きた
22. 22. 22 2015 (チーム作り) 課題 ・1プロジェクトから20プロジェクトへ ・テストだけでなく、開発や運用も自動化 結果 ・1名から22名に！ ・Dev、Opsとの自動化の統合 アクション ・テストエンジニアのスキルと地位向上 ・チームを越える
23. 23. 23 Fearless Change Side Ops
24. 24. 24 •  楽天のインフラ §  プライベートクラウド主流の文化 §  サーバ台数: 30,000+ §  管理する部署: 400+ •  私 §  サーバプロビジョニング専門グループに所属 •  OSインストール・初期設定 •  MWの初期設定 •  DNSレコード登録 •  etc 楽天のインフラの特徴と私 インフラ DB API API アプリケーション 自動テスト ここ
25. 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. 26 2010 - 2012 課題 •  仮想化によって増加するサーバ台数 •  手順書によるマニュアル作業（コピペマシン） アクション •  サーバ構築作業への構成管理ツール導入
27. 27. 27 2010 - 2012 •  手順書の作業コストやリスクの説明 •  Chef, Puppet, Saltstackを比較し、Chefを採用 •  最初はchef-soloでスモールスタート •  定型作業などの優先度の高いものから順に パターン：エバンジェリスト　（1） “新しいアイデアを組織に導入し始めるなら、 情熱を共有するために出来る限りの事をしよう”
28. 28. 28 2010 - 2012 アクション •  サーバ構築作業への構成管理ツール導入 結果 •  定型作業にかかる工数削減！ 課題 •  仮想化によって増加するサーバ台数 •  手順書によるマニュアル作業（コピペマシン）
29. 29. 29 2013 - 2014 課題 •  他部署にChefの導入を推進 アクション •  社内勉強会を開く
30. 30. 30 2013 - 2014 §  運用部署向け社内勉強会 §  荻野さんが開催している社内勉強会で発表。 パターン：種をまく（22） “機会のある時に資料(種)をもっていって、 それらを見せる(蒔く)ようにしよう” 運用 運用 サーバ構築専門グループ 開発 運用 運用 開発 開発 開発 開発 開発 開発 開発 開発 開発 開発 開発 開発 開発 開発 開発
31. 31. 31 2014 挫折
32. 32. 32 •  忙しくて学習できない •  スクリプトで自動化した方が早い •  導入実績がまだまだ足りない •  サーバ台数とサーバの種類が多い •  Chefだけではすべてのインフラ作業をコード化で きない 2013 - 2014 パターン：懐疑派代表（44） “懐疑派代表の意見を活用しよう”
33. 33. 33 2013 - 2014 課題 •  他部署にChefの導入を推進 アクション •  社内勉強会を開く 結果 •  あまり浸透せず・・・。
34. 34. 34 2014 - 2015 課題 •  Chefでカバーできない部分のコード化 •  Infrastructure as Codeの導入実績 アクション •  Chefとは別の構成管理ツール導入 •  Devとのコラボレーション
35. 35. 35 2014 - 2015
36. 36. 36 2014 - 2015 パターン：ステップバイステップ（3） “目標に向かって一歩一歩進めていく” ChefとTerraformで コードによるインフラ管理が可能に •  Chef: サーバの内側 •  Terraform: サーバの外側 •  Terraformのプラグイン開発 •  VMware vSphere providerはOSSで公 開、Terraform本家にマージされる
37. 37. 37 Infrastructure as Codeの重要性 パターン：テイラーメイド（26） “組織のニーズに合わせる” Ops •  組織の業務内容をChef CookbookとTerraform Moduleで抽象化 Dev •  要件に合わせてCookbookやModuleを利用 •  インフラ知識がなくてもインフラ作業が可能に
38. 38. 38 2014 - 2015 結果 •  インフラのコード管理の実績ができた •  抽象化されたコードは組織の壁を越える 課題 •  Chefでカバーできない部分のコード化 •  Infrastructure as Codeの導入実績 アクション •  Chefとは別の構成管理ツール導入 •  Devとのコラボレーション
39. 39. 39 Fearless Change DevOps
40. 40. 40 組織がDevOpsな文化になるために ・もちろんトップの戦略、 意思決定やサポートは重要 ・それと同じくらい、変化に対して 　「現場が準備出来ていること」 　が重要 →　現場の準備のパターン 　　「アラサーエンジニアパターン」
41. 41. 41 アラサーエンジニアパターン ・ チームで成果を出した経験と信頼貯金 ・ 社内事情と業界のトレンドを熟知 ・ マネジメント業務に忙殺されていない → チームを越えたFearless Changeの 基盤が整っている
42. 42. 42 Dolphin Project:Dev Ops Testのワンチーム Dev Ops Test Automation Business Values Business Requirements
43. 43. 43 Dolphin プロジェクト 特徴 Dev, OpsとTestのワンチーム 課題 コンセプト
44. 44. 44 ビジョン：サービスの成長のための
 Dev, TestとOps SCM 時間 サービスの 成長度 デプロイ デプロイ デプロイ SCM テスト テスト テスト ソースコードソースコードソースコード Dev Test テストケーステストケーステストケース SCM デリバリー Ops 構成情報構成情報構成情報 デリバリー デリバリー
45. 45. 45 ウェブサービスの持続可能な成長に関する
 非機能要件の例 カテゴリ 例 Deliverability ・１週間に１度リリース可能であること Operability ・ログ監視システムより５分以内に 障害の切り分けが可能なこと Testability ・１週間に１度、評価データを 　更新可能なこと
46. 46. 46 DevTestOps 三位一体の自動化 Dev OpsTest システム 開発 フィーチャー （機能 モジュール） 自動テスト モジュール 運用自動化 モジュール 非機能要件の テスタビリティや オペラビリティを担当 開発 開発
47. 47. 47 コンウェイの法則：
 チーム体制とアーキテクチャ インフラ DB API API アプリケーション 自動テスト アーキテクチャー レイヤーごとに共通化 チーム レイヤーに対応した チーム
48. 48. 48 Dolphinの課題 Dev OpsTest 役割で分割されたチーム 影響 モノリシックなアーキテクチャ インフラ DB レイヤ API API アプリケーション 依存 ウォータースクラムフォール？ Dev Test Ops Dev 役割で分割されたチームの問題点 ・ ビジネスの非機能要件とは無関係に 組織構造によりアーキテクチャやプロセスに制約 ・ 役割を越えた作業に交渉や承認が必要 Test Ops チーム アーキテクチャ 影響 プロセス 自動テスト 影響 影響
49. 49. 49 Dolphinで実現したいこと サービスごとのワンチーム ビジネスの非機能要件 サービスごとに分割されたチームの利点 ・ ビジネスの非機能要件に最適なアーキテクチャや プロセスをサービスごとに選択可能 ・ チームがすべての作業を担当可能 チーム アーキテクチャ プロセス 影響 インフラ DB レイヤ API API アプリケーション Dev Test Ops Dev Test Ops 自動テスト ? ? 依存 影響 影響
50. 50. 50 Dolphin プロジェクト 特徴 Dev, OpsとTestのワンチーム 課題 サービスごとに非機能要件を実現 コンセプト
51. 51. 51 Dolphinプロジェクトのコンセプト ・Dev, Test Ops三位一体の自動化 -パターン指向自動化　　 　　　 　　 専門性を生かし標準パターンを作成 　　 標準パターンを自動化 -セルフサービス 　　 標準パターンの自動化スクリプトの 　　 実行権限をチームメンバーに付与
52. 52. 52 パターン指向自動化とセルフサービス Dev Ops Test Ops Ops Ops Ops 煩雑な交渉 Dev Ops Test 専門家 標準パターン 自動化スクリプト ワンクリック! 権限の不足している サービスチーム 十分な権限のある サービスチーム 専門家 専門家 専門家
53. 53. 53 Dolphin プロジェクト 特徴 Dev, OpsとTestのワンチーム 課題 サービスごとに非機能要件を実現 コンセプト ・Dev,Test Ops三位一体の自動化 -パターン指向自動化 -セルフサービス
54. 54. 54 プロビジョニング サーバ情報 テスト結果 CI システム テスト Cookbook Terraform Files Pull Request Review デプロイメントパイプライン Opsの自動化 開発〜テストの 自動化
55. 55. 55 CIとInfrastructure 
 Automationの連携 プロビジョニング サーバ情報 テスト結果 CI システム テスト Cookbook Terraform Files Pull Request Review OpsDev
56. 56. 56 Deployment Pipeline in CI
57. 57. 57 新人研修で開発した
 パフォーマンステスト自動化パターン
58. 58. 58 パイロットプロジェクトでの成果
59. 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. 60. 60 そしてDevとOpsの 壁がなくなった・・・
61. 61. 61 まとめ
62. 62. 62 まとめ❶：DevTestOps自動化パターン Context -共通化されたアーキテクチャ -レイヤーごとのチーム -サービスの堅実な成長 Problem -スタートアップ的なスピード感を阻害 -組織を越えた協働の不足 Solution -開発、テスト、運用三位一体の自動化
63. 63. 63 まとめ❷：アラサーエンジニアパターン アラサーエンジニアこそ 組織を変えるチャンス！ ・ チームで成果を出した経験と信頼貯金 ・ 社内事情と業界のトレンドを熟知 ・ マネジメント業務に忙殺されていない → チームを越えたFearless Changeの 基盤が整っている
64. 64. 64 DevOps エンジニア募集中！！！