生产环境全链路压测建设历程 21：某快递 A 股上市公司的生产压测案例之彩蛋 2 前言

上一篇是《生产环境全链路压测建设历程 20：某快递 A 股上市公司的生产压测案例之彩蛋1》



D公司在生产环境实施了全链路压测后，具备了对性能问题主动出击的“核能力"，性能问题导致的系统不可用（故障)时长大幅收敛。甚至在2019年双十一期间，性能问题引发的系统不可用时长为0。



但，D公司的业务系统已经超过了100多套（加起来有近300个API），各个系统加起来，大概是一天50个版本要进行发布，核心业务版本一个月差不多有400-500个版本。



在这样一个大规模团队、系统也非常复杂的情况下，平常流量不算太大的情况下，仍然存在了以下痛点：



1.对系统问题后知后觉：近300多个API，只能做只读的拨测监控，但对于写操作等API，只能等用户操作出错后，依赖APM等被动式、事后式的发现，有几百个监控点。



2.协同难，单个角色难以从全局去看问题所在： 监控团队主要是从PaaS、IaaS层面去进行监控。

业务人员在使用系统出现问题后，在系统功能无法正常服务的时候，只能干等。

开发团队人员对自己的业务很了解，但在排查PaaS和IaaS层面的问题，也要不断靠猜测。

而监控团队和业务团队的人员，要联动起来排查问题，还是比较困难的。有时候熟悉系统的人在开会，而做监控值班的人也往往不太懂得如何排查。



3.排查时间长，对业务影响大：当出现系统问题后，往往需要联动业务人员、监控中心、业务团队、中间件运维团队、DBA、应用运维团队、测试团队来排查问题，光是信息同步就起码要起码10-15分钟。



4.每次发版本后，功能可用性回归时间长。需要近十个测试人员不断的做可用性回归，需要的人力和时间长。