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