结构良好的创造活动要优先于毫无结构的创造活动 ——《系统架构：复杂系统的产品设计与开发》
写在前面，最近生活和工作的节奏都十分紧凑，在技术方面也已瓶颈了一阵时间。于是只能寄希望于一边总结案例，一边阅读书籍。虽然收获甚微，但还是简单记录一下。本文主要总结自《系统架构：复杂系统的产品设计与开发》。不过遗憾的是，没经验的看不懂，有经验的可能用不上。
在开始之前，我们先了解一下什么是系统。简单来说：系统是一组实体和实体关系的集合，其功能的涌现（emergence）大于各自功能（function）之和。
系统中的实体关系主要分为功能关系和形式关系。功能关系有时被称为交互(interaction)关系, 形式关系有时被称为结构(structure)关系。需要注意的是，功能关系一般情况下需要以形式关系为前提。
系统在功能涌现之外，还会涌现出其他特性, 例如可靠性(reliability)、可维护性(maintainability)、可操作性(operability)、安全性(security)、性能（performance）等特性，而针对意外的涌现物，常常被称之为紧急状况（emergency）。
其中由于区分维度的不同，系统的形式也就不同，例如某个产品可以是一个系统（注意，有些事物只是产品而不是系统，有些事物是系统而不是产品），比如DLP和UEM都是单独的系统，但放在办公网安全里，当其整体被看作是一个系统时，DLP和UEM又成了一个模块/组件。物是如此，人也如此，一个人有五脏六腑，是一个系统。对应到一个团队内，整个团队也是一个系统。
另外上文中提到的意外涌现物实际情况分为两种，一种是预期的良好涌现物未能出现，另一种是意外的不良涌现物出现了。而这两种都会导致系统故障。
对涌现物的理解，正是系统思维的主要目标。只有通过努力了解并预测涌现物以及涌现物对系统的作用，才能去掌握系统。预测涌现物通常有三种方式，分别是：
先例(precedent)，即根据经验进行。
试验(experiment)，即通过组合去验证假设，例如螺旋式开发。
建模(modeling)，即通过数据计算完成设计，例如集成电路开发
在架构工作中，应当尽量避免纯粹的依赖先例经验，而是需要通过对案例的经验抽象，形成规范/策略/SOP，以供后续建模，最后逐渐过渡向建模的方式去处理日常任务。例如架构评审中，部分是需要依赖经验进行，部分需要多种POC（试验），但实际上，更需要的是能够以建模方式针对架构设计结果给出控制和追踪，例如云上系统的网络架构，一旦绘制完成后，就能够针对云厂商的IAAS产品特性给出行业标准控制，也能根据自定义规范策略去识别其他问题（e.g. 自定义网络安全域）。
如果一个系统即无先例，又无法试验，也不能可靠建模怎么办？在这种情况下，更多就是靠判断力去推理了，不过这仍需要尽可能的寻找支撑，然后再去推理涌现的功能，亦或是采用不完备的建模。你可以通过自顶向下（top-down）或者自底向上（bottom-upde）,由外向内（ outer-in）的方式进行思考。当然，这里所讨论的都是局限在系统思维的范畴。如果有成本试错，创新思维也未尝不是一场热烈的浪漫。
那么当我们去分析系统时，需要搞懂哪些问题？
系统形式（是什么）与功能（能做什么）？
系统边界(system boundary)和所处的环境是什么？系统边界位于系统和大环境之间，当系统内实体与系统外环境中的实体发生形式关系或功能关系时，这种关系会跨越外部接口。
系统中实体的形式与功能是什么？
系统中各个实体之间的关系以及位于边界处的关系，并确定这些关系的形式及功能（形式和功能是两大块，可以理解为是什么样的，可以做什么）
系统的涌现属性（实体的功能及功能性的互动）是什么？
当我们得到以上问题的答案时（形式与功能，实体与关系，抽象与涌现，边界与环境），还需要注意仍有两个目标（高级目标）尚未完成：
预测系统在某实体发生变化之后的情况
用部件合成整个系统
复杂的系统是由很多高度相关、高度互联或高度混杂的元素或实体所组成的。分解（decomposition）是处理复杂系统最常用的一种方式，不过分解的过程并不复杂，相反整合的过程中需要考虑更多，例如不同实体能否被适当的拼接到一起。除此之外体系（hierarchy）也是一种思考复杂系统的常用方法，以及在不同的hierarchy上进行decomposition。例如 AWS Well-Architected Framework中的Six Pillars。而那些一经拆解就失去意义的东西，被称之为atomic part。在理解并管理复杂度方面，还有一些逻辑关系需要注意：1. 类-实例；2. 特化-泛化；3. 递归。
架构正是对系统中的实体及实体之间的关系所进行的抽象描述。换句话说，架构是对功能与形式之间的对应情况所做的分配，是对元素之间及元素同环境周边的关系所做定义（原文就tm也很拗口）。需要注意的是，形式和功能虽然都是系统的属性，但是架构并不是，它是形式与功能之间的映射。作为架构师，工作之一就是需要训练自己的思维，以便能够理解复杂的系统，最好能够快速理解复杂的系统，同时还能够创建易用易懂的系统。当然，易用不是简陋，是基于一定复杂度但不难懂。上文已经介绍过，实体关系主要为形式关系和功能关系。形式是已经实现或终将实现的东西，包含了所有实体，描述了系统是什么，如何承载某些功能。所以形式可以基本等于形式实体加上结构（结构关系主要分为空间/拓扑关系与连接关系, 除此之外还有地址关系、顺序关系、成员关系、所有权关系等）。这些形式关系可以通过依赖结构矩阵DSM（Dependency Structure Matrix）表示，也可以使用SysML和OPM（Object Process Methodology）表示，有兴趣也可以了解下UAM, MBSE。
系统架构的原则有涌现(Emergence)原则、整体(Holism)原则和聚焦(Focus)原则。在观察系统形式的过程中，采用整体原则十分有效。通过整体原则在观察系统及环境的过程中，可以将其分为整个产品系统(Whole product system 包含了产品/系统本身以及伴生系统（accompanying system），注意还需要去划分系统边界)，以及使用情景(Context)。对于软件系统，代码就是形式对象，软件的形式可以分解为模块和过程，继续拆分可以为单行的代码。整个产品系统则包括代码，编译器，CPU，OS等等。不过与物理系统的抽象稍有不同的地方在于信息化的形式总需要某种物理形式来存储或者编码。
相对于形式的存在，还有功能的活动。我们在系统表面所使用的功能，是从系统内各功能实体之间的交互及整个产品系统中涌现出来的。这也是设计系统的挑战所在。功能可以分解成过程和操作数两部分。操作数可以理解为一种对象，过程可以理解为作用于一个活多个对象的转换模式，通常过程涉及到操作数的创建、销毁和改变。要想做好架构，就一定是专注于对外功能的涌现。而对外展现的功能、性能又是从内部功能及关系中涌现出来的。对内部功能的分析除了前面提到过的先例、试验、建模三种方法，还可以通过逆向工程法、标准蓝图法、隐喻法实现。标准蓝图法指的是某些功能会内自然而然的形成了一系列内部功能，并且在许多年后依旧保持稳定。例如运送重物需要克服重力、克服阻力、使物体前行。制定决策需要收集信息、提出备选方案、提出规范标准用于决策，评估备选方案、确认最终方案等。在认清了内部的功能实体之后，还需要确认功能交互（过程之间相互交换或共享操作数），功能与功能交互一同构成了功能架构。具体可以通过PO矩阵进行分析（行是过程，列是操作数），PO矩阵也可以根据OPM图创建。如果一个系统能以适当的成本创造出较大的收益，那系统的价值就比较高，在这个过程中，就需要投入精力在具备高价值的操作数上。例如对于IDS，就是发现入侵行为并产生告警，对于XSOAR，就是能够使SOP自动化。
形式与功能，乃至功能交互，实际上都是静态的分析。当系统在运行时，还需要关注操作者，操作行为和操作成本。行为就是由功能以及功能相关状态变化情况所构成的序列，系统中的形式对象，应该按照这个顺序来执行各项功能。比如，登录登出。至于操作成本，是架构师在架构决策时需要慎重对待的问题，它由直接成本（研发成本）和间接成本（维护升级等）组成，另外操作成本决定了设计出来的系统是否具备竞争力。
以上的内容里，讨论了关于系统架构的形式、功能、环境、关系。最后还剩下关于“概念”以及从概念到架构的部分没有介绍。有时间的话回头再整理总结一下啊，推荐阅读原作可能效果更好。本来也准备了几个例子，但感觉文字内容可能已经需要消化一阵了，就暂时不放出来了。不知道最近是不是写作变得少了，居然写一篇博客也需要花上几天空闲时间，还是要时常写作才行。2023年06月16日22点，落笔。
