这篇开始进入第六章，第一小节是可靠性工程。这是DevOps中的第三个主要练习区域。在工程中，可靠性描述了系统或组件在规定条件下在指定时间段内运行的能力。 在IT中，这包括可用性，性能，安全性以及允许您的服务实际向用户提供其功能的所有其他因素。
在任何一种管理良好的现代化基础设施中，基础设施造成的停电和生产问题越来越少见。一旦您通过最基本的系统自动化，可以毫不夸张地说，90％的生产问题都是软件问题。是的，这是完全正确的。但在传统IT中，当提到可靠性，性能或安全性时，它们有时可被称为非功能性需求。您知道，许多产品经理甚至不认为他们是他们责任的一部分。
是的，这会导致问题的手动处理效率低下，因为开发人员资源被分配来修复它们，以及团队之间的冲突，由于它们的优先级不同，并且最终导致由于流程战争导致的速度减慢。是的，你知道平均恢复时间，或MTTR，这是衡量你的服务从中断和恢复服务中恢复的速度。在高性能商店，平均不到1小时。 难题的另一部分是您有多少次失败，平均故障间隔时间或MTBF，您服务的总中断是MTBF和MTTR的函数。
Patrick Debois确定了DevOps的四个关键领域，将交付扩展到生产，将反馈从运维扩展到开发，将开发嵌入到运维中，以及将运维嵌入到开发中。我们将使用它来说明可靠性工程的整体方法，但我们将通过将嵌入和反馈部分组合到我们称之为设计操作和操作设计的两个区域来简化它。在设计操作中，我们将研究如何构建您的系统，使其最初是最可靠和可维护的，从项目进入操作。
然后在设计操作中，我们将讨论操作中的实践，以及如何根据三种方式的反馈循环思想将所有信息从生产传回项目。当您将这两种实践结合在一起时，您就可以使用DevOps进行可靠性工程。您可能听说过网站可靠性工程这一术语。这是谷歌为这种方法推广的术语。 Google的产品团队支持自己的服务，直到达到一定的流量和成熟度。即便如此，他们仍然让开发团队处理5％的运维工作量。
这保持了健康的反馈循环，不断提高产品的运营能力。甚至还有一本名为Site Reliability Engineering的O'Reilly新书由一些Google工程师提供，这些书有很多很好的见解，特别是对于这个主题的大型网上商店。现在让我们深入探讨可靠性工程，详细介绍我们如何在下一部分设计可靠的系统，设计操作。然后，我们将讨论如何以一种方式运行系统，将生产结果反馈给开发团队进行设计操作，并通过探索现代SRE可能使用的工具进行总结。
