三位一体の自動化で壊せDevとOpsの壁“アラサーエンジニアの挑戦” Feb. 19, 2016 ハッシュタグ: #devsumiC セッションID: 19-C-5 Kotaro Ogino, Takaaki Furukawa Rakuten, inc.

2

楽天のDevとOps

Dev Ops

越えられない壁

3

コンウェイの法則：チーム体制とアーキテクチャ

インフラ

DB

API API アプリケーション

自動テスト

アーキテクチャー レイヤーごとに共通化

チーム レイヤーに対応した チーム

4

お持ち帰り頂きたいこと：DevTestOps自動化パターン

Context -共通化されたアーキテクチャ -レイヤーごとのチーム -サービスの堅実な成長

Problem -スタートアップ的なスピード感を阻害 -組織を越えた協働の不足

Solution -開発、テスト、運用三位一体の自動化

インフラ DB レイヤ

API API

アプリケーション

自動テスト

アーキテクチャ上の レイヤーとチーム

5

DevとOpsのエンジニアそれぞれが この壁を自動化によって壊す Fearless Changeのストーリー

6

Fearless Change

マリリン・マンズ, リンダ・ライジング　（著） 川口恭伸　（監訳）, 楽天株式会社

・エバンジェリスト(1) ・外部のお墨付き(12) ・勉強会(25) ・恐れは無用(46) など

7

Fearless Change Side Dev

8

2010 - 2012 (新人時代)

業務内容： ・サーチプラットフォームの開発 ・開発・テスト・運用すべてやっていた ・CassandraやSolrのテストやパッチ ・テストの自動化も

思い出： ・NoSQLは品質特性が大事 ・しかしまだまだ未成熟な時代 ・僕自身たくさんバグを作った（笑）

9

2013 (Fearless Changeの始まり)

課題 ・開発の片手間でのテスト自動化 ・信頼性・再現性などに問題

アクション ・テスト自動化に専任。勉強会など ・本業以外の学習

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

2013 (本業以外の学習)

XP祭り クラウドとの出会い

DevLOVE

パターン：種をまく(22) 本業以外の学習

12

2013 (Fearless Changeの始まり)

課題 ・開発の片手間でのテスト自動化 ・信頼性・再現性などに問題

結果 ・仲間ができた ・テスト自動化以外の知見

アクション ・テスト自動化に専任。勉強会など ・本業以外の学習

13

2014 (個人の価値から組織の価値へ)

課題 ・エンジニア個人ではなく組織にもたらす価値 ・勉強会のROI

アクション ・仕事の成果のシンポジウムでの発表 ・Fearless Changeの継続的な共有 ・部署移動

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

2014 (Fearless Changeの継続的な共有)

パターン：体験談の共有(32)　著名人を招く(27) インフラ自動化、運用効率化などのFearless Changeの共有

16

2014

挫折

17

2014 (挫折)

挫折の内容 ・組織的な評価 ・勉強会のROI

考えたこと ・ヘッドハンターに相談 　→ 真剣に転職を考える ・人事や執行役員に相談 → 自分の組織を作れと怒られる ・勉強会コミュニティの先輩に相談

　 →勉強会は”準備できている事が大事”

結論 ・部署移動

18

2014 (部署移動)

パターン：正式な推進担当者(29) ぼっチームでFearless Changeを再始動

異動して変わったこと ・正式な自動化担当部署 ・担当するプロジェクトが1から20に

しかし実質的に何もない状態

自動化要素 ある？ やる気 ◯ Jenkins たくさん テスト自動化ツール × アジャイルな文化 × テストエンジニアの自動化スキル ×

19

2015 (チーム作り)

課題 ・1プロジェクトから20プロジェクトへ ・テストだけでなく、開発や運用も自動化

アクション ・テストエンジニアのスキルと地位向上 ・チームを越える

20

2015 (テストエンジニアのスキルと地位向上)

http://kokotatata.hatenablog.com/entry/2015/05/06/190029

http://kokotatata.hatenablog.com/entry/2015/05/23/214208

楽天テクノロジーカンファレンス

システムテスト自動化カンファレンス

パターン：グループのアイデンティティー(13) ブログに色々書いたり、カンファレンスで発表してみたり

21

2015 （チームを越える）

パターン：みんなを巻き込む(33) DevやOpsを巻き込んで欲しいとの依頼が色々きた

22

2015 (チーム作り)

課題 ・1プロジェクトから20プロジェクトへ ・テストだけでなく、開発や運用も自動化

結果 ・1名から22名に！ ・Dev、Opsとの自動化の統合

