Devops的文化和方法论

2,145 阅读7分钟
原文链接: mp.weixin.qq.com

这两天在整理准备做 Devops 的分享,在过程中发现自己之前对 Devops 的认知也不是很全面, 到底什么是 Devops, Devops 和持续交付是什么关系,下面是我目前对其的一个认识。

首先是 Devops 要解决的一个典型问题,传统开发流程中开发和运维虽然都是工作于同一个产品,但他们的工作目标却有着根本且本质上的冲突,开发主要是根据产品和用户的需求来开发各种新功能,而运维则会关注线上所部署产品的可用性,稳定性以及可靠性。这主要会引发以下两点矛盾:

  1. 据坊间传闻以及日常的经验生产环境中有大概 70% 的崩溃是因为变更引起的,这样对于运维来说当然是不变更最好了

  2. 开发想要自己新的代码部署到线上,必须通过运维来手动或半自动进行部署操作,这边就存在两者间的沟通问题以及责任不明确

随之发生的就是软件交付周期变长,开发不愿意提交变更,开发运维之前相互责备,技术负债不断累积这一系列的问题。而且这些问题会随着时间变长不断变得越来越严重。这个问题并不是说开个团结会说开发运维要目标一致水乳交融就能解决的,更多的是组织架构,团队沟通,软件生命周期方面暴露出的缺陷。

Devops 的诉求在于我们如何更好的形成组织架构,减少沟通成本,树立团队内一致的目标以及优化软件生命周期。其实到现在对 Devops 还存在各种各样的定义,因为它涉及的面实在是太广了。之后会主要谈谈 Devops 文化以及 Devops 的方法论。

其实如果想在一个企业内践行 Devops,招几个 Devops 工程师,把软件发布流程自动化是远远不够的。更重要的是树立 Devops 的文化,再把这种文化自上而下的渗透到流程团队中,主要包括以下几点(主要参考 Netflix 的分享):

  1. 不要构建一个说不的系统,取而代之的是自由和责任。我们不会指定所谓的部署窗口期,开发人员可以随时部署,也可以随时登陆线上环境,我们相信获得自由的同时也能承担与之对应的责任

  2. 当创新速度和线上稳定性有冲突时,优先选择创新速度。我们不应该不惜一切代价来保证系统的稳定,而是要把系统做的足够弹性,我们鼓励开发人员做更快更有趣的事来吸引更多的用户

  3. 我们不会在有各种繁文缛节的批准而是去营造一个信任的氛围,我们应该把这些过程融入到交付流程中

  4. 我们不会去控制,但是乐意提供一个上下文,我们不会限定开发人员这个交付流程必须按怎么样的流程跑,但我们乐意为其中流程中的每一个步骤提供一个标准的实现,开发人员也可以把自己自己实现其中一个步骤放到共享仓库,把局部知识转化为全局知识

  5. 我们不会制定标准,而是允许开发人员自己权衡。我们不会说你这个项目必须要用某某语言,而是让该团队自己选择更适合该情景的技术栈,给予其足够的自由。

  6. 我们应该是一个基于数据的团队而不是基于猜测,之前团队里也遇到过这样的情况;诶,这个服务是不是只有我一个人访问不了,是不是挂了?或者说这个请求好慢,是不是数据库死锁了。这些问题应该是通过设立快速持续的监控,根据数据来更早的得到反馈,这样不仅能更早的修复问题,也能增强团队对系统的信心。

  7. 对自己的代码负责,你构建它,你运行它,这其实对开发也提出了更高的要求,所以 Devops 不仅是会要求运维更懂开发,还会要求让开发更懂运维。运维应该提供更好的工具还帮助开发配置和了解线上服务,从而让开发更接近线上环境。

可以看到在这种文化下想要创建的是一个相互信任,积极创新,基于数据充满信心的氛围。基本这种团队的文化,Devops 方法论其实是为了达成这种文化,我们可以做的一些事情,主要会包括下面这三点:

  1. 减少开发人员接到需求编写代码开始到代码部署到线上的时间,对于用户来说能更快的享受到新功能,对于开发来说能更快的得到反馈,目标也会更一致

  2. 基于全局来制定计划,关注代码内建质量,持续,快速的得到反馈。反馈主要包括单元测试,集成测试以及各种级别的监控告警

  3. 创建相互信任敢于创新的企业文化,这是前两点的自然延伸和加强

对于前两点来说,只是把代码交付流程做成自动化,加点单元测试是远远不够的,更重要的在于代码高频次的小批量部署以及其内建质量,这样才能确保交付流从左到右更快的流动以及从右到左更快更持续的反馈。在目前来看持续交付实践能非常完美的实现整个流程。

  1. 首先,持续交付要求保证每次软件发布都是一个可重复且可靠的过程,这样就要求尽可能的把流程中的所有步骤自动化来提高交付速度,同时也使系统更具弹性,就算系统挂了也可以马上重建

  2. 持续交付强调我们应该提前且频繁的做让我们感到痛苦的事,线上部署我们害怕出问题,敢不敢每天线上部署十次?害怕服务器挂,敢不敢随机让 1/3 的服务器挂掉?我们应该保证这些事情是可预测的,当这些事对于我们来说稀疏平常时,那我们系统的变更速度,稳定性会变得越来越好

  3. 通过内建质量来保障快速交付,很多时候我们害怕把代码提交到线上是因为我们不知道部署到线上时会发生什么,会不会影响到客户。而内建质量可以帮我们树立这个信心,这部分主要是包括测试和监控,应该要做到在交付流程中尽快的通过测试发现问题,已经部署到线上后能尽快通过监控发现问题

  4. 保证交付流程成功是团队中所有成员的责任,我们应该不断的优化这个流程,团队中所有成员的目标就是更快的为市场提供符合用户需求,稳定,可靠的产品

在以上这些实践中,我们认为对于开发人员来说代码部署到线上,监控指标未告警才算是完成工作,对于运维来讲协助实现真个过程才算完成了工作。倘若能以上这些,那整个流程自然会适配于 Devops 的方法论。

就像在软件工程中所说的那样,没有银弹,Devops 可能并不能解决一切问题,在未来也可能会被其它所替代,但就目前来看,Devops 能解决一些方面的问题。目前公司内部 Devops 也有很多做的不好的地方,每个公司有不同的情况,对于一些公司可能没有必要遵循其所有实践。但就像其理念内所蕴含的,

就做 Devops 这件事来讲,我们可以持续不断在公司做相应的实践,尽可能多的获取反馈来不断优化,最终能达到适合当前情况的 Devops 实现。So don’t think of Devops, Just do it。

参考: Netflix 分享

         《devops 实践指南》

         《持续交付:发布可靠软件的系统方法》