共计 2179 个字符，预计需要花费 6 分钟才能阅读完成。
《SRE Google 运维解密》第 3 章讲了拥抱危险，一些要害的观点，在这里与大家分享，融入了我本人的一些了解，心愿对你有些帮忙。
服务可用性必须 100%？其实齐全没必要
一个服务客户的产品，不须要谋求极其的可用性，因为切实是没有必要。比方一个论坛服务，用户应用智能手机来拜访，手机自身有可能故障，手机的蜂窝网络可能出问题，如果用的 wifi 本地路由器可能出问题，小区宽带可能出问题，运营商的骨干网可能出问题，这些都不是论坛服务可能管制的。简略来说，用户在一个有着 99% 可靠性的智能手机上，是不能分辨出 99.99% 和 99.999% 的服务可靠性的区别的。
高可靠性带来高老本
99.99% 的可用性，每年不可用时长不能超过 53 分钟，如果是 99.999% 的可用性，每年不可用时长不能超过 5.3 分钟。多了一个 9，不可用时长只是缩减了 47.7 分钟，然而付出的老本可能是微小的，须要掂量 ROI 是否值得。老本通常来自两个方面：
- 冗余物理服务器 / 计算资源的老本
- 机会成本
机会成本是说，咱们把过多的人力投入到稳定性建设上了，导致投入到业务性能开发的人力就变少了，这个机会成本是很难估计的，然而很重要。
如何度量可用性
通常的做法是依照计划外停机工夫来度量，比方：
可用性 = 零碎失常运行工夫 / (零碎失常运行工夫 + 零碎计划外停机工夫)这个计划外停机工夫，通常是指零碎不可用的工夫，比方零碎解体了，或者零碎的某个性能不可用了，或者零碎的某个性能的性能降落了，都能够算作计划外停机工夫。与计划外停机工夫绝对的，显然是打算内停机工夫，偶然告诉用户，说凌晨 3 点我会做系统升级，打算停机 3 分钟，这个 3 分钟就是打算内停机工夫，这 3 分钟内的不可用，不影响 SLA。
然而，很多零碎都是分布式的，尤其是 Google，一个服务，通常不会齐全不可用，可能某个 region 不可用，然而其余 region 还可用，所以，大型互联网公司的服务通常是不会 100% 不可用的，可能会局部不可用，此时这个计划外停机工夫就不好计算了。怎么办？应用申请数量来统计，可用性计算公式变成：
可用性 = 胜利申请数 / 总的申请数 这是服务可用性的度量办法，一个大型互联网公司可能有几千个微服务，老板问技术团队，咱们往年的可用性如何？显然没法应用服务层面的数据，那就把泛滥微服务做个加权均匀？也不那么说得通！那公司整体业务的 SLO 应该怎么算？个别是看业务指标，分享一下滴滴的做法，滴滴最外围的业务就是打车，外围就看打车的订单量，如果订单量上涨 10%，就开始计算不可用时长，这是整个公司最重要的可用性指标。这种指标称为北极星指标，咱们当初守业就专门做了一个北极星指标的产品，对北极星指标做 VIP 级别的保障。详情能够理解这里。
谁来制订 SLO？
在 Google，对于服务于终端用户的产品，通常有个产品技术团队，是这个服务的「商业所有者」，这个团队明确晓得本人的商业指标，能够拍板 SLO。因为：SLO 最终是服务于商业指标的！
通常来讲，线上 70% 的故障是变更导致的，更好的 SLO 意味着线上变更的频率会升高，然而低频的变更，就意味着有些性能 feature 不能尽快公布给终端用户，终端用户的体验就会变差，竞争对手可能有更花哨好用的性能，咱们无奈及时跟进。那好，那就更快的变更，更快的变更通常意味着稳定性变差，所以就须要衡量了，这实质上是一个商业取舍，所以，须要商业所有者来拍板。而这个商业所有者，对于服务于终端用户的产品，通常就是产品团队，最终可能是这个业务的负责人最终拍板。
服务于外部的基础设施，比方 BigTable 这样的服务，没有终端用户，那谁来拍板？基础设施类服务，通常是服务于外部其余服务的，此时应该是 BigTable 的研发团队和上游服务所有者一起拍板，制订 SLO。
BigTable 可能同时服务两类上游服务，举例：一类上游服务是面向终端用户的，他们须要更低的提早，另一类上游服务可能是离线工作，在 BigTable 里存储离线剖析数据，他们须要更大的吞吐。低提早的上游服务心愿 BigTable 的申请队列（简直总是）为空，这样零碎能够立即解决每个呈现的申请。而离线剖析的上游服务，须要更高的吞吐，心愿 BigTable 忙碌，心愿申请队列永远不为空。如果拿申请队列长度作为 SLO，就难堪了 …
所以，对于差异化要求比拟大的基础设施，通常会拆分成不同的集群，提供不同维度的 SLO。
晋升 SLO 的时候要留神 ROI
举个例子，假如某个服务每一个申请的价值是一样的：
- 可用性指标心愿从 99.9% 晋升至 99.99%
- 减少的可用性：0.09%
- 服务收入：100 万美金
- 改良可用性后的价值：100 万 * 0.09% = 900 美金
可用性晋升一个 9，收益是 900 美金，如果晋升一个 9 的老本低于 900 美金，就是划算的，如果高于 900 美金，就是不划算的。
SLO 和谬误估算构建过程
- 产品管理层定义一个 SLO，确定一项服务在每个季度预计的失常运行工夫
- 理论在线工夫是通过一个中立的第三方来测算的：咱们的监控零碎
- 这两个数字之间的差值就是这个季度中残余的不可靠性估算
- 只有测算出的失常在线工夫高于 SLO，也就是说，只有依然有残余的谬误估算，就能够公布新的版本
扩大浏览
- 快猫星云可观测性产品，专一故障定位止损、稳定性治理
- 夜莺专业版，提供加强监控的能力，提供可观测性专家教训
- 告警事件对立 OnCall 核心，解决告警降噪、排班、认领、降级、协同的需要