发布策略 | 阿里巴巴DevOps实践指南

编者按:本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》前往:https://developer.aliyun.com/topic/devops,下载完整版电子书,了解阿里十年DevOps实践经验。

DevOps 追求更短的迭代周期、更高频的发布。但发布的次数越多,引入故障的可能性就越大。更多的故障将会降低服务的可用性,进而影响到客户体验。所以,为了保证服务质量,守好发布这个最后一道关,阿里逐步发展出了适应 DevOps 要求的发布策略。

在开始讲述阿里的实践之前,我们先简单介绍下几种常见发布策略, 以及它们适用的场景和优缺点。

常见发布策略

停机发布

停机发布会在发布以前关闭服务,停止用户访问,然后一次性的升级所有服务。这种发布策略的发布频率往往比较低,且需要在发布之前做好充足的测试。

停机发布的特点有:

  • 所有需要升级的组件被整合到一次发布中

  • 一个项目中的大部分应用都会被更新

  • 发布之前的研发流程和测试流程往往需要花很长的时间

  • 发布时如果出现问题, 修复和回滚的成本很高

  • 完成一次停机发布, 需要花费很久的时间, 且需要很多团队在一起才能完成

  • 往往需要客户端和服务器端同步升级
    停机发布并不适合互联网公司,因为两次发布的间隔很久,从功能特性提出到进入市场的时间太长,对市场反应不敏感,会在充分竞争的市场里处于下风。每次发布因为要停机,也会带来经济损失。

优势:

简单, 不太需要考虑新旧版本共存时的兼容性问题

劣势:

发布过程中,服务不可用
只能在业务低峰期 (往往是夜间)发布,并且需要很多团队在一起工作
出现故障后很难回滚

适合场景:

  1. 开发测试环境

  2. 非关键应用,用户影响面小

  3. 兼容性比较难管控的场景

金丝雀发布

金丝雀发布这个术语源自 20 世纪初期,当时英国的煤矿工人在下井采矿之前,会把笼养的金丝雀携带到矿井中,如果矿井中一氧化碳等有毒气体的浓度过高,在影响矿工之前,金丝雀相比人类表现的更加敏感快速,金丝雀中毒之后,煤矿工人就知道该立刻撤离。金丝雀发布是在将整个软件的新版本发布给所有用户之前,先发布给部分用户,用真实的客户流量来测试,以保证软件不会出现严重问题,降低发布风险。

在实践中,金丝雀发布一般会先发布到一个小比例的机器,比如 2% 的服务器做流量验证,然后从中快速获得反馈,根据反馈决定是扩大发布还是回滚。金丝雀发布通常会结合监控系统,

你可能感兴趣的:(阿里巴巴DevOps实践指南,devops,运维,阿里云,云原生,发布策略)