1. 上下文 -- 和问题相关的场景，指一组已经是明确已知的，关于问题的条件的描述。
2. 目标 -- 指关于构成问题的结论的明确的描述。
3. 障碍 -- 指问题的正确解决方法不是显而易见的，必须通过一定的思维活动，才能找到答案。
良好的定义问题是解决问题的关键步骤。
定义问题就是鉴别期望和现状的差异。有如下几个关键点：
1. 首要的是，收集整理关于现状的可信的信息，而不要假设已经拥有完备的可信信息；
2. 不暗示倾向于某种原因或者解决方法；
3. 只陈述现状和期望的状态；
4. 在解决问题的过程中，问题的定义可能（有必要）会不断的改进或者转换形式。
源文档 <http://zh.wikipedia.org/w/index.php?title=%E9%97%AE%E9%A2%98&variant=zh-cn>
心态
静心：在定位问题之前，最好先安静下来，摒除杂念。放下自己的身份（项目经理、开发人员），以解决当前系统的问题为中心。静心之后，将问题现象在脑中过一遍，弄清问题。
问题解决者不轻信，不盲从
绝不因为一句“应该是对的”“大概没有变化”而抛弃一个怀疑的点。
大局观：不要尽早的陷入细节
实际上，在整个问题定位和解决的过程中，都应该尽量在头脑中对整个系统的映像以及当前位置保持清晰的认知。这样有助于前后、上下联系，在更高更广阔的空间中发现问题。在解决问题的时候提醒自己：我现在处于一个什么位置？如果不启动调试环境我能不能解决掉这个问题？
预判断，然后验证：尽量将日志、调试、HttpFox等都用作验证问题的工具——首先对问题的原因做预判断（猜测），然后确定该原因会导致什么现象，然后验证该现象（日志等）。预判断比验证更应被关注。
当很难预判断问题位置时，可以采用排除法：每次排除系统范围的一半左右，逐步将包围圈缩小到问题原因本身。应注意：排除的过程中，同样要注意验证排除的是否正确，即：排除、验证、排除、验证……
关注日志
很多问题解决过程中其实打开日志文件就能马上得到结论，但是开发人员宁可自己猜也不愿意动手打开日志。
另外也暴露了我们系统日志没有为开发人员提供足够的信息支持用以解决问题，后面的设计中要把异常设计作为一个重要部分。
充分利用工具，能得到事实就不猜测
比如：HttpFox等工具能将HTTP请求录下来，我们不需要猜测；还有Windows事件日志，性能计数器，Windbg等等工具可用
通过差异找到问题的原因
很多问题的解决可以不依赖开发态的调试，比如通过比较当前版本和上一版本的区别，比较产品和产品之间的差别就能通过差异来定位问题。
解决掉一个问题不是终结
之前往往满足于一个能够解决眼前问题的答案；这是远远不够的，一个问题的出现暴露出我们系统的缺陷，这是一个线索，需要避免同样的问题的出现
一个问题的出现我们要追究到问题的本质，例如前段时间SSO登陆失败和验证码本地使用失败，本质上都是由于配置文件中指定了Cookie的域。