问题描述
有些IT高管和业务领导者认为，业务需要100%的可靠性。然而，这与DevOps和SRE的基本原则相悖，因为故障是正常的，将完美可靠性作为目标是错误的。有什么好的方法可以说服他们改变这种想法吗？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
以下是一些我过去在解决这个问题时见过或采取的方法。《Site Reliability Workbook》提供了一些建议，包括：
– 100%不是一个合理的目标，因为任何系统的每个组件都有可能发生故障。
– 客户和目标系统之间的外部组件（如ISP）并不是100%可靠的。
– 100%的可靠性意味着你永远不能改变系统，因为所有的改变都会引入风险。
– 100%的可靠性意味着你将花费所有的时间来应对可靠性问题，没有时间做其他事情。
除了上述方法，我还从各种面对面的讨论中收集了以下一些观点，这些观点可能有助于说服组织领导者：
– 如果IT高管设定了100%可靠性的目标，他们实际上是在鼓励工程师对他们撒谎和隐藏问题，这意味着他们将以最昂贵的方式发现这些问题。
– 自然界从未演化出100%可靠的系统。基因复制是不可靠的，人类的心脏也不是100%可靠的。生命在面对不完美的可靠性时继续存在和繁荣，技术系统和它们的用户也可以如此。
– 没有任何一组人类在长期内工程化出100%可靠的系统。
我们还必须承认，在某些可靠性维度上，如数据丢失预防，一些受监管的行业要求的可靠性水平非常高，长时间内几乎无法与100%区分，如99.999999%。对于可用性和延迟等其他维度来说，三个或四个9的可靠性通常已经足够了，上述的一些论点可能有助于说服IT领导层这是正确的。
方案2
如果你的公司/经理等坚持要求100%的可靠性，请要求他们列举一个在任何非微不足道的时间段内实现了这一目标的人工系统。我不知道有任何一个这样的系统 – 我已经做了很多研究。甚至起搏器也没有100%的可靠性。
去掉人类。你会很难找到自然界中实现了这一目标的任何事物。
完美的目标是非常低效的，最终会使你的创新趋近于0。
如果你更注重错误的减少，而不是集中于快速检测和减轻错误，你将为客户提供更高的可靠性。爆炸半径越小，你就可以越快地前进。
罪不在于失败，而在于未能注意到失败。
方案3
为什么你认为100%的可靠性不是一个好主意？你能用数字、事实和逻辑解释来支持你的观点吗？
硬件成本太高吗？开发时间太长吗？也许你可以证明一个由组件链的成功概率组成的系统，其中一些组件不在你的控制之下？
如果你能支持你的观点，那么请向你的经理提出这些观点；如果不能，那么你的经理可能是正确的。
评论：1. 我想知道是否有一个软件或硬件系统是100%可靠的。用什么指标来衡量可靠性，测量的时间跨度是多长？