这个是AIoT-SRE在小爱的一个尝试性运营项目，我们旨在用持续运营的方式提高开发和运维人员对生产环境的敬畏之心，培养团队文化，减少变更类故障，让大家从骨子里守纪律，按规矩

这个是AIoT-SRE在小爱的一个尝试性运营项目，我们旨在用持续运营的方式提高开发和运维人员对生产环境的敬畏之心，培养团队文化，减少变更类故障，让大家从骨子里守纪律，按规矩上线生产环境。

操作思路上参考机动车驾照制度，每个人都有一个月度分数，随着异常上线进行扣减，扣完后就要强制参加一次我们组织的合规部署培训，培训完成后分数清零，循环往复。在培训流程设置上，首先是听枯燥的上线制度，然后组织每个人进行复盘，在会后由SRE将培训总结进行全员通知，利用大家的责任心和羞耻心慢慢培养起对线上环境的敬畏心。

先对现状做个简介，小爱同学在快速的成长，支持其快速发展的是小米的各技术和产品团队，小爱架构、云端大脑为网民提供了成熟的线上服务，AI实验室为小爱提供了人工智能和机器学习的技能更新，形成了一个完整的进化生态。

进化的越快，迭代变更也就越多，进而变更类故障频出不穷，每次回滚复盘后，听起来都有合理的原因，一次、两次、三次…进而部分同学开始有点麻木了。

其实从SRE的角度来看，任何原因都是说不过去的，变更类故障没有可开脱的理由，稳定压倒一切，只是碍于团队职能不想去过多扯皮，形成不好的团队气氛，从人性的角度总结不按规矩上线主要有两点，新工程师对生产环境认识不够，老工程师太过自信。

再看一下小爱现在的一个数据，这个是包括staing、prew、prod三套环境，和所有job所有机房加和的上线统计，拉取近半年的数据，小爱的更新迭代频率在全公司遥遥领先，近六个月的全部上线将近有4万次，同样带来的是每个月都会有不少变更类的故障。

一、不合规上线业务建模、数据分析

思路想清楚后，第一件事儿就是要对不合规上线进行业务建模，然后使用技术手段对模型落地，形成每个人的变更情况的数据分析，有了这个基础后才能计算好分数，这个是整个项目执行的基础，如果使用人工的方式做这个事情会疯掉的。

1、业务建模

这个阶段主要是为了定义出什么是不合规上线，以及不合规上线的分类，经过和芬姐的梳理，我们把不合规分成了3类：

    -紧急上线

        非工作时间上线，如法定节假日，或工作日的晚上6点之后，早上9点之前；

    -多次上线

        24小时，同一个服务生产环境全量上线两个或以上的版本；

    -回滚

        7天内，生产环境将服务版本全量回滚到上一个版本；

业务建模中我们简化了过程，单纯从结果上进行了分析，其中紧急上线不一定影响服务，非工作时间上线为服务带来了风险，但可能没有产生故障，但也是需要尽可能减少的，当前的服务都是微服务的架构，大家相互耦合依赖严重，生产环境的全量上线需尽量选择在大家都在工作岗位的时间进行，便于观察，减少故障。

确定影响到线上服务的是多次上线和回滚，统称为异常上线，按照小爱目前的业务属性，一个服务一天内正常是不会全量上线生产环境多个版本的，一旦多次上线，从意图上分析，一定是前个版本有问题，然后没有经过测试、灰度等环境又快速的推了新的版本；对于回滚那就不用解释了，当前版本有问题，生产环境全量回滚到上一个正常的版本，触发回滚这个动作的时候，线上的服务肯定是异常了。

在分数设置上，要考虑几点，首先并不是生产环境上线越多越好，其次紧急上线和异常上线的次数越少越好，这几个都要体现在分数计算中，基于此，分数设置如下：

    -分数建模

        每人每月有30分的上线分，生产环境正常全量上线一次扣1分（我们认为上线并不是越多越好），紧急上线一次扣3分，回滚或重复上线一次扣5分。

2、数据实现

数据从部署系统采集后，采用elk+grafana的技术方案进行数据分析的建模，形成dashboard，展现形式如下，可以按产品线按人来查询其上线的情况：

二、建立制度、编写合规上线规范组织持续培训

将日常的上线制度形成规范，基本是到20人就开始组织一次培训，上两张图如下：

三、运营半年后的效果

相比运营刚开始的不合规上线比例，运营半年后，每月的不合规上线比例降低了10%，消灭了不少潜在的变更类故障，大家也增强了对生产环境的敬畏之心，还是感谢芬姐在前期的付出，形成制度后，此项目转为由SRE轮流组织培训。

社长"矢量比特"，曾就职中软、新浪，现任职小米，致力于DevOps运维体系的探索和运维技术的研究实践.