改めてSREについて考えてみる話
7月にもなり、季節も暑くなりましたね。
暑くて溶けそうですねぇ。。。。。
昨日、Road to SRE NEXTというイベントがあり京都で開催され、参加してきました。Road to SRE NEXTは8月にSRE NEXTというカンファレンスが東京で行われるための、プレイベントみたいです。
行われたセッションとＬＴは以下の内容でした。
セッション1
タイトル: ソーシャルゲームの長期運用を目指すための SRE の取り組み - 10 周年を目指すコトダマンの場合 -
セッション2
スポンサーセッション
タイトル: マネーフォワード関西開発拠点のSREの始まりと今と未来
概要: マネーフォワードの関西開発拠点で開発しているマネーフォワード クラウド会計Plusのチームで、どのようにSRE活動を初め、どのような課題に取り組んできたのか、そして何を目指そうとしているのかについてお話しします。
LT1
タイトル：SRE チーム立ち上げ前に考えたこと・取り組んだこと
LT2
タイトル: メールサービスの信頼性を支えるSREの取り組み
LT3
タイトル: TerraformサポートされていないFirebase Remote ConfigでもIaCしてみた
飛び込みLT
ポストモーテム読書会のすすめ
飛び込みLT②
※後日記載
簡単な感想として
様々な会社で様々な事業に関わっているSREエンジニアのサイトの信頼性における活動を聞いてとても勉強になりました。セッションやLTを聞いて共通して言えるのは、みんな地道に泥臭く苦労しながら活動していっているんだなぁ。。と思いました。
多くの開発組織におけるSREの立ち位置に関して、話を聞いているとやっぱり立ち上がったばかりでプロダクト横断型のSREとかやったり、1人SREだったり、SREとしてチームが組めていないから開発チーム等を巻き込んでスケールアウトで浸透させていくとか多種多様でありすごく有意義な時間でした。
8月の本番のカンファレンスが楽しみになってきました。
詳しい発表概要は以下から
ここで、改めてですが、本番カンファレンスまでに知識をもっと深めたいので、改めてSREについて勉強していこうと思います。
SREは、大規模なソフトウェアシステムの信頼性と効率性を確保するための実践的なアプローチです。以下がSREの主要な基本概念です：
サービスレベル目標（SLO）とサービスレベル指標（SLI）：
SLOは、サービスの期待される性能レベルを定義します。
SLIは、サービスの実際の性能を測定する指標です。
エラーバジェット：
許容可能な障害の量を定義し、信頼性とイノベーションのバランスを取ります。
監視とアラート：
システムの健全性を継続的に監視し、問題を早期に検出します。
自動化：
反復的なタスクを自動化し、人的エラーを減らし効率を向上させます。
障害対応と事後分析：
障害からの迅速な復旧と、根本原因の分析を行います。
キャパシティプランニング：
将来の需要を予測し、それに応じてリソースを計画します。
変更管理：
システムの変更をコントロールし、リスクを最小限に抑えます。
トイル（単調な作業）の削減：
反復的で手動の作業を特定し、可能な限り自動化または排除します。
DevOpsとの統合：
開発チームと運用チームの協力を促進します。
これらの概念は、システムの信頼性を高め、効率的な運用を実現するために相互に関連し合っています。SREチームは、これらの原則を適用することで、大規模で複雑なシステムを効果的に管理し、継続的な改善を図ることができます。
↑の今のところSREの基本的な考えは以下だと思っています。
詳細な内容に関しては、以下の本を買って勉強したのちアウトプットしていこうかなと思います。
暑く燃える一日でした。今週もお疲れ様でした。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？