概要
「SREをはじめよう」を読み終え、自分が学んだ部分にフォーカスしてアウトプットをかねて記事にしました。
この記事は私の経験と視点に基づいています。
現場私の組織としてSREの文化はまだありません。なのでSREを実践されている方向けというより、これからSREをはじめたい、SREについて知りたい人向けの記事となります。
正しい、間違っているというものではなく、あくまでこういう考え方の人もいるんだなといった気持ちで捉えていただけましたら幸いです。
SREという分野の面白さ、奥深さと、組織におけるその重要性を改めて認識しました。本書はSRE実践のための具体的な手順書というよりは、SREの理念、文化、プラクティスを包括的に解説するガイドブックのような内容になっています。これからSREを始めようと思っている方や、すでにSREを実践しているチームにとっても、現状を客観的にみて改善点を見つけるためのきっかけとして役立つ本だと感じました。
自己紹介
自社開発企業に入社し、WEBエンジニアとしてプロダクト開発に携わっています。
最近はパフォーマンス改善やインフラ可視化部分に携わっています。
SREとは
Site Reliability Engineering（サイト信頼性エンジニアリング ）とは、元々Googleが提唱したシステム管理とサービス運用に対するアプローチで、システムやサービス、製品において適切なレベルの信頼性を持続的に達成するための工学分野です。
SREの定義
サイトリライアビリティエンジニアリングは、組織がシステム、サービス、製品において適切なレベルの信頼性を持続的に達成できるよう支援することを目的とした工学分野である。
「信頼性」「適切」「持続的」というキーワードが示すように、SREは単なる技術論ではなく、ビジネス目標と密接に連携した活動です。顧客視点でシステムの目的を理解した上で適切な信頼性レベルを設定し、SLI(サービスレベル指標)、SLO(サービスレベル目標)のようなプラクティスに焦点を当てています。
信頼性に問題があるとどんな損失がある？
- 収益: 障害中のシステムが収益を上げるために重要なものであれば損失になる
- 時間: 従業員は計画していた仕事の代わりに障害の対処をすることになる
- 評判: 顧客は不安定なサービスを使いたがらず、競合他社に乗り換えてしまう
- 健康: オンコール対応の人が定期的に呼ばれると精神的健康的にも影響を及ぼす
- 採用: IT業界は情報交換を頻繁に行なっている為あなたの職場が炎上しているということが知れ渡ったら採用が難しくなる
SREが該当する出発点と到達点範囲の図
SREの心構え
信頼性はフィードバックを通じて改善されるという考え方にしっかりと根ざしています。
インシデントやエラーログなどは必ずしも敵ではなく、それを元にフィードバックを可能な限り作成し、育成することがSREの役割です。つまり顧客やシステムからの声を聞き取り、いかに失敗から学ぶことが改善につながることがわかります。インシデント後レビューが一番成長改善できるチャンスなので、しっかり取り組みたいと感じました。
有効な取り組みとしてカオスエンジニアリングというものもあります。
カオスエンジニアリングとは
全世界に動画配信サービスを提供するNetflixが導入したことで注目されるようになった手法で、本番環境または本番前環境で障害を意図的かつ制御的に引き起こし、その影響を理解することでより良い防御態勢とインシデント・メンテナンス戦略を計画するという取り組みです。
システムは顧客にとってどのように機能するのか、顧客にとって、システムはどのように機能するのか
顧客の点からみたシステムの意図は何かを問い、常に顧客に与える影響に関心を持ち、顧客重視の姿勢を貫くことが大事です。
SREのロードマップ
Dickersonの信頼性の階層構造というものがあり、組織から信頼性という言葉が出てきたら、状況は良くなっているのか、悪くなっているのかを図るためのナビゲーションとして下層から実行していくと良いと言われています。
有名な図でたくさん記事が書いてあるので詳細は割愛します。
SREになるためには？
-
コーディングの知識
デバックやトラブルシューティングの方法を学ぶ
何がどのように作られているか知らなければ、それがどのように故障する可能性があるかを理解する能力は著しく制限される。システムの信頼性を向上させるためにそのシステムに対してコードレベルの変更を提案したり実行したりするべきです。 -
分散システム、故障した時の対応方法
統計とデータの可視化、監視やオブザーバビリティが組織におけるSREやSREの役割の根幹となる活動、関心ごとにアンテナを張る。ストーリーテリングというインシデント後のレビューやポストモーテムは基本的にストーリーがあり、うまく人に伝えなかればいけないのでわかりやすく物事を説明する、伝える能力が必要になります。
ソフトウェアエンジニアとしては以下思考、取り組みが大事だと感じました。
- 自分の書いたコードがどのように故障する可能性があるのか把握
- 簡単にデバックできるコード、仕組みづくり
- リリースに関して簡単にロールバック、アップデートできる仕組みを作る
SRE文化作り
チームのSREが成功する唯一の方法は、SREが必要とする環境を理解し、育成すること
SREを実践するには、組織全体にSRE文化を根付かせることが重要で、そのためには、まずチーム内でSREのプラクティスを積極的に取り入れる必要があります。
具体的には、トイル削減のための時間をスケジュールに組み込み、作業の可視化と成果報告を徹底することで、SRE活動が周りに浸透していきます。また、作業前にドキュメントを作成し、タスクを小さなパーツに分割して目的を明確にすることで、効率的かつ効果的なSRE実践が可能になります。
そうやって早い段階からトイルの削減に重点を置くことでSRE文化の土台が築けます。
さらに、SRE文化を組織全体に広げるためには、SRE勉強会を開催し、シャドーイングやペアプロを通してスキル共有を促進することが有効です。SREの重要性を理解していない関係者に対しては、SREの役割やメリットを明確に説明し、SREへの投資が組織にもたらす価値を理解してもらう必要があります。SREのストーリーをどれだけ明確に伝えられるかが重要であり、理解してもらうことで組織全体でSREを推進していくための協力体制を作ることができます。
レジリエンス工学から学ぶこと
レジリエンス工学とは、システムが避けられない不測の事態に対応するために必要な能力のことである。
適応能力とは、経験する出来事、機会、混乱の種類の将来の変化に対処するために、活動のパターンを調整する可能性のことである、
したがって、適応能力は変化や混乱がその能力を求める前に存在する。
システムは様々な適応能力を持っており、レジリエンス工学は、それらがどのように構築され、維持され、劣化し、失われていくのかを理解しようとするものである。
SREを組織に導入するための成功要因
-
SREの組織導入を成功させるには、まずSREの役割と目標を明確にする必要があります。具体的にどのような問題を解決し、パフォーマンス改善、可用性向上、開発速度向上など、どのような目標を目指すのかを組織全体で共有することが重要です。SREは長期的な取り組みであるため、経営層を含めた組織全体のコミットメントと継続的な支援が不可欠です。
-
開発、運用、ビジネスなど、様々なチームとの連携強化が重要です。円滑なコミュニケーションと情報共有を促進する仕組みを構築し、SREがシステム変更にどの程度関与できるかを明確に定義し、適切な権限を付与する必要があります。
-
データに基づいた意思決定を重視する必要があります。現状を把握するための適切な指標を設定し、データに基づいて改善策を検討し、実行する文化を醸成することが重要です。失敗を恐れず、そこから学び、改善につなげるフィードバックループを確立することも重要です。
ビジネス視点で見るSRE
SREチームは、自らの存在意義を主張するのではなく、最終的には自分たちの役割が不要になることを目標とすべき
成熟したSREチームは、「もし〇〇だったら△回の障害が起きていた可能性がありました」といったヒヤリハットリストを作成することで、その成果を示して伝えることが重要です。
SRE組織の進化段階
SRE組織は、その成熟度に応じていくつかの段階を経て進化します。
消防士フェーズ : 本番環境の火災対応に追われる段階。監視/オブザーバビリティ、インシデントレスポンスの構築が課題になります。
ゲートキーパーフェーズ : 信頼性を守り、問題の発生を防ぐ段階。ゲートキーピングは反発を生む可能性があるため、全員が納得する問題に絞ることが重要です。
提唱者フェーズ : 組織全体の信頼性向上に取り組む段階。信頼性を担保するシステムを構築し、プロダクト開発の初期段階からSREが関与します。
パートナーフェーズ (18→48人): 開発者とSREが対等なパートナーとして、信頼性向上のための計画やロードマップを共同で作成します。オンコールの責任分担も可能になり、全員が信頼性に対して責任を持つようになります。複数のSREチームが存在し、Platform Engineeringチームなど専門チームも生まれます。
エンジニアフェーズ (48→108人以上): 全てのチーム・開発者にSREの意識が浸透し、SREチームは現場の運用から解放されます。SREは、他のチームでは対応できない高度な信頼性課題に集中できます。組織が大きくなり、オンボーディングも重要になります。
SRE組織の発展は必ずしもこの順番通りではなく、組織の状況によって異なることを理解しておくことが重要です。
組織における適切なSREのサイズ
SREチームの適切な規模は、組織の状況や成熟度によって異なります。
フェーズ1：立ち上げ期 (0→1人): まずは小さく始めてみる段階です。「とりあえず立ち上げる」ことを優先し、1人の担当者がSREの役割を担います。この段階では、SREの概念を組織に導入し、基盤を構築することに重点を置きます。
フェーズ2：探索期 (1→6人): SREの担当者が増え、他の業務と並行しながらSREを実践していく段階です。小規模なチームでSREの成功体験を積み重ね、組織内での理解と認知度を高めることを目指します。
フェーズ3：体制構築期 (6→18人): 18人程度の規模になると、24時間365日のオンコールローテーションが可能になります。チーム内に専門性が芽生え始め、より体系的なSRE活動が展開できるようになります。
フェーズ4：組織拡大期 (18→48人): 複数のSREチームが形成され、SRE組織としての体制が整う段階です。Platform Engineeringチームのような専門チームを設立したり、GoogleのSREチームのような組織構造を参考に、役割分担を明確化していくことが重要になります。チーム間の連携強化や情報共有、失敗から学んだ教訓の共有など、組織全体の結束力を高める取り組みが重要になります。
フェーズ5：成熟期 (48→108人以上): 大規模なSRE組織となり、さらなる専門チームの細分化や、新規メンバーのためのオンボーディング体制の充実化などが課題となります。この段階は入門書の範囲を超えるため、あくまで一般的な傾向として捉えてください。
重要なのは、必ずしもすべての組織が最大の規模を目指す必要はないということです。組織のニーズと状況に合わせて、適切な規模と体制を構築することが重要です。各フェーズの特徴を理解し、自組織に最適なSREチームの成長戦略を策定しましょう。
まとめ
この記事では、SREの基礎知識から組織への導入、チームの成長まで、幅広い内容を網羅できる本を紹介しました。SREは顧客中心の考え方と、継続的な改善を重視する文化によって支えられています。この本から信頼性の重要性を改めて認識したので、これからSREを始める方(私も含め)は、まず小さな一歩から始め、組織全体でSREの価値を共有し、共に成長していくことを目指しましょう！
すでにSREを実践しているチームも、現状を振り返り、新たな視点を取り入れることで、さらなる信頼性向上を実現できるはずです。「SREをはじめよう」をきっかけに、SREの世界への理解を深め、より安定したシステム運用と、より良いサービス提供を実現する一助になれば幸いです。
一緒に働く仲間を募集しています！
株式会社コネクター・ジャパンでは一緒に働いてくれる仲間を募集しています！
事業拡大に伴い、エンジニアを大募集しています。
興味のある方は下記リンクから弊社のことをぜひ知っていただき応募してもらえると嬉しいです。
▼会社について
https://www.wantedly.com/companies/cnctor/about
▼代表メッセージ
https://cnctor.jp/10years-anniversary/
▼応募はこちら
https://www.wantedly.com/companies/cnctor/projects