SRE は現代のエンタープライズ アーキテクチャに焦点を当てます
「オン」であることはパフォーマンスの尺度ではありません。 ランプに電力が供給されているからといって、ユーザーが何をしているのかを確実に確認できるだけの十分な光が与えられるわけではありません。 パワー以外にも、さまざまな要因がユーザーの視力に影響します。 電球が暗いのは、電球が切れかけているか、電力は供給されているが十分でないことが原因である可能性があります。 電球が十分な明るさを保てない場合は、配線に問題があるか、調光器によって電気の流れが制限されている可能性があります。 また、電球が明るすぎる場合は、ランプシェードが暗すぎるか、またはスペースが 1 つの電球では大きすぎる可能性があります。 つまり、ランプのパフォーマンス、ひいてはユーザーエクスペリエンスに影響を与える要因は数多くあります。 同様に、システムやアプリケーションのパフォーマンスと信頼性を評価するには、従来の稼働時間の測定以外にもさまざまな方法があります。 信頼性はサービスのレベルにも依存します。
システムとアプリケーションは、インフラストラクチャ、API、セキュリティ、ワークフロー、ロジック、データなど、目的のためにまとめられた多くのコンポーネントで構成されており、単に稼働しているだけでは信頼性が保証されるわけではありません。 ランプの例えと同様に、最適なパフォーマンスとエクスペリエンスを確認するには、すべてのコンポーネントを評価して判断できる必要があります。 実店舗ビジネスでは、サービス レベルの欠陥を判断することは、「顧客経路」を歩いて全体的なエクスペリエンスを評価するのと同じくらい簡単ですが、デジタル ビジネスでは、これは大きな課題となる可能性があります。 従来のエンタープライズ アーキテクチャによって作成されたビジネスと IT のサイロでは、問題を特定してその根本原因を見つけることが必ずしも容易または効率的であるとは限りません。 ビジネス リーダーは問題があると考えるかもしれませんが、すべてが「オン」であれば、コンポーネントを管理する IT チームは問題に気付かない可能性があります。 サイト信頼性エンジニアリング (SRE) は、サービス レベル目標 (SLO) によってビジネス コミットメントの実行を保証する、ビジネスと IT の間の架け橋です。
SRE とは何ですか?
サイト信頼性エンジニアリングは 2000 年代初頭に Google で始まり、同社によれば「運用をソフトウェアの問題であるかのように扱ったときに得られるもの」だそうです。 私たちの言葉で言えば、それはビジネス目標をサポートする信頼性が高く、効率的で、スケーラブルなシステムを作成するために採用される一連のプロセス、プラクティス、ツール、および文化と考え方です。
SRE は、可用性だけでなく信頼性とスケーラビリティに重点を置きます。 私たちは、これは考え方と文化であると付け加えます。なぜなら、セキュリティと同様に、役割に関係なく、全員が高品質で信頼性の高いシステムに積極的に貢献することが期待されるからです。 SRE の実践は、文化や考え方でもありますが、多くの場合、サービス全体をエンドツーエンドで提供するサービス チームに組み込まれます。 これらのチームは通常、自動化と効率化による継続的な改善を推進しながら、可用性、レイテンシ、パフォーマンス、および回復を監視することでコア システムを改善し、イノベーションを実現する責任を負います。 本質的には、ランプが点灯しているかどうかを確認するだけでなく、部屋全体を見ているのです。
SRE が SLO を満たすために SLI を使用する方法
サイト信頼性エンジニアリングは、ビジネス成果を満たすための SLO と SLI (サービス レベル インジケーター) の測定基準を定義します。 もっと簡単に言えば、SRE は開発、セキュリティ、運用の各チームのニーズと目標を統合し、ビジネスが顧客に対して行った約束を確実に実現します。
ビジネス上のコミットメントが、ユーザーが自分の作業を確認するのに十分な明るさを確保すること (サービス レベル) である場合、SLO は 10 平方フィートのスペースごとに 1 つの明るいランプ (可用性) が維持されることになる可能性があります。 一方、別の SLO としては、定義された MTTR (平均回復時間) が考えられます。この例では、切れた電球や寿命が近づいた電球を交換するのにかかる時間です。 SLI は、光束、各ランプへの電気の流れ、ユーザーがランプをぶつけたり動かしたりすることで生じるランプの位置のわずかな変化などを監視するなど、SLO が達成されるようにサイト信頼性エンジニアと IT によって定義されるしきい値です。 アプリケーション配信システムでは、CPU 使用率、API 呼び出し、データベース クエリ時間などがこれに該当します。 ビジネス SLO に影響を与える SLI 対策と、運用ポリシーと構成を調整して特定のしきい値を下回った場合にどのような対応を取るかを定義するのは、サイト信頼性エンジニアの責任です。
現代のエンタープライズ アーキテクチャにおける SRE の利点
対策、しきい値、および対応は、デジタル ビジネスのアプリケーション配信用に設計された最新のエンタープライズ アーキテクチャの他のドメインと SRE の交差点です。 運用データ (テレメトリ) は、SRE によって設定された定義済みの測定基準としきい値の観測可能性にフィードされます。 自動化とは、ツール、テクノロジー、プラクティスを組み合わせて適用することで、サイト信頼性エンジニアが、より少ない労力で定義された応答を拡張できるようにし、デジタル サービスの SLO を効率的に満たすことを可能にします。 また、デジタル サービスのシステム信頼性により、デジタル ビジネスにおけるユーザー エクスペリエンスが向上する可能性が高まります。
繰り返しになりますが、SRE は、利用可能なすべてのツール、テクノロジー、プロセスを使用して、システムを単に「オン」にするだけでなく、システムが確実に動作していることを保証することで、IT とビジネスの取り組みを統合する架け橋として機能します。 SRE をエンタープライズ アーキテクチャに導入することで、企業はシステム アプリケーションを積極的に管理し、パフォーマンスの低下や異常を早期に検知できるようになります。これにより、サイト信頼性エンジニアは、ユーザー エクスペリエンスに影響が出る前に調査して解決できるようになります。
SRE をビジネスに統合し、効率的でスケーラブルなデジタル ビジネスへの変革をサポートする方法については、O'Reilly の書籍『 Enterprise Architecture for Digital Business』の Julia Renouard 著の章「The Need for Speed」をお読みください。