运维团队中的流程规范


这周在内部享关于团队在流程规范上的一些实践心得,整理一下分享到公众号。

运维工程师一般对业务功能上线要求还是比较严格的,但到了自己开发的功能上线和变更时,往往因为有较大的权限且缺乏监督,更容易疏忽和踩坑。

文章针对运维方面分享一些具体的实践经验和建议,一般来说也适用于业务产品的上线流程。希望对你有所帮助。如果你想和更多运维技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

为什么需要流程规范?

宝玉老师在《软件工程之美》中分享到,流程规范就像马路中的红绿灯。这个比喻我认为非常贴切,所以就以此来延伸到今天的分享中。

一开始有马路的时候,并没有红绿灯,当开车的人多了,问题就出现了。
1.jpg

为了解决这个问题,需要有一个权威来协调各方,其中一个方法是交通指挥员。
2.jpg

但交通指挥员能运作需要满足有两个条件:
  1. 指挥员具备指挥经验,并需要时刻头脑清醒;
  2. 听从指挥的人需要理解并执行指挥员的指示。


成本在于两者的沟通,可以毫不夸张地说,即使是老司机,考完驾照后还有多少人可以清晰地记得指挥员的所有手势的意思呢。

于是交通灯出现了。
3.jpg

交通灯的好处在于,它可以容易被复制,不需要依靠人来控制。于是交通规则正式从人治变成了法治。

当然如果附加上一定的约束力,比如摄像头和罚款,效果往往就更佳了。

大家可以很简单地联想到工作中,团队合作中的协调,跟在路上开车很像。红绿灯就是流程规范,看似是对个人的行为产生影响,但是从整体上更有效率,也避免了撞车事故——运维故障的发生。
4.png

痛点

作为运维团队,本来应该对流程规范的意识更强,但这种情况仅限于对业务的要求。当需要变更的是自己的运维平台时候,通常就变得不太一样。

分析一下原因,主要的问题在于运维工程师的权限太大,他们往往既是开发运维平台的人,又是负责运维变更和上限的人。当没有人可以监督的时候,往往就暴露了很多人性的弱点在里面。

在开始介绍规范之前,我们需要定义哪些事情需要纳入规范下面,于是我们规定了运维事件等级。

运维事件等级

根据风险和内容,定义了两级运维事件。

不同等级运维事件在处理变更流程时会不一样,二级事件如果不是很紧急,一般会随一级事件一起变更。
5.png

这里我会先列举一次普通的双周变更流程,然后再针对不同环节进行说明,包括分支管理、版本控制和操作环节。
6.jpg

需要补充说明一点,我们一般以双周为一次开发周期,第一周以开发功能为主,第二周如上所示进行更新上线。这里的第二周,可能是其他功能开发周期的第一周,不同功能开发周期会有一定的重叠。
7.jpg

分支管理

我们的分支管理参考 Jeff Kreeftmeijer 的方案以及使用 git-flow 工具来对分支进行管理。如下图所示:
8.png

关于分支管理的具体内容,这里就不展开了。需要指出的是这里涉及到的功能分支、开发分支、发布分支等,都应该要有对应的运行环境,并通过推送分支进行部署,以提高开发、测试和部署效率。

上文中提到我们有个测试环境,用于模拟生产环的变更。这个测试环境大部分时间都是跟生产环境保持一致的,平时开发的时候不会用到,只有在上线新功能到生产环境,或者对生成环境验证紧急Bug修复时才会用到。

版本管理

目前的管理平台采用微服务的思想进行开发和管理,每个功能模块有独立的仓库和相关的负责人。在运维变更时,如果没有版本管理的概念,容易造成沟通上的问题。

以下是一个真实的案例,某一次更新过程的聊天记录:
  • 产品说:前端已经更新了,咦,这个功能为什么报错的?
  • 前端说:接口请求报错了。
  • 后端说:这个API是在这次更新发布到线上吗?我不知道呢。


后来我们在更新维护的时候,都要求每个模块相关负责人把本周维护的版本整理在一起:

周版本 20190525 相关模块更新流程:
【9】
这里功能开发的时候使用的版本采用语义化版本格式,版本格式为:主版本号.次版本号.修订号。除了语义化版本,我们通常还会附加上一个上线时间日期作为分支的标签,用于产品沟通需求的时候用途。

每次更新的时候,有了这个表格,就知道当前版本和要更新的版本,根据版本号能够迅速找到该功能对应的分支,有以下一些好处:
  • 清晰每次变更的内容;
  • 遇到问题有助于排查和定位;
  • 短期解决不了可以尽快回滚。


一次常规维护流程(周四)

有了前面的准备之后,那么在维护变更的时候,只要按照相应的文档进行操作即可,这里简单说明即可:
  • 通知用户群
  • 备份数据库
  • 更新代码、执行 SQL 变更语句
  • 测试验收,有问题则排查和修复,短时间内修复不了则需要进行回滚
  • 结束维护,通知用户群


收益

  1. 由于有了操作文档和规范,人为操作的时候会更加有准备,出错机会更低。
  2. 目前几乎每周都有版本迭代,每次变更相对较少,有问题能够更早和更容易发现。
  3. 有了规范并不代表不会出错,但是在规范下出错更容易定位排查问题和解决。
  4. 规范是对运维操作人员有保护的作用。有了规范之后,我们不再以是否产生故障来判断这次操作是否有问题,而更多的是依据是否遵守规范来判断。


建议

一个好的规范,可以帮助团队和产品提高稳定性,更重要的是改变了依靠人的自觉和经验这一个局面,变成通过流程和规范,让每一个加进来的同学都可以快速进行开发、测试和部署。

如果你正在尝试为你的团队建立流程规范,以下是我的一些具体建议。

1. 从发生过的故障和问题着手

虽然故障不是什么好事,但是故障处理得好可以避免下次在同样的地方跌倒。按照故障整理流程规范就是其中一个手段。比如上文中一个提及的一个沟通的例子,由于不同模块负责人之间的沟通问题导致上线出错,于是通过版本管理的方式来提前规避。

2. 凡事都有记录

思考上面的所有措施,可以发现,整理规范的第一步,几乎都是从记录开始,记录版本号、分支和运维操作,当人需要通过文字去记录过程的时候,就会下意识地提高准确性,而不再仅仅是自己脑海里面概念。

记录过程和操作记录,也有助于后续的问题排查和处理,以及未来可能的运维数据分析。

当然记录也是有时间成本的,所以尽可能通过自动化的方式,让系统帮助我们进行记录是最理想的情况。

3. 持续迭代,合适当下的才是最好的

整理规范一时爽,实施部署时常常就打自己的脸,因为实际情况跟预期差太多。

建立规范不是一蹴而就的事情,常常考虑成本和收益的权衡。建议从小的地方做起,通过闭环的方式持续迭代,慢慢形成适合自己团队的规范。

最后

本文总结了我们团队在流程规范上的一些实践经验,并给出了建立流程规范的一些建议,希望对你有帮助。

流程规范最终的归宿就是消亡——所有的事情都自动化后,按照规范行事就成了自然的事情,遵守规范变成了成本最低的道路,而到了那一天就没有所谓的规范了。

如果有一天道路上所有的汽车都实现了自动驾驶,那个时候红绿灯应该就没有存在的意义了。

作者:单汉强,网易资深运维工程师,目前主要负责网易游戏部Redis服务化平台的架构设计和开发工作。

原文链接:https://mp.weixin.qq.com/s/D5pO-kDgwb8T4NEL1iPi1Q

0 个评论

要回复文章请先登录注册