想问运维与解决生产环境的问题跟安装实施所遇到的问题时的过程与流程有什么不一样？
据我所知，因为移动等核心业务的生产环境的中间件环境涉及到生产应用，而生产应用通常由系统，存储，中间件，数据库来支撑，所以，遇到的问题，跟在安装实施，布署过程中遇到的问题要相对复杂得多，排除故障也困难得多。
所以，请教一下，在排除生产环境的中间件的故障时候，流程是怎样？，怎样做才算规范？有没有一套标准流程，第一步做什么，第二步做什么？
如果初步诊断是业务应用问题，但应用方面不认为是是应用问题，坚持说是中间件软件本身问题,以及性能问题 ，那又如何协调解决？
总的来说，如何才能明确诊断到底是中间件（was,mq)问题 ，还是aix/hpux/linux系统问题，或者是db2/oracle问题？或者说,有没有一个明确标准，满足这个标准就是WAS/MQ软件、性能问题，不满足这个标准就是WAS/MQ中间件以外的问题，例如系统，数据库问题，如果区分与识别？
谢谢。
2同行回答
不同部门之间进行扯皮甩锅是常见的现象，如果解决这种类似问题，感觉还是得从领导层面协调沟通好出现这类问题时的一种解决机制，分工明确每个部门的相关职责，然后再按照一定的方法和流程去定位问题，如果拿不出问题的真正症结所在，张口就说应该是XX的问题，这样显然无法说服别人。
我们一般的思路是，首先中间件出问题都是由应用无法正常使用表现出来的，建议先从应用层面入手，通过分段定位的方法去分析，比如应用响应慢或者响应错误等，可以先看一下操作系统层面的参数，CPU、内存、网络和存储。比如我们在压力测试时发现并发量一直上不来，通过观察发现CPU和内存都很低，IO的使用已经达到100%，这时几乎可以确定瓶颈点，然后再找和存储相关的具体情况进行分析；如果发现IO使用量也很低，也就是整个的基础资源都很低，那并发上不去显示就是应用层面有一些问题，我们再采集应用日志进行分析，最后可能通过对JVM的分析，发现他们的并发机制有问题。
1】各系统都有运行时参数，先集中获取并分析异常点；
2】分析异常点出现的原因，这个才是难点，如果能简单定位还好。但无论如何要小心A系统的问题是因为B系统出问题导致的情况，没准是系统设计就有隐患呢？如果出现疑难问题，还是靠集体解决，没人愿意背锅，但是如果找不到锅是哪来的，还是大家一起背，所以要团结起来解决问题。再说，也许是哪里不经意的挖了个坑呢，不问哪里想的起来。
3】有了猜想最好能验证，这样可以避免大家判断失误，实在不能验证的，要写明情况，这样下次再出现也好有参考；
4】报告、报告、报告，重要的事情说三遍，份透彻的分析报告，对上讲是负责，对IT同仁是促进、对自己是知识沉淀。