《进化运维技术变革与实践探索》要点总结

l130zbge.png

前言

很好的一本书，读完大受启发。没有讲具体的技术，就像武功秘籍，提升的是认识和见识。1-4章讲运维的基础，5-7章讲效率和稳定性方面的实践，8-9章讲云计算方面的思考和实践，10章讲个人成长与趋势热点分析。最后拓展讲了一下个人成长和趋势热点的关系。

1章 运维的本质

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

例子 Netflix SRE不超过10个人

引入微服务架构后，软件架构的细化拆分和灵活多变，大大提升了开发人员的开发效率，也提升了业务需求的响应和迭代速度 微服务被广泛接受和采用的根本原因

微服务架构复杂到了一定程度，已经远超单纯的开发和单纯的运维职责范畴，也远远超出了单纯的人力认知掌握范围，所以必须寻求在此架构之上的更为有效和统一的技术解决方案，来解决复杂度认知的问题。 devops 理念以及衍生出来的一系列话题，我们可以仔细思考，是同样的背景和逻辑。

合理的组追架构和先进的工具体系及理念 中间件 SRE DBA 交付和自动化工具、基础架构等团队放在统一的云平台工程这个大团队下，在产品层统一规划和建设

持续交付系统 spinnaker 稳定性保障工具体系 chaos engineering

自由和责任 企业文化 you build it you run it

更多公司采用微服务架构后，没有充分考虑到后续基于微服务架构的运维问题。在运维团队的设置上，仍然脱离整个技术团队。

1.2 运维体系建设的核心概念：应用

微服务架构 是从单体架构或分层架构演进过来的 软件架构服务化的过程，就是我们根据业务模型进行细化的过程 一个字 拆

应用模型及关系模型的建立

应用业务模型

应用管理模型

应用运行时的依赖（基础设施和组件）

建立各个基础设施和组件的数据模型，同时识别出它们唯一标识。以NameSpace来标识唯一命名。 识别出基础设施及组件可以与应用名AppName建立关联关系的属性

大部分公司在软件架构上引入了微服务，但是后续的一系列运维措施和管理手段没跟上 devops 运维和开发合并 传统模式 运维和开发分开

常见场景 片面的对待基础组件，没有与应用建立起关联关系，没用任何生命周期管理措施。 申请资源的人离职，说不清哪是哪，有没有在用 不了解 不清楚，后续的人不敢动

应用名不统一的问题 开发随便命名，运维方便管理定义一套应用命名体系，方便自己管理。 持续交付和监控系统平台也是独立的，脱节问题更严重

以应用为核心的运维管理体系

2章 运维体系建设

2.1 标准化体系建设基础

标准化 最基础、最重要的一项工作，最容易被忽视 标准先行

标准化的原因和步骤

基础设施层面的标准化

服务器 SN序列号，IP地址，厂商 、硬件配置（cpu，内存、硬盘、网卡、PCIE、BIOS）维保 交换机 厂商，型号，带宽

服务器---机柜 虚拟机---宿主机 机柜---IDC

        识别出针对运维对象日常运维操作有哪些，识别出运维场景

             可视化，查询
             交换机和服务器之间的级联关系
            状态（正常/故障）的展示

应用层面标准化

识别对象（微服务架构设计，或拆分的时候确定下来的）

识别对象属性 （业务，运维两个维度）

识别对象关系

识别应用的运维场景创建 持续集成，持续发布，扩容，缩容，监控容量评估，压测，限流降级

总结：应用是微服务架构下的核心运维对象

2.2 实践：基础架构标准化

基础设施和应用标准化是运维团队职责 基础架构标准化是架构，开发，运维的共同职责

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

基础架构组件的选型问题

开发层面

运维层面

基础架构的服务化

运维的职责 要做的事情基础架构标准化，基础架构服务化

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

核心运维对象（应用）的生命周期涵盖其他附属运维对象的子生命周期 应用的生命周期有五个阶段：

• 创建阶段
  • 确认应用的基础信息和基础服务的关系，固化下来
• 研发阶段
  • 业务逻辑的实现和验证阶段
    • 业务逻辑层面（开发代码/质量保证）涉及代码提交合并，编译打包，发布部署
    • 验证（持续集成）各种测试
• 上线阶段
  • 过渡阶段
• 运行阶段
  • 核心阶段（需要各种指标的输出）
    • 制定每个运维对象的SLI、SLO、SLA
    • 同时能够对这些指标进行监控和报警
    • 业务需求的不断变化和迭代，仍然会用到研发阶段的持续集成过程，最终与线上发布形成持续交付的闭环体系
    • 应用关系，与基础服务之间的关系，与其他应用之间的依赖（应用之间依赖管理和链路追踪）
    • 外部业务量的各种异常变化，流量激增，热点事件，服务器故障，IDC故障，数据库故障，api报错（线上稳定性保障场景）
