dveloper infrastracture in devlove2015
TRANSCRIPT
Developer InfrastructureWantedly,Inc. Kodai Sakabe @koudaiii
About me
• Kodai Sakabe@koudaiii
• インフラチーム
• 2015 - Wantedly
• 2010 - 2015 TIS
http://qiita.com/advent-calendar/2015/wantedly
http://qiita.com/koudaiii/items/bc89368e1279649f2498
本日お話する内容 「現場のDiff = 文化の違い」
Wantedlyの文化 インフラチームの文化
Wantedly とは
����� �������
自分の寿命が縮むことを願う人々
�� �����������
働くを面白くする ビジネスSNS
月間
60万 ユーザ
Wantedlyの提供するサービス• プロフェッショナル・プロフィール
• 多面的に魅力の伝わるプロフィール
• 会社訪問・インターン探し
• 会社とのマッチング
• ビジョンや人を重視したコンテンツ
• ビジネス用の人脈管理
• ソーシャルグラフ・プロフィール検索
• グループメッセンジSync←New!
• 社内外のプロジェクトで効率的にコラボレーション
• Wantedlyアカウントでご利用いただけます
https://www.wantedly.com/users/310906
プロフェッショナル・プロフィール
(= )
Sync
3
@
利用社数約
10000社以上
http://jp.techcrunch.com/2015/11/09/wantedly-open-api/
http://japan.cnet.com/news/service/35073141/
Wantedly OpenAPI
https://www.wantedly.com/developers/
• for Engineer
• for Engineer
• 60 –
• – Visit ( ) – Sync (SNS ) – Corporate ( )
• – Ruby on Rails
– GitHub pull request
「現場のDiff = 文化の違い」
Wantedly Value
Wantedly value
• OwnerShip
• LeaderShip
• Wantedly Way
コップに水を貯めよう• 失敗は成功の母
• 空のコップがひとつあったとして、何かに失敗して、PDCAサイクルを一度回すと、失敗から学んだ分コップに水が溜まっていくのイメージ
• 最終的に水があふれる時が成功
• その人の姿勢で水の入り具合は変わる
• 年齢や経験値が高まると、コップも大きくなるし、水の量も変わる
• 誰もがOwnerShipとLeaderShipを発揮していこうとする文化
OwnerShip Leadership
Wantedly Way
Wantedly Way
• Code Wins Arguments
• User First
• Simple is Not Easy
Code Wins Arguments
• チームで1時間MTGするならcodeを書いて検証しよう
• エンジニアの場合
• 限られた情報で決断をして、前に進んでいるか
• 仮説をあれこれ考えるより、まずプロトタイプを作って早く学習しているか
• 爆速で動けているか
• 営業の場合
• 自分で良い機能が浮かんだからエンジニアに頼むのではなく
• 企画書を書いて会社を回って、５社程度を確約して、これなら行けると思ったらエンジニアに頼むことが出来るか
User First
• 「もっと速い馬車がほしい」というユーザの声を聞き続けるのではなく、「速く移動したい」というユーザの本質的な欲求に応える行為
• 「言葉 < 行動」
• ユーザーテストで3人間違えるようだったりまごついたりしたら改善して、もう一回試してもらって違う人にも試してもらう
Bad(例: ユーザテスト)
• どうやって●●(機能名)探しますか？？
• どうやって改善にしたらいいですか？
• 仮説がなくて、意見をひたすら聞きまくる
Good(例: ユーザテスト)
• まずは実際に操作している状況をイメージさせる
• シチュエーション・シナリオを描く
• goalを明確に伝える
• 答え合わせポイントを明確に
• 今考えていることを聞く
• 考えてることを口に出してもらう
• 答えをいわない
• 困惑した部分をメモる
• 挙動が不自然だった場合をメモる
Simple is Not Easy
• 作る側が使う側の事を徹底的に考え抜いているか
• 足すよりも引いてフォーカスをしているか
• 上限10%も改善しないような施策をしない(KPIが取りにくいのと、その掛けた工数分でもっと有効な改善はなかったのか？)
• 仮説をたてて、その仮説のコアとなる部分だけにフォーカスできているか
Wantedlyのインフラチーム仕事の考え方と進め方
インフラチームが目指していること
WHY: 自動化/セルフサービス化
• 数年前までエンジニアが少なかった頃
開発チーム インフラ
タスク依頼 作業開発
WHY: 自動化/セルフサービス化
• エンジニアの増加、サービスの増加。。
開発チーム インフラチーム
タスク依頼 作業開発
WHY: 自動化/セルフサービス化
• 依頼のタスクが増加
• 新たなサービスローンチ
• サービスの分割
• 気づいたらインフラチームの作業待ちがボトルネックに。。。
• インフラチームも日々追われる仕事ばかり自分たちのプロジェクトが進められない
どうするか？• 一つは開発チームみたいに人を増やす
• もう一つはインフラチームの力をあげること
• 一人あたりどれくらいのサーバ、どれくらいの種類のアプリ、どれくらいのユーザ数を支えているか
• 例: 1万台のサーバを一万人で見ていたら結局1人1台の力しかない
• 1台のサーバー1人で見ていたものを、100台見れると力上がった
• 2011 年の時点で Facebook のインフラチームはわずか 5 人ほどで 10 万台を超えるサーバを管理
• Wantedlyは後者を目指す
WHAT：何を実現するか？
• Code wins Arguments を可能にするインフラ
• 既存のアプリでも新規アプリでもどんどんデプロイできるように = 変化に強いインフラ
• 変化を避けるインフラではなく、むしろ変更を前提としたインフラ
• 議論や権力ではなく、まず出してみて結果を見る文化を可能にする
WHAT：何を実現するか？
• 「スピード感ある組織にしていくために必要なものは何か」
• ”「文化とインフラだと思う。どんどん前に進もうとする文化と、それを可能にするインフラに投資をすること」” Mark Zuckerberg
HOW：どう実現するか？
• 自動化
• セルフサービス化
HOW:自動化/セルフサービス化
• インフラの自動化(Code化)
開発チームインフラチーム
Pull request開発
開発
インフラを操作できる APIやcode
HOW:自動化/セルフサービス化
• インフラを操作出来るAPIやCodeにする
• 開発チームが自分たちだけで進められる
• インフラチームも開発チームも自分たちの自分たちの仕事に集中出来る
計測方法
• deploy(変更)回数 / 日
• Container数 + ホスト数 + AWS Resources数 / インフラチーム
• 要件を満たしつつインフラコストを下げる
仕事の進め方
• 情熱プロジェクトと痛み分けタスク
• GitHub Issue Driven
• GitHub Flow
情熱プロジェクトと痛み分けタスク• インフラチームのタスクは大きく 2 種類
• やりたいと思っているプロジェクト
• 障害対応や開発チームからの依頼などアドホックに生まれるタスク
Issue Driven
• Issueタイトルは直感的なもの
• 説明には必ず「WHY」と「WHAT」を書く
なぜWHYとWHAT
• 自分以外の人とのコミュニケーションに用いているので他人が理解できなかったら Issue を立てる意味がないし、3ヶ月後の自分は他人。
• 集中して作業している同僚への配慮（非同期コミュニケーション＋情報共有）
• コメントは粒度の細かい「報告」とも考えられる = マイクロマネジメネントも避けられる
• 突然別のタスクをすることになって、あとでその issue に戻ってきても思い出せる => 「なぜそうしたのか？」 意思決定を忘れずに書いておこう
• チームメンバー間で Issue のバトンタッチが可能になる
GitHub Flowとは
• masterブランチのものは何であれデプロイ可能である
• 新しい何かに取り組む際は、説明的な名前のブランチをmasterから作成
• （例: new-oauth2-scopes）
• 作成したブランチにローカルでコミットし、サーバー上の同じ名前のブランチにも定期的に作業内容をpushする
• フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、 プルリクエスト
を作成する
• 他の誰かがレビューをして機能にOKを出してくれたら、あなたはコードをmasterへマージすることができる
• マージをしてmasterへpushしたら、直ちにデプロイをする
GitHub Flow
• シンプルで制約のあるプロセスは、完璧だけど複雑なプロセスに勝る
• RailsだけじゃなくてNginxの設定でも topic branch ->
PR -> merge -> deploy で進める
• 資料作成も基本的にこの方法に従う
• プロジェクトが別でも同じ開発フローなら join しやすい
Github FlowShellScript
インフラチームの指針• 「情熱的に働く手助けをする」という理念は自分たち自身も例外ではありません。
• 自分たちが情熱的に働いてなければ周りの人の力になれるはずもありません。
• インフラチームでは、各自情熱的に取り組めるプロジェクトを必ず 1 つ持つ
• 同時に、事業に貢献する必要もあるため、そのプロジェクトは会社としてやるべきことと、やりたいことが重なる領域を選ぶ
インフラチームの指針• インフラチームはより多くのユーザーに価値を届けられるよう挑戦しています。
• Infrastructure as codeが世の中に定着していますが、そのほとんどが既にあるツールの利用したものが多いと感じています。
• Wantedlyのインフラチームでは、自分たちにとって必要なツールは何か？を考え、必要であればツールの開発行うことをしています。
• ツールの開発ができる現場はそう多くはなく、Wantedlyならではの体験です
ご静聴ありがとうございました