参加者と登壇あわせて実は皆勤賞だったんですが、ついに今回それが途絶えてしまいました（笑）

Beyond Next

基調講演

初日の基調講演はGoogle SREのSteve氏でしたね。いやはやEnterprise本読んでいたので、著者の方の講演が聞けるのは胸圧でした。

sre.google

著書内でも掲載されている図にも言及されていました。

クラウドコンピューティングではなかった従来であれば、インフラは下から堅牢に積み上げるピラミッド型であったが、現在は故障を想定したアーキテクチャを選択できる。故障したら全部取っ替えるという発想ではなくなったわけですね。

#srenext #srenext_a
Steveのスライドの一部は彼の著書にも書かれてますね👀https://t.co/utCiMUaFMX
— oʎЯꓕɅ (@3s_hv) 2024年8月3日

スライドを見つけられなかったので、記憶（しかも英語）を頼りに思い出すには割と限界ががが。ブログとポストモーテムはその日のうちに書くべし。

また、Ask the speakerしたかったんですが、このときその部屋がどこにあるか見つけられず（地図が首からぶら下がってることに気づいてない）、残念ながら質問はお蔵入りしました。

組織的なインシデント対応を目指して〜成熟度評価と改善のステップ〜

本日の登壇資料です。登壇後のAsk the speakerでいろんな方とたくさんディスカッションできてとても楽しかったです。https://t.co/vQpisncp4E #srenext #srenext_b
— Narimichi Takamura (@nari_ex) 2024年8月3日

Topotal CEOの高村さんのお話。インシデントレスポンスの難しさと成熟度モデルについてです。

僕個人の感覚としても、サービスが初期〜中期フェーズくらいまでならインシデント対応は超人や古参による銀の弾丸で対応するケースをよく見てきました。しかしある規模を超えたり、複数のマイクロサービスから成り立っていたりすると組織的に対応しなければ効率的にできないというフェーズが来るはずです。

というような課題を感じてはいたので、こちらの内容は実に面白かったというわけです。

組織によって課題も期待値も解決策も異なるので、自分のN=1体験が次も役に立つとは限らない。高村さんのスライドでは「不確実性が高い」という表現をされていますが、まさにそうでしょう。

ベストプラクティスが適用できるとは限らない点から、これだという決まったものをぶつけていくことも難しい。

そういうものには、能力成熟度モデル統合 *1を当て込んで、プロセスを洗練していく話。

SREの状況をベースに段階的に定義するというアプローチはSREからすればごく自然な発想なので理解しやすいかと。

自分たちがどのフェーズにいるのかを分析し*2、次の世界で何が必要なのかを見極められるようになると良さそうです。

そしてそのそのモデルは、高村さんが公開してくれています。さすがだ。

講演時に紹介したインシデントレスポンス成熟度モデルを再利用しやすいかたちで公開してほしいという要望を多数いただいたので、Miroとスプレッドシートを公開します。ぜひご利用ください！ #srenext
Miro: https://t.co/6WbzPijha1
Google Sheets: https://t.co/mc409NYiS1 pic.twitter.com/gWr42UbQUR
— Narimichi Takamura (@nari_ex) 2024年8月4日

そしてようやくこの登壇からAsk the speaker ルームを見つけられたので、無事に質問攻めできました。いつもお世話になっております。

他の質問者さんともちょっとだけ交流できたので良い時間でした。

スポンサーブース

なるべくスタンプラリーしたいと思って回ってましたが、混雑とスタッフの関係で話を聞けないところも多数……。いつも全部回って話を聞くぞという気持ちだけはあるんですが、並んでまではしたくないのですぐに諦めがち。

知らなかった企業も、ずっと前から知っている企業、中の人といった業界内のつながりが垣間見えたりする時間でもあります。以前Go Conferenceに行ったときはほとんど知らない企業が多く、あれはあれで新鮮で面白かった記憶。結局楽しいので問題なし。

それから意味わからんレベルのGoodノベルティを配っている企業がおり、有識者曰く「これ無料で配るようなものじゃない」と羨ましがられました。コーヒー飲むので毎日使ってるレベル。Thank you snyk!

#srenext でもらったノベルティ、有識者に見せたら「YETIってこれめちゃくちゃ良いやつだぞ」って言われたのでしらずに当たり引いてたらしい pic.twitter.com/7lRVMS9DN3
— oʎЯꓕɅ (@3s_hv) 2024年8月3日

go.snyk.io

日本最大口座数を保有するSBI証券のAWSマイグレーションを支えたサービスとソリューション

AWSへのマイグレーション時に負荷試験をAWSでシュッと構築した話が印象的でした（スライドが見つけられなかったので記憶だけで感想書いてます）。

というのも私も負荷試験準備をしている時期だったので、AWSですぐに実行できるなら実に良いなと思った次第。

AWS Distributed Load TestingやAWS Fault Injection Serviceは使ったことがありませんでした。

aws.amazon.com

私はk6を使って負荷プログラムを書いてますが、こういう方法も組織と課題が異なればありだったかなと思いました。

k6.io

負荷試験を作成するときに気をつけることについて「不要なところに負荷をかけてないか？」は確かにそうだなと。社内NWにばかり負荷をかけてしまうとか、別の基盤でスロットリングかかっちゃうとかあるあるでしょう。

「システムをAからBに変更する」という作業自体が非常に大変なので、ひとつの事例として勉強になりました。

懇親会

2024の懇親会は、渋谷のクラブ？会場にて。クラブ自体に興味がなくて行ったことがなかったので、最初入ったときに何をする場所なのかわかってませんでした。

それはそれとしてすごいのはこのクラフトビール。CloudBaseさんが原材料から指定した？上に、スタイルも2つ用意されてました。缶詰で発注するにはそれなりの予算が必要なはずで、さらに材料やスタイルも決めるとなると結構お高めなのではとエスパー。予算がないと「このスタイルになりますねー」みたいな、オリジナルとは？を考えさせられるものが出来上がってしまうので、スクラッチできるのは実に羨ましいですね。