Tweet
Tweet

Slide 1

Slide 1 text

SREを「続けていく」あなたへ @Money Forward SRE Meetup

Slide 2

Slide 2 text

自己紹介 ● taxin ○ BtoBサービスの会社でSREやってます ○ GCP、Terraform、Datadog etc. ○ Twitter: @taxin_tt

Slide 3

Slide 3 text

今回の勉強会のテーマは 「SREをはじめるあなたへ」です。 SREをこれからはじめようとしている個人や組織に向けて、これまでの私達の苦労や成功体験などを共 有できるような機会にしたい と思っています。 すでにSREとしての活動を続けて来られた方でも同じような課題に共感したり、改めてご自身の SREに対 する考えを見つめ直すような機会になると考えています。

Slide 4

Slide 4 text

「私達の苦労や成功体験」に紐づく話

Slide 5

Slide 5 text

● 監視周りの整備 ● SLI / SLOの策定と運用 ● Postmortemの運営と開発チームとの共同実施 ● Toilの整理と削減 ● Design Doc / Production Readiness Checklistの利用による platformの整備における明文化 etc…

Slide 6

Slide 6 text

継続は難しい SREのPracticeは正しく理解して「継続する」ことが難しい (SLI / SLO、Postmortem、Toilの削減 …) e.g.) SLI / SLO ● サービスへの機能追加・削除などの要因によって SLIのベースとなる部分 (CUJ) は変化する可能性がある ● = 継続的に更新しないと、Service levelを適切に表現できなくなる

Slide 7

Slide 7 text

継続は難しい 一方で、継続の阻害につながる外的要因が発生することも ● 緊急対応が必要な差し込みタスク ● SREとしての活動より重要度の高いタスク etc…

Slide 8

Slide 8 text

継続は難しい taxinのダメダメだった経験 ● 「xxをやろう！」→ 差し込みのタスクによって 実施予定のタスクがバックログに残ったまま放置される ● SREとしての活動自体が形骸化しないように、 SLI/SLOの運用など最低限のタスクは進めていた

Slide 9

Slide 9 text

継続は難しい ※バックログにアイテムが存在すること自体は悪いことではない = 自分達のサービスやインフラに対して、問題意識を持っていて 　バックログにアイテムを作成することで明文化してる アイテムを放置しない / させないことが大事だけど大変 (放置する中でcontextが失われて取り組みづらくなることも)

Slide 10

Slide 10 text

ここまでは「私達の苦労や成功体験」に紐づく話

Slide 11

Slide 11 text

ここまでは「私達の苦労や成功体験」に紐づく話 → どのようにしたら、もっとうまくやれただろうか?

Slide 12

Slide 12 text

1. 継続を見据えた取り組み方 SREの文脈で人と時間があればやりたいことは様々出てくる → バックログのアイテムに対して優先度をつけることが非常に重要

Slide 13

Slide 13 text

1. 継続を見据えた取り組み方 優先度をつけるために何をすればいいのか? 1. 評価における「客観的な評価軸」を得る 2. 自分達が何ができている / できてないのかを把握する (= 開発組織に対するSRE文脈での自己評価)

Slide 14

Slide 14 text

1. 継続を見据えた取り組み方 優先度をつけるために何をすればいいのか? 1. 評価における「客観的な評価軸」を得る 2. 自分達が何ができている / できてないのかを把握する (= 開発組織に対するSRE文脈での自己評価)

Slide 15

Slide 15 text

1. 継続を見据えた取り組み方 1. 評価における「客観的な評価軸」を得る ● できていないことを自分達で理解している場合はOK (= 評価軸を理解して、できていないと評価してる) ● そもそも、「何ができてないのかを理解していない」場合は...?

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

1. 継続を見据えた取り組み方 ref: https://cloud.google.com/blog/ja/products/gcp/how-to-start-and-assess-your-sre-journey

Slide 18

Slide 18 text

1. 継続を見据えた取り組み方 ref: https://cloud.google.com/blog/ja/products/gcp/how-to-start-and-assess-your-sre-journey

Slide 19

Slide 19 text

1. 継続を見据えた取り組み方 1. 評価における「客観的な評価軸」を得る SREチームの評価に役立つレベル別チェックリスト ● 我流ではなく、客観的な評価軸を理解するために利用する

Slide 20

Slide 20 text

1. 継続を見据えた取り組み方 優先度をつけるために何をすればいいのか? 1. 評価における「客観的な評価軸」を得る 2. 自分達が何ができている / できてないのかを把握する (= 開発組織に対するSRE文脈での自己評価)

