一、继续部署
1，现状
因为没有建设规范的继续部署流程，导致了版本管理混乱，制品管理混乱，上线持续时间长，上线测试笼罩不全面，业务流量回升后故障较多，排查简单。运维、测试、开发人员每次版本迭代的时候，都要可能须要经验一次通宵的历练，并且这种在上线的第二天仍然会呈现很多线上故障。
2，痛点
l 自动化公布体系覆盖率低。
l 无标准化公布的流程。
a) 只重视麻利、漠视品质问题；
b) 变更频繁导致故障率减少；
c) 开发语言品种多，公布制品管理混乱，公布形式简单；
l 平安问题容易被忽视。
二、工具介绍
1，Saltstack
基于 ZeroMQ 的开源的配置管理工具。笔者之所以选型应用 saltstack，而放弃了 ansible，起因是因为 ansible 基于 ssh 通信，在管控主机超过五百台之后，基于音讯队列的命令下发形式无论在稳定性还是速度上都优于 ssh 协定。笔挺另外选在 saltstack 的起因是，在服务的开发团队中存在着不同的技术栈并行的情况，尤其是 java 和.net 并存的状况下，saltstack 对于 windows 的反对显著要优于 ansible。更容易作为多平台的底层公布工具。
而基于 SaltStack 打造自动化部署平台次要是用 grains、pillar、state 三个个性，grains 用于获取默认环境配置信息、pillar 用于定义环境信息、state 用于编排公布文件进行公布。
2，Artifactory
全语言制品仓库管理软件，有开源版及企业版两种。开源版反对 maven 制品治理；企业版反对全语言制品治理，反对元数据管理性能，提供高可用部署形式、匹配 nvd 及 vulnDB 数据库，提供破绽扫描能力。
三、针对上述痛点解决方案
1，自动化公布覆盖率低
通过搭建兼容多平台部署对立公布工具，替换掉传统的 shell 脚本拷贝的形式实现公布工具标准化。通过 SaltStack 的 state 个性，实现跨平台的根底服务公布、服务启停、文件公布、配置公布、近程主机治理等 90% 以上手动操作。应用 SaltStack 的 state 编排文件，执行近程命令，通过 Artifactory 获取制品及配置，将须要的版本公布到线上。
次要计划在部署平台中，通过 json 格局形容公布流程，通过 yaml.dump(sls_json）将 json 文件转换成 yaml 各位的配置文件，最终通过平台调度 saltstack 执行编排好的工作。
转换后的 yaml 文件格式如下：
2，标准化公布流程
l 备份
公布工作编排的第一步就是备份，备份需采纳本地备份加异地备份两种机制，本地备份用于疾速回滚，异地备份用于环境重建。
l 切流量（蓝绿部署）
对于服务，尤其是有状态的服务，须要在注册核心中进行节点下线，确保本节点所有解决完结后，再进行部署。
对于页面，须要在负载平衡上将节点登记，对没有流量的 web 页面进行部署操作。
l 部署
通过 saltstack 的 sls 个性，编排部署文件，对多个部署工作进行对立进行公布。
部署时咱们心愿能够在部署页面查看到相似下述信息，如：部署包对应的需要 id、部署包对应代码的提交信息、部署包自动化测试的通过率、部署包的代码扫描后果、部署包的平安扫描后果、部署包人工测试的后果等等。运维人员须要在公布过程中看到此类信息，来明确包是否通过了所有品质关卡、具备了上线条件，从而判断此次上线是否能够持续进行。这里咱们应用了 Artifactory 的元数据性能，用于记录软件包诞生的整个生命周期的信息，并通过 api 形式对接到公布平台。给运维人员一个残缺的包的信息记录。
l 自动化测试
此处自动化测试次要能够了解为检测服务端口通信是否失常、回归线上性能是否可用、缺点是否被修复、新个性是否部署实现等。同时此处须要预热服务及站点，通过自动化的测试买通业务流程。
l 流量回归（金丝雀）
局部实在流量切换到曾经部署实现的利用上，通过全链路日志追踪或监控指标反馈来初步判断新上线利用是否衰弱运行，并将此后果作为后续公布或回退的根据。
l 部署补全（滚动公布）
在应用低谷工夫将流量牵引到已部署实现的利用上，同时将其余利用降级。
l 变更治理通告。
上线胜利后须要及时的告诉大家线上版本已变更，产品经理须要及时更新文档，经营人员须要及时对用户进行告知。
l 回滚
任何公布都须要思考回滚计划，对于单个利用须要回滚到一个指定版本；对于多个利用，须要明确一个回滚集，通过公布时的编排工作指定回滚的编排工作。对于数据库等更新，如果回顾简单，则须要在降级计划制订前就明确回滚计划或在业务中做好版本兼容。
3，建设对立的制品治理仓库
大多互联网公司曾经对源码仓库有了对立的治理，但对于制品仍然处于一个原始的管理状况，比方应用 ftp 以及每种语言开源的治理仓库。这里遇到的问题是，运维人员须要投入大量的精力保护不同的包治理平台（如 ftp、maven、nuget、pypi、docker 镜像核心等）。节约掉大量运维团队的人力老本之外，也极度简单了公布流程。公布人员须要在不同的平台获取上线的包，导致公布流程凌乱，公布平台配置凌乱。并且大多数开源组件均不提供高可用能力，一旦硬件或软件呈现故障，都将重大的影响公布效率。
为了解决这种问题，咱们采纳 Artifactory 来治理所有语言的制品仓库。与对立 gitlab 一个情理，咱们把整个公司的制品对立治理，成为对接公布平台的惟一包起源，从而标准了公布流程。
4，破绽扫描
目前平安团队扫描大多是在服务部署上线后进行，这种状况下和容易造成因为版本有安全漏洞导致的整个迭代废除，所有包须要从新编译，从新通过测试流程以及上线过程，节约掉大量的工夫，升高迭代的速度。
解决办法是将破绽扫描步骤前置，在制品包结构编译的时候，乃至开发人员 code 代码的时候就对外部援用、外部公共库进行破绽扫描，一旦匹配到高危破绽，间接把提交或构建终端。如果肯定要持续构建，那么能够将扫描后果记录到制品的元数据中，供测试人员，运维人员查看。目前 JFrog Xray 等平安扫描旧居提供此类能力。也能够应用开源软件，如 cvechecker，在编译流水线中对包进行扫描，避免因为安全漏洞造成的整个迭代失败。
四、前期欠缺
1，设置度量体系，晋升公布品质
麻利开发模式下，开发人员和测试人员往往是汇报给同一位管理人员，出于疾速迭代线上性能，往往有些团队会投机取巧、将没有测试残缺的包公布到线上进行测试。该种问题的间接体现是，为了解决一个 bug，可能多工夫屡次对同一个利用或页面进行 hotfix 或公布新版本。这样做是非常危险的，置线上业务稳固于不顾。为了防止此类情况产生、咱们能够采纳一些措施或标准来束缚开发团队。例如：
上线后触发新 bug 数量
短时间内对雷同问题公布次数
因为上线起因造成的 P5-P0 级别故障的数量
上线后故障复原工夫
上线后回滚的次数
非上线工夫内紧急上线数量
…
通过收集上述数据，每月或固定周期对各个团队进行考核。并对公布状态复盘，通过制订规约，评估团队的交付品质及交付能力，开掘团队中的公布问题及痛点，从而进步公布品质，缩小线上故障率。
2，制订度量规范，进行公布品质考核
每团队初始分为 100 分，每月重置，每月用此分作为迭代品质的一项规范，分数不挂钩 kpi 考核，只用来驱动开发团队去提高效率。
评判为两个维度：项目组公布稳定性得分、服务（站点、app、微服务等）公布品质得分
l 非上线工夫公布 hotfix（项目组减 1 分，服务减 1 分）
l 代码类 hotfix，同一我的项目每天公布超过 3 次（项目组减 1 分，服务减 2 分）
l hotfix 公布失败或回滚（项目组减 2 分，服务减 2 分），公布是否失败，由运维团队认定。
l 数据库等脚本异样或执行失败（项目组减 1 分）
l 每月服务公布数量（取 top5，服务按排序减 5 到 1 分）
l 因为 hotfix 起因造成 P2 级以上的线上事变，项目组减 5 分，相干服务减 5 分
l 项目组本月 hotfix 量如超过前 3 月平均值的 30%，减 10 分
3，变更治理
在 google 的 SRE 体系中，变更治理是 DevOps 体系中最为重要的一个局部。依据以往的教训，90% 的线上故障是因为线上变更导致的，该变更起因包含软件、硬件、环境等所有因素。建设变更管理体系目标就是为了疾速定位线上问题，止损因为变更造成的线上故障，及时告诉相干人员做好故障预防工作。所以，变更管理体系也是须要咱们重点去建设以及欠缺的。
落地形式包含但不限于下述几点：
l 运维人员、对应的开发及测试人员、产品经理等微信告诉
l 大屏滚动播放最近的变更记录
l 变更记录同步到监控零碎
五、总结
总结为一句话，尽管在麻利开发模式下、产品、开发、测试团队都在小步快跑，但运维必须有本人的准则，肯定要对整个上线流程制订标准、对 DevOps 工具链进行对立治理。
线上稳固大于所有！
** 欢送观看 JFrog 杰蛙每周二在线课堂，点击报名：
https://www.bagevent.com/even…**