みなさまこんばんは！あすみです！小田原に帰ってきましたが、さっきまでSRE Nextに参加していました！小田原（！）にあるNE株式会社というところで働いていて、シルバースポンサーとして協賛しています🙌

私自身は何をしているかというと、メインはPHP、たまにGo、極たまにRails、そして機会をもぎ取れたときはインフラをいじったりしています。そうです。基本はバックエンドエンジニアなのです。そんな私が異郷（？？）のカンファレンス「SRE Next」に参加してみた感想を書いていきます！

なぜ参加しようと思ったか

さっきチラッと言ったのですが、たまに「インフラをいじったり」しています。元々はインフラ何もわからんだったのですが、去年あることをきっかけにAWS SAAをとってそこからインフラもちょっとずつ頑張るようになりました。

asumikam.com

そして、その「きっかけ」はまさに会社の「SREメンバー」だったのです。当時、インフラメンバーがSREチームになって、さまざまな改善をしてくださりました。ただ、最初の頃はよくわかっておらず、「急に色々変わっていく・・・！」「なんかコントロールされている感じがする・・・！」と、勝手にお前らはダメだ！だから俺たちがかえてやる！と言われているような気がして、勝手に落ち込んでいました（←マジで猛省。ここに書くのも恥ずかしい）

そこで私の何かが燃えて、「じゃあSREの人たちが話している領域を自分がわかればよいんだ！！！」となり、とりあえずAWSの勉強をして資格をとってみて、その後もインフラの仕事を少しずつ受けてみる、ということをしていました。今思えばここでAWSに走ってるのが、もうちょっとずれてる感ありますが、はいwその頃は「SREとは"インフラ"の人がやることで、"インフラ"を少し言い換えたくらいのもの」と考えておりました👼

時は経ち、自分は大勘違いをしていると気づき、さまざまなビッグ恩恵を受け、今。「SREはみんなのもの」ということをかつてのSREメンバーが教えてくれました。その頃のSREメンバーは転職していった方が多くなってきており、2度めの「自分がわかればよいんだ！！！」の波が自分に押し寄せました。

blog.ytake.jp.net

また、ytake(@ex_takezawa)さんのこのブログがとても好きで、これは「インフラエンジニア」目線な話もありますが、バックエンドエンジニアの私にもめちょ刺さりしていたので、じわじわ「自分もやらないとなー」の気持ちになっていたところもあります。

冒頭の「SREってインフラですよね？」などは、「おいおい、自分の言葉切り取られたんか？？？」となりました。

そんなこんなで！！！！！参加を！！！！した〜〜〜〜〜い！！！と、なり、参加してみました！！！

参加してみてどうだったか

「自分でもできることがある」と思えた

どのセッションも洗練されており、また浅い知識の私でも理解できるセッションが多数あり、「あれもこれもみたい...！」になりました！なれました！初心者でも楽しめるカンファレンスにしてくださっているのは本当にありがたい🙏✨感謝です。

また、「SRE」とはプラクティス・アプローチだと思うので、その特性上「自社ではこのようにやっている」だったりの発表が多いのかな、と思っております（...違ったらごめんなさい🙏）そのため、具体的な事例を出していただけることが多く、自分の組織と照らし合わせて考えることがたくさんできました。その中で「自分でもここまではできるなー」とか、「SREがこの活動をしたいと思っているだろうか？そうだとしたら、自分は何ができるかな？」と色々考えるきっかけとなりました。

SRE を実践するためのプラットフォームの作り方と技術マネジメント
- ユーザー体験を良くするように「工夫する」、というマインドがいい言葉だな〜〜と思いました👏
- 他の会社の組織構造をしっかりみたことがなかったので、ここは自分のところと一緒、ここは違う...！と比較しながらみていました
マルチプロダクト運用におけるSREのあり方
- 「全てを同じ構成にしている」な、なるほどそういう方法があるのか！！！とびっくらこいた。
- 確かに楽になるところも多いだろうし、自分たちのところもそうなったらだいぶ楽だろうなと思った
  - やはりそれぞれのrepoでリソースが別れる、大体書かれているものは同じ、などはあるので
