在当今永远在线的数字经济中，DevOps正迅速成为主流，就像云一样。实际上，DevOps的诞生是出于对更快部署的需要，以创建持久的竞争优势，而不管行业如何。简而言之，如果您的企业组织一直在寻求加速应用程序交付，那么很有可能你已经考虑实现DevOps。
近年来，管理IT基础设施的另一种方法开始在企业业务场景中获得更多的关注。站点可靠性工程(Site Reliability Engineering，简称SRE)已经成为DevOps的远亲，DevOps使用一些相同的核心原则，但将它们应用于大型框架，比如谷歌。
DevOps和企业业务
在我们进一步讨论之前，有必要更详细地解释一下DevOps的一些基本概念。
DevOps是一种遵循精益或敏捷原则的编程方法。在DevOps中，团队专注于持续交付可用的数字产品。自动化使持续交付成为企业的现实。
对于正在经历数字转换过程的组织来说，DevOps站在操作和开发之间架起了一座桥梁，这两者之间的差距有时可能非常大:开发团队专注于编程和交付，而操作必须监视和维护平台的稳定性，并确保满足功能需求。
这意味着运维经常给开发带来压力，让开发人员去做一些事情，而不是推出新的软件(例如测试和QA);而开发人员有时会在操作有机会审计发布版本之前偷偷地将其推出。
不用说，这两个部门之间的关系因此可能有争议。这就是DevOps提供了一种自动化的敏捷软件开发方法的原因，它允许开发团队专注于交付新软件，同时维护操作所需的功能和遵从性原则。
创建DevOps文化的基本要素包括:
- 持续交付，发布频率高
- 自动化开发方法
- 开发和运维之间存在共同的责任
使用这种方法，许多企业不仅增强了他们的IT部门，而且增强了他们的整体企业文化。这是因为成功地迁移到DevOps需要企业思维的转变，从而激发整个组织的变革。
现场可靠性工程的历史
在企业环境中，需要多个应用程序在给定的框架上进行自动化和集成，DevOps是一种粘合剂，通过精益的开发方法和敏捷性将各个部分结合在一起。相反，可以将SRE看作允许开发人员创建框架本身的引擎。
SRE的概念产生于谷歌，当时一位名叫Ben Treynor的工程师领导了一个团队来提高谷歌的站点可靠性。很明显，不存在一种体系结构方法来满足这种大型系统的需求。因此，SRE应运而生。
SRE团队将一半的时间用于操作调用和其他软件开发，添加配置和程序特性。
体系结构方法被认为是DevOps的扩展，它有一些必要的和重要的区别。
相同点和不同点:DevOps vs SRE
SRE和DevOps之间一个惊人的区别是，SRE是由上而下的操作驱动的。在这种方法下，开发人员被授权检查和维护他们的软件版本，这是一个通常包含在IT操作中的功能。然而，只有当团队领导对IT操作有敏锐的眼光，并且对频繁的发布充满激情时，这才能实现。
DevOps试图通过协调关键目标和计划的方式来弥合部门之间的差距，而SRE则致力于通过安装具有运维背景和思维方式的团队领导工程师来彻底消除部门之间的沟通难题。
尽管这一核心理念听起来与DevOps非常不同，但事实是，这两种方法对成功的定义是相同的:
- 减少组织silos的数量，
- 营造一种接纳失败、期待失败的文化，
- 逐渐的做出改变，
- 使用自动化和监控
然而，需要注意的是，对于复杂框架的持续开发和改进，SRE是一种更具可伸缩性的方法，而DevOps则是数字产品和代码频繁发布的理想选择。但是它们都存在于相同的DevOps范例中。
SRE将持续改进的重要性提升到持续发展的重要性。使用SRE方法，对现有程序的改进归开发团队所有。它们和新版本一样重要。
希望您开始清楚地看到这两种方法是如何相似的，但同时又非常不同。
改善人际关系和整体文化
DevOps的本质就是支持开发团队和操作之间的“跨通道”方法，以便在重要的目标上保持一致。然而，要想在DevOps生态系统中茁壮成长，团队必须得到以下方面的支持:
- 高度互信的文化。这是一个关键的需求，以确保开发人员和运维人员能够一起完成令人难以置信的事情——作为一个内聚的DevOps工作。实现这一目标的一种方法是指定一位“变革型领导人”，他具有推动这种进步势头的特征。
- 鼓励创新的文化注重于集成精益原则和更短的实现周期。
- 消除组织竖井从而增强战略一致性和减少冲突的结构。
更好的灵活性
使用DevOps方法，企业业务可以从稳定的操作环境、自动化、早期缺陷检测和持续的产品发布中获益。这些都是提供业务灵活性的好处，这是高功能企业组织经常追求的结果。
DevOps vs. SRE:您应该选择哪一个?
正如您所看到的，对于确定哪种方法更好:DevOps还是SRE，没有一个cookie cutter响应。然而，很明显的是，任何希望对其中一种方法进行更改的企业组织都应该为组织内部的组织、文化和生产方面的重大更改做好准备。
在你做任何决定之前，一定要:
- 评估你的基线:了解您的流程目前所处的位置是开发路线图的重要第一步，该路线图允许您对关键的企业需求进行优先级排序。
- 考虑您当前的团队:哪种方法意味着引入新员工、与IT供应商合作开发软件和托管服务、实现支持增长、培训等的新流程?这将如何影响您的IT预算?
- 关注结果:确定您想要的产品输出是快速发布的用于收入增长的数字产品(DevOps)还是更大的侧重于持续改进的框架(SRE)。
本文暂时没有评论，来添加一个吧(●'◡'●)