• 销毁阶段
  • 应用自身销毁
  • 围绕着应用的基础设施，基础服务以及关联关系都要被一并清理（减少浪费)
  • 日常工作中，缓存系统有很多NameSpace不知道是谁的，消息系统中很多Topic也不知道是谁的，但又不敢随意乱动，无端占用着系统资源 总结

独立思考很重要 别人的思路和解决方案往往建立在一个非常稳固的基础之上，二这些基础又太枯燥，太繁琐，常常被一带而过，甚至略去不讲。

3章 配置管理数据库（CMDB）

3.1 CMDB的介绍

运维架构基础（运维对象）：

• 基础设施层面（IDC机房、机柜、机架、网络设备、服务器）
• 应用层面（应用元信息，代码信息，部署信息，脚本信息、日志信息）

ITIL（信息技术基础架构库）

传统CMDB cmdb与每个企业具体的it软硬件环境、组织架构和流程强相关，是高度定制化的系统 以设备为中心的信息管理平台（适用于IT基础设施形态变化不大）（单体架构，或分层架构）

个人经历（500台服务器，以excel作为cmdb，记录去管理和分配各种资源）能够胜任的原因就是基础设施层面的架构形态相对稳定，有稳定的软件模块数量和架构

ITIL 管理服务的流程体系，以一条条流程规范和约束，增加流程和审批

互联网运维体系下的cmdb 以应用为核心 微服务技术架构的落地和实践，应用各维度的管理复杂度，应用复杂度就体现出来 云计算蓬勃发展，逐渐屏蔽了IDC，网络设备，以及硬件服务器这样的底层基础设施复杂度

前面狭义的指简单的硬件资源配置管理 后面广义的以应用为核心的分布式服务化框架，缓存，消息，数据库，接入层等基础组件都被纳入这个体系

运维自动化

• 第一层 自动化服务器安装部署，网络自动化配置
• 持续交付，devops ， SRE

3.2 cmdb 与 应用配置管理

cmdb 是面向资源的管理，资源不等于资产，是运维的基石 建设运维基础管理平台步骤

1. 确定服务器，网络，IDC，机柜，存储，配件等大的维度
2. 确定硬件属性
   • 服务器属性有SN序列号，IP地址，厂商，硬件配置（CPU，内存，硬盘，网卡，BIOS）维保
   • 网络设备有厂商，型号，带宽，IP
3. 梳理以上信息的关联关系，拓扑图
   • 服务器所在的机柜
   • 虚拟机所在的宿主机
   • 机柜所在的IDC等
   • 复杂的还有核心交换机，汇聚交换机，接入交换机以及机柜和服务器之间的级联关系
4. 规划问题
   • IP地址段的规划，数据库，大数据，业务应用等
   • 那个机柜用于做虚拟化宿主机，哪些机柜只放数据库机器等
   • ER建模，固化到数据库中
5. 流程规范建设
   • 服务器的上线，下线，维修，装机等流程
   • 流程过程中的状态变更同步管理
6. 拓扑关系的可视化和动态展示
   • 交换机与服务器之间的级联关系、状态（正常/故障）的展示 至此，从资源维度进行信息的梳理，以及基于这些信息进行平台和流程规范建设算是基本成型

应用配置是面向应用的管理，是运维的核心 cmdb的基础信息部分，从传统的SA运维模式看，已经足够，从应用运维的角度看，远远不够

