解决问题的通常套路

        工做中若是碰见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等，记住咱们是解决问题的，没有权限也是问题，咱们要去解决。

       这些大体是一些经常使用的解决问题的套路，欢迎指正。说了这么多，全靠实战。就像看了好多《如何脱单》同样，扎心了……，最近时不时的有点焦虑，我以为解决焦虑的最好办法就是看书，学习，运动，作家务等，不要让本身闲下来，看下图！！！愿代码是你的“柳飘飘”，你就是是“尹天仇”！