运维体系框架标准化模型简介

为什么要做标准化？

标准化的过程实际上就是对运维对象的识别和建模过程。形成统一的对象模型后，各方在统一的认识下展开有效协作，然后针对不同的运维对象，再抽取出它们所对应的运维场景，接下来才是运维场景的自动化实现。

这有点像我们学的面向对象编程的思想，其实我们就是需要遵循这样一个思路，我们面对的就是一个个实体和逻辑运维对象。

在标准化的过程中，先识别出各个运维对象，然后我们日常做的所有运维工作，都应该是针对这些对象的运维。如果运维操作脱离了对象，那就没有任何意义。同样，没有理清楚对象，运维自然不得章法。

比如我们说扩容，那就要先确定这里到底是服务器的扩容，还是应用的扩容，还是其它对象的扩容。你会发现，对象不同，扩容这个场景所实施的动作是完全不一样的。

如果把服务器的扩容套用到应用的扩容上去，必然会导致流程错乱。同时对于对象理解上的不一致，也会徒增无谓的沟通成本，造成效率低下。自然地，这种情况下的运维自动化不但不能提升效率，还会越自动越混乱。

这就是为什么我每次都会连续强调三遍“标准先行”的原因。虽然这个事情比较枯燥和繁琐，但是于纷繁复杂中抽象出标准规范的东西，是我们后续一系列自动化和稳定性保障的基础。万丈高楼平地起，所以请你一定不要忽略这个工作。

好，总结一下标准化的套路：

• 第一步，识别对象；
• 第二步，识别对象属性；
• 第三步，识别对象关系；
• 第四步，识别对象场景。

接下来我们就按照上面这个思路，一起来分析从基础设施层面和应用层面应该识别出哪些运维对象。

基础设施层面的标准化

基础设施层面的运维对象应该不难识别，因为都是一个个物理存在的实体，我们可以进行如下分析。

• 第一步，识别实体对象，主要有服务器、网络、IDC、机柜、存储、配件等。
• 第二步，识别对象的属性，比如服务器就会有 SN 序列号、IP 地址、厂商、硬件配置（如 CPU、内存、硬盘、网卡、PCIE、BIOS）、维保信息等；网络设备如交换机也会有厂商、型号、带宽等信息。
• 第三步，识别对象之间的关联关系，比如服务器所在的机柜，虚拟机所在的宿主机、机柜所在 IDC 等简单关系；复杂一点就会有核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的级联关系等，这些相对复杂一些，也就是我们常说的网络拓扑关系。

把以上信息梳理清楚，通过 ER 建模工具进行数据建模，再将以上的信息固化到 DB 中，一个资源层面的信息管理平台就基本成型了。

以服务器为例简单展示一下，我们的视角就是下面这样的：

但是，信息固化不是目的，也没有价值，只有信息动态流转起来才有价值。接下来我们需要做的事情，就是识别出针对运维对象所实施的日常运维操作有哪些，也就是识别出运维场景是什么。

• 第四步，还是以服务器为例，我们针对服务器的日常操作有采购、入库、安装、配置、上线、下线、维修等等。另外，可能还会有可视化和查询的场景，如拓扑关系的可视化和动态展示，交换机与服务器之间的级联关系、状态（正常 or 故障）的展示等，这样可以很直观地关注到资源节点的状态。

完成了这些工作，接下来才是对上述运维场景的自动化开发。所以你看，在真正执行去做工具和自动化平台之前，其实是需要先做好大量的基础准备工作的。我要再次强调这一点，一定不能忽视。

应用层面的标准化

下面我们再一起看一个逻辑上的对象，就是我们前面经常提到的运维的核心：应用。对这个逻辑对象的建模会相对复杂一些，不过我们依然可以按照上面的套路来。

• 第一步，识别对象。

我们前面讲过，这个识别过程是在做微服务架构设计或拆分的时候就确定下来的。所以严格地讲，它不应该是运维阶段才被识别出来的，而是在之前设计阶段就被识别和确认下来，然后延伸到运维这里才对。

• 第二步，识别对象属性。

一个应用是业务的抽象逻辑，所以会有业务和运维两个维度的属性。业务属性在业务架构时确定，这主要是需要业务架构师去识别的，但是它的运维属性就应该由运维来识别了。

下面我们一起来看一下，一个应用应该具备哪些基本的运维属性。

* 应用的元数据属性，也就是简单直接地描述一个应用的信息，如应用名、应用 Owner、所属业务、是否核心链路应用以及应用功能说明等，这里的关键是应用名；

* 应用代码属性，主要是编程语言及版本（决定了后续的构建方式），GitLab 地址；

* 应用部署模式，涉及到基础软件包，如语言包 Java、C++、Go 等；容器如 Tomcat、JBoss 等；

* 应用目录信息，如运维脚本目录、日志目录、应用包目录、临时目录等；

* 应用运行脚本，如启停脚本、健康监测脚本；

* 应用运行时的参数配置，如运行端口、Java 的 JVM 参数 GC 方式、新生代、老生代、永生代的堆内存大小配置等。

从应用属性的视角，应该是下面这样一个视图（简单示例，不完整）：

• 第三步，识别对象关系。

