雪花纷纷落下，片片各得其所。

体系篇

1、对象为实体

对象是一个实际存在的某物，它具备某种能力或提供某种服务，对象是一个实例或实体，比如具体部署的一个硬件设备或一个应用系统、一个数据库实例均是对象，多个对象以某种逻辑关系组成架构，换句话说架构是由对象所组成的。

对象的颗粒度定义大小由架构管理能力而定，架构管理能力越强，对象分解则越细。当一个架构所组成的所有对象是运行正常时，架构一定是运行正常的，如果不是，则是架构分解过程中出现了对象定义遗漏。

一般而言，在一个架构中会存在多种对象，此时需要将对象进行分类定义，以便于管理及分析，在复杂情况下，分类是一个树形结构，分类的过程就是对架构解构的过程，完全穷尽、相互独立是分类很重要的原则。

分类是根据对象属性进行的，严格来说，一些对象被归为同一类，是因为他们具备相同的属性，相同的属性包含两层意思，一种是具备相同的属性字段，一种是具备相同的属性值。

2、属性为指标

对象是组成架构的基本单元，属性是组成对象的基本单元，一个对象的属性包括它具体的所有内在的能力、功用以及外在的特性，除去属性，对象为空，对象的本质是一堆属性的集合。

换句话可以说，架构是由属性构成的，属性就是一个配置项（一个可配置的项目），配置一个属性的过程就是操控架构的过程，所以对象不是配置项，属性才是配置项，历来的CMDB概念对此有着定义上的问题。

由于不同对象有着不同的属性，所有对象的所有属性，可以抽象成一个属性池，由一个一个字段所构成，这个属性池即是描述架构的基本语义。

属性池的设计梳理在工具意义上是必要的，每一类对象拥有哪一些属性，需要进行定义，此时只是一个数据建模的过程，还不是对象实例化的过程，不同分类的对象可能拥有重叠的属性字段。

由于属性是可配置的，也是可监测的，一个不可被监测的属性一定是不可配置的，不管这个工具监测的人工监测，所以属性能以一种指标的形式进行监控。

3、动作为事件

对于一个对象的属性的配置过程，可以称之为动作，也就是操作，架构的管理在绝大多数情况下，是对对象的操作形式体现出来的，一开始是人工手工执行，慢慢发展到利用工具进行执行。

当属性定义完整的情况下，动作的执行结果就是属性的变化，我们也可以称之为一个架构事件，将动作进行标准化及自动化的过程，就是架构自动化的过程，一切架构自动化的目的与结果都是围绕对象属性的，所以属性池的总集就是理论上架构动作的总集。

理论上可以将所有对象的属性对应的可能操作进行梳理，形成一个动作集，将动作的执行脚本化、程序化，再经由对属性改变的结果进行监测验证，来加以判断执行及回馈。

当自动化程度较高时，可以根据动作执行与属性值的变化逻辑判断进行跨对象的动作执行，此时形成处理流程或叫调度编排，动作的执行结果与对象属性值是校验下一个步奏基本的逻辑判断单元。

动作也是桥接虚拟架构与架构本体的一个窗口，它对应是可能是一个脚本也可能是一个启停手册，动作是可以根据对象分类进行划分的，即每一类对象可能有哪一些操作动作，这些操作动作的多少其实就预示着架构维护能力的强弱。

4、视图为架构

架构对于不同专业职能的人员有着不同的面向，这也意味着不同职能分工的人对架构都有着自己的视角，本质上不同专业职能的人员事实上是面对架构中不同对象的不同属性，此时视图的意义就会凸显。

本质上视图就是不同角色对架构的不同切片，不同角色的人会根据自己的专业职能范围，绘制出自己管理对象的范围，由于在架构中对象之间均存在关系，所以视图会以系统结构的形式呈现。

视图是由对象及关系组成的，视图中对象的多少、属性的多少以及相互之间的关系，包括视图中的对象的排列布局，取决于用户对架构的理解与抽象。

由于视图只是架构的一个切片，当用户需要查看管理更大的架构范围时，此时视图与视图之间可以建立关联，所以对象与对象可以组合，视图也可以与视图组合。

对架构的切片越多，意味着对架构的理解越深入，也表示对架构的描述越精确，就好比对一个社会或一个人，你从更多层面去审视它，你就会对它的理解越发深入，真实情况就是所有层面的总和。

5、关系为逻辑

在模型层面，关系是基于对象分类的，在对架构进行解构时，即将架构的对象进行分类后，每个分类之间可能存在关系即可明确，这个定义并不是必要的，它更多是在关系数据校验时发挥作用，或者对绘制视图进行行为约束。

在实例层面，关系只属于于视图，而不属于对象，不同的对象在不同的视图中可能存在不同的关系，关系的存在与否取决于用户的视角即视图。

关系的性质是由两个对象本身的属性决定，而不是关系本身，这意味着不需要赋予关系任何属性，这是从体的层面而言；从用的层面而言，在架构层面，我们只需要知道两个对象存在着关系，就能满足我们一切构建与操作所需要的所有结构信息了。

