系统级/应用级傻傻分不清楚
其实做技术的都知道，在有疑难杂症的时候最难的是没有思路。
有些问题要折腾许久都没有结果，那要想抽丝剥茧的去查出问题需要的技术功底特别深厚。但是一个人的功底再深厚也不能覆盖所有的技术细节（至少我是做不到的）。
今天想说的是一个思路的事情，就是从硬件到软件，从操作系统到某一行代码、某一个SQL、某一个参数。
（以下是示意图，仅是示意图哦。）
现在关注用户态业务层代码和用户态应用层框架的人很多。各种应用框架看得眼花缭乱。
但是往下深入的人就比较少了。稍微懂一点从语言框架往下的人，都被大部分人认为是深不可测的能力。其实这一层比应用层变化要少很多。真正深入下去也比较有意义。从知识点上会更涉及到一些原理的东西。
对于应用层框架和代码来说，市场上一抓一大把。但是要做好，必须往下深入。
有些开发人员，现在写代码的很少关注原理。会写几个队列放些数据，写几个线程来存取就被称为是架构师级别、分布式、云架构的代码了。
今天在7D Group的群里看到有人说，现在性能测试不好做了。之前改个参数、改个索引就能调优了，现在这些也不算是技能了。又有人说，那怎么办？我只会这些。瞬间无言以对了有没有？
要想有比较好的知识体系，只能多看书。当思路完整的时候，技术也就不会那么难了。
聊聊系统级跟踪
说说系统级的跟踪，因为操作系统是个复杂的东西。如果你想搞清楚，就得知道系统是分为硬件层、驱动层、系统内核层，然后才是用户态可调用的接口层、然后才是library之类的。先知道这些层，然后再横向了解，什么是内存管理、磁盘管理、文件系统、进程调用，还有各层的cache/buffer等内容。才能慢慢搞清楚在实际的环境中的具体作用及影响范围。而这些都是基础知识，记得以前我讲性能分析的培训的时候，在讲到操作系统的时候，会花一些时间先讲系统内核图，大部分时候除了一脸懵之外，就是走走神了。所以后来我就越来越少的讲内核图。为什么要讲呢？我觉得判断一个问题的层次应该是从架构来的（关于架构不展开讨论了，以后有空另写文章说明）。也就是层层剥离问题的时候必须的基础知识。而那种直接猜问题在哪个层面的，显然是在刷脸呀。
全栈其实要求的不止是从前端到后端，还有从上层到下层。瞬间觉得要累死的感觉呀。
聊聊应用级跟踪
不得不说的应用级跟踪，现在有很多应用级跟踪的工具已经做得挺好了，直接到代码层、SQL层、这是进步了，所以现在一个个application monitor工具在打广告的时候毫不掩饰自己的自信。像终止你的用户流失、降低运维成本之类的，大概是说，你全关注自己的代码就好了，我负责所有的有问题的环节。其实做过运维，你就会明白，没有一个系统的运维系统是搭一个平台就可以解决所有问题的，这需要一代代的演进才可以（当然不排除技术的发展让这演进变短）。
在上线前的测试过程中也是一样，没有工具看到所有层面的数据吗？那肯定不是。我记得在五年前做项目的时候，我们团队就已经完全可以从前到后，从里到外都透明化的看问题了。但是上线还是逃不了宕机的生产事故。并且这故事还是在我得意的项目中出现的。
那应用级跟踪是要做什么呢？有几点要注意的：一类是配置类的，这类的问题可大可小，有些麻烦的，找很久都找不到，找到了就想揍人；一类是代码、sql类的。这类的问题应该说比较简单，大概有经验和相应技能的人，只要数据拿到手上，不会超过10分钟就知道问题在哪，再差一点的，也可以搜索些网上同类的问题；还有一类是架构级的，这类问题通常需要从全局视角分析性能瓶颈点，再对照应用架构做分析，这类问题通常在修改代价和沟通上需要沟通好。
问题分析逃不开这两个层面，只是这两个层面都不是那么简单。不管如何，都是需要花很多时间去锻炼自己的技术思路，才能遇到问题也波澜不惊。
