Tweet
Tweet

Slide 1

Slide 1 text

組織に対してSREを適用するとはどういうことか 株式会社ビズリーチ（Visionalグループ） HRMOS事業部 SREマネージャー 國井 匡生

Slide 2

Slide 2 text

名前: 國井 匡生（くにい まさお） 所属: 株式会社ビズリーチ（Visionalグループ） HRMOS事業部 職業: SRE マネージャー（雑務） 趣味: 子供にアジャイルを教えること 自己紹介

Slide 3

Slide 3 text

設立 ：2020年2月（ビジョナル株式会社設立） 創業 ：2009年4月（株式会社ビズリーチ創業） 代表者 ：ビジョナル株式会社 代表取締役社長 南 壮一郎 グループ従業員数：1,469名（2021年7月末時点） 資本金 ：164億円（資本準備金含む）※2021年5月18日時点 拠点 ：東京、大阪、名古屋、福岡、静岡、広島 グループ概要

Slide 4

Slide 4 text

グループミッション

Slide 5

Slide 5 text

グループ運営サービス インキュベーション（新規事業領域） 採用プラットフォーム 人財活用プラットフォーム 人材マネジメント（HR Tech）エコシステム 事業承継M&A 物流Tech Sales Tech サイバーセキュリティ

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

プロダクト開発組織をシステムと捉えたときにSREの見地から何が見えるか 今日話すこと

Slide 10

Slide 10 text

● コンピュータシステムに対するSREのプラクティス ● 一般的なチームビルディングやマネージメント的なこと 話さないこと

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

● プロダクトはどこから生まれる？ ○ プロダクトを作るのも運用するのも 人 ○ 大抵の場合、1人ではなく複数人の 組織 なぜ組織の話をするのか

Slide 13

Slide 13 text

● 信頼性とは “「［システムが］求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こす ことなく実行する確率」“ Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (xiv). なぜ組織の話をするのか

Slide 14

Slide 14 text

● 組織の信頼性とは “「［システムが］求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こす ことなく実行する確率」“ Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (xiv). 求められる機能 = プロダクトを作り、提供し、運用する なぜ組織の話をするのか

Slide 15

Slide 15 text

● 組織の信頼性とは “「［システムが］求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こす ことなく実行する確率」“ Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (xiv). 求められる機能 = プロダクトを作り、提供し、運用する 定められた条件 = プロダクトの提供が続く限り なぜ組織の話をするのか

Slide 16

Slide 16 text

● 組織の信頼性とは “「［システムが］求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こす ことなく実行する確率」“ Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (xiv). 求められる機能 = プロダクトを作り、提供し、運用する 定められた条件 = プロダクトの提供が続く限り 定められた期間 = プロダクトの使命を果たすまで なぜ組織の話をするのか

Slide 17

Slide 17 text

● 組織の信頼性とは “「［システムが］求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こす ことなく実行する確率」“ Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (xiv). 求められる機能 = プロダクトを作り、提供し、運用する 定められた条件 = プロダクトの提供が続く限り 定められた期間 = プロダクトの使命を果たすまで 障害 = プロダクト開発、運用ができない状態になる なぜ組織の話をするのか

Slide 18

Slide 18 text

● 信頼性の低い組織から信頼性の高いプロダクトが生まれるだろうか プロダクト開発、運用ができない状態になりがちな組織が 高い品質を担保できる状態になることは考えにくい なぜ組織の話をするのか

Slide 19

Slide 19 text

“SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるもの” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.5). 運用ではなく、運用チームの話 SREのおさらい

Slide 20

Slide 20 text

“実際のところ、ソフトウエア開発上の問題の多くは、技術的というより社会学的なものである。” トム デマルコ；ティモシー リスター. ピープルウエア 第3版 (p.28) ソフトウェアを作るのも運用するのもピープルウェア 組織をコンピュータシステムと捉える

Slide 21

Slide 21 text

• マシン = 人 • サーバー = 役割、仕事 • クラスタ = チーム、組織 • データ = 人やチームの知識、記憶、文化 • SRE = マネージャーや組織長、チーム自身 組織をコンピュータシステムと捉える システム

Slide 22