不需要对关系本身的数据再做一些头上安头的重复定义，导致数据结构或模型的复杂化，只有在绘制视图时，才需要建立关系，而建立的方法是指定哪些对象有关系即可，而不需要指定它们有哪一种关系。

这在系统设计与数据结构设计时有着重大意义，所以关系数据是在记录哪一些视图中哪一些对象存在关系。

我们说两个对象之间存在关系，是因为这两个对象之中的某些属性存在关系，在完美的配置模型下，关系的构建不是以对象出发的，而是从对象的属性出发。

因为两个对象之间的属性存在关系，所以两个对象才存在关系，所以两个视图才存在关系，而这种基于属性级的终极配置模型只有在高度自动化的环镜中才有可能实现。

6、场景为服务

任何架构的维护者均是面向对象的，做好服务工作的前提是识别出架构所存在的对象有哪一些，只有这些对象的运作良好，才有可能提供合格的服务，视图的绘制是为了描述理解架构。

视图本身就是承载服务的使用场景，基于一个视图的使用其实就是在提供服务，比如查看这个视图运行情况或基于这个视图对架构进行维护操作，这本身就是一个服务场景。

服务是由一个一个的场景所组成的，识别出一个服务拥有的所有场景，并进行有效的管理，这是做好服务交付的必要环节，梳理服务场景的过程或能就会带来新的视图需要，大多数组织并没有真正理解他们的服务是什么。

一个网络维护组、一个机房运行组、一个系统维护组，这些组织都是在做一个服务提供，它们的服务交付的客户其实并不是业务方，而是其它的专业组，正是因为对服务的理解片面，进而导致服务场景的梳理无从下手，从视图也是毫无目的。

其实对视图的监控其实就是对服务的监控，对视图的操作其实就是服务的动作。通过场景可以把上述的一切进行有效组织，进行服务交互。

工具篇

1、基础数据

• 需要定义对象的分类树

• 需要定义分类的图标

• 需要定义属性池

• 需要定义分类与属性的关系

• 维护或导入对象数据

• 维护或导入关系数据

2、视图管理

• 负责对象与对象的组装

• 数据维护模式：用户可以手工拖拽对象数据进行关系构建，以类VISIO的操作方式，对象的位置与图标均可拖拽维护，每画一根关系线则在这个视图数据层面创建了一条关系数据，在视图上删除一个关系线条即在数据层面做了关系数据删除。

• 建模关联模式：用户可先画好视图，再手工拖拽对象数据进行关联映射到视图中。

• 可以基于一个视图进行对象关系数据的导入，提供算法将对象与关系自动进行布局排列，且可手工进行调整。

• 管道线路类对象以线条方式存在，此类对象与对象的关系线条属于不同的视觉效果与数据类型。

• 视图可以容器化，在绘制一个视图时，可以将视图的多个对象进行设定为容器，此时在图中多个对象会折叠成一个容器，可点击再展开容器，此时视图中的容器的所有对象会展开，以便更复杂的视图表达。

• 每一个视图的维护与查看权限均可设置，即谁能改谁能看，每一个视图需要有自己的名称与版本时间记录。

3、场景管理

• 负责视图与视图的组装、指标与指标的组装、动作与动作的组装。

• 视图组合：可设置视图之间可以相互嵌套与组合，从一个视图点击跳转到另外一个视图，或者以平铺模式、分层模式将多个视图进行整合。

• 指标管理：基于一个视图进行场景设置，可定义在视图中能查看不同分类对象的哪一些属性指标，在不同的场景下关注的对象的属性集可能不一样。并可设置哪一些指标影响对象的状态，不同的状态将可反映到对象不同的颜色闪烁。

• 操作管理：选择一个视图设置与视图每个对象关联的操作动作，它可以关联一个脚本执行或调用一个自动化软件的API入参，甚至只关联到一个启停操作文档，这些操作以按钮方式集成视图之中。

• 调度管理：在场景中可设置跨对象的操作执行，这种调度执行与场景进行绑定，可进行定制开发。

• 场景管理：经过指标与操作与视图的绑定，形成一个可执行的服务场景，开启时会加载视图数据与指标数据与操作动作，供用户监控与操作交互。每一个场景可以单独命名。

• 图层管理：可在场景中选择不同分类的对象设置按不同的对象属性作为显示对象名称。

• 文档关联：可点击调用场景中任意对象相关的巡检、保养、维护、文档与工单记录，以面向对象的方式组织其它分散的数据与信息。

• 查询搜索：可输入任意对象的任意属性或任一视图名称或场景名称进行搜索定位。

4、集成接口

• 负责工具与工具的组装

• 对象数据集成：可对外采集其它系统的对象数据，也可批量导入对象表格。

• 关系数据集成：基于视图可对外采集其它系统的关系数据，也可批量导入关系数据。

• 性能数据集成：将对象属性与监控性能指标进行对应映射，实时显示性能情况。

• 告警数据集成：将告警级别与对象颜色进行设置匹配，实时显时告警情况。

• 操作数据集成：外接其它自动化软件，在点击执行操作按钮时，传递对象的属性信息作为入参条件，驱动其它软件的命令操作或执行脚本。

