を14日間無料で試してみる
700以上ものツールと連携。システム障害を自動的に検出・診断するだけでなく、適切な障害対応メンバーをアサインし、デジタル業務全体の修復ワークフローを自動化します。
顧客にとって信頼性の高いサービスを構築するには、SLA・SLO・SLIの定義や追跡、モニタリングが必要です。
しかし、SLA・SLO・SLIなどの関係性を理解していないと、適切な設定や運用が実現できず、作業が増えすぎるという問題が生じます。
そこで今回は、SLA・SLO・SLIの定義やそれぞれの違い、適切な設定方法など、活用のポイントをご紹介します。
目次
SLA(Service Level Agreement:サービスレベルアグリーメント)は、サービス提供企業(ベンダー)と顧客との間で交わされる、サービスの品質についての合意です。
サービス可用性などの特定のメトリクスに関して、企業が顧客に提示したさまざまな公約が定められています。
SLAには、以下の要素を含むのが一般的です。
サービスの品質・性能について具体的には、稼働率や障害回復までの時間です。例えば、GoogleのSLAでは、月間稼働率99.99%以上を顧客に保証しています。
さらに、SLAには違反の責任も定められます。SLAで設定した内容が守られなかった場合のペナルティや救済手段として、返金や改善対策の実施などを設定されることが多い傾向です。
SLAは、サービス提供企業の責任範囲を明確にするために活用されています。有料サービスを利用する顧客との間で締結されるものであり、無料サービスでは締結が不要です。
SLO(Service Level Objective:サービスレベル目標)は、インシデント対応や稼働時間などの具体的なメトリクスに関して、企業が顧客に提示する公約です。SLAの構成要素であり、個別の公約として顧客との合意内容に含まれます。
SLOは、SLAを遵守するためにサービスが満たさなければならない具体的な目標です。ただし、SLOは理想的な数値や最大限のしきい値で設定するのではなく、組織がビジネス目標を達成するうえで許容可能な最低限のレベルが望ましいでしょう。
GoogleのプロダクトマネージャーJay Judkowitz氏とMark Carter氏は、SLOについて「各サービスに対して許容できる最低限のレベル」を定義する必要があると述べています。
月間稼働率99.99%を保証するGoogleのSLAでは、SLOを99.99%に設定されています。
SLOの設定は、サービスの全体的な品質や信頼性の向上につながります。そのため、SLOは有料サービスと無料サービスの両方にとって有益なものです。
SLI(Service Level Indicator:サービスレベル指標)とは、SLOの達成を判断するために使用される主要なメトリクスです。SLO内に示されたメトリクスの測定値を指します。
SLIに設定されるメトリクスの例には、以下が挙げられます。
例えば、前述したGoogleのSLOは月間稼働率99.99%ですが、SLIはその時点で測定された実際の値です。SLAを遵守するには、SLIは常にSLOで定められた値か、上回る値を達成しなければなりません。
そのため、ダウンタイム発生時に早急に対応できるよう、優れたインシデント対応計画を立てることが重要になります。
SLA・SLO・SLIは、いずれもSREの重要指標です。SRE(Site Reliability Engineering)とは、元々Googleが提唱したアプローチで、システム管理やアプリケーション監視などのITインフラストラクチャタスクをソフトウェアを用いて自動化する方法です。
SLAは、多岐にわたるSLOで構成され、SLIを測定することにより追跡・モニタリングされる関係にあります。そして、サービス提供企業と有料サービスを利用する顧客間での合意を定義するためのものとして、対外的に使用されます。
SLOは、SLAを達成しているかを判断するために社内で設定する目標値です。SLOに定めた項目で違反が発覚した場合、チームは迅速に対応し、SLAの未達を阻止するために対策を講じる必要があります。
SLOは、重要なSLIを密にモニタリングすることにより測定されます。SLOは目標値ですが、SLIは実績値のため、SLIなしにSLOの正確な測定はできません。
SLOが未達の場合は、顧客満足度の低下を招くことがあります。さらに、SLAを下回れば顧客との契約違反となるため、サービス提供企業は違反の責任を負わなければなりません。
サービス提供企業はSLA・SLO・SLIにより、サービスにおいて顧客へ保証したことの定義・追跡・モニタリングが可能です。適切な設定や運用に役立つポイントをご紹介します。
SLAは、サービス提供企業のビジネス部門または法務部門により策定されます。
策定段階に技術チームを含めない場合、SLAは重要な側面を欠くことになり、測定が極めて困難なものになります。
それを回避し、より現実的なシナリオに沿ったSLAを完成させるには、技術チームと連携してSLAの策定に取り組む必要があります。
SLOはユーザーエクスペリエンスに基づいて、シンプルかつ明確で測定が簡単にでき、目標が達成できているかを判断できるもの、制御可能なものを選定しましょう。
不明瞭なSLOが設定されていると、運用に混乱を招き、エンジニアの作業を中断させることにもなりかねません。
SLI を選択する際には、サービスに適した指標・指標タイプ・指標の品質・必要な指標の正しい数を考えなければなりません。そして、なるべく内容をシンプルにしモニタリングする主要メトリクスを、正しく選択することが大切です。
追跡するメトリクスが多すぎると、作業が増えるばかりで、結局ほとんど効果を得られません。
SLA・SLO・SLIを包括的に活用すれば、インシデント管理と対応プロセスの継続的改善を重視しながらも、サービスに関する顧客の信頼を高められます。
SLIに設定した可用性などに関わる項目の低下を防ぎ、サービスの信頼性を向上させるには、インシデント管理も重要です。
インシデント管理ツール「PagerDuty」は、インシデント対応の自動化推進や再発防止、オペレーション改善のための分析を実施することで、将来のインシデントを予防できます。
PagerDutyに関する資料や導入事例は、以下のページからダウンロードいただけます。
https://www.pagerduty.co.jp/resources/
また、PagerDutyでは、14日間の無料トライアルをご利用いただけます。
https://ja.pagerduty.com/sign-up/
700以上ものツールと連携。システム障害を自動的に検出・診断するだけでなく、適切な障害対応メンバーをアサインし、デジタル業務全体の修復ワークフローを自動化します。
目次