あなたらしくSRE Rakuten Technology Conference 2022 株式会社スリーシェイク 阿部貴晶 Copyright © 3-shake, Inc. All Rights Reserved.

注意事項 Copyright © 3-shake, Inc. All Rights Reserved. 2022/11/19に開催されたRakuten Technology Conference 2022の発表資料です。 記載内容は発表当時の情報となります。 また、公開のために具体的な事例を削っておりますのでご了承ください。

自己紹介 Copyright © 3-shake, Inc. All Rights Reserved. 株式会社スリーシェイク Sreake事業部所属。 大学1年生の頃からMSPに所属して、国内外問わず様々なクラウドおよびシステムで運用監視を経験。 2020年5月から株式会社スリーシェイク。 金融系のお客様を中心にインフラ周辺の実作業からコンサルティングまで幅広く対応。 お客様がより良くサービスを提供できる環境を目指して SRE組織の発足をお手伝い中。 阿部 貴晶

アジェンダ Copyright © 3-shake, Inc. All Rights Reserved. 1. SREはなぜ必要なのか？ 2. SRE原則 3. SRE を導入する上での障壁とアプローチ ○ SREの原則を実践する難しさと進め方 ○ 大企業で認識合わせする難しさ ○ SRE人材を集める難しさ 4. 最後に

SREはなぜ必要なのか？ 01 Copyright © 3-shake, Inc. All Rights Reserved.

SRE とは ~ SRE 本の序章より ~ Copyright © 3-shake, Inc. All Rights Reserved. Googleで定義されるようになった Site Reliability Engineeringとは一体何なのか？ 私の説明は簡単です。 SRE とは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです 。 What exactly is Site Reliability Engineering, as it has come to be defined at Google? My explanation is simple: SRE is what happens when you ask a software engineer to design an operations team. By Benjamin Treynor Sloss ・Site Reliability Engineering: How Google Runs Production Systems. （2016） O'Reilly Media. （Niall Richard Murphy 他 玉川 竜司 訳 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム （2017）オライリージャパン） 1.2 サービス管理への Googleのアプローチ：サイトリライアビリティエンジニアリング（ P5） ・Google - Site Reliability Engineering https://sre.google/sre-book/introduction/ （参照 2022/11/14）

SRE とは Copyright © 3-shake, Inc. All Rights Reserved. 難しい

SRE とは Copyright © 3-shake, Inc. All Rights Reserved. SREとは、 サービスの信頼性を高めるために、 ソフトウェアエンジニアが行う 設計やアプローチ、またはこれらを行うチーム

Copyright © 3-shake, Inc. All Rights Reserved. 信頼性？ SREにおける信頼性

Copyright © 3-shake, Inc. All Rights Reserved. いかなるシステムにおいても最も重要な機能は信頼性である。 監視が信頼性を決めるのではない。ユーザーが決めるのだ。 SREにおける信頼性 ・Google Cloud で実践するSRE https://www.slideshare.net/GoogleCloudPlatformJP/google-cloud-sre-249557085 （参照 2022/11/14）

Copyright © 3-shake, Inc. All Rights Reserved. SREにおける信頼性 サービスがユーザに提供している価値（＝機能）を ユーザが利用したいタイミングで意図したとおり快適に提供できること、 と私は理解している 例えばECサイトであれば、 商品を選んでカートに入れて購入完了する一連の流れが正しく動作し続けること 信頼性が低いということは、ユーザが求めている価値を提供できていない とも考えられるためビジネスの視点から見ても信頼性は重要であると言える

Copyright © 3-shake, Inc. All Rights Reserved. 信頼性と機能開発 システム運用において信頼性と機能開発はトレード・オフの関係にある 運用「信頼性を担保するためにあまり変更したくない！」 開発「新しい機能を提供したいので機能開発をたくさんしたい！」 運用と開発それぞれ目標が異なり協調が難しく サービスの価値を効率的に上げることが難しいこともしばしば ※システム障害の 7割は変更により発生 ・Site Reliability Engineering: How Google Runs Production Systems. （2016） O'Reilly Media. （Niall Richard Murphy 他 玉川 竜司 訳 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム （2017）オライリージャパン） 1.1 サービス管理へのシステム管理者のアプローチ ・Google - Site Reliability Engineering https://sre.google/sre-book/introduction/ （参照 2022/11/14）

