Engineering as a Service すべてのエンジニア不足を解消する VALUE Engineering as a Service (EaaS) Application Development IaaS DevOps / SRE UIUX / Management HR(Engineer Hiring) Data Engineering Security
そもそも、全世界シェア75%以上の検索エンジンを運用するわけでも、国内月間アクティブユーザー4000万人超えの動画配信 サービスを運用するわけでも、20億人以上が利用しているWorkspaceツールのSaasを運用するわけでもない。 • そもそも、大抵の組織は Google 規模のエンジニア組織なんて作れっこない事を理解しないといけない。というかその必要が無 いのでは? • そもそも、SRE というのが Google 様が何年もの運用の結果見出したメソッドだということを忘れていないかい? We are not Googler !!! ~ 私たちは Googler ではありません ~ 自分の身体に合うサイズの服選びが重要なのでは? ※ 例えると、中学校入学前の制服を選ぶママの感覚が大事...?
the tool SRE uses to balance service reliability with the pace of innovation. Changes are a major source of instability, representing roughly 70% of our outages, and development work for features competes with development work for stability. The error budget forms a control mechanism for diverting attention to stability as needed. An error budget is 1 minus the SLO of the service. A 99.9% SLO service has a 0.1% error budget. If our service receives 1,000,000 requests in four weeks, a 99.9% availability SLO gives us a budget of 1,000 errors over that period. 参照: https://sre.google/workbook/error-budget-policy エラー予算とは、サービスの信頼性と技術革新のスピードのバランスをとるためにSREが使用するツールです。 変更は不安定さの主な原因であり、障害の約70%を占めています。機能のための開発作業は、安定性のための開発作業と 競合しています。エラーバジェットは、必要に応じて安定性に注意を向けるための制御メカニズムを形成しています。 エラーバジェットは、1 からサービスの SLO を引いたものです。 99.9%SLOのサービスでは、エラーバジェットは0.1%です。私たちのサービスが4週間で1,000,000のリクエストを受け取る場合、 99.9%の可用性SLOは、その期間に1,000のエラーのバジェットを提供することになります。 「エラー予算」を設けて信頼性を制御する
&提供 一気に SRE における全ての実践をすることは不可能。プロダクトの性質やフェーズに応じてやるべきこと は動的に変化していくはず。 課題・プロダクト検証 マーケット検証 グロース PSF Problem/Solution Fit PMF Product Market Fit GTM Go To Market CPF Customer Problem Fit IV Idea Verification 顧客課題検証 New Products