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 层面
系统层面
应用层面
有效的组织协调
确定故障影响面及等级
组织应急小组
信息通报
故障复盘
召集复盘会议
组织会议流程
故障简单回顾
故障处理时间线回顾
针对时间线进行讨论
确定故障根因
故障定级定责
发出故障完结报告
对故障定级定责
明确后续改进行动及责任人，录入系统并定期跟踪
技术运营体系建设
需要有服务意识
多使用业务术语，少使用技术术语
学会挖掘问题背后的真正诉求
解决问题的时候关注目标，而不是聚焦困难
技术产品：能够将需求讲清楚
是不是能够把原本靠人工完成的很多工作转化成需求
是不是能够把日常工作中运维和开发的痛点转化成需求
是不是能够把当前系统存在的问题和隐患找出来，在解决的过程中，经过分析总结提炼成需求
能够将产品落地
平台推广落地
线上运行数据分析
过程改进