システム運用で起こる問題 Copyright © 3-shake, Inc. All Rights Reserved. 煩雑で繰り返しの多い 手動の運用作業 日々追われる障害対応とメ ンバーへの過負荷 守りを重視するが故に リリーススピードが遅い 信頼性と機能開発の問題以外にもシステム運用では様々な問題が存在

SREはなぜ必要なのか？ Copyright © 3-shake, Inc. All Rights Reserved. 自動化の推進による 煩雑で繰り返しの多い 作業を削減 適切なオンコールや データによる業務ハンドリングで過負 荷を削減 信頼性を担保しつつ 素早いリリースサイクル 準備 SREを導入することで信頼性を軸に ソフトウェアエンジニアでシステム運用の問題を解決していく

SREの原則 02 Copyright © 3-shake, Inc. All Rights Reserved.

Copyright © 3-shake, Inc. All Rights Reserved. ● リスクの受容 ● SLO の定義 ● トイルの撲滅 ● 分散システムのモニタリング ● 自動化の推進 ● 適切なリリースエンジニアリング ● 単純さ SREの原則＝典型的にSREを実践するためのパターン、振る舞い、関心事 本日の発表で必要な知識を中心に紹介 SREの原則 ・Site Reliability Engineering: How Google Runs Production Systems. （2016） O'Reilly Media. （Niall Richard Murphy 他 玉川 竜司 訳 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム （2017）オライリージャパン） 第Ⅱ部 原則 ・Google - Site Reliability Engineering https://sre.google/sre-book/part-II-principles/ （参照 2022/11/14）

Copyright © 3-shake, Inc. All Rights Reserved. SREでは単純に稼働時間を最大化するよりも可用性におけるリスクと、 機能開発やサービス運用の効率性のバランスを取る ● 100%の信頼性を目指さない ● 過度の信頼性はコストに跳ね返る ● 安定性を追い求めるとリリースの頻度が減る ● ユーザは高い信頼性と極端に高い信頼性に気づかない SREの原則①：リスクの受容 ・Site Reliability Engineering: How Google Runs Production Systems. （2016） O'Reilly Media. （Niall Richard Murphy 他 玉川 竜司 訳 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム （2017）オライリージャパン） 3章 リスクの受容 ・Google - Site Reliability Engineering https://sre.google/sre-book/part-II-principles/ （参照 2022/11/14）

Copyright © 3-shake, Inc. All Rights Reserved. SLO＝サービスレベルの目標・基準 ● SLI (Service Level Indicator) サービスレベル指標 ○ 何をもとにシステムの良し悪しを判断するかの指標となるもの ○ SLO を定義する時に利用する ○ ex. ユーザのリクエストに対して正常に応答（ 5xx以外のアクセス）した割合を SLIとする ● SLO (Service Level Objective) サービスレベル目標 ○ サービスレベルに対する内的な目標値 ○ ex. 前述のSLIが99.9%であることをSLOとする ○ 100からSLOを引いた失敗して良い割合（ 0.1%）をエラーバジェットとする ■ 失敗した割合が0.1%を超えるまでは、不具合解消より新規開発を優先する ■ 失敗した割合が0.1%を超えた場合は、新規開発を停止する ● SLA (Service Level Agreement) サービスレベル保証 ○ サービスレベルに対する対外的な保証値 SREの原則②：SLOの定義 ・Site Reliability Engineering: How Google Runs Production Systems. （2016） O'Reilly Media. （Niall Richard Murphy 他 玉川 竜司 訳 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム （2017）オライリージャパン） 3.4.1 エラーバジェットの形成、 4.1 サービスレベルに関する用語 ・Google - Site Reliability Engineering https://sre.google/sre-book/part-II-principles/ （参照 2022/11/14）

Copyright © 3-shake, Inc. All Rights Reserved. トイルとはSREが行う運用業務のうち以下の特徴に当てはまるものを指す - 手作業であること - 繰り返されること - 自動化できること - 戦術的であること - 長期的な価値を持たないこと - サービスの成長に対してO(n)であること GoogleではSREの作業時間のうち50%がトイル以外の 将来的なトイル削減やサービスの機能追加に時間を費やすべきと定義 SREの原則③：トイルの撲滅 ・Site Reliability Engineering: How Google Runs Production Systems. （2016） O'Reilly Media. （Niall Richard Murphy 他 玉川 竜司 訳 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム （2017）オライリージャパン） 5.1 トイルの定義、 5.2 トイルは少ない方が良い理由 ・Google - Site Reliability Engineering https://sre.google/sre-book/part-II-principles/ （参照 2022/11/14）

