A. 运维体系：SRE/CRE

A. 运维体系 — SRE/CRE

体系

• 核心：应用
• 标准化
  • 核心
    • 识别对象
    • 识别对象属性
    • 识别对象关系
    • 识别对象场景
  • 基础设施标准化
    • 识别实体对象
      • 主要有服务器、网络、IDC、机柜、存储、配件等
    • 识别对象的属性
      • 比如服务器就会有 SN 序列号、IP 地址、厂商、硬件配置
      • 网络设备如交换机也会有厂商、型号、带宽等信息
    • 识别对象之间的关联关系
      • 比如服务器所在的机柜，虚拟机所在的宿主机、机柜所在 IDC 等简单关系；
      • 复杂一点就会有核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的级联关系等，这些相对复杂一些，也就是我们常说的网络拓扑结构
    • 识别对象场景
      • 还是以服务器为例，我们针对服务器的日常操作有采购、入库、安装、配置、上线、下线、维修等等
  • 应用层面的标准化
    • 识别实体对象：指的是应用
    • 识别对象属性
      • 应用的元数据属性
      • 应用代码属性
      • 应用部署模式
      • 应用目录信息
      • 应用运行脚本
      • 应用运行时的参数配置
    • 识别对象关系
      • 应用与基础设施的关系
      • 平行层面的应用与应用之间的关系
      • 应用与各类基础组件之间的关系
    • 识别应用的运维场景
      • 这个就会比较多了，比如应用创建、持续集成、持续发布、扩容、缩容、监控等；
      • 再复杂点的比如容量评估、压测、限流降级等。
• 基础架构标准化：对基础架构组件做了统一标准之后
• 基础架构的服务化
  • 目标是平台自助化，让开发依赖平台的能力自助完成对基础组件的需求，而不是依赖运维的人

核心组件

• CMDB 是面向资源的管理，是运维的基石
  • 第 1 步，把服务器、网络、IDC、机柜、存储、配件等这几大维度先定下来；
  • 第 2 步，把这些硬件的属性确定下来，比如服务器就会有 SN 序列号、IP 地址、厂商、硬件配置（如 CPU、内存、硬盘、网卡、PCIE、BIOS）、维保信息等等；网络设备如交换机也会有厂商、型号、带宽等等；
  • 第 3 步，梳理以上信息之间的关联关系，或者叫拓扑关系。比如服务器所在机柜，虚拟机所在的宿主机、机柜所在 IDC 等简单关系；复杂一点就会有核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的级联关系；
  • 第 3.5 步，在上面信息的梳理过程中肯定就会遇到一些规划问题，比如，IP 地址段的规划，哪个网段用于 DB，哪个网段用于大数据、哪个网段用于业务应用等等，再比如同步要做的还有哪些机柜用于做虚拟化宿主机、哪些机柜只放 DB 机器等。
  • 第 4 步，基于这些信息进行流程规范的建设，比如服务器的上线、下线、维修、装机等流程。同时，流程过程中状态的变更要同步管理起来；
  • 第 5 步，拓扑关系的可视化和动态展示，比如交换机与服务器之间的级联关系、状态（正常 or 故障）的展示等，这样可以很直观地关注到资源节点的状态。
• 应用配置管理是面向应用的管理，是运维的核心
  • 应用基础信息，如应用责任人、应用的 Git 地址等；
  • 应用部署涉及的基础软件包，如语言包（Java、C++、GO 等）、Web 容器（Tomcat、JBoss 等）、Web 服务器（Apache、Nginx 等）、基础组件（各种 agent，如日志、监控、系统维护类的 tsar 等）；
  • 应用部署涉及的目录，如运维脚本目录、日志目录、应用包目录、临时目录等；
  • 应用运行涉及的各项脚本和命令，如启停脚本、健康监测脚本；
  • 应用运行时的参数配置，如 Java 的 jvm 参数，重要的是 GC 方式、新生代、老生代、永生代的堆内存大小配置等；
  • 应用运行的端口号；
  • 应用日志的输出规范；
  • 等等

运维基础平台体系建设

分布式中间件的服务化建设

持续交付体系建设

• 关键点
  • 配置管理
  • 需求拆解
  • 提交管理
  • 构建打包
  • 自动化测试
  • 部署发布
• 配置管理
  • 版本控制
  • 依赖配置
  • 软件配置
    • 代码配置
    • 应用配置
  • 环境配置
• 环境建设
  • 环境分类
    • 线下环境
      • 开发环境
      • 集成环境
      • 项目环境：针对大项目的测试环境
      • 预发环境
    • 线上环境
      • Beta环境
      • 生产环境
  • 关键点
    • 网段规划
    • 服务化框架的单元调用
    • 环境的域名访问策略
    • 自动化管理
• 提交管理
  • 主干开发模式
  • gitflow开发模式
  • 分支开发模式

稳定性体系建设

• 极端业务场景
  • 可预见场景：双十一、大促等等
  • 不可预见场景：微博热点等等
• 应对策略
  • 容量规划
• 故障管理：故障是常态
  • 故障定级
    • NOC团队：职责
      • 故障复盘
      • 故障定级
  • 故障定责
    • 变更执行
    • 服务依赖
    • 第三方责任
  • 故障追责：切忌上纲上线
    • 原则：鼓励做事，而不是处罚错误对于故障，一定要有容忍度，一定要有耐心
    • 高压线
      • 未经发布系统，私自变更线上代码和配置；
      • 未经授权，私自在业务高峰期进行硬件和网络设备变更；
      • 未经严格的方案准备和评审，直接进行线上高危设备操作，如交换机、路由器防火墙等；
      • 未经授权，私自在生产环境进行调测性质的操作；
      • 未经授权，私自变更生产环境数据信息。
  • 故障应急
    • 业务恢复预案
      • IDC 层面
      • 系统层面
      • 应用层面
    • 有效的组织协调
      • 确定故障影响面及等级
      • 组织应急小组
      • 信息通报
  • 故障复盘
    • 召集复盘会议
    • 组织会议流程
      • 故障简单回顾
      • 故障处理时间线回顾
      • 针对时间线进行讨论
      • 确定故障根因
      • 故障定级定责
      • 发出故障完结报告
    • 对故障定级定责
    • 明确后续改进行动及责任人，录入系统并定期跟踪

技术运营体系建设

• 需要有服务意识
  • 多使用业务术语，少使用技术术语
  • 学会挖掘问题背后的真正诉求
  • 解决问题的时候关注目标，而不是聚焦困难
• 技术产品：能够将需求讲清楚
  • 是不是能够把原本靠人工完成的很多工作转化成需求
  • 是不是能够把日常工作中运维和开发的痛点转化成需求
  • 是不是能够把当前系统存在的问题和隐患找出来，在解决的过程中，经过分析总结提炼成需求
• 能够将产品落地
  • 平台推广落地
  • 线上运行数据分析
  • 过程改进