Q1：可以理解错误预算是计划内维护的一种吗？
Googel对自己的考核有计划内和计划外，计划内就是如果有99.5%的Error Budget，一年内允许停机2628 minutes，实际备份只用了1400 minutes，还有1228 minutes可用的停机，在12个月内停机使用了这1228 minutes，是属于计划内停机，是使用错误预算的。另外对于SRE工程师考核的计划外停机，计划外是不计算在2628 minutes内，计划外停机是通过SLO方式做整个调整和改进；
计划内可能还包括一些计划内维护外的工作，在计划内维护外又不超过Error Budget。比如计划内维护比较顺利，用的down time比计划的少，可能就可以用这些时间投入到错误预算里；

Q2：您个人对于拥抱风险的原则，是否完全接受？
寻求变与不变之间其实是有一个总成本权衡的，想清楚最大化总成本的就可以在运维侧接收一定的风险。
最难的实还是量化风险和相关的业务价值，目前给出的指标还很有限。

Q3：分布式系统的可靠性？
实际上分布式系统就是认为硬件的故障是迟早发生的，那么就做好故障发生后的预案。分布式系统的问题不会像商业服务器那么安全，所以要拥抱故障拥抱变化。DevOps里面有相关的章节引入了Chaos Monkey测试，就是去破坏服务器验证服务器的健壮性。商业的服务器，其实也很难达到100%可靠吧，可能就是多几个9，不存在100%的可靠性。
Google是因为有了SRE工程师来实施分布式、用容器化技术、分布式锁等很多技术突破才确保了几个9。在传统应用小型机、服务器的企业，他们的可靠性是通过大的厂商去解决的。在金融行业，会为了查账或者是合规做很多的业务系统，这些业务系统投入很大，实际上一年内查账挽回的损失有可能很小，对于这种投入来说，我们要尽量的量化几个9，计算成本收益来判断评估是否要做这些业务系统。

Q4：Google有没有把风险进行数字化等级评估，评估的机制是什么？
目前看到的是用量化的方式做评估，从调研对象、可用性目标、故障类型、成本做定性定量分析，测算投资回报率。

Q5：Google对基础资源的可用性，如何度量。如网络，集群等
SRE这本书中介绍的是通过基于时间的可用性指标以及用服务请求数来计算的可用性指标。