无线运维的起源与项目建设思考

原本是计划写写无线运维的项目年度总结的，但是想想一个项目总结文章，只是对自己和项目有个回顾和交代，对于无线运维这个新的概念，还不如放开讨论一下。说到这里，可能一些好奇的同学可能会发出灵魂三问：什么是无线运维 ？为什么要做无线运维？无线运维能解决什么问题？因此，作为一个从开发转入安全生产时间不太长的小白，结合自身在无线运维项目建设过程中的思考，来说说无线运维的起源，可能更好的重温初心。

无线运维的来历

说起运维一词，很多人第一印象都会想到后端基础设施的维护和保障，哪怕当前是无线互联网繁荣的今天，基本也不会一下子想到运维跟无线端有什么大的联系；那么首先我们来看看百度词条对运维的释义：

“运维，本质上是对网络、服务器、服务的生命周期各个阶段的运营与维护，在成本、稳定性、效率上达成一致可接受的状态。”

从上面百度词条对运维的释义来看，运维是一个持续性的行为，范围是基础设施以及运行在基础设施上的服务，同时职责上还要兼顾稳定性和效率；随着国内外各大云厂商业态的出现和发展，基础设施已经云化，互联网的各个厂商可以更多的把精力放在业务服务上，因此保障提供的业务服务的稳定性成了现在运维的重点。 如今移动互联网消费业务丰富多样，抛开服务的架构和部署形态，单纯从提供服务的组成来看，绝大多数都少不了提供数据计算和业务服务的后端程序和响应用户交互的前端程序；提供数据计算和业务服务的后端程序的运维从之前的传统运维继承下来了很多成熟的运维工具和运维手段；响应用户交互的前端程序这一块，因为是运行在用户的无线设备上，天生的分布式和设备差异，让无线侧的运维的复杂性增加了许多；如何保持业务和服务在用户无线设备上的稳定运行，让用户拥有良好的使用体感，就是无线运维的来历。

要解决的问题

在无线互联网繁荣发展多年后，我们在无线端看到了很多的运维产品，比如用户打点和监测日志，用户舆情反馈和聚合订阅，热修复等生态工具和平台，这些都是一些被动的或者等问题出现后才感知并去处理的工具和平台；像手淘这样的前后端上千人协同开发，频繁发布和更新各种服务，拥有亿级别用户群的产品，被动发现问题就意味着后知后觉的线上故障；因此无线运维的北极星目标，就是提高线上问题的发现率。 如果一个事物各物理参数不随时间变化处于平衡时的状态，那么他基本上就处于物理学意义总的稳定；基于我们过往的线上问题处理经验，也基本验证了：稳定性的波动大多数都是变更带来的；在业务迭代中，有的是上游或者下游的变动被动的对你的业务产生了稳定性影响，有的是自己的业务变更对自己的业务稳定性造成波动；因此无线运维在问题的发现率上，从两个方面去着手：一个是日常的线上问题发现，一个基于自身变更灰度放量下的问题发现。

1.日常线上问题的发现效率

日常情况下，很多问题可能是由于业务上下游的变更导致当前的业务被动出现稳定性问题，也有一些是自身的变更造成长尾历史版本出现稳定性问题；不论那种情况，这些被发现的问题，短的也逗留了几天或一周，长的几周甚至裸奔几个月；对于这种问题，我们没有啥未卜先知的好办法，需要通过各个业务配置(不定期更新)业务核心监控和订阅规则告警，以及用户反馈的业务舆情信息的日常值班留观。 配置订阅的监控，告警，舆情等稳定性反馈渠道，对于手淘这种流量巨大的产品，底层数据的量级也是比较大的，通过2020年的基础链路团队从7月份到12月份的日常稳定性值班实践情况来看，每天去Crash平台，舆情平台，告警记录等都相对仔细的浏览一遍，人力上也要平均四十分钟到一个小时左右的时间；如果有疑似问题，排查除疑那又是另外的时间了；因此日常线上问题的发现，发力点是提升问题的发现效率。 发现效率的提升，也就是要提升日常值班的效率；因此，对于Crash我们除了订阅自己负责的业务模块最好把自己业务重点依赖的模块也订阅上，然后通过排行，环比上升等方式来快速突显快速变化的记录；舆情方面，通过一段时间的正负样本打标训练来过滤技术性舆情，同时对于舆情图片接入OCR和关键词来区分舆情与业务的关联性；告警方面，目前的告警很多都是基于一个阈值来触发，但是线上如果有促销活动，基于阈值的告警则误告频繁，因此基于时序算法的趋势告警准确性更高。

