案例 | 小鹏汽车运维监控是如何落地实现的？

本文整理自李晓凯在2020Zabbix中国峰会的演讲，ppt获取请联系小Z。更多演讲视频可关注官方Bilibili账号主页（ID：Zabbix中国）。

  一  网联 - 移动网络稳定性挑战  

由于跟普通传统的互联网公司不太一样，小鹏汽车在整个车联网有较多的挑战。比如说在车机方面要脱离传统互联网的思维和定论，本身整个车机更像是定位的大监控平台，在产品设计之初，运维就已经开始入手了。汽车研发过程中就会参与到汽车信号、4G信号的稳定性，比如说电磁干扰、基站的信号通信等，会考虑更前一点深入到业务稳定性的测试过程，比如说路测，基站的通信信号对于车速会不会有什么影响，都做了详细的收集以及分析。

而且收集这些数据后，推动相应的部门进行优化，比如说汽车天线在什么位置上会比较好？当前这个位置对于信号影响会不会有什么问题？对车机系统也会有一个深入的监控，比如说当时导航以及语音助手是否好用？比如说用户在使用的时候，呼唤你好小P，它是否马上就可以响应出来？是否能精准识别用户的语音，同时支持用户能做到实时的反馈结果，服务器是否稳定，这都是之前做监控的挑战，而且都成功的把它实现了。

在整个监控方向，更前一步、更面向业务，这是整个小鹏汽车运维的理念，运维应该更接近业务，做的监控也更应该接近业务，而不是单纯在运维做闭环，而是要形成一个完整的闭环。

这是应用到小鹏汽车上的车联网网络。车联网网络在国内就是几个出口，它跟咱们本地使用手机不是一样的，出口是在国内的几个节点，是固定的，内部会分为几个通道，不同的通道会有不同通道承载着不同的服务。

• 第一个通道，是承载娱乐服务，一般是抖音、爱奇艺。

• 第二个通道是系统通道，由于跟阿里云服务器交互，下发指令，访问后端服务的关键服务。

• 第三个是加密的通道，车控的通道，比如说大家用手机开启它的空调、开车门。每个通道的应用方式是不同的，而且会着重优化车控的通道以及跟服务之间通信的通道。

根据统计，后端的实际车控的可用率是在99%以上，必须有个硬指标，要求用户点击手机之后他的空调能正常打开是要达到这个数值才符合最初的设定。但是在于这种物联网的情况下，在整个车联网、车控是基于MQTT协议来服务的。MQTT协议在物联网是非常常见的协议，通过MQTT还能看到当时在这个时间段或者全天这个车辆会是一个什么样的在线情况？它的连接是一个什么样的情况？

当然这个东西是脱敏的，完全不知道这个用户是谁，只知道这个时间段是有哪些车在线的。但是会在0点的时候，可能运营商会有切割，会比较常见，可能会遇到突然有这种波峰突然下坠或者是突然这种不稳定的情况，这个时候通过监测MQTT的连接数，就知道在某个区域或者某个地方的运营商的网络是存在问题的，我们会主动去推运营商。这种车联网公司跟传统互联网公司有一个比较大的区别，就是直接对的是运营商。比如手机APP开发出来之后，他们不需要太考虑网络和运营商的沟通，但是我们头痛的点需要推全国各地的运营商来帮定位、排查对应的问题，帮解决问题。 

举个例子之前有个用户在海南 打电话过来，我的车在这个地方没有4G信号了是什么情况？当时监测着MQTT的时候，连接数发现在海南的部分区域确实是有些用户的车辆是不正常的，它的连接数也是连不上来的，一开始定位是T-box，或者说就是车机的一个路由器，或者说车机的联网的东西是否有存在问题？定位之后发现这个问题更多是在运营商一侧，所以说还会去推动运营商来帮解决这些问题。

