18018650584

18621556435


​​学院动态

College dynamics

SRE与DevOps的区别有哪些?

SRE是运维人员自下而上自我救赎,自我革命。武器就是自动化精益。避免被开发推动DevOps自上而下裹挟革命。所以我遇见的运维团队对于DevOps是疑惧交织,对于SRE大都欣然接受。


因为DevOps和SRE关注点不一样,甚者都不应该放在一起讨论,SRE仅仅是运维侧的一种方法论和实践,而DevOps不是。


去年和招商银行的领导有过一个有趣的探讨,即现在很流行的DevOps和SRE的定位和异同,讨论的结果倾向于认为:DevOps是开发拥抱运营,是从开发侧出发,解决开发运维一体化的问题;SRE是运维拥抱开发,是运维团队自身的一次深刻转型,我个人倾向于——殊途同归。


所有可以标准化自动化的东西,理论上都可以纳入运维的范畴,这样运维的定位可能会历史性地提升咸鱼翻身或可期,我用的词是花开两朵,殊途同归,鉴于立场不同,实践侧重自然不同。SRE是运维的自我革命。 


sre是devops的最佳实践


SRE是DevOps的最佳实践:

SRE和DevOps同属开发运维一体化时代的产物,有交集很正常,他们是“殊途同归”。 SRE可以是运维向运维研发的拓展,这可以适用于国内广泛的运维部门转型,事实上DevOps或者说“开发运维一体化”在国内刚刚开始落地,很多组织上仅仅通过引入DevOps理念,仍然需要面对“生产环境天天出问题,就是不知道问题出在哪”等问题。


SRE可以理解成Devops的具体实践。相比devops有更具体的工作或者角色定义。

1、SRE主要思想如下:

事故是正常的/变更应该循序渐进/工具和文化是相互关联的/度量的。

2、SRE主要原则或者核心如下:

2.1 软件问题:用软工思想来解决运维领域的问题;

2.2 通过SLOs进行管理:产品团队和SRE团队为服务及其用户群选择适当的可用性目标,并将服务管理到该SLO;

2.3 减少琐事:甄别琐事的来源以便可以最小化这些工作甚至消除;

2.4自动化:决定什么条件下做什么自动化以及怎么自动化;

2.5与开发者共享:工件透明,信息共享,工具同步;

2.6 持续改进:快速试错,快速改进,更高效,更可靠,提高收益;