业务梳理与故障分析，看网深科技如何保障用户业务

关于某港口

        某港口是国家重要的战略资源，是京津冀及“三北”地区的海上门户、雄安新区主要出海口，是“一带一路 ”的海陆交汇点 、新亚欧大陆桥经济走廊的重要节点和服务全面对外开放的国际枢纽港 ，连续多年跻身世界港口前十强。

分析背景

        该港口的疫情通行卡系统，为港口货运车辆司机提供通行安全保障。司机通过手机上传核酸报告才能顺利通过港口。近期凌晨时段总是会出现上传时间过长或无法上传现象。

故障描述

        IT人员怀疑是上传核酸报告接口出现了问题，但通过网深科技流量分析系统分析，确认并非该接口出现问题。

本次进一步分析该故障原因。

业务流程梳理

        在进行详细分析前，需要先了解疫情通行卡系统的网络结构和连接关系，这样就可以精确采集数据，提高故障分析效率和准确性。

        一般情况下，用户可能提供的粗略的业务调用情况和网络连接信息，而精确的业务流程，需要借助网深科技分析系统精确识别和梳理。

        通过多个交换设备的数据采集，整理做出详尽的流程图（其中红色线区域是NetInside分析中新发现的），如下图。

        将实际调用流程拓扑结果发给客户，得到客户的认可和赞许，他们感慨Netinside系统的强大功能，帮助他们完整的梳理了复杂的系统调用过程。

故障分析

        本次故障分析，通过实地操作客户端小程序，进行疫情防疫卡上传操作，对图片上传接口行为和性能进行监测与分析。

    分析环境

        操作时间：2022年9月8日星期四，凌晨3点40左右

        操作内容：在某小程序疫情通勤卡，上传一张7M左右的图片

        动机：分析整个操作过程的延时分布情况，试图发现异常

        上传环境：普通100M共享家庭网络

    详细分析过程

        本次分析依据抓包文件进行分析。

        图片上传时间分析

        图片上传从frame 28开始。数据包最大长度为1466字节。

        图片上传到frame 11591结束，时长共计6.85秒。

        图片上传完成与回显之间的延时分析

        图片上传完成后，从frame 11593之后，到图片回显期间，都是小程序自动维护信息传输的信息。

        这里视为空闲时间，或等待时间。

         空闲等待时间，到frame 11625，共计时长160.27秒。

         从应用程序操作来看，在上传图片时，显示“上传中…”字样的等待界面时间，主要是这一部分时间。

        图片回显时间分析

        图片回显数据包传输从frame 11625开始。

         图片回显数据传输到frame 22942结束，共计时长4.5秒。

        报文传输长度1347+219字节成对模式出现。

    分析结论 

        本次上传操作成功。

        通勤卡上传动作由2部分组成，图片上传 + 图片回显。

        对于一张7M左右的图片：图片上传时间为6.85秒，图片回显时间为4.51秒，图片上传完成到图片回显之间的时间长度为160.27秒（超过2分钟），即空闲等待时间长为160秒，整个操作完成时间约为171.6秒。

        由上看到，图片上传时长约3分钟，时间最长的地方在中间等待时段，约160秒左右。

        特征发现，图片上传时，每一个报文最大传输大小为协商一致的1412（数据包长度为1466字节）；图片回显时，出现成对的1347和219字节长度报文传输行为，传输效率低下。

结语

        通过本次监测分析，用户认识到上传图片的性能问题，计划对防疫通行卡的上传接口进行优化改进。

        而导致故障的真正原因，则是由于安装在服务器上的安全终端防护程序，在凌晨3点左右自启动，占用CPU过高导致系统出现偶发的上传图片异常。

        本案例根据实际需求，通过使用业界领先的NetInside产品，对关键网络链路、关键网络节点、负载均衡设备、业务集中系统群的通信情况进行自动化发现，并对这些系统在网络中的运行状态进行实时监控、分析和告警。

        NetInside从设计之初，并非定位于单纯的网络运维分析工具，而是集管理、运维与优化于一体，面向大数据的数据系统。NetInside将不断以优异的技术及产品、最佳的解决方案，为用户提供完善、先进、高效、安全的服务。