首页 运维杂谈服务器运维方式比较 | SRE vs DevOps vs Cloud Native(原生云)

服务器运维方式比较 | SRE vs DevOps vs Cloud Native(原生云)

运维派是国内成立最早的IT运维技术社区,欢迎关注公众号:yunweipai

我并不相信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)

本文链接:http://www.yunweipai.com/20932.html

网友评论comments

发表评论

电子邮件地址不会被公开。 必填项已用*标注

暂无评论

Copyright © 2012-2020 YUNWEIPAI.COM - 运维派
扫二维码
扫二维码
返回顶部