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