[SRE NEXT 2022]組織に対してSREを適用するとはどういうことか

SRE NEXT 2022
https://sre-next.dev/2022/

[Speaker]
Visional（株式会社ビズリーチ） HRMOSプロダクト本部 SREグループ Manager: 國井 匡生

[Description]
Site Reliability Engineeringには原則があり、今日では様々なプラクティスや事例が紹介されています。しかし、最初のSRE本にも書いてあるにもかかわらず、SREを実践する人々の人間的側面についてはあまり語られません。どのようなシステムもそれを作るのも運用するのも人であり（SREが目指すのが運用をなくすことだとしても）、大抵の場合、一人ではなく組織としてシステムを作っています。信頼性の低い組織からは信頼性の高いシステムは生まれることは考えにくく、組織に対してSREを適用すると考えると見えてくることがあります。
このセッションでは組織がどうやって信頼性を保つことができるかを、チーム発足から5年間の教訓をもとに紹介します。

Transcript

1. 組織に対してSREを適用するとはどういうことか 株式会社ビズリーチ（Visionalグループ） HRMOS事業部 SREマネージャー 國井 匡生
2. 名前: 國井 匡生（くにい まさお） 所属: 株式会社ビズリーチ（Visionalグループ） HRMOS事業部 職業: SRE マネージャー（雑務） 趣味: 子供にアジャイルを教えること 自己紹介
3. 設立 ：2020年2月（ビジョナル株式会社設立） 創業 ：2009年4月（株式会社ビズリーチ創業） 代表者 ：ビジョナル株式会社 代表取締役社長 南 壮一郎 グループ従業員数：1,469名（2021年7月末時点） 資本金 ：164億円（資本準備金含む）※2021年5月18日時点 拠点 ：東京、大阪、名古屋、福岡、静岡、広島 グループ概要
4. グループミッション
5. グループ運営サービス インキュベーション（新規事業領域） 採用プラットフォーム 人財活用プラットフォーム 人材マネジメント（HR Tech）エコシステム 事業承継M&A 物流Tech Sales Tech サイバーセキュリティ
9. プロダクト開発組織をシステムと捉えたときにSREの見地から何が見えるか 今日話すこと
10. • コンピュータシステムに対するSREのプラクティス • 一般的なチームビルディングやマネージメント的なこと 話さないこと
12. • プロダクトはどこから生まれる？ ◦ プロダクトを作るのも運用するのも 人 ◦ 大抵の場合、1人ではなく複数人の 組織 なぜ組織の話をするのか
13. • 信頼性とは “「［システムが］求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こす ことなく実行する確率」“ Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (xiv). なぜ組織の話をするのか
14. • 組織の信頼性とは “「［システムが］求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こす ことなく実行する確率」“ Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (xiv). 求められる機能 = プロダクトを作り、提供し、運用する なぜ組織の話をするのか
15. • 組織の信頼性とは “「［システムが］求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こす ことなく実行する確率」“ Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (xiv). 求められる機能 = プロダクトを作り、提供し、運用する 定められた条件 = プロダクトの提供が続く限り なぜ組織の話をするのか
16. • 組織の信頼性とは “「［システムが］求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こす ことなく実行する確率」“ Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (xiv). 求められる機能 = プロダクトを作り、提供し、運用する 定められた条件 = プロダクトの提供が続く限り 定められた期間 = プロダクトの使命を果たすまで なぜ組織の話をするのか
17. • 組織の信頼性とは “「［システムが］求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こす ことなく実行する確率」“ Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (xiv). 求められる機能 = プロダクトを作り、提供し、運用する 定められた条件 = プロダクトの提供が続く限り 定められた期間 = プロダクトの使命を果たすまで 障害 = プロダクト開発、運用ができない状態になる なぜ組織の話をするのか
18. • 信頼性の低い組織から信頼性の高いプロダクトが生まれるだろうか プロダクト開発、運用ができない状態になりがちな組織が 高い品質を担保できる状態になることは考えにくい なぜ組織の話をするのか
19. “SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるもの” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.5). 運用ではなく、運用チームの話 SREのおさらい
20. “実際のところ、ソフトウエア開発上の問題の多くは、技術的というより社会学的なものである。” トム デマルコ；ティモシー リスター. ピープルウエア 第3版 (p.28) ソフトウェアを作るのも運用するのもピープルウェア 組織をコンピュータシステムと捉える
21. • マシン = 人 • サーバー = 役割、仕事 • クラスタ = チーム、組織 • データ = 人やチームの知識、記憶、文化 • SRE = マネージャーや組織長、チーム自身 組織をコンピュータシステムと捉える システム
22. 組織は人、 しかし、人をコンピュータとして捉えたとき、信頼性はとても低い • 期待した動作をさせるのは困難 • 人には人生があり、ずっとそこにいるとは限らない 組織をコンピュータシステムと捉える
23. クラスタとして信頼性を高めるにはどうしたらいいだろうか？ 組織をコンピュータシステムと捉える
24. と言っても人を機械のように扱うという話ではないです 組織をコンピュータシステムと捉える
25. プロダクトの成長と共に開発組織の人数は変わっていく プロダクトと開発組織のタイムライン 時間 人数 ※特定のプロダクトの話ではなく一般論です
26. プロダクトの成長と共に開発組織の人数は変わっていく プロダクトと開発組織のタイムライン 時間 人数 立ち上がり期 少ない人数で開発・運用しているため、多 少の暗黙のルールがあっても品質はある 程度保たれている。 ドキュメントは少なく、属人化が激しい。
27. プロダクトの成長と共に開発組織の人数は変わっていく プロダクトと開発組織のタイムライン 時間 人数 立ち上がり期 急成長期 コミュニケーションコストが膨大になり、暗 黙知は完全に意味をなさなくなる。 品質は劇的に下がる。 複数のチームに分割される。 明文化されたルールや品質向上の取り組 みが検討され始める
28. プロダクトの成長と共に開発組織の人数は変わっていく プロダクトと開発組織のタイムライン 時間 人数 立ち上がり期 急成長期 飽和期 ある程度のルールが生まれるも、圧倒的 な人数によって足並みは揃わず、混乱が 続く
29. プロダクトの成長と共に開発組織の人数は変わっていく プロダクトと開発組織のタイムライン 時間 人数 立ち上がり期 急成長期 飽和期 調整期 立ち上がり期にいた人、やり切った感が出 てきた人が一気にいなくなり、知識が急速 に失われていく
30. プロダクトの成長と共に開発組織の人数は変わっていく プロダクトと開発組織のタイムライン 時間 人数 立ち上がり期 急成長期 飽和期 調整期 安定期 残った人々の不断の努力により、秩序を取 り戻していく
31. その時チームの中はどうなっているか プロダクトと開発組織のタイムライン １年目
32. その時チームの中はどうなっているか プロダクトと開発組織のタイムライン １年目 2年目
33. その時チームの中はどうなっているか プロダクトと開発組織のタイムライン １年目 2年目 3年目
34. その時チームの中はどうなっているか プロダクトと開発組織のタイムライン １年目 2年目 3年目 4年目
35. その時チームの中はどうなっているか プロダクトと開発組織のタイムライン １年目 2年目 3年目 4年目 5年目
36. その時チームの中はどうなっているか プロダクトと開発組織のタイムライン １年目 2年目 3年目 4年目 5年目 6年目
37. • メンバーは4年くらいするといなくなっている可能性が高い • 知識も文化も失われ続ける プロダクトと開発組織のタイムライン １年目 2年目 3年目 4年目 5年目 6年目
38. 我々はSREを定着させようとしている もしその情熱を持った人たちがいなくなってしまったら、文化は残るのだろうか
39. SREの原理原則を振り返る
40. SREのキーワードは持続可能であること SREの原理原則を振り返る
41. • リスクの受容 • サービスレベル目標 • トイルの撲滅 • モニタリング • 自動化 • リリースエンジニアリング • 単純さ 原則
42. 開発組織におけるリスクとは • 認知能力の限界 • 疲労 • 感情 • チームからの人の離脱 など それらは当然にあるものとして考える 原則 -リスクの受容
43. 組織におけるSLI/SLOとは • チームの目標 • チーム / メンバーの負荷 • オンボーディングの達成 • 課題の解消速度 • etc… 原則 - SLO
44. ”日常的に繰り返される運用上の作業であり、 永続的な価値を生み出さず、サービスの成長に比例してスケールするもの” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.25). 組織におけるトイルとは • マネージャーとのコミュニケーション 原則 -トイルの撲滅
45. ”日常的に繰り返される運用上の作業であり、 永続的な価値を生み出さず、サービスの成長に比例してスケールするもの” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.25). 組織におけるトイルとは • マネージャーとのコミュニケーション • チームに権限を移譲しよう 原則 -トイルの撲滅
46. ”日常的に繰り返される運用上の作業であり、 永続的な価値を生み出さず、サービスの成長に比例してスケールするもの” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.25). 組織におけるトイルとは • マネージャーとのコミュニケーション • チームに権限を移譲しよう • 暗黙知の伝達 原則 -トイルの撲滅
47. ”日常的に繰り返される運用上の作業であり、 永続的な価値を生み出さず、サービスの成長に比例してスケールするもの” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.25). 組織におけるトイルとは • マネージャーとのコミュニケーション • チームに権限を移譲しよう • 暗黙知の伝達 • “準備とドキュメンテーションの価値を信じること” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (xvi). 原則 -トイルの撲滅
48. 組織の何を可視化すべきだろうか • バス（トラック）係数 原則 - モニタリング
49. 組織の何を可視化すべきだろうか • バス（トラック）係数 • 属人化した状態はRAID0と同じ 原則 - モニタリング
50. 組織の何を可視化すべきだろうか • バス（トラック）係数 • 属人化した状態はRAID0と同じ • 目標の達成度 原則 - モニタリング
51. 組織の何を可視化すべきだろうか • バス（トラック）係数 • 属人化した状態はRAID0と同じ • 目標の達成度 • SREの習熟度 • https://cloud.google.com/blog/ja/products/gcp/how-to-start-and-assess-your-sre-journey 原則 - モニタリング
52. 組織の何を可視化すべきだろうか • バス（トラック）係数 • 属人化した状態はRAID0と同じ • 目標の達成度 • SREの習熟度 • https://cloud.google.com/blog/ja/products/gcp/how-to-start-and-assess-your-sre-journey • 重要だが緊急でないことがどれだけできているか • トイルの撲滅、運用の自動化、複雑性の低減など 原則 - モニタリング
53. 自動化すべきものはチーム • マネージャーの指示がないと動かないチームではマネージャーがSPOFになる • 自己組織化されたチームを作ろう • マネージャーをフォローできる人を作ろう 原則 - 自動化
54. 組織におけるリリースとは組織の変更 • オンボーディングプロセスは明確か。改善し更新され続けているか • 組織体制の変更は小さく計画を立てて実行されているか 原則 -リリースエンジニアリング
55. “正常に動作する複雑なシステムは、例外なく正常に動作する単純なシステムから発展したものである” ゴールの法則 • 組織は制御可能な人数か • 7±2、6±3、2 pizza team 原則 - 単純さ
56. “正常に動作する複雑なシステムは、例外なく正常に動作する単純なシステムから発展したものである。” ゴールの法則 • 組織は制御可能な人数か • 7±2、6±3、2 pizza team • コンポーネントチームが生まれていないか • コンポーネントチームは作業の複雑性を生む 原則 - 単純さ
57. “正常に動作する複雑なシステムは、例外なく正常に動作する単純なシステムから発展したものである。” ゴールの法則 • 組織は制御可能な人数か • 7±2、6±3、2 pizza team • コンポーネントチームが生まれていないか • コンポーネントチームは作業の複雑性を生む • サイロが生まれていないか • 透明性のない状態では全てが不確実になる 原則 - 単純さ
58. “正常に動作する複雑なシステムは、例外なく正常に動作する単純なシステムから発展したものである。” ゴールの法則 • 組織は制御可能な人数か • 7±2、6±3、2 pizza team… • コンポーネントチームが生まれていないか • コンポーネントチームは作業の複雑性を生む • サイロが生まれていないか • 透明性のない状態では全てが不確実になる • コミュニケーションパスが迂回路を通っていないか • 間に挟まっている人（MITM）がいるとパケットロスが発生する 原則 - 単純さ
59. • 初心者の心構えを忘れないこと • 信頼しつつも検証を • 願望は戦略にあらず • 多層防御 データの完全性に対するSREの一般原則
60. • 初心者の心構えを忘れないこと • その組織がどういう組織で何を目指しているのか明文化されているか • ミッションやビジョン、価値基準、ルール、評価基準が明確か データの完全性に対するSREの一般原則
61. • 信頼しつつも検証を • うまくチームが動いているか確認をしているか • チームは自分達の働き方を振り返っているか。その雰囲気はどうだろうか。 • 1 on 1やパルスサーベイなどでチームの状態を把握しているか データの完全性に対するSREの一般原則
62. • 願望は戦略にあらず • 組織がうまくいかないことを考慮しているか • 誰かがいなくなった時に問題がないか検証できているか（カオスエンジニアリング） データの完全性に対するSREの一般原則
63. • 多層防御 • チーム内でフォローしあえる状態になっているか • マネージャーをフォローできる人はいるか データの完全性に対するSREの一般原則
64. #1 SREは結果を伴うSLOを必要とする #2 SREは、明日を今日よりも良くするための時間を持たなければならない #3 SREチームは作業負荷を調整できる能力を持っている 原理
65. #1 SREは結果を伴うSLOを必要とする • マネージャーやチーム自身は課題に対する意思決定をし、結果をもたらすのに十分な権限があるか？ • チームの状態を把握できているか？ 原理
66. #2 SREは、明日を今日よりも良くするための時間を持たなければならない • チームの力を十分に発揮することやプロダクトについての意思決定のために時間を使えているか？ 原理
67. #3 SREチームは作業負荷を調整できる能力を持っている • 承認を得たり調整事をしたりすることに忙殺されていないか？ • 兼務によってオーバーヘッドが増えていないか？ • もし負荷が高いのであれば、それを調整可能だろうか？ 原理
69. • 信頼性が高いプロダクトを作るためには組織が安定した状態で稼働している必要がある • 知識や文化は失われていくので全てを明示する必要がある • チームは自己組織化され、自身で目標を立て行動し、マネージャーの指示を必要としない • スクラムやXPを実践するのは良いアイデア • SREの原則やプラクティスがどう組織に適用できるか考えてみると新しい発見があるかも • 紹介したもの以外にもtimeout、retry、circuit breaker、 back pressure、shed load、bulkhead、 graceful degradationなどパターンが組織においてどういう意味を持つか考えてみると面白い まとめ
70. • 何よりも重要なのは採用 • 文化を受け入れること（クラスタリング）ができなければ組織は不安定にな ってしまう • お互いに受け入れられ、同じ価値基準とSLOを共有できる人と共に仕事をし よう まとめ
72. ここで話しきれなかった背景や詳細は弊社のエンジニ アブログで公開予定です。 https://engineering.visional.inc/blog/
73. ありがとうございました！