一、SRE将替代传统运维工作

改变之前靠人去做运维的方式，转而通过工具体系、团队协作、组织机制去搭建新的运维体系，运维与开发将在同一起跑线上。

SRE核心是用软件工程的方法重新设计和定义运维工作。


二、微服务架构以应用为核心

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

1.建立各个基础设施和组件的数据模型，同时识别出它们的唯一标识。

2.识别出的基础设施以及组件可以与应用名appname建立关联关系，或者在基础组件数据模型中增加所属应用字段。如通过外键关联模式建立应用与缓存空间关联关系。


三、标准化体系建设

标准化对象套路

1.识别对象---服务器、网络、机柜、存储

2.识别对象属性---服务器有SN序列号、IP地址、厂商、硬件配置

3.识别对象关系---服务器所在机柜、虚拟机所在宿主机、机柜所在IDC等关系。核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间关系。

4.识别对象场景---服务器的日常操作有采购、入库、安装、上线、下线、维修。

标准化应用

1.设计阶段应用应该被识别和确认下来。

2.应用有业务和运维两个属性，业务由架构师识别，运维属性由运维识别。

    应用的元数据---应用名、应用owner、所属业务、应用功能说明

    应用代码属性---编程语言以及版本，GitLab地址。

    应用部署模式---软件包，如Java、C++；容器如Tomcat、JBoss

    应用目录信息---运维脚本目录、日志目录、应用包目录、配置文件目录、临时目录。

    应用运维脚本---如启停脚本、健康监测脚本；

    应用运行时参数配置---运行端口、JVM的GC方式、堆内存大小配置。

3.应用与外部关系

    应用与基础设施关系---应用与资源、应用与VIP

    平行层面的应用与应用关系---应用服务或API依赖关系

    应用与各类基础组件关系---应用与缓存、应用与消息、应用与DB

4.应用运维场景

   应用创建、持续集成、扩容、锁容、监控、容量评估、压测、限流降级。

运维职责第一步为基础架构的标准化，如：数据库只允许用MySQL并且版本统一；第二步是基础架构的服务化，如：组件提供的维护API进行封装，以提供更佳便捷的运维能力。

四、应用运维体系建设

人类从出生到死亡就是一个生命周期，在这个周期的每个阶段，我们都会有不同的属性、关系和所要面对的场景。

应用的生命周期大致分为五个阶段，应用的创建阶段、研发阶段、上线阶段、运行阶段、销毁阶段。

运行阶段要制定每个运维对象的SLI、SLO、SLA，建设对这些指标能够监控和报警的监控体系。

应用销毁，某个应用业务职责不存在了，需要对应用所产生出来的基础设施、基础服务以及关联关系要一并清理，否则会给系统造成无源的资源浪费。

从生命周期入手，划分阶段，提炼属性，理清关系，固化基础信息，实现运维场景。

五、标准固化CMDB配置管理

CMDB配置管理数据库，是与IT系统所有组件相关的信息库，它包含IT基础架构配置项的详细信息。

CMDB是面向资源的管理，是运维的基石；应用配置是面向应用的管理，是运维的核心。

资源管理：

1.服务器、网络、IDC、机柜

2.硬件的属性，如服务器的SN序列号、厂商、硬件配置(CPU/MEM)

3.确定服务器所在机柜，虚拟机所在宿主机

3.5. IP地址段规划，哪些机柜用于做虚拟化宿主机，哪些机柜只放DB机器。

4.流程规范建设，服务器上线、下线、维修、装机。

5.交换机与服务器级联关系，状态展示。

应用配置：

1.应用名-IP关联关系

2.应用基础信息，如应用Git地址

3.应用部署涉及的软件包

4.应用部署涉及的目录

5.应用运行涉及的脚本

6.应用运行时的参数配置

7.应用运行时端口号

8.应用日志的输出规范

六、CMDB配置管理落地

应用组织管理：产品线-业务团队-应用

应用名定义规范：应用名必须以大小写英文字母以及下换线组合；应用名长度不超过40个字符，简单易懂。

应用组织分组：应用-集群服务分组-资源

多环境问题、多IDC问题、多服务分组问题；多服务分组依赖应用优先级，两个因素决定，核心应用和非核心应用，思考应用出现故障是不是会影响业务收入，如果影响就属于核心应用，这种属于静态调整。场景因素，秒杀场景不同阶段会有IC的大促秒杀分组，这种属于动态调整。

CMDB会保存“应用-分组-资源”对应关系，为以下场景的基础依赖。

1.监控系统

2.发布系统

3.服务化框架

4.基础服务(应用于资源的对应关系)

   核心资源要做ACL访问控制，对于交易支付敏感数据，其数据库不允许随意连接，仅限于授权过的应用访问。

5.稳定性保障平台(服务治理)

   为了保护系统稳定性，会在应用中做降级限流和开关的预案。

七、打造运维组织架构

考虑如何打造和体现出整个技术架构的运维能力，而不是运维的运维能力。

1.从价值呈现的角度看运维

  回归效率、稳定和成本这三目标

  • 运维基础平台体系建设

      标准化体系、CMDB、DNS域名管理、资源管理等偏向运维自身体系。

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

      分布式中间件服务起到了支撑作用。

  • 持续交付体系建设

     提升整个团队效率的关键部门，包括从应用创建、研发阶段的持续集成，上线节点的部署发布，线上运行各类资源扩缩容，应用下线的资源回收。

  • 稳定性体系建设

     如何快速发现线上问题、如何快速定位问题、如何快速从故障中恢复业务、如何有效评估系统容量等等。如何对故障应急响应、如何对故障复盘、如何加强日常演练。

  • 技术运营体系建设

     确保我们制定的标准、指标、规则和流程能够有效落地。

八、SRE运维模式

      SRE【网站稳定性工程师】，是一个通过软件工程的方式开发自动化系统来替代重复和手工操作的岗位。

      SRE负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关工作。

      管理体系上：服务质量指标（SLI、SLA、SLO）、发布规则、变更规则、应急响应机制、事后复盘机制等管理规范和便准指定。

      技术体系上：以支持和实现上述标准和规范为目标，自动化、发布(持续交付)、监控、问题定位(服务治理)、容量定位以电子流程串联各个环节。

     CRE即要具备良好的专业技术能力，又要有问题解决能力，同时还要具有优秀的客户沟通和关怀能力。

     CRE更多的是一个服务性质的岗位。如何提升自己的服务意识？

    可分为三个方向：

     1.多使用业务术语，少使用技术术语。

        从业务的角度出发让业务适配技术。

     2.学会挖掘问题背后的真正诉求  

  •  为什么这样做
  •  谁要求做这件事情？
  • 这样做的目的是什么？解决什么问题？

     3.解决问题的时候关注目标，而不是聚焦困难