在 4 月份, 我写了不少的关于技术问题分析和诊断的文章, 这些问题基本也是来源于真实的项目实践, 即使到现在有些问题也没有完全得到定位和最终解决, 包括我们找了 Oracle 的专家和顾问, 也不是说马上就能够满足我们解决掉该技术问题. 简单来说, 如果一个技术问题, 你能够直接快速的在网上搜索到相关的答案, 这种问题都谈不是真正有挑战的技术问题.
对于技术问题的解决, 基于前面实践的问题定位, 分析和解决的思路, 我还是想谈下在解决技术问题中的一些关键点和思考逻辑方面的内容.
个人已有的知识技能和大量实践经验的积累
这个点相当重要, 任何知识库, 搜索都代替不了个人已有的知识经验积累. 为什么说工作经验很值钱, 往往就是你在一个专业领域有大量实践积累, 大量问题分析解决经验积累. 这些经验可以帮助在在遇到问题的时候快速的对问题进行预判和定位, 包括提出最可能的假设路径.
我们现在解决问题, 很多都是才是非结构化解决问题方法, 即是优先提出最可能的假设, 然后再去验证假设是否能够真正解决问题. 那么有经验的人往往就最容易提出最可能的假设路径, 而减少对各种不可能弯路的尝试. 一个问题本身有 A 到 E 五个独立假设路径, 而最可能路径是 A, 你解决问题慢往往就是你最后才假设和尝试到 A 路径并解决问题, 而有经验的人往往一开始就选择了假设 A 进行验证.
要积累这种经验, 任何技术问题解决后个人也必须进一步的复盘, 将其抽象为经验和方法论.
问题定位的重点就是缩小范围和确定边界
一个问题出现了最重要的就是快速的定位, 比如一个业务系统查询故障, 要快速的定位是基础设施资源的问题, 还是数据库和中间件的问题, 还是说程序的问题. 如果是程序的问题, 又需要马上定位到究竟是前端的问题, 还是逻辑层的问题或数据库的问题. 只有快速的确定边界和定位问题, 往往才能够有针对性的去解决问题.
任何问题的定位都是追溯到引发问题的根源, 而不是解决问题的表象, 类似头痛医头脚痛医脚.
如何缩小范围和快速的确定边界, 比如我们假设一个最简单的场景, 问题的产生经历了 A-B 的两个过程. 那么如何快速的确定问题是在 A 阶段产生的还是在 B 阶段产生的呢? 对于这个问题, 我们有如下的问题定位方法和思路可以参考和借鉴:
1. 替换法: 比如将 A 替换为 A1, 如果问题消失, 那么说明问题出在 A 这个阶段.
2. 断点法: 已经 A 阶段完成后的输出应该为 x, 那么就设置断点监控是否是 x, 如果不是则问题出在 A 阶段.
3. 假设法: 假设 A 阶段有问题, 对 A 阶段的参数进行调整并观察问题是否解决, 如果解决问题可能出在 A.
当然还有其他很多的问题定位方法, 但是对于所有问题定位和确定边界的方法中, 最有效的仍然是类似于快速查找中的二分法, 通过二分法可以快速的帮助我们缩小范围和定位问题.
善用搜索引擎
要明白, 任何你遇到过的技术问题, 往往一定有他人也遇到过类似的技术问题, 因此善用互联网和搜索引擎, 进行基于问题关键字的技术检索仍然是解决技术问题的关键途径. 即使搜索引擎没有帮助我们解决最终的问题, 往往也会帮助我们在搜索的过程中学习与该技术问题相关的很多知识.
要搜索, 一个重点就是选择搜索的关键字, 对于关键字的选择一次没有选择准确自己就要多次尝试和迭代, 知道能够准确的描述问题为止, 同时在搜索的过程中搜索的答案往往也可以帮助你进一步的细化关键字.
对于关键字的描述, 从我 4 月写的技术问题解决思路文章来看, 应该包括:
1. 从数据库, 中间件和业务系统错误日志中提取关键字信息.
2. 从你产生问题的环境, 背景, 场景中增加缩小检索范围的关键字信息.
3. 从搜索到的网页中挖掘更加有意义的描述类似问题的关键字信息.
同时对于搜索而言, 特别是技术问题的搜索, 有官方知识库的要优先搜索官方的知识库, 比如对于 Oracle 产品相关的技术问题, 我们也会先搜索 Oracle 官方的 Support 网站, 同时搜索类似 StackOverFlow 网站, 这些网站往往有更加全部的技术问题解决文章.
搜索技术文章, 国外的技术网站相对来说更加全面, 而对于百度这块相对弱, 很多国外技术网站内容都搜索不到, 可以尝试 Google 或 Bing 搜索.
来源: http://www.tuicool.com/articles/YZvaAfb