SREを導入する上での障壁とアプローチ 03 Copyright © 3-shake, Inc. All Rights Reserved.

Copyright © 3-shake, Inc. All Rights Reserved. SREを導入する上での障壁とアプローチ SREを導入することは一筋縄では行かない これまでの支援の中で直面した障壁とアプローチについて 実際に行った方法を交えながら話していきたい ● SREの原則を実践する難しさと進め方 ● 大企業で認識合わせする難しさと認識合わせの重要性 ● SRE人材を集める難しさ

SREの原則を実践する難しさと進め方 03-01 Copyright © 3-shake, Inc. All Rights Reserved.

決済基盤で考える SREの原則を実践する難しさ Copyright © 3-shake, Inc. All Rights Reserved. 例えば決済基盤の信頼性を考えてみる ● 金銭の取引であるため 1件もトランザクションを取りこぼしたくないケースもある ○ 例外的な手作業による再実行の処理はできるだけ実施しないが理想 ○ 取りこぼしは決済店舗からの信頼を失うし、全店舗に SREを浸透させるのは令和では夢物語 ○ ユーザが「システム側で再実行してくれるはずなので待つか」という世界は 現実的ではない ● サービスの特性によってはエラーを許容する SLOやエラーバジェットの考え方と相性が悪い 場合がある

単純にSLOでは計測できない信頼性が大事な要素である場合 Copyright © 3-shake, Inc. All Rights Reserved. サービスによっては 数値で測定することが難しいが信頼性の一部となる大事な要素 が存在する 理想 現実 SLOを守ってるので 将来のトイル削減！ SLOを守ってるので 新機能開発！ SNSが炎上してる... 復旧優先だ... 重要な決済機能で エラー出てるから 新機能開発できない...

SREの原則と相性が悪い場合の進め方 Copyright © 3-shake, Inc. All Rights Reserved. 例えばあなたのサービスで開発効率を上げることが一番大きい課題 →一時的にSLOによるハンドリングを一旦ストップ 別のデータを利用して開発生産性を向上させたり別の原則から始めるのも一手 ＝SREを諦めるのではなくSREを導入するために改善を進めていく 組織の強みなどを活かして別のKPIを仮に利用するのも一手 ex. ソフトウェア開発のパフォーマンスを数値化した Four Keysやそれに準じた値により業務をコントロール

SREの原則と相性が悪い場合の進め方 Copyright © 3-shake, Inc. All Rights Reserved. また効果が大きいところから 小さくSREを始めることで実績を作って行くことも大事 ・エンジニア必見！ SREへの第一歩 https://www.slideshare.net/ssuserf50296/sre-249888011 （参照 2022/11/14）

大企業で認識合わせする難しさ 03-02 Copyright © 3-shake, Inc. All Rights Reserved.

SRE は組織全体で取り組む課題 Copyright © 3-shake, Inc. All Rights Reserved. SRE は当然開発やこれまでの運用といった役割と密接に関わる SLOの定義や人材の調整などビジネスサイドとも密接に関わる SREは様々な組織や役割と密接に連携しながら実践していく Biz Dev SRE

連携がしっかり取れずにSREを導入する弊害 Copyright © 3-shake, Inc. All Rights Reserved. SREを導入に対する認識のズレや考え方の違いは 組織にとって軋轢や期待通りの結果を得られない原因になる 組織組成や改革は当事者や周りが冷めてしまったら終わり その為に生まれたての組織は尚更慎重に活動していく必要がある 企業の規模が大きくなるにつれて部署が分かれてサイロが増えてこれらの弊害の解消が難しくなる 組織の役割が曖昧でメンバーに目的が浸透しておらずタスクが進まない 活動が他のチームや上層部から理解が得られず新しい考え方や仕組みを導入できない 現実と折り合いを付けずに到達困難な目標を立ててしまいメンバーが疲弊する 新しい活動に割けるリソースがなく、コミット量が少なくおもったような結果が得られない

