之前写过一篇解决问题的一般套路，在之前的基础上再丰富一下。想要解决好问题就要明白什么是问题，什么是问题呢？
- 上下文 -- 和问题相关的场景，指一组已经是明确已知的，关于问题的条件的描述。
- 目标 -- 指关于构成问题的结论的明确的描述。
- 障碍 -- 指问题的正确解决方法不是显而易见的，必须通过一定的思维活动，才能找到答案。
良好的定义问题是解决问题的关键步骤。定义问题就是鉴别期望和现状的差异。有如下几个关键点：
- 首要的是：收集整理关于现状的可信的信息，而不要假设已经拥有完备的可信信息；
- 不暗示倾向于某种原因或者解决方法；
- 只陈述现状和期望的状态；
- 在解决问题的过程中，问题的定义可能（有必要）会不断的改进或者转换形式。
服务是突然变慢还是长时间运行后观察到变慢？类似问题是否重复出现？把问题描述理解清楚，需要对这个问题进行更加清晰的定义。也分享一下解决问题需要注意的几个事项：
心态
静心：在定位问题之前，最好先安静下来，摒除杂念。放下自己的身份（项目经理、开发人员），以解决当前系统的问题为中心。静心之后，将问题现象在脑中过一遍，弄清问题。一定可以解决掉。
问题解决者不轻信，不盲从
不确定定问题的时候，不要说大概是什么问题。绝不因为一句“应该是对的”“大概没有变化”而抛弃一个怀疑的点。
大局观：不要尽早的陷入细节
实际上，在整个问题定位和解决的过程中，都应该尽量在头脑中对整个系统的映像以及当前位置保持清晰的认知。这样有助于前后、上下联系，在更高更广阔的空间中发现问题。在解决问题的时候提醒自己：我现在处于一个什么位置？如果不启动调试环境我能不能解决掉这个问题？
预判断，然后验证：
让我们一起debug，注意环境变量，基础路径等，尽量将日志、调试、HttpFox等都用作验证问题的工具——首先对问题的原因做预判断（猜测），然后确定该原因会导致什么现象，然后验证该现象（日志等）。预判断比验证更应被关注。
当很难预判断问题位置时，可以采用排除法：每次排除系统范围的一半左右，逐步将包围圈缩小到问题原因本身。应注意：排除的过程中，同样要注意验证排除的是否正确，即：排除、验证、排除、验证……，这个过程一定要有耐心、耐心、耐心。
关注日志
NumberFormatException: For input string、NumberFormatException: Value out of range、Duplicate entry、Data truncation: Data too long for column、Transaction rolled back because it has been marked as rollback-only……
日志一定要看明白，很多问题解决过程中其实打开日志文件就能马上得到结论，但是开发人员宁可自己猜也不愿意动手打开日志。
另外也暴露了我们系统日志没有为开发人员提供足够的信息支持用以解决问题，后面的设计中要把异常设计作为一个重要部分。
充分利用工具，能得到事实就不猜测
抓包工具，监控工具等，比如：HttpFox等工具能将HTTP请求录下来，我们不需要猜测；还有Windows事件日志，性能计数器，Windbg等等工具可用，
工具是让人用的，善于借助监控和运维监控工具排查问题，dump stack文件，会有一些童鞋说，我压根就没权限看到这些东西，记住我们是解决问题的，没有权限也是问题。
通过差异找到问题的原因
版本提交记录，tag版本号，配置文件，很多问题的解决可以不依赖开发的调试，比如通过比较当前版本和上一版本的区别，比较产品和产品之间的差别就能通过差异来定位问题。代码的话版本工具已经很棒了。也可以借助一些工具如：nodepad 的compare plugin来比较不同的。
解决掉一个问题不是终结
之前往往满足于一个能够解决眼前问题的答案；这是远远不够的，一个问题的出现暴露出我们系统的缺陷，这是一个线索，需要避免同样的问题的出现。一个问题的出现我们要追究到问题的本质。你调用别人的问题，也是你的问题，如果没有解决的话。
透析三棱镜
你需要明白一件事，就是你要解决问题，一定不能盯着问题看，盯着症状是找不到答案的，即便找到了答案也只是治标不治本的方案，有时候你得跳出问题来找解决方案。这个交互给系统造成了很大的负载，那么业务流程能不能优化一下呢？
用透析三棱镜看问题，问题就是：期望与现状落差的部分。
这些大致是一些常用的解决问题的思考，希望能抛砖引玉。再推荐一下What、Why、How黄金三问。没有Why，就没有动力，What和How也就没有意义。没有How，就只是鸡汤，再多道理也只是体现在纸面上，Why要解决这个问题？问题的价值也需要多思考。
每周一句：一件东西的特别，你只要相信即可，你是X？你是Y？那些都是你，你只是你自己而已。
