こちら↓の日の東京遠征の続きです。
#1 でブログ枠参加して以来、日程が合わなかったり気づいた時にはすでに枠が埋まっていたりしてなかなか参加できませんでしたが、今回は別の強い（？）イベントが同じビル内で開催されていたせいか参加枠が埋まるのが遅く、無事参加できました。
なお、今回はブログ枠ではないのでゆるく書いていきます。
会場スポンサー LT : プロダクト横断で可視化するダッシュボードの開発（山北さん）
会場スポンサー、メタップス山北さんの LT でした。
SRE チーム発足から「srest」サービス開発に至る経緯が短めにまとめられていました。
仕組み化してトイル削減できたぜ！…と思ったらアラート地獄が。#yurusre pic.twitter.com/jiBdO7ghVz
— hmatsu47(まつ) (@hmatsu47) 2024年6月6日
プラクティスに従うとか文化を醸成するのは大事なのですが、それに強くこだわりすぎると、良かれと思ってやったことが思わぬ方向にいってしまうのはありがちですね。
ダッシュボード化→srestにつながる。
— hmatsu47(まつ) (@hmatsu47) 2024年6月6日
（きれいに着地！）#yurusre pic.twitter.com/KScU4QD2Lx
スポンサー LT らしい、きれいなオチでした。
SRE のように歩き、SRE のように鳴くときに（maru さん）
SRE としてサービス開発チームを支援する難しさを解決するヒントを育児本に求めつつ、相手の視界に入って活動する重要性を説くお話でした。
来た！#yurusre pic.twitter.com/G9Itd1K0Dx
— hmatsu47(まつ) (@hmatsu47) 2024年6月6日
会場のプロジェクターが Mac の周波数に合いづらかったのかそれともケーブル長が厳しかったのかはわかりませんでしたが、急遽プロジェクターの代わりにディスプレイが用意されました（それまでのつなぎの話、おつかれさまでした）。
チームとして個人としてやってると本当に難しい。#yurusre pic.twitter.com/ZYeqnooisy
— hmatsu47(まつ) (@hmatsu47) 2024年6月6日
サービス開発チームが Stream Aligned Team、SRE が Enabling Team、というコンテキストで。
「とてもおすすめなSRE本」w#yurusre pic.twitter.com/ot0qbeTseN
— hmatsu47(まつ) (@hmatsu47) 2024年6月6日
なお「この本は読者を選ぶ」（ダメな人にはダメ）だそうです。
TiDB に移行してみたが、実際どうなん？（Oda さん）
最近 Aurora MySQL などからの移行事例が多い、TiDB への移行作業と移行後に感じたことのお話でした。
さいきんは中の人に聞いても「AuroraはPostgreSQLのユーザーが多くてMySQLの比率は下がってるから…」みたいな感じらしい。#yurusre
— hmatsu47(まつ) (@hmatsu47) 2024年6月6日
AWS の Aurora MySQL → OCI の MySQL HeatWave、という事例もあるにはありますが、TiDB の話もよく聞きますね。
今回のケースでは、コストとスケーラビリティが移行の動機だったそうです。
Aurora以降（本当は◯racleの某製品以降、と言ったほうが良いのかも）のRDBMSは「ストレージ層が一つの肝」とも言える。
— hmatsu47(まつ) (@hmatsu47) 2024年6月6日
（TiDBではTiKV大事）#yurusre pic.twitter.com/omqv9KOP2S
あまり意識されていないかもしれませんが、ここは結構大事です。
その他、クエリチューニングを含め、PingCAP のサポートが手厚かったのが移行が成功したポイントとして挙げられていました。
ちゃんとバックワードレプリケーション組んでる。#yurusre pic.twitter.com/BTpHa8RqfX
— hmatsu47(まつ) (@hmatsu47) 2024年6月6日
何かあったときに切り戻しが必要になるので、これも大事です。
とあるソフトウェアエンジニアの小さく始めるオブザーバビリティ（pHaya さん）
（SRE というよりは）SWE として障害対応に課題を感じて、OpenTelemetry でオブザーバビリティに取り組んでいるお話でした。
いろんなものが自動でできるようになった結果「これって何のために計測してる指標？」みたいになることはないのかな？#yurusre
— hmatsu47(まつ) (@hmatsu47) 2024年6月6日
ある程度自動化しないと環境構築段階で定着せず挫折しがちな反面、それを利用する側が意識しないところで環境が出来上がってしまうと元の目的や意図が理解されない…というジレンマが発生しそう。
実際にやってみないとわからないことがある。#yurusre pic.twitter.com/bgjHaorEMG
— hmatsu47(まつ) (@hmatsu47) 2024年6月6日
まず始めることが大事。
後半の 5 分 LT
それぞれ軽くコメントなどを。
後半戦スタート。
— hmatsu47(まつ) (@hmatsu47) 2024年6月6日
LT1本目はへたれさん。#yurusre pic.twitter.com/nwB36KE5rq
ドキュメントと IaC で SWE にもインフラ関連を担当してもらえる環境づくりは大事…ですが、チーム構成と役割分担が固定化されてくるとなかなかうまくいかないので、やるなら早い段階で、というのが個人的な感覚です。
久しぶりの登壇緊張しました！本日の資料です！#yurusrehttps://t.co/HciYMFEXUo
— Masa (@maaaato) 2024年6月6日
LT2本目はmaaaatoさん。#yurusre pic.twitter.com/10mId3FrFh
— hmatsu47(まつ) (@hmatsu47) 2024年6月6日
SLO の前にまず CUJ（クリティカルユーザージャーニー）を意識して SLI/SLO を設定。ツールに泣かされてうまくいっていないところがあるようですが、参加者のコメントをヒントに解決すると良いですね。
つぎはわらしなさん。
— hmatsu47(まつ) (@hmatsu47) 2024年6月6日
前世（？）はDBA。
（たぶん知ってる）#yurusre pic.twitter.com/BfWGuauJow
写真がちょっとブレちゃいましたが、不要なリソースを削除するのはセキュリティ的にも大事、です。
サブドメインテイクオーバー、何年か前に流行ったなー。#yurusre pic.twitter.com/htfxjsa31Z
— hmatsu47(まつ) (@hmatsu47) 2024年6月6日
パブリッククラウドがターゲットになりやすかった記憶が。
次は渡部さん。#yurusre pic.twitter.com/BSlR5rdCKF
— hmatsu47(まつ) (@hmatsu47) 2024年6月6日
ドキュメント、手順とか決まりごとをまとめるのも大事ですが、その裏にある意図を残すのも大事ですね。
あと OpenSLO は知らなかったので一度確認しておきたいです。
ラストは蒲生さん。
— hmatsu47(まつ) (@hmatsu47) 2024年6月6日
障害対応訓練的なやつ、割と緊張感がある。#yurusre pic.twitter.com/tpkh2RGfpp
これ、なかなか大変なんですよね…。
社内ISUCON的なものも障害対応訓練的なものも自分が準備してやったことあるけど準備はすごく大変。#yurusre pic.twitter.com/G7cnMKs5O8
— hmatsu47(まつ) (@hmatsu47) 2024年6月6日
準備それ自体の大変さもありつつ、エンジニア層以外には「遊んでる」と誤解されがちで色々根回しが大変だったり。
（なので、個人的には今の組織にいる限り、もう準備することはないでしょう…残念ですが）
懇親会も、立ち話をしているうちにあっという間に時間が過ぎました。
SRE NEXT は有意義ですが、ゆる SRE 勉強会も「SRE NEXT とは別の軸」として大事な存在ですね。
そろそろ 1 周年記念回が開催されるそうなので、楽しみにしています！
