社内勉強会で「SRECon16の紹介」をした
基本的に毎週金曜日に30分で社内のエンジニアで勉強している。 今回は自分が発表しようと思って色々とネタを探していたが、最近参加した外部の勉強会でSREConなるものを知り、色々と追いかけてみたのでその情報を共有する内容にした。
Microservices Meetup vol.2 - Tsuyoshin blog
発表資料
SRECon
所感
- 英語がもっと得意な人は自分の数倍早く、深く理解できるだろうな....
- やっぱり各社それぞれ定義が異なっていたがそれぞれ面白かった
- failure-resilient, not failure-resistantという言葉が印象的で納得感あった
- 今回の資料には出てこないけどOn-Callという言葉も自分の中では印象的であった
- 少しでも理解が進めばよいなと
- 下記はSRE関連の情報がまとまっていてとても勉強になった
- 今後もっとSREという言葉が言われるようになると思うけど、ある程度のサービスを運営するチームであれば必然と誰かがやってる状態になって、その業務領域を皆にわかるように（ちゃんと評価されるように）
SREというtagがつけられた感がしてる - 下記の本を読んで見ても良いかも（スイマセン自分は読んでません）
Site Reliability Engineering: How Google Runs Production Systems
- 作者: Betsy Beyer,Chris Jones,Jennifer Petoff,Niall Richard Murphy
- 出版社/メーカー: O'Reilly Media
- 発売日: 2016/03/23
- メディア: Kindle版
- この商品を含むブログを見る
Microservices Meetup vol.2
勉強会に参加させてもらったのでメモ
勉強会概要
microservices-meetup.connpass.com
発表
「マイクロサービスとSREの役割」by 鈴木@kenjiszk (株式会社FiNC)
- コンウェイの法則
- 理想形？各microsericeのチームにSREをいれるのがよい？
- SREのリソースがネックになりつつある
- SRE業務ができる人材を育てる。権限の委譲を進めながら
- 開発/SREの壁をどんどんとり払っていく
- SREももちろんコードを書く
- SREが責任を持って守るライン
- セキュリティ
- コスト管理
- スケール
- 新技術の取り組み
マイクロサービスの本やInfrastructure as Codeの話等々を踏まえて自分は、セキュリティは独立したチームを組むべきで、逆にそれ以外は各microservicesのチームに託していくべきだと思っている。
SRE（の役割）とは各microservicesのチームに含まれている部分もあれば、独立して担う役割の部分があると思ってる。当然各チームや会社によって範囲は変わってくる。
なのでマイクロサービスとSREというのはそれぞれの解釈？定義が違うので一概に語ることは難しく、FiNCさんの場合はという感じで聞いていた。
参考
マクロサービスアーキテクチャを数回読んだ - tsyoshin blog
Recruit Technologies Open Lab #03 テーマ：Infrastructure as Code に参加してきた - tsyoshin blog
「SRECon 2016 Wrap Up」by 坂本さん@takus (スマートニュース株式会社)
- Freedam & Responsibility
- どの開発者もNetflixのシステムを買わせるほどのアクセス権がある
- そこでSREの作るツールが重要になる
プロダクトを作っている感覚でSREはツールを作っていく
SRE should be a Enabler , SRE should not be a Servant
SREcon16の内容とか追っていなかったのでそこでの話などとても為になった
「マイクロにしすぎた結果がこれだよ！」by 榎本さん@mosa_siru (株式会社Gunosy)
www.slideshare.net
- AWSのsecurityグループとIAMを活用して経路自体に制限をかけてまとめた
- 全体構成が複雑が複雑になり人数いないと機能しない話
- 少人数のために各APIを管理する統合管理画面なるものを作成してその為だけのAPIを作った話
- ここまでくるとちょっと辛いし、microsericeは自立したチームでもあるので、組織構成が大切だなと
「Microservicesの実際と対策」by 大谷さん@shot6 (株式会社 ファーストリテイリング)
- swagger使ってる
- appはnodeで書くパターンが多い
- kong使ってる
- 体制が重要で。専任のスモールチームが必要
- そもそもマイクロサービスとは、すごく優秀な数名で最大限に活用するモデルがmicroservice
- 課題
- 運用面。既存の仕組みとの連携方法が難しい
- 共通的に解決しなくてはいけない課題をどう乗り越えるか？
- 答えがないのでどうやって横のつながりを増やすか
- サービス間の通信の可視化
- 依存関係の把握
- microserviceのテストの課題。dockerにすりゃ済む話ではない。10個以上docker立ち上げられないよローカルで
ウェルネスタイム (大好評、FiNCトレーナーによるストレッチタイム)
- タバタトレーニング
- しんどかった。勉強会で筋肉痛になったの初めて
「より良いAPIを作るために」by 相川さん@awakia (ウォンテッドリー株式会社)
- 最初からHerokuを使っていてその後、Dockerへ移行
- 2002年にamazonの社長だした司令の話
Kong使ってる事例を初めてみたけど、使ってる感じどうなのかなぁ？って思ってる。ざっくり聞きたいな
最後まとめ的な
Coveを試してみた
Coveって？
要は会社のOKR、チームのOKR、個人のOKRを便利に管理するツールです。
ざっくり特徴とか
日報的に毎日進捗等を記したり、進捗N%と更新することで定量的なレポートが見えるので管理がしやすくなる。
- そのレポートをメールで飛ばされる。チームのObjectiveはチーム全員へメールされると思われる
- そのレポートをメールで飛ばされる。チームのObjectiveはチーム全員へメールされると思われる
Key Resultの部分でTO-DOSを登録できたりする
OKRのマップ（視覚化）
感想やら雑感
- 目標に対する進捗なるものの管理はすでにあったりして、もし導入するならそれを置き換えるイメージになると思う。
- 追加でこのツールも導入とか考えると、ダブル管理の部分が出てくるし、手間でしかなくなる気がする
- ちゃんと使いこなす文化ができれば、あまり関わりの無い部署のOKRの進捗が簡単にみれたりする(OKR Map)でのその点は良いと思う
- エンジニアでは無い人は使いこなせるかは、んー
- 結局ある特定の人、チームだけが使いこなしていても他の人達が分からなかったり、伝わらなければ仕事の透明性を欠き色々と問題が噴出してくるのは変わらないと思う
- 少し前にプロジェクトの見取り図なるものを教えてもらって作って運用してるけど、他部署の人への伝わってる感はそれなりに感じている
PMについて思った事
元ネタは下記の動画をみて、自分的に思った点やメモを残す
まずはPMとは
- ここで言っているのはプロジェクトマネージャでは無く、プロダクトマネージャ である
- この辺りは色々な所で違いを定義したり、言われたりするけど個人的には下記の文がしっくりきている
プロダクトマネージャ
プロダクトの課題の解決に向けて技術的なアプローチも含めどうやって実現していくかに責任をもつ
プロジェクトマネージャ
品質であったり、開発コスト、スケジュールに責任をもつ。
補足等々
- パッケージソフトが主流だった頃を考えるとプロジェクトマネージャの立ち位置はわかりやすいと思う。
- webやアプリでサービスを継続的にスピード感持って提供していく上ではプロダクトマネージャがより重要になってきると思う
- プロダクトマネージャには技術的な理解や手法の習得がとても重要でほとんどエンジニアのような存在だったりする
- プロダクトマネージャの部下はエンジニアではなく、お互いに対等なレイヤーなので、指示等は基本存在しない
- なんでお互いの信頼関係がとても重要
- でも実際はプロダクトマネージャがリードしていくパターンが多く、エンジニアをリードするにはエンジニアリングもスーパーな人でないと厳しい気がする
Product Manager vs Project Managerでもひと記事いけそう...
さて本題. PM(プロジェクトマネージャ)の役割に関して
結局は全社でCross Functional TeamになるんだけどPM(プロジェクトマネージャ)とEngineerは両輪になるし、密に連携しながら進めなければいけない。なので重要なPMとEngineerの役割をピックアップする
PM(プロジェクトマネージャ)
- 「What」「When」「Why」をしっかり定義して押し進める。
- PRD:Product Requirements Documenを主に活用していく
- プロダクトの課題の解決に向けて技術的なアプローチも含めどうやって実現していくか (2回目記載)
- OKR
Engineer
- 「What」「When」「Why」で決まった方針に関して「How」どのように実装していくかを担当していく
- Design Doc
memoやら
- 「How」の実装方法はEngineerのリスペクトにつながるのでPMは基本的に関与しない
- ただ、Engineerのただ試してみたいという意向だけでselectされたオーバーアーキテクチャには注意が必要だなとおもった
- そこまでやる必要ある？ってスタートアップではよくある話で....
- 「How」の実装方法はEngineerに託すが、PMは内容に関してはしっかりコードレベルで理解していかないとキツいと思う。
- PRD:Product Requirements Documenは重要で工期の終盤、リリースを優先する場合は機能を削減しなければいけない場合がある
- その時に方針をブレずに判断する為に必要
参考
- Servant leadership - Wikipedia, the free encyclopedia
- job-descriptions/product_manager.ja.md at master · increments/job-descriptions · GitHub
- OKR (目標と主な結果) – 前田ヒロ
- OKR：組織内のコミュニケーション効率化と重要なゴールへの集中を促すシステム - yaotti's diary
- Design Docの例:WebKit WebSocket design doc - Google ドキュメント
最後
主にKPIの所からPRDに落とし込んでOKRを設定して開発を進めるが、当然それだけだと全く楽しくないし、それだけでは不十分。思ってもみなかった不具合やユーザの反応を見ての改善＝ボトムアップで出てくる改善の開発も入れながらバランスを取ってやっていく事が重要だなと思う。
ひとえにPMといってもプロダクトマネージャなのかプロジェクトマネージャを指してるのか曖昧になってる事がよくあると思う。スタートアップでは両方の役割を一人がこなす事が多いから問題にならないけど、違う事を理解しておかないとスケールした時に色々と問題が生じる
作るプロダクトによる（B2B向け？B2C向け？）けどプロダクトマネージャはほぼengineerと同程度のテックは必要だと思ってる。 日本でよくいる技術的な事が分からないディレクターやプロデューサーとは全然別ものなんだけど、彼らにプロダクトマネージャの役割を担わせようとしてる事が多い気がする。当然無理が生じる。結局はengineerの誰かが補ってるパターンが多い。
別にテックが無いディレクターやプロデューサーを批判しているわけではない。仕事を通してスキルを身につけていく事は普通だけど、例えば経済を学ぶ学生アルバイトに弁護士試験をパスしていてと言っているぐらい、別物で難易度が高いもを担わせようとしているような感じ？かな。もっとイイ例えがありそうだけど。
プロダクトマネージャと言うものをちゃんと理解してテックのバックボーンがある人間が担っていく事が理想だけど、なかなかそういう人っていないよなーって思うし、社内から生み出していかないといけないだろうなーと思う。
とにかくそれぞれの役割の違いをみんなで理解するところかな。ちなみに動画でも言っていたけどそれぞれの役割とラップする部分は多くあるのでオーバーラップは当然ある。重要なのはどこに軸足を置いてるかと
Habitat Meetup #1 に参加してきた
勉強会に参加させてもらったのでその時のメモやら
勉強会概要
発表
Habitatとは？ Chef Software, Inc. Alex Vinyar
- Habitatを含むChef Automationのお話
- Chef Automate – Embrace DevOps | Chef
- Chef Automationのポイントは下記3つ
- Visibility
- Workflow
- Compliance
- Chef Automationの概要図は下記の図がわかりやすい（本家から）
感想
今、Chef,Rubocop, Foodcriticを使ってレシピかいてServerSpecで担保してってやってるけどこれらをChef内で完結できるとより良いエコシステムになるしビジュアライズはステキだなと感じた。 githubのPRのような人によるレビューをするワークフローが存在していた。
関連情報
Foodcritic - A lint tool for your Chef cookbooks
Habitat考察(仮) 高石諒(@r_takaishi)
- Chefがデータセンターの自動化なら、Habitatはアプリの自動化というお話
- HabitatはRustで書かれているらしい
- HatbitatはInfrastructure as Codeの分類で言う所のinfractures serviceに属するお話
- Infrastructure as Code の分類の話は関連情報で
- Habitatの特徴としては
packageとsuperviorがある - どういったアーキテクチャで動いているかや他のプラットフォームでも動く点など
- docker上でもいける
- 実際のデモ
関連情報
Infrastructure as Code のこれまでとこれから/Infrastructure as Code // Speaker Deck
ChefConf2016参加レポート クリエーションライン株式会社 鈴木逸平
VP of EngineerのSeth FalconのKeynote
@r_takaishiさんがデモしてくれた内容やChef Automationに関しての話が中心
CEOのBarry CristのKeynote
Chef Automationの話はあるが、注目すべきポイントは下記
slowness kills
ビジネスアイディアとshipingはという要素は重要で良いアイディアはあるけど実際にshippingできたのは2年後といったものではもはや遅すぎる。 たとえどんな素晴らしいアイディアであっても遅いと全てが無くなってしまうという話。Amazonなどのサービスがなぜ良いか、当たり前のサービスを迅速にユーザにshippingし続けているからだ！！と
ここではShippingまでのスピードといってるけど、サーバのレスポンスだったり、カスタマーサポートのレスポンスだったりのスピードも同じだと思っている
ideas = easy
アイディアを出すのは簡単。shippingをどれだけ迅速にできるかが重要。shippingまで至るまでにはどうやって実現するかや乗り越えるべき障壁は色々とあるだろうが、結局はshippingできてからの話
まとめ的なもの
- Chefの製品は自分が３年前に見た時よりかなり変わってて、Chef内で完結するような製品群になってきているなと
- 日本だとServerSpecとかがあってそれなりに定着してる感あるのでInspecとかはどうかなと思ってる
- Inspecの書き方や動作はServerSpecそのままのように見えた
- Habitatも各デプロイツール+Dockerとかという部分とかぶる気がするけど、Supervisorやクラスタ機能は手軽感あったので今よりは良いのかな
- visualizeの機能は可視化は重要なので今までに無い機能でよいなと思った
- ChefConf2016のKeynoteを聞いた。英語全然得意じゃ無いけど雰囲気わかった
slowness killsの話は本当にそうだし、実現するには色々な壁があるけど、重要性をずっと説いていくことは意味あることだと認識した- 同じことを事ある後に言い続けるのはツライけどそれだけ価値があることだと思った
- 自分は不得意です
- 今回の勉強回に参加させてもらって改めて思ったのは、その先にあるProductivityやDevOpsの話に必然的に繋がって、どう事業を成長させるかという感じになって深くなっていく。
- そして本当のObjectiveにぶつかる
お疲れさまでした
API Meetup Tokyo #15 〜OpenAPI Specification (Swagger)特集〜 の勉強会に参加してきた
勉強会に参加させてもらったのでその時のメモやら
勉強会概要
発表
1. OpenAPI Specification/Swagger概要 (19:05〜19:20) API Meetup運営チーム/Apigee 関谷和愛さん @kazuchika
www.slideshare.net
- Swaggerとの関係というか歴史の話
- 今後のロードマップの話
- OAS 3.0は2.0とガラリと変わるだろうとの話
2. OpenAPI Specification を使ったスマートな API 運用 (19:20〜19:40) 株式会社 KUFU 芹澤雅人さん
- SmartHRの紹介の話
- 黎明期のAPIの話から現在に至るまでのAPIの話
- ドキュメントにSphinxを活用していたのはちょっと懐かしく思った
- 昔Pythonで作ってるプロダクトで導入してた人がいたなぁーっと
- ソースとおなじレポジトリ（ディレクトリ）にSphinxでつくったドキュメントを置く事でレビューの対象になり抜け漏れがなくなる話
- なるほどなと思った。
- インターネットへの公開領域のディレクトリとかあったら注意ですね。
- 仕様書とコードは近ければ近いほど良いは大賛成
- Swagger導入までには書きのようなステップで導入していった話
- step1 Swagger coreの導入
- step2 Swagger specの確認
- Swagger UIの導入
3. Swaggerを使用したモデルファーストなAPI開発のよもやま話 (19:40〜20:00) TIS株式会社 小西啓介さん
www.slideshare.net
- すべてが使いやすいわけではないという話
- 表示されてるレスポンスが加工されてる場合があり、HTTP statusコードが実際には違う話とかちょっとハマりそう
- 内部と外部のAPIのSwaggerを分けたくなるけど統一のがいい
- 共通化のポイントは下記
- Parameters Definitions
- Responses Definitions
- Schema Definitions
このあたりは参考になる
4. Lightning Talks by Open API Initiative members! (20:05〜20:55)
Mashape Augusto Mariettiさん ※英語トーク
下記のプロダクトで活用している話 www.mashape.com
- 個人的にはちょっと時間を作っていじってみたいと思った
- 英語のリスニングってむずいっすね。結構海外の基調講演の動画とか見てたりするんだけど、、、
Paypal 岡村純一さん
IBM 森住祐介さん
Microsoft 佐藤直樹さん
Apigee 関谷和愛さん
まとめ・雑感的な
Recruit Technologies Open Lab #03 テーマ：Infrastructure as Code に参加してきた
勉強会に参加させてもらったのでその時のメモやら
勉強会概要
発表
"Infrastructure as Code" から数年、結果どうなったか @naoya_ito さん
日本語でいうところの冪等性=ReproducibleBuildちょっとしたキーワードだった。
自分はわりとそのままにしていた管理画面からのポチポチ業もReproducibleBuildしなきゃいけないなーと感じた。最近はDNSの設定でさえもコード化されていてサービス（プロダクト）を最速に提供する事が重要でそこに集中する為にという流れなんだろう。
AWSのIAMの設定重要っすね。
あとはモデリングの話で今の業務をそのままシステムに落とし込んで効率化や自動化を図っていくのが本質では無くて、複雑な業務をいかにシンプルにモデリングしてシステムに落とし込んでいくかが重要
自分もアプリケーション開発が主なのでアプリケーションを開発するときに考える、言語、FWの特性が今回の要件に合うかや正規化等々を想像したら分かりやすかった
最後にコンテナとかが出てきているのでモデリングがそこまで議論にならなそうって。
スライドに出てきた参考
Domain-Driven Design: Tackling Complexity in the Heart of Software
- 作者: Eric Evans
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2003/08/22
- メディア: Kindle版
- この商品を含むブログを見る
Infrastructure as Code と企業文化 @ryuzee さん
クラウドがどんどん使われ始めてインフラなのかアプリなのかという境界線がどんどんなくなっていっている(同意)
採用アーキテクチャをうまく回していくにはやはり使う側の人・組織構造もセットで変えていかないとツライはなし（=コンウェイの法則）が出てきて最近別のところでも聞いた内容だったのでやはりそうですよねって思った。
同じくその際の注意点としてどうしても横断的に見た方が良いプロダクとの一貫性やセキュリティ面は考慮しておいた方がよいと。
なので共通するチームは残る。
文化面でのチャンレンジは正直相当ツライだろうなと想像してしまった。半端な決意では出来ないというか、、、相当な覚悟が必要
まぁ一気にやろうとすると正しい事でも爆死しますね。
Infrastructure as Code のこれまでとこれから mizzyさん
現代の開発の三本柱の「バージョン管理」「テスト」「自動化」を実現した部分が大きいと。
Infrastructure definition toolsでTerraformは最近あまりよい話を聞かないなぁ。
Infrastructure as Codeを下記の分類に分けて説明していた部分はとても分かりやすかって理解の整理になった
- Dynamic Infrastructure Platforms
- Infrastructure Definition Tools
- Server Configuration Tools
- Infrastructure Services
ここでもコンテナの話やマイクロサービスの話が出てきて繋がってるもんだなと。
モニタリングとの融合の話で”テスト＝本番デプロイ前、モニタリング＝本番デプロイ後”はなるほど！
スライドに出てきた参考
Monitoring is Dead // Speaker Deck
運用・監視もコード化する。開発者が監視まで考える方法論 @songmu さん
どんどんコード化され、インフラ・アプリの境界線が曖昧になってきているし、アプリケーションエンジニアはコードを書くのが得意な領域なのでどんどん取り組んだ方が良いと思った。
I Love Webhookの話はもっと色々と持ってそうでしたね。
今の会社でも最近Mackerel使ってるので聞きやすかったです。
プロビジョニングツールはMakeで決まりだろ @katzchang さん
タイトルの釣り感がはんぱない。
プロビジョンイングツールでCofuってあったけど始めて知りました。 github.com
chefのcookbookレシピの中でmakeを書いてた過去を思い出しました。。。
まとめ
話を聞いていて最近特に調べたりする「マイクロサービス」「ThoughtWorks社」「Martin Fowler」「コンウェイの法則」とかのワードが出てきて、まぁ繋がってきますよねって感じました。DDDの話はちゃんと理解していないので勉強していかないとなと
最近Chefいじってなくて。別の同僚に任せきりになってることを反省した。Infrastructure as Codeでもちろん頑張って自分もコード書いていこうと思うと同時に構造もセットで変えていかなくちゃななー。スモールスタート。成功実例作り。んー胃が痛い
