もうだいぶ日が経ってしましたが、1/18(金)に SRE Loungeのイベントに参加してきました！すでに7回目の開催ですが、はじめて参加してきました。
SREチームを部署内で立ち上げてみて半年以上が過ぎ、これまでの活動のまとめ・自分の引き継ぎ(産休のため)・来期の計画/活動方針などを考えるタイミングだったので、他社の取り組みを聞いたり、SREs/SREに興味のある方と交流できたのはとても良かったです。
個人の感想が多分に入ったレポートに仕上がってしまいました(ﾉ≧ڡ≦)
SRE Loungeとは
SRE Lounge は、UZABASE のSRE チームが中心となり、発足した勉強会です。 http://tech.uzabase.com/entry/2018/01/26/200021
もともとは、クローズドで少人数な勉強会運営をしておりましたが、より幅広く参加者を集い、SRE 同士で交流したいという想いから、2018/6 より、オープンに参加者を募集することとなりました。 SRE や、SRE にご興味をお持ちの方は、ぜひご参加ください。
Facebook グループや、Slackもあるそうです。
- Facebookグループ
- Slackグループ(参加リンク)
- ハッシュタグは #srelounge
SRE的チーム開発Tipsやベストプラクティスっぽい何か
おぐま @ktykogm さん (メルカリ)
スライドは下記に公開されています。
ボリューム満点で駆け足の発表でしたが、全体的に自分のモヤッとしていることが言語化されていたり、なんとなく普段意識している点が盛り込まれていたりして、正に「首がもげる」ほど頷きながら聞いていました。スライドも公開されているので、今回じっくり振り返れてよかった。
SREsとは？という話。
twitter.comSREsはDevとOpsの脱サイロ化を目指す。ベースにはDevOpsの思想。インフラ・開発・ガバメントをまたぐ領域を担当。その中でもSREメンバーの中にも得意分野はそれぞれ。色々な分野から集まった、多様性のあるチームが望ましい。#srelounge
— kusuwada (@kusuwada) 2019年1月18日
DevOpsとSREは対立するものではないし、そもそもDevOpsは文化・SREは技術手法であったり領域を指すので、DevOpsの思想に基づいたSRE活動というのは成り立つよなぁと、自分の過去エントリ思い出しながら聞いていたり。
それにしてもSREの守備範囲(領域)、広すぎ。
信頼性に関わることは、基本的に対応
とのことなので、必然的に守備範囲は広くなる。SREer、強そうな人が多そうな印象を受けるのは、守備範囲をかっちり決めず「どこでも行きまっせ！何でもやりまっせ！」的な人がリードしてることが多いからかなー、と推測したり。
それでも、一人で全方位を100%カバーするのは難しい。SREメンバーは得意分野がそれぞれある、多様性を持ったチームになるのが望ましい。
ここ悩ましいところで、なんとなくSREっての作ってみようか、今いるメンバーで！で始まると、Ops/インフラよりのメンバーばかり集まりがちだったり、ガバメント・セキュリティ・BI的な要素を持つメンバーは「なぜ私がSRE？？」となかなか釣れなかったり。SREは守備範囲広い → 多様性が必要という今回の話は、なるほどな確かにそれそれ、それだわ！となった。SRE立ち上げてメンバー集めて自己流でやっていたけど、こういう集まりに来るとモヤッとしてて言語化できていない課題が納得行く言葉で表現されてて大変良かった。
twitter.com成長フェーズになると、新しい人の受け入れに向けて、「オンボーディング準備」が必要。ドキュメント準備にも力を入れたい。ドキュメントや受け入れ体制が揃っているかで、新しい人の立ち上がりがぜんぜん違うよね。#srelounge
— kusuwada (@kusuwada) 2019年1月18日
戦略的SRE組織論の章。スタートアップや新規事業における、各ステージのSREの配属計画や、SREの立ち回りについて。
どのフェーズでどういうことに力を入れ、どういう活動をしていくべきか、という話。成長フェーズの「オンボーディング準備」の話が特に刺さったので呟いたけど、その他の話も非常に面白かった。詳細はスライドへ。
Document整備も本当に軽視されがち。上の人・マネージャーはこだわってる人も多いけど、実際にDocument書くのは一担当者だったりするわけで、得意な人もそうでない人もいる。そういう人が書くドキュメントを、どう価値あるものに、参照されるものにしていくのか。どういう内容で、どういう構成にすべきか、そして何よりどこに何があるかをどうやってわかりやすくするのか。この半年のSRE活動でかなり心がけてきた部分でもあったので、ここも首がもげるほど頷き。
ドキュメント作成時にRFCを参考にする（Must, Should, Must Not, Should Not をはっきりさせる）という話も面白かった。この辺しっかりしていないと「で、結局どうしたらいいん？」というドキュメントに仕上がっちゃうことも多い。
twitter.comいまメルカリではマイクロサービス化を行っているが、タイミングとしては悪くないと思っている。スタートアップ時点ではモノリシックのほうがコストも低いし広告の機会もたくさん持てる。そっちのほうがプロダクトを成功に導きやすい。#srelounge
— kusuwada (@kusuwada) 2019年1月18日
このフェーズでなぜ microserviceが必要なのか、という話もされており、納得。microserviceの採用にあたっては、会社の状態をよく考え慎重に、というお話も。
その他、最近話題のSOA(Service-oriented atchitecture)や、SREでも取り入れたほうが良い文化(アジャイル・リーダブルコーディング)、GitとReview/PullRequestについての話など。本当に盛り沢山だったし首がもげるかと思った。
Gunosy版「SREのミッション」策定
浜地 @aibou さん(Gunosy)
スライドは下記に公開されています。
SREとSREsのお話。
- SRE: 技術手法・領域
- SREs: 職種・SREをしているエンジニア
と定義してお話をしますとのこと。このMeetupのいち日前くらいにちょうどSREとSREsについての話がTLに流れてきていて「ほほう」と思ったところだったのでタイムリーだった。
紹介されていた、ゆううきさんのブログ
以降では、SRE本の原著にならい、技術領域名を指すときはSRE、職種名を指すときにSREsと表記する。
twitter.comグノシーSRE：3名で回している。オンコールは核開発チームも巻き込んで輪番監視。ユーザー影響のあるアラートはPagerDutyでアラート飛ばしている。
— kusuwada (@kusuwada) 2019年1月18日
障害対応（ポストモーテム）に参加して、対応内容が「運用でカバー」になっていないかをチェックしている。これいいな。#srelounge
「運用でカバー」警察は本当にいいなと思った。うちの組織だと、一応ポストモーテム的な会と、どうやって対応する(した)のかを報告する場はあるんだけど、聞く側はマネージャー陣しか基本いないので、技術がわかるマネージャーといえどなかなか運用観点でのレビューが漏れていそう。
年末年始に「ポストモーテム大会」と称して、SREメンバー＋各チームのOps担当メンバーで2018年に発生した（しそうだった）障害と原因・対策を発表しあう場を設けたんだけど、もう少し頻度を高くして対策に対する議論の場にできたらなーと思ったとこだった。
障害対応報告の場でこれをできればもっと良さそう。他のチームの失敗に学ぶことも多いし、そこで新たに生まれてしまうところだったToilの防止だったり、新しい技術・サービスの導入にも繋がりそう。
と妄想しながら聞いていたら、暫く聞き逃した気がする。
twitter.comSREの定義は？特に社内の人が考えているSREがぶれていると大変。何でも屋さんとか、そんな感じで雑に扱われてない？
— kusuwada (@kusuwada) 2019年1月18日
→わかる。とりあえずSREがやってくれるらしいで、ってなりがち。
立ち上げ時からこうなる予感がしていたので、うちはミッション・守備範囲を事あるごとに確認していた。#srelounge
発足時からここを懸念する声はうちでも多く、活動開始前に「ミッション・活動方針」を決めて大きな声で宣言していました。特にSREはアンテナの高い人が音頭を取りがちな気がするので、組織内の困ったこととか面倒なことがあったらすぐに丸投げされそうな予感。ただでさえ「困りごとの磁石」みたいなところにSREの看板がつくと「より強力な磁石」になって課題を引き寄せるイメージ。Google本にも「組織ごとに形は異なる」とあるので、SREという言葉に活動範囲の定義もない。
本当にやりたいこと・やるべきに注力するために、便利屋さんにならないために、「SREのミッション」策定は必須だなぁと感じた。
Gunosyさんでは、あくまで「SREの位置づけ」として定義したり、「事業」を大事にすることを一番にする(SRE都合のルールで社員を苦しめない)、など、ユーザーのみならず社員全体がハッピーになるように気をつけてこのポリシーを策定されたそう。
最後に、「人物としてのSREsの理想像」が大変良かったのでコピペ。SREに限らない気もするけど…。
- 常に向上心を持つ
- 現状に満足せず、自己の成長を常に心がける
- 常に余裕を持つ
- つまり「自動化していきましょうね」
- 問題解決は「冷静」に行う必要がある
- 社員に信頼されている
- SREsは必然的に関わるチームが多い
- 自社プロダクトを愛している
- 自社プロダクトを使わないと課題が見えてこない
事業成長×キャリア形成という観点でのSREを立ち上げ
天野 @pataiji さん (Speee)
スライドは下記に公開されています。
エンジニアリングマネージャー 兼 SREチームリーダーの方のお話。
twitter.comSpeee SRE：SRE立ち上げ時期は2018年5月。うちと一緒だ！親近感。
— kusuwada (@kusuwada) 2019年1月18日
開発チームは15名、バックエンド8名、うちSREは2名、くらいの規模感。
大きな問題点：リードエンジニアが圧倒的SPOF🔥（単一障害点）→SREチームの立ち上げ#srelounge
リードエンジニアが圧倒的SPOF、あるある。このままの構造だとフットワークが重く攻めの開発ができないと感じていた。
ここからプロジェクト制を導入する組織変更を行うことで、各エンジニアの裁量が増え、事業成長につながる攻めの開発をやりやすくなった。
が、今度は各所で部分最適が進み、プロダクトの信頼性が落ちやすい状態になった
→SREチームの立ち上げ
という経緯が一つ、もう一つはキャリア形成という視点でのSRE立ち上げ。この視点は新しかったので面白かった。
今までのSpeeeエンジニアは、バックエンド・インフラ・フロントエンド → Web開発におけるほぼ全部のスキルが求められていた。が、それぞれのエンジニアの「インフラ/フロントを伸ばしたい！」というモチベーションに応えることができていなかった。採用としても、特定領域に強みを持った人の採用がやりづらかった。
→SREチームの立ち上げにより、SREチームにはインフラや基盤型の開発を伸ばしたい人が集まりやすくなり、フロントエンドも同様に専用のスキルを持ったメンバーを集めやすくなった。本人のモチベーションと、仕事のアサインの問題。エンジニアリングマネジメントだー！
これによって採用計画も引きやすくなった & エンジニアのキャリア形成の計画も立てやすくなり、めっちゃよかった、とのこと。
SREsの採用についても言及。
まず転職エージェントにSREがなにかわかってもらうのが大変だったり、SREって新しいロールなので経験者が少ない＋他社の経験者は重要なポジションをしているケースが多くて転職しにくい、など。
全体の感想など
他のイベントと比べて、タイムラインの流れが圧倒的に早かった！※AWS Summitなど規模が桁違いのものは除く
話を聞きながら頭で解釈、まとめてアウトプットしていく…というのが得意/好きな人もSREsの特徴なのかも？SREsは色んな人から色んな相談が寄せられがちだし、マルチタスク得意な人多そう。単にTwitter民が多いだけという話もある。
twitter.comおわった！運営をいっしょにやってくれた皆さんや、参加者の皆さんに感謝👏
— かつひささん (@katsuhisa__) 2019年1月18日
今回、運営メンバーの皆さん(SRE集団) と運営やってて思いましたが、
やっぱSRE の人ってメンションに反応する速度が常人の2倍くらいはやい気がするw
運営の困りごとを解決していくスピードが早すぎたw
#srelounge
SRE の人ってメンションに反応する速度が常人の2倍くらいはやい気がする
🤗🤗🤗 わかる 🤗🤗🤗
今回は技術的な話はほぼなかったですが、他社がどういう背景でSRE立ち上げたのか、どのような取り組みをしているのか、何が課題でどういうことに気をつけているか、など一番聞きたいことが聞けて大満足でした。
twitter.com今更ですが、SRE Lounge#7に参加してきました。いい話ばかりだった！
— kusuwada (@kusuwada) 2019年1月18日
見習いたいなーと思った内容：
・SREのメンバーの多様性（スキルマップ作る）
・ポストモーテムへの参加と「運用でカバー」警察
・SREの理想像をチーム内外でシェア#srelounge
