SREについて
SREをはじめるには
近年、何かと話題に上がるSRE(Site Reliability Engineering)
しかし「自分たちのチーム・組織に関係する話なのかよく分からない」「具体的に何をやればいいのか？」といった感想を持つ方が多い
参考文献
- 英語版は、オンラインで無料で公開されている Google - Site Reliability Engineering
- 日本版はオライリー・ジャパンにより出版されている SRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチーム
はじめに
- SREって何？
- これまでのシステム運用やDevOpsとは何が違うの？
- SREに取り組む前に考えるべきこと
SRE
- SREは、Googleが提唱したエンジニアの役割。
- また、Site Reliability Engineeringという名称の通り、システムの信頼性に焦点を置いている
Google社 VP of EngineeringのBen Treynor氏によるSREの説明を、書籍「Google - Site Reliability Engineering」より引用
My explanation is simple: SRE is what happens when you ask a software engineer to design an operations team.（筆者訳：私の説明は簡潔です。SREは、ソフトウェアエンジニアに運用チームの設計を依頼した時にできあがるものです。） - 引用：Google - Site Reliability Engineering
ソフトウェアエンジニアがシステム運用を設計することで、これまでのシステム運用と具体的にどのような違いが生まれるかについて考えてみる
システム運用とは何か
- ソフトウェアが稼働するサーバーの準備が必要
- ネットワークの設定・構築も必要
- サーバー内でソフトウェアが稼働する状態を設定しなければならない
- ソフトウェアに変更があれば修正を反映する作業も行う
- 障害が発生した場合には、サーバー、ネットワーク、ミドルウェアやのどこに原因があるかを突き止め、解消しなければならない
ソフトウェア開発の一連の流れは、 ソフトウェアを開発する役割（Dev）と ソフトウェアの価値をユーザーに届け続ける役割（Ops）が存在している 後者の役割を担うのが、システム運用
従来のシステム運用のデメリット
直接的なコスト
- システム運用を手作業で行っていた場合、システムが大きくなればなるほど、比例して作業量が増加する
- ユーザー増えれば、それに伴い管理するサーバーは増える、開発に関わるソフトウェアエンジニアが増えれば、変更頻度が増えることにより障害発生頻度も増加する。それにより、システム管理者をたくさん雇用しなければならない
間接的なコスト
- 従来のシステム運用では、DevとOpsが、時に対立的にならざるを得ない場面がある
- 開発をした修正を次々にリリースしたいDevに対して、安定してシステム運用するために変更頻度を減らしたいOpsとでは、修正変更を行うことに対するスタンスが真逆
- 時に利害関係解消のための、コミュニケーションコストが発生することがある。これをSRE本では、間接的なコストと呼んでいる
SREと従来のシステム運用との違い
SREは従来のシステム運用が抱えるこれらのデメリットを解消するための方法論を持っている
- システム運用に伴う作業の多くをエンジニアリングによって効率化・自動化を行う
- エンジニアリングによって効率化・自動化された作業には、人手による作業を削除・もしくは撲滅することができる
- システムが大きくなることに伴う直接的なコスト（人件費）の増加速度を低減させることができる
- SREでは、エラーバジェット（エラー予算）の考え方を採用することで、前述した対立構造を解消できる
- エラーバジェットは文字通り、エラーの発生を予算のように扱う考え方
- エラーが発生すると予算が減り、予算が無くなりそうになると、Devは新しい変更をリリースせずに、既存のエラーに優先対応する
- こうすることで、DevとOpsもエラーバジェットという共通目標に向き合うことで、協力的な関係が生まれる
SREは、従来のシステム運用に置ける問題を解消するための、延長線上にある考え方だと分かる
「SREは、ソフトウェアエンジニアに運用チームの設計を依頼した時ににできあがるもの」という意味を少しでも感じ取れる
SREとDevOpsの違いに対するGoogleの解説
What's the Difference Between DevOps and SRE?
この動画の中で、「class SRE implements DevOps」というメッセージが登場する。つまり、SREがDevOpsを実装しているという考え方で、動画内では、「DevOpsを哲学とするならば、SREはその哲学を達成するための規範的な方法です」とも解説されている
動画の後半では、「しかし、プログラミングのクラスがそうであるのと同様、class SREには、追加の機能やメソッドがあるかもしれない」と補足されている。 要するに、SREは、DevOpsを推進するための実装を行うが、それだけではなく、上記で述べてきたような従来のシステム管理の役割も担うということ
SREに取り組む前に考えるべきこと
SREを取り入れるメリットについての期待値コントロールを行う
- SREを取り入れるメリットを改めて整理すること
- 例えば、みなさんの会社が、システムの運用に関わる人月計算でビジネスが動いているとした場合
- 「SREを取り入れて、運用工数を削減しましょう」と提案しても、「そんなことをしたらうちのビジネスが縮小するだけでは？」と、SREに否定的な態度を取られてしまう可能性だってある
- ソフトウェアエンジニアが運用を設計することのメリットは、必ずしも効率化や自動化だけではない
- メリット・デメリットの整理は自身の組織やチームを見渡しながら考えてみる
- 「今、組織でこういう問題が起きているけど、SREの考え方を取り入れれば解消するのでは？」
- 「うちの場合は、SREを取り入れるメリットが適切に発揮できそうだ」などきっと色んなアイデアが思い浮かぶはず
- 例えば、みなさんの会社が、システムの運用に関わる人月計算でビジネスが動いているとした場合
SREを取り入れる際に組織規模は関係はない。 ソフトウェアエンジニアの考え方を似てシステム運用を設計する原理原則に従うことに、組織やチーム規模は関係ないから。
Google SREとの差分を意識しよう
- SRE本、各章それぞれがエッセイで構成されている
- SREの原理原則に従いGoogle社内で実践されてきたプラクティスだが、厳密で学術的なものではない
- Googleのプラクティスはもちろん大いに参考にすべきだが、必ずしもGoogle SREと同じ実践する必要はない
- Gooogle SREと自分たちとの差分を意識するとよい
SRE本の出版は、世の中の他の企業からもたくさんSREに関するプラクティスを生み出して欲しいというGoogleの想いが込められている
さいごに
Googleと言えば、エンジニアリングばかり注目されがだが、SREに関して理解を深めると、組織運営のプラクティスも非常に先進的な企業であることが分かる
- Googleのカンファレンスにて
世の中のすべての企業が、SREという役割や名称を引き継ぐかどうかは分からないが、多かれ少なかれ、SREの考え方に影響を受ける企業は増えていくと感じる
SREをはじめるには、まずどうすればいいですか？ SREに必要なスキルと取り組み方
はじめに
- SREに必要なスキルセット
- SREに取り組むために
- サービス信頼性階層
SREに必要なスキルセット
「SREは、ソフトウェアエンジニアに運用チームの設計を依頼した時にできあがるもの」というBen Treynor氏（Google VP of Engineering：SREの考案者）の言葉を紹介した
書籍『Site Reliability Engineering』のChapter 1の中で、「SREがすべきこと」（Tenets of SRE）について紹介されている。
In general, an SRE team is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of their service(s).
筆者訳
一般的に、SREチームは、「サービスの可用性」「レイテンシ」「パフォーマンス」「効率性」「変更管理」「モニタリング」「緊急対応」「キャパシティプランニング」に責任を持ちます。 - 引用：Chapter 1 - introduction（Google - Site Reliability Engineering）
SREの責務から考える
「サービスの可用性」を保つには
- 冗長構成を設計および実装できる必要がある
- パブリッククラウドを利用している場合は、利用するサービス自体の可用性を考慮するためには仕様の深い理解が求められるケースもある
「パフォーマンス」を向上させるには、どのようなスキルが必要か
- データ構造やアルゴリズムをふまえ、非効率なプログラムの改修を行えば、パフォーマンスは改善できそう
- パフォーマンスの向上のため、キャッシュ層をどう活用するかを考える必要もある
「変更管理」について
- 変更管理は、システムに対する変更内容を管理すること
- 例えば、ミドルウェアのconfigファイルの変更を行った際には、変更内容をどこかに記録する
- SREはシステム運用とサービス開発の思想・スキル双方が必要
- また、責務を満たすために扱うツール群も多く、かつ、それらを協調させることが求められる
SREが使うツール
AWSのサービスをメインで紹介
Infrastructure as Code
Monitoring
Log
- fluentd
- Beats/Logstash
ChatOps
- Slackなどのチャットツールから、コマンドなどを入力することで何かしらの作業を行う
- Hubot
CI/CD
Development Environment
- 開発環境
- Docker
- VirtualBox + Vagrant
Infrastructure Automation
Security
Data
Incident Management
- インシデント管理
- PagerDuty
- ステータス管理
- Statuspage
Performance Test
プログラマブルに運用を行う
- SREとして仕事をしていくにあたり、一番はじめに変えるべきことは、プログラマブルに運用をしていく意思統一
- SREは「ソフトウェアエンジニアに運用チームの設計をした時にできあがるもの」なので、プログラマブルに問題解決を行うことが本質的な部分だから
- 前述した「変更管理」にInfrastructure as Codeの考え方を適用するのはわかりやすい例
- 他にも、コーディングすることで、特定の運用業務こ効率化・自動化していくこともプログラマブルに運用を行うことの分かりやすい例
- プログラマブルに運用を行うべき範囲は各社異なっていると思うので、まずは現状を俯瞰してみる
運用業務の土台を整える
- コードを書いて運用業務を効率化・自動化していくには、時間が必要
- 運用業務の現状がボロボロになっている状態であれば、SREを実践していくにあたり、まずは土台整備から行うべき
- 運用業務の土台が整備できない状態とは
- サービス稼働に必要不可欠な運用業務が1人しか実施できない状態かつ、その業務のドキュメントが整備されていない
- サービス稼働に問題が起こったことを検知できず、かつ問題の原因究明が行われない（また原因究明を行う時間がない、もしくは原因究明を行う技術力が自社で不足している）
- 上記のような状態にも関わらず、サービス運用の改善に対する問題意識が薄い
バス因子に対処する
- まず第一にやらなければならないことは、バス因子に対処すること
- バス因子とは、書籍『エラスティックリーダーシップ』に登場する表現で、バスに轢かれてしまい、いなくなってしまったらプロジェクトに大きな影響を与えてしまう人物のこと
- つまり、プロジェクトにとって必要不可欠な人のこと
バス因子に対処するとはどういう意味でしょうか。簡潔に書くと「その人に依存しなければならない状況を可能な限り減らすこと」です。
PDCAではなくOODA
サービス稼働に問題があった際に検知できる環境を整備する必要がある。これは端的に書くと、モニタリングを整備すること。モニタリング結果から分かったことを元に、実際に改善を行っていくことで、サービスの信頼性を向上させる
「SREは、PDCAではなくOODAを回すことが重要」
OODAは、アメリカ空軍のジョン・ボイド大佐によって提唱された理論で、指揮官のあるべき意思決定プロセスを分かりやすく理論化したもの
OODAとは
- 観察・監視（Observe）
- 情勢への適応（Orient）
- 意思決定（Decide）
- 行動（Act）
運用業務に関わっている読者の方は、身をもって体感されていると思うが、サービス運用業務では、不確実性が高い状況に度々直面する。そのため、どこからどうやって手をつけていくかをPlanするよりも、まずObserveするべき
サービス信頼性階層
信頼性という抽象的な概念を、どのような要素として理解すればよいかについて補足
以下は、書籍『Site Reliablity Engineering』に登場する「Service Reliablity Hierarchy（サービス信頼性階層）」の図です
- モニタリングが重要である点は前述下が、その次に整備すべきは、Incident Response（インシデント対応）
- ここで言う「インシデント」とは、セキュリティインシデントに限定した話ではなく、障害対応全般だと理解ください
- ここで言うIncident Responseは、単に問題に対応すればよいと言うものではなく、「インシデント管理プロセスが、チームで共通化された効率的な対応フローになっているかどうか」という観点が重要
- 例えば、問題が発生した際に、まずどういう行動をとるべきかは、チームで共有されているでしょうか。トリアージ[1]は誰でも同じ基準で行うことができるでしょうか。こういった観点を突き詰めていくと、一言でIncident Responseといっても、実にさまざまな論点が含まれていることが分かります。
[1] トリアージ：事象の緊急度に従って優先順をつけ、可能な範囲で問題の影響を緩和すること。詳しくは以下を参照。 - クラウド時代のトラブルシューティング : 解決に役立つプロバイダーとのコミュニケーション（後編）（Google Cloud Platform Japan Blog）
