本来打算写无线运维项目年度总结，没想到一篇项目总结文章，只是对自己和项目的回顾和说明。对于新概念，还是放弃讨论比较好。说到这里，可能有些好奇的同学会问三个反省的问题：什么是无线运维？为什么要做无线运维？无线运维可以解决哪些问题？所以，作为一个从开发转入安全生产很久的新手，结合自己在无线运维项目建设过程中的思考，或许说起本源来回顾初衷更好无线运维。无线运维的由来说起运维这个词，很多人第一印象都会想到后端基础设施的维护和保障。多么大的联系；那么首先我们来看看百度对运维词条的解读：“运维本质上是对网络、服务器、服务生命周期各个阶段的运维。达到一个同意和可接受的状态。”从上面百度词条对运维的解释来看，运维是一个持续的行为，范围是基础设施和运行在基础设施上的服务，同时还要兼顾稳定性和效率；随着国内外各大云工厂商业化地位的出现和发展，基础设施已经云化，各家互联网厂商可以更加专注于业务服务，从而保证所提供的业务服务的稳定性成为关注的焦点。现在运维。当今的移动互联网消费服务丰富多样。无论是何种服务架构和部署形式，大部分都离不开提供数据计算和业务服务的后端程序和响应用户交互的前端程序；数据计算和业务服务的后端程序的运维，继承了以往传统运维很多成熟的运维工具和方法；响应用户交互的前端程序，由于运行在用户的无线设备上，固有的分布和设备差异性大大增加了无线端运维的复杂度；如何维护用户无线设备上业务和服务的稳定运行，让用户有良好的使用感，是无线运维的原点。待解决的问题无线互联网经过多年的繁荣发展，我们看到了很多无线端的运维产品，比如用户管理和监控日志、用户舆情反馈和聚合订阅、热修复和其他生态工具和平台，这些是一些工具和平台，这些工具和平台是被动的或者等待问题出现后再去感知和处理；数以千计的前后端人员像手机淘宝一样共同开发，频繁发布和更新各种服务，拥有数亿用户基础的产品，被动地发现问题就是事后看来的线上故障；因此，北极星无线运维的目标是提高线上问题的发现率。如果一个事物的物理参数处于平衡状态，不随时间变化，那么它在物理意义上基本上是稳定的；根据我们以往处理线上问题的经验，也基本验证了：稳定性的波动大部分是变化带来的；在业务迭代中，一些上游或下游的变化被动影响了你业务的稳定性，而你自己的一些业务变化又引起了你业务稳定性的波动；在发现率上，从两个方面入手：一是日常在线问题发现，二是基于自改灰度的问题发现。1.日常线上问题发现效率一般情况下，很多问题可能是由于业务上下游发生变化，导致当前业务被动稳定性问题，也有一部分是由于自身变化导致的长尾历史版本的稳定性问题；不管是那种情况，这些发现的问题可能会短时间停留几天或一周，甚至长时间裸奔几个月；对于这种问题，我们没有很好的预测未来的方法，需要通过各种业务配置（不定期更新）业务核心监控和订阅规则告警，以及日常值班业务舆情观察用户反馈的信息。配置订阅监控、告警、舆情等稳定反馈渠道。对于手机淘宝等流量巨大的产品，底层数据的量级也比较大。通过2020年7-12月基层链路组的日常工作，从维稳执勤实践来看，我每天去Crash平台、舆情平台、告警记录都比较仔细的翻阅，花费了一个以人手计算平均40分钟至1小时；如果有疑似问题，检查并排除。这是另一个时间；因此，在日常线上问题的发现中，重点在于提高问题发现的效率。发现效率的提升是为了提高日常值班效率；所以，对于Crash，除了订阅我们负责的业务模块外，最好也订阅我们业务所依赖的模块，然后通过排名和环比增长快速突出。快速变化的记录；舆情方面，通过一段时间的正负样本标注训练，对技术舆情进行过滤，同时对舆情图片进行OCR和关键词，区分舆情与业务的相关性；在告警方面，目前很多告警都是基于阈值触发的，但是如果线上有促销活动，基于阈值的告警会导致误报频繁，所以基于时序算法的趋势告警更加准确。2、低流量下问题主动发现率对于用户量比较大的移动互联网产品，灰度没有变化，这是大家逐渐建立起来的安全生产意识；小流量下的变化，对于产品端，可以收集用户端的点击、转化等数据，分析小规模用户对新功能的接受程度，作为改进产品/运营策略或上线的辅助依据/全量；对于开发和测试，通过小规模的流量，可以初步验证小范围内不同用户设备上代码变更的稳定性。如果有问题，会很快修复。如果没有问题，将扩大规模。无论是产品/运营还是开发/测试，在小流量下观察这部分用户反馈数据，单靠唯一的灰度版本号是无法真正从全球数据市场圈出这部分数据的；因为大量推送10W并不一定意味着推送的用户已经看到/走到了你改的新功能的那部分！因此，为了知道新特性在用户端是否真的可用，端侧需要给特性“上色”使其生效。同时，在新功能的实际曝光期，我们在应用的Crash报告、舆情反馈报告、监控埋点报告等环节打上了这个独特的着色标记；这种独特的染料标记可以清理新功能在用户设备上生效时产生的各种用户反馈数据。作为一个多业务模块的用户产品，多团队协作、并行变更是常态。一个版本的一段时间内，可能不止一个业务发生大规模的变化。比如一个Crash报告，如何区分是哪个业务变更引起的？很难快速判断划分，所以我们将当前生效的特征的颜色标记用于更改。当changecoloring下的Crash数据被清理后，这个Crash会出现在多个change中。在观察到的Crash列表中，确保没有遗漏任何在线问题；其他稳定染色数据的报告和清理遵循相同的规则。通过对变化特征实际作用下的多个稳定性指标的数据进行精准清洗和染色的手段，我们只能在小流量增加量逐渐增加的过程中看变化影响下的数据体积;如果没有这种手段，由于小流量引起的问题所占比例相对较小，以市场上的海量数据为分母，甚至不会出现涟漪。当大范围甚至全量放出时，问题就暴露的很明显，之前的小范围问题可能已经变成大范围的故障了。它能解决什么问题？上述日常在线问题发现效率和变更中问题的主动发现率，如果业务团队付出了行动和努力，并进行了值班观察和变更染色接入，对于业务团队来说，可以取得成就。商科学生的安全焦虑在线上能在多大程度上得到解决？这其实要看我们做了这两件事深层次解决了什么问题？1、变被动为主动根据集团安全生产要求，线上问题要求5分钟响应，15分钟定位，60分钟解决。从这个目标来看，我们也希望研究生能够尽快响应和解决线上问题，越早解决线下问题，商科学生就会越积极。在日常值班业务方面，根据基础链路客户端团队2-3月的实践经验，每天轮流花15分钟到半小时进行线上稳定性检查，可以大大缩短问题的暴露时间时间长，提高了在线问题的响应效率。在问题影响变大之前，通过前后端业务切换、降级方案、热修复等方式，可以快速解决巡检中发现的大部分问题。在灰度变化大监控方面，通过2021年基础环节部分重点项目的对接，业务切换平台的灰度发布监控效果可见一斑。在变更发布的小流量灰度期，有效捕获有效的业务/技术问题。这些问题都是在小流量验证下发现的，通过服务器和重载平台的流量回滚，避免了问题的暴露和扩散。与日常值班检查相比，算是真正意义上的主动发现问题。2.减少问题的爆炸半径。在线问题对用户的影响可以从三个维度来衡量。三个维度的叠加决定了问题实际的“爆炸半径”：问题持续时间：问题从发生到恢复的总体持续时间对用户使用的影响，大致可以分为几个等级：阻断不可用（闪退，核心功能不可用），部分不可用，轻微不可用，不影响日常业务巡检值班可以缩短发现线上问题的时间，减少持续时间问题;对不断变化的灰度级进行重型监控，可以尽早发现问题并控制受影响设备的数量，降低问题的影响和问题的严重性；无线运维关注日常和变化的场景，可以有效控制和减少问题的爆炸半径；你将来想解决什么问题？目前无线运维已于今年探索建设并上线。刚刚过去的2021年，在满足日常业务和变化下对线上稳定需求的过程中，我们深感自己还处于早期阶段。监控，但目前商科学生仍需投入大量人力工作量；商科学生在这个过程中也提出了更高的要求，希望实现业务变更发布阶段的过程，业务Top舆情场景诊断和报警智能化，从安全生产的角度，能够阻断那些质量变更发布不符合标准。1、分阶段发布当前的业务变化，多通过业务切换、群选，或者像一秀这样的大型平台。通过不断扩展，不断观察，直到业务满员；这个过程可能会持续好几个对于研究生来说，有足够的时间来保证上网的稳定性。对于产品运营同学来说，全面铺开业务效率太低；从小到大的分阶段发布过程。每个阶段验证无误后，可以快速流向下一阶段；内网白名单：业务生产研发测试，上下游团队和TL，内部经验优先；内网灰度：群内网有很多热心同学积极反馈问题，可以反馈很多产品体验和功能bug。他们能够掩盖他们家庭的丑陋。外网人群：产品运营圈选出的第一波用户，观察用户数据反馈，研究并关注外网用户在线稳定性问题外网分批灰度：增量分批增加灰度，业务&体验&稳定性综合验证外网全量：完成多次灰度验证，停止换色，业务量全2.智能诊断日常我们有监控观察等机制对线上问题进行排查，改变线上问题，但有时需要耗时确认问题是否是需要处理的问题；有些问题不通过Crash，可以发现埋点的监控告警。比如很多页面组件缺失导致业务拥堵的问题，都是通过舆论反映出来的；如果问题的确认、分析和诊断都靠群体调查，效率低下。通过标准化算法的引入是一种更好的辅助方法；定义完善业务日志规范，为日志可视化打下良好基础，建立全链路调查体系；覆盖业务阻断/阻断舆情场景，结合用户日志、埋点智能分析诊断；崩溃/告警，从基于阈值触发升级为基于时序算法的趋势智能告警；但目前批次放行的综合质量是否符合安全生产要求还没有给出详细的定论，更多的还是要靠研测同学自己判断和决策；因此，在发布过程中，对每批次做好卡口，帮助研究生分析评估是否可以进入下一阶段的发布，从而有更高效、更安全的体感。线性增量发布：比如业务切换，补丁，大规模线性增量，全面时间周期比较短。每增加一个增量，都要综合检查染色数据和灰度标准的指标。对于不符合灰度标准或染色数据指标异常的，应及时提示卡住；往复式释放：如易秀，服务器端自定义规则增加音量，多个分支的流量可以自由调配或随时回滚，音量周期比较长，不同流量配置覆盖验证时，应该还要注意对在线命中用户稳定性的影响。对于异常的实验分支，应及时提示卡住；
