笔者最近经历了一起生产系统线上问题处置、排查的过程，因为涉及业务应用、大数据平台、操作系统、硬件、厂商、网络几个团队，在寻找根本问题的过程中虽然费劲了心力，但仍得不到令人满意的结论，本文将相关过程记录下来并尝试分析深层次的问题和解决办法。

排查始末

有一个总容量在1PB左右的ES集群，周六早上的时候监控发现集群的写入性能下降明显，大量的业务数据已经开始排队等待写入产生了堆积。整个集群设备数量有50多台，ES节点数量有200多个。首先是应用运维的同事收到业务告警开始排查，同时也联系了大数据负责ES的同事协助排查。

当时，从集群的健康度和节点状态上看，整个集群还是 Green 状态，没有发生某个ES节点的重启。集群的写入也并非完全停止，排查ES集群的慢查询语句也并没有发现大量的查询，排除因为大量查询引起的集群性能下降。

在这期间，分别联系了网络、环境、操作系统领域的同事分别检查是否有相关的故障信息。网络领域排查网络上没问题，但是观察到某些设备有网络流入流量的突增和突降。环境领域排查服务器硬件层面没有告警。操作系统领域通过 iostat、sar 等命令检查，认为当时磁盘高的现象都是应用正常使用导致，操作系统层面并无异常。

因为应用运维人员没有ES集群的全部权限，不能查看ES日志，后续的排查更多的以大数据的同事为主，大概花了40多分钟后定位到集群中有两台服务器的写入任务堆积比较多，同时发现这两台设备的磁盘写入速度不高，但是 util 使用率几乎被打满，怀疑是磁盘故障，决定对这两台机器进行隔离处置。

隔离处置的操作很快，但是因为这些服务器中数据量比较大，大数据服务器单台20T空间，使用率均在70%以上，数据迁移用了很长时间，大概花了2个多小时，整个集群最后恢复到了正常状态。

问题定位

生产的故障已经解除，最后对于问题定位有了困难。大数据团队认为是磁盘有问题，慢盘影响和拖累了整个集群。

而环境团队认为磁盘硬件上并无明显报错，一致性校验任务也是一个固定的检查动作，需要上层应用分析为何应用会受到影响。环境团队答复一致性校验是在操作系统中配置的任务，可以根据应用需求进行调整。

我们作为应用运维团队，真是左右为难，根本原因没有一方愿意承担，后续措施不好具体落实，如何推进系统的安全稳定运行?

深层问题

因为笔者所在单位对于线上生产问题的处理和考核非常严格，这就造成了「铁路警察，各管一段」的情况。环境团队觉得磁盘一致性校验是提供了多个选项的服务，具体使用由上层来控制。大数据团队觉得基础设施的性能变化影响了应用，应该由基础设施来提供优化解决措施。

这种场景，如果对于管理模式为竖井式的团队来说，从基础设施到上层应用都由一个团队负责，则很容易达成问题点和优化的措施，推进起来就比较困难。

而我所在单位为了推进专业化分工，采用了按领域划分的管理模式，这就提高了问题解决的沟通协调成本。其实在日常运维工作领域，有非常多的类似冲突每天在不断上演，例如老旧设备到期到底是应用周转搬迁，还是基础设施满足应用IP不变、操作系统不变的要求；基础设施建设到底是先建设好再给应用部门，还是应用部门明确需求后再规划建设。研发、运维就像是带着业务前进的两个车轮，两方如果步调不一致，那必然会产生非常多的摩擦和问题。

回看SRE

自从 Google 推出 SRE 的概念之后，在运维领域 SRE 代表了运维水平较高。实际上 SRE 代表了一种运维的文化。

在这种文化中，SRE 团队做为系统可用性的责任人，会牵头各方齐心协力来推进系统可用性的改进。改进包括可观测性、高可用、容量规划等等运维全生命周期覆盖的领域。

在这种文化中，我相信 SRE 团队一定是充满了责任感、使命感，同时 SRE 团队也需要有相当的话语权以及获得相关的组织上的支持。

很想了解在 Google 内部，类似我们单位的这种场景是如何解决的，想了解 Google 内部是如何划分组织结构的。

当然，即便知道 Google 的组织结构划分，如何应用到现在的单位，因为不同的文化背景差异，一定也需要做适合单位特点的改造和裁剪。

个人体会

简单总结下，如果想在一个组织中推进运维质量的提高，以下几点应该是必须的：

• 制度、流程和规范要求在稳定性保障中必不可少
• 勇于挑战，敬畏生产，重视过去失败的经验
• 对于玩忽职守引起的问题要严格问责，其他之外的问题则不过于追究

对于运维领域感兴趣的，欢迎关注我随时交流。

参考资料

1. 以阿里为例，详解SRE的团队建设与职能分工
2. 一文帮你理解整个SRE运维体系_运维白屏化