SRE NEXTに参加してきました。
自分はインフラ経験があるけれど SRE 職ではありませんし、今はどちらかというとアプリケーション開発によっています。
ただ、これまで自分自身が業務でやってきたこと、これからやっていきたいことが「SRE なのでは」と思ったことが、今回参加したきっかけです。
参加セッション
発表資料については、Twitter#srenext でご登壇された方がアップされています。
Qiita にインデックスを作成してくださっている方がいるので、そちらをご確認ください。
【SRE Next 2020】発表資料まとめ
- 分散アプリケーションの信頼性観測技術に関する研究
- 絶え間なく変化するメルカリ・メルペイにおけるSREの組織と成長
- 成長を続ける広告配信プラットフォームのモニタリングを改善してきた話
- freee のエンジニアは障害から何を学び、どう改善しているのか？
- 日経電子版SREチーム立ち上げ中
- 急成長するPairsと共に変化・成長し続けてきたエウレカのSRE戦略
- SREがセキュアなWebシステムを構築、維持するためにやれることはなにか
- サイト信頼性エンジニアリングの原則
- Webサービスを1日10回デプロイするための取り組み
- パネルディスカッション
所感
プラクティス等は、発表資料に（非常に）わかりやすくまとめられているので、自分なりのまとめです。
「SRE」とは
- SLI/SLO を定めるところから始まる。
- 最も大事なのは、ポストモーテム。
- 非難が存在しないこと
- 人ではなく、環境（プロセスと技術）に注目して修正すること
- 組織、サービスによって解決すべき課題が変わるので「これをやれば SRE」は一概には言えない。
- SRE本は同人誌のようなもので、プラクティスをつまみ食いして実践していくのもよい。
- スキルセットとしては、Web 開発の知識はもちろんのこと、過去ログや障害のデータを集計して、統計する知識が求められる。
- 組織のフェーズ、サービスの特性を踏まえて、「生産性」と「信頼性」のバランスをとるための、コミュニケーションスキルが必要。
チームとしての「SRE」
- 成果を図るのは難しい
- SRE チームとして OKR を立てて、メンバーはそれにいかに貢献しているかで評価する
- ソフトウェアチームにメンバーとしてジョインする場合、専門職としての「期待値」を上回ることが求められる
- インフラチームの名称を変えただけでは「SRE チーム」とは呼べない
今後のSRE
- 短期的には、インフラでもクラウド、オンプレが混在しており一長一短があるなかで、現状の技術基盤を賢く活用してサービス運用していく。
- 長期的にみると、Firebase や Heroku でカバーできる範囲が増えているなかで、専門職として必要とする会社は増えないかもしれない。ただし、サービス開発に携わる限り、SRE という「考え方」はなくならない。
最後に
個人的な感想です。
まず、今回勢いで参加しましたが、非常に学びが多く有意義な時間を過ごさせていただきました。 運営スタッフの皆様、登壇された皆様、本当にありがとうございました！
あらためて SRE とは「考え方」であると実感した 1 日でした。 SRE チーム立ち上げの苦労話、freee さんのセッションなど、失敗経験や大きな障害からの学びを共有していただける機会は非常にありがたく、次回もぜひ参加したいと思いました。
個人的には、eureka さんの SRE チームの Mission「会社の目指すビジネスの実現の阻害確率を上げる要因を全て排除する事」がとても印象に残っています。 今後 SRE ロールになることがあろうとなかろうと意識していきたいです。