工作中如果遇见XX系统出现问题了，我们的第一反应是什么？你的内心活动肯定是：是自己的锅和坑吗？连蒙带猜，赶紧看日志，有错误日志还好，但是没有错误日志啊？参数的问题？窝草，方法的入参忘了打印了，添加打印日志方法，发版，看日志……，这样有点太Low了，小哥哥下一篇给你说一下日志系统，这篇先说解决问题的套路，我相信干什么事情都有套路的，比如学驾照，学英语，撩妹等。
什么是问题？
1. 上下文 -- 和问题相关的场景，指一组已经是明确已知的，关于问题的条件的描述（比如订单-产品-支付-库存肯定有关系）。
2. 目标 -- 指关于构成问题的结论的明确的描述（让系统更流畅，更高速的，更稳定的运行）。
3. 障碍 -- 指问题的正确解决方法不是显而易见的，必须通过一定的思维活动，才能找到答案。
良好的定义问题是解决问题的关键步骤。
定义问题就是鉴别期望和现状的差异。有如下几个关键点：
1. 首要的是，收集整理关于现状的可信的信息，而不要假设已经拥有完备的可信信息；
2. 不暗示倾向于某种原因或者解决方法；
3. 只陈述现状和期望的状态；
4. 在解决问题的过程中，问题的定义可能（有必要）会不断的改进或者转换形式。
把问题描述理解清楚，不要掩盖问题，把问题公开化，透明化，解决完问题最好自己再总结一下(二狗子，高中时候的纠错本你给忘了)。
心态
静心：在定位问题之前，最好先安静下来，摒除杂念。放下自己的身份（项目经理、开发人员），以解决当前系统的问题为中心。静心之后，将问题现象在脑中过一遍，弄清问题。
问题解决者不轻信，不盲从
不确定定问题的时候，不要说大概是什么问题， 绝不因为一句“应该是对的”，“大概没有变化”，“我昨天没发版，之前都是好的”，而抛弃一个怀疑的点。
大局观：不要尽早的陷入细节
实际上，在整个问题定位和解决的过程中，都应该尽量在头脑中对整个系统的映像以及当前位置保持清晰的认知。这样有助于前后、上下联系，在更高更广阔的空间中发现问题。在解决问题的时候提醒自己：我现在处于一个什么位置？如果不启动调试环境我能不能解决掉这个问题？
预判断，然后验证：
让我们一起debug,注意environment(dev,qa), zone,region,contextPath等，尽量将日志、调试、Postman等都用作验证问题的工具——首先对问题的原因做预判断（猜测），然后确定该原因会导致什么现象，然后验证该现象（日志等）。预判断比验证更应被关注。
当很难预判断问题位置时，可以采用排除法：每次排除系统范围的一半左右，逐步将包围圈缩小到问题原因本身。应注意：排除的过程中，同样要注意验证排除的是否正确，即：排除、验证、排除、验证……
关注日志
日志一定要看明白NumberFormatException: For input string，NumberFormatException: Value out of range，Duplicate entry，Data truncation: Data too long for column……，很多问题解决过程中其实打开日志文件就能马上得到结论，但是开发人员宁可自己猜也不愿意动手打开日志，那么日志该怎么打印？留个悬念，下篇说。
工具
工具是让人用的，善于借助监控和运维工具排查问题，会有一些童鞋说，我压根就没权限看到这些东西，springbootadmin，zipkin，log history，zabbix等，记住我们是解决问题的，没有权限也是问题，我们要去解决。
这些大致是一些常用的解决问题的套路，欢迎指正。说了这么多，全靠实战。就像看了好多《如何脱单》一样，扎心了……，最近时不时的有点焦虑，我觉得解决焦虑的最好办法就是看书，学习，运动，做家务等，不要让自己闲下来，看下图！！！愿代码是你的“柳飘飘”，你就是是“尹天仇”！
原文出处：https://www.cnblogs.com/viaiu/p/9382114.html
随时随地看视频
