共计 1230 个字符，预计需要花费 4 分钟才能阅读完成。
在很多公司中，IT、数据中心、业务零碎一出故障，会有很多人被叫到作战室（就是一个为了解决该问题，而把所有相干人员集中在一起的一个会议室）, 然而对于这个问题他们是否能够修复, 是否他们应该负有责任, 常常没有线索.
「证据」(基础架构监控数据, 日志文件, 用户投诉等等) 表明了症状, 然而与 root cause 无关. 只有很多的日志信息和高级别的告警并不会给你与这个问题根因真正相干的答案.
为了远离这种场景, 真正的「证据」应该是什么? 你应该问什么问题?
是一个用户埋怨还是所有用户都受影响?
「只是」CEO 埋怨一个问题, 因为一份 BI 报告在他的老 IE7 上无奈工作? 或者「只是」应用联通上网的终端用户? 理解一个问题产生在十分小的用户群, 还是说全中国的用户都受到影响, 是重中之重.
交付链 (如: CDN, 第三方, ISP, 云供应商, 托管服务, 手机网络) 有问题么?
当代 web 利用、挪动服务、互联网服务、O2O 业务等依赖一长串交付链的服务. 晓得每个的影响会通知你是否应该查看本人的数据中心, 还是说应该打电话给服务商.
要害事务是否受影响?
是否要害业务比方保险投保受到影响? 还是说报错的页面早曾经不必了? 你须要监控最要害的业务性能.
是这个利用的问题么?
利用很简单. 如果你晓得问题是产生在这个利用里, 你而后须要进行故障隔离, 而后让对应的开发和架构师定位问题效率更高.
这个问题与蹩脚的代码无关么?
如果客户应用加载迟缓、体验很差，利用响应工夫很慢, 第一个问题应该是是否与蹩脚的代码无关. 你须要剖析代码级别的性能热点来找到是否起因是低效的算法还是不足代码和架构的最佳实际.
这个问题在虚拟机、容器、中间件 … 里么?
如果虚拟机 (如:VMware, EC2…) 或你的容器 (Docker) 或你的中间件或你的利用运行时（如：tomcat）没有正确的 size, 或者和其余虚拟机及容器存在资源争用也可能引起性能问题. 如果你晓得虚拟机的性能影响到了利用, 你会晓得引入 VM 专家, 而不是利用开发, 来解决这个问题.
容器、中间件、利用运行时同理。
是基础架构导致的问题么?
如果不是利用本身问题, 而是因为 app 运行在资源有余的基础架构上会怎么? 如果须要运行垃圾回收的 CPU 因为超用导致不可用会怎么? 那么是时候思考拆分利用或扩大基础架构了.
是应用服务器的问题么?
因为不正确的配置或谬误的部署, 应用服务器也可能是性能问题的起因. 正确的资源池 (线程, 数据源等) 大小, 平安配置或日志参数都会影响性能. 如果发现是应用服务器的问题, 如果是商业应用服务器，你须要分割 IBM, Oracle, 微软专家；如果是开源应用服务器，你须要分割贵司的相干中间件专家.
总结
有了这些问题的答案, 你能够打消作战室, 迅速定位问题本源, 优化并找到解决方案. 所以不须要 20 人的作战室, 你只须要 3 集体 – 一个开发, 一个测试, 一个运维 – 评估具体的性能 insight, 并引入须要的专家. 完满!
三人行, 必有我师; 常识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.