QCon Tokyo 2014 - Virtuous Cycles of Velocity: What I Learned About Going Fast at eBay and Google
•Descargar como PPTX, PDF•
4 recomendaciones•2,004 vistas
eBay and Google operate some of the largest Internet sites on the planet, and each maintains its leadership through continuous innovation in infrastructure and products. While substantially different in their detailed approaches, both organizations sustain their feature velocity through a combination of organizational culture, process, and people. This session will explore how these large-scale sites do it, and will offer some concrete suggestions on how other organizations -- both large and small -- can do the same.
Recomendados
Recomendados
Más contenido relacionado
Similar a QCon Tokyo 2014 - Virtuous Cycles of Velocity: What I Learned About Going Fast at eBay and Google
Similar a QCon Tokyo 2014 - Virtuous Cycles of Velocity: What I Learned About Going Fast at eBay and Google (20)
Más de Randy Shoup
Más de Randy Shoup (20)
QCon Tokyo 2014 - Virtuous Cycles of Velocity: What I Learned About Going Fast at eBay and Google
- 1. Virtuous Cycles of Velocity What I Learned About Going Fast at eBay and Google ベロシティ(速度)の好循環： 速く進むことの重要性 に関して、GoogleとeBayで学んだこと Randy Shoup @randyshoup linkedin.com/in/randyshoup
- 2. Background 背景 CTO at KIXEYE • Real-time strategy games for web and mobile Webとモバイル用のリアルタイム戦略ゲーム Director of Engineering for Google App Engine • World’s largest Platform-as-a-Service 世界最大のプラットフォーム・アズア サービス Chief Engineer at eBay • Multiple generations of eBay’s real-time search infrastructure ｅＢａｙのリアルタイムサーチ・インフラ数世代分
- 3. Why Are Organizations Slow? なぜ組織はスローなのか Organizational Culture 組織とカルチャー Process プロセス People ピープル
- 4. Why Are Organizations Slow? Organizational Culture 組織とカルチャー Process People
- 5. Organization: Quality over Quantity 組織：量よりも質 Whole user / player experience ユーザー/プレーヤの全体経験 • Think holistically about the full end-to-end experience of the user ユーザの最初から最後までの全経験を包括的に考えろ • UX, functionality, performance, bugs, etc. ユーザエクスピリエンス，機能、性能、バグ、その他 Less is more 小さいことはよいことだ • Solve 100% of one problem rather than 50% of two ２つとも５０％よりも、１つの問題を１００％解くべし • Users prefer one great feature instead of two partially- completed features ユーザは中途半端な2機能よりも、凄い機能１つの方がよい
- 6. Organization: Culture of Learning 組織：学習するカルチャー Learn from mistakes and improve 失敗から学んで改善せよ • What did you do -> What did you learn 何をしたか 何を学んだか • Take emotion and personalization out of it そこから感情や個人的な思いを掴まえろ Encourage iteration and velocity 繰り返しとスピードを重視せよ • “Failure is not falling down but refusing to get back up” – Theodore Roosevelt 「失敗とは倒れること自体ではなく、起き上がるのを 拒むこと」 セオドア・ルーズベルト
- 7. Google Blame-Free Post- Mortems グーグルの責めない振り返り Post-mortem After Every Incident 全インシデント毎に振り返りを • Document exactly what happened 何か起こったのかを正確に文書化 • What went right 正しく進めたこと • What went wrong 誤ってしまったこと Open and Honest Discussion オープンで正直な議論 • What contributed to the incident? 何がそのインシデントの原因だったのか • Engineers will compete to take responsibility (!) エンジニアは先を争って責任を取ろうとする
- 8. Google Blame-Free Post- Mortems グーグルの責めない振り返り Action Items アクション・アイテム • How will we change process, technology, documentation, etc. どのようにしてプロセス、技術、文書化 等を変えるのか • How could we have automated the problems away? どのように自動化して問題を取り除けるのか • How could we have diagnosed more quickly? どのようにしてもっと早く問題を見つけられるのか • How could we have restored service more quickly? どのようにしてもっと早くサービスを回復できるのか Follow up (!) それらをきちんとフォローせよ
- 9. Virtuous Cycle of Improvement 改善の好循環 Honesty 正直 Learn 学習 Improve 改善 Results 結果
- 10. Organization: Service Teams 組織： サービスチーム • Small, focused teams 目標の明確な小チーム • Single service or set of related services １つまたは関連する少数のサービス • Minimal, well-defined “interface” 最小限の明確に定義された「インターフェース」 • Clear “contract” between teams チーム間の明解な「契約」 • Functionality 機能性 • Service levels and performance サービスレベルと性能
- 11. Google Services グーグルサービス • All engineering groups organized into “services” すべてのエンジニアリングチームは「サービス群」の単 位で組織化される • Gmail, App Engine, Bigtable, etc. • Self-sufficient and autonomous 自己充足的かつ自律的 • Layered on one another 階層化されている Result: Very small teams achieve great things 結果 極小のチーム群が偉大な成果を成し遂げる
- 12. Organization: Ownership Culture 組織： 所有形態のカルチャー • Give teams autonomy チームに自律性を • Freedom to choose technology, methodology ,working environment 技術、手法、ツール環境を選択する自由 • Responsibility for the results of those choices これらの選択によって生じた結果に対する責任 • Hold them accountable for *results* 彼らに『結果』に関する説明責任を持たせなさい • Give a team a goal, not a solution 各チームにはソリューションではなくゴールを与えなさい • Let team own the best way to achieve the goal そのゴールを達成するベストな方法は各チームに所有を 任せなさい
- 13. KIXEYE Service Chassis KIXEYEのサービスの胴体（シャーシ） • Goal: Produce a “chassis” for building scalable game services ゴール： スケールするゲームサービス構築の胴体の製造 • Minimal resources, minimal direction 最小限のリソース、最小限の指示 • 3 people x 1 month • Consider building on open source projects オープンソースプロジェクトとして構築することを検討 • Results • Exceeded expectations: chassis, transport, servcie template, autoscaled deployment, etc. 期待を超える成果： シャーシ、トランスポート、サービス・テンプレート、自 動スケールするディプロイ • 15 minutes from no code to running service in AWS (!) コードのない状態から15分でＡＷＳ上にサービスを運用開始できる！ • Plan to open-source several parts of this work この成果物の一部のオープンソース化を計画中
- 14. Virtuous Cycle of Ownership 所有形態の好循環 Autonomy 自律 Motivation 意欲 Efficiency 効率 Results 結果
- 15. Organization: Collaboration 組織： コラボレーション • One team across engineering, product, operations, etc. エンジニアリング、製品、運用、…を通して1チーム • Solve problems instead of pointing fingers 問題を指摘するのではなく問題を解決する
- 16. Google Co-Location グーグルのコロケーション Multiple Organizations 複数組織 • Engineering エンジニアリング • Product 製品 • Operations 運用 • Support サポート • Different reporting structures to different VPs 異なる組織長への異なるリポートライン構造 Virtual Team with Single Goal 単一ゴールの仮想チーム • All work to make Google App Engine successful 全員、Google App Engine 成功のために働く • Coworkers are “Us”, not “Them” 小ワーカーはみな「私たち」であって、「彼ら」ではない • Never occurred to us that other organizations were not “our team” 他の組織は「我がチーム」ではない、といった問題は決して起こらない
- 17. Why Are Organizations Slow? なぜ組織はスローなのか Organizational Culture Process プロセス People
- 18. Process: Experimentation プロセス： 実験 *Engineer* successes エンジニア の成功 • Constant iteration 定常的な反復 • Launch is only the first step ローンチは最初の1歩に過ぎない • A|B Testing needs to be a core competence ＡＢ テストを中核的に実施する必要性 Many small experiments sum to big wins 多くの小さな実験の積み重ねが大きな成功に繋がる
- 19. eBay Machine-Learned Ranking eBayの機械学習によるランキング Ranking function for search results サーチ結果のランキング機能 • Which item should appear 1st, 10th, 100th, 1000th 1st, 10th, 100th, 1000th番目にどのアイテムを表示すべきか • Before: small number of hand-tuned factors 以前： 手作業でチューニングした数個の因子 • Goal: Thousands of factors 目標： 何千もの因子 Experimentation Process 実験プロセス • Predictive models: query->view, view->purchase, etc. 予測モデル： クエリ->ビュー、ビュー->購入 など • Hundreds of parallel A|B tests 何百もの並列ＡＢテスト • Full year of steady, incremental improvements 1年間の徹底した段階的改善プロセスによる安定化 Result: 2% increase in eBay revenue (!) eBay収入2%向上
- 20. Virtuous Cycle of Experimentation 実験の好循環 Experiment 実験 Learn 学習 Improve 改善 Results 結果
- 21. Process: Quality Discipline プロセス： クオリティの原則 “Quality is a Priority-0 feature” 『クオリティは優先順位0の機能である』 Automated Tests help you go faster 自動テストは速く進むヘルプになる • Tests have your back テストはあなたの背中を支えてくれる • Confidence to break things, refactor mercilessly 既存物を壊して容赦なくリファクタリングする自信を与えてくれる • Catch bugs earlier, fail faster バグをより早くキャッチし、より速く失敗することを可能にする Faster to run on solid ground than on quicksand 砂地よりしっかりとした地面の方が速く走れる
- 22. Process: Institutionalize Quality プロセス： クオリティの制度化 Development Practices プラクティスの開発 • Code reviews コードレビュー • Continuous Testing 継続的テスト • Continuous Integration 継続的インテグレーション Quality Automation クオリティのオートメーション • Automated testing frameworks 自動テストフレームワーク • Canary releases to production 製品の試験リリース “Make it easy to do the right thing, and hard to do the wrong thing” 『正しいことが簡単にできるようにせよ、そして誤ったことをす るのをむずかしくせよ』
- 23. Google Engineering Discipline グーグルのエンジニアリング原則 Solid Development Practices 安定した開発プラクティス • Code reviews before submission サブミット前にコードレビューを • Automated tests for everything すべてに自動化テストを • Single logical source repository 単一の論理的ソースリポジトリ Result: Internal Open Source Model 結果： 内部的なオープンソースモデル • Not “here is a bug report” 「はい、バグレポート」ではない • Instead “here is the bug; here are the code changes; here is the test that verifies the changes” そうではなく、「これはバグで、これはコード変更で、これはその変更を検証 するテストです」というモデル
- 24. Virtuous Cycle of Quality クオリティの好循環 Engineering Discipline エンジニア リング原則 Solid Foundation 安定した 基礎 Faster and Better より速く より良く Results 結果
- 25. Process: Manage Technical Debt プロセス： 技術的負債の管理 Make Explicit Tradeoffs 明示的トレードオフ • Triangle: date vs. quality vs. features トライアングル： 期限 ｖｓ 品質 ｖｓ 機能 • When you choose date and features, you implicitly choose a level of quality 期限と機能を選んだとき、品質レベルも暗黙に選んだことになる Manage Your Debt あなたの負債の管理 • Plan for how and when you will pay it off いつどうやって負債を返すかを計画せよ • Maintain a sustainable level of debt 持続可能な負債のレベルを維持せよ “Don’t have time to do it right” ? 正しくやってる時間がない？ • WRONG – Don’t have time to do it twice (!) 間違い ― 間違えることで2度もやる時間を取ってしまう方が問 題！
- 26. Vicious Cycle of Technical Debt 技術的負債の悪循環 Technical Debt 技術的負債 “No time to do it right” 『正しく行う 時間ない』 Quick-and- dirty やっつけ仕事
- 27. Virtuous Cycle of Technical Investment 技術的投資の好循環 Invest 投資 Solid Foundation 安定した基礎 Faster and Better より速くより良く Results 結果
- 28. Why Are Organizations Slow? なぜ組織はスローなのか Organizational Culture Process People ピープル
- 29. People: Hire and Retain the Best ピープル：良き人材を雇用し続ける Hire ‘A’ Players Ａ人材を雇用する • In creative disciplines, top performers are 10x more productive (!) 創造的分野の原則では、トップ人材の生産性は通常人の10 倍を超える Confidence 信頼の伝搬 • A players bring A players Ａ人材はＡ人材をもたらす • B players bring C players Ｂ人材はＣ人材をもたらす
- 30. Google Hiring グーグルの採用 Goal: Only hire top talent トップタレントのみ雇用 • False negatives are OK; false positives are not 誤認識は(良いモノの排除)よしとする、偽陽性(悪いモノの受容)はダメ Process プロセス • Famously challenging interviews 有名な挑戦的インタビュー • Very detailed interviewer feedback 非常に詳細なインタビュアーからのフィードバック • Hiring committee decides whether to hire 採用委員会が雇用するか否かを判断 • Separately assign person to group 個別に個人をグループにアサインする Results: Highly talented and engaged employees 結果： 才能を持った熱意のある従業員
- 31. People: Respect People ピープル： 人を尊敬する People are not interchangeable 人は交換可能でない • Different skills, interests, capabilities 異なるスキル、関心、能力 • Create a Symphony, not a Factory 交響楽団を創るのであり、工場を作るわけではない Most valuable and irreplaceable asset もっとも価値があって置き換えできない資産 • Treat people with care and respect 人を気遣いと尊敬をもって遇すること • If the company values its people, people will provide value to the company もし会社がその人の価値を評価するなら、人はその会社に価値をもたら すだろう
- 32. eBay “Train Seats” 「列車席」 eBay’s development process (circa 2006) 開発プロセス • Design and estimate project 設計と見積りプロジェクト (“Train Seat” == 2 engineer-weeks) 列車席＝＝2エンジニア週 • Assign engineers from common pool to implement tasks タスクの 実装に共通プールからエンジニアをアサイン • Designer does not implement; implementers do not design 設計 者は実装せず、実装者は設計しない Many Problems 多くの問題 • Engineers treated as interchangeable “cogs” エンジニアは交換可能な歯車の歯として扱われている • No regard for skill, interest, experience スキル、関心、経験に対する敬意を払わない • No pride of ownership in task implementation タスクの実装におけるオーナーシップのプライドがない • No long-term ownership of codebase コードベースの長期的なオーナーシップがない
- 33. Vicious Cycle of People 人の問題の悪循環 Hire ‘B’ / ‘C’ players BCクラスの 人材の採用 Mediocre results 平凡な結果 People leave 人が離れて いく Need to hire more もっと採用 する必要
- 34. Virtuous Cycle of People 人の問題の好循環 Hire ‘A’ Players Ａクラス人材 の採用 Treat Well 大切に扱う Keep and Retain ずっと残っ てくれる Results よい成果