SREの歩き方・進め方 @rrreeeyyy @taxin_tt 

自己紹介 ● @rrreeeyyy (Ryota Yoshikawa) ○ 株式会社 Topotal で CTO/SRE をしています ■ Topotal: https://topotal.com/ ○ SRE や Platform Engineering に関する Podcast を @deeeet さんと一緒にやっています ■ e34fm: https://e34.fm/ ● @taxin_tt (Takushi Nishikawa) ○ SRE Next 2022 STAFF (本セッションのモデレーター ) ○ 普段は、株式会社ビザスクで SRE をしています 2 

そもそもSREとは何か? 3 

そもそもSREとは何か? ● SRE の歴史 ○ 2004 SRE Team @ Google ■ Simple concept: オペレーションをソフトウェアの問題として扱う ○ 2014 SRECon14 (#1), Keys to SRE by Benjamin Treynor Sloss ■ Hire only developers, Have an SLA for your service, Error Budgets, Toil, Postmortem, … ○ 2016 Site Reliability Engineering (SRE Book) ● SRE とは ○ “SRE is what you get when you treat operations as if it’s a software problem” ( sre.google ) ■ 自分の解釈: オペレーションに正しくエンジニアリングを取り入れて改善し続けること ● サービスの信頼性を定義し数字でコントロールする (SLI/SLO) ○ 定義を明らかにしデータを用いて判断を行う ● Toil の削減 ○ 手作業を行わずに自動化しサービスをスケールさせていく 4 

SRE と DevOps の関係 5 

SRE と DevOps の関係 6 ● DevOps の歴史 ○ Agile2008 Conference: Agile Infrastructure & Operations ■ アジャイルアプローチでの Operation や Dev/Ops の Cross Functional Team の提案 ○ Velocity 2009 – O’Reilly Conferences 10+ Deploys per Day: Dev and Ops Cooperation ■ Dev と Ops が協業することでサービスの価値提供速度が高まるという発表 ● SRE と DevOps は似ている？ ○ 同じ Dev/Ops のサイロ化という課題を解消しようとする側面もある ■ SRE: オペレーションをソフトウェアの問題として扱う ■ DevOps: Dev/Ops がサイロ化しないように協業していく ○ class SRE implements DevOps - (SRE workbook) ■ SRE のプラクティスは DevOps の範囲外のものも含んでいるが、範囲内のものについては 具体的な手法が提案されている 

SRE のプラクティスについて 7 

SRE のプラクティスについて 8 ● “Site Reliability Engineering” から始まり様々な SRE のプラクティスがある ○ Site Reliability Engineering ○ The Site Reliability Workbook ○ Seeking SRE ○ Building Secure & Reliable Systems ○ … ● 今日は “Site Reliability Engineering” から代表的なものをいくつか紹介 ○ SLI/SLO & Error Budget ○ Toil の削減 ○ Postmortem 

SLI/SLO 9 

SLI/SLO & Error Budget 10 ● SLI: Service Level Indicator (サービスレベル指標) ○ ex: 成功した HTTP リクエストの数 / 全ての HTTP リクエスト (success rate) ○ ex: レスポンスタイムが 500ms 以下のリクエストの数 / 全てのリクエスト ● SLO: Service Level Objective (サービスレベル目標) ○ ex: 99.9% success rate, レスポンスタイムタイムが 500ms 以下のリクエストが 95% ● Error Budget: 定めた SLO から算出される許容できるエラーの量 ○ 100 - SLO (%) ○ ex: 0.1% error budget ● Window (期間) ○ SLI/SLO を評価する期間 ■ ローリングウィンドウ : 特定の日数による評価期間。 ex: 7 日間, 14 日間, … ■ カレンダーウィンドウ : 暦を利用した評価期間。 ex: 4 月の SLO, 四半期の SLO, … 

SLI/SLO & Error Budget の決め方 ● SLI: 何らかの割合となるように値を定めると良い ○ 例: (良いイベントの数 / 全てのイベントの数) ■ レイテンシの SLI の例 ● △: レスポンスタイムの平均値が 500ms ● ◯: (レスポンスタイムが 500ms 以下のレスポンスの数 / 全てのリクエストの数 ) ○ サービスや事業の目標値と関連するように指標を定めると良い ■ 例: 動画の配信サイトでは動画再生成功回数や動画投稿成功回数を指標にするなど ● SLO: 高い値を目指しすぎないこと ○ 高すぎると運用コストが非常に高くなる ○ 開発速度とサービスの信頼性を上手くコントロールできるように値を調整する ● 大事なこと ○ サービスのステークホルダーや関係者と合意を取りながら決めること ○ 「決めて終わり」ではなくて改善し続けること 11 

SLI/SLO & Error Budget の運用 ● SLI/SLO は決めた後に改善を続けていくことが大事 ○ 最初から完璧な SLI/SLO を定めることはできない ○ サービス・事業の目標が変化し続ける => SLI/SLO も変化が必要 ● 月や四半期ごとなどに SLI/SLO のフィードバックを行う ○ 定期的に SLI/SLO がどのように運用されているかチェックして改善していく仕組みを作る ○ 最初に SLI/SLO を決めるときに合意した内容をドキュメントに残しておくとよい ■ 例: SLO が週単位で定めた値を下回った場合、開発メンバーは信頼性を向上させる ● 様々な指標と合わせて信頼性を上手く ”コントロール” していくのが大事 ○ 例: カスタマーサポートのチケットは多いが SLO は目標値を上回っている ■ => ユーザの体感と設定している SLI/SLO が食い違っているので見直した方がよい ○ 例: SLO の値を満たすために工数が割かれすぎていて機能開発が全然進んでいない ■ => その SLO の高さは本当に必要？目標値を少し下げて機能開発をするべきかも 12 

Toil の削減 13 

Toil とは 14 ● Toil とはどういったタスクのことか: ○ 手作業 ○ 繰り返される ○ 自動化が可能 ○ 戦術的・長期的な価値がない ○ サービスの成長に比例して増加する ● Toil は SRE がエンジニアリングを行う時間を奪う ○ 適切な信頼性を定義・コントロールしていく時間がなくなってしまう ○ コードを書いてサービスを安定・スケールさせる時間がなくなってしまう ● Toil は放っておくと増え続けてしまう ○ 常に SRE の作業の 50% 未満になるように意識する 

Toilの削減 15 ● まずは Toil を洗い出すことが大事 ○ 例: SRE の作業を簡単にチケット管理システムで洗い出す ■ 作業の種類・作業の難易度（概算の掛かる時間）・作業者 ○ 例: SRE チームに対して月単位・四半期などでアンケートを行う ■ 全体の作業のうち Toil に掛かった時間, Toil の発生源, Toil に費やした時間の満足度 , … ● Toil が 50% 以上になっていたら改善プロジェクトを行う ○ 50% 以上になっているとキャリアの停滞 , 燃え尽き, 混乱, … など様々な悪影響がある ● Toil の解消は自動化するのが一般的 ○ 頻度や掛かる時間の長いものから自動化していく ● Toil は習慣化するのでチーム全体で処理するようにする ○ 例: 割り込みタスクやチケットなどは SRE チーム内のローテーションで処理する ● 全ての Toil を無くすのは非常に難しいので多少は受容していく 

Postmortem 16 

Postmortem とは 17 ● Postmortem: インシデントから学びを得るためのプロセスの一部 ○ Postmortem 文章として次のような内容が書かれる ■ インシデント ■ インパクト ■ 緩和や解消のために行ったアクション ■ 根本原因 ■ 再発防止策 ● Postmortem を書く基準を決めておく ○ 例: ユーザ影響のある障害が 15 分継続したら～など ● Postmortem では非難を避け建設的であるようにする ○ Postmortem はサービスのどこをどうすれば改善できるのか提起するもの ● レビューや公表まで含めて一つのプロセスとする ○ レビューを通じてレビュアー・レビュイー間で知識が共有できる ○ 公表するすることで組織全体が失敗から多くのことを学ぶことができる 

Postmortem 文化の導入 18 ● 理想的な Postmortem の文化の形成は一朝一夕にはいかない ○ 全員が非難しない・協調する文化を形成し続ける必要がある ● 協調的な Postmortem の文化を生み出すために ○ 色々な人がレビューに積極的に参加するようにする ■ リーダーやマネージャーも積極的に参加できると良い ● 非難のない Postmortem の文化を生み出すために ○ エンジニアが非難のない文化を自発的に形成できると理想的 ○ 例: ■ Postmortem の読書会を開く ■ 月刊のニュースレター（今月の Postmortem）を行う ○ Postmortem を書いた人をしっかり労う・奨励する 

プラクティスを組織に導入するには? 19 

プラクティスを組織に導入するには? 20 ● ”エンジニアリング” が出来るようにする ○ ソフトウェアエンジニアリング ■ コードを書き続けること ○ システムエンジニアリング ■ 理論に基づいた設定変更やモニタリングの設定など ○ データに基づいた判断をする ■ SLI/SLO のような指標を定め、アップデートし、判断し、コントロールをする ○ ✖ しないこと ✖: Toil の放置, 場当たり的な運用, 指標に基づかない判断 , … ● 関わるサービス・ビジネスのことを正しく理解する ○ SRE は単にサーバやコンテナが安定稼働することだけを目指すものではない ○ ユーザに機能・サービスを正しく届ける状態を継続できるか ■ SLI/SLO として指標を持ちアップデートし続けられるか ● サービスに関わる人達や会社全体と共有できるか 

SRE の実践パターン: Embedded SRE 21 ● 期間限定でサービス開発チームの一員として SRE を実践していくパターン ○ 文化の相互理解に有効だと考えている ■ SRE は開発チームを、開発チームは SRE を理解できる ○ SRE は実際に開発をしながらプラクティスを実践することができる ■ 実際の開発をすることでスキル的な向上もある ■ 両立することがどれくらい大変か分かる ● 上手くコントロールする必要があると感じられる ○ 開発チームは SRE の概念から実践方法まで隣で見ることができる ● Embedded SRE から SRE チームに戻ったときにできることも増える ○ サービスチームから見て SRE の実践に足りないものが何かわかる ● SRE の認知負荷の高まりなどには注意する必要がありそう ○ 様々なことを同時に上手くやる必要があるので大変 

まとめ 22 ● SRE とはどういう概念か？を基本から簡単に説明 ○ SRE と関連する概念についても簡単に説明 ■ DevOps と SRE について ● SRE に関連するプラクティスについていくつか紹介 ○ SLI/SLO & Error Budget ○ Toil の削減 ○ Postmortem ● SRE を組織に導入するプラクティスについて紹介 ○ エンジニアリング・サービス /ビジネス理解 ○ Embedded SRE パターン 

参考文献 23 ● https://sre.google/sre-book/table-of-contents/ ● https://sre.google/workbook/table-of-contents/ ● https://sre.google/resources/practices-and-processes/art-of-slos/ ● https://cloud.google.com/blog/products/devops-sre/how-sre-teams-are-organized-and-how-to-get-started ● https://cloud.google.com/blog/ja/products/gcp/incident-management-at-google-adventures-in-sre-land ● https://medium.com/slalom-build/the-many-shapes-of-site-reliability-engineering-468359866517