這篇開始進入第六章，第一小節是可靠性工程。這是DevOps中的第三個主要練習區域。在工程中，可靠性描述了系統或元件在規定條件下在指定時間段內執行的能力。 在IT中，這包括可用性，效能，安全性以及允許您的服務實際向用戶提供其功能的所有其他因素。

        在任何一種管理良好的現代化基礎設施中，基礎設施造成的停電和生產問題越來越少見。一旦您通過最基本的系統自動化，可以毫不誇張地說，90％的生產問題都是軟體問題。是的，這是完全正確的。但在傳統IT中，當提到可靠性，效能或安全性時，它們有時可被稱為非功能性需求。您知道，許多產品經理甚至不認為他們是他們責任的一部分。

        是的，這會導致問題的手動處理效率低下，因為開發人員資源被分配來修復它們，以及團隊之間的衝突，由於它們的優先順序不同，並且最終導致由於流程戰爭導致的速度減慢。是的，你知道平均恢復時間，或MTTR，這是衡量你的服務從中斷和恢復服務中恢復的速度。在高效能商店，平均不到1小時。 難題的另一部分是您有多少次失敗，平均故障間隔時間或MTBF，您服務的總中斷是MTBF和MTTR的函式。

       Patrick Debois確定了DevOps的四個關鍵領域，將交付擴充套件到生產，將反饋從運維擴充套件到開發，將開發嵌入到運維中，以及將運維嵌入到開發中。我們將使用它來說明可靠性工程的整體方法，但我們將通過將嵌入和反饋部分組合到我們稱之為設計操作和操作設計的兩個區域來簡化它。在設計操作中，我們將研究如何構建您的系統，使其最初是最可靠和可維護的，從專案進入操作。

       然後在設計操作中，我們將討論操作中的實踐，以及如何根據三種方式的反饋迴圈思想將所有資訊從生產傳回專案。當您將這兩種實踐結合在一起時，您就可以使用DevOps進行可靠性工程。您可能聽說過網站可靠性工程這一術語。這是谷歌為這種方法推廣的術語。 Google的產品團隊支援自己的服務，直到達到一定的流量和成熟度。即便如此，他們仍然讓開發團隊處理5％的運維工作量。

       這保持了健康的反饋迴圈，不斷提高產品的運營能力。甚至還有一本名為Site Reliability Engineering的O'Reilly新書由一些Google工程師提供，這些書有很多很好的見解，特別是對於這個主題的大型網上商店。現在讓我們深入探討可靠性工程，詳細介紹我們如何在下一部分設計可靠的系統，設計操作。然後，我們將討論如何以一種方式執行系統，將生產結果反饋給開發團隊進行設計操作，並通過探索現代SRE可能使用的工具進行總結。