Slide 22 text

組織は人、 しかし、人をコンピュータとして捉えたとき、信頼性はとても低い • 期待した動作をさせるのは困難 • 人には人生があり、ずっとそこにいるとは限らない 組織をコンピュータシステムと捉える

Slide 23

Slide 23 text

クラスタとして信頼性を高めるにはどうしたらいいだろうか？ 組織をコンピュータシステムと捉える

Slide 24

Slide 24 text

と言っても人を機械のように扱うという話ではないです 組織をコンピュータシステムと捉える

Slide 25

Slide 25 text

プロダクトの成長と共に開発組織の人数は変わっていく プロダクトと開発組織のタイムライン 時間 人数 ※特定のプロダクトの話ではなく一般論です

Slide 26

Slide 26 text

プロダクトの成長と共に開発組織の人数は変わっていく プロダクトと開発組織のタイムライン 時間 人数 立ち上がり期 少ない人数で開発・運用しているため、多 少の暗黙のルールがあっても品質はある 程度保たれている。 ドキュメントは少なく、属人化が激しい。

Slide 27

Slide 27 text

プロダクトの成長と共に開発組織の人数は変わっていく プロダクトと開発組織のタイムライン 時間 人数 立ち上がり期 急成長期 コミュニケーションコストが膨大になり、暗 黙知は完全に意味をなさなくなる。 品質は劇的に下がる。 複数のチームに分割される。 明文化されたルールや品質向上の取り組 みが検討され始める

Slide 28

Slide 28 text

プロダクトの成長と共に開発組織の人数は変わっていく プロダクトと開発組織のタイムライン 時間 人数 立ち上がり期 急成長期 飽和期 ある程度のルールが生まれるも、圧倒的 な人数によって足並みは揃わず、混乱が 続く

Slide 29

Slide 29 text

プロダクトの成長と共に開発組織の人数は変わっていく プロダクトと開発組織のタイムライン 時間 人数 立ち上がり期 急成長期 飽和期 調整期 立ち上がり期にいた人、やり切った感が出 てきた人が一気にいなくなり、知識が急速 に失われていく

Slide 30

Slide 30 text

プロダクトの成長と共に開発組織の人数は変わっていく プロダクトと開発組織のタイムライン 時間 人数 立ち上がり期 急成長期 飽和期 調整期 安定期 残った人々の不断の努力により、秩序を取 り戻していく

Slide 31

Slide 31 text

その時チームの中はどうなっているか プロダクトと開発組織のタイムライン １年目

Slide 32

Slide 32 text

その時チームの中はどうなっているか プロダクトと開発組織のタイムライン １年目 2年目

Slide 33

Slide 33 text

その時チームの中はどうなっているか プロダクトと開発組織のタイムライン １年目 2年目 3年目

Slide 34

Slide 34 text

その時チームの中はどうなっているか プロダクトと開発組織のタイムライン １年目 2年目 3年目 4年目

Slide 35

Slide 35 text

その時チームの中はどうなっているか プロダクトと開発組織のタイムライン １年目 2年目 3年目 4年目 5年目

Slide 36

Slide 36 text

その時チームの中はどうなっているか プロダクトと開発組織のタイムライン １年目 2年目 3年目 4年目 5年目 6年目

Slide 37

Slide 37 text

• メンバーは4年くらいするといなくなっている可能性が高い • 知識も文化も失われ続ける プロダクトと開発組織のタイムライン １年目 2年目 3年目 4年目 5年目 6年目

Slide 38

Slide 38 text

我々はSREを定着させようとしている もしその情熱を持った人たちがいなくなってしまったら、文化は残るのだろうか

Slide 39

Slide 39 text

SREの原理原則を振り返る

Slide 40

Slide 40 text

SREのキーワードは持続可能であること SREの原理原則を振り返る

Slide 41

Slide 41 text

• リスクの受容 • サービスレベル目標 • トイルの撲滅 • モニタリング • 自動化 • リリースエンジニアリング • 単純さ 原則

Slide 42

Slide 42 text

開発組織におけるリスクとは • 認知能力の限界 • 疲労 • 感情 • チームからの人の離脱 など それらは当然にあるものとして考える 原則 -リスクの受容