SREを企業に導入するためのステップ Copyright © 3-shake, Inc. All Rights Reserved. SREの探求 8章 大企業におけるSREの導入で紹介されているステップ 現状の 定義 ステーク ホルダーの 特定と教育 ビジネス ケースの 作成と提示 SREチーム の編成 結果の 計測 ・Seeking SRE: Conversations About Running Production Systems at Scale （2018） O'Reilly Media. （David N. Blank-Edelman 渡邉 了介 訳 SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践 （2021）オライリージャパン） 8.2 SREの導入 図8-1 SREを企業に導入するためのステップ

とある組織におけるSRE導入のステップ Copyright © 3-shake, Inc. All Rights Reserved. ● キーメンバーに組織についてヒアリング・ディスカッション ● 組織自体とSREについて理解を深める ● 組織をよりよくする方法や他部署とのコミュニケーション方法を確認・模索 ● 他部署へSRE導入について打診するための準備や導入の流れがその組織らしいSRE導入のステップとなっていった 現状の 定義 ToBe像 の定義 ビジネス ケースの 作成と提示 SREチーム の編成 結果の 計測 （予定） ステークホルダーの特定と教育 1プロダクトへ SRE導入

ステークホルダーの特定と教育 Copyright © 3-shake, Inc. All Rights Reserved. なぜSREの探求で紹介されているアプローチと異なりステークホルダーの特定と教育が薄く横断して引かれているのか？ ● 不確定な情報を伝えて混乱や誤解を招かないように ○ 各ステップやステップを実現するためのヒアリングごとに必要になるメンバーを特定・巻き込む ○ 前述の通り組織の組成・改革は慎重に行っていく ● 教育については必要なときにSREに関する知識や事例 ↔ 組織に関する知識で補う ○ 関わるメンバーが一気に増える場面では勉強会やハンズオンを適宜実施して知識を埋め合わせていく 現状の 定義 ToBe像 の定義 ビジネス ケースの 作成と提示 SREチーム の編成 結果の 計測 （予定） ステークホルダーの特定と教育 1プロダクトへ SRE導入

まずは1つのプロダクトへSRE導入 Copyright © 3-shake, Inc. All Rights Reserved. 効果が見込めるかつSREを導入しやすいプロダクトを選定してSRE導入を推進 プロダクトA プロダクトB プロダクトC ✕ 全プロダクトに一気にSRE導入 ○ まずはプロダクトを選定してSRE導入 SRE導入 プロダクトA プロダクトB プロダクトC SRE導入 選定基準：SREと親和性が高いサービス、すでに SREについて知識がある人の割合、等

将来的なプロダクトへのSRE導入の構想と全体のロードマップ Copyright © 3-shake, Inc. All Rights Reserved. 特定プロダクトに対しての小さなSRE導入を繰り返し、 将来的にはプロダクト横断的なSRE施策を実施する 1プロダクトSRE導入 1プロダクトSRE導入 1プロダクトSRE導入 1プロダクトSRE導入 1プロダクトSRE導入 1プロダクトSRE導入 3ヶ月 3ヶ月 3ヶ月 3ヶ月 3ヶ月 3ヶ月 3ヶ月のサイクルで各サービスへ SRE導入を行う 主な内容： SLO・エラーバジェット策定 / 監視基盤の改善 / オンコール対応フロー整備 など 横断的なSRE推進 単一サービスに収まらない横断的な SREに関する課題に取り組む （小さく始めるを意識しているが既に同じような取り組みを進めている部署があれば認識合わせを進める） SREのためのPlatform改善 SREを推し進めるためにインフラレベルの改善も進めていく （小さく始めるを意識しているが既に同じような取り組みを進めている部署があれば認識合わせを進める）

SRE人材を集める難しさ 03-03 Copyright © 3-shake, Inc. All Rights Reserved.

