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年４月期 決算説明会資料 より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