SRE体系05----发布工程

概念

发布工程专注于构建和交付软件，通过源代码仓库，编译器，自动化构建工具，包管理器等工具软件，让代码运行起来，对外提供服务。

发布工程属于devops的一部分，对于提升研发效率意义重大，但是效率和稳定性是一对矛盾，发布工程就是要在提升效率的时候保持足够的稳定，确保业务系统不因频繁的上线等操作出现故障。

在我们组建自己的发布工程时，应该注意以下几个原则：

1.自服务模型

SRE工程师开发工具软件，利用开源软件构建流水线的目标是提升发布效率。在此过程中要注意，这些工具和流水线是由开发团队来使用和执行的，运维工程师不要过度参与到发布过程，除非出现开发团队无法处理的问题才干预。只有这样在应对业务规模扩张时，运维人员才不会疲于奔命，同时也给了开发团队足够的自由度，让各个开发团队能够依据自己的节奏和计划上线服务。

2.追求速度

面向用户的软件上线发布非常频繁，因为这类软件的目标是让用户可见的功能越快上线越好，能够快速响应用户和市场的需求以获得商业价值。快速迭代的敏捷开发方式已经成为主流，小步快跑的模式可以减小版本之间的差异和变化，让测试和调试变得简单，同时降低上线后出现问题的概率。所以我们的发布工程要满足速度的要求

3.幂等性

我们使用的发布工具链必须具有一致性和可重复性。常常都听过开发人员这么抱怨："在我服务器上明明跑的好好的，怎么上线了就出问题？"
，这里有两种可能，一种是因为开发环境和生产环境的配置差异造成的，还有一种可能是我们构建和发布的软件包不一致，不满足幂等性导致的。同一份源代码理论上必须要保证无论构建多少次，最终出来的软件包是一致的，不受构建服务器上安装的系统版本，第三方库或其他工具软件影响

4.强调策略和流程

要指定安全，合理的发布流程规范和权限，确保只有指定的开发人员或产品人员有权限执行发布操作。在无特殊情况时，要遵循发布规范操作。

同时发布流程要足够简洁高效，通俗易懂，不要给其他团队的同事造成学习成本和流程负担。 一旦过于繁琐，开发团队可能会选择绕过这些流程，再完善的流程和规范也变成了摆设。

5.协调与共识

我们需要制定发布计划和通知事宜。发布前要和研发，市场，产品，运维等团队沟通上线计划，获得认可和共识，同时要通知到所有受影响相关方

6.检查列表

在我们上线前，通常我们要列一个检查表单，以消除潜在的问题和影响，以下是举例：

1. 架构和依赖
   我们需要评审该服务是否使用了合理的基础架构资源，是否有依赖服务和被依赖服务，是否会对IAAS层造成影响
2. 系统集成和配置
   如何选择服务器，配置网络，设置监控，与负载均衡系统和DNS服务结合
3. 容量规划
   业务刚上线可能会带来尖峰式的流量，需要配合压力测试，及产品，市场等部门的用户反馈设置合理的资源容量，确保不发生雪崩事故
4. 安全防护
   针对系统可能受到的攻击进行安全测试，同时配置防火墙，WAF等相关设备和策略
5. 回退计划
   针对发布计划中的每一步分析潜在危险，并制定相应的补救和备用方案。同时针对发布失败或异常，制定合理的回退方案