Slide 21

Slide 21 text

1. 継続を見据えた取り組み方 2. 自分達が何ができている / できてないのかを把握する (= 開発組織に対するSRE文脈での自己評価) ● あるべき状態から比較して、今どのような状態かを確認する ● 開発チーム / 組織ごとに「何が必要か」は異なる ○ 今できていないこと = 今すぐ改善が必要なこと とは限らない ○ 現状が分かれば優先すべきかは判断しやすい

Slide 22

Slide 22 text

1. 継続を見据えた取り組み方 3. 優先度の高いものから「小さく」取り組む ● 小さく始めることのメリット ○ 重要度/緊急度の高いタスクが他にある中でも、 小さく切り出せば、隙間時間で比較的取り組みやすい ○ SREの文化的な側面も考慮すると継続しやすい取り組み方が良い

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

1. 継続を見据えた取り組み方 3. 優先度の高いものから「小さく」取り組む ● 「各項目の 100 % 達成には至らないかもしれません。 それでも、継続していくことが SRE にとって大切だということを、私たちは Google での経験から知っています。」 ref: https://cloud.google.com/blog/ja/products/gcp/how-to-start-and-assess-your-sre-journey

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

1. 継続を見据えた取り組み方 3. 優先度の高いものから「小さく」取り組む ● 「アンチパターン: あきらめるのが早すぎる … （中略）... これは前もって全て達成する必要があるということではなく、 数四半期後に正しい方向へ進むための明確なシナリオが必要ということ です。」 ref: https://static.googleusercontent.com/media/sre.google/ja//static/pdf/jp-enterprise-roadmap-to-sre.pdf

Slide 27

Slide 27 text

「よし、SRE文脈での課題を整理して優先度を...」

Slide 28

Slide 28 text

「よし、SRE文脈での課題を整理して優先度を...」 「えっ、SREチームができたんですか。 実はインフラ関連でお願いしたいことがあってですね...」

Slide 29

Slide 29 text

2. SRE = 何でも屋からの脱却 ※ 個人の経験に基づく意見なので異論はあるかもしれません ● SREが触れる技術分野の広範さから、何でも屋のイメージが 持たれると社内からの依頼タスクが増えがち ● SREの文脈に照らし合わせて、範囲外のものもある

Slide 30

Slide 30 text

2. SRE = 何でも屋からの脱却 依頼する人が悪いのではなく、相互理解と期待値の問題 ● 自分が知っているほど、他の人はSREのことを知らない ● SREはなんでもやるスーパーチームではないと理解してもらう ○ (正確にいうと「SRE文脈でやるべきこと」はなんでもやる?)

Slide 31

Slide 31 text

2. SRE = 何でも屋からの脱却 タスクコントロールを行う必要性が発生するとして... Q: じゃあ、SREとして違うと思ったことは全部断ってもいい? A: 正直ベースでは、Yesとは言いづらい SREは開発チームとの協業が中心なので一定の信頼関係を作りたい → どうするか?

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

2. SRE = 何でも屋からの脱却 12章 多すぎる尺度 より抜粋 ● 重要度/優先度は依頼者が所属するチームなどの文脈によって変わる ● 文脈を踏まえて整理するためにチームとしての目標 (e.g. SREチームとしてのマニフェスト) が判断の有効手段となる ○ 1で出てきた優先度の整理にも利用できる ref: https://www.oreilly.co.jp/books/9784873119847/

Slide 34

Slide 34 text

2. SRE = 何でも屋からの脱却 12章 多すぎる尺度 より抜粋 「一方で、そのタスクを依頼する側は、同じ文脈をもっていないため、依頼に対 する見方が異なる場合があります。 ...(中略)... 目標はその依頼を評価する ための客観的なレンズとなります。」 ref: https://www.oreilly.co.jp/books/9784873119847/

Slide 35

Slide 35 text

2. SRE = 何でも屋からの脱却 Site Reliability Engineering = 特定のロールに閉じるものではない (Embedded SREはSREの実践パターンの一例) = 権限を移譲して、開発者自身で問題解決できるように 　自律性を促進するのも一つのアプローチ

Slide 36

Slide 36 text

まとめ SREとしての活動を「うまく始めて、続ける」ためには ● 継続を念頭において、SREとしての自己評価と優先度の整理を行う ● それを足がかりにPracticeをベースに小さく取り組み始める ● チーム目標も判断基準として使い、SREとしての動きを決める