Slide 43

Slide 43 text

組織におけるSLI/SLOとは • チームの目標 • チーム / メンバーの負荷 • オンボーディングの達成 • 課題の解消速度 • etc… 原則 - SLO

Slide 44

Slide 44 text

”日常的に繰り返される運用上の作業であり、 永続的な価値を生み出さず、サービスの成長に比例してスケールするもの” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.25). 組織におけるトイルとは • マネージャーとのコミュニケーション 原則 -トイルの撲滅

Slide 45

Slide 45 text

”日常的に繰り返される運用上の作業であり、 永続的な価値を生み出さず、サービスの成長に比例してスケールするもの” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.25). 組織におけるトイルとは • マネージャーとのコミュニケーション • チームに権限を移譲しよう 原則 -トイルの撲滅

Slide 46

Slide 46 text

”日常的に繰り返される運用上の作業であり、 永続的な価値を生み出さず、サービスの成長に比例してスケールするもの” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.25). 組織におけるトイルとは • マネージャーとのコミュニケーション • チームに権限を移譲しよう • 暗黙知の伝達 原則 -トイルの撲滅

Slide 47

Slide 47 text

”日常的に繰り返される運用上の作業であり、 永続的な価値を生み出さず、サービスの成長に比例してスケールするもの” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.25). 組織におけるトイルとは • マネージャーとのコミュニケーション • チームに権限を移譲しよう • 暗黙知の伝達 • “準備とドキュメンテーションの価値を信じること” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (xvi). 原則 -トイルの撲滅

Slide 48

Slide 48 text

組織の何を可視化すべきだろうか • バス（トラック）係数 原則 - モニタリング

Slide 49

Slide 49 text

組織の何を可視化すべきだろうか • バス（トラック）係数 • 属人化した状態はRAID0と同じ 原則 - モニタリング

Slide 50

Slide 50 text

組織の何を可視化すべきだろうか • バス（トラック）係数 • 属人化した状態はRAID0と同じ • 目標の達成度 原則 - モニタリング

Slide 51

Slide 51 text

組織の何を可視化すべきだろうか • バス（トラック）係数 • 属人化した状態はRAID0と同じ • 目標の達成度 • SREの習熟度 • https://cloud.google.com/blog/ja/products/gcp/how-to-start-and-assess-your-sre-journey 原則 - モニタリング

Slide 52

Slide 52 text

組織の何を可視化すべきだろうか • バス（トラック）係数 • 属人化した状態はRAID0と同じ • 目標の達成度 • SREの習熟度 • https://cloud.google.com/blog/ja/products/gcp/how-to-start-and-assess-your-sre-journey • 重要だが緊急でないことがどれだけできているか • トイルの撲滅、運用の自動化、複雑性の低減など 原則 - モニタリング

Slide 53

Slide 53 text

自動化すべきものはチーム • マネージャーの指示がないと動かないチームではマネージャーがSPOFになる • 自己組織化されたチームを作ろう • マネージャーをフォローできる人を作ろう 原則 - 自動化

Slide 54

Slide 54 text

組織におけるリリースとは組織の変更 • オンボーディングプロセスは明確か。改善し更新され続けているか • 組織体制の変更は小さく計画を立てて実行されているか 原則 -リリースエンジニアリング

Slide 55

Slide 55 text

“正常に動作する複雑なシステムは、例外なく正常に動作する単純なシステムから発展したものである” ゴールの法則 • 組織は制御可能な人数か • 7±2、6±3、2 pizza team 原則 - 単純さ

Slide 56

Slide 56 text

“正常に動作する複雑なシステムは、例外なく正常に動作する単純なシステムから発展したものである。” ゴールの法則 • 組織は制御可能な人数か • 7±2、6±3、2 pizza team • コンポーネントチームが生まれていないか • コンポーネントチームは作業の複雑性を生む 原則 - 単純さ

Slide 57

Slide 57 text

