サイト リライアビリティ エンジニアリング（SRE）でモダン エンタープライズ アーキテクチャに照準を定める

「稼働していること」は、パフォーマンスの尺度ではありません。照明に電力が供給されていても、手元が確実に見えるくらい明るいとは限らないからです。手元が見えるかどうかには、電力以外にもさまざまな要因が影響します。電球が暗いのは、電球が切れかかっているか、電力は供給されていても十分でないかのどちらかでしょう。電力が不十分で暗い場合は、配線に問題があるか、調光器で電気の流れが制限されている可能性があります。また、電球が明るく点灯している場合は、ランプシェードが汚れているか、空間が広すぎて１つの照明では足りないのかもしれません。つまり、照明のパフォーマンス、ひいてはユーザーの使い勝手に影響を与える要因はたくさんあります。同様に、システムやアプリケーションのパフォーマンスと信頼性を評価するには、従来のアップタイムという尺度だけでは不十分です。そして信頼性は、サービス レベルにも依存します。

システムやアプリケーションは、インフラストラクチャ、API、セキュリティ、ワークフロー、ロジック、データなど、1つの目的のために多くのコンポーネントが組み合わされて構成されており、稼働しているだけでは、信頼性を確保できません。照明の例えのように、最適なパフォーマンスとエクスペリエンスを確認するには、すべてのコンポーネントを評価できなければなりません。実店舗のビジネスでは、「お客様の動線」を歩いて全体の使い勝手を評価するといった簡単な方法でサービス レベルの不十分な点を特定できますが、デジタル ビジネスでは、この評価が大きな課題になり得ます。従来のエンタープライズ アーキテクチャによってビジネス部門とIT部門でサイロが生じているため、問題を特定してその根本原因を突き止めることは必ずしも容易ではなく、効率的でもありません。ビジネス リーダーは問題があると考えていても、コンポーネントを管理するITチームは、すべてが「稼働」していれば問題ないと見なすかもしれません。SREは、サービス レベル目標（SLO）に従ってビジネス上の義務を確実に履行するためのビジネス部門とIT部門の橋渡し役となります。

サイト リライアビリティ エンジニアリング（SRE）は、2000年代初頭にGoogleが提唱したもので、「ソフトウェアの問題と同じように運用の問題を扱うことで得られるもの」と説明されています。当社では、信頼性が高く、効率的で拡張性のあるシステムを構築し、ビジネス目標をサポートするための、一連のプロセス、慣行、ツール、さらには文化や考え方を指します。

SREは、可用性だけでなく、信頼性と拡張性の高いシステムに重点を置いています。また、セキュリティと同様に、誰もがその役割にかかわらず、高品質で信頼性の高いシステムに積極的に貢献することが求められるため、私たちはSREが考え方であり文化でもあると付け加えています。文化や考え方でもあると同時に、SREの慣行は、多くの場合、エンドツーエンドでサービス全体を提供するサービス チームに組み込まれます。通常、これらのチームには、可用性、遅延、パフォーマンス、リカバリを監視してコア システムの改善とイノベーションを進めながら、自動化と効率化により継続的な改善を推進する責任があります。要するに彼らは、照明が点いているかどうかを確認するだけでなく、部屋全体を見ているのです。

SREは、ビジネス成果を達成するためのSLOとSLI（サービス レベル指標）の評価基準を定義します。簡単に言えば、SREによって、ビジネスがお客様に約束したものを確実に実現するための、開発、セキュリティ、運用の各チームのニーズと目標が統合されます。

ビジネス上の義務が、手元が確実に見える十分な明るさを確保すること（サービス レベル）である場合、10平方フィートの空間ごとに明るく点灯する照明1個（可用性）を維持することがSLOとなるかもしれません。また、別のSLOとして、MTTR（平均修復時間）を定義することもできます。この例では、切れた、または切れかかっている電球の交換にかかる時間です。次にSLIは、たとえば、光束、各照明への電気の流れ、ユーザーが照明にぶつかったりその周りで動いたりすることで生じる照明の位置のわずかな変化などを監視することで、SLOを確実に実施するためにSREとIT部門が定義する閾値です。アプリケーション デリバリ システムでは、これらは、CPU使用率、API呼び出し時間、データベース クエリ時間などに相当するでしょう。ビジネスのSLOに影響を与えるSLIの評価基準と、特定の閾値を下回った場合の対応は、サイト リライアビリティ エンジニアが運用方針や構成を調整して定義します。