- 「制限」はされるが、だからこそ効率化される、の体現だなぁと感じました
プラットフォームSREによる脆弱性対策を意識したコンテナビルドフロー構築
- 自分たちのサービスでも脆弱性監視を強化している最中だったので他社の話が聞けてよかった
- 「4つの監視すべきところ」などは知らなかった部分なので、丁寧に言語化されてわかりやすかったです
【コミュニティコラボ企画】パネルディスカッション〜信頼性に関わる、ご近所さんが集まりました〜
- 他のコミュニティの話きけるのありがてぇ〜〜〜〜😭🙏
- 「運営が楽しめるようにする」、大事だなと思った。自分もそうであろう、とおもった。（？）
- カジュアルな雰囲気で、ザッと多くのことを知れて楽しかった
開発者がインフラ設計や運用に参加したら信頼性が上がった話~CloudWatch Evidently~
- 全員で「インフラる」、大事すぎる...私、きっとまだまだできてない...！やらねば...！！！
- え、何このサービス。めっちゃええやん。となった。このサービス自分でもみてみる👀
プロダクトオーナーとしてSLOに向き合う。Mackerelチームの事例
- 「POの目線」でのSLO、自分たちのチームだとそこまでPOの視座を高くできるだろうか...！（できてるのすごい）と別の方向から考えてしまった
- 「信頼性の主語はユーザー」←ビビッときた。そうだ.... たしかにすぎる....！
- この辺から「私はSREを知らなすぎるな」となって何か本を買って読もうという気持ちになってきた
Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵
- 初期調査のパパッとやれちゃうが、ちょっとだるいところ、そこをなくす。←すげぇ...めっちゃ最高だ
- 「メトリクスやAPMを見てエラーを少なくする」のような活動はしていたので、「そこにトイルがあるの、わかる...なくしてるのすごい....」という気持ちになった
Yahoo!ショッピング商品管理システムにおける、問い合わせ駆動の信頼性向上の取り組み
- SRE領域って、マジでめっちゃ解釈広いやん。しかも確かにこれもSREか。となった。
- そしてこの辺で元SREメンバーが一緒にやってくれていた「障害対応ガイドブック」の制定とか、あれもSREやん。ってなった（今更）
- 「私はSREを知らなすぎるな」となって何か本を買って読もうという(ry
信頼性目標とシステムアーキテクチャー
- めっちゃ基礎的なところからまとめてくださっていて非常にわかりやすくて神だった。
- そうか、フィーチャーフラグを作ったり、冗長化するのも「エラーバジェットを減らす」活動なのか...となった
- SREやべぇ。奥深い。やべぇ。

全セッションを通して、「SREとはなんなのか」が少しずつ自分の中で形作られていき、もっとちゃんと知りたい！となりました。また「前SREメンバーがしてきた活動がいかに尊かったか」を強く実感しました。

わたしもがんばらなきゃーーーーー！😭

垣根が違うカンファレンスの楽しみ

他のコミュニティに行くのは良いですね！！良い！！先ほども書きましたが、「取り組み」のような発表が多いと言ったのは、PHPコミュニティと比較して、の文脈が自分の中でつよいです。

PHPは言語のコミュニティなので、言語そのもののセッションなどがありますが、SREは言語ではないので、やはり実際のブツ、（言葉の定義、みたいなのはみなさん発表につけくわえてくださっているが）が軸になっているなと思いました。まぁふつうにあたりまえ体操ではありますが、参加してみてわかったので、より、コミュニティおもしろいなーとなりました。

また、「みんなで作り上げていこう！」なコミュニティでもあるかな、と思うので、私のような初心者が楽しめるコンテンツなのもありがたいです。🙏🙏🙏

重ねてになりますが、めーちょ楽しかったです✨