“正常に動作する複雑なシステムは、例外なく正常に動作する単純なシステムから発展したものである。” ゴールの法則 • 組織は制御可能な人数か • 7±2、6±3、2 pizza team • コンポーネントチームが生まれていないか • コンポーネントチームは作業の複雑性を生む • サイロが生まれていないか • 透明性のない状態では全てが不確実になる 原則 - 単純さ

Slide 58

Slide 58 text

“正常に動作する複雑なシステムは、例外なく正常に動作する単純なシステムから発展したものである。” ゴールの法則 • 組織は制御可能な人数か • 7±2、6±3、2 pizza team… • コンポーネントチームが生まれていないか • コンポーネントチームは作業の複雑性を生む • サイロが生まれていないか • 透明性のない状態では全てが不確実になる • コミュニケーションパスが迂回路を通っていないか • 間に挟まっている人（MITM）がいるとパケットロスが発生する 原則 - 単純さ

Slide 59

Slide 59 text

• 初心者の心構えを忘れないこと • 信頼しつつも検証を • 願望は戦略にあらず • 多層防御 データの完全性に対するSREの一般原則

Slide 60

Slide 60 text

• 初心者の心構えを忘れないこと • その組織がどういう組織で何を目指しているのか明文化されているか • ミッションやビジョン、価値基準、ルール、評価基準が明確か データの完全性に対するSREの一般原則

Slide 61

Slide 61 text

• 信頼しつつも検証を • うまくチームが動いているか確認をしているか • チームは自分達の働き方を振り返っているか。その雰囲気はどうだろうか。 • 1 on 1やパルスサーベイなどでチームの状態を把握しているか データの完全性に対するSREの一般原則

Slide 62

Slide 62 text

• 願望は戦略にあらず • 組織がうまくいかないことを考慮しているか • 誰かがいなくなった時に問題がないか検証できているか（カオスエンジニアリング） データの完全性に対するSREの一般原則

Slide 63

Slide 63 text

• 多層防御 • チーム内でフォローしあえる状態になっているか • マネージャーをフォローできる人はいるか データの完全性に対するSREの一般原則

Slide 64

Slide 64 text

#1 SREは結果を伴うSLOを必要とする #2 SREは、明日を今日よりも良くするための時間を持たなければならない #3 SREチームは作業負荷を調整できる能力を持っている 原理

Slide 65

Slide 65 text

#1 SREは結果を伴うSLOを必要とする • マネージャーやチーム自身は課題に対する意思決定をし、結果をもたらすのに十分な権限があるか？ • チームの状態を把握できているか？ 原理

Slide 66

Slide 66 text

#2 SREは、明日を今日よりも良くするための時間を持たなければならない • チームの力を十分に発揮することやプロダクトについての意思決定のために時間を使えているか？ 原理

Slide 67

Slide 67 text

#3 SREチームは作業負荷を調整できる能力を持っている • 承認を得たり調整事をしたりすることに忙殺されていないか？ • 兼務によってオーバーヘッドが増えていないか？ • もし負荷が高いのであれば、それを調整可能だろうか？ 原理

Slide 68

Slide 68 text

No content

Slide 69

Slide 69 text

• 信頼性が高いプロダクトを作るためには組織が安定した状態で稼働している必要がある • 知識や文化は失われていくので全てを明示する必要がある • チームは自己組織化され、自身で目標を立て行動し、マネージャーの指示を必要としない • スクラムやXPを実践するのは良いアイデア • SREの原則やプラクティスがどう組織に適用できるか考えてみると新しい発見があるかも • 紹介したもの以外にもtimeout、retry、circuit breaker、 back pressure、shed load、bulkhead、 graceful degradationなどパターンが組織においてどういう意味を持つか考えてみると面白い まとめ

Slide 70

Slide 70 text

• 何よりも重要なのは採用 • 文化を受け入れること（クラスタリング）ができなければ組織は不安定にな ってしまう • お互いに受け入れられ、同じ価値基準とSLOを共有できる人と共に仕事をし よう まとめ

Slide 71

Slide 71 text

No content

Slide 72

Slide 72 text

ここで話しきれなかった背景や詳細は弊社のエンジニ アブログで公開予定です。 https://engineering.visional.inc/blog/

Slide 73

Slide 73 text

ありがとうございました！