日常工作中，我们可能会经常遇到如下情况：
领导老板们在群里夺命连环call
伴随社会突发事件，服务流量也会随着热点一路狂飙，导致各种不可预期的问题
随着业务年代久远、服务越来越复杂，业务之间调用关系错综复杂，没有一个人可以对业务了如指掌。
2020年之前，团队每当遇到如上问题的时候，大家经常是心头一震，心里发慌。wocou！发生了什么。要是已经下班或正在休假，还得掏出电脑，在经过没有预期的尝试与排查后，给领导一个故障范围和问题原因，有时也只能定位到大概范围。甚至会出现「莫名其妙坏了，莫名其妙好了 」的尴尬局面，事后很难复现。
大部分故障与问题都是用户投诉或老板@才发现。问题发现后，不能快速定位问题，不能做到及时只损。以微博会员20年临时头像的故障为例，故障从反馈到最后临时解决，花费了将近2个小时。这是微博会员团队近2年来最严重的故障。最后确定故障根因是MC存在热点大Key，导致带宽打满，最终影响了用户使用。
同时微博会员是一个成立了近10年的业务团队。人员与业务分分合合，依赖关系错综复杂。没哪个人能完整知道所有服务的链路细节，新人上手难。20年团队也在做各种变动，基础服务升级重构、PHP版本升级、Go语言技术栈转型、服务全面拥抱k8s等等。频繁的变动也就意味着会滋生新的问题，新问题难免会隐藏、无法被及时发现。
这一年，团队痛定思痛。我们都希望能有更趁手的工具，让开发人员更关注开发本身。希望90%的问题能通过报警主动发现而非用户反馈。希望问题从发现到定位耗时缩短至15-30分钟，缩短MTTR。希望服务RT降低30%。
正因如此，也就有了本文。
会员团队服务质量保障的发展历史我大概分为了三个阶段。
如上图所示，ELK+Grafana的方案基本已经成了事实标准一样的存在。尤其对于中小团队或者研发成本不是非常充裕的公司来说（研发成本宽裕的公司都有自研的方案，暂不做讨论）。微博的各团队基本也都是这套方案或这套方案的变种。
这套方案本身没什么问题，但由于微博内部业务方众多，互不相通。不少团队都自行维护了一套自己的ELK+Grafana。由于没有统一调控，各自数据模型不统一，数据互相之间像是一座座孤岛。
每次排查问题要需要打开N个Grafana Dashboard，还要在每个Dashbord中一个条件一个条件的筛选。时间就这样一点点流逝了。下游依赖报警相互独立。若是碰上服务异常的连锁反应，完全无法判断是先有鸡还是先有蛋，告警反倒成了拖累。监控覆盖度不足，监控体系不统一，都是需要解决的问题。
有问题就要解决问题。监控覆盖度提高，快速定位性能瓶颈，成为了当时首要解决的目标。经过调研与权衡，最终我们决定引入APM工具—https://github.com/apache/skywalking。SkyWalking与其他APM工具相比，功能对PHP兼容相对完善，接入无需代码侵入，社区活跃度高。