組織に対してSREを適用するとどうなるか

どのようなシステムもそれを作るのも運用するのも人であり（SREが目指すのが運用をなくすことだとしても）、大抵の場合、一人ではなく組織としてシステムを作っていますが、信頼性の低い組織からは信頼性の高いシステムは生まれることは考えにくいです。 SRE NEXT 2022で提起した組織に対してSREを適用することでどうやって信頼性を保つことができるかということについて、実際に組織に起きた問題とそれにどういうプラクティスを適用し、どうなったのかを紹介します。

Transcript

1. 組織に対してSREを適用する とどうなるか SRE Lounge #14 
 
 國井 匡生 

2. 自己紹介 名前: 國井 匡生（くにい まさお） 職業: データエンジニア 　　　（元SREマネージャー） 趣味: 子供にアジャイルを教えること
3. 今日話すこと • 組織の信頼性に対してSREを適用することについて • 実際に組織に起きた問題とそれにどういうプラクティスを適用し、どうなったのか ※個人の見解であり、いかなる組織の意見を代表したものではありません
4. 話さないこと • コンピュータシステムに対するSREのプラクティス • 一般的なチームビルディングやマネジメント的なこと
5. SRE NEXT 2022のおさらい
6. なぜ組織の話をするのか • プロダクトはどこから生まれる？ ◦ プロダクトを作るのも運用するのも 人 ◦ 大抵の場合、1人ではなく複数人の 組織
7. なぜ組織の話をするのか 信頼性とは “「［システムが］求められる機能を、定められた条件の下で、定められた期間にわたり、 障害を起こすことなく実行する確率」“ Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (xiv). 求められる機能 = プロダクトを作り、提供し、運用する 定められた条件 = プロダクトの提供が続く限り 定められた期間 = プロダクトの使命を果たすまで 障害 = プロダクト開発、運用ができない状態になる
8. なぜ組織の話をするのか • 信頼性の低い組織から信頼性の高いプロダクトが生まれるだろうか プロダクト開発、運用ができない状態になりがちな組織が 高い品質を担保できる状態になることは考えにくい
9. SREのおさらい “SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるも の” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.5). 運用ではなく、運用チームの話
10. 組織をコンピュータシステムと捉える “実際のところ、ソフトウエア開発上の問題の多くは、技術的というより社会学的なもので ある。” トム デマルコ；ティモシー リスター. ピープルウエア　第 3版 (p.28). ソフトウェアを作るのも運用するのもピープルウェア
11. 組織をコンピュータシステムと捉える “人間は不完全なマシンです。人間は退屈し、十分には理解されていないプロセッサ（場 合によってはUIも）を持ち、あまり効率も良くありません” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.431). 組織は人、 しかし、人をコンピュータとして捉えたとき、信頼性はとても低い • 期待した動作をさせるのは困難 • 人には人生があり、ずっとそこにいるとは限らない
12. 組織をコンピュータシステムと捉える マシン = 人 サーバー = 役割、仕事 クラスタ = チーム、組織 データ = 人やチームの知識、記憶、文化 SRE = マネージャーや組織長、チーム自身 システム
13. プロダクトと開発組織のタイムライン プロダクトの成長と共に開発組織の人数は変わっていく
14. プロダクトと開発組織のタイムライン プロダクトの成長と共に開発組織の人数は変わっていく
15. プロダクトと開発組織のタイムライン プロダクトの成長と共に開発組織の人数は変わっていく
16. プロダクトと開発組織のタイムライン プロダクトの成長と共に開発組織の人数は変わっていく
17. プロダクトと開発組織のタイムライン プロダクトの成長と共に開発組織の人数は変わっていく
18. プロダクトと開発組織のタイムライン プロダクトの成長と共に開発組織の人数は変わっていく
19. プロダクトと開発組織のタイムライン メンバーは4年くらいするといなくなっている可能性が高い 知識も文化も失われ続ける
20. 我々はSREを定着させようとしている もしその情熱を持った人たちがいなくなってしまったら、文化は残るのだろうか
21. こう考えるに至った経緯 SREの概念の難しさ 社内の各事業長やプロダクト開発組織の部長やPO、PM的な人にSREについての説明 をして回っていた。 やってみて思ったことは • 概念が広すぎて簡単に言い表すのが難しい • 簡単に説明しようとすると何かを置き去りにしている気持ちになる • 組織の話とシステムの話で切り離すことで少しわかりやすくなる • 一通りの人に説明し切ると異動や新規事業によってステークホルダーが変わり無 限に説明しなくてはいけない
22. こう考えるに至った経緯 SRE本に書かれているプラクティスのうち、コンピューターシステムにおけるパターンを組織に置き換えたものがあると気づ いた 原理 #3 SREチームは作業負荷を調整できる能力を持っている “最低でもSREの時間の50%はエンジニアリングに費やされるように努めています。オンコールは残りの時間の 25%以上に ならないようにして、他の25%はプロジェクトの作業ではない、他の種類の運用業務のために残せるようにします。 ” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.133). “SREチームには「ページャーの返却」という選択肢もありえます。すなわち、 SREチームの基準を満たせるようになるまで、 開発チームだけがそのシステムのオンコールをしてくれるように要求できるのです。 ” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.137). これはBack pressureやgraceful degradation
23. こう考えるに至った経緯 “低すぎる運用負荷はSREチームにとって望ましくありません。プロダクトとの関わりを持 たない期間が長くなると、自信に関する問題が生じることがあります。” “SREのチームのサイズを調整して、すべてのエンジニアが少なくとも四半期に1回ない し2回はオンコールを担当できるようにして、各チームメンバーが十分にプロダクトに触 れられるようするべきです。” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.138). これはAuto scaling
24. こう考えるに至った経緯 “Google では、お客様に対しても同じようなアプローチが必要だという結論に達しまし た。SRE の原理や教訓をお客様に適用すると、CRE にたどり着くのです。” Google の新しい専門職 : CRE が必要な理由 (https://cloudplatform-jp.googleblog.com/2016/10/google-cre.html).
25. こう考えるに至った経緯 顧客 顧客の顧客 システム 開発組織 SREとされている範囲
26. こう考えるに至った経緯 顧客 顧客の顧客 システム 開発組織 SREとされている範囲 CREの扱う 範囲
27. こう考えるに至った経緯 顧客 顧客の顧客 システム 開発組織 システム的 なSREの扱 う範囲 組織的SRE で扱う範囲 CREの扱う 範囲
28. こう考えるに至った経緯 “究極的には、ユーザーの満足度が問題なのです。... 顧客を満足している状態に保つた めに、私たちはサービスの信頼性を保つのです” Betsy Beyer、Niall Richard Murphy、David K. Rensin、Kent Kawahara、Stephen Thorne. サイトリライアビリティワークブック (p.17). 手段 対象 SLO CRE システム 顧客（と顧客の システム） 顧客の顧客の満 足度 システム的な SRE 開発チーム SREチーム システム 顧客の満足度 組織的なSRE マネージャー チーム 開発チーム SREチーム システムの満足 度？
29. 用語の整理 組織におけるデータ • 人やチームの知識、記憶、文化 組織におけるリリース • 組織に対する変化 ◦ 人員の追加・削減 ◦ やり方やポリシーの変更 ◦ やることの決定
30. 用語の整理 組織における障害 • プロダクト開発、運用ができない状態になる
31. 障害の兆候 • 人が急に増えてカオスになりパフォーマンスや品質が低下する • 認識が揃わず期待通りのものが出来上がらない • 低い品質の結果、開発速度が遅くなる • 人が急にいなくなって手が回らなくなる • 誰かがボトルネックになって進まなくなる • 運用負荷が高すぎて何もできなくなる • 知識が失われてどうしていいかわからなくなる • 目指す方向を見失い迷走する • 無力感に苛まれて辛い気持ちになる • コミュニケーションがしんどすぎて何も言いたくなくなる • 信頼関係が失われ、協力しあえなくなる
32. 障害の兆候 • 人が急に増えてカオスになりパフォーマンスや品質が低下する 事業がうまくいくと人が増える 様々な価値観が持ち込まれる 暗黙的なルールが守られることはなくなる ゴールの認識が揃わず、人々は自己の判断でバラバラな行動をしはじめる
33. 障害の兆候 • 低い品質の結果、開発速度が遅くなる ◦ リリースする度に障害が発生するようなシステムは障害の対応をするためにどんどん開発速度が 遅くなる
34. 障害の兆候 • 人が急にいなくなって手が回らなくなる 理由は何でも人はいなくなる • 過負荷によるもの • キャリアプラン • ライフイベント
35. 障害の兆候 • 誰かがボトルネックになって進まなくなる ◦ 組織の中にSPOF ▪ 人の数 ▪ 知識や能力 ▪ 権限 ◦ そしてそういう人は決まって忙しい
36. 障害の兆候 • 運用負荷が高すぎて何もできなくなる ◦ 人が減ったり、障害が発生したり手が回らないレベルで負荷が高まる ◦ 一時的なものならいいが、 1週間2週間と続いていくうちに疲労が蓄積され、燃え尽きてしまう
37. 良いプロダクト リリース 信頼性低下 インシデント 発生 障害の兆候（運用負荷） 運用負荷 アラートへ の対応の遅 れ 離職 開発速度 時間経過 品質の軽視 ネガティブな影響 ポジティブな影響
38. 障害の兆候 • 知識が失われてどうしていいかわからなくなる ◦ 実はあの人しか知らなかった、あの人しかできなかったということに退職してから気がついても遅い ◦ 何らかの知識が属人化した状態が長く続くと組織にとっては危険な状態 ◦ 最悪のケースは属人化していることすら知らずにいること ▪ ある日突然何かが動かなくなり、何がどうなっているのかも分からない状態から復旧に向かう のは困難
39. 障害の兆候 • 目指す方向を見失い迷走する ◦ 特性上、人は方向を見失いがち ◦ 認識を合わせることが困難な上にすぐに忘れる ◦ その上、組織の場合は人の入れ替わりによっても記憶がリセットされる
40. 障害の兆候 • 無力感に苛まれて辛い気持ちになる ◦ 計画していた仕事が終わらない状態が続くとチームは無力感を感じはじめる ◦ 放置すると麻痺してさらに悪い状態になる ▪ 問題があるとわかっていながら他の作業を優先し続けると、どうせ優先度は上がらないと諦 めはじめる
41. 障害の兆候 • コミュニケーションがしんどすぎて何も言いたくなくなる “嫌な奴は良きリーダーではない” Titus Winters、Tom Manshreck、Hyrum Wright. Googleのソフトウェアエンジニアリング (p.69). 上記の本では無礼な発言を目撃しただけで組織のパフォーマンスが数十パーセント下 がるという研究に触れられている。 The Price of Incivility（https://hbr.org/2013/01/the-price-of-incivility）
42. 障害の兆候 • 信頼関係が失われ、協力しあえなくなる ◦ チーム対チーム、マネージャー対チーム、その他何でも対人の信頼関係が失われることがある ◦ 信頼性と同じく信頼関係も基本的に期待とそれに対する結果によって生まれる ◦ 信頼関係というのは上から下に一方的にあるものではなく関係のある両側からその反対側に対し てある ◦ 信頼関係が失われるときはこういうことが続いた結果 ▪ 期待に応えなかった ▪ 期待が何だかわからないうちに一方的に失望される
43. 原理と原則
44. 組織の存在意義 どんなチームでもその存在についてチーム外からの承認が必要 • チームに対するSREを考える場合、その意義を明確にする必要がある ◦ なぜそのチームの信頼性を高める必要があるのか ◦ それを通してどんな結果がもたらされるのか • チーム内外においてはっきりと認識されなくてはならない
45. チームのSLO 原理#1 SREは結果を伴うSLOを必要とする。 システムの満足度？ • システムのSLOが満たせている 原理#2 SREは、明日を今日よりも良くするための時間を持たなければならない。 • チームを改善し、継続的な価値提供ができる状態にしていること
46. チームのSLO GSM（Goals/Signals/Metrics：ゴール／シグナル／メトリクス）フレームワーク “ゴールは、望ましい最終結果である。ゴールは、ハイレベルでの理解が望ましいとの見地からこのような 言葉で表されており、特定の計測方法への参照を含むべきではない。 シグナル（signal：信号、合図）は、最終的な結果を達成したことを知る方法である。シグナルは我々が計 測を望むものだが、それ自体は計測できないかもしれない。 メトリクスは、シグナルの代用品である。メトリクスは実際に計測可能なものだ。メトリクスは理想的な計測 手段でないかもしれないが、それに十分近いと信じられるものである。 ” Titus Winters、Tom Manshreck、Hyrum Wright. Googleのソフトウェアエンジニアリング (p.153).
47. チームのSLO ゴール（SREチームまたはSREがいる組織の場合） 例えば • システムのSLOを満たしている • 事業がスケールしてもチームが ◦ 継続的な（素早い）価値提供ができる ◦ 持続可能な運用ができる
48. チームのSLO シグナル 例えば • システムのSLOを満たせているか • システムのSLOを改善するための行動ができたか • システムのSLOを満たすための行動ができたか ◦ 障害の予防のための行動 ◦ 障害の回復のための行動 • 運用を減らしたか • 精神状態が安定しているか
49. チームのSLO メトリクス 例えば • システムのSLOの達成率 • 行動に割いた時間と効果 ◦ 運用（トイル＋オンコール） ◦ 運用を減らすための時間（単純化、自動化） ◦ 削減できた運用の時間 ▪ システムのSLOに直接反映されるもの ▪ 直接は反映されないもの • Four keysのようなメトリクス
50. チームのSLO SLIは “SLIとして機能する数値はたくさんありますが、私たちが推奨しているのは SLIを2つの数値の比とすること、すなわち良いイ ベントの数をイベントの総数で割ること ” Betsy Beyer、Niall Richard Murphy、David K. Rensin、Kent Kawahara、Stephen Thorne. サイトリライアビリティワークブック (p.18). 例えば • システムのSLOの達成率＝全てのシステムの SLOが上回っていた時間/SLOの計測期間 • 運用をした時間/チームが使った時間 • 運用を減らすために使った時間 /チームが使った時間 • 削減できた(であろう)運用の時間/運用を減らすために使った時間 • リリース成功回数/リリース回数 • 深夜労働回数/出勤回数 • ポジティブな会話時間/全会話時間 目標値を設定し、エラーバジェットが算出できるだろうか
51. リスクの受容 組織に障害が起こるのは仕方ない。 組織のSLOを守れるようにようにSREの観点でどうアプローチできるか
52. 組織の可用性 可用性は信頼性の大きな部分を占めており、以下の式で表せる MTBF/MTBF+MTTR 可用性を高める基本的な戦略 • MTTRを可能な限り短くする • MTBFを可能な限り長くする
53. 組織の可用性 MTTRを短くするには • 障害検知までの時間を短くする • 復旧までの時間を短くする MTBFを長くするには • 障害発生確率を減らす • 障害に強くする というアプローチが考えられる
54. 願望は戦略にあらず／初心者の心構えを忘れないこと ある目的で組織を作ったから放っておけばうまくいくということはない。 どんなときもこれをしたから組織は大丈夫だということはない。 そのためにSREの観点を取り入れる試み。 メンバーを信頼しつつ検証と多層防御をする。
55. 信頼しつつも検証を どれだけ優秀なメンバーが揃っていても知識や能力が失われていないことを検証する必 要がある
56. 多層防御 安定した組織であっても何らかの原因で組織に障害が発生する可能性がある。 組織上のSPOFをなくし、チームの自動化を促し多層で防御する。
57. モニタリング • 組織の障害の検知 • 何にどんな時間を使っているか • ポストモーテムのアクションアイテムが実行できているか
58. リリースエンジニアリング ワークブック 21 章 SREにおけるIT変更管理 に組織の変更についての管理方法が紹 介されている。 無計画な変更は失敗する
59. 単純さ “単純なリリースは、概して複雑なリリースよりも優れています。複数の変更をまとめて同 時にリリースするよりも、単一の変更をリリースする方が、その変更の影響を理解するこ とがはるかに容易です。” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.104).
60. 単純さ ルールは単純であればあるほど強い 単純で少ないルールで効果が得られるかを考慮する
61. 自動化 “自動化は多くの環境において手作業による運用よりも優れていると私たちは信じては いますが、そのどちらよりも優れているのは、どちらも必要としない高レベルの設計、す なわち自律的なシステムです。” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.71).
62. トイルの撲滅 “日常的に繰り返される運用上の作業であり、永続的な価値を生み出さず、サービスの 成長に比例してスケールするもの” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.25). • 権限とコミュニケーション ◦ マネージャーとのコミュニケーション ▪ マネージャーの承認 ▪ 評価にまつわるやりとり ◦ チーム対チームのコミュニケーション ▪ レビュー依頼 ▪ 権限 • 暗黙知
63. 適用できるパターン、プラクティス
64. ドキュメンテーション “準備とドキュメンテーションの価値を信じること” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.xvi). 暗黙知を伝えるのはトイル。 知っている側は暗黙知と思っていないことも多い。 以下のルールを作った結果、暗黙知は減り暗黙的なものは単に誰も知らないものだけ になった。 • オンボーディングプロセス完了後にオンボーディング資料の改善を自分で行う • 聞いた人が暗黙知と思った場合はドキュメント化する
65. 目標の設定 チームのSLOを定めるためにはゴールを定める必要がある。 チームの存在意義からシステムのSLO、チームのSLOを定め、定期的に見直すことで ゴールを見失わないようになる
66. 過負荷の監視 SRE本 22.1.2 リソースの枯渇 を人だと思って改めて読むと監視すべきことのヒントにな るかも
67. ロードバランシング • スティッキーセッション（アンチパターン） ◦ セッション中は同じクライアントからのアクセスを同じサーバーにルーティングする ◦ スケーラビリティの観点でボトルネックになる • 誰でも誰かのタスクをすぐに引き継げるようにすることで安定してタスクを消化する ことができる ◦ 原則全員同席で計画をすること ◦ できるだけ最小限の価値（ 1日で何らかの目に見える形になる）にチケット化すること ◦ チケットの課題、要件、完了基準を明確にすること ◦ 基本的に「〜を作る」「〜を設定する」は完了を示していない ▪ 「xxxをしたときにyyyとなること」のような実際の振る舞いを完了の基準にする
68. キューの監視 キューとバックログ、サブスクライバーと人は似た概念 キューの監視は主に • サイズ • 滞留時間 • スループット
69. キューの監視 バックログも同様に監視することで健全性が確認できる • バックログアイテムの数の変化 • バックログアイテムの生存期間 • バックログアイテム消化のスループット ※システム的なキューと違うのは、キューに入るメッセージは基本的に実際の需要に基 づいたものだが、バックログには必要かどうかわからないものも入る可能性がある バックログのサイズが膨れ上がると認知負荷が高まり、並べ替えることが現実的に不可 能になるので、サイズの上限を定め定期的に掃除をすることにした 30個程度なら何とか快適に過ごせるとわかった
70. 監視間隔 リアルタイムで集計されていれば理想ではあるが、頻度を上げれば負荷がかかる。最低 限必要なタイミングで行う。 • 日次（デイリースタンドアップ） ◦ タスクの粒度が大きく、 1日で1つのタスクが終わらないと問題があってもよくわからない ▪ 基本的にチケット化の粒度を 1日で何らかの目に見える形になるようにチケット化することで 状況を把握しやすくなった ◦ 1日1回の共有があるから困ったときにその場でアクションすることをためらう ▪ 1日3回共有することにしたところ、共有することに抵抗感は減ったが、負担になるのですぐや めることになった ◦ 謎時間 ▪ 仕事はしていたはずだが、チケットの消化には時間が使えなかった時間 ▪ 例えばレビューや休憩など、最初から計画に含める必要があることに気がつける
71. 監視間隔 • スプリント単位の計画の監視 ◦ 計画時 ▪ 1つの課題の計画に時間がかかってしまう • かかった時間を計測し、長くかかる理由を分析した ◦ 課題、事実、実現方法のどれかが不明確 • 計画時に15分以上かかるようであれば、まだ計画できる段階にないということで不明な ものを明らかにするアクションにするルールとしたことで不必要に計画に時間がかから なくなった ◦ スプリント終了後 ▪ 問題を把握し、必要であれば次のスプリントの計画に反映することで計画の精度を上げる • 計画したことに時間を使えたか • 計画時の見積もりより時間がかかったか
72. 監視間隔 • 3ヶ月毎の計画の監視 ◦ 1ヶ月毎の進捗 ▪ 数日から数週間単位の見積もりになるため、当初計画した期間とずれていても問題があるのかよくわか らない • 他のことを優先した結果、スケジュール上遅れているなら問題はない • 見積もり時間と使った時間の差を監視することによって、見積もり時の想定と違うことについて把 握できるようになった ◦ 3ヶ月後 ▪ 問題を把握し、必要であれば次のスプリントの計画に反映することで計画の精度を上げる • 計画したことに時間を使えたか • 計画時の見積もりより時間がかかったか
73. セルフサービス “大規模な環境で機能するためには、チームは自給自足でなければなりません” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.92). • 優先してやるべきこと ◦ 運用上の問題に対するバックログはどれもこれも重要に見えて優先度を決めることができなかった ◦ 課題における信頼性に対する RoIを計算する方法を定め、チーム自ら優先度を議論し決められるよ うにした
74. セルフサービス • 評価基準 ◦ 個人目標設定や評価のたびに思い出したようにその話をすると時間がかかるし、自分からアクショ ンができない ◦ 評価基準を明示することによって目標も立てやすく評価も分かりやすくなった
75. セルフサービス • 評価基準（Lv1） ◦ 必要知識等 ▪ SREの原則の理解 ▪ モニタリングの基礎知識 ▪ パブリッククラウドの基礎知識 ▪ アプリケーションのセキュリティの基礎知識 ▪ ソフトウェアの設計原則（ SOLID, Yagni, パターン...） ▪ Linux、Docker、ネットワークの基礎知識 ▪ IaC（terraform） ◦ 能力 ▪ 必要な要件を持ったセキュアなアプリケーションとシステムを構築できる ▪ 必要な機能やシステムを運用を最小限にすることを考慮した上で実装できる ▪ 適切なモニタリングの設計ができる ▪ オンコール対応できる
76. セルフサービス • 評価基準（Lv2） ◦ 必要知識等 ▪ 仮想化、オーケストレーション等の基本的な知識 ▪ キャパシティプランニングの手法 ▪ パフォーマンスチューニングの手法 ▪ リリースエンジニアリングの手法 ◦ 能力 ▪ SREのプラクティスに基づいた改善活動が実践できる ▪ 運用を考慮したシステム設計のレビュー ▪ キャパシティプランニングと適切なパフォーマンスチューニング ▪ 小規模なシステム障害で対応の指揮を取れる ▪ オンコールの訓練シナリオを作成できる ▪ リリースを安全にするための設計と改善ができる
77. セルフサービス • 評価基準（Lv3） ◦ 必要知識等 ▪ クラウドネイティブなアプリケーションの設計 ▪ 大規模システムの設計 ▪ 体系的な問題解決アプローチ ▪ 強力なコミュニケーションスキル ◦ 能力 ▪ システムの複雑性の分析をし、改善箇所の特定と改善方法の提案ができる ▪ SREの原則に基づいたシステム設計のコンサルティング ▪ 比較的大規模なシステム障害の対応で指揮を取れる
78. セルフサービス • 評価基準（Lv4） ◦ 必要知識等 ▪ SREに関する深い理解（SRE本３冊を丸暗記しているくらい） ▪ システム開発・運用の合計 10年以上の経験 ▪ 大規模分散システムの設計、分析、トラブルシューティングの経験 ▪ オーナーシップと意欲 ◦ 能力 ▪ SREのプラクティスに基づいた組織の改善活動の実践 ▪ 複数プロダクトにおいて SREを再現性を持って実践できる
79. セルフサービス • 成熟度レベル ◦ SREを実践するにあたり具体的にどんな状態を実現したらいいのかわからない ◦ SREの成熟度レベルを示した SRE チームの評価に役立つレベル別チェックリスト は参考にはなる が、具体的に何が実現されていればできていると言えるのかという定義が必要 ◦ 社内のSREを集め、SREの行動や配置戦略を考えるために成熟度レベルの社内版を作っている ▪ 結論よりも全員の議論の過程こそが重要で、 SREが実現すべきことについての認識がまと まっていく過程で自らアクションできる状態になると考えている
80. Timeout • タイムボックスを設定する ◦ タスクが終わるまでやるのではなく、この時間の枠でこのタスクを行うという考え方 ◦ 例えば ▪ スプリントは1週間の枠 ▪ 作業の粒度では15分単位の枠 ▪ 3ヶ月単位の枠 ◦ それぞれの枠で何を達成するのか決める ▪ タイムボックスをオーバーした場合に一旦立ち戻れる ▪ 何かにはまっている時はそれの解決に 1人で格闘しがちだが、チームで話せばすぐに解決す るかもしれない
81. データの可用性 “バックアップをしたい人はいないのであり、人々が本当に求めているのはリストアです。 ” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.361). “サービスのデータが利用できなくなれば、その際の対応によってサービスやプロダクト、さらには会社そ のものを破綻に追い込むことさえありうるのです。 ” “チームが「単にバックアップを行う」のではなく、以下のようにすることを求めています。 • さまざまな障害状況におけるデータの可用性に対してサービスレベル目標（ SLO）を定義する。 • 実践し、そのSLOを満たせることを示す。” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.364).
82. データの可用性 • 障害対応訓練 ◦ 何もかもがうまくいかなかった障害対応を教訓に障害対応のオペレーションを全て見直すために始 まりまった ◦ 検知、連絡、復旧の目標を定め、訓練チームが障害を準備し、 CSチームとの連携まで行うことで障 害対応フローで実際の障害対応が可能であることを証明し、改善すべき点を洗い出すことができる ようになった
83. データの可用性 • 離職時の引き継ぎ ◦ 有休消化を前倒してもらうことでその人がいなくなって困ることを洗い出していた ◦ その後スプリントの期間以上に属人化されたことはなくなり、基本的に引き継ぐことそのものがなく なった
84. Load shedding WIP制限という概念はロードシェディングに似ていて 人間は複数のことを同時にするのは得意ではないし、コンテキストスイッチは負荷になる 組織のリソース効率を高めようとするよりフロー効率を高めることでより確実に価値を積 み上げることができる
85. Delegation • 依頼への対応や承認について、本質的にはいらないものがある ◦ 以前は必要だったかもしれないけどもう不要なもの ◦ 何か条件を満たせば不要になるもの • 移譲できるものは移譲し、実装は任せることで待ち時間の無駄を減らせる ◦ 例えば ▪ 機能開発チームがAWSの権限を持っていないから開発中に AWSリソースの構築待ちが発 生していた • 検証環境のadmin権限を渡す ▪ terraformの書き方がわからない • ペアプロやドキュメントを充実させる、サンプルコードを作るなど ▪ スプリントバックログの並べ替えに POの判断を待たないといけない • 並べ替えの基準を明確にすることでチーム内で並べ替えが可能になる ▪ POがチケットの完了の承認するまで待たないといけない • 完了基準を明確にすることでマネージャーや POでなくても承認が可能になる
86. 割り込みへの対処 SRE本 29章 割り込みへの対処 にも事例が書いてある • 人間は複数のことを同時にすること、長時間何かをすること、集中することが苦手 ◦ 割り込みはなるべく減らす必要があるが、運用という性質上 SREチームには割り込みが多い ▪ 移譲によって減らせるものもあるが、減らせないこともある ◦ 割り込みにも期待される完了期限があり、すぐに対応しなければならないものや 2、3日の猶予があ るものもある ◦ 割り込みによってスプリント計画したものが全て終わらないことが常態化した後に、 2つの問題があ ると認識した ▪ 長時間のプランニングミーティングは疲労によりさらに長時間化する ▪ 終わらないことを計画する時間は無駄である
87. 割り込みへの対処 すぐ対処しなければならないものは対処するとして、全てをスプリント計画に影響を与え るようにしてしまうべきではない • スプリントに割り込み用の時間を用意する ◦ 枠以上に来るかもしれないし、全然来なかったら何をするか考えないといけない • いっそスプリントを1日にしてみる ◦ 猶予のある割り込みは基本的に次のスプリントにできるようになった ◦ 1日で終わらないものを調整するのが面倒 ◦ 無理やりチケットを分割したりして計画に無駄な時間を使っている • スプリントを2日にして落ち着いた ◦ （正確には1週間を2日と約2日とチーム外とのミーティング等の日に分けた） ◦ こうすることで猶予のあるチケットを次のスプリントの計画に入れつつ、無駄な計画の時間をなくせ た
88. 障害対応とポストモーテム 組織に障害があった場合、何も対応しない組織があるとしたらそれはもうきっと存在する 意義がない。そうでなければ何か対応するはず。 基本的に組織の障害はメンバーから見た場合、何だかわからないうちにうやむやになる ことが多い。 SREの観点から言えることは学びを生かすために • 非難なきポストモーテムを行い改善のためのアクションをする • Playbookを作る
89. どんなチームになったか チームを離れた後もチーム自身でチームのゴールに向け、 チーム自身で課題を整理し、 3ヶ月の目標を立て、 自己管理してチームを改善しながら課題を解決し続けている
90. まとめ 組織に何かを取り入れる際にSREの原則やプラクティス、パターンに当てはめて考えて みて、うまくいくイメージが持てるのであればおそらく理に適っているのではないだろうか そのまま組織にSREが適用できるというよりも、チーム作り、組織作りの観点としてヒント となるのではないか
91. ありがとうございました！