サービス・レベル目標（SLO）とは

小数点が100に近いほど、通常、達成するにはコストと複雑さが大きくなります。社内外の顧客は、一定レベルの応答性を要求する場合があります。そのレベルを超えると、違いに気付かなくなります。SLOを設定することは、科学と芸術の一部であり、統計的な完全性、飛行効率性、現実的な目標のバランスを取ることと関連しています。

開発チームは新しい機能を提供したいと考えており、運用チームは安定性と品質を提供し、管理された方法で変更を導入したいと考えています。企業は社内外の顧客に製品やサービスを提供するにあたり、顧客の視点からサービス・レベルを測定することが重要です。

SLOは信頼性を中心に組織をまとめるのに役立ちます。最終的には、利害関係者は、速度とサービス品質の効果的なバランスを実現する、顧客向けの測定可能なSLOに合意する必要があります。

信頼性の問題は会社に金銭的な損害を与える可能性があります。SLOが適切に設定されていれば、オブサーバビリティーにおけるギャップを確認して発見することができます。設定されたSLOは、組織内で使用されている複数の監視ツールからの分析情報を一元管理できる唯一の方法かもしれません。オブサーバビリティーが向上すると、より優れた製品の提供、顧客離れの削減、より効率的な運用が可能になります。

SLOとSLIは、サービスとアプリケーションのパフォーマンスに関する洞察を提供し、ダウンタイムやその他の潜在的な問題を正確に測定する手段をチームに提供します。この情報は、既存の製品を更新し、新機能をリリースする際に、イノベーションと信頼性のバランスを取ろうとするDevOpsチームやITチーム、その他の関連チームの役に立ちます。

顧客が体験するマイクロサービスの健全性を測定する、よく考え抜かれたSLOは、製品のパフォーマンスとユーザー・エクスペリエンスに関する貴重な洞察を提供します。

SLOの策定と追跡はどちらも、サービスとそれに関連する期待に対する理解に基づいて組織全体のチームを団結させるのに役立ちます。徹底的に検討されたSLOは、すべての関係者が自分の部署がサービスに何を期待しているかについて意見を述べ、SLAが満たされるようにするための自分の役割を理解するコミュニケーション文化を育みます。

さらに、SLOを使用してレポートを作成し、オートメーションを導入すると、チームの各メンバーがインシデントに関する質問に迅速に回答できるようになります。SLOはDevOpsチームやインフラストラクチャー担当チーム、SREチームにとって重要ですが、企業のほぼすべての側面のトランスフォーメーションも促進します。オブサーバビリティーを通じて収集されたデータは、アクセス可能でコンテキストに沿った実用的な情報に変換できます。これらの分析情報により、チームがタイムリーかつコスト効率の高い意思決定を行うために必要な可視性が提供されます。

目標が明確に定義されていれば、組織はオートメーションを利用してSLIを監視および測定できます。このアプローチは、監視を超えてエンドツーエンドのプロセスを完全に自動化するという目標を掲げ、目標が達成されていることを確認するのに役立ちます。

自動監視システムは、サービス・パフォーマンスがSLOで設定された目標を実際に達成できなかったり、SLAに違反したりする前に、潜在的な問題を検出するのに役立ちます。SLOを満たすプロセスが確立されると、例えばワークロードの需要に基づいてリソース割り当てを自動化するプラットフォームを使用することで、オートメーションを導入して一貫したパフォーマンスを確保できます。

SLOは、潜在的な問題が発生する前にDevOpsチームがその兆候を特定できるようにします。この先見性により、エンド・ユーザーに悪影響を与えたり、会社に金銭的な損害を与えたりする可能性のある、許容できないダウンタイムやその他のイベントを防止できます。

SLAでは、請求額を計算するために、月ごとのダウンタイムまたは可用性のパーセンテージが使用されることがよくあります。ダウンタイム期間は、システムが主要な機能を実行できない期間です。例えば、通信障害によってネットワークのダウンタイムが発生する可能性があります。業界の可用性基準は依然として高く、ダウンタイムのコストも増加し続けています。財務的な影響以外にも、SLOの不履行は顧客の不満につながる可能性もあります。

多くの組織は、事後対応型のインシデント管理プロセスに基づいて運営されています。しかし、インシデントが発生するまで待つと、システム内の問題の軽減と解決に時間がかかり、平均修復時間（MTTR）¹ が増加します。適切に確立されたSLOは、オブサーバビリティーの向上に役立ち、組織が インシデント管理をより積極的に実行できるようにします。

無関係なアラートは運用コストを増加させるだけでなく、存在しないアラートに応答することでエンジニアが時間を浪費し、生産性が低下することで、燃え尽き症候群の発生率を高める可能性もあります。アラートにおける最大の課題の1つは、アラートが多すぎることと、逆に少なすぎることの間の適切なバランスを見つけることです。

ここで重要になるのは、劣化により信頼性の目標が達成できなくなる可能性が高い場合にエンジニアに通知するアラート、つまり症状ベースのアラートです。例えば、過去1時間において、サービスに対応にレイテンシーがあれば、その週のレイテンシーSLOを満たすことができなくなる可能性がある場合、これは大きな問題です。

SLAまたはビジネス目標をサポートするSLOを定義します。20項目のSLOは本当に5項目のSLOより4倍優れているのでしょうか。それとも、これは単にITチームの作業を増やし、顧客を混乱させるだけで、大きなメリットは得られないのではないでしょうか。測定できるものすべてを評価する必要はありません。

過大な約束をして、その後に不十分な成果しか得られない場合、罰金が高額になり、場合によっては顧客を失う原因にもなりかねません。現実的なSLO目標を設定してください。社内の関係者だけでなく顧客に対しても現実的になることで、誰もが十分な情報に基づいた意思決定を行うことができます。非現実的に高いSLO目標は、長期的にはコストがさらに高くなるだけです。

現実的な期待に事前に合意することで、社内チーム間および顧客との間で将来的に生じる混乱や対立を回避できます。

手動のメトリクス収集シートでは修復が遅くなり、根本原因の分析ができなくなる可能性があります。関連するSLIを収集してSLOを自動的に評価し、SLOが満たせなくなる前にに自動アラートが発せられるように設定します。また、重大な問題になる前に、スタッフが問題に対処できるよう、必要な背景情報と依存関係を明確にします。