Being healthy dev and ops in cookpad - Issei Naruta

552 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
552
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Being healthy dev and ops in cookpad - Issei Naruta

  1. 1. being-healthy-dev-and-ops 迷ったら健全な方 クックパッドのDevとOps 成田 一生 2013/09/28
  2. 2. About me
  3. 3. なるた いっせい 成田 一生 @mirakui photo by sora_h VP Infrastructure at Cookpad Inc. 2008 ヤフー 新卒入社 メールサービスのバックエンド開発 2010 クックパッド入社 サービス開発エンジニアとして入社後、 開発基盤チームを経てインフラチームに
  4. 4. About Cookpad
  5. 5. Our Phase
  6. 6. 2013年4月期 決算説明会資料 より https://info.cookpad.com/wp-content/uploads/13.4_s.pdf
  7. 7. 歴史
  8. 8. 1997 創業 エンジニアの人数: 1998 1999 2000 2001 2002 2003 2004 2005 3 2006 2007 東証マザーズ上場 2008 Coldfusion → Ruby on Rails へ移行 2009 2010 10~20 成田 JOIN 2011 東証一部へ上場変更 2012 2013 現在 約60 1
  9. 9. エンジニアの規模 1人 1人が開発も運用も全部やる 10人 うち1 2人が開発しつつ運用 このあたりで JOIN 50人 数人規模の運用チーム登場 いまここ 100人 運用チームの拡大・専門別の細分化
  10. 10. 2013 Dev サービス開発系エンジニア (約40人) Dev 技術部エンジニア (12人) インフラ部 エンジニア (5人) Ops
  11. 11. 今日の話 • 組織が大きくなってきた • Dev と Ops の関係は どうなっていくのか? DevOps Dev Ops
  12. 12. デプロイ
  13. 13. デプロイ 5~10 deploy / day
  14. 14. デプロイルール(一部) • CI をパスしたリビジョンのみ デプロイしてよい • デプロイはコードを push した開発者自身が 行う • • 営業時間内のみデプロイ可能 デプロイ後は開発者が動作確認し、 不具合を見つけたらすぐにロールバックする
  15. 15. 失敗
  16. 16. リリース日が今日だった • Dev「リリース今日です」 • Ops「!?」
  17. 17. リリース前の Ops の作業 • 本番サーバセットアップ • 監視設定 • キャパシティ測定 • 冗長化 • などなど…
  18. 18. Dev の事情 • ソースコードは リリース直前まで fix しない • 「リリース日」は重要 • Dev がデプロイ可能 =(技術的には)勝手にリリース可能 • 非公開→ユーザ限定公開→全体公開
  19. 19. ✔source code fix developing setup servers Dev Ops release ✔ fixtures fix
  20. 20. 本質的な問題 Dev - Ops 間コミュニケーション
  21. 21. どうするか? • リリース日の決定に Ops の承認が 必要なルールにする? • Ops「ソースコード fix してから リリースまでに3営業日必要です」??
  22. 22. 権威的にならない
  23. 23. 承認フローの増加 • 個人のオーナーシップが減衰 仕事が楽しくなくなる • 承認を通すテクニックや政治が発生 • コミュニケーションで解決できる部分は ギリギリまでそうするべき
  24. 24. プロダクトのリリースを Ops が止めない
  25. 25. BAD ✔source code fix developing setup servers Dev Ops release ✔ fixtures fix
  26. 26. GOOD ✔ fixtures fix ✔source code fix Dev Ops release developing communication setup servers
  27. 27. 完璧さを追求しない
  28. 28. Ops が完璧さを求めると… • リリース前に、完全に fix された ソースコードでキャパシティ計測したい • パフォーマンスに問題のあるコードを 一切許したくない
  29. 29. Customers Corporation Dev Ops
  30. 30. Dev とか Ops とかの前に 組織や顧客(ユーザー)にとって 有益な判断かどうか大事
  31. 31. 求めるべきは 「完璧さ」ではなく「健全さ」
  32. 32. 健全さのために 時には Ops にとって不利益な選択を許す ➡ 素晴らしいアーキテクチャ vs リリース日 ➡ サーバ増やして解決 vs コスト ➡ オペレーション完全自動化 vs 人件費
  33. 33. Not 完璧 but 健全 リリース前、完全に fix された ソースコードでキャパシティ計測したい ➡ 開発初期からパフォーマンスについて話し合う ➡ キャパシティ計測するのに十分な レベルのコードを早めに出してもらう ようにコミュニケーション
  34. 34. Not 完璧 but 健全 パフォーマンスに問題のあるコードを 一切許したくない ➡ サーバ増やして解決するなら それでいい場合もあるのでは? ユーザ/組織に利益がある方は?
  35. 35. 歩み寄りのために
  36. 36. Dev のことをよく理解する • Ops がサービスの最新の ソースコードを追う • Dev 同士の議論に耳を傾ける • 開発の初期から輪に入れてもらう
  37. 37. Ops に求められるもの サーバで動いているものを ソースコードレベルで理解する ➡ ミドルウェア ➡ アプリケーション
  38. 38. Dev に求めるもの • サーバサイドのセンス • そのコードに大量のトラフィックが 来たらどうなるか • キャッシュなど
  39. 39. 例: パフォーマンスが出ない × Ops が黙ってチューニング ○ Dev と Ops 一緒に直していく
  40. 40. パフォーマンスに影響が出そうなコード 必ず pull-request で mention してもらう というルール
  41. 41. Ops もサービスのコードに pull-request を出す
  42. 42. わりとできていること Ops → Dev の理解 ➡ 元 Dev が Ops を率いている ➡ Ops が全員コード読み書きできる ➡ Dev への口出し ソースコードレベルでのつっこみ
  43. 43. 今後の課題
  44. 44. 組織がさらに巨大になると エンジニア個人が自分で 意思決定する機会が少なくなっていく? ➡ 人が増えると自分より上の視点を 持ちにくくなる ➡ ルールやフローを信じて疑わない状態に陥りやすい ➡ 現場の裁量を維持できるかが
  45. 45. おわりに
  46. 46. ベンチャー企業の DevOps • はじめはみんな DevOps • 組織が拡大すると、それまで当たり前 だったことがやりにくくなる • Dev とOps が離れていくのを どこまで食い止められるか • は「健全な方を選択し続けること」 • Dev Ops 間の健全さ=組織の健全さ
  47. 47. 迷ったら健全な方 • • 完璧さではなく健全さ トレードオフにぶつかったら 「この選択は健全だろうか?」 と自分に問いかける • • 時には泥臭い方法を選ぶ 自分の立場にとっての都合のよさではなく、 全体にとって健全な方を選ぶ
  48. 48. PR
  49. 49. We re hiring [en, ja] https://info.cookpad.com/jobs/
  50. 50. Thank you for listening

×