Q1：可以理解错误预算是计划内维护的一种吗？
A1: Googel对自己的考核有计划内和计划外，计划内就是如果有99.5%的Error Budget，一年内允许停机2628 minutes，实际备份只用了1400 minutes，还有1228 minutes可用的停机，在12个月内停机使用了这1228 minutes，是属于计划内停机，是使用错误预算的。另外对于工程师考核的计划外停机，计划外是不计算在2628 minutes内，计划外停机是通过SLO方式做整个调整和改进。
计划内可能还包括一些计划内维护外的工作，在计划内维护外又不超过Error Budget。比如计划内维护比较顺利，用的down time比计划的少，可能就可以用这些时间投入到错误预算里。
Q2：您个人对于拥抱风险的原则，是否完全接受？
A2: 寻求变与不变之间其实是有一个总成本权衡的，想清楚最大化总成本的就可以在运维侧接收一定的风险。
最难的实还是量化风险和相关的业务价值，目前给出的指标还很有限。
Q3：分布式系统的可靠性是怎么样的？
实际上分布式系统就是认为硬件的故障是迟早发生的，那么就做好故障发生后的预案。
分布式系统的问题不会像商业服务器那么安全，所以要拥抱故障拥抱变化。里面有相关的章节引入了Chaos Monkey测试，就是去破坏服务器验证服务器的健壮性。
商业的服务器，其实也很难达到100%可靠吧，可能就是多几个9，不存在100%的可靠性。
Google是因为有了SRE工程师来实施分布式、用容器化技术、分布式锁等很多技术突破才确保了几个9。在传统应用小型机、服务器的企业，他们的可靠性是通过大的厂商去解决的。在金融行业，会为了查账或者是合规做很多的业务系统，这些业务系统投入很大，实际上一年内查账挽回的损失有可能很小，对于这种投入来说，我们要尽量的量化几个9，计算成本收益来判断评估是否要做这些业务系统。
Q4：Google有没有把风险进行数字化等级评估，评估的机制是什么？
目前看到的是用量化的方式做评估，从调研对象、可用性目标、故障类型、成本做定性定量分析，测算投资回报率。
Q5：Google对基础资源的可用性，如何度量? 如网络，集群等;
SRE这本书中介绍的是通过基于时间的可用性指标以及用服务请求数来计算的可用性指标。
通过阅读《SRE：Google运维解密》，大家可以学习到Google工程师在提高系统部署规模、改进可靠性和资源利用效率方面的指导思想与具体实践——这些都是可以立即直接应用的宝贵经验。
大型软件系统生命周期的绝大部分都处于“使用”阶段，而非“设计”或“实现”阶段。那么为什么我们却总是认为软件工程应该首要关注设计和实现呢？在《SRE：Google运维解密》中，Google SRE的关键成员解释了他们是如何对软件进行生命周期的整体性关注的，以及为什么这样做能够帮助Google成功地构建、部署、监控和运维世界上现存的软件系统。通过阅读《SRE：Google运维解密》，读者可以学习到Google工程师在提高系统部署规模、改进可靠性和资源利用效率方面的指导思想与具体实践——这些都是可以立即直接应用的宝贵经验。
任何一个想要创建、扩展大规模集成系统的人都应该阅读《SRE：Google运维解密》。《SRE：Google运维解密》针对如何构建一个可长期维护的系统提供了非常宝贵的实践经验。
