クックパッドのインフラ責任者が語る、DevOpsを成功させる考え方「迷ったら健全な方を選ぶ」～DevOps Day Tokyo 2013
世界中でDevOpsのイベントとして行われている「DevOps Days」の東京版「DevOps Day Tokyo 2013」が9月28日に開催されました。
国内企業のDevOps実践例から学ぶセッションで登壇したのが、クックパッドの成田一生氏。「迷ったら健全な方」というテーマで、同社におけるDevとOpsの良好な関係を構築する方法論を、Opsチームの責任者の視点で解説しています。内容をダイジェストで紹介しましょう。
迷ったら健全な方
クックパッドの成田一生（なるたいっせい：@mirakui）です。クックパッドでインフラチームを担当しています。
クックパッドはいますごいスピードで新しいサービスを作っているフェーズで、社員の3分の1くらいが新規事業を担当しています。
クックパッドの歴史を振り返ってみると、1997年に創業。創業者の佐野はエンジニアでした。2010年に僕が入社したときにはエンジニアが10人とか20人とかだったと思います。この頃はインフラのチームはまだなくて、得意な人が1人か2人でやっていました。
いまはエンジニアが60人くらいです。そして専用の運用チームがあります。
どんな企業も、最初はエンジニアが一人で開発も運用もやっていますが、人数が増えてくると運用の部署ができて、開発部門などとコミュニケーションをとらなくてはならなくなってきます。クックパッドでは、いまエンジニアの比率はこうなっていて、60人のうち5人がインフラチームです。
組織が大きくなってくると、DevとOpsの関係も変わってきます。今日はその関係がどうなるのか、というところに焦点を当てて話そうと思います。
クックパッドではデプロイを開発者が自分の責任でやる
クックパッドでは、1日に5回から10回デプロイしています。デプロイは伝統的に開発者が自分でやります。Opsはそれを見ているだけです。
ビルドがテストを通ったら、デプロイを行います。デプロイ後に動作確認をして、エラーが起きたらロールバックをするところまで開発者に責任があります。
これは僕が開発したなんちゃってDevOpsツールで、スロークエリなどをモニタします。
承認フローを作るとOpsが権威的になる
ここで失敗の話をします。「リリース日が今日だった」事件（会場笑い）
「そういえばあの案件、リリースいつだっけ？」って僕が開発者にたまたま話しかけたら「今日です」って言われて、「え？ 今日？」って知ったという。
リリース前には、必要な本番サーバのセットアップ、冗長化や監視設定など、やることがあります。だから「今日リリースしたい」と言われても急にはできません。
一方でリリース日というのは「この日にリリースしたい」という事情があって動かせません。
そしてDevは自分でデプロイ可能です。
Opsがリリース日を知らなかったということの本質的な問題は、DevとOpsのあいだのコミュニケーションにあります。
例えば、リリース日を決定するのにOpsの承認が必要、というルールにしたとします。ソースコードがフィクスしてから3営業日必要ですとか。
こう決めれば、問題は起きないかも知れませんが、なにかおかしいですよね。
DevOpsのルールのひとつに、「権威的にならない」というのがあります。Opsの承認が必要、といった承認フローを作り始めるとOpsが権威的になります。
で、どうなるかというと仕事が楽しくなると思っています。実際……いや、実際の話はやめておこうかな（会場爆笑）
承認フローを作るとリリースの責任がOpsに移るわけです。Devの人からはリリース権限がなくなり、Opsに「リリースしていいですか」と聞いて、Opsが「うむ」と言うとリリースになる。そうすると「このサービスはオレがリリースしているんだ」というのがなくなって、仕事も楽しくなくなります。
楽しさがビジネスに大事なのかというと大事で、例えば優秀な人が辞めていったりと、良くないことが起きるわけです。
だから承認フローよりもDevとOpsの間のコミュニケーションで解決できるなら、ぎりぎりまでそうすべき。組織が大きくなってくると、そうしたコミュニケーションだけでは解決できない日がくるのかもしれませんが、それまではやると。
プロダクトのリリースをOpsが止めないようにする、というのが大事だと思っています。
求めるべきは完璧さではなく健全さ
ではクックパッドではどうしているのか。
まず、プロダクトを作り始めるときにDevとOpsでコミュニケーションをして、こういうのを作ります、こういうサーバが必要です、じゃあこういうコードを書いた方がいいんじゃない？ といった話し合いを密にします。
するとサーバの準備などもコードがフィクスしなくてもできて、リリース日には特にやることはないというわけです。
リリース前に完全にフィクスされたコードを出してくださいとか、パフォーマンスに問題のあるコードは許さないとか、そういう完璧さを求めるのは正しいように見えるけれど、なにかおかしい。
DevとかOpsとかの前に必ずBizというのがあって、会社なり組織のビジネスを盛り上げなければなりません。大事なのはお客さんに価値を届けることであって、性能を出すことでもバグをなくすことでもない。
そもそも利用者にとって有益かどうか、だから求めるべきは完璧さではなくて健全さ。
健全さは、意思決定をするのにとてもいい言葉だと思っていて、「これって組織にとって健全だっけ？」と考えるのはいいと思う。
健全な判断って、例えば開発初期からパフォーマンスについて話し合って、このサービス結構アクセスくるのではないかとか、ここにリンクを貼ると誘導でいっぱい来るよねとか、じゃあパフォーマンスのためにKVSを置こうとか。
パフォーマンスの問題なら、サーバを増やして解決するならそれでいいかもしれないし。ユーザーや組織にとって何がいいかを考える。
OpsとDevの歩み寄りのために
Opsがサービスの最新のコードを追うこと。僕は最新のプルリクエストを見ているし、問題があると思えば突っ込みを入れているし、Devのミーティングの議事録も読んでいます。
これからのOpsに求められているのは、ソースコードを読める力だと言い切れます。読めない人は採用しません。サーバで動いているものを理解しないで運用することは許されません。
いざとなったらコードを追いかけて、ここエラーじゃん、という力も大事だと思っています。
一方でDevに求めるのはサーバサイドのセンスです。
パフォーマンスに問題があった場合、DevとOpsが一緒に直していくということをしています。
パフォーマンスに影響なでそうなコードだったら、僕に連絡が来て、僕もコードを見たりします。
組織が大きくなっても健全さを選び続ける
いまはOpsからDevに歩み寄る、というのを意識してやっています。これは僕がもともとDevだったため、Devの目線でOpsをやっていることにも起因しているのではないかと思います。
幸いOpsのメンバーは全員コードを読めるし指摘もできます。
じゃあうまくいっているのではないか、と思われると思いますが、組織は絶えず成長していますし、いまのエンジニア部門が60人から10倍になったらどうなるか。サービスに対してコミットしているチームが100人とか200人になったら、一人あたりの責任が軽くなってしまったり、意思決定する機会が減ってしまう。コミュニケーションも難しくなってしまうかも知れません。
そういうときにも「健全さ」を選び続けることで、DevとOpsの関係をいい状態に保てるのではないかと思います。
人事評価はどうしている？
まとめると、ベンチャーは最初はひとりのエンジニア。でも、ひとりだったらできることでも、人数が増えるとできなくなることも起こります。
そういうときのキーワードが「健全な方を選ぶ」。DevとOpsの間が健全なら組織も健全だし、ビジネスも健全だと思います。
トレードオフにぶつかったら、「この選択は健全だろうか」と自分に問いかける。自分の立場にとって都合がいいことではなくて、組織にとって健全な方を選ぶ、というのが大事だと思います。
（会場から質問）健全な方を選ぶとき、自分に不利な方を選ぶと人事評価などに関わってくると思いますが、評価の仕方やKPI（Key Performance Indicator：重要業績評価指標）などはどうなっているのでしょうか？
（回答）評価も数字だけではやってなくて、例えば性能を80％アップさせたから給料はプラスいくらです、というのはやってなくて、会社にとっていいことができているかとかで決めています。
KPIも部署ごとにやっているところもありますが、ユーザーにとって良いことができているかどうか、という成果をつねに上長との個別面談などで評価しているので、割といい評価ができているのではないかと思っています。
公開されているスライド：Being healthy dev and ops in Cookpad
DevOps Day Tokyo 2013
- 運用を見える化することでDevOpsを前進させよう（前編）～DevOps Day Tokyo 2013
- 運用を見える化することでDevOpsを前進させよう（後編）～DevOps Day Tokyo 2013
- GitHub社内のDevOpsを支えるツール「Boxen」と「Hubot」（前編）～DevOps Day Tokyo 2013
- GitHub社内のDevOpsを支えるツール「Boxen」と「Hubot」（後編）～DevOps Day Tokyo 2013
- クックパッドのインフラ責任者が語る、DevOpsを成功させる考え方「迷ったら健全な方を選ぶ」～DevOps Day Tokyo 2013
DevOps Day Tokyo 2012
あわせて読みたい
