标准化

将工作标准化是运维过程中最基础、最重要的一个环节。

为什么要做标准化

标准化的过程实际上就是对运维对象的识别和建模过程。形成统一的对象模型后，有助于各方在统一的认识下展开有效协作。针对不同的运维对象，确定所对应用的运维场景，才能更好地实现运维自动化。

标准化步骤

1. 识别对象
2. 识别对象属性
3. 理清对象关系
4. 确定对象场景

基础设施层面的标准化

1. 识别实体对象，主要有服务器、网络、IDC、机柜、存储、配件等
2. 识别对象属性，如：服务器的SN序列号、IP地址、厂商、硬件配置(CPU、内存、硬盘、网卡、PCIE、BIOS)、维保信息等;网络设备如交换机会有厂商、型号、带宽等信息。
3. 理清对象间的关联关系，普通关系如服务器所在的机柜，虚拟机所在的宿主机、机柜所在的IDC等; 网络拓扑关系如：核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的级联关系。
4. 确定对象场景，以服务器为例：针对服务器的日常操作有采购、入库、安装、配置、上线、下线、维修等。可能还会有可视化和查询的场景，如拓扑关系的可视化和动态展示，交换机与服务器之间的级联关系、状态(正常or故障)的展示等。

应用层面的标准化

应用是运维的核心。

1. 识别对象。应用对象的识别过程应该在做微服务架构设计或拆分的时候确定下来，然后延伸到运维这里。

2. 识别对象属性。

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

   • 应用的元数据属性：元数据描述了应用的信息，如应用名、应用Owner、所属业务、是否核心链路应用及应用功能说明等;
   • 应用代码属性：有编程语言及版本（决定了后续的构建方式）、git仓库地址等;
   • 应用部署模式：涉及基础软件包依赖问题;
   • 应用目录信息：运维脚本目录、日志目录、应用包目录、临时目录等;
   • 应用运行脚本：如启停脚本、健康监测脚本;
   • 应用运行时的参数配置：如运行端口、如果是java程序的话可能需要Java的JVM参数GC方式、新生代、老生代、永生代的堆内存大小配置等。

3. 理清对象关系

   即应用与外部的关系，主要有三大类：

   1. 应用与基础设施的关系：如应用与资源、应用与VIP、应用与DNS等的关系。
   2. 平行层面的应用与应用之间的关系：应用与其它应用之间的依赖关系如A服务的API依赖B服务的API等。全链路这样的工具平台就是用来处理应用间关系管理的。
   3. 应用与各类基础组件之间的关系：如应用与缓存、应用与消息、应用与DB等。

4. 应用的运维场景

   应用的运维场景比较多：如应用创建、持续集成、持续发布、扩容、缩容、监控，容量评估、压测、限流降级等。

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

• 分布式服务化框架，如Dubbo、Spring Cloud
• 分布式缓存及框架，如Redis、Memcached
• 数据库及分布式数据库框架，如Mysql、MariaDB等，中间件如淘宝TDDL(现叫DRDS)、Sharding-JDBC等
• 分布式的消息中间件，如Kafka、RabbitMQ、ActiveMQ以及RocketMQ等
• 前端接入层部分，如四层负载LVS、七层负载Nginx或Apache、硬件负载F5等

运维的职责

1. 基础架构标准化

   参与制定基础架构标准，并强势地约束。在这里运维作为线上稳定的Owner，发挥约束作用有可能会比业务架构师这样的角色更为有效。另外，由于历史原因或其他种种因素造成 的已有架构标准不统一的问题，是需要开发和运维共同合作去改造的。这里面如何保持良好的协作，制定统一的路线图也是非常重要的。所以这里强制约束是一方面，同时也要 提供工具化的手段来支持开发的改造，也就是下面这个动作。

2. 基础架构服务化

   基础架构的服务化平台开发，目标是平台自助化，让开发依赖平台的能力自助完成对基础组件的需求，而不是依赖运维的人。这个事情是驱动运维转型和改进的动力，也是运维能够深入 了解架构组件细节的有效途径。同时，要注意到，如果不朝着服务化方向发展，运维将始终被拖累在这些基础组件的运维操作上。
   Redis缓存服务化例子：

   • 创建和容量申请
   • 容量的扩容和缩容，新增分片的服务发现及访问路由配置
   • 运行指标监控，如QPS、TPS、存储数据数量等
   • 主备切换能力等