我并不相信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）
本文链接：https://www.yunweipai.com/20932.html
网友评论comments