元記事の方がスライドがembedされて見やすいです
https://okash1n.tech/2018/09/25/jddstudy-3-devops/
JDDさんが主催されたJDDStudy #3 最新DevOps事例勉強会！スタートアップとグロースフェーズ それぞれの開発チームが取り組むDevOpsの今。に行ってきたのでレポ
概要
プロダクトのスタートアップでリーンに立ち上げるタイミング、マーケットフィットを経てグロースさせるタイミング、それぞれのフェーズで開発体制や運用体制、運用手法は異なってきます。
なぜそのDevOpsになったのか？
DevOpsにこだわりをもつ3社をお招きして、ツール選定や意思決定の背景から、実際に活用してみた感想までをお伺いしていきます。開発をより効率的に！と考えている方、最新DevOps事例を聞きながら、一緒にディスカッションをしていきましょう！
DevOps on Merpay Microservices - 株式会社メルペイ 高木 潤一郎さん
スライド
SREってなんだっけ??
- Google Cloud Platform Blog: SRE vs. DevOps: competing standards or close friends?
- The human scalability of “DevOps” – Matt Klein – Medium
メルペイのアーキテクチャ
- 殆どはGoで書かれている
- Go microservice templateのようなコードがある
- gRPCでやりとり
Merpay API Gateway
- メルペイ側も改善する
- CI/CD CircleCI -> Container Registry -> Spinnakerで自動デプロイ
運用の仕組みの共通化
- Microservicesでは各サービスのチームがOwnerとなって運用をすすめていく｡技術選定も自由｡
- とはいえ､SREや他のチームのメンバーがサポートするためには共通化が必要
- 運用の仕組みの共通化がDevOpsでは大事
- 皆が好きに仕組み作るといざSREがサポートしようと思ってもできない
- モニタリングやロギングツールは共通化
ルールの共通化
SLO(Service Level Objective)を決める
- SLO: サービスが信頼できる状態かどうか判断するための指標
- 例: Gatewayで測定して､あるAPIのRequestの成功率が99.99%
- 指標がないと､何を直すのか､いつ緊急対応するのかの判断ができない
ツールの共通化
- ログ: StackDriver & BigQuery, メトリクス: Datadog, エラー通知: Sentry, 当番通知: Pagerduty
- Microservice starter-kitで自動で書くサービスのTeamやProjectなどが生成される
感想
流石に日本でSREの先駆けとなったメルカリの関連会社だけあって､今日の発表の中では一番Googleの教科書に近いSREをやっている印象｡SREチームは開発者のDevOpsを助けるような存在を目指しているのが特徴的だと思いました｡｢共通化｣という言葉はビッグワードですが､メルペイさんの共通化というのはあくまで｢最低限｣の部分についてであって､何でもかんでも共通化するわけじゃないです｡じゃあ｢最低限｣ってなんなのか?
運用の仕組みの共通化
サービスを作ってスケールさせていくということは､結局サービスを｢運用｣するということ｡必ず発生する｢運用｣について､ちゃんと見据えて各MicroserviceごとのDevOpsを円滑に回すための｢仕組み｣の部分をSREが担保していくというスタンスはこれから自分のチームでも取り入れていきたい｡
ITインフラにおける継続的改善の実践 - レッドハット 株式会社 中島 倫明さん
ITインフラの自動化への関心
- 総論賛成
- QCDが改善されて嫌な人はいない
- 各論いろいろ
- 眼の前の作業を自動化したい人
- 全体最適化を狙う人､部分最適を狙う人
- 自動化されると仕事がなくなって嬉しい人､困る人
- 今までのやり方を変えたい人､変えたくない人
- 周辺も含めて考える人､ピンポイントに絞って考える人
ITインフラ効率化の三位一体
自動化を進める時の悩み
- 眼の前の作業をAnsibleなどで自動化する
- 実はそんなに難しくない
- 実際に取り組むと出てくる悩み
- これってほんとに動く(意図した結果になっている)んだっけ?
- 本番環境で実行して影響を与えないんだっけ?
- このPlaybookって､別の環境でも動くんだっけ?
- このPlaybook(半年前につくったやつ)って､今そのまま動かせるんだっけ?
- Ansibleをバージョンアップしたけどこれって動くの??
大半は自動化の実行､再利用､時間経過に伴う｢自動化の正しさ｣に関する悩み
自動化の正しさとは
- 自動化の正しさに関する悩み
- 手順書や仕様書は｢作業の前｣に検証･担保するためのもの
- 自動化しても設計工程についての疑問や課題がやればやるほど出てくる
TDD的なインフラへのアプローチ
自動化の正しさが自動で検証できると
- 精度の高い変更計画と作業が可能
- 変更に伴う影響派にを早期に検証可能(テストが何件エラーなど)
- やる､やらない､いつやる
- 変更に伴う影響派にを早期に検証可能(テストが何件エラーなど)
- ノウハウの蓄積とスケール
- 運用すればするほど人に依存せずに品質が向上する
- 確実性の高い再発防止がコードとして積み上がる
- 横展開を用意にする
- 運用すればするほど人に依存せずに品質が向上する
｢変化｣への対応を安全で低コストに行えるようになる
変化への対応
- 変化への対応を前提にシステム構築･運用した方が合理的
感想
まず､第一に｢さすが教授｣という､大学で講義を受けているような気分になる発表でした｡(ま､私大学卒業してないんですけどね)
高木さんの話と同様に､｢変化｣が起こることを前提に基盤作って行きましょう､という話ですが､TDD的なアプローチをIaCでやっていくことで､｢運用すればするほど品質が向上する｣ような｢仕組み｣を作るという部分はまさにSREやQAでやっていくべき部分だな､と改めて認識しました｡
インフラCI実践ガイド Ansible/GitLabを使ったインフラ改善サイクルの実現 という本を最近発売されたそうです!
DevOps実装者としてのSREの存在と役割 - 株式会社スタディスト 北野 勝久さん
スライド
感想
2010年3月創業の株式会社スタディストさんは､2011年3月創業の弊社アソビュー株式会社と同じく､グロースフェーズにSREをやり始めたということもあって､すでにある程度｢散らかってる｣サービスにテコ入れをしていったその過程を発表してくださったので､とても参考になりました｡
そもそも私がこの勉強会に参加したのは､北野さんの書いた記事｢SREって何？ これまでのシステム運用やDevOpsとは何が違うの？｣を読んでからTwitterなどで連絡を取ってみたあと､彼のTweetで見たからでした｡今回のスライドよりもこの記事の方が詳しいのでそちらもぜひ｡全部読むには会員登録が必要なんですが､私はこの記事を読みたくて登録しましたw
class SRE implements DevOps - SREはDevOpsの実装
- DevOps
- Dev, Ops, その他チーム全体を巻き込み一体で仕事を進めるための文化運動であり方法
- SRE
- ソフトウェアエンジニアがOpsを設計する際のプラクティスであり､DevOpsを実装する役割
- DevOpsほど文化的変化を前提としない
SREを含めたDevOpsを実装していくために
SREにしろTDDにしろ､もっと各論でIaCだとか､Kubernetesだとか､分析基盤だとかエンジニアなら皆やりたいですよね? でもせっかく提案してもうまくいかないって人多いんじゃないでしょうか?
その点についての一つの材料として､｢データや研究結果を示す｣という話がありました｡
私は前職の時から｢提案の仕方｣｢声の上げ方｣は下手な方で､ずっと考えてきたんですが､うまくいかなかった提案ってのは｢こんな困ってることがある｣｢こっちの方がいいじゃん｣ということだけをばら撒いてることが多かったことに最近気づいてきました｡逆に上手く行くときは､しっかりデータ出してる時だということも最近感じてたので｢カチッ｣っと音がした気がしました｡そして最近､DevOpsにさらにBizを足したような発想､つまり経営目線や他のチームや運用まで考えた提案をすることが何より大事であると考えるようになったのですが､それはまた近々ちゃんとまとめて記事書こうと思います｡
ちなみにpuppetのwhitepaperはここで毎年出てるみたいです｡(発表で紹介されてたのは2014 State of DevOps Report – Thank you | Puppet)
チームのスケールのために
｢サービスがスケールするためにはチームも個々人もスケールしないといけない｣ので､そのために何をやるのか｡
- 社内勉強会や社外の勉強会のアウトプットをしてストックする
- 早速週明けに開発チームに共有します
- 開発チームをまたいだ振り返りの実践
- ポストモーテム
- Twitterでの情報収集･発信
- Twitterは仕事
実際､TwitterやFacebookで北野さんに連絡取らなかったらこの勉強会にも参加しなかったし､後述する懇親会での情報交換における気付きも無かったと思います｡あ､北野さんは｢SRE Lounge｣という勉強会も主催してるそうです｡今月はもう枠埋まってましたが､次回はぜひ行きたいと思います｡
CI/CD自動化とDevOpsの抽象化の試み - Japan Digital Design株式会社 Takuya Noguchiさん
スライド
主催のJDDさんの野口さん｡｢どえらい人がやってきたなぁ｣という第一印象でした｡この方Gitlabのコアエンジニアだそうです(日本では一人)｡
DevOpsとは何か､について紹介されていたドキュメント
-
Effective DevOps—O’Reilly E-book | Microsoft Azure
- MSから無料で落とせるよ
- 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
感想
Japan Digital Design 株式会社さんはMUFGグループからFintech部分を切り出して､ダイバーシティを意識して積極的に外部や他業種から採用をしていってるそうです｡週に2､3日しか来なかったり､フルリモートだったり､勤務時間も全然違う人がいたりと非同期な働き方をしてる会社｡その中でDevOpsをやっていくにあたって､とにかくGUIポチポチを無くして､コード化することで後から他のメンバーが振りかえることが出来る状態を作っている話が印象的でした｡もちろんこれは非同期な働き方じゃなくても必要ですが､非同期な働き方だからこそなおさら必要なことなんだと思います｡
ドキュメント化やコード化については最近思うところがあって､特に障害対応なんかはストックされるべきだと思うんですよね｡基本的にはサービスは一人で作るものじゃないし､｢運用｣や｢変化｣､｢障害｣が皆に等しく必ず起こります｡今日の全ての発表に共通することですが､それらの｢必ずやってくるもの｣に備えた動きをすることがSREを含めたDevOpsには必須だということですね｡そしてそういうことを考えて行くと自ずと｢提案｣する際に必要なスタンスも見えてきそうな気がしました｡
懇親会
むちゃくちゃ元気の良いJDD副社長さんの乾杯で､懇親会も執り行われました
料理も美味しかったです｡
これ､間違いなくSansanで毎月やってる社内懇親会と同じケータリング会社だと思うんですよね｡先月表参道.rbに行った時も食べましたが､このおにぎり食べるとSansan思い出します｡(まだ辞めて2ヶ月くらいですが)
懇親会では､野口さんや北野さん､JDDのエンジニアさんとも直接お話したり､他にもいろんな会社の人々と話せました｡
番外編｢懇親会での会話｣
懇親会でメルカリの@ktykogmさんとお話したんですが､その中でも特に参考になった点をいくつか｡
自動化の基準
- とにかく毎日使うものは自動化したほうがいい
- 完全な自動化はまだ人類には早い
- バックオフィス的な業務もzapierなどで自動化しちゃう
｢Open Door｣ - Zapierなどを非エンジニアに根付かせるにはどうしてるのか?
｢Open Door｣という話が特に興味深かったです｡どういうことかと言うと､社内勉強会や意見交換会､フリーディスカッション､｢なんでも聞いて会｣などを時間と会場を決めてかっちりとやるのではなく､｢この時間ここにいるから､いつでも好きな時に来て帰っていいよ｣というスタンスで開くような会だそうです｡
例えば､｢Zapierで定常業務などを自動化しましょう｣というのを非エンジニアにも教える時に､｢ゆるーく3時間くらい開いてるので5分くらいでもいいから聞きに来てね｣という感じで社内にアナウンスして､人が来るまで普通に仕事して､人が来たら手を止めて教えて上げるそうな｡これ､目的は｢心理的障壁を下げる｣ことで､新しいことを広めるのに心理的障壁があっては広まらないということだそうです｡なんとそういう勉強会をやったら2~3ヶ月で非エンジニアにもZapierでの日々の業務の自動化が広まったそうな｡(いくらポテンシャルの高いメルカリ社員とはいえ､すごすぎだろ｡)
もちろんこれ､勉強会だけじゃなく開発業務や新機能､その他サービスに関わるようなこともエンジニア･非エンジニア問わず､｢いつでも来てね｣というような感じで開いている会がメルカリでは多いそうです｡最近弊社でも､いろんな部署巻き込んでの会話が増えてきてますが､｢Open Door｣を取り入れるとさらに加速していろんなコラボレーション生まれそう!と思ったので早速持ち帰りたいと思います｡
メルカリでのコミュニケーション
｢心理的障壁を下げる｣というのはやっぱり大事らしく､メルカリではSlackなどで特にマネージャーなど位の高い人から率先して｢下らないこと｣などをSlackに投下したりしてるそうです｡確かに前職Sansanでも､Workplaceの個人グループとかで行われる半分雑談のような会話から生まれるコラボレーションやアイデアって多かったな､と｡
- ｢言っていいんだ｣という文化を作ることが大事
だそうです｡怖がってたら会社に来たくなくなりますからね｡ちなみに､これも｢研究で出てる｣そうです｡(やっぱデータ大事だー)
全体の感想
いろんな発表や懇親会での会話､それぞれに共通点があったり､組み合わさることでより理解できたり､飯も美味いし総じて良い勉強会でした｡11月にもDevOps系のテーマでJDD Studyやるそうなのでまた行きたいと思います｡
Top comments (0)