高效的Ops为什么要从标准化开始？

todo

一、从标准化开始谈起

1.1、什么是标准化

简单来说，标准化就是一个识别运维对象、建立对象模型的过程。

在有了统一的对象模型后，我们就能在统一的认识下开展有效的协作。进而就可以针对不同的运维对象，抽取出它们所对应的运维场景，最后就是这些运维场景的自动化实现了。

1.2、为什么要标准化

标准化的最终目的是为了自动化。在进行了标准化后，我们日常的运维工作就可以针对具体对象的具体场景进行展开。而如果运维操作脱离了具体对象的具体场景，那工作将变得混乱、没有章法，自动化也就无从谈起。

以扩容为例，要先确定到底是服务器的扩容，还是应用的扩容，还是其它对象的扩容。我们可以发现，对象不同，扩容这个场景所实施的动作是完全不一样的。如果把服务器的扩容套用到应用的扩容上，就必然会导致流程错乱。

1.3、如何标准化

在进行标准化工作时，我们可以遵循以下几个步骤：

第一步，识别具体对象
第二步，识别对象属性
第三步，识别对象关系
第四步，识别对象场景

接下来，我们按照这几个步骤，来看看如何对基础设施和应用进行标准化

二、基础设施的标准化

基础设施层面的运维对象都是一个个物理存在的实体，应该很好识别：

第一步，识别出具体对象。比如，会有服务器、存储、交换机、路由器、配件、机柜、IDC等。
第二步，识别出对象属性。比如，服务器会有SN序列号、IP地址、硬件配置（如CPU、内存、硬盘、网卡、PCIE、BIOS等）、操作系统、厂商、维保信息等；交换机会有带宽、厂商、型号等信息。
第三步，识别出对象关系。比如，虚拟机所在的宿主机、宿主机所在的机柜、机柜所在的IDC等简单的位置关系；更复杂一点就会有核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的拓扑关系。
第四步，识别出对象场景。比如，服务器的日常操作场景会有采购、入库、安装、配置、上线、下线、维修等等。另外，可能还会有针对这些基础设施之间拓扑关系的可视化查询场景，如交换机与服务器之间的级联关系、状态展示等。

在这里，如果我们通过ER建模工具对前三步梳理出的信息进行数据建模，并将这些信息固化到DB中，一个资源层面的信息管理平台就基本成型了。

然而，信息固化并不是最终的目的，也没有价值，信息只有动态流转起来才有价值，因此，我们进行了第四步运维场景的识别。完成了这些准备工作后，就可以针对具体的运维场景进行自动化开发了。

三、应用的标准化

应用层面的运维对象就是我们之前提到的运维核心：应用。对于这个对象的标准化，我们依然可以按照上面的逻辑来：

第一步，识别出具体对象。比如，在微服务架构中，就是我们根据业务逻辑拆分出来的一个个业务应用。而在单体架构中，所有的业务逻辑都融合在一个应用中。
第二步，识别出对象属性。一个应用所具备的基本运维属性有：
- 元数据属性，主要是一些简单直接地描述信息。比如，应用名、应用Owner、所属业务、是否为核心链路应用以及应用的功能说明等，这里的关键是应用名；
- 代码属性，主要是编程语言及版本（决定了后续的构建方式），GitLab地址等信息；
- 部署模式，主要涉及到一些基础软件包（如语言包Java、C++、Go等）和应用容器（如Tomcat、JBoss等）；
- 目录信息，主要是运行应用所需的一些目录。比如，应用包目录、日志目录、运维脚本目录、临时目录等；
- 运行脚本，如启停脚本、健康检查脚本；
- 运行时的参数配置，如运行端口，Java的JVM参数等
第三步，识别出对象关系。主要是指应用与外部的关系，概括起来有三大类：
- 应用与其它应用的关系。也就是应用的依赖关系，在微服务架构中，一个应用往往只能具备某些特定的功能，想要提供一个完整的业务逻辑就需要和外部的多个应用协作。
- 应用与基础设施的关系。运行应用需要有服务器资源来承载，访问应用需要ip、vip或dns等资源。
- 应用与基础组件的关系。一个动态应用在运行过程中，一定会依赖消息队列、缓存、DB和存储等基础组件。
第四步，识别出对象场景。比如，持续交付，扩缩容，稳定性等。

需要注意的是，应用是业务逻辑的抽象，因此应用会有业务和运维两个维度的属性。在运维工作中，更侧重于运维属性的识别，至于业务属性则往往由业务架构师识别。

四、小结