SLA

Service Level Agreement

運用・現場

サービス提供者と利用者の間で結ばれる、提供するサービスの品質基準（稼働率や応答時間など）に関する明確な約束・合意のこと。基準を下回った場合のペナルティ（利用料金の減額や返金など）も含まれることが一般的です。

🐾 猫で例えると？

アメショと茶トラの2匹が、机に向かって勉強している子供の正面に座り、じっと見つめて監視している様子。約束された品質（勉強時間）が守られているかをモニタリングするSLAの概念を表現 — 約束されたタスクが実行されているか、ド正面から厳格にモニタリング

机に向かう子供のド正面から、アメショと茶トラが2匹並んで鋭い視線を送っています。「毎日決まった時間に勉強する」という約束（サービスレベル）がきちんと果たされているかを、冗長化されたシステムのように相互連携しながら見守る姿は、まさにSLAの遵守状況を厳格にモニタリングしている状態です。

🐾 猫あるある：IT現場の日常

朝7時までにご飯を出す契約：システムの目標稼働率やレスポンスタイムなどを明確に定めた品質保証基準。
1日3回は遊ぶという要求水準：ユーザー側がビジネスを継続するために最低限必要とする、システム要件の閾値。
撫でたら必ずゴロゴロ言う保証：定義された条件を満たした場合に、必ず期待通りの正常応答を返すという可用性の担保。

💻 IT現場における「SLA」とは？

AWSやGCPなどのクラウドサービスを利用する際、インフラエンジニアが必ず確認するのがこのSLAです。「月間稼働率99.9%を保証する」といった形で、サービスがどれだけの時間、正常に動き続けるかを数値化して約束します。

SLAが「99.99%（フォーナイン）」であれば、年間で許容されるシステムの停止時間は約52分しかありません。この厳しい基準をクリアするために、エンジニアはサーバーの冗長化や自動フェイルオーバー、ロードバランシングといった高可用性のためのアーキテクチャを設計・構築する必要があるのです。

⚠️ SLAの仕組みと注意点

SLAはただの「努力目標」ではなく、ビジネス上の「契約」です。もしクラウド事業者が約束した稼働率を下回った場合、利用料金の一部が返金される（サービスクレジット）などのペナルティが発動します。しかし、ここで注意すべきは「補填されるのはあくまでインフラの利用料のみ」という点です。システムダウンによって自社が被ったビジネス上の損害（機会損失や顧客への賠償）までをクラウド事業者が負担してくれるわけではありません。

💡 SLA、SLO、SLIの使い分け

現場では、SLAを守るための内部指標として「SLO」と「SLI」をセットで運用します。

// 現場で使われるSLA/SLO/SLIの概念
SLA (合意) : 「外部顧客に対し、月間稼働率99.9%を約束。違反時は返金」
SLO (目標) : 「社内の開発目標として、月間稼働率99.95%を目指す」
SLI (指標) : 「実際のシステムから取得した、HTTP 200 OKの割合（現在99.98%）」

SRE（サイト信頼性エンジニアリング）の文脈では、外部との厳しい約束（SLA）を破綻させないよう、それよりも少し高めの社内目標（SLO）を設定し、日々の監視メトリクス（SLI）をチェックしてシステムを改善していくのがベストプラクティスです。

🛠️ SLAを賢く使うためのポイント

クラウドや外部APIを導入する際、SLAの観点からシステムを堅牢に保つための注意点です。

責任共有モデルの理解： クラウド事業者がSLAで保証する範囲（物理サーバーやネットワーク層など）と、自分たちが責任を持つ範囲（OSのパッチ当てやアプリケーションのバグ）を明確に切り分ける。
マルチリージョン構成の検討： 単一のデータセンターが災害等でダウンしてもシステム全体のSLAを維持できるよう、物理的に離れた場所にサーバーを分散配置する。
監視とアラートの自動化： SLIがSLOを下回りそうになった（エラーバジェットが枯渇しそうになった）時点で、運用チームに即座に通知が飛ぶ仕組みを構築する。

アメショと茶トラによる厳しい「監視体制」のもとで勉強する子供のように、システムも常にモニタリングされ、約束された品質（SLA）を守り続けることが求められます。もし「おやつの配給が遅れる」というSLA違反が起きれば、茶トラは寂しがって泣き、普段は寛容なアメショもクリティカルエラーを起こして無茶苦茶怖い顔で迫ってくるかもしれません。日々の運用保守と適切なリソース配分で、平和な稼働状況を維持しましょう。