三位一体の自動化で壊せ devとopsの壁~アラサーエンジニアの挑戦~
TRANSCRIPT
三位一体の自動化で壊せDevとOpsの壁“アラサーエンジニアの挑戦” Feb. 19, 2016 ハッシュタグ: #devsumiC セッションID: 19-C-5 Kotaro Ogino, Takaaki Furukawa Rakuten, inc.
4
お持ち帰り頂きたいこと:DevTestOps自動化パターン
Context -共通化されたアーキテクチャ -レイヤーごとのチーム -サービスの堅実な成長
Problem -スタートアップ的なスピード感を阻害 -組織を越えた協働の不足
Solution -開発、テスト、運用三位一体の自動化
インフラ DB レイヤ
API API
アプリケーション
自動テスト
アーキテクチャ上の レイヤーとチーム
6
Fearless Change
マリリン・マンズ, リンダ・ライジング (著) 川口恭伸 (監訳), 楽天株式会社
・エバンジェリスト(1) ・外部のお墨付き(12) ・勉強会(25) ・恐れは無用(46) など
8
2010 - 2012 (新人時代)
業務内容: ・サーチプラットフォームの開発 ・開発・テスト・運用すべてやっていた ・CassandraやSolrのテストやパッチ ・テストの自動化も
思い出: ・NoSQLは品質特性が大事 ・しかしまだまだ未成熟な時代 ・僕自身たくさんバグを作った(笑)
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
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) 組織にもたらす効果をマネージメント層が理解できる言葉で
17
2014 (挫折)
挫折の内容 ・組織的な評価 ・勉強会のROI
考えたこと ・ヘッドハンターに相談 → 真剣に転職を考える ・人事や執行役員に相談 → 自分の組織を作れと怒られる ・勉強会コミュニティの先輩に相談
→勉強会は”準備できている事が大事”
結論 ・部署移動
18
2014 (部署移動)
パターン:正式な推進担当者(29) ぼっチームでFearless Changeを再始動
異動して変わったこと ・正式な自動化担当部署 ・担当するプロジェクトが1から20に
しかし実質的に何もない状態
自動化要素 ある? やる気 ◯ Jenkins たくさん テスト自動化ツール × アジャイルな文化 × テストエンジニアの自動化スキル ×
20
2015 (テストエンジニアのスキルと地位向上)
http://kokotatata.hatenablog.com/entry/2015/05/06/190029
http://kokotatata.hatenablog.com/entry/2015/05/23/214208
楽天テクノロジーカンファレンス
システムテスト自動化カンファレンス
パターン:グループのアイデンティティー(13) ブログに色々書いたり、カンファレンスで発表してみたり
22
2015 (チーム作り)
課題 ・1プロジェクトから20プロジェクトへ ・テストだけでなく、開発や運用も自動化
結果 ・1名から22名に! ・Dev、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
楽天のプライベートクラウドの歴史
27
2010 - 2012
• 手順書の作業コストやリスクの説明 • Chef, Puppet, Saltstackを比較し、Chefを採用 • 最初はchef-soloでスモールスタート • 定型作業などの優先度の高いものから順に
パターン:エバンジェリスト (1) “新しいアイデアを組織に導入し始めるなら、 情熱を共有するために出来る限りの事をしよう”
28
2010 - 2012
アクション • サーバ構築作業への構成管理ツール導入
結果 • 定型作業にかかる工数削減!
課題 • 仮想化によって増加するサーバ台数 • 手順書によるマニュアル作業(コピペマシン)
30
2013 - 2014
§ 運用部署向け社内勉強会 § 荻野さんが開催している社内勉強会で発表。
パターン:種をまく(22) “機会のある時に資料(種)をもっていって、 それらを見せる(蒔く)ようにしよう”
運用 運用
サーバ構築専門グループ
開発
運用 運用
開発 開発
開発 開発
開発 開発
開発 開発
開発 開発
開発 開発
開発 開発
開発
32
• 忙しくて学習できない • スクリプトで自動化した方が早い • 導入実績がまだまだ足りない • サーバ台数とサーバの種類が多い • Chefだけではすべてのインフラ作業をコード化で
きない
2013 - 2014
パターン:懐疑派代表(44) “懐疑派代表の意見を活用しよう”
34
2014 - 2015
課題 • Chefでカバーできない部分のコード化 • Infrastructure as Codeの導入実績
アクション • Chefとは別の構成管理ツール導入 • Devとのコラボレーション
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とのコラボレーション
40
組織がDevOpsな文化になるために
・もちろんトップの戦略、 意思決定やサポートは重要
・それと同じくらい、変化に対して 「現場が準備出来ていること」 が重要 → 現場の準備のパターン 「アラサーエンジニアパターン」
41
アラサーエンジニアパターン
・ チームで成果を出した経験と信頼貯金 ・ 社内事情と業界のトレンドを熟知 ・ マネジメント業務に忙殺されていない → チームを越えたFearless Changeの 基盤が整っている
44
ビジョン:サービスの成長のためのDev, TestとOps
SCM
時間
サービスの 成長度
デプロイ デプロイ デプロイ
SCM
テスト テスト テスト
ソースコード ソースコード ソースコード Dev
Test テストケース テストケース テストケース
SCM
デリバリー
Ops 構成情報 構成情報 構成情報
デリバリー デリバリー
45
ウェブサービスの持続可能な成長に関する非機能要件の例
カテゴリ 例
Deliverability ・1週間に1度リリース可能であること
Operability ・ログ監視システムより5分以内に 障害の切り分けが可能なこと
Testability ・1週間に1度、評価データを 更新可能なこと
46
DevTestOps 三位一体の自動化
Dev Ops Test
システム
開発
フィーチャー (機能
モジュール)
自動テスト モジュール
運用自動化 モジュール
非機能要件の テスタビリティや
オペラビリティを担当
開発 開発
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
自動テスト
? ?
依存
影響
影響
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
59
パイロットプロジェクトの成果
0
50
100
150
200
旧チーム体制 Dolphin
(hours)
99.40%削減
Dev, Ops, Testの三位一体の自動化により それぞれの自動化の効果を最大化
Build Functional Test
Provisioning (Deploy)
Non-Functional Test Test Report
リードタイム
62
まとめ❶:DevTestOps自動化パターン
Context -共通化されたアーキテクチャ -レイヤーごとのチーム -サービスの堅実な成長
Problem -スタートアップ的なスピード感を阻害 -組織を越えた協働の不足
Solution -開発、テスト、運用三位一体の自動化
63
まとめ❷:アラサーエンジニアパターン
アラサーエンジニアこそ 組織を変えるチャンス!
・ チームで成果を出した経験と信頼貯金 ・ 社内事情と業界のトレンドを熟知 ・ マネジメント業務に忙殺されていない → チームを越えたFearless Changeの 基盤が整っている