SREを「続けていく」あなたへ

Transcript

1. SREを「続けていく」あなたへ @Money Forward SRE Meetup
2. 自己紹介 • taxin ◦ BtoBサービスの会社でSREやってます ◦ GCP、Terraform、Datadog etc. ◦ Twitter: @taxin_tt
3. 今回の勉強会のテーマは 「SREをはじめるあなたへ」です。 SREをこれからはじめようとしている個人や組織に向けて、これまでの私達の苦労や成功体験などを共 有できるような機会にしたい と思っています。 すでにSREとしての活動を続けて来られた方でも同じような課題に共感したり、改めてご自身の SREに対 する考えを見つめ直すような機会になると考えています。
4. 「私達の苦労や成功体験」に紐づく話
5. • 監視周りの整備 • SLI / SLOの策定と運用 • Postmortemの運営と開発チームとの共同実施 • Toilの整理と削減 • Design Doc / Production Readiness Checklistの利用による platformの整備における明文化 etc…
6. 継続は難しい SREのPracticeは正しく理解して「継続する」ことが難しい (SLI / SLO、Postmortem、Toilの削減 …) e.g.) SLI / SLO • サービスへの機能追加・削除などの要因によって SLIのベースとなる部分 (CUJ) は変化する可能性がある • = 継続的に更新しないと、Service levelを適切に表現できなくなる
7. 継続は難しい 一方で、継続の阻害につながる外的要因が発生することも • 緊急対応が必要な差し込みタスク • SREとしての活動より重要度の高いタスク etc…
8. 継続は難しい taxinのダメダメだった経験 • 「xxをやろう！」→ 差し込みのタスクによって 実施予定のタスクがバックログに残ったまま放置される • SREとしての活動自体が形骸化しないように、 SLI/SLOの運用など最低限のタスクは進めていた
9. 継続は難しい ※バックログにアイテムが存在すること自体は悪いことではない = 自分達のサービスやインフラに対して、問題意識を持っていて 　バックログにアイテムを作成することで明文化してる アイテムを放置しない / させないことが大事だけど大変 (放置する中でcontextが失われて取り組みづらくなることも)
10. ここまでは「私達の苦労や成功体験」に紐づく話
11. ここまでは「私達の苦労や成功体験」に紐づく話 → どのようにしたら、もっとうまくやれただろうか?
12. 1. 継続を見据えた取り組み方 SREの文脈で人と時間があればやりたいことは様々出てくる → バックログのアイテムに対して優先度をつけることが非常に重要
13. 1. 継続を見据えた取り組み方 優先度をつけるために何をすればいいのか? 1. 評価における「客観的な評価軸」を得る 2. 自分達が何ができている / できてないのかを把握する (= 開発組織に対するSRE文脈での自己評価)
14. 1. 継続を見据えた取り組み方 優先度をつけるために何をすればいいのか? 1. 評価における「客観的な評価軸」を得る 2. 自分達が何ができている / できてないのかを把握する (= 開発組織に対するSRE文脈での自己評価)
15. 1. 継続を見据えた取り組み方 1. 評価における「客観的な評価軸」を得る • できていないことを自分達で理解している場合はOK (= 評価軸を理解して、できていないと評価してる) • そもそも、「何ができてないのかを理解していない」場合は...?
17. 1. 継続を見据えた取り組み方 ref: https://cloud.google.com/blog/ja/products/gcp/how-to-start-and-assess-your-sre-journey
18. 1. 継続を見据えた取り組み方 ref: https://cloud.google.com/blog/ja/products/gcp/how-to-start-and-assess-your-sre-journey
19. 1. 継続を見据えた取り組み方 1. 評価における「客観的な評価軸」を得る SREチームの評価に役立つレベル別チェックリスト • 我流ではなく、客観的な評価軸を理解するために利用する
20. 1. 継続を見据えた取り組み方 優先度をつけるために何をすればいいのか? 1. 評価における「客観的な評価軸」を得る 2. 自分達が何ができている / できてないのかを把握する (= 開発組織に対するSRE文脈での自己評価)
21. 1. 継続を見据えた取り組み方 2. 自分達が何ができている / できてないのかを把握する (= 開発組織に対するSRE文脈での自己評価) • あるべき状態から比較して、今どのような状態かを確認する • 開発チーム / 組織ごとに「何が必要か」は異なる ◦ 今できていないこと = 今すぐ改善が必要なこと とは限らない ◦ 現状が分かれば優先すべきかは判断しやすい
22. 1. 継続を見据えた取り組み方 3. 優先度の高いものから「小さく」取り組む • 小さく始めることのメリット ◦ 重要度/緊急度の高いタスクが他にある中でも、 小さく切り出せば、隙間時間で比較的取り組みやすい ◦ SREの文化的な側面も考慮すると継続しやすい取り組み方が良い
24. 1. 継続を見据えた取り組み方 3. 優先度の高いものから「小さく」取り組む • 「各項目の 100 % 達成には至らないかもしれません。 それでも、継続していくことが SRE にとって大切だということを、私たちは Google での経験から知っています。」 ref: https://cloud.google.com/blog/ja/products/gcp/how-to-start-and-assess-your-sre-journey
26. 1. 継続を見据えた取り組み方 3. 優先度の高いものから「小さく」取り組む • 「アンチパターン: あきらめるのが早すぎる … （中略）... これは前もって全て達成する必要があるということではなく、 数四半期後に正しい方向へ進むための明確なシナリオが必要ということ です。」 ref: https://static.googleusercontent.com/media/sre.google/ja//static/pdf/jp-enterprise-roadmap-to-sre.pdf
27. 「よし、SRE文脈での課題を整理して優先度を...」
28. 「よし、SRE文脈での課題を整理して優先度を...」 「えっ、SREチームができたんですか。 実はインフラ関連でお願いしたいことがあってですね...」
29. 2. SRE = 何でも屋からの脱却 ※ 個人の経験に基づく意見なので異論はあるかもしれません • SREが触れる技術分野の広範さから、何でも屋のイメージが 持たれると社内からの依頼タスクが増えがち • SREの文脈に照らし合わせて、範囲外のものもある
30. 2. SRE = 何でも屋からの脱却 依頼する人が悪いのではなく、相互理解と期待値の問題 • 自分が知っているほど、他の人はSREのことを知らない • SREはなんでもやるスーパーチームではないと理解してもらう ◦ (正確にいうと「SRE文脈でやるべきこと」はなんでもやる?)
31. 2. SRE = 何でも屋からの脱却 タスクコントロールを行う必要性が発生するとして... Q: じゃあ、SREとして違うと思ったことは全部断ってもいい? A: 正直ベースでは、Yesとは言いづらい SREは開発チームとの協業が中心なので一定の信頼関係を作りたい → どうするか?
33. 2. SRE = 何でも屋からの脱却 12章 多すぎる尺度 より抜粋 • 重要度/優先度は依頼者が所属するチームなどの文脈によって変わる • 文脈を踏まえて整理するためにチームとしての目標 (e.g. SREチームとしてのマニフェスト) が判断の有効手段となる ◦ 1で出てきた優先度の整理にも利用できる ref: https://www.oreilly.co.jp/books/9784873119847/
34. 2. SRE = 何でも屋からの脱却 12章 多すぎる尺度 より抜粋 「一方で、そのタスクを依頼する側は、同じ文脈をもっていないため、依頼に対 する見方が異なる場合があります。 ...(中略)... 目標はその依頼を評価する ための客観的なレンズとなります。」 ref: https://www.oreilly.co.jp/books/9784873119847/
35. 2. SRE = 何でも屋からの脱却 Site Reliability Engineering = 特定のロールに閉じるものではない (Embedded SREはSREの実践パターンの一例) = 権限を移譲して、開発者自身で問題解決できるように 　自律性を促進するのも一つのアプローチ
36. まとめ SREとしての活動を「うまく始めて、続ける」ためには • 継続を念頭において、SREとしての自己評価と優先度の整理を行う • それを足がかりにPracticeをベースに小さく取り組み始める • チーム目標も判断基準として使い、SREとしての動きを決める