我並不相信DevOps是一件可恥的事情，我們的社群認為，把DevOps作為工具的形容詞更為正確。挫折是很合理的：DevOps明確地挖掘了開發者和運營者想法，因為開發者和運營者對於自動化的未來能夠有一個更加清晰地認識。比如：可以檢視Cindy Sridharan關於DevOps的傑出演講。

作為一個行業，我們渴望人為的衝突，這樣就能自然地嘗試和提取站點可靠性工程（SRE），DevOps和原生雲(Cloud Native)，並將他們放入對比方。這三個點都共同關注於精益流程。

很簡單的：SRE是一個工作函式，DevOps是一個過程方法，Cloud Native是一個架構。

這三個概念有很大的相似之處，因為他們最基本的目標是相同的：在改善的過程中提高產品交付率。我們正在考慮使用精實生產中的系統思維概念。

SRE通過消除人工操作來提高生產率，降低錯誤，提高基礎建設的質量。這個是從產品基礎建設和反向工作開始。高度自動化的交付，繼承的logs，系統範圍內的監控以及毫無怨言的根本原因分析，都是關鍵的工作。在我們陷入工具中時，SRE團隊間的區別因素在於，他們掌握了生產服務設施。

為了交付分配所有權是存在巨大的影響的。這就是我為什麼在定義SRE為工作函式時引入了工業利益。一個DevOps的策略是一個系統方法，並且成為一個反面模式，讓一個人或者一個團隊負責來擁有“the DeveOps”。

在DevOps中，我們尋找方法來將整個產品建立流的過程精化。SRE需求通常驅動了工具和技術的使用。然而，我們的目標不是針對特定部分的。我們想要和所有的利益相關者協作：包括開發者，產品管理者，測試者，SRE，主管們和顧客。系統對開發者的關注變為CI/CD管道，平臺，工作跟蹤工具和其他工作流元素。這些工作不是專門指定給DevOps的工具，但是由於這些元素通常被帶入DevOps的相關考量中，這就帶來了一定的困惑。

SRE應該期望與DevOps的過程中的其他功能深度協作。

在DevOps的託管下，原生雲（Cloud Native）架構也同樣落寞了，因為它努力將大的任務分解為高度自動化的服務集。在原生雲（Cloud Native）設計中，沒有神器的“DevOps 平臺”，然而，使用架構方法的團隊會變得模組化，強有力的API支撐，服務導向，簡化的配置，和DevOps考量完美適用的自動訓練。

例如，使用容器並不意味著一個開發者或者SRE團隊正在追隨DevOps過程或者使用原生雲（Cloud Native）架構；然而，這個現象反映出，他們正努力做到更小級別的交付、更加完善的開發產品。

然而，SRE，原生雲（Cloud Native）和DevOps都有一個共同的難點：

我們正在做一些創造性的工作，能夠促進開發者的最佳實踐和抽象，一些在雲和實體中創造性的基礎建設。這就意味著，我們要注意到開發者生成和基礎假設複雜性中的雙重膨脹。不行的是，對於能夠提供最佳增量改進的自動化，這樣的財富還不能達到。更糟糕的是，增加的工作負載和複雜度增加了SRE方法的壓力。

最終，這三個概念都是精益商務實踐的方面。然而，DevOps和原生雲（Cloud Native）對過程的促進是超過SRE的。這樣的不平衡為每個相關的人都創造了風險，因為精益是關於系統性能的。延遲和失敗都不能被歸為為某一個的原因。

把Dev和Ops看做想獨立的部分是錯誤的，這意味著在SRE，DevOps和原生雲（Cloud Native）之間建立了錯誤的論點。

如果你在你的專案中聽到過這些內容，那就把這些作為一個熱身，看看你的團隊如何將精益思想融合到你個人的過程中。

原文：https://devops.com/sre-devops-cloud-native-server-cage-match
中文出處：DevOps社群（微信公眾號），作者：ROB HIRSCHFELD，翻譯：張欣（NJU）