SRE原則:7つの基本ルール

以前の記事の 1 つで、SRE とは何か、その機能、および一般的な SRE が持つ共通の責任について説明しました。この記事では、サイトの信頼性エンジニアが役割を果たすさまざまな SRE の原則とガイドラインについて詳しく説明します。 DevOps と同様に、これらの SRE 原則は、組織の目標の調整、達成、サポートに関連するアライメントを促進するためのガイドとして機能します。

Google は、サイトの信頼性エンジニアリングの役割の背後にサポートを作成し、受け入れ、配置した最初の企業でした。それ以来、SREの役割は、業界が変化し、従来のモノリシック構造から大規模で広く分散したネットワークやマイクロサービスに移行するにつれて進化してきました。しかし、一つのことは、ほとんど同じままであり、SRが遵守する原則です。これらのコアSREの原則は、駆動システムとサービスの信頼性という1つのことに焦点を当てています。これらの中核となる SRE の原則について、より深く説明しましょう。

SRE原則

リスクの受け入れと管理

リスクを受け入れることは、実はSREの基本原則の1つであり、その理由は簡単に理解できます。システムの信頼性を高めるには、「what if」シナリオを考慮し、潜在的な障害から学ぶ必要があります。100%信頼できるシステムはなく、ある時点で何かがうまくいかなくなることは避けられません。残念ながら、ほとんどのユーザーはこの現実について知りません (または特に気にしていません)。彼らはただ物事がうまくいくことを望んでいるだけであり、その信頼性を達成するためには、お金、時間、さらには顧客の信頼を維持することにさえ、常にコストがかかります。

SREにとって、リスクに傾倒し、失敗から学ぶことは、レジリエントなシステムを構築するために不可欠です。しかし、常にトレードオフを比較検討する必要があります。信頼性を最大化するには、新機能のペースを遅くしたり、収益をあまり増やさずにコストを増やす可能性があります。このアイデアは、システムを実際に必要な信頼性以上に高めることではありません。結局のところ、余分な努力とリソースが意味のある価値をもたらさない場合は、他の場所に費やす方がよいでしょう。SREでは、コスト、速度、価値のバランスが取れた「適切な」レベルの信頼性を見つけることがすべてです。

サービスレベル目標

リスクを受け入れるという原則は、サービスレベル目標(SLO)と密接に関連しています。SLOは、サービスレベルアグリーメント(SLA)内の特定のパフォーマンス目標であり、サービスのパフォーマンスを追跡する実際の指標であるサービスレベル指標(SLI)に対して測定されます。たとえば、SLO で稼働率を 99.9% にすると記載されている場合、SLI はその目標に達しているかどうかを測定します。これらの SLI は SRE によって継続的に監視されるため、パフォーマンスが合意されたしきい値を下回った場合、チームはアラートを受け取り、迅速に対応することができます。SLIは、最終的にはユーザーにとって最も重要なことに関するものであり、チームがユーザーエクスペリエンスに直接影響を与えるサービスの側面を優先するのに役立ちます。

これらの用語の簡単な内訳は次のとおりです。

SLA: 提供されるサービスのレベルに関するクライアントまたは顧客との全体的な合意。
SLO: SLA 内の特定のパフォーマンス目標 (稼働時間、応答時間、セキュリティ標準など)。
SLI: SLO への準拠を追跡する実際のパフォーマンス測定値。

基本的に、SLOにより、チームはSLAに対する実際のパフォーマンスを測定し、サービス品質について明確な期待値を設定できます。この構造は、リスクに対する許容度が合意されていることを強化し、ユーザーのニーズとビジネス目標を満たしながら、サービスがどの程度の変動性またはダウンタイムを維持できるかを定義します。

「組織内の SLA コンプライアンスの管理について」を参照してください。

廃滅

Toil は、SRE ロールのスコープで定義されているとおり、サービスの実行を保証するために必要な手作業の量です。 SRE の主な目標の 1 つは、できるだけ多くの作業を自動化することです。これにより、SRはより重要なタスクに時間を与え出すことができます。そして、考えてみると、苦労を減らすことは本当に誰の仕事の一部であるべきです。冗長なタスクにかかる時間が短いほど、長期的には生産性が向上します。サイトの信頼性エンジニアが生産サービスの管理に関連して、繰り返し手作業を行う必要がある場合はいつでも、この作業は苦労と言えます。

多くの場合、SREが手動で時間のかかるアクティビティを実行しなければならない場合がありますが、それらのすべてを苦労として定義する必要はありません。ただし、SRE チーム内で最も時間がかかっているアクティビティを定義することが重要です。そこから、より良いワークバランスのために苦労の量を減らすために改善を行うことができる場所を特定します。 Google が SRE の役割を初めて導入したとき、SRE の半分の時間は、将来の運用作業の削減やサービス機能の追加に重点を置くべきであるという目標を設定しました。新機能の開発は、信頼性やパフォーマンスなどのメトリックの向上と相関し、最終的には潜在的な問題を減らします。

モニタリング

