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