Developers Summit2014に参加してきた #devsumi
http://event.shoeisha.jp/devsumi/20140213/
デブサミ2014の1日目に参加してきたので、その講演メモになります。
■グリーにおけるChef導入事例:荒井 良太さん〔グリー〕
まず会場に質問
- Chefを知っている→ほとんどの人が知っている
- Chefを使った事がある→半数くらい
- Chefを仕事で使った事がある→1/3くらい
- Chefはまだ仕事で使えていないのが現状
Chefとは
- サーバ構築、更新を自動化するツール
- サーバのあるべき姿をRuyで書くとセットアップしてくれる
- 何度実行時手も同じサーバになる
- Chef社のOSS
今までのよくある光景
- サーバ運用者とプロダクト担当者がいる
- プロダクト担当者がサーバください等の依頼を運用者に依頼
- 運用者が手順書に沿ってセットアップ
- 終わったら担当者に報告
- 何か依頼する度に↑の繰り返し(ルーチンワーク)
- これを自動化する
導入背景
- 非効率(ルーチンワーク)
- オペレーションミスの危険(自動化により安定運用を目指す)
- リードタイム(サーバのデリバリーを素早く行う）
Before Chef
導入方針
- 新規サーバをChefで構築
- 既存サーバをChefで更新はリスク
- 既存サーバ管理システムを利用
- Chefで構築していないサーバも平行運用
- 運用スクリプトがサーバ管理システムに依存
- 運用手順がサーバ管理システムに依存
- 既存のツール、スクリプトが動く状態で移行する
- Chef SoloとChef Serverをどっち使うか
- サーバの台数で決める
- 複数台あるのでChef Serverを選択
- 結果的にはChef ServerをやめてChef Soloにした
Chef Serverをやめた理由
- 単一障害点になる
- 冗長構成はサポートされてない
- サーバ管理が重複
- Chef Serverはサーバ管理の役割
- 既存のサーバ管理システムと役割が重複
- 運用
Chef Solo + Chef Bridge
- Chef Bridge
- GREE Chef Client
- Chef Soloのラッパー
- Chef Bridgeから必要なものを取得(ノード、クックブック、ロール)
- Chef Soloを実行
- 自動テスト
クックブック
Chef入門
- Chefは学習コストが高い
- Chef使いを育てる必要がある
クックブックの開発
■テストを書く
- serverspec
- ブラックボックステスト
- サーバのあるべき状態を記述して状態になっているかテスト
- Test Kitchen
- ブラックボックステスト
- テスト対象の環境を記述してその環境でテストする
- serverspecでは出来ないため
- chefspec
- Foodcritic
- Lint
- クックブックのLintツール
- クックブックに統一感を持たせる
- ルールに従っていないと警告がでる
■なぜテストを書くのか
- 開発を後押しする
- TDD
- Chefを実行 sshでログイン ちゃんと設定されているか確認 クックブックを修正 繰り返しを防ぐ
- レグレッションを防ぐ
- ドキュメント代わり
- 本番サーバの構築テスト
- テストが遅い問題は継続改修中..
■GitHub PR
- PRで変更を投げる
- masterに直接pushしない
- WIP
- PR上で議論
- チャットに通知
- JenkinsでCI
- デプロイまで行う
ノード
- どのクックブック、ロールを利用するか
- ノード設定のバリデーション
- ノードの共通化
- 複数のノードで共通設定がでてくる
- YAMLで書く
運用、障害発生
- Chef以前
- scriptコマンドやscreenでログを取る
- wikiにコピペ
- Chef
- Report Handlerを利用してログを送信
- Fluentdに保存
公式クックブック使いこなすのが大変とか、Chef-Serverやめた背景とかうんうんと頷く機会が多かったですね、どこも直面する問題は一緒。。。
個人的にはChefのテスト周りがとても興味深い話でした。Chefのテスト書くという概念がなかったのですが、話聞いていて確かにテストが一番必要なツールだなと、話にあがった方法は是非試してみたいと思います。(そしていい加減仕事で使いたい)
※発表資料がすでにアップされていました。 https://speakerdeck.com/ryotarai/guriniokeruchefdao-ru-shi-li-ji-cun-falsezi-chan-wohuo-kasixin-siiji-shu-wodao-ru-suru
■フロントエンドエンジニア（仮）～え、ちょっとフロントやること多すぎじゃない！？～:石本 光司さん〔サイバーエージェント〕
https://gist.github.com/t32k/8934355
発表資料がすでにあがってました。
http://rmurphey.com/blog/2012/04/12/a-baseline-for-front-end-developers/ http://slid.es/passy/yeoman/fullscreen#/1/1
確かにフロントエンドエンジニアはやる事が多く、かつそのためのツールもたくさんありますね。 最終的にはやはりGruntに落ち着くのかなーという印象でした。
■新卒エンジニア研修ですべきことできること:関口 亮一さん[ディー・エヌ・エー]
世にある新卒研修
- 必要な情報を浴びせる
- 新卒てんぱる
- 研修終わり、突撃
- 受け入れ側；負担多すぎ
- 研修ガー研修ガーと研修のせいになる
現状の整理
- 未経験者がほとんど
- 出来る人は既に出来る
- 講師は現場エンジニア3人 + 外部講師数名
教える事
- もう無限にある
- 絞ったとしても教えるの難しい
やれる範囲でやるようにしてみる
- できてない
- やる前に投げてる
- 講師：トレンドの技術や知識とかよくわからん
現場のニーズの変化
- サーバサイドだけやってればいい時代じゃない
- あれもこれも
- もっともっと成長してくれないと
- 研修内容がニーズから乖離
研修自体の問題を整理
- 技術レベルが求める水準に達していない
- いいから引き上げる
- 現場エンジニアが直に教える
- 今まで研修で棚上げしていたことをちゃんと教える
- 諦めの連鎖を断ち切る
- 研修でやってきた知識が現場で生きない
- 現場で教える時間も暇もないからしっかりやって
- 勝手に学ぶような習慣をつける
- 問題を正しく認識し、立ち向かえる力
- 目先の技術より観察眼、応用力を養う
- 斜め上に進まないようにする力
- 技術や知識は水準、本質、応用力の3本柱
研修の目標
- 自走出来るエンジニア
具体的な研修フェーズ
- 座学
- 企画
- 設計
- 実装
各フェーズでのレビュー
- 1回1時間 各フェーズ毎に各ステップ5-7回
- 新卒と講師の1on1
- 研修の重要ポイント
レビュー風景
- ホワイトボード
- ディスプレイ
- レビューブース
- アウトプット
- インプット
レビューで大事な事
- 正しく論破する
- 指摘の仕方や1人1人変える
- 対面
- レビューでの出来事や内容を記録
進捗と成長度合い
- フェーズが進んでくると差がでてくる
- 未知の領域での対処法
- 論理の構築
- 弱点の克服
成長に早めに気づいてあげる
- 成長を促すために手を打つ
- より合う形に教え方を調整
- 強みを延ばして弱点を克服するスタイル
成長を正しく計測する
- 進捗、レビュー、日報、何気ない会話の内容
- 全て記録
- プログラムの筆記テスト
- 1hのデイリーミィーテイングで活用
- 徹底したデータ化とPDCA
成長に気がつけたら
- 改善を促す
- 最初は自力で
- 改善してこなさそうであれば手助け(フォローアップ)
フォローアップ
- 毎日、隔日で30分間の講師との1on1
- プログラミングのハマり解消
- 問題解決の手法トレーニング
- 講師のトレーニング
- 成長促進のための徹底した振り返り
- KPT
- 日々のKを蓄積
- 成長を実感
- モチベーションアップ
フォローアップで大事な事
- 良い所を延ばし良くない所を改善
- ひとりひとり丁寧に
- 一筋縄ではいかないのでひたすら工夫
- 改善したらフォローアップを卒業
- 最終的に自信をつけさせる
フォローアップのすすめ
- フォローアップを受けた人は急激に成長する人が多かった
- 時間が許すなら全員やってよかった
- ただ自分の弱い面と向き合うのは辛い
- 無理強いは良くない、一人一人きちんと合ったやり方で進める
まとめ
- 組織のニーズに応えるのも大事だが変化の激しいニーズに応えるのも大変
- 基本的な技術力、マインド向上は非常に役立っている
- 新しい技術も本質的な知識、問題定義力が備わっているので吸収が早い
- 人にフォーカスする事で人材の柔軟性を高めたら組織にフィットしやすくなる
- 組織の型にはめて人材を育成するより変化に強い
- 変化の激しい会社や組織に特に有効な研修
- 実際の技術的な研修内容 http://www.slideshare.net/DaisukeTamada/perl-26371335
今日一番聞きたかった講演、現場のニーズに応えるとか研修のせいにされるとかうんうんととても頷きましたw。
私が研修で一番気にしている事は研修を受ける人たちが自分の成長とモチベーションを感じる事、そういう意味ではレビューやフォローアップはとても良さそうな印象でした。(コストがかかるという問題はありますが)
■さくらインターネットブース
講演とは別にブース出展がされていて、さくらインターネットでちょっとさくらのクラウドについて色々お話を聞きました。
私はプレイベートで以前さくらVPS→さくらのクラウドに安いという理由で移行したのですが、AWSと違いサーバがあるだけで(停止していても)課金対象になるため辞めたというのを話してみました。さくらの方もそこは問い合わせも多く、さくらインターネット自体も考えているとの事です。実際、AWSと同じような課金体制にするという話もあるとの事でした。
また、私がさくらのクラウドで良いなと思ったのがコントロールパネルの扱い易さで、そこはユーザからも一番評価されているとのことでした。個人的にはさくらインターネットさんのサポート対応は素晴らしいと思ってるので今後に期待しています。
この後にも「何故クックパッドのサービス開発は日々進化しているのか」とか面白そうな講演があったのですが私用のため途中退場、、。明日も組織作りやアプリ周りの講演があり面白そうですが、私はこちらに参加してきます。
発表資料は基本的にアップされるようで、アップされたらデブサミのサイトで告知されるとの事です。
追記(2014/02/13 22:00)
いくつか講演資料がアップされていました。
また、CodeZineさんにブログを掲載してもらったようです、ありがとうございます、ありがとうございます。
