zoukankan      html  css  js  c++  java
  • 严选电子面单稳定性治理实践

    稳定性治理是系统演进过程中一个不容忽视的重要命题,这个命题往往需要持续性的投入,如何让持续性的治理工作有目标、过程可跟进、结果能检验?本文结合严选供应链技术团队在稳定性治理上的实践,对治理工作中的可用性、监控告警和线上应急三个方面做了一些思考与总结。

    1. 什么是稳定性治理

    稳定性治理是个比较复杂的命题,业界没有统一的定义。系统「稳定性」是指系统要素在外界影响下表现出的某种稳定状态,但事实上,复杂系统中潜伏着大量影响稳定状态的故障组合,那么「稳定性治理」的核心用一个词来概括的话,“故障管理”应该比较合适,故障管理领域下面细分为故障防范、故障感知、故障触达、故障止损和故障复盘5个子领域。稳定性治理的主要工作范围涵盖了可用性、监控告警以及线上应急。

    接下来以严选电子面单服务的稳定性专项治理为例,进一步说明在服务器仓库部署 和外部服务商等不可控因素下如何保障稳定性。

    2. 严选电子面单介绍

    严选电子面单亦称为一体化面单或者标准化面单,是指严选配送中心提供一整套可以适配所有仓库的面单服务,包括面单生成、面单打印、面单管理、服务监控等功能,是供应链环节赋能的基础产品和服务。

    电子面单服务由于特殊的项目条件和历史包袱,发展至今仍存在一些痛点问题,例如:

    • 定位问题比较

    面单打印发生异常时,需要联系仓库服务商提供日志用于定位问题,受响应时间和配合程度影响,解决异常的耗时往往被拉长。

    • 面单生产感知

    严选侧不了解仓内生产面单的状态(是否打印、是否分包、打印成功/失败等状态),对履约链路中重要一环缺少数据信息。

    • 整体流程监控

    对仓内生产操作没有整体的可视化监控界面和预警,面单服务中的异常无法及时感知。

    • 面单打印反馈

    仓内操作人员反馈打印慢时,无法准确了解打印耗时、打印机、主机等数据信息。

    • 安全性信任度

    电子面单服务中的面单打印SDK是嵌入仓库服务商的仓库管理系统(WMS),因此安全性备受关注。

    3. 稳定性治理整体思路

    3.1 整体策略与方向

    有了痛点就有具体的策略和实施,实施策略覆盖了事前、事中和事后3个阶段,且形成了闭环。

    (1)故障防范:如果新系统从设计、实现到运营就充分考虑稳定性,例如采用防御性设计,规范化操作和标准化运营等,一般能规避大部分故障风险。但对于存在历史包袱的老系统来说,除了服务治理和优化外,还可以借助生产环境的定期演练来发现系统「稳定性」「鲁棒性」「自动恢复性」上的问题。此外,与外部系统交互的过程中,服务安全性是容易被忽略但却是影响稳定性的重要因素之一。

    (2)故障感知:除了对常规的「系统数据」「应用数据」收集外,还需要感知和识别生产过程中的异常,从而需要进一步收集生产环境的「业务数据」

    (3)故障触达:基于第二环节故障感知的数据基础上,建立相应的机器监控,应用监控和业务监控,最终实现「监控分层」「告警互补」,通过监控告警来触达相应的技术人员、运维人员和业务人员,从而达到快速感知异常、快速辅助定位的效果。

    (4)故障止损:前三个环节可以理解为事前操作,那么此环节是故障发生时应该第一时间采取的动作,需要沉淀一整套验证过的故障响应预案,覆盖可能出现故障的「核心场景」「定位方法」「应对策略」,最终达到能应急响应、故障定位和快速恢复。

    (5)故障复盘:这一环节属于事后操作了,复盘源于围棋术语,故障复盘与围棋对局后的复演相似,都是检查对局中招法的优劣与得失,让出现过的故障处于「发展可控」「范围收敛」的状态,同时从出现的故障中提炼出一些流程和经验,以避免后续出现同样或同类的故障。

    基于上述的闭环策略,稳定性专项治理实施的主要范围包含「可用性」「监控告警」「线上应急」三大块,发力的方向是达到「可预防」「可感知」「可快速处理」

    3.2 案例实施与分析

    3.2.1 可用性建设

    电子面单服务专项治理在可用性上的主要工作分为三个方面:「服务治理」「动态演练」「安全升级」

    (1)服务治理从服务本身和上下游关系出发

    在服务上下游关系上需要完成强弱依赖接口的治理,首先梳理出依赖关系、流量大小以及依赖强弱,在此基础上去除没有必要或者不合理的依赖,同时把一些不影响业务核心功能的依赖变成弱依赖,建立合理的系统拓扑。强弱依赖治理的成果可以应用于系统改造、性能优化、限流降级、故障定位、容量评估等场景。

    服务本身性能优化是一个持续的过程,也是提供服务方和服务使用方共同优化的过程,常见的技术手段包括业务场景的合理兜底、利用缓存提高系统的吞吐率,慢SQL治理,线程池调优、异步削峰、历史数据的定时备份和清理、打印流程优化等等。

    (2)生产环境的动态演练常态化

    动态演练可以理解为消防演习,是验证故障应对措施的有力手段。我们建立了生产环境的定期动态演练计划,覆盖的维度从面单服务单台机器故障、单条链路故障到整个面单服务故障的演练。

    (3)服务安全升级及认证

    由于电子面单服务中的一部分是嵌入仓库服务商的仓库管理系统(WMS)中使用,因此安全性受到严选和服务商的共同关注。在电子面单服务安全的建设上,我们先后完成了两个方面的工作:

    一方面我们完善了面单服务的鉴权校验,以及面单相关的敏感信息(商品信息、收件人信息等)隔离和隐私化;

    另外一方面是联合第三方部门完成面单打印SDK的安全测试,获得服务商的认可,也方便后续的推广和使用。

    3.2.2 监控告警建设

    监控告警的建设目标是完善监控能力和有效告警触达,而建设的过程中实现监控分层是为了能达到有效监控和报警互补的效果,同时监控分层能促进每个层次监控的深度和覆盖面,防止建设失控。

    在电子面单服务的监控告警建设上,我们分为两步走,第一步完成了关键信息的远程实时收集,覆盖的范围包括系统层面、应用层面、业务层面的数据。

     基于第一步的结构化和非结构化的数据基础,完善了面单服务链路的监控,包括仓内服务器监控,仓内生产监控,面单打印监控。

    3.2.3 线上应急建设

            线上应急是故障发生时的行动指南,能有效降低故障定位和止损的时间,提升团队内外的协作效率。在电子面单服务的线上应急建设上,我们准备了三板斧:「场景」「工具」「预案」

    (1)关于场景,首先是对核心系统的核心链路进行梳理,然后完成核心链路的日志治理,最后对常见的单个异常场景和紧急批量异常场景进行分别梳理。

    (2)关于工具,需要借力现有的成熟工具,比如严选预案平台、严选压测平台、运维工具等,应用于全链路性能测试和异常场景处理,同时充分考虑外部依赖的不可控因素,建立相应的服务商紧急沟通群。

    (3)关于预案,针对高频的单个异常,建立常规的处理SOP,从技术、产品和业务角度考虑优化或者工具化;针对批量异常场景,建立上下游团队紧急处理和协作机制;最后采用定期的动态演练来验证预案的可执行性和有效性,从而形成预案产出、验证、优化的正向闭环。

    4. 稳定性思考与拓展

    稳定性治理的思考准备从两个角度来谈,一个角度是从稳定性治理的人出发,关键词是「阶段工作」「角色转变」;另外一个角度是从稳定性工作本身出发,关键词是「持久战」

    对于稳定性治理的人来说,稳定性治理可以看成是由众多阶段性工作组成,随着治理的过程,治理的人逐渐发生角色上的转变。一开始我们都是被动方,被动的接收问题和处理问题;后来我们开始考虑主动做些什么,能够主动挑战和测试核心链路,比如定期的梳理,动态演练和压测;随着治理经验的积累和落地,我们都会在下一个新的场景和故事里转变成前置主动方。

    对于稳定性工作本身来说,稳定性工作不仅仅是大促时的保障和平时的稳定性轮值,而应该是有目标、过程可跟进、结果能检验的体系化工作。稳定性治理是稳定性工作中的较为复杂的部分,不是某个时间点的某个动作就能彻底完成,而是一场很硬的持久战,这里面既包含历史包袱,又有新的问题场景,现有的很多系统均会逐步经历原始阶段、部分具备、基本覆盖、能力完善以及全面提升的阶段,当前严选电子面单服务的稳定性治理正处于基本覆盖到能力完善阶段,除了这个服务外,有很多系统都将在这段进程中被推动着前进。

    作者简介

    东晨雨,高级服务端研发工程师,参与严选供应链仓配系统建设,目前主要负责快递配送业务、干线物流业务以及仓储相关业务,致力于为严选用户提供优质的物流服务。

  • 相关阅读:
    黑盒测试和白盒测试的区别
    alpha测试和beta测试的区别
    selenium退出语句区别
    QTP8.2--安装流程
    Xshell无法连接Linux虚拟机问题
    Linux-----centos6.2---安装Linux的流程
    MySql错误处理--错误代码和消息
    基于Linux系统--web环境搭建
    前端底层-作用域 this 原型笔试题练习
    前端底层-冒泡与捕获
  • 原文地址:https://www.cnblogs.com/purple5252/p/14420655.html
Copyright © 2011-2022 走看看