如题，运维人员最不想收到的是什么呢？
答案就在下面这两个BPC的排障案例里，这就开始去寻找吧。
案例一 某农商行
互联网前端系统故障
故障描述：
某日11:46开始，行内互联网前端系统指标出现异常，业务响应时间急剧上涨，最高时达到2500多毫秒，是平日的20多倍；在业务指标异常期间，响应率不断下跌。
故障分析：
Step1：在响应时间、响应率等多个指标异常波动的起始阶段，BPC已经将告警指标在前台展示并通过短信平台通知对应系统负责人；
Step2：随即，负责人在BPC平台点击分析按钮，系统自动通过多维分析方式进行数据钻取和分析，发现其中交易类型为「http.do」的交易响应时间达到6300ms以上，且影响比例高达99.98%；
Step3：通过BPC前台多维统计模块，选择告警的时间点按交易类型统计并按照响应时间大小进行排序，发现「http.do」交易在交易量占比很高的情况下平均响应时间达到了4200ms以上，由此可以判定该交易影响了整体的响应时间导致触发告警；
Step4：随后BPC负责人与应用负责人一起对「http.do」交易展开排查，发现此交易存在大量的并发，导致端口拥堵以致服务器整体响应时间大幅增长。由于BPC告警及时并且定位准确，协助应用负责人短时间内找到问题根源并对应用进行重启操作，业务系统恢复正常。同时，负责人继续在BPC平台钻取交易明细进行细节分析和定位。
案例二 某大型国有银行
电子银行服务总线系统故障
故障描述：
某日10:12，值班人员手机收到行内集中监控的告警短信通知，显示电子银行服务总线响应率低于阀值，持续3分钟。
值班人员登录天旦业务性能管理平台BPC后，发现电子银行服务总线系统的某个节点响应率连续告警多次。
故障分析：
Step1：值班人员通过天旦业务性能管理平台BPC对异常波动分析发现电子银行服务总线系统在这个时间点出现响应时间大幅增长，响应率明显下降；
Step2：值班人员在天旦业务性能管理平台BPC上通过多维统计的分析方式进行数据钻取和进一步分析发现，某分行的响应率明显偏低，再下钻分析，发现交易码3367和3365两支交易的响应率明显偏低；
Step3：
定位到出问题的具体分行和交易后，值班人员联系电子银行服务总线应用系统的负责人员，进入系统查看和处理该问题。
好啦，案例讲完了，你找到答案了吗？
答案就是：短信！
因为每次系统故障，BPC都会在第一时间通过短信通知对应系统负责人。所以对于他们而言，没消息就是好消息。
据中国银联统计，1月24日-1月30日，银联网络支付交易增长较快，同比增长46.79%。同时，银联移动支付业务交易增长，云闪付APP交易笔数较去年同期提升23%。受疫情影响，手机银行、网上银行访问量增长明显，成为关键业务途径之一。由此，也给相关运维工作带来了挑战。
而我们之所以能够安心在家娱乐、购物、工作、投资，离不开银行、证券、电商、电信等各行各业运维人员的坚守岗位。他们不像医生、警察，甚至外卖、快递小哥，经常出现在我们眼前，但没有他们的付出，我们「足不出户」的生活如何得以有声有色地坚持到现在。在此，旦旦想向所有运维一线的伙伴们道一声：辛苦啦！
