Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
はじめの一歩を踏み出したい方へ~SREというロールを担うためにやったこと、学びや反省 / Le...
Search
gonkun
February 24, 2023
3
520
はじめの一歩を踏み出したい方へ~SREというロールを担うためにやったこと、学びや反省 / Let's start the first step to the SRE
gonkun
February 24, 2023
Tweet
Share
More Decks by gonkun
See All by gonkun
20240119_KEDAでスパイク負荷を迎え撃つ。メトリクスとスケジュールドリブンなオートスケールでKubernetes上のプロダクトの信頼性を高めよう/lets_use_keda_for_reliability
gonkun
1
280
20230929_SRE_NEXT_エラーバジェット運用までの取り組み-信頼性の低下に対するアクションを定義しよう / Let's define actions against unreliability
gonkun
2
3.1k
Featured
See All Featured
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.1k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
28
2.1k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
Git: the NoSQL Database
bkeepers
PRO
427
64k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.2k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Building Applications with DynamoDB
mza
91
6.1k
Rails Girls Zürich Keynote
gr2m
94
13k
BBQ
matthewcrist
85
9.4k
Transcript
はじめの一歩を踏み出したい方へ SREというロールを担うためにやったこと、学びや反省
もくじ はじめに 自己紹介 本発表の背景 本題 前提知識の共有 SREチームにジョインしてから取り組んだこと まずは現状を知る モニタリングダッシュボードの整理の話 障害の基準整理の話
おわりに
はじめに • 自己紹介 • 本発表の背景
自己紹介 - 佐々木優太(Sasaki Yuta) - 2022/08にマネーフォワードに入社 - 前職はSIerでSE - やってたこと
- メトリクス/ログの可視化(Elastic Stack) - 性能試験 - すこしだけスクラムチームのDeveloper - 旅行が好き。47都道府県制覇するのが目標 はじめに
本発表の背景 はじめに 私はこんな状況でした - 転職後なので社内のコネクションが無い - 関わるプロダクトに対する知識が少ない - SRE活動に取り組むのは初めて 自分が取り組んできたことが、似たような状況の方の参考になれば嬉しい
本題 • 前提知識の共有 • SREチームにジョインして からの話
マネーフォワードのSRE 本題 > 前提知識の共有
今回はHRのProduct SREの体験談です 本題 > 前提知識の共有
HRのProduct SREが目指していること 本題 > 前提知識の共有 『 SWE自身で信頼性と開発生産性を最大化できる組織』を目指し、 SRE活動を各チームにインストールしています。 等々
今回はクラウド勤怠のProduct SREとしての話です 本題 > 前提知識の共有 等々
入社時におけるクラウド勤怠のSRE活動状況 - Datadogを用いたモニタリング基盤が整備されている - SLI/SLOが実装/計測されている - プロダクトチームもSLI/SLOを理解して、日々ウォッチしている 本題 > 前提知識の共有
あれ、結構進んでる...?
まずは現状を知る まずは最初に思ったことは 「今どんな状況なんだっけ?」 - アプリ/インフラの構成は? - どこまで出来ていて、何が足りないのだろうか? - プロダクトチームは何に困っている? 本題
> SREチームにジョインしてから
まずはキャッチアップから
はじめにやってよかったこと オンボーディング計画に沿って学習と実践 - 今の状態を知る - 過去の経緯を追う - トラブルシューティング/障害解析に積極的に関わる 本題 >
SREチームにジョインしてから > まずは現状を知る
今の状態を知る 本題 > SREチームにジョインしてから > まずは現状を知る > はじめにやってよかったこと - プロダクトのアーキテクチャ図を眺める
- ミドル/インフラ/CI・CD周りの技術スタックを追う - モニタリングの仕組みを確認する - SRE本の内容と今の状態を比べてみる
SRE本の内容と比べてみる > システム信頼性のピラミッドと比べる 本題 > SREチームにジョインしてから > まずは現状を知る > はじめにやってよかったこと
引用:https://sre.google/sre-book/part-III-practices/ どこまで出来ていて、何が足りないのかを考える上で参考になる ↓ - Datadogを活用したMonitoringの土台がある - インシデント対応の仕組みが整備されている - 大きな障害発生時にはPostmortemが執筆されている
過去の経緯を追う 本題 > SREチームにジョインしてから > まずは現状を知る > はじめにやってよかったこと - 今のアーキテクチャに至るまでの経緯を聞く
- SLI/SLOの実装経緯を追う - ポストモーテムを読み込む
雰囲気は分かってきたけど 具体的なことはまだまだ分からない
あとは実践あるのみ
トラブルシューティング/障害解析に積極的に関わる 本題 > SREチームにジョインしてから > まずは現状を知る > はじめにやってよかったこと 入社当初から怪しいアラートがあればひたすら追っていました
ふりかえり 本題 > SREチームにジョインしてから > まずは現状を知る > はじめにやってよかったこと - オンボーディング計画に沿って学習と実践を積みました
- チームにジョインする側としてはとてもありがたい - アラートをひたすらに追いかけるのも大事 - プロダクトの理解が深まった - どこに何の情報があるのか感覚的に掴めてくる
ちょっと分かってきたところで 小さな改善にチャレンジ
モニタリングダッシュボードを改善 課題感 - ダッシュボードに配置されているものの使われていないグラフがある - 解析を進める上で足りない情報がある やったこと ダッシュボード上のグラフを整理 (細かすぎるのもBADだと思うので、一概にこれが良いとは限らないです) -
グラフの見せ方を改善 - アラート解析時に有用だった情報をダッシュボードに載せた 本題 > SREチームにジョインしてから > モニタリングダッシュボードの整理の話
1つのグラフ内に情報量が多すぎるパターン 本題 > SREチームにジョインしてから > モニタリングダッシュボードの整理の話 Before
意味のある塊ごとにグラフを分割した 本題 > SREチームにジョインしてから > モニタリングダッシュボードの整理の話 After
→ スパイクの発生が分かりやすくなる 過去のデータと比較して並べてみる 本題 > SREチームにジョインしてから > モニタリングダッシュボードの整理の話
解析時に使ったグラフをダッシュボードに組み込む 本題 > SREチームにジョインしてから > モニタリングダッシュボードの整理の話
解析時に使ったグラフをダッシュボードに組み込む 本題 > SREチームにジョインしてから > モニタリングダッシュボードの整理の話 解析中に有用だった情報はダッシュボードへ逆輸入
ふりかえり - プロダクトチームが調査を進める上で困らないようダッシュボードを改善 - アラートをひたすらに追いかける経験が生かされる - (学びと反省)プロダクトチームの習熟度に合わせて、ダッシュボードを進化させる のが大事 - 勝手に変更し過ぎると、他のメンバーが使えなくなる
本題 > SREチームにジョインしてから > モニタリングダッシュボードの整理の話
次は障害の基準の話
障害の基準整理の話 課題感 信頼性の低下に関わる事象が発生していても、 対応の優先度が上がりきらないことがある ⇒ SLOを元に、開発と信頼性のバランスを取った意思決定をしたい やったこと SLOが基準値を下回った際のアクションを定め、関係者と認識を合わせた 本題 >
SREチームにジョインしてから
障害の基準整理の話 どうやって決めていこう...? というときに、ワークブックが大活躍 本題 > SREチームにジョインしてから
エラーバジェット枯渇時のアクション(エラーバジェットポリシー)を定めた 本題 > SREチームにジョインしてから > 障害の基準整理の話
エラーバジェット枯渇時のアクション(エラーバジェットポリシー)を定めた 本題 > SREチームにジョインしてから > 障害の基準整理の話
実際にエラーバジェットポリシーが発動することも 本題 > SREチームにジョインしてから > 障害の基準整理の話
とはいえ、まだまだ改善も必要 (四半期に一度見直してます)
そんなこんなで SREのはじめの一歩を踏み出してきました
おわりに
取り組んだこと - オンボーディング計画に沿って学習と実践を重ねた - 現状や課題への理解が深まったところで小さい改善をスタート 学び - プロダクトに関わりまくって理解を深めるのが大事 - SRE本やワークブックは教科書として大活躍
反省 - 作るのもいいが、運用までを見据えなければならない - 「自分が居なくなっても、その取り組みは消滅しないか」我々は考えなければなら ない おわりに
発表は以上です