技术思维（功能、交付、性能、创新型）工程思维（流程、成本、质量、风险）产品思维（痛点、体验、特性、效果）商业思维（经营、商业模式）​技术赋能业务​自我管理 （情绪管理、目标管理、时间管理）​沟通表达（不同角色沟通、述职表述）​项目管理（风险管控、组织协调、落地执行）​跨界协同（人际理解、关系建立、资源整合）​思维决策（系统思考、方案设计、情绪管理）​领导团队（管理规划、团队培养、任务管理）

在 Kubernetes 中，资源是非常常用的术语，从广义上来讲，Kubernetes 系统中所有你能接触的方方面面，都被抽象成了资源，比如表示工作负荷的资源（Pod、ReplicaSet、Service、……），表示存储的资源（Volume、PersistentVolume、Secret、……），表示策略的资源（SecurityContext、ResourceQuota、LimitRange、……），表示身份的资源（ServiceAccount、Role、ClusterRole、……），等等。事实上，“一切皆为资源”的设计也是 Kubernetes 能够顺利施行声明式 API 的必要前提。Kubernetes 以资源为载体，建立了一套同时囊括了抽象元素（如策略、依赖、权限）和物理元素（如软件、硬件、网络）的领域特定语言。它通过不同层级间资源的使用关系，来描述上至整个集群甚至是集群联邦，下至某一块内存区域或者一小部分的处理器核心的状态，这些对资源状态的描述的集合，就共同构成了一幅信息系统工作运行的全景图。

架构关乎的是整个复杂的软件工程，它关乎实现它的人，它又因团队的能力而异。同时，架构也关乎用户需求，作为架构师，我们不只是要知道当前的用户需求是什么，我们还要预测需求未来可能的变化，预判什么会发生，而什么一定不会发生。预测什么不会发生最为重要，只有做到这一点，才能真正防止架构的过度设计，把简单的事情复杂化。

软件行业里有一本名著叫《人月神话》，其中提到两个非常重要的概念：本质复杂度（Essential Complexity）和偶然复杂度（Accident Complexity）。简单来说，本质复杂度就是解决一个问题时，无论怎么做都必须要做的事，而偶然复杂度是因为选用的做事方法不当，而导致要多做的事。比如你要做一个网站，网站的内容是你无论如何都要写的，这就是“本质复杂度”。而如果今天你还在用汇编写一个网站，效率是不可能高起来的，因为你选错了工具。这类选错方法或工具而引发的问题就是“偶然复杂度”。

直觉是本能的，无需积累，而洞见是溯因推理（Abductive Reasoning），需要前期进行大量的积累之后，从中发现模式，方能形成洞见。打个比方，同样的思念，可以说，衣带渐宽终不悔，为伊消得人憔悴，也可以说，我想死你了。二者看上去差不多，但境界有差异。

思考框架是道，原则是演化下的术，我们从 A → B，有无穷无尽的路径，最有效的唯有那条直线。本质上，各个维度、原则都是帮助我们更好地定位 A 在哪里，B 在哪里，那条直线在哪里。

遇大事，静 遇烂事，离 遇顺事，敛 遇难事，变 遇急事，缓

“不可变基础设施” 是“云原生”的实践基础（这也是容器技术的核心价值）；而 Kubernetes、Prometheus、Envoy 等 CNCF 核心项目，则可以认为是这个路径落地的最佳实践。

“云原生” 刻画出的，是一个使用户能低心智负担的、敏捷的，以可扩展、可复制的方式，最大化利用“云”的能力、发挥“云”的价值的一条最佳路径。

存储让数据跨越时间，（今天存储明天读取）传输让数据跨越空间，计算让数据改变形式。时空一体，那么存储和传输可能也是统一的

准确的需求分析是做出良好架构设计的基础。很多优秀的架构师之所以换到一个新领域一上来并不一定能够设计出好的架构，往往需要经过几次迭代才趋于稳定，原因在于新领域的需求理解需要一个过程。除了心里对需求的反复推敲的严谨态度外，对客户反馈的尊重之心也至关重要。

系统要与外部世界交互，就应该有输入和输出的能力（黑洞是否只有输入没有输出）；作为人造系统，主要的交互对象是人，所以针对人类的输入输出能力就更重要，显示器和键盘就是这个角色；存储和计算能力是系统智能的核心，决定了系统如何用输入输出与外部世界交互；系统需要有演化能力，初期只能人类帮助演化（编程语言、编辑器、编译器），足够智能后才能自我演化。

以终为始，确定好真实目标；任务分解，找到实施路径；沟通反馈，解决与人打交道出现的问题；自动化，解决与机器打交道出现的问题。