サイトリライアビリティエンジニアリング」の、今日は3章を見ていきます。この章は冒頭でこのように書かれており、非常に重要な章であることがわかります。「SREの仕事とはどういうものか」、そして「なぜそのような仕事をするのか」についての幅広い見地を得たい方にとっては、最重要となる必読の章です。この章では、大きく4つのことが書かれています。一つ一つ、いつものように雑にまとめてみましょう。信頼性のないシステムは急速にユーザーの信頼を失うことになるので、可能性を減らすためのコストは支払う必要があります。このコストには2つの特徴があります。コンピュートリソースのコスト設備の冗長化にかけるコスト。機会のコストリスクを減らすためのシステムや機能を構築するために組織がエンジニアリングリソースを割り当てることから生じるコストSREでは、サービスの信頼性を管理する大部分は、リスクを管理することによって行います。下記2つは、等しく重要なポイントです。システムの信頼性を高めるためにエンジニアリングを見いだすこと動作させるサービスの適切な障害許容レベルを定めることサービスを十分信頼できるものにするための努力はしつつも、必要以上に信頼性を高めようとはしない、というのも重要なポイントです。サービスリスクの計測Googleが注目している客観的なリスク検知のメトリクスは、計画外の停止時間です。この計画外の停止時間は、サービスの可溶性に求められるレベルによって把握できます。Googleのように24/7で世界中のどこかからサービスのトラフィックを少なくとも一部を提供している可能性が高いとなると、時間を基にしたメトリクスは意味を持たないので、リクエストの成功率の観点から可用性を定義しています。このサービス可用性のターゲットを四半期単位で設定し、そのターゲットに対して週単位、もしくは日単位でパフォーマンスを追跡しています。サービスリスクの許容度サービスリスクの許容度を特定するためには、SREがプロダクトのマネージャーと共同で作業を行い、一連のビジネスゴールをエンジニアリング可能で明確な目標に変換する必要があります。この共同作業は、現実には簡単ではなく、本の中ではコンシューマサービスとインフラストラクチャサービスの場合で分けて解説されていますが、共通するリスク許容度の評価に関しては、以下の4点が挙げられています。エラーバジェットの活用プロダクト開発者のパフォーマンスがプロダクトの開発速度で主に評価されているのに対し、SREのパフォーマンスはサービスの信頼性を基にして評価されます。そのため、この両者には本来的な緊張が存在していますが、エラーバジェットはこの緊張を客観的に解消することのできる手法です。エラーバジェットは、Googleでは以下のように形成されます。プロダクトマネージャーがSLOを規定。実際の稼働時間は、中立な第三者であるモニタリングシステムによって計測この2つの値の差異が、その四半期内の「損失可能な信頼性」という「予算」の残分となる計測された稼働時間がSLOを超えている、言い換えればエラーバジェットがまだ残っているなら新しいリリースをプッシュできる非常にわかりやすいですね。これなら社内政治等のわかりづらい手法で両者の対立が激化することなく、プロダクト開発とSREとのバランスを保つことができます。エラーバジェットが枯渇したタイミングで、どうしてもその四半期内に追加のプロダクト開発を行いリリースをプッシュしたいときは、SLOを緩和することによってエラーバジェットを増やす、という選択肢を取ることもできます。まとめサービスの信頼性管理の大部分はリスク管理に関係することであり、リスク管理には多くのコストがかかることがある信頼性のターゲットとして100%が適切であることはほぼありえない。月別アーカイブはてなブログをはじめよう!jumpeim37さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。