DevOps / 記事

Love DevOps? Wait until you meet SRE

Google という会社について少しでも聞いたことがあるでしょう。この会社は、無人自動車や宇宙エレベーターといったクールなものを発明しています。そう言えば、Gmail、Google ドキュメント、Google マップなどの大成功を収めたアプリケーションも開発していますね。彼らは、成功するアプリケーション開発について熟知していると言っても過言ではありません。

Google もまた、Site Reliability Engineering (SRE) と呼ばれる発展途上のムーブメントを支えている先駆者です。SRE は、開発チームと運用チーム間の長年の争いを事実上終わらせます。また、製品の信頼性、アカウンタビリティ、そしてイノベーションが促進されます (ただし、「Software Development High School」のような、廊下を舞台にした学園ドラマはありませんが)。

これはどうしてでしょうか。まず、基本を見てみましょう。

SRE とは何か

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

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

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

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

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

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

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

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

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

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

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

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

Illustration of coworkers having a conversation

SRE チームは実際には、ロックスターのような開発者とシステム管理者の混成チームです。彼らは、問題を見つける方法を知っているだけでなく、問題を解決することもできます。また、開発チームと円滑にやり取りを行い、コードの品質が改善するにつれてプロジェクトに必要な SRE の人員が少なくなると、多くの場合、開発チームに移ります。

実際には、主要原則の 1 つにおいて、SRE は運用業務に自分の時間の 50% しか費やすことができないと規定されています。できる限り多くの時間をコードの作成やシステムの構築に費やし、パフォーマンスや運用効率の向上に取り組む必要があります。

開発者も手を汚す

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 の導入に向けて一歩を踏む出すための実用的な手順や、テクノロジーが果たすことができる役割が取り上げられていくでしょう。

著者について

Patrick Hill

アトラシアン、Site Reliability Engineer

私は以前からアトラシアンに勤めていますが、最近、シドニーからオースティンのオフィスに転属になりました (皆さん、よろしく!)。余暇には、顎ひげのスタイルを「著名な教授」から「木こり」へと変えて楽しんでいます。Twitter で私を見つけてください! @topofthehill

さらに詳しく
Jira Service Desk logo

より多くの問題をさらに素早く解決

無料トライアル
Jira Software logo

プロジェクト / 課題管理

無料トライアル