アクション ・テストエンジニアのスキルと地位向上 ・チームを越える

23

Fearless Change Side Ops

24

•  楽天のインフラ §  プライベートクラウド主流の文化 §  サーバ台数: 30,000+ §  管理する部署: 400+

•  私 §  サーバプロビジョニング専門グループに所属

•  OSインストール・初期設定 •  MWの初期設定 •  DNSレコード登録 •  etc

楽天のインフラの特徴と私

インフラ DB

API API

アプリケーション

自動テスト

ここ

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

2010 - 2012

課題 •  仮想化によって増加するサーバ台数 •  手順書によるマニュアル作業（コピペマシン）

アクション •  サーバ構築作業への構成管理ツール導入

27

2010 - 2012

•  手順書の作業コストやリスクの説明 •  Chef, Puppet, Saltstackを比較し、Chefを採用 •  最初はchef-soloでスモールスタート •  定型作業などの優先度の高いものから順に

パターン：エバンジェリスト　（1） “新しいアイデアを組織に導入し始めるなら、 情熱を共有するために出来る限りの事をしよう”

28

2010 - 2012

アクション •  サーバ構築作業への構成管理ツール導入

結果 •  定型作業にかかる工数削減！

課題 •  仮想化によって増加するサーバ台数 •  手順書によるマニュアル作業（コピペマシン）

29

2013 - 2014

課題 •  他部署にChefの導入を推進

アクション •  社内勉強会を開く

30

2013 - 2014

§  運用部署向け社内勉強会 §  荻野さんが開催している社内勉強会で発表。

パターン：種をまく（22） “機会のある時に資料(種)をもっていって、 それらを見せる(蒔く)ようにしよう”

運用 運用

サーバ構築専門グループ

開発

運用 運用

開発 開発

開発 開発

開発 開発

開発 開発

開発 開発

開発 開発

開発 開発

開発

31

2014

挫折

32

•  忙しくて学習できない •  スクリプトで自動化した方が早い •  導入実績がまだまだ足りない •  サーバ台数とサーバの種類が多い •  Chefだけではすべてのインフラ作業をコード化で

きない

2013 - 2014

パターン：懐疑派代表（44） “懐疑派代表の意見を活用しよう”

33

2013 - 2014

課題 •  他部署にChefの導入を推進

アクション •  社内勉強会を開く

結果 •  あまり浸透せず・・・。

34

2014 - 2015

課題 •  Chefでカバーできない部分のコード化 •  Infrastructure as Codeの導入実績

アクション •  Chefとは別の構成管理ツール導入 •  Devとのコラボレーション

35

2014 - 2015

36

2014 - 2015

パターン：ステップバイステップ（3） “目標に向かって一歩一歩進めていく”

ChefとTerraformで コードによるインフラ管理が可能に •  Chef: サーバの内側 •  Terraform: サーバの外側

•  Terraformのプラグイン開発 •  VMware vSphere providerはOSSで公

開、Terraform本家にマージされる

37

Infrastructure as Codeの重要性

パターン：テイラーメイド（26） “組織のニーズに合わせる”

Ops •  組織の業務内容をChef CookbookとTerraform

Moduleで抽象化 Dev •  要件に合わせてCookbookやModuleを利用 •  インフラ知識がなくてもインフラ作業が可能に

38

2014 - 2015

結果 •  インフラのコード管理の実績ができた •  抽象化されたコードは組織の壁を越える

課題 •  Chefでカバーできない部分のコード化 •  Infrastructure as Codeの導入実績

アクション •  Chefとは別の構成管理ツール導入 •  Devとのコラボレーション

39

Fearless Change DevOps

40

組織がDevOpsな文化になるために

・もちろんトップの戦略、 意思決定やサポートは重要

・それと同じくらい、変化に対して 　「現場が準備出来ていること」 　が重要 →　現場の準備のパターン 　　「アラサーエンジニアパターン」

41

アラサーエンジニアパターン

・ チームで成果を出した経験と信頼貯金 ・ 社内事情と業界のトレンドを熟知 ・ マネジメント業務に忙殺されていない → チームを越えたFearless Changeの 基盤が整っている

42

Dolphin Project:Dev Ops Testのワンチーム

Dev Ops Test Automation

Business Values

Business Requirements

43

Dolphin プロジェクト

特徴 Dev, OpsとTestのワンチーム

課題 コンセプト

44

ビジョン：サービスの成長のためのDev, TestとOps

SCM

時間

サービスの 成長度

デプロイ デプロイ デプロイ

SCM

テスト テスト テスト

ソースコード ソースコード ソースコード Dev

