在很多公司中，IT、数据中心、业务系统一出故障，会有很多人被叫到作战室（就是一个为了解决该问题，而把所有相关人员集中在一起的一个会议室）, 但是对于这个问题他们是否可以修复, 是否他们应该负有责任, 经常没有线索.

「证据」(基础架构监控数据, 日志文件, 用户投诉等等) 表明了症状, 但是与 root cause 无关. 只有很多的日志信息和高级别的告警并不会给你与这个问题根因真正相关的答案.

为了远离这种场景, 真正的「证据」应该是什么? 你应该问什么问题?

(资料图片)

「只是」CEO 抱怨一个问题, 因为一份 BI 报告在他的老 IE7 上无法工作? 或者「只是」使用联通上网的终端用户? 了解一个问题发生在非常小的用户群, 还是说全中国的用户都受到影响, 是重中之重.

当代 web 应用、移动服务、互联网服务、O2O业务等依赖一长串交付链的服务. 知道每个的影响会告诉你是否应该检查自己的数据中心, 还是说应该打电话给服务商.

是否关键业务比如保险投保受到影响? 还是说报错的页面早已经不用了? 你需要监控最关键的业务性能.

应用很复杂. 如果你知道问题是发生在这个应用里, 你然后需要进行故障隔离, 然后让对应的开发和架构师定位问题效率更高.

如果客户使用加载缓慢、体验很差，应用响应时间很慢, 第一个问题应该是是否与糟糕的代码有关. 你需要分析代码级别的性能热点来找到是否原因是低效的算法还是缺乏代码和架构的最佳实践.

如果虚拟机(如:VMware, EC2...)或你的容器(Docker)或你的中间件或你的应用运行时（如：tomcat）没有正确的 size, 或者和其他虚拟机及容器存在资源争用也可能引起性能问题. 如果你知道虚拟机的性能影响到了应用, 你会知道引入 VM 专家, 而不是应用开发, 来解决这个问题.容器、中间件、应用运行时同理。

如果不是应用自身问题, 而是因为 app 运行在资源不足的基础架构上会怎样? 如果需要运行垃圾回收的 CPU 因为超用导致不可用会怎样? 那么是时候考虑拆分应用或扩展基础架构了.

因为不正确的配置或错误的部署, 应用服务器也可能是性能问题的原因. 正确的资源池(线程, 数据源等)大小, 安全配置或日志参数都会影响性能. 如果发现是应用服务器的问题, 如果是商业应用服务器，你需要联系 IBM, Oracle, 微软专家；如果是开源应用服务器，你需要联系贵司的相关中间件专家.

有了这些问题的答案, 你可以消除作战室, 迅速定位问题根源, 优化并找到解决方案. 所以不需要 20 人的作战室, 你只需要3个人 - 一个开发, 一个测试, 一个运维 - 评估详细的性能 insight, 并引入需要的专家. 完美!

三人行, 必有我师; 知识共享, 天下为公.本文由东风微鸣技术博客 EWhisper.cn 编写.

关键词：