はじめに

SRE kaigiという技術イベントに初めて参加してきました。自分が聞いたセッションの中でかなり学びがあったので、振り返りながら記載していこうと思います。

セッション

さくらのクラウドからAWSに移行をすすめつつ新規サービスを進行。インフラ領域を担当していたtech Leadの方が、退職により責任集中。属人化を脱却しつつ、技術以外の負債も抱えながらきっちり取捨選択をして進めていくストーリーが展開されていました。

これらの状況に対して戦略をとりながら、アプローチをとっていくところが印象的でした。

SREを実施するまでの過程もとんでもない寸劇だなと思ったのですが、上記4つを進めて基盤をつくっていくところも爽快で。SREとしてのアプローチも徹底されて感動しました。

自分がいま担当している開発領域でも業務要件の優先順位を明確に整理していきたいなと思いました。

組織拡大に伴う「SREとプロダクトエンジニア（実際にアプリケーションを開発している人）」間での課題を構造的に解釈し、アプローチを提示していました。

SREとエンジニア間での分断がおきること自体、すごく違和感というのか、プロダクトエンジニア側から、口を出さない方がいいのかな🤔と思っていたのですが、その境目もコミュニケーションを図りながら構築していく必要があるのだと強く感じました。

最後の「視座」の観点は、全エンジニア必読の内容になりそうです。

刷新のプロジェクトに携わっている自分にとってはリリースすることが最優先事項ですが、今後は機能面だけではなく非機能面の課題感や意識を持っておこうと思いました。

とても痺れました。

縛りの強い中でのAWS移行の話が語られていました。要件を整理したうえでデータのフロー図だったり、システムフロー図を使いながら全体を整理して段階的に移行を進めていてたのが残りました。

rubyでの実装も包含しているので、rubyを使われている方には話が共感できる内容なのかなと思いました。
データ欠損しても原因を掴んで、EKSを扱い倒してリリースのクローズまでもっていく精神がカッコ良すぎました。

データ基盤の観点でさまざまな設計パターンを用いて、アプリケーション・インフラレイヤそれぞれで仕組みを検討していくところがわかりやすかったです。

設計パターンは「選ぶ」だけではなく、「育てる」ことが重要

ユーザー側の可用性ってすごくありがたいことを実感するセッションでした（笑）
（もう一度データ指向アプリケーションデザインの本を読もうかな....）

そもそも監査のスコープを最小化することや、セキュリティチェックで怪しい問題があったらissueに自動記載する仕組みを構築していたりなど、Toilを減らしていく姿勢（SREの精神）が随所に散りばめられていて印象的でした。

Cognitoを多要素認証の強制で使うであったり、KMSを機密情報保持の暗号化に使うであったり.....
AWS各種サービスを目的ベースでまとめており、技術選定の意図がクリアになりました。

これをきにドキュメントの整備やアーキテクチャ図など、見直す機会になりそうです笑

とっても充実したイベントでした。これまでに技術イベント参加した際には、スタンプラリーに毎回参加していたのですが、今回はいっさいやらず、sessionをききまくりました。

"SRE"という言葉は知っていますが、具体的にどういうことをやるのか？どんな概念があるのか？を知らなかったので、「知る」という歩みを得られただけでもかなり大きな収穫です。

他のsessionも参加したいのがいくつかあったので、発表資料を見にいこうかなと思いました。