Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

srenext
May 21, 2022

[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年間の教訓をもとに紹介します。

srenext

May 21, 2022
Tweet

More Decks by srenext

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  4. グループミッション

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  35. SREの原理原則を振り返る

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  67. ありがとうございました!

    View full-size slide