一、基础设施篇

Created 6 years ago by 学院君, Updated 5 years ago Revision #2 13728 views 2 likes 0 collects

本系列教程是学院君在极客时间学习赵成的运维体系管理课记录的学习笔记，希望对有这方面需求的同学有所启发，如果想要深入了解细节可以去极客时间订阅该专栏。作者介绍：赵成，美丽联合集团技术服务经理。

为什么 Netflix 没有运维岗

相关术语

SRE: Site Reliability Engineer 系统可用性工程师
DevOps: You build it, you run it.

用软件工程的方法重新设计和定义运维工作

启示一：微服务架构模式下，我们必须换一个思路来重新定义和思考运维；
启示二：合理的组织架构是保障技术架构落地的必要条件；
启示三：Freedom & Responsibility，Owner意识很重要。

运维体系建设要以“应用”为核心

运维体系建设

以 AppName 贯穿整个生命周期：应用业务模型（开发）->应用管理模型（上线）->应用所需基础设施：基础设施（服务器、IP、DNS）和组件（数据库、缓存、消息队列等）。

建立应用标准化体系和模型

标准化的过程实际上就是对运维对象的识别和建模过程，标准化的套路：

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

基础设施层面的标准化

第一步，识别实体对象，主要有服务器、网络、IDC、机柜、存储、配件等。
第二步，识别对象的属性，比如服务器就会有 SN 序列号、IP 地址、厂商、硬件配置（如 CPU、内存、硬盘、网卡、PCIE、BIOS）、维保信息等；网络设备如交换机也会有厂商、型号、带宽等信息。
第三步，识别对象之间的关联关系，比如服务器所在的机柜，虚拟机所在的宿主机、机柜所在 IDC 等简单关系；复杂一点就会有核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的级联关系等，这些相对复杂一些，也就是我们常说的网络拓扑关系。
第四步，还是以服务器为例，我们针对服务器的日常操作有采购、入库、安装、配置、上线、下线、维修等等。另外，可能还会有可视化和查询的场景，如拓扑关系的可视化和动态展示，交换机与服务器之间的级联关系、状态（正常 or 故障）的展示等，这样可以很直观地关注到资源节点的状态。

基础设施层面的标准化

应用层面的标准化

第一步，识别对象：应用
第二步，识别对象属性。包括业务属性和运维属性，我们重点关注运维属性：应用元数据属性（应用名称、负责人、所属业务等）、应用代码属性（语言、仓库等）、应用部署模式、应用目录信息、应用运行脚本、应用运行时的参数配置
第三步，识别对象关系：应用与基础设施的关系、平行层面的应用与应用之间的关系、应用与各类基础组件之间的关系
第四步，识别应用的运维场景：应用创建、持续集成、持续发布、扩容、缩容、监控等；再复杂点的比如容量评估、压测、限流降级等

建立基础架构标准化及服务化体系

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

分布式服务化框架，业界开源产品比如 Dubbo、Spring Cloud 这样的框架；
分布式缓存及框架，业界如 Redis、Memcached，框架如 Codis 和 Redis Cluster；
数据库及分布式数据库框架，这两者是密不可分的，数据库如 MySQL、MariaDB 等，中间件如淘宝 TDDL（现在叫 DRDS）、Sharding-JDBC 等。当前非常火热的 TiDB，就直接实现了分布式数据库的功能，不再额外选择中间件框架；
分布式的消息中间件，业界如 Kafka、RabbitMQ、ActiveMQ 以及 RocketMQ 等；
前端接入层部分，如四层负载 LVS，七层负载 Nginx 或 Apache，再比如硬件负载 F5 等。

基础架构组件的选型问题

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

对基础架构有统一的规划和建设。原则上，每种基础组件只允许一种选型，至少就能满足 90% 甚至更多的应用场景。

基础架构的服务化