2.小流量放量下问题的主动发现率

对于用户规模比较大的移动互联网产品，无灰度不变更是每个人都逐渐建立的安全生产意识；在小流量下的变更放量，对于产品侧来说，可以收集用户侧的点击、转化等数据，来分析小规模用户对新特性的接受程度，作为改进产品/运营策略或是铺开/全量的一个辅助依据；对于开发和测试来说，通过小流量，能初步的验证代码变更在小范围的不同的用户设备上的运行的稳定性情况，有问题则迅速修复无问题则扩大放量比例。 不管是产品/运营还是开发/测试，要观测小流量下的这一部分用户反馈数据，单靠一个唯一的灰度版本号，并不能比较真实的从全局数据大盘中圈出这一小部分数据；因为放量推送10W，并不一定意味着被推送的用户都看见/走到了你变更的那一部分新特性！因此要想知道新的特性是否真正的在用户侧触达，端侧需要对特性生效做”染色”。与此同时，用户在新特性的实际暴露期，我们在APP的Crash报告，舆情反馈上报，监控埋点上报等环节，都带上这个唯一的染色标记；这样我们在放量后的沉淀阶段，通过这个唯一的染色标，就可以清洗出此次新特性在用户设备上生效时产生的各种用户反馈数据。 作为一个多业务模块的用户产品，多团队协同并行变更是常态，一个版本一个时间段内，可能不止一个业务在进行变更放量，比如一条Crash报告，如何区分到底是哪一个业务变更造成的呢 ? 这种很难快速判断划分，因此我们把当前多个在变更生效的特性的染色标都带上，在变更染色下的Crash数据的清洗的时候，这条Crash就会出现在多个变更放量的留观的Crash列表中，保证线上问题不遗漏；其他的稳定性染色数据的上报和清洗遵从同样的规则。 有了能准确清洗出变更特性实际生效下染色多个稳定性指标数据的手段，我们在小流量放量并逐步加大放量的过程中，就能只看变更影响下的数据；如果没有这个手段，小流量放量产生的问题，由于比例比较小，在大盘海量数据作为分母的情况下，连一个涟漪都不会泛起。等到大规模放量甚至全量的时候，问题被明显暴露出来，之前的小范围问题可能已经是大范围故障了。

能解决什么问题

上面所说的日常线上问题发现效率和变更下问题的主动发现率，如果业务团队都付出行动和努力，进行了值班留观和变更染色接入，对于业务团队来说，能多大程度解决业务同学在线上问题的安全焦虑？这个其实就看我们通过做了这两方面的事情，深层次是解决了什么？

1.转被动为主动

按照集团安全生产的要求，对于线上问题，要求5分钟响应，15分钟定位，60分钟解决，这个目标来看，也是希望研测同学能尽早的响应和解决线上问题，越早的解决掉线上问题，业务同学也能相对的越主动。 在日常的业务值班方面，经过在基础链路客户端团队2月份-3月份的实践经验来看，每天轮流花个十五分钟到半个小时，进行线上稳定性的巡检，能大大缩短问题的暴露时长，提高线上问题的响应效率，在问题影响变大之前，通过前后端的业务开关，降级预案，热修复等手段，基本能快速解决大部分的巡检出来的问题。 在变更灰度的放量监控方面，我们通过2021年的基础链路部分重点项目的对接和业务开关平台灰度发布监控的效果来看，我们通过染色下的舆情、Crash、服务端错误码，在变更发布的小流量灰度放量期间，均有效捕获了业务/技术上的有效问题。这些问题都是在小流量的验证下发现，并通过服务端和放量平台的流量回滚规避了问题的暴露和扩散，相对日常巡检值班来说，可以算做是真正意义上的主动发现问题。

