记得住的逻辑顺序-内在结构
前面说到，在金字塔原理中有时间、重要性、内在结构三种顺序。说起来，我自己最喜欢的是内在结构，为什么呢？ 先说说什么是内在结构？ 用云计算举例的话，IaaS，PaaS，SaaS就是云计算的内在结构， IaaS再分解，CPU/GPU虚拟化，磁盘虚拟化，内存虚拟化，网络虚拟化就是IaaS的内在结构。看起来，内在结构的顺序逻辑其实就是整体到部分的拆解，而这种拆解要符合后面思考篇才具体介绍到的MECE原则，简单说就是要求部分组合起来能还原整体。这要求，能给定了一个明确的标准。符合标准，对于我这个略带处女座特性的完美主义的人来说，其实会让人很安心，但是对于上级/客户，乃至听众有什么价值呢？其实一个价值就是容易记，哪怕只是记得一个部分，例如只记得磁盘虚拟化，但这就像提示语一样提示着构成整体的其他部分。但是这么好的内在结构顺序，却非常难。这需要我们会事物有足够的理解，才能自己建构内在结构，怎么建构，以及其更深层次的架构，我们会在后面的思考篇提到。而比起自己构建，这里我们先介绍下如何站在巨人肩膀上。
如何获取各种内在结构
我始终相信，在计算机领域，很多技术的内在结构的思考绝对不是新鲜事。下面来介绍几个涞源
- 书籍的目录
之前我写过一本书，《Andorid移动专项实战》，在构建书本的大纲的时候，其实就是在构建内在结构。所以对于大部分的书来说，书籍的目录或者前面1～2章节其实会让你对这个技术有一个从整体到局部的认识。举个例子，如文稿上的目录截图，这是我前一阵阅读的《性能之巅》的目录，这里能就清晰地看到Linux性能优化方法的内在结构。
- 论文
我始终相信计算机技术的内在结构肯定有人思考过的原因之一，就是学术界的存在。很多前沿的技术研究，会在学术界先出现，这些研究会形成论文。在百度学术或者谷歌学术按照对应技术的关键词来搜索，总能有不少惊喜。而这里面有一种论文对于内在结构的形成很有帮助，这类论文会分类对比，归纳总结，就是综述类型的论文，跟前面说的目录有异曲同工的作用。 - 得到App
如果论文都没有？那么我们可以获得一些套之万物皆准的内在结构。这类结构，得到App上的如精英日课等课程总能偶遇到。例如戴明环中的计划（Plan）、执行（Do）、检查（Check）、处理（Act），就与专项测试中的发现、分析、解决、度量很相似。
下面来说几个，其他通用的内在结构
- 内部与外部，例如：宿主机与网络组成了集群，哲学都有内部矛盾和外部矛盾，这算是万用结构了；
- 象限图，例如：重要紧急，不重要不紧急，重要不紧急，不重要紧急组成任务管理四象限，SWOT组成了商业可行性分析的四象限。构建象限并不算太难，我自己就专项测试的工具类型就构建个一个象限图，分析难易与度量的难易形成的象限图；
- 人与非人，例如：团队配合与技术架构来打造出色的项目，套进去没差的，基本上技术就会有人的存在；
- 前台中台后台，例如：如阿里巴巴的中台，传递的概念是通过前中后来做分层，提供服务接口，解除耦合提升效率，套入不用的业务场景就会有不同的前中后台；
- DevOps，例如：需求设计、源码开发、编译集成、测试调试、发布运营构成了软件研发的流程，结合角色和责任就可以套用在很多场合。
如何选择合适的逻辑顺序
同样的一个事情，我们有许多很多不同的逻辑顺序，不同的逻辑顺序对不同的人有不同的价值。假如我要汇报腾讯云QAPM性能监控的建设情况，面对不同的人就会有不同的逻辑顺序
对于直接上级，按照时间顺序来汇报建设的进度；
对于客户，按照发现、分析、解决、度量的内在结构来说明我们如何提升研发效率；也可以按照交互类性能与资源类性能的内在结构来说明我们对于应用的质量是如何确保的；
对于财务负责人，按照QAPM采集的性能数据的上报、存储、分析的内在结构来评估对于服务架构造成的压力、支撑的机器数量以及对应的成本；
对于大老板/投资人，按照QAPM的功能，已经对应的PV/UV来说清楚投资回报；按照重要性来描述后续建设的重点；
另外，大家可以结合前面我们提过“结论先行”来思考，演示文稿的内容通常也可以作为小标题的论据，所以也可以理解为从什么维度（逻辑顺序）来论证最有力。下一节我们会