SRE人材に求められる能力 Copyright © 3-shake, Inc. All Rights Reserved. スキルセット オペレーティングシステムの内部、ネットワーキング、モニタリングと アラート、トラブルシューティング、デバッグ、インシデ ント管理、ソフトウェアエンジニアリン グ、ソフトウェアのパフォーマンス、ハードウェア、分散システム、システム管理、キャ パシティ プランニング、セキュリティ、その他にも多くの領域… 技術以外にもサービスと対峙する中で以下のような能力が求められる ● 新しいチームにオンボードしてそのチームを知ること ● 新しいサービスにオンボードしてそのサービスを知ること ● 少なくとも 1 つの既存サービスに対する重要な変更を実施することができる ● 自分たちのシステムがやり取りする別のシステムにおける変更への対処 ○ 例えばECサイトあればクレカ決済をしてくれるシステム ● 爆発的な成長や他の重要なシステム課題への対処 SRE人材は多くの能力を求められる これらすべてを満たす人材を見つけることは困難 ・Seeking SRE: Conversations About Running Production Systems at Scale （2018） O'Reilly Media. （David N. Blank-Edelman 渡邉 了介 訳 SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践 （2021）オライリージャパン） 20章 アクティブなティーチングとラーニング

各々得意なスキルを持ったメンバーで一枚岩で SREを実現する Copyright © 3-shake, Inc. All Rights Reserved. 自分たちのシステムの規模、やりたい事に応じて、 メンバーを構成して一つのチームとして SREを提供する ※ Googleではソフトウェアエンジニアが 50% ~ 60% 残りはそれ以外のSREに必要なスキルを持ったメンバー （とはいえGoogleの場合は、ほぼソフトウェアエンジニアに近いスキルの人材とのこと） Software Engineer Software Engineer Software Engineer Infra Engineer Network Engineer Project Manager SRE ・Site Reliability Engineering: How Google Runs Production Systems. （2016） O'Reilly Media. （Niall Richard Murphy 他 玉川 竜司 訳 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム （2017）オライリージャパン） 1.2 サービス管理への Googleのアプローチ：サイトリライアビリティエンジニアリング

SREと教育 Copyright © 3-shake, Inc. All Rights Reserved. 内製化やさらなる増員を考えるとSREを教育していく必要もある ● SREの探求で紹介されているアクティブラーニングがおもしろい ○ アクティブラーニング ■ 座学ではなく生徒が能動的に考え、学習する教育方法 ○ アクティブラーニングの例としてゲームが紹介されている ■ ロールプレイングゲームによる障害対応訓練 ● リスクやプレッシャーの少ない ● 障害対応、原因分析、インシデント管理について学べる ● 前職のMSPではロールプレイングゲームで 障害対応の意志決定＆オペレーションを学んだため個人的はおすすめ ■ カードゲームによるインシデント対応 ● インシデント管理で重要なコミュニケーション、調整、責任の分離について学ぶ ・Seeking SRE: Conversations About Running Production Systems at Scale （2018） O'Reilly Media. （David N. Blank-Edelman 渡邉 了介 訳 SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践 （2021）オライリージャパン） 20.1 アクティブラーニング、 20.1.1 アクティブラーニングの実例： Wheel of Misfortune、20.1.2 アクティブラーニングの実例： Incident Manager（カードゲーム） ・インフラエンジニアの卵になってもらう研修 https://www.slideshare.net/kamaekawa/infraeduhb （参照 2022/11/14）

SREと教育 Copyright © 3-shake, Inc. All Rights Reserved. その他に学習習慣として紹介されている例は泥臭い ● 地道な努力は必要だし熱心なことは大切と理解 ○ 障害やサービスについて議論する MTGに参加してもらい疑問点をリストにしてもらう ■ 後ほどメンターが回答して育てていく ○ 初めて担当するシステムの要件を把握してから設計のスケッチを自分なりにまとめる ■ 何もわからない状態から自分で調査 ■ 既存資料で答え合わせ ■ 時間はかかるけど楽しいし効率が良いと感じられるとのこと ・Seeking SRE: Conversations About Running Production Systems at Scale （2018） O'Reilly Media. （David N. Blank-Edelman 渡邉 了介 訳 SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践 （2021）オライリージャパン） 20.1.3 アクティブラーニングの実例： SRE Classroom

最後に 04 Copyright © 3-shake, Inc. All Rights Reserved.

最後に Copyright © 3-shake, Inc. All Rights Reserved. Googleのとあるソフトウェアエンジニアがシステム運用を任されて、 長い時間をかけて理想を形にした結果がSREである。 現在サービスを運用する上で最適だと言われる方法論の一つとしてSREがあり SREの本の状態を目指すことが真のゴールではない。 SREのプラクティスを自分たちなりに解釈して 組織やサービスと向き合い続けて、仲間を集めた先に、 あなた（の組織）らしいSREが生まれるのです。