読者です 読者をやめる 読者になる 読者になる

ほわいとぼーど

ぷろぐらまのメモ帳

はじめるDevOps [2013/07/19 19:00-21:30]に参加してきました。

DevOps 勉強会

http://atnd.org/events/41286
ハッシュタグ #init_devops

基本は資料が公開されるはずなのでピックアップ的に気になった内容&感想を。


・「DevOps の今とこれから」 伊藤 直也さん

 DevOpsの経緯や現状、そしてこれからの展望を非常にわかりやすく説明されていました。
 スライド眺めただけでも結構おなか一杯になれそうですね。
 ・属人性→特権→ボトルネック化→排除→自動化
 ・継続的デリバリー(以後CD):ビジネスを良くする為に試行錯誤で頻繁にリリースしたい。
 ・冪等性大事。スクリプトを2回流すと・・・
 ・レシピをGit Commitすることでサーバの状態を共有できる。
  インフラもVersion管理。プルリクも出来る。見える化
 ・インフラをコード化したらテストも書いてCIも。
 ・Chefにもバッドノウハウが溜まってきた⇔Ansibleの登場
 ・AnsibleはSimple、コマンド実行も内包、拡張性、楽、Yamlで言語非依存
 ・次はインフラのサービス化? インフラをサービスとしてCIする未来
  「Strider CD」というのが出てきたっぽい。

 説明が非常にわかりやすくて背景含めて色々クリアになりました。
 継続的デリバリーの意義をしっかり捉えると価値も明確になる気がする。
 Web系だと特にCDに対する価値が利益に直結しやすいので導入進んでる印象ですが、
 エンプラ寄りだと「とりあえず自動化~」「とりあえずChef~」となって効果がイマイチに
 なりかねないのでその辺りはしっかり考えてみたいです。
 まぁ導入方向だったら試してみて、でもいいのかもしれない。
 導入を掲げつつアレコレ難癖付けられちゃうなら、導入意義の明確化は大事な気がする。
 naoyaさんの自身の経験からサーバはインフラチームしか触れない縛り環境での
 DevとOpsの対立(OpsはDefensiveになりやすい)を仰っていて、
 やっぱりサービス(ビジネス)軸からの視点は欲しいですよね。
 規模大きい部署だと開発者個々は思っていてもなかなか動けなかったりする。


・「おさえておきたいDevOpsのはじめかた」 浅沼 敬さん(株式会社じげん)

 DevOpsに取り組んで2ヶ月たった現状までの道のり導入例。
 ひたすら「あるある」すぎてこういうシェアはありがたいです。
 ・動機:サービス多数、個人依存、バージョンばらばら、コアな部分ほどレガシー化
   →そんな中で開発速度を上げたい
 ・準備:課題と対策ロードマップ→役割分担→全社プレゼン
   →インパクトがモチベーションアップに大事。
   →モデルPJ作り
 ・GitからGitHubへ プルリクでレビュー 他の人からも見える→見える化
 ・レガシーにしない為にテストを書く
 ・インフラもCIしよう
 ・プルリクでJenkins(naoyaさん参照)
 ・とりあえず決めたルール
  ・ソフトウェア毎にレシピ分割してroleでまとめる
  ・インストール完了をチェックするテストをServerspecで。
  ・テストはnode種別毎ではなくレシピ単位をつなげてJenkinsで一括で。
  ・FluentdもChefで入れた
  ・デプロイにはCapistranoも使っている。設定ファイル配布。区分けは迷い中。
 ・課題
  ・プルリクの属人化→ローテーション性に。
  ・rspecテストをどこまで書くか→事例を積み上げるしかない。始めることが重要。
  ・進捗の見える化→成果を報告する→経営層にも。
  ・進捗の管理表を作った。 →使ってね!

 マイルストーンをしっかり作ってるあたりが非常に参考になります。
 実際、2ヶ月で浸透って早いですよね。準備大事というお話。
 そして実施したら開発者から大絶賛だったという所も良い話。
 多かれ少なかれ困ってる人はいるはずで、そこにどうリーチするかとか、
 しっかり考えられていると思いました。
 まともな開発者的には間違いなく幸せになれるはずなんですが、
 色んなしがらみ怖い怖い・・・
 
 