Dotcom-Monitorでは、サーバー、Webサイト、サービス、アプリケーションの稼働時間、可用性、機能性、およびオールラウンドパフォーマンスを追跡するためのソリューションを監視しています。監視は、ロール内で最も重要な SRE 原則の 1 つです。継続的な監視により、サービスが意図したとおりに実行され、問題が発生した瞬間を特定して、直ちに直ちに解決できるようになります。前のセクションで説明したように、これらの SLA を満たすことは、定義されたビジネス SLA の重要な要素であり、最終的にはユーザーです。監視は、SR やチームにパフォーマンスの履歴傾向を提供し、一回限りの問題と、より広範で全身的な問題に対する洞察を提供できます。 Google SRE イニシアチブで定義されているように、監視の 4 つのゴールデンシグナルには次の指標が含まれます。

レイテンシー: 遅延時間は、サービスが要求に応答するのにかかる時間 (遅延) です。明らかに、応答時間が遅いと、ユーザーエクスペリエンスに影響します。監視は、次の
トラフィック: トラフィックとは、システム上のユーザー需要(負荷)の量を指します。これは、1 秒あたりの HTTP 要求または実際のサービスによって測定できます。
エラー: エラーは、サービスへの要求が失敗する速度を示します。ただし、SRE チームは、500 個のサーバーエラーなどのハードエラーと、特定のパフォーマンスしきい値が設定されたためにタイムアウトした 200 OK 応答などのソフトエラーを区別することが重要です。このような異なるシナリオを適切に監視する方法を検討することが重要です。
彩度: 飽和は、特定のサービスが持っているシステムリソースの量を測定することです。ほとんどのサービスでは、ある時点までパフォーマンスが低下します。この状況を理解することで、監視目的と目標を正しく定義できるため、是正措置を実行できます。

オートメーション

自動化、自動化、自動化。私たちは、苦労を減らすことを議論したとき、私たちは先にこの原則に触れましたが、それは過小評価することはできません。 SREの役割の性質は、役割と同じくらい多様です。業務のあらゆる面で手動による介入の可能性を減らすために、業務を成功させるためにはタスクの自動化が重要です。サービスの規模が拡大し、分散化が増えるにつれて、管理が非常に困難になります。テスト、ソフトウェアの展開、インシデント対応、またはチーム間のコミュニケーションを通じて繰り返しのタスクを全面的に自動化することで、即座にメリット、効率性、そして最も重要な一貫性を提供します。 SREの役割が考案されて以来、開発、QA、および運用チームのコラボレーション方法が変わりました。これらの新しい DevOps 環境とプラクティスをサポートするために、さまざまなプラットフォームとツールが開発されました。

読む: トップ 13 サイト信頼性 (SRE) ツール.

リリースエンジニアリング

エンジニアリングをリリースします。複雑な主題のように聞こえますが、実際には、ソフトウェアの構築と配信方法を定義する簡単な方法です。リリース・エンジニアリング自体は独自のタイトルと役割ですが、SREのコンセプトの中で、安定した一貫性があり、もちろん再現可能なサービスを提供することを意味します。これは、オートメーションに関する前のセクションに戻ります。あなたが何かをするつもりなら、それを正しく行い、必要に応じて一貫した方法でそれを繰り返すことができます。大量の 1 回限りのサービスを構築するには時間がかかり、不要な苦労を生み出します。

GoogleのSREポジションの歴史に戻ると、SREと直接協力する専任のリリースエンジニアがいました。リリースエンジニアは、ソフトウェアサービスの開発、更新の展開、継続的なテスト、ソフトウェアの問題への対処に関連するベストプラクティスを定義する一般的な任務を負っています。サービスのスケールと展開をすばやく行う方法を考えると、この役割はより重要になります。一連のベストプラクティスとツールを持つこと(そしてそれらを強制する)ことは、これらの要求を満たすことが不可欠であり、ビルドが生産に投入されるとSREチームに安心感を与えます。

簡略

SREの役割のような責任と期待の数に終わりがないと思われるポジションでは、皮肉なことに、最後の原則はシンプルです。実際に行うよりも簡単に言えば、この原則は、必要なだけ複雑なシステムやサービスを開発するという考えに焦点を当てています。最初は直感に反するように思えるかもしれませんが、信頼性が高く、一貫性があり、予測可能なシステムが必要です。それは退屈に聞こえるかもしれませんが、SREには、それは究極の最終目標の1つです。

SR は、複雑で管理が困難ではないシステムまたはサービスを目指します。 SRは、単にそれが設計された仕事をする必要があります。しかし、ユーザーの観点からは、多くの機能を提供するサービスも多くの利点を提供するかもしれませんが、SREにとって、それは潜在的な頭痛を意味します。ただし、Web サービスに新しい機能を追加する場合は、常に変更は避けられません。小規模で増分的な変更は、一度に多くの機能を構築して出荷するよりも、管理が簡単 (かつ簡単) です。また、中小企業はビジネスのニーズや目標も考慮する必要があります。