这是内部的地厅系统，会收集内部有不同的产品线，比如说有租车和出行的业务部，会下发一些特定的探针到这些车上去收集这个车当时的基站的网络信号是什么样的情况？他的车速是什么样一个情况？对线上的一些服务进行模拟探测，类似于APM那样的方式。模拟本地应用去执行它整个的基站的使用情况是什么样的？来达到监测的服务是否正常以及对应的区域。如果监测到比如说某个区域它那个点是红色的，就说明它那个区域的基站是有问题的，或者说信号是不好的。如果发现用户在这个区域反馈他的问题的时候，通知客服就会预判，告诉他这个地方的基站是不正常的，或者说你这个位置是不良的，所以说会导致你当前网络是不正常的。

其实运维会跟两条线，一条是产品线，一条是客户线，都会密切的进行配合，这就是我说的目前整个的一个通道，就是会有OTA整车的产品系统升级以及娱乐通道、以及车控，都是基于下面T-box，通过APN通道去连接到的服务，这个是在互联网汽车行业上是比较常见的一个方案，大家都是这样用。

  二  监控 - 小鹏汽车的落地与实践  

这是整个运维基础监控的平台界面，首先是要做到一个覆盖度广，对于关键业务，内部是要求100%覆盖，对于核心业务也有指标，对于每天的报警统计，都会有对应的运维监控团队输出当天的运维报表。

小鹏汽车在监控方面参考了行业内比较专业的工具，进行二次开发打造成符合自己公司的产品，因为小鹏汽车本身是物联网企业，大家常用的一些监控东西不能完全覆盖到公司的产品，所以说要进行一些整合改进。当然最优秀的产品是Zabbix，吸取了Zabbix很多的经验和功能点。但是Zabbix本身是一个基于服务器维度的监控。但是它对业务覆盖不是非常足，所以说做了补充，开发这个产品来符合自己公司的应用。

为了深入业务，提供给业务自定义扩展的接口和推送，他们直接调用统一的模板，就可以直接把它的报警策略推到系统上，只要按照的规范就会形成这样操作。比如拨测、检查，这些系统直接接收到它推送后进行识别，自动形成模板，同时也支持手动的自定义。

有一套整体的日志分析系统，因为车机上会带来大量的日志，比如说本身的 modern日志、大屏日志、应用日志，但是因为用的是全套的阿里云系统，所以会把这些日志都上报到阿里云的日志中心进行统一分析，通过日志来进行自定义的监控并进行处理。

针对之前的业务、流量的定义，拨测做逻辑性的判断来形成一定的告警推送，把这些推送给对应的业务人员，比如进程数、网络的流量等，根据之前的一些策略实施告警下发。

这一块分业务监控跟基础监控两个方向，一个方向是整个看当前业务健康性以及一些服务器的基本信息，比如内存、硬盘还有网络它本身的承载性。因为小鹏汽车大部分服务都承载在微服务上，整个有一套微服务的体系。但是有动态扩容，要监测本身的服务器的空间是否允许进行动态扩容。所以说会有两套，一个是监控它的业务是否正常，比如上面的语音，另外一方面要监控承载这些服务器的容量、资源是否够用。

所有的告警都是在推到的告警集中系统，在系统进行处理之后，通过钉钉或者是电话的方式来实时的发送给各位工作人员，他们是通过订阅的方式来获取自己需要的告警。因为公司的人员变动或者 说部门调整会比较多，所以还会根据组织架构方式来设置这个告警会推给谁。

同样，我们的告警在内部是会分为几个级别，最高级就是P1级，然后P2、P3这种等级，这种P2级以上，不管任何时候都会打到对应的人的电话，要求第一时间进行处理。有对应的NOC团队跟进整个对应的告警流程，形成一个工单，这个问题是什么时候发现的？第一时间联系了谁？哪些人在什么时间点上线？上线的时候大概什么时间内判断是什么样的一个问题？这个问题在什么时候谁来跟进？形成一个工单进行交互，每天完成之后会有一个对应的交接，把这些东西进行处理。

以上是我的分享，谢谢大家。