・「Amazon EC2 + Vagrant 」 吉羽龍太郎さん(アマゾンデータサービスジャパン株式会社)

 Vagrantを使い倒した人ならではの便利な技術集。
 ・吉羽さん「皆さん元気出してますか?改善するような人達が元気ないと困りますよ!」
  伊藤さん「『これからはじめるDevOps』だから、まだですよ」
  冒頭から始まる漫才。レベルたけぇ。。
 ・SCRUM BOOT CAMP買ってね(宣伝)
 ・システム利用割合は実は無駄が多い、ウォーターフォールは時間がかかりすぎる
   →早く投入して回収、何度もデプロイ繰り返すことでお金の使い方が改善
   →そのためにはFeature単位でリリース(&テスト)→人手無理
 ・ツールと文化の両方が必要
 ・Vagrant
  ・ソフトの構成要素が増える→間違えやすい
  ・実行環境依存
  ・ちょっとしたテスト
 ・Vewee/Packer→AMI作れる(ビルド)
 ・他Plugin一杯紹介、、、は後で資料で見る予定
  ・ChefServerでもProvisioner使える
 ・何回実行してもいいように →パッケージがレポジトリ無くなった、とかもわかる。CI
 ・ローカルと同じテスト環境→更にお客さんにそのままデモれる

 DevOpsの例えが秀逸でした。スベらないAWSの人。
 (https://twitter.com/mkimu04/status/358188918128119808/photo/1 お借りしました)
 naoyaさんも言ってたけど何故CDしたいか、っていう説明が明確。
 ツールだけじゃなくて文化も必要だよっていうのは今回の登壇者全員から多かれ少なかれ感じたし、
 DevOpsの根幹であるというのが本当によくわかりました。
 後半はツール紹介なのでメモさぼりry
 資料公開されるはず。気になったPlugin何個かあったので公開されないと死ぬ。
 Vagrantで繰り返しっていうのはまさに最近感じています。
 Chef導入目指している人はVagrantと併せて開発しやすい環境をあらかじめ用意してあげると
 開発者は面白がって楽しくレシピ書いてくれると思う。
 そしてServerspecもセットにしておけばテストも・・・!


・「インフラチームが無い会社でのインフラ運用 」 田中 勇輔さん(株式会社アカツキ)

 ・アカツキはインフラ担当がいない
 ・人数も少ないので運用の効率化が必要
 ・当初はシェルで自動化して場合分けしまくった黒歴史
 ・NFSがSPOFに!
 ・CookbookはForkよりOverride?形式で。元をいじるとbugメンテで困る。
 ・反映(トリガー)はまだ手動
 ・アプリデプロイはCapistranoをEC2タグにRole設定して。AWSタグ便利。
 ・監視はプロセス監視God、NewRelic。Web系はNewRelic入れとけば幸せになれる。
 ・AutoScalingがAWSうまくいかず自作した。
   →Chariot PVでScaling 「気が向いたら公開します」
 ・コラボレーション(DevOpsを推進するため)
  ・GitHub 見える化。プルリク
  ・Redmine 意識、課題の共有
  ・HipChat GitHub連携できる
 ・文化
  ・keep changing
  ・Do it yourself
  ・文章化して共有しモチべUP(微妙に、らしい)
  ・共有言語Ruby
  ・小さく始める(まずはChef soloから)そして成功体験を共有する

 これも資料待ち(ぉぃ
 田中さんの発表は実体験そのままでの生々しい話でそういった意味でも
 メモよりも発表自体に集中して聞いてました。
 2010年から2013年の年毎に押し寄せる問題・黒歴史が「人間らしい生活」になって
 更に「良い感じ(本人談)」になっていくのが聞いていても楽しかったです。
 そして会社自体の理念が良い方向に根付いているのが素晴らしいと思います。
 Chariotとか作っちゃう技術力もすごいです。


全体の感想ですがこの勉強会は内容が濃くてものすごく充実してました。
ここで聞いた内容が先日のJTFの内容の一部ともリンクして「なるほどね」と納得したりも。
印象的だったのは複数の登壇者が同じような事を多数発言していて、
・DevOpsムーブメントの由来となるCDの意義
・ツールだけでなく文化が大事
見える化して共有、属人性の排除
特にCDについてはアジャイルとかリーンスタートアップではよく語られますが、
naoyaさんの説明は非常にわかりやすかったです。
Twitterやブログで見慣れてるせいで何故か一人だけローマ字:D)

ちょっと興奮していたせいかアンケートに謎の内容&超汚い字で書いた気もしますが、
非常に楽しい&為になる勉強会でした。
株式会社じげんさん、登壇者の皆さん、参加者の皆さん、ありがとうございました。