一、导读
如何分析自己知识体系内无法解决的棘手的问题
在项目中, 我们经常遇到一些不在知识范畴内的问题, 在这里我提供了一个思路,、
帮助你遇到自己无法处理的问题的时候能通过一些步骤, 大致分析问题的方法, 找到问题的根本, 寻求问题的解决之道,
本文在某些层面是一种寻找答案的路径, 不一定帮你立刻解决问题, 至少能巡查到是什么大致原因 , 不至于一问三不知,
不知道怎么出现, 不知道怎么解决, 不知道怎么汇报
二、快速定位
关键词: 超知, 超前知道, 你需要对公司的业务和技术有足够的了解, 至少会一点大致的部署结构,
这些会在你排查问题的时候可以减少很多假设, 减少建立思考连接的时间
如果你自认为还没具备这些能力, 请首先去跟张三丰、扫地僧、令狐冲学习一下技术或者业务的架构吧.
超知条件 : 全链路服务器的流转过程, 比如,
[请求] 1.从哪里发起请求, 请求发往何地, 经过了哪些服务器
[流转] 2.通过什么中间件, 中间件类型是什么, 版本多少, 几个版本, 是否有监控 等
[基础] 3.使用了哪些技术, dotnet java nacos apollo clickhourse elasticsearch 等
[硬件] 4.服务器磁盘, docker挂载磁盘, 系统硬件基础等
[设施] 5.cdn oss nas 七牛等第三方靠网络连接方面使用的设施
[网络] 6. 防火墙类型, 网关类型, 基础网络类型, vip slb 还是linuxse 等
[隐晦] 7.哪些服务出现过问题, 曾出现过, 最近几周出现过, 还是正在出现
三、分析
分析问题也要有步骤, 不能一来,就是xx的问题, 很多问题只是表象, 不是真正的问题所在 ,
明面上看a出了问题, 实际上可能是b导致的, b在前, 但不影响业务, a在后, 直接宕机
小例子: 同样是请求超时时 , timewait 和 timeout 会反映出两个方面的问题 , timeout 具象, timewait 抽象
具象和抽象不一样的是, 解决的思路和途径会发生少许变化
1、具象特征
具象特征表现为接口较慢 , 请求超时报错等, 但同服务器中其他不受影响
一般为某应用, 某业务产生的单个问题初期可以定位到是某些接口请求导致的
或者具有相对特征的情况下, 能迅速摸清问题链路的称之为具象特征.
（1）链路法
一步步验证
例: 小程序发送一个请求, 到服务器, 小程序超时了, 那排查手段是什么呢
（2）特征分析法
核心思想: 出现问题后如何分析很重要, 需要归类, 不同类型的问题使用不同的手法
（3）假设验证法
大胆假设，小心验证，不假设，就意味着面对问题只会说“不知道”，导致拖延处理。
会假设，就意味着可能找到了正确的路径，通过一步步验证，去证明自己的假设，比起被动等待好得多。
2、抽象特征
抽象特征表现为 阵痛 , cpu暴涨, 内存暴涨, 忽然网站全站卡顿等
当cpu出现问题时、当内存出现问题时、当服务器频繁宕机时
重要: 对基础问题进行一个大致的归类, 做出一个假设, 假设错了并不可耻, 可耻的是不知道如何假设
关键词: 合并验证,多个条件在一起测试, 不适合做精准定位, 排查错误时候尽量避免, 以此得到最精准的错误.
在做假设和验证时 , 尽量的做到别合并验证, 什么是合并验证？
打个比方, 你想问a借10块钱, 但你联系不到a, 你找的b , b说a不借给你 , 这里面就存在了合并验证
这样会让你忽略真正错误, 可能b造成, 也可能a造成，所以不如直接问a , 可以让你得到更精准的答案, 在排查错误时能更自信