应用名(应用标识）---IP 或其他 主机名，容器ID等

CMDB是以IP为标识的资源维度的配置管理，有了应用名之后，来看应用维度的配置管理 涉及的信息

• 应用的基础信息，责任人，应用的git
• 应用部署涉及的基础软件包，语言包（java，c++，Go等）、web容器（tomcat，jboss等），web服务器（apache，nginx）基础组件（各种agent，如日志，监控，系统维护类的tsar）
• 应用部署涉及的目录，运维脚本目录，日志目录，应用包目录，临时目录
• 应用运行涉及的各项脚本和命令（如启停脚本，健康脚本）
• 应用运行时的参数配置（如java的JVM，GC方式，堆内存大小配置）
• 应用运行的端口号
• 应用日志的输出规范
• 其他 梳理的过程就是标准化的过程，然后进行信息建模和数据固化，有了“应用配置管理”

在往后基于应用配置管理的流程规范和工具平台建设，涉及经常说的持续集成和发布，持续交付，监控，稳定性平台，成本管理

将两类信息统一，二者通过“应用名---IP”联系到一起就是CMDB

总结： 仅仅基于cmdb 的资源信息作自动化，最多只能做出自动化的硬件采集，自动化装机，网络-硬件拓扑关系生成等资源层面的工具，这些工具只会在运维层面产生价值，离业务很远

基于应用这一层去做，可以做持续集成和发布、持续交付、弹性扩缩容，稳定性平台，成本控制

3.3 在CMDB中落地应用的概念

以应用为核心，如何落地？ 如何建立应用集群分组？

• 有效组织和管理应用
  • “服务树”的概念，树形的层次结构
  • 业务维度的拆分---->产生应用拆分原则---->技术团队的组织架构（业务架构决定技术架构，技术架构决定团队组织架构）
    • 组织架构中不同的团队单元分别承担着对应业务的需求开发和实现的职责
  • 应用管理规范
    • 应用名必须使用大小写英文字母以及下划线的组合
    • 应用名不超过40个字符，尽量简单易懂
    • 不允许出现机房代号和主机名称这样的信息
• 应用的集群服务分组建设（应用----集群服务分组----资源）
  • 为什么有集群分组
    • 多环境问题
    • 多IDC问题
    • 多服务分组
      • 功能优先级不同（核心应用和非核心应用），影响业务收入就属于核心应用
      • 场景因素决定（电商）（秒杀活动）
• CMDB在基础服务体系中的核心位置
  • 应用----集群服务分组----资源的对应关系，对周边系统的作用
    • 监控系统（根据此关系监控应用，集群，以及每台服务器上的关键信息）
    • 发布系统（将每个应用对应的代码编译打包，并发布到对应集群的主机上）
    • 服务化框架（需要依赖应用和集群分组两个信息，主要是对应用名和集群分组名的依赖）
      • 通过配置中心注册的应用名来实现对应用的服务和api管理，与cmdb统一
      • lvs 和nginx 四层和七层负载
      • zookeeper开源分布式配置管理等
    • 基础服务
      • 分布式数据库，分布式缓存，消息（需要应用名，应用与资源IP的对应关系，集群分组与IP的对应关系）
      • 访问控制依赖--应用与资源IP的对应关系
    • 稳定性保障平台（服务治理平台）
      • 针对系统稳定性，有很多降级限流和开关预案策略

4章 运维组织架构及模式

4.1 运维组织架构和转型

• 自助化运维能力的建设（做好运维和整个技术架构体系的融合，不要割裂两者。不仅仅是促进组织架构层面的融合，更是促进职能协作上的融合）
• 价值呈现的角度看运维（效率，稳定，成本）
  1. 运维基础平台体系建设（标准化体系，cmdb，应用配置管理，DNS域名管理，资源管理）基础核心
  2. 分布式中间件的服务化建设（标准化，服务化） 支撑
  3. 持续交付体系建设 （连接运维和业务开发的关键纽带，是提升整个研发团队效率的关键部分）
     • 依赖（1和2）
     • 是整个应用的生命周期的管理体系
       • 包含应用创建，研发阶段的持续集成
       • 上线阶段的部署发布
       • 运行阶段的各类资源服务扩容缩容
     • 运维和开发比较容易爆发矛盾的地方
  4. 稳定性体系建设（依赖1和2）
     • 稳定性保障
     • 快速发现线上问题
     • 快速定位问题
     • 快速从故障中恢复业务
     • 有效评估系统容量
     • 机制建设，应急响应，故障有效管理，复盘，演练
  5. 技术运营体系建设
     • 侧重运作机制方面（确保我们制定的标准，指标，规则，流程可以有效落地）
     • 技术运营意识
       • 制定输出标准的意识和能力
       • 制定规范流程的能力
       • 将标准和流程固化到工具平台
       • 确保承载了标准和规范的平台落地，平台必须可用
• 运维协作模式的改变
  • 运维团队发起，周边技术团队协作配合完成
  • 运维团队主动出击，去沟通和推进
  • 上级主管甚至更高层技术领导的支持
  • 例子：平台技术部门（分布式中间件，虚拟化技术，稳定性工具平台以及大数据几个字部门），指责细分
    • 运维基础平台建设（运维完成）
    • 分布式中间件服务化建设
      • 运维和分布式中间件部门一起制定各种使用标准、规范和流程
      • 中间件团队负责提供运维服务能力
      • 运维根据用户使用场景需求分析，负责实现，同时负责标准和自助化工具平台的推广和落地
    • 持续交付体系建设
      • 多部分协作完成（虚拟化部门，中间件团队，运维）
      • 服务化框架提供底层运维服务能力，中间件运维能力的封装整合
    • 稳定性体系建设
      • 链路埋点，限流降级，开关预案
• 运维的组织架构
  • 基础运维：IDC运维，硬件运维，系统运维以及网络运维。
    • 应该擅长硬件和操作系统层面的运维
  • 应用运维：主要是业务和基础服务层的稳定性保障和容器规划等
    • 应该更擅长业务稳定性保障、疑难问题公关以及技术运营等
  • 数据运维：数据库、缓存以及大数据的运维
    • DBA本身就是专业性极高的一个岗位
  • 运维开发：效率和稳定性层面的工具开发
    • 对上述几个岗位日常运维需求的支持，是否能将人力投入转换成工具平台支撑，取决于这个团队的能力 总结：

业界没有一劳永逸的组织架构，也没有放之四海皆准的组织架构标准，更没有万能的可以解决任何问题的组织架构设计 需要不断的与自己所在团队和业务的特点去匹配和契合 这是一个不断变化的过程，也是需要持续调整的过程

4.2 Google SRE 的运维模式

SRE的岗位定位

SRE的岗位职责

管理上，涉及服务质量指标（SLI，SLA，SLO），发布规则，变更规则，应急响应机制，On-Call, 事后复盘机制等一系列的管理规范和标准制定

技术上，以支持和实现上述标准和规范为目标，涉及自动化，发布，监控，问题定位，容量定位，以电子流串联各个环节，实现事件的闭环

自动化：通过减少认为的，频繁的，重复的线上操作，来大大减少因为认为失误造成的故障，同时提升效率（kubernetes)