我们对基础架构组件做了统一标准之后，下一步要做的就是服务化。因为这些组件都只提供了简单的维护功能，还有很多都是命令行层面的维护，这时我们要做的就是把这些组件提供的维护 API 进行封装，以提供更加便捷的运维能力，基于这些原生能力进行封装，结合运维场景，将能力服务化，这样就大大提升了使用方的便利性。

同时，我们也可以看到，这个服务化的过程其实就是 PaaS 化的过程。换言之，如果我们能把基础架构组件服务化完成，我们的 PaaS 平台也就基本成型了。

运维的职责是什么？

总结上面的过程，我们要做的事情，可以归纳为两步：第一步是基础架构标准化，第二步是基础架构服务化。所以这个时候，运维必须要有意识去做的两件事情：

参与制定基础架构标准，并强势地约束；
基础架构的服务化平台开发，目标是平台自助化，让开发依赖平台的能力自助完成对基础组件的需求，而不是依赖运维的人。

从生命周期的角度看应用运维体系建设

对应用的生命周期阶段进行分解，大致分为五个部分，应用的创建阶段、研发阶段、上线阶段、运行阶段和销毁阶段：

应用创建阶段：这个阶段，最重要的工作，是确认应用的基础信息和与基础服务的关系，要同时固化下来，从应用创建之初，就将应用与各类基础服务的生命周期进行挂钩。另外一个很重要的工作，就是要开启与应用相关的各类基础服务的生命周期（队列、DB、缓存等）。
应用研发阶段：主要是业务逻辑实现、验证和测试的阶段。我们要做的最重要的一个事情，就是为研发团队打造完善的持续集成体系和工具链支持。
应用上线阶段：这是个过渡阶段，从应用创建过渡到线上运行。
应用运行阶段：这是应用生命周期中最重要、最核心的阶段。从运维角度来看，这个阶段应用最重要的属性就是应用本身以及相关联的基础服务的各项运行指标（监控、报警）；从业务角度看，业务需求是在不断变化和迭代的，所以就需要不断地去迭代更新我们的线上应用；从运行阶段应用的关系看，除了它跟基础服务之间相对固化的关系外，应用跟应用、以及应用包含的服务之间的调用关系也非常重要，而且这个关系可能随时都在变化，这个时候，我们应用之间依赖管理和链路跟踪的场景就出现了。同时，应用线上运行还会面临外部业务量的各种异常变化，以及应用自身所依赖的基础设施、基础服务以及应用服务的各种异常状况（如双十一）。
应用销毁阶段：如果应用的业务职责不存在了，应用就可以下线销毁了。执行应用的销毁这一步动作，其实是取决于最前面应用与基础服务的关系模型分析和建设是否做得足够到位。

做运维架构的切入点套路：从生命周期入手，划分阶段，提炼属性，理清关系，固化基础信息，实现运维场景。

CMDB的前世今生

当我们识别出运维对象和对象间的关系，并形成了统一的标准之后，接下来要做的事情就是将这些标准固化，固化到某个信息管理平台中，也就是我们常说的配置管理，专业一点就叫作 CMDB（Configuration Management DataBase）。

CMDB 并不是一个新概念，它源于上世纪八十年代的 ITIL（Information Technology Infrastructure Library，信息技术基础架构库）。

从传统 IT 运维的角度来看，运维的核心对象是资源层面。所谓的基础架构也就是网络设备和硬件设备这个层面；各种关联和拓扑关系，基本也是从服务器的视角去看。所以更多地，我们是把 CMDB 建设成为一个以设备为中心的信息管理平台。

传统运维思路下的 CMDB，因为管理范围有限，可以定义为狭义上的 CMDB；而互联网运维思路下的 CMDB 外延更广，我们称它为广义的 CMDB。此时的 CMDB，仍然可以叫做配置管理数据库，但是这个配置管理的外延已经发生了很大的变化。之前所指的简单的硬件资源配置管理，只能算是狭义的理解；从广义上讲，当前的应用以及以应用为核心的分布式服务化框架、缓存、消息、DB、接入层等基础组件，都应该纳入这个配置管理的范畴，尤其是云计算的兴起，我们对硬件基础设施的关注越来越低。