也就是应用与外部的关系，概括起来有三大类：

第一类是应用与基础设施的关系，包括应用与资源、应用与 VIP、应用与 DNS 等等的关系；

第二类是平行层面的应用与应用之间的关系，这里再细分下去就是应用服务或 API 与其它应用服务和 API 的依赖关系。如果你有相关的经验，应该会联想到全链路这样的工具平台了，没错，这样的平台就是用来处理应用间关系管理的。

第三类是应用与各类基础组件之间的关系，比如应用与缓存，应用与消息、应用与 DB 等等之间的关系。

• 第四步，识别应用的运维场景。

这个就会比较多了，比如应用创建、持续集成、持续发布、扩容、缩容、监控等；再复杂点的比如容量评估、压测、限流降级等。

好，这里我们先收一下，聚焦到标准化的层面，通过基础设施和应用层面标准化的示例，我想你应该可以掌握基本的建模思路了，这样的思路可以应用到其它的运维对象上 。

同时，通过上面这些内容，你应该可以比较清晰地看到，我们的每一个运维操作都是针对某个运维对象的，这一点在规划运维体系时非常重要。

而在这些对象中，应用又是重中之重，是微服务架构下的核心运维对象。

从应用标准化的过程中我们也可以看到，针对应用的识别和建模，明显复杂很多。所以，后面我还会从理论和实践的角度来继续强化和分析这个概念。

今天，我继续跟你聊基础架构标准化的问题，但是今天我计划不谈如何进行架构标准化的细节，而是想强调一下基础架构标准化的重要性，因为从我个人的经历和我实际观察到的情况来看，这块的问题会更普遍一些，而这一部分又影响着后续一系列效率和稳定性平台的建设方案。

同时，如果说上次我们讲的基础设施和应用标准化是运维团队职责的话，那今天的内容就是架构、开发和运维共同的职责。

常见的分布式基础架构组件

让我们先一起列一下，微服务的分布式架构下，涉及到的主要基础架构组件有哪些。

• 分布式服务化框架 ，业界开源产品比如Dubbo、Spring Cloud这样的框架；

• 分布式缓存及框架 ，业界如Redis、Memcache，框架如Codis和Redis Cluster；

• 数据库及分布式数据库框架 ，这两者是密不可分的，数据库如MySQL，MariaDB等，中间件如淘宝TDDL（现在叫DRDS）、Sharding-JDBC等。当前非常火热的TiDB，就直接实现了分布式数据库的功能，不再额外选择中间件框架；

• 分布式的消息中间件 ，业界如Kafka、RabbitMQ、ActiveMQ以及RocketMQ等；

• 前端接入层部分 ，如四层负载LVS，七层负载Nginx或Apache，再比如硬件负载F5等。

上面是几类主要的基础架构组件，为了便于理解我以开源产品举例。但在实际场景中，很多公司为了满足业务上的个性化需求，会自己研发一些基础组件，比如服务化框架、消息中间件等，这个情况在有一定技术实力的公司里比较常见。不过大部分情况下，我们会基于这些开源产品做一些封装或局部的改造，以适应我们的业务。

基础架构组件的选型问题

关于基础架构组件，业界可供我们选择的解决方案和产品是非常多的，但是选择多了就容易挑花眼，反而不知道从何入手。我们大概都会遇到同样的问题，是自研还是选择开源产品？有这么多的开源产品到底该选哪一个？

按正常的思路，一定是先组织选型调研，然后进行方案验证和对比，最后确认统一的解决方案。

但是，由于开源产品的便利性，以及开发同学对技术探索的好奇心，实际情况往往是，整个大的技术团队中，不同的开发团队，甚至不同的开发人员，会根据开发的需要或个人喜好，选择不同的开源产品，在没有严格限制的情况下，甚至会尝试去自研。

按照我的观察， 这个问题特别容易出现在微服务架构引入初 期。在这个阶段，团队组织架构按照业务领域进行切分，产生一个个与业务架构匹配的小规模技术团队。每个小团队所负责的业务相对独立，自主权就会变大，如果这个时候整个团队中没有一个强有力的架构师角色去做端到端的约束，就极其容易出现上面的这个问题，并且会一直扩散蔓延下去。

相比之下，成规模的大公司在这一点上做得就相对严格一些，当然也可能是因为之前尝过苦头，所以后来变得越来越规范了。所以这一点也是每个技术团队在引入微服务架构时要提前关注的。

我们以分布式服务化框架为例，我之前遇到的一个实际情况就是，整个大的技术团队选型时以Java技术栈为主，毕竟这块有很多的业界经验和产品可以借鉴参考。但是有的团队对PHP特别精通熟悉，就想用PHP去做微服务，有的团队对Go感兴趣，就想尝试Go的微服务。

从单纯的技术选型上来看，选择什么语言并没有严格的标准。而且在技术团队中，我们也应该鼓励技术多样性和尝试新技术。不过这里要有个度，我暂时先不细说这个度在哪里，我们先来看看，假设没有统一标准的约束会带来什么问题。

技术的应用，一般都会随着应用场景的逐步深入和业务体量的增长，逐步暴露出各种各样的问题，我们分两个层面来看。