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

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

masao kunii
January 31, 2023

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

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

masao kunii

January 31, 2023
Tweet

Other Decks in Technology

Transcript

  1. なぜ組織の話をするのか 信頼性とは “「[システムが]求められる機能を、定められた条件の下で、定められた期間にわたり、 障害を起こすことなく実行する確率」“ Betsy Beyer; Chris Jones; Jennifer Petoff;

    Niall Richard Murphy. SRE サイトリライアビリティエンジニアリング (xiv). 求められる機能 = プロダクトを作り、提供し、運用する 定められた条件 = プロダクトの提供が続く限り 定められた期間 = プロダクトの使命を果たすまで 障害 = プロダクト開発、運用ができない状態になる
  2. SREのおさらい “SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるも の” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall

    Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.5). 運用ではなく、運用チームの話
  3. 組織をコンピュータシステムと捉える “人間は不完全なマシンです。人間は退屈し、十分には理解されていないプロセッサ(場 合によってはUIも)を持ち、あまり効率も良くありません” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall

    Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.431). 組織は人、 しかし、人をコンピュータとして捉えたとき、信頼性はとても低い • 期待した動作をさせるのは困難 • 人には人生があり、ずっとそこにいるとは限らない
  4. 組織をコンピュータシステムと捉える マシン = 人 サーバー = 役割、仕事 クラスタ = チーム、組織

    データ = 人やチームの知識、記憶、文化 SRE = マネージャーや組織長、チーム自身 システム
  5. こう考えるに至った経緯 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
  6. こう考えるに至った経緯 “究極的には、ユーザーの満足度が問題なのです。... 顧客を満足している状態に保つた めに、私たちはサービスの信頼性を保つのです” Betsy Beyer、Niall Richard Murphy、David K. Rensin、Kent

    Kawahara、Stephen Thorne. サイトリライアビリティワークブック (p.17). 手段 対象 SLO CRE システム 顧客(と顧客の システム) 顧客の顧客の満 足度 システム的な SRE 開発チーム SREチーム システム 顧客の満足度 組織的なSRE マネージャー チーム 開発チーム SREチーム システムの満足 度?
  7. 障害の兆候 • 人が急に増えてカオスになりパフォーマンスや品質が低下する • 認識が揃わず期待通りのものが出来上がらない • 低い品質の結果、開発速度が遅くなる • 人が急にいなくなって手が回らなくなる •

    誰かがボトルネックになって進まなくなる • 運用負荷が高すぎて何もできなくなる • 知識が失われてどうしていいかわからなくなる • 目指す方向を見失い迷走する • 無力感に苛まれて辛い気持ちになる • コミュニケーションがしんどすぎて何も言いたくなくなる • 信頼関係が失われ、協力しあえなくなる
  8. 障害の兆候 • コミュニケーションがしんどすぎて何も言いたくなくなる “嫌な奴は良きリーダーではない” Titus Winters、Tom Manshreck、Hyrum Wright. Googleのソフトウェアエンジニアリング (p.69).

    上記の本では無礼な発言を目撃しただけで組織のパフォーマンスが数十パーセント下 がるという研究に触れられている。 The Price of Incivility(https://hbr.org/2013/01/the-price-of-incivility)
  9. チームのSLO メトリクス 例えば • システムのSLOの達成率 • 行動に割いた時間と効果 ◦ 運用(トイル+オンコール) ◦

    運用を減らすための時間(単純化、自動化) ◦ 削減できた運用の時間 ▪ システムのSLOに直接反映されるもの ▪ 直接は反映されないもの • Four keysのようなメトリクス
  10. チームのSLO SLIは “SLIとして機能する数値はたくさんありますが、私たちが推奨しているのは SLIを2つの数値の比とすること、すなわち良いイ ベントの数をイベントの総数で割ること ” Betsy Beyer、Niall Richard Murphy、David

    K. Rensin、Kent Kawahara、Stephen Thorne. サイトリライアビリティワークブック (p.18). 例えば • システムのSLOの達成率=全てのシステムの SLOが上回っていた時間/SLOの計測期間 • 運用をした時間/チームが使った時間 • 運用を減らすために使った時間 /チームが使った時間 • 削減できた(であろう)運用の時間/運用を減らすために使った時間 • リリース成功回数/リリース回数 • 深夜労働回数/出勤回数 • ポジティブな会話時間/全会話時間 目標値を設定し、エラーバジェットが算出できるだろうか
  11. トイルの撲滅 “日常的に繰り返される運用上の作業であり、永続的な価値を生み出さず、サービスの 成長に比例してスケールするもの” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall

    Richard Murphy. SRE サイトリライアビリティエンジニアリング (p.25). • 権限とコミュニケーション ◦ マネージャーとのコミュニケーション ▪ マネージャーの承認 ▪ 評価にまつわるやりとり ◦ チーム対チームのコミュニケーション ▪ レビュー依頼 ▪ 権限 • 暗黙知
  12. ドキュメンテーション “準備とドキュメンテーションの価値を信じること” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard

    Murphy. SRE サイトリライアビリティエンジニアリング (p.xvi). 暗黙知を伝えるのはトイル。 知っている側は暗黙知と思っていないことも多い。 以下のルールを作った結果、暗黙知は減り暗黙的なものは単に誰も知らないものだけ になった。 • オンボーディングプロセス完了後にオンボーディング資料の改善を自分で行う • 聞いた人が暗黙知と思った場合はドキュメント化する
  13. ロードバランシング • スティッキーセッション(アンチパターン) ◦ セッション中は同じクライアントからのアクセスを同じサーバーにルーティングする ◦ スケーラビリティの観点でボトルネックになる • 誰でも誰かのタスクをすぐに引き継げるようにすることで安定してタスクを消化する ことができる

    ◦ 原則全員同席で計画をすること ◦ できるだけ最小限の価値( 1日で何らかの目に見える形になる)にチケット化すること ◦ チケットの課題、要件、完了基準を明確にすること ◦ 基本的に「〜を作る」「〜を設定する」は完了を示していない ▪ 「xxxをしたときにyyyとなること」のような実際の振る舞いを完了の基準にする
  14. 監視間隔 リアルタイムで集計されていれば理想ではあるが、頻度を上げれば負荷がかかる。最低 限必要なタイミングで行う。 • 日次(デイリースタンドアップ) ◦ タスクの粒度が大きく、 1日で1つのタスクが終わらないと問題があってもよくわからない ▪ 基本的にチケット化の粒度を

    1日で何らかの目に見える形になるようにチケット化することで 状況を把握しやすくなった ◦ 1日1回の共有があるから困ったときにその場でアクションすることをためらう ▪ 1日3回共有することにしたところ、共有することに抵抗感は減ったが、負担になるのですぐや めることになった ◦ 謎時間 ▪ 仕事はしていたはずだが、チケットの消化には時間が使えなかった時間 ▪ 例えばレビューや休憩など、最初から計画に含める必要があることに気がつける
  15. 監視間隔 • スプリント単位の計画の監視 ◦ 計画時 ▪ 1つの課題の計画に時間がかかってしまう • かかった時間を計測し、長くかかる理由を分析した ◦

    課題、事実、実現方法のどれかが不明確 • 計画時に15分以上かかるようであれば、まだ計画できる段階にないということで不明な ものを明らかにするアクションにするルールとしたことで不必要に計画に時間がかから なくなった ◦ スプリント終了後 ▪ 問題を把握し、必要であれば次のスプリントの計画に反映することで計画の精度を上げる • 計画したことに時間を使えたか • 計画時の見積もりより時間がかかったか
  16. 監視間隔 • 3ヶ月毎の計画の監視 ◦ 1ヶ月毎の進捗 ▪ 数日から数週間単位の見積もりになるため、当初計画した期間とずれていても問題があるのかよくわか らない • 他のことを優先した結果、スケジュール上遅れているなら問題はない

    • 見積もり時間と使った時間の差を監視することによって、見積もり時の想定と違うことについて把 握できるようになった ◦ 3ヶ月後 ▪ 問題を把握し、必要であれば次のスプリントの計画に反映することで計画の精度を上げる • 計画したことに時間を使えたか • 計画時の見積もりより時間がかかったか
  17. セルフサービス “大規模な環境で機能するためには、チームは自給自足でなければなりません” Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard

    Murphy. SRE サイトリライアビリティエンジニアリング (p.92). • 優先してやるべきこと ◦ 運用上の問題に対するバックログはどれもこれも重要に見えて優先度を決めることができなかった ◦ 課題における信頼性に対する RoIを計算する方法を定め、チーム自ら優先度を議論し決められるよ うにした
  18. セルフサービス • 評価基準(Lv1) ◦ 必要知識等 ▪ SREの原則の理解 ▪ モニタリングの基礎知識 ▪

    パブリッククラウドの基礎知識 ▪ アプリケーションのセキュリティの基礎知識 ▪ ソフトウェアの設計原則( SOLID, Yagni, パターン...) ▪ Linux、Docker、ネットワークの基礎知識 ▪ IaC(terraform) ◦ 能力 ▪ 必要な要件を持ったセキュアなアプリケーションとシステムを構築できる ▪ 必要な機能やシステムを運用を最小限にすることを考慮した上で実装できる ▪ 適切なモニタリングの設計ができる ▪ オンコール対応できる
  19. セルフサービス • 評価基準(Lv2) ◦ 必要知識等 ▪ 仮想化、オーケストレーション等の基本的な知識 ▪ キャパシティプランニングの手法 ▪

    パフォーマンスチューニングの手法 ▪ リリースエンジニアリングの手法 ◦ 能力 ▪ SREのプラクティスに基づいた改善活動が実践できる ▪ 運用を考慮したシステム設計のレビュー ▪ キャパシティプランニングと適切なパフォーマンスチューニング ▪ 小規模なシステム障害で対応の指揮を取れる ▪ オンコールの訓練シナリオを作成できる ▪ リリースを安全にするための設計と改善ができる
  20. セルフサービス • 評価基準(Lv3) ◦ 必要知識等 ▪ クラウドネイティブなアプリケーションの設計 ▪ 大規模システムの設計 ▪

    体系的な問題解決アプローチ ▪ 強力なコミュニケーションスキル ◦ 能力 ▪ システムの複雑性の分析をし、改善箇所の特定と改善方法の提案ができる ▪ SREの原則に基づいたシステム設計のコンサルティング ▪ 比較的大規模なシステム障害の対応で指揮を取れる
  21. セルフサービス • 評価基準(Lv4) ◦ 必要知識等 ▪ SREに関する深い理解(SRE本3冊を丸暗記しているくらい) ▪ システム開発・運用の合計 10年以上の経験

    ▪ 大規模分散システムの設計、分析、トラブルシューティングの経験 ▪ オーナーシップと意欲 ◦ 能力 ▪ SREのプラクティスに基づいた組織の改善活動の実践 ▪ 複数プロダクトにおいて SREを再現性を持って実践できる
  22. セルフサービス • 成熟度レベル ◦ SREを実践するにあたり具体的にどんな状態を実現したらいいのかわからない ◦ SREの成熟度レベルを示した SRE チームの評価に役立つレベル別チェックリスト は参考にはなる

    が、具体的に何が実現されていればできていると言えるのかという定義が必要 ◦ 社内のSREを集め、SREの行動や配置戦略を考えるために成熟度レベルの社内版を作っている ▪ 結論よりも全員の議論の過程こそが重要で、 SREが実現すべきことについての認識がまと まっていく過程で自らアクションできる状態になると考えている
  23. Timeout • タイムボックスを設定する ◦ タスクが終わるまでやるのではなく、この時間の枠でこのタスクを行うという考え方 ◦ 例えば ▪ スプリントは1週間の枠 ▪

    作業の粒度では15分単位の枠 ▪ 3ヶ月単位の枠 ◦ それぞれの枠で何を達成するのか決める ▪ タイムボックスをオーバーした場合に一旦立ち戻れる ▪ 何かにはまっている時はそれの解決に 1人で格闘しがちだが、チームで話せばすぐに解決す るかもしれない
  24. データの可用性 “バックアップをしたい人はいないのであり、人々が本当に求めているのはリストアです。 ” 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).
  25. Delegation • 依頼への対応や承認について、本質的にはいらないものがある ◦ 以前は必要だったかもしれないけどもう不要なもの ◦ 何か条件を満たせば不要になるもの • 移譲できるものは移譲し、実装は任せることで待ち時間の無駄を減らせる ◦

    例えば ▪ 機能開発チームがAWSの権限を持っていないから開発中に AWSリソースの構築待ちが発 生していた • 検証環境のadmin権限を渡す ▪ terraformの書き方がわからない • ペアプロやドキュメントを充実させる、サンプルコードを作るなど ▪ スプリントバックログの並べ替えに POの判断を待たないといけない • 並べ替えの基準を明確にすることでチーム内で並べ替えが可能になる ▪ POがチケットの完了の承認するまで待たないといけない • 完了基準を明確にすることでマネージャーや POでなくても承認が可能になる
  26. 割り込みへの対処 SRE本 29章 割り込みへの対処 にも事例が書いてある • 人間は複数のことを同時にすること、長時間何かをすること、集中することが苦手 ◦ 割り込みはなるべく減らす必要があるが、運用という性質上 SREチームには割り込みが多い

    ▪ 移譲によって減らせるものもあるが、減らせないこともある ◦ 割り込みにも期待される完了期限があり、すぐに対応しなければならないものや 2、3日の猶予があ るものもある ◦ 割り込みによってスプリント計画したものが全て終わらないことが常態化した後に、 2つの問題があ ると認識した ▪ 長時間のプランニングミーティングは疲労によりさらに長時間化する ▪ 終わらないことを計画する時間は無駄である
  27. 割り込みへの対処 すぐ対処しなければならないものは対処するとして、全てをスプリント計画に影響を与え るようにしてしまうべきではない • スプリントに割り込み用の時間を用意する ◦ 枠以上に来るかもしれないし、全然来なかったら何をするか考えないといけない • いっそスプリントを1日にしてみる ◦

    猶予のある割り込みは基本的に次のスプリントにできるようになった ◦ 1日で終わらないものを調整するのが面倒 ◦ 無理やりチケットを分割したりして計画に無駄な時間を使っている • スプリントを2日にして落ち着いた ◦ (正確には1週間を2日と約2日とチーム外とのミーティング等の日に分けた) ◦ こうすることで猶予のあるチケットを次のスプリントの計画に入れつつ、無駄な計画の時間をなくせ た