如何管理IT系统可靠性风险
你可能认为Google会试图构建一个百分之百可靠的服务。事实证明，超过一定值后，再提高可靠性对于一项服务（和它的用户）来说，结果可能会更差而不是更好!极端的可靠性会带来成本的大幅提升∶过分追求稳定性限制了新功能的开发速度和将产品交付给用户的速度，并且很大程度地增加了成本，这反过来又减少了一个团队可以提供的新功能的数量。此外，用户通常不会注意到一项服务在高可靠性和极端可靠性之间的差异，因为用户体验主要是受较不可靠的组件主导，例如手机移动网络或者他们正在使用的设备。简单地说，用户在一个有着99%可靠性的智能手机上是不能分辨出99.99%和99.999%的服务可靠性的区别的!基于这一点，SRE旨在寻求快速创新和高效的服务运营业务之间的风险的平衡，而不是简单地将服务在线时间最大化。这样一来，我们可以优化用户的整体幸福感，平衡系统的功能、服务和性能。
不可靠的系统会很快侵蚀用户的信心，所以我们想要减少系统出故障的几率。然而，经验表明，在构建系统的过程中，可靠性进一步提升的成本并不是线性增加的——可靠性的下一个改进可能比之前的改进成本增加100倍。高昂的成本主要存在于以下两个维度。
冗余物理服务器 / 计算资源的成本
通过投入冗余设备，我们可以进行常规的系统离线或其他预料之外的维护性操作。
又或者可以利用一些空间来存储奇偶校验码块，以此来提供一定程度的数据持久性保证。
机会成本
这类成本由某一个组织承担。当该组织分配工程资源来构建减少风险的系统或功能，而非那些用户直接可用的功能时需要承担这些成本。这些工程师不能再从事为终端用户设计新功能和新产品的工作。
在SRE 团队中，我们管理服务的可靠性很大程度上是通过管理风险来进行的。我们是将风险作为一个连续体来认知的。对于提高Google系统的可靠性和对服务故障的耐受水平，我们要给予同等关注。这样我们可以进行成本/收益分析。例如，Search、Ads、Gmail 或者Photos应该置于风险连续体上（非线性）的哪一点?我们的目标是∶明确地将运维风险与业务风险对应起来。我们会努力提高一项服务的可靠性，但不会超过该服务需要的可靠性。也就是说，当设定了一个可用性目标为99.99%时，我们即使要超过这个目标，也不会超过太多，否则会浪费为系统增加新功能、清理技术债务或者降低运营成本的机会。从某种意义上来说，我们把可用性目标同时看作风险的上限和下限。这种表达方式的主要优势在于它可以促使团队进行明确的、深思熟虑的风险讨论。
页:
[1]