Test テストケース テストケース テストケース

SCM

デリバリー

Ops 構成情報 構成情報 構成情報

デリバリー デリバリー

45

ウェブサービスの持続可能な成長に関する非機能要件の例

カテゴリ 例

Deliverability ・１週間に１度リリース可能であること

Operability ・ログ監視システムより５分以内に 障害の切り分けが可能なこと

Testability ・１週間に１度、評価データを 　更新可能なこと

46

DevTestOps 三位一体の自動化

Dev Ops Test

システム

開発

フィーチャー （機能

モジュール）

自動テスト モジュール

運用自動化 モジュール

非機能要件の テスタビリティや

オペラビリティを担当

開発 開発

47

コンウェイの法則：チーム体制とアーキテクチャ

インフラ

DB

API API アプリケーション

自動テスト

アーキテクチャー レイヤーごとに共通化

チーム レイヤーに対応した チーム

48

Dolphinの課題

Dev Ops Test

役割で分割されたチーム

影響

モノリシックなアーキテクチャ

インフラ DB レイヤ

API API

アプリケーション

依存

ウォータースクラムフォール？

Dev Test Ops

Dev

役割で分割されたチームの問題点 ・ ビジネスの非機能要件とは無関係に 組織構造によりアーキテクチャやプロセスに制約 ・ 役割を越えた作業に交渉や承認が必要

Test Ops

チーム アーキテクチャ 影響 プロセス

自動テスト

影響

影響

49

Dolphinで実現したいこと

サービスごとのワンチーム ビジネスの非機能要件

サービスごとに分割されたチームの利点 ・ ビジネスの非機能要件に最適なアーキテクチャや プロセスをサービスごとに選択可能 ・ チームがすべての作業を担当可能

チーム アーキテクチャ プロセス 影響

インフラ DB レイヤ

API API

アプリケーション Dev Test Ops

Dev Test Ops

自動テスト

? ?

依存

影響

影響

50

Dolphin プロジェクト

特徴 Dev, OpsとTestのワンチーム

課題 サービスごとに非機能要件を実現 コンセプト

51

Dolphinプロジェクトのコンセプト

・Dev, Test Ops三位一体の自動化

-パターン指向自動化　　 　　　　　　　

　　 専門性を生かし標準パターンを作成 　　 標準パターンを自動化

-セルフサービス 　　 標準パターンの自動化スクリプトの 　　 実行権限をチームメンバーに付与

52

パターン指向自動化とセルフサービス

Dev

Ops

Test

Ops

Ops

Ops

Ops

煩雑な交渉

Dev

Ops

Test

専門家 標準パターン

自動化スクリプト

ワンクリック!

権限の不足している サービスチーム

十分な権限のある サービスチーム

専門家

専門家

専門家

53

Dolphin プロジェクト

特徴 Dev, OpsとTestのワンチーム

課題 サービスごとに非機能要件を実現 コンセプト ・Dev,Test Ops三位一体の自動化 -パターン指向自動化 -セルフサービス

54

プロビジョニング

サーバ情報 テスト結果

CI システム

テスト

Cookbook

Terraform Files

Pull Request Review

デプロイメントパイプライン

Opsの自動化

開発〜テストの 自動化

55

CIとInfrastructure Automationの連携

プロビジョニング

サーバ情報 テスト結果

CI システム

テスト

Cookbook

Terraform Files

Pull Request Review

Ops Dev

56

Deployment Pipeline in CI

57

新人研修で開発したパフォーマンステスト自動化パターン

58

パイロットプロジェクトでの成果

59

パイロットプロジェクトの成果

0

50

100

150

200

旧チーム体制 Dolphin

(hours)

99.40%削減

Dev, Ops, Testの三位一体の自動化により それぞれの自動化の効果を最大化

Build Functional Test

Provisioning (Deploy)

Non-Functional Test Test Report

リードタイム

60

そしてDevとOpsの 壁がなくなった・・・

61

まとめ

62

まとめ❶：DevTestOps自動化パターン

Context -共通化されたアーキテクチャ -レイヤーごとのチーム -サービスの堅実な成長

Problem -スタートアップ的なスピード感を阻害 -組織を越えた協働の不足

Solution -開発、テスト、運用三位一体の自動化

63

まとめ❷：アラサーエンジニアパターン

アラサーエンジニアこそ 組織を変えるチャンス！

・ チームで成果を出した経験と信頼貯金 ・ 社内事情と業界のトレンドを熟知 ・ マネジメント業務に忙殺されていない → チームを越えたFearless Changeの 基盤が整っている

64

DevOps エンジニア募集中！！！