DevOps を気に入りましたか? SRE もご紹介します

SRE とは何か

Google における SRE の裏の立役者である Ben Treynor 氏は、まだ 1 文の定義も発表していませんが、サイトの信頼性について「以前は運用と呼ばれていたタスクをソフトウェアエンジニアが担当するときに生じるもの」と説明しています。

根本的な問題は、開発チームは画期的な新機能を多くのチームにリリースして、それらが大々的に利用されるのを見たいと思っているのに対し、運用チームはそれらの機能によって問題が起きないようにしたいと考えていることです。従来、こうした考えが大きな権力争いを引き起こしてきました。運用チームはリリースを最小限に抑えようとし、開発チームはリリースを妨げるプロセスを巧みに回避しようと新たな方法を模索しているのです (よくある話だと思います)。

SRE は推察を取り除いて、何をいつリリースできるかを議論します。また、リリースの可否を決めるための数式を導入したり、運用スキルを持つスタッフ (SRE (Service Reliability Engineer) と呼ぶのが適切) で構成されたチームの作業に専念して、製品の信頼性を継続的に管理したりします。Google 自身の SRE である Andrew Widdowson 氏は次のように述べています。「私たちの仕事は、世界で最も情熱的なピット クルーの一員になるようなものです。私たちは、100mph で走るレーシング カーのタイヤを交換しているのです」

まだ革新的なようには聞こえませんか? この魔法の大きな特長はその仕組みにあります。ここでは、主な原則の一部を紹介しますが、これらも期せずして、従来の IT 運用から最もかけ離れているものです。

まず、現在の製品のパフォーマンスに基づいて、新しいリリースにゴーサインが出されます。

ほとんどのアプリケーションは 100% のアップタイムを達成できません。そのため SRE チームでは、各サービスに SLA (サービス レベル アグリーメント) を設定してシステムがエンド ユーザーに提供しなければならない信頼性を定義します。チームが 99.9% の SLA に同意した場合は、0.1% のエラー予算がチームに与えられます。エラー予算はその名前のとおり、エラーやシステム停止に対する許容可能な最大しきい値を表します。

ヒント: この便利なアップタイム チート シートを使用して、SLA を「ダウンタイム時間 (分)」に簡単に変換できます。

決定的要因は、開発チームがこのエラー予算を好きなように「使える」ということです。製品が問題なく動作している場合 (エラーがほとんどまたはまったくない状態の場合)、開発チームは何でも望むことをいつでも開始することができます。逆に、エラー予算に達した、あるいはエラー予算を超えた場合や、定義済みの SLA 以下で運用している場合には、リリースを進めることができるレベルにまでエラーの数が減らなければ、すべてのリリースが凍結されます。

特徴は、SRE と開発者の両者が協力してエラー数を最小限に抑えるために、強力なインセンティブを持っていることです。

SRE はコーディングもできる

古いモデルでは、信頼性に関する問題に対して人材を投入し、問題が解決するか、あるいは計画が中止されるまで、解決するよう要求し続けます (場合によっては 1 年以上)。

しかし、SRE ではそのようなことはありません。開発チームと SRE チームの両方が単一のスタッフプールを共有するため、SRE が採用されるたびに、利用可能な開発者が 1 人少なくなります (逆も同様)。これにより、開発チームと運用チームとの間で延々と続くスタッフ争奪戦に終止符を打つことができます。また、開発者がより高パフォーマンスのコード (例：SRE を減らすことで、必要なサポートも減らすようなコード) を作成するために、チームメートの増員が可能な自己管理型のシステムを構築できます。

開発者も手を汚す

Google では、Ben Treynor 氏がこの条項のために争わなければなりませんでしたが、彼は自分が成し遂げたことに満足しています。それどころか、彼は SREcon14 で行った SRE に関するすばらしい基調講演において、SRE を開始する前に経営陣からこの約束を取り付ける必要があると強調しています。

基本的に、開発チームは全運用ワークロードの 5% を処理します (チケットへの対処、オンコール サポートの提供など)。これによって、担当の製品との密接なつながりを維持してそのパフォーマンスを確認できるだけに留まらず、コーディングやリリースに関する意思決定をより適切に行えます。

また、運用負荷が SRE チームの能力を超えた場合はいつでも、超過分が開発者に割り当てられます。システムが正常に動作している場合、開発者は自己管理を始め、将来問題が発生しないよう、強力なコードを作成して慎重にリリースを行えるようにもなります。

SRE は自由契約選手である (必要に応じて引き抜くことができる)

チームが正常かつ満足した状態を維持するために、Treynor 氏は、SRE を各自の希望に応じて別のプロジェクトに移動したり、さらには別の組織に転属したりできるようにすることを推奨しています。SRE は、やる気にあふれ、献身的で効果的なチームワークを奨励します。そのため、どのチームメンバーも、個人目標の達成に努めることができます。

SRE と開発者から成るチーム全体が良好な関係になく、信頼できるコードよりも多くの問題を生み出しているような場合には、最終的な抜本的対策を取ることができます。つまり、SRE チーム全体をプロジェクトから外し、すべての運用作業を開発チームに直接割り当てるのです。Treynor 氏はこれまでのキャリアの中でこれを数回しか行ったことがありませんが、通常は両チームに十分な脅威をもたらし、より良好な仕事上の関係を築くことができます。

SRE が本番環境のインシデントを防止する方法、オンコールサポートチームへのスタッフの配置方法、各シフトにおいて従うルールなど、SRE に関する情報は 1 回の記事に収まりきらないほどあります。

当社の見解

IT は確かに、流行語やトレンドであふれています。あるときはクラウドでした。その次は、DevOps、カスタマー エクスペリエンス、ゲーミフィケーションです。SRE は強い立場にあり、基盤となるテクノロジーよりも人材やプロセスが重視されるようになってからは特に、こうしたトレンドをはるかに超える存在になっています。テクノロジーが成熟してより多くのチームが導入するようになる中で、テクノロジーは確実にコンセプトに適合できるようになっています (またはそうなる可能性が高い)。しかも、Site Reliability Engineering の原則を中心として開発チームと運用チームを連携させるために、新しいツールは不要です。

今後の記事では、SRE の導入に向けて一歩を踏む出すための実用的な手順や、テクノロジーが果たすことができる役割が取り上げられていくでしょう。