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

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

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

SRE原則

リスクの受け入れと管理

リスクを受け入れることは、SREの原則の第一であり、正当な理由があります。システムの信頼性を向上させるためには、”what if”の障害の影響を測定することが重要です。 100%信頼できるシステムはないことがわかります。ある時点で、何かがうまくいかないでしょう。残念ながら、日常のユーザーや顧客は、そう理解することを知らない、または気にしません。そして、信頼性の確保に関連する固有のコストがあります。つまり、金銭的なコスト、時間コスト、または単にサービスに対する顧客の信頼が必要です。

SR の責任は、最終的にサービスとシステムの回復力を高める方法を学ぶために、失敗とリスクに傾く責任があります。ただし、考慮する必要があるトレードオフがあります。たとえば、信頼性を最大限に高めるには、将来のサービスをより迅速に展開できるコストがかかる場合があります。それとも、さらなる改善は必ずしも収益の大幅な増加を意味するのではないですか? 目標は、信頼性の高いシステムを作るですが、それを行うことに関連するコストと時間が潜在的な利益を上回るので、必要以上にありません。

サービスレベル目標

リスクを受け入れる原則は、サービス・レベル・オブジェクト(SLA)と密接に結びついています。 SLA は、サービスレベルアグリーメント (SLA) 内の目標を形式化する一連の目標であり、サービスレベルインジケーター (SLA) に対して測定されます。 SLA は、サービスの実際のパフォーマンスメトリックです。たとえば、SLO で稼働時間が 99.9% である必要があると示されている場合、実際の SLI はその特定の SLO を満たすために、そのパフォーマンスメトリックを満たすか、それを超える必要があります。 SRE は SRE が継続的に監視する指標であり、そのしきい値から外れた場合はチームにアラートが表示され、問題を迅速に解決できます。 SL は、サービスに関連するエクスペリエンスにとって最も重要なものを決定するために、ユーザーに結び付けられています。

SLA 対 SLA 対 SL

SLA. 配信されるサービスのレベルを定義するクライアントまたは顧客との契約。
SL . 稼働時間、応答時間、セキュリティ、問題解決など、特定のメトリックを示す SLA 内の合意。
SL. コンプライアンスのレベルを決定する SLA の実際のパフォーマンス(測定値)

SLA は、サービスプロバイダーとクライアント間の契約である 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 サービスに新しい機能を追加する場合は、常に変更は避けられません。小規模で増分的な変更は、一度に多くの機能を構築して出荷するよりも、管理が簡単 (かつ簡単) です。また、中小企業はビジネスのニーズや目標も考慮する必要があります。