持续交付

问题定位，google的Dapper 涉及全链路跟踪和分析，限流降级，开关和预案系统，强弱依赖等

各类分布式系统（分布式锁，分布式文件，分布式数据库）

借鉴和落地

4.3 运维的服务意识

google 新岗位 CRE 翻译 客户稳定性工程师

• CRE 的产生背景
  • 越来越多的公司将自己的业务迁移到云上，基础环境不在可控，客户变得焦虑
• CRE的岗位职责
  • 消除客户焦虑，真正的站在客户的角度去解决问题，对客户进行安抚
  • 和客户一起排查，问题不解决，自己不撤退，随时通报进展，必要的时候将故障升级到更高级别，寻求更专业的资源投入以共同解决
  • 跟客户沟通传递一些稳定性保障知识
  • CRE即具备良好的专业技术能力，又有非常强的问题解决能力，优秀的的客户沟通和关怀能力
• 运维为什么要有服务心态
  • 日常工作中不断提升自己的服务意识
  • 很多问题都是因为服务意识不够而导致的
  • 具体的改进措施
    • 多用业务术语，少用技术术语，用对方能够听得懂的表达方式表达技术观点
    • 挖掘问题背后真正的诉求
      • 为什么要这样做
      • 是谁要求做这件事情的
      • 这样的目的是什么
      • 这样做是为了解决什么问题
    • 解决问题时关注目标而不是聚焦困难(下图) 运维要不断提升自己的技术能力，另一方面也要注意培养自己的服务意识，让自己的能力得以发挥，创造更大的价值

l136kf5e.png

4.4 云计算和AI时代下的运维转型

随着日常重复的人工操作被逐步自动化之后，如果还是固守原有的工作模式和思路，能做的事、能提供的价值，就一定会越来越少

• 案例
  • 国外的netflix模式，强调自助化运维
  • 国内阿里巴巴的模式，“去PE”的组织架构调整，初期靠人，后期靠平台
• 应用运维的转型
  • 学会写代码，具备代码开发能力，已经成为一项必备技能
  • 即懂业务，又懂开发，更具竞争力
  • 代码开发上，建议从python、php或Go这些上手比较简单的语言开始
  • 提升产品意识，改变被动响应模式
  • 提升技术运营仪式
    • 把承载了标准化和规范体系的工具平台真正落地应用起来，同时在落地过程中，进行问题收集和一定数据分析，再回到产品设计和需求实现的流程中进行改进，形成良性的闭环
• 云计算和AI带来的挑战
  • AI的一种实现方式---机器学习算法
  • AI和ops的结合，更多是场景驱动的
  • 机器学习算法是离不开场景和业务特点的，懂线上运维实际情况的人做这件事情，会更加合适

总结，传统的SA（系统管理员，系统运维工程师）网络工程师会更加收敛，一方面是岗位设置上会收敛到各大云平台厂商哪里，做专职的基础和后端的服务维护。随着自动化的完善，在岗位数量上也会收敛，不会再出现大批量的岗位需求。岗位的价值空间以及成长空间，将变得极为有限。

本文共 6811 个字数,平均阅读时长 ≈ 18分钟