SRE Nextに参加しました。
SRE Nextに参加しました。
今回は、スポンサーブースをほとんど回ることなく、セッションをずっと聴いてました。聴講したセッションのまとめと感想をつらつらと書いていきます。
WHO AM I
普段は、エンジニアなんでも屋として働いています。バックエンド(Go言語)も、フロントエンド(TypeScript, Astro, React, Svelte)も、インフラ(Google Cloud)も、リリース管理、そして、企画、ディレクターの仕事もしています。ここまでして、エンジニアなんでも屋と言わずして、誰のことをなんでも屋というでしょうか。
Day1
Becoming SRE - SREって何から始めればいいの?
立ち見が出るほどのパネルディスカッションでした!Day1の中でも最も聴きたいセッションだったので、立ち見で前の方にて、聴講していました!
SREとして求められる要素は、競合も含むサービス・ビジネスを理解して、改善に取り組むことで、小さな改善の積み重ねるというのがポイントという感じでした。
採用・育成に関しても、各社とも、興味関心・好奇心がキーとなっているようで、課題を見つける、改善提案、採用→解決という一般的なサービス開発で行う一連の流れを行える人がSREにも求められているようでした。
このパネルディスカッションを聴講するまで、SREという仕事について、ハードルが高い、技術力があるレベルの高い人が取り組む仕事というイメージを持っていましたが、聴講して、普段の仕事にて、取り組んでいることの延長線にあるものとして感じました。
巨大インフラ産業で戦うSRE
オープンロジさんのSREの取り組み事例についてのお話でした。
SREは、組織横断のチームということで、ファシリテーションとして動く、同じ目線に立って課題に取り組むといった各チームとの関わり方について、知ることができました。
同時にモノリスからマイクロアーキテクト対応が課題とのことで、その対応に対して、SREとしてどのように関わるのかといったスタンスも出されており、このマイクロアーキテクト対応について、実際どうだったのかといった事例をまた知りたいと思っています!
同時に、IaCのterraformで管理、Git管理にて変更を追いやすくなったとのことで、インフラのコード化のメリットを改めて、認識できました。
日本最大口座数を保有するSBI証券のAWSマイグレーションを支えたサービスとソリューション
SBI証券でのAWSマイグレーション時に使用したサービスとソリューションについての発表でした。
テンプレートを活用しての負荷試験を行えるDistributed Load Testing (DLT)障害を意図的に起こして挙動を確認できるAWS Fault Injection Simulator (FIS)とどちらも使用したことがないもので、メリット、SBIでの活用事例を知ることができました。
なかなか、どちらも使う機会がないので、DLTは、Cloud9を活用して触ってみようと思いましたが。。。💦
Day2
朝は、起きることができず。。。
オブザーバビリティのマクロからミクロまで〜あるいはなぜ技術書を翻訳するのか
2日目に聴講したいセッションの1つでした!
マクロの視点では、ユーザーに近いところで、SLOを定義して、小さな単位で解決する。そして、ラムズフェルドの4象限をオブザーバビリティに置き換えて、Unkown-UnkwonをKnown-Knownに持っていくという取り組みの必要性を感じました。また、ミクロの視点においても、Known-Knownを確実にして、Known-Unknowを探究するということで、SREとして、大きな視点を小さな視点の双方を行ったり、来たりして、より良いサービスを作っていけると感じました。
内製化を見据えた効果的なSRE支援のアプローチ
SLOの理解を深めて、ユーザーエクスペリエンスを向上する方法
day1でのパネルディスカッションを聴講して、スリーシェイク社の取り組みについて知りたいと思い、トラックAに残り聴講しました!
定義→スタート→実践→発展継続するためのロードマップを設定して、自走を内製化を支援するという取り組み。
暗黙知→形式知への変換、そして、標準化していくという部分に、SREだけじゃなくて、全てのコンサルで重要じゃないかと感じる話ばかりでした!
500万人が利用する「友達と遊べるたまり場アプリ パラレル」におけるデータベース基盤の継続的改善
Z世代が中心に活用するアプリ「パラレル」さんでのデータベース基盤の継続的改善事例の発表でした。MySQLのパフォーマンス低下に伴うタイムアウト設定、Cloud SQLの定期メンテナンスといった最近、興味があるデータベース改善について、事例を知ることができました。
SQL問題というとクエリ問題かなと思っていたら、案の定、クエリ問題でした。スロークエリ問題において、クエリのアクセス数を調整できるVitessは、初めて知ったサービスで、SRE NEXT後、少し調べたりしています。
SRE の考えをマネジメントに活かす
day2にて、とても面白く聴講したセッションでした!
マネジメントとSREとの比較を行うと期待値を調整するという点で共通していることから、SREは、既にマネジメントをしているということでした。
明日からすぐできる処方箋として、「期待値を調整する」という一番取り組みやすい学びを得られました!
スタートアップの急成長に寄り添うOn-Call体制構築とその変遷
10XさんのOn-Call体制構築の事例です!
地元にあるスーパーも10Xさんのサービスを使っていることから、10Xさんについては、知っていました!
初期段階→種蒔きフェーズ→成熟期→振り返りの流れで、一番印象に残っているのは、ドキュメント整備とメンバー間の課題意識の統一です。内部で標準化されているルールの言語化と向いている方向が一致させないといけないのは、痛いほど痛感したことがあるので、On-Call体制だけでなく、他の新しく物事を始めるときには、重要な気づきを改めて、認識しました。
Enabling SRE by Guide Maps
最近、気になっている日本経済新聞社さんの社内取り組み事例です。
ガイドラインの作成、Trail Mapの作成などの取り組みで、組織として、より良いサービスを作るには何をすべきか、できることは何かを明確にして、取り組めるようにする仕組みだと感じました。
印象的だったのが、組織に不足している能力を分析しつつ、改善できることを念頭にして、ガイドラインを作成しているという点です。
マクロ(組織)をガイドラインを設定して、ミクロ(チーム)で改善するという動きをできるので、無理のない範囲から小さな取り組みからスタートできると思っており、今後会社で取り組むときには、この動きを取り入れたいと思いました。
SREが考えるハイブリッド開催の技術イベントのライブ配信における信頼性
SRE NEXTの最後のセッションでした。
2020年以降、ライブ配信も増えており、信頼性、安定稼働をどのように取り組んでいるのか知ることができました!
「完璧なライブ配信を目指してはいけない」という、何が起こるかわからないライブ配信は、「そうだよね」という印象しかありませんでした!
同時に、ライブ配信にて対応していただいている皆様、いつもありがとうございます!という気持ちになりました!
終わりに
SREという解像度が低かったものが、少し解像度が上がったイメージです。
いきなりSREになるというよりも、現在の仕事にプラスして、サービスをよりよくするには、という視点でスタートするのもありなのかもしれないと感じました。
現在の仕事に少しずつ改善を加えて、もっと腰を据えて取り組みたいとなったら、SRE専門を目指すというのも、アリなのかもしれない。そんなことを感じるイベントでした!
継続して、SREの勉強会なども参加して、各社の取り組み事例を勉強して、活かせることを仕事に取り入れていきたいです!
なお、来年のSRE NEXTは、2025年7月に開催されるとのことです!