• 图形数据集成：可导入CAD、VISIO等图纸资源。

• 对外服务接口：以API方式提供视图与场景调用以及对象的搜索查询功能。

应用篇

1、工具应用

打造一款灵活的拓扑管理工具，利用这个工具灵活的绘制拓扑的能力，绘制各类架构视图，从数据中心的基建、暧通、弱电到网络、主机到系统及应用关系均可将原来分散的线下图纸转为统一集中的管理，把大量在规划设计阶段的图纸重新发挥价值，转移到运营段来利用管理。

它的绘制能力可以跟VISIO相对应，除去精确度，它甚至可以将绝大多数的CAD图纸能人肉转译过来，它的绘制能力必须高度重视用户体验，灵活让它没有专业应用的限制，简洁让它易于上手，设计的美感能让它以把架构之美、抽象之力赋予使用者。

同时它的数据集成能力以及线上协作能力，让它可以真正从设计到运维，并可以跨专业、跨工具的进行数据整合，同时它可以让运营端的工程师们把它做为一个灵活管理工具，随时根据自己的运维需要进行视图绘制。

如此跨专业的信息协作以及人员离职的架构知识可以有效留存在组织之中，这些大量的视图可以工程师快速阅读、理解、分析架构情况。

2、行业应用

拓扑的管理对于架构越复杂、对象越多、关系越复杂的服务管理越有意义，除去熟悉的IT运维，还有像电力行业的通信网络管理、电网的电力传输调度、公安的办公网、视频专网管理、运营商的通信资源管理。

这些网络结构复杂的行业均存在大量的运维交互需求，一些历史陈旧的工具还顽强的束缚着工程师们，经过这这几年年移动互联网的洗礼，工程师人群对传统工具交互的不满越来越大。

甚至一些城市的管廊跟管道、交通的轨道管理，是通通可以用拓扑管理的形式桥接他们的运维应用。

可视化只是人机交互的形式，基于一个灵活的拓扑管理工具，可以在不同的行业做出更多的纵深应用，灵活的绘制能力跟开放的集成能力是广度与深度两个重要保证，这对工具的抽象能力也提出极高的要求。

3、平台应用

上面提到的在线拓扑管理工具有两种推广做法，一种是按软件方式按客户、项目去计费实施，一套一套去部署，它的易用性决定了它的售前POC是一种低成本的，甚至销售人员也可以用它来快速绘制一个行业的DEMO场景，只要他具备一点点行业理解知识。

还有一种模式是按SaaS模式，即提供一个在线绘制拓扑工具，它可以免费试用，让用户零门槛的先尝试绘制自己的架构图，如果他们的确绘制方便，他们就会有意欲查看架构图中的对象信息，甚至对接监控数据，这样后续按月按年进行收费。

理论上用户可以用这个平台搭任何他们想要的模型，绘制任何平面图纸，甚至多个图纸的组合交互，这种基于可视化交互的拖拽才是更具实用意义的模模搭，它的应用广度跟深度可以走的更远。

这几年物联网热潮渐起，事实上基于拓扑图的可视化是物联网很好的交互平台，任何用户可以在这个平台把自己的物联网架构快速实现绘制，不管它是一个家居的物联网，还是一个工业4.0的数字工厂设备交互，物联网的多场景模式，决定了未来它的服务场景数量巨大。

必须提供一个开放的让用户可自定义的可视化交互模式，才能将分散的物联网设备及关系实现纳管；现在谈的智能建筑，物业与运营管理，这个智能楼宇里面的任何一层楼甚至任何一个子系统，都需要一个基于图形的交互方式，不采用这种用户可自定义的拓扑绘制的方式进行交付管理是不可想象的。

拓扑的本质是节点与关系，如果进一步抽象，把一个流程环节也可以对象化，你可以把一个政府所有的电子政务流程进行绘制，并可以把每个流程的关联关系梳理出来，甚至可以对每个政务流程环节当前的办理数量与排队数量进行监控调度。

一个停车位也可以是一个对象，一个会议室也可以是一个对象，希望构建出来的平台是可以面对一切物理结构跟逻辑结构的，只要这个复杂的结构有承载服务，就有对它进行解构跟监视、操控的需要。

在这个平台上纳管的对象越多、能监控的指标与能操作的动作越多，平台的意义就越发明显，随着它的属性池的丰富、自动化程度越高，可以发展成为一个操作系统，你也可以说它是底层所有工具的UI。

人类越来越希望以一种符合直觉的方式去管理一切，可视化的需求会随着这个过程不断涌现，高度的自动化没有实现之前，可视化交互整合的需求会一直处于上升趋势，一旦自动化程度发展到封装大多数场景，人类会慢慢放弃洞悉其内部运作的诉求，也就是说对架构的切片会随着自动化发展而递减。

因为大量的现实会告诉我们，这种打开黑匣子往里看的冲动更多是一种情绪上而不是理性上的，机器会接管一切，它以一种更加自然的方式交付服务，而可视化将退回到另一个位置，一如黑夜之中，你仰望夜空的星光点点。