2.缩小问题爆炸半径

一个线上问题对用户的影响可以用三个维度来度量，三个维度叠加决定了问题的实际“爆炸半径”：

问题持续时长：问题从发生到恢复的总体时长 问题影响面：发生的次数，影响的设备数 问题严重程度：对用户使用造成的影响程度，可以大致分为几个等级：阻塞不可用（闪退、核心功能不可用）、部分不可用、轻微不可用、无影响

日常的业务巡检值班可以缩短线上问题的发现时间，减小问题持续时长；变更灰度的放量监控可以尽早捕捉问题和控制受影响的设备数量，减小问题的影响面和问题严重程度；无线运维紧抓日常和变更两个场景，能有效的控制和缩小问题的爆炸半径；

未来想解决什么问题

上述对无线运维要解决的问题，能解决什么问题的阐述内容，也是目前无线运维这一年探索和建设并且已经上线的部分。在过去的2021年里，对接业务日常和变更下的线上稳定性诉求过程中，深感目前我们还处于一个初期的阶段，虽然从海量数据留观走到了业务关心的小部分数据留观和监控，但是目前还是需要业务同学投入较多的人肉工作量；业务同学也在这个过程中提出了更高的要求，希望能实现业务变更的分阶段发布的流程化，业务Top舆情场景诊断和告警的智能化，从安全生产角度能卡住那些变更质量不达标的发布。

1.分阶段发布

目前的业务变更放量，大多是通过业务开关、圈选人群或者类似一休这样的放量平台进行放量，通过不断的扩量，不断的留观，直至业务全量；这个过程可能持续几个月，对研测同学来说，线上稳定性是有足够时间来保障，对产品运营同学来说，业务全量铺开的效率显得过低；因此期望，能有一个从内到外，流量从小到大的分阶段发布流程，每个阶段验证无误后，能快速流转到下一个阶段；

内网白名单：业务的产研测、上下游团队以及TL，先进行内部体验； 内网灰度：集团内网有很多热心的同学积极反馈问题，能反馈很多产品体验和功能bug，兜住家丑 外网人群：产品运营圈选的第一波人群用户，观测用户数据反馈，研测关注外网用户线上稳定性问题 外网分批灰度：分批递增灰度放量，业务&体验&稳定性综合验证 外网全量：多次灰度验证完成，停止变更染色，业务全量

2.智能诊断

日常线上问题巡检和变更下的线上问题的我们有监控和留观等机制保障，但是有时确认一个问题它是否是一个需要处理的问题，这个过程往往也比较耗时；还有些问题并非是通过Crash，埋点监控告警能发现，比如页面组件缺失导致业务阻塞等问题很多都是通过舆情来反馈的；如果问题的确认、分析和诊断，都靠拉群排查是偏低效的，通过规范化的埋点，体系化的排查手段，引入算法是比较好的辅助方式；

定义&完善业务日志规范，打好日志可视化基础，建立全链路排查体系； 覆盖业务阻塞/阻断的舆情场景，结合用户日志和埋点，进行智能分析诊断； Crash/告警，从基于阈值触发升级到基于时序算法的趋势智能告警；

3.发布卡口

虽然我们已经有了变更染色的手段，可以对变更下的稳定性问题进行多个指标的监控，但是当前批次的发布综合的质量是否达到安全生产的要求，并没有给出一个详细的结论，更多是靠研测同学自行判断决策；因此在发布过程中做每个批次的卡口，帮研测同学分析评估是否可以进入下一阶段的发布，能有一个更高效和安全的体感。

线性递增式发布：如业务开关、Patch，放量线性递增，全量时间周期相对短，对于每次递增放量，都应该综合染色数据各项指标和灰度标准做Check，对于不满足灰度标准或者染色数据指标有异常的，应该及时提示卡住； 回旋往复式发布：如一休、服务端自定义规则放量，多个分支的流量可以随时自由调配或回滚，放量周期相对比较长，在不同的流量配置叠加验证时，也要关注对线上命中用户的稳定性影响，对于出现异常的实验分支，要及时提示卡住；