SRE从某种程度上来说是为了适应大型复杂团队中的运维需求而诞生的。
SRE是系统管理员、数据库管理员、应用运维工程师、运维工程师、开发工程师的合集。

SRE

SRE定位

工作着力点

  1. 将独立的运维人员由单一的任务承担角色转变为对线上系统稳定性负责的角色

  2. SRE团队必要再技术之外加强自己的沟通、说服能力

  3. SRE团队要注重以产品的角度看运维，而不是简单的完成业务的运维操作需求。

KPI的制订

  1. 运维工作项目化
  2. 运维项目评审
  3. 进度汇报和主动沟通

贡献价值

  1. 维持业务高效运作
  2. 提升资源利用率
  3. 减少业务中断

监控设计

监控系统的评价标准

  1. 稳定

    1. 数据源稳定
    2. 网络稳定
    3. 数据处理稳定
    4. 存储稳定

  2. 准确

  3. 易用

监控设计的逻辑分析

  1. 数据生产
    1. Agent
    2. 日志
  2. 数据上报
    1. 上报协议
    2. 推拉模型
  3. 数据处理
    1. 流处理
    2. 数据热点
  4. 数据存储
    1. HBase
    2. InfluxDB
  5. 数据使用
    1. 监控数据展示
    2. 监控数据报警
      1. 多指标和单指标
      2. 实时报警和离线报警
      3. 对外输出
  6. 应用场景
    1. 系统监控
      1. CPU
      2. 网卡流量
      3. 磁盘负载
      4. 上下文切换
    2. 应用监控
      1. 黑盒监控
      2. 白盒监控
      3. 中间件监控
    3. 终端监控
      1. 移动端、PC端和各类嵌入式设备
      2. 更复杂、延迟更高、影响更大
    4. 秒级监控
    5. 监控大盘
    6. 链路监控
  7. 报警治理
    1. 报警阈值
    2. 报警发送方式
    3. 发送目标
    4. 报警抑制
    5. 报警处理

变更管理

变更是万恶之源

变更管理

  1. 传统的变更管理
    1. 变更提出——Review评审——执行变更
    2. 传统的运维变更管理在指定规范时时中流程的，但在执行时又是轻流程的。
  2. DevOps的变更管理
    1. DevOps更加相信从代码提交到自动发布的CI/CD
    2. 变更侧重点倾向于代码开发和发布相关的流程和环节
  3. SRE的变更管理
    1. 引入ITIL的自动化
    2. 不同的业务适配不同的发布策略

变更控制

变更控制的设计原则：

  1. 基于变更人的背景、历史变更记录、变更类型，决定变更审批流程
  2. 基于业务模块的冗余程度和可靠性要求，决定变更审批流程
  3. 基于是否是业务活动期，决定变更审批流程
  4. 基于业务资源水位和变更错误率灯数据，决定变更审批流程

稳定性和迭代速度

变更管理和变更控制更像是一种处理逻辑，而不是精确计算的数学函数。在实际落地时，变更更多表现为和业务需求相关的一种控制考量，变更和团队管理的概念类似，讲究的是要根据实际情况，因地制宜的执行。对于业务而言，稳定性和迭代速度是整个变更管理的核心，所有的变更管理本质上是在寻找这两者的完美平衡点。
需要考虑的内容：

  1. 业务发展阶段：初期-速度优先 中期—速度优先兼顾稳定并建立制度 稳定期—稳定优先
  2. 业务体量
  3. 业务影响力

风险控制

  1. 不要评估“不可能”风险：聚焦业务变更风险，避免“脑暴”罗列所有风险
  2. 控制变更因素：一次只变更一个因素，如必须同时变更多个因素，则要多次独立执行

异常响应

  1. 困境:
    1. 运维角色负责领域割裂
    2. 运维跟进滞后于业务发展
  2. SRE处理方向：
    1. 规则统一、对于异常指标建立统一标准
    2. 持续对平台和工具进行建设，通过跟进业务需求，针对性调整工具和流程

定义

  1. 区分事件和事故
  2. 建立事故等级制度

响应流程

设计异常处理流程：

  1. 异常处理设计要求：
    1. 异常发现——问题跟进——问题升级——问题分析——问题通知——问题解决——问题后续跟踪
  2. 自动化处理workflow工作流：
    1. 监控发现——自动建立排查流程——自动预检——人工接手——自动通知报备——处理结果验收——处理结果同步到故障跟进平台
  3. 人工处理流程：
    1. 问题发现——跟进人指派——问题跟进——问题修复——结果同步/问题升级
  4. 注意事项
    1. 流程的各个节点运维必须有效，每个环节执行到位
    2. 流程尽量自动化、工具化、减少人为流程执行
    3. 流程围绕解决问题优先，需要让信息流流转得更快

值班

  1. 建立标准得值班反馈清单，清晰、明确的说明问题、相关信息内容和验证方法
  2. 将异常反馈整理成为结构化的信息
    1. 良好的沟通能力
    2. 异常类型分类
    3. 流程梳理和建立

应急沟通机制

  1. 分别指定问题排查人和信息同步人：启动应急沟通机制时，应当指定操作人、信息同步人、现场指挥决策人
  2. 信息定期同步：一方面要将问题同步到内部问题跟进群，同时也要要将其他成员的反馈信息进行分析判断后提供给问题排查人员
  3. 信息量足够，不过多解释：对问题的分析判断要及时反馈出去
  4. 需要定期进行内部演练

引入ROC

随着线上业务复杂度增加，运维团队必须要定位问题，问题原因调查引入了ROC(问题溯源，RootOfCause),实现RCA(问题分析，Root Cause Analysis)。SRE团队主要通过以下几点进行调查：

  1. 业务系统架构拓扑
  2. 监控平台
  3. 日志查询

运维治理

规范的指定和落地

SLA时业务团队对付费用户的法律承诺，SLO是业务团队想要达成的目标，SLI则是为满足SLO需要做到的技术指标

SLI

  1. 服务等级指标-Service Level Indicator：代表了业务的核心质量指标，反映了用户对服务的核心质量诉求
  2. 指标：
    1. 性能指标：延迟、吞吐量、处理速率、时效性
    2. 可用性指标：可靠性、故障时间、在线时间
    3. 质量指标：准确性、正确性、完整性、覆盖率

SLA

  1. 服务等级协议 Service Level Agreement，用于付费用户的场景，具有法律效力，免费用户不需要签订SLA
  2. 必须清晰、严谨
  3. 最好和SLO一致

SLO

  1. 服务等级目标 Service Level Objectives
  2. 承诺指标，既可以用于付费用户，也可以用于免费用户，可用于内部或者外部场景
  3. SLO以月、季度、半年、年为周期结算
  4. 当业务不满足SLI时，则会触发SLO计算
  5. 为每个团队设置SLO是促进公司管理的有效手段

故障预防

对于所有线上故障，最好的处理方式是防患于未然。

常见问题有：

  1. 容量问题
  2. 高可用架构和自愈设计问题
  3. 业务降级防护问题

解决方案：

  1. 推动技术方案统一
  2. 复用原有成熟方案

抑制不可控因素

  1. 落地变更管理、变更控制
  2. 运维检查清单建设
  3. 变更信息自动化协调工具建设
  4. 推动业务解耦合

Devops力推的小迭代、高频率发布模式从某种意义上说也是为了减少不可控因素，因为DevOps的核心是建设CI/CD的过程。

故障演练

故障梳理

常见故障预案问题：

  1. 不在评估期内的故障类型
  2. 故障预案执行有问题

故障预案

混沌工程

使用线上随机故障触发器角色，要求整个团队对每个组件的每个类型的故障都制订处理预案，而且强迫整个团队能制定预案和能执行预案。

攻击队(红队)策略 防御队(蓝队)策略 预案执行结果
攻击A模块的磁盘IO 隔离问题节点 符合预期
攻击B模块的CPU资源 隔离问题节点 符合预期
攻击C模块的网络资源和延迟 隔离问题节点 不符合预期，未及时发现
攻击D模块的RPC调用 隔离问题节点 符合预期
攻击A缓存 抓攻击IP，加黑 符合预期
执行D模块的SQL注入 抓慢SQL，杀查询 不符合预期，业务有影响

故障演练最终还是以故障预案平台的工具建设为主。

故障自愈

故障自愈不只是主从、多副本等部署，它代表的是一整套设计理念和运维想法。从落地方法和实现上说，故障自愈有多个层级：

  1. 基于主备的设计
  2. 基于负载均衡的设计
  3. 基于平台的设计
  4. 基于业务架构的设计

所有的自愈只是在某种程度上的自愈。故障自愈是所有SRE团队和开发团队对线上稳定性的最终追求，但并不意味着就不需要SRE团队和开发团队。它只是缓冲了故障对线上的影响，后续仍然需要修理故障点。

业务MTTR

为了评估故障修复时间，业界引入了MTTR(Mean Time to Repair)概念，是指产品从故障状态恢复可用到状态修复产生的平均时间。SRE团队的正常选择是执行平均故障修复时间优先的运维策略。故障修复策略选择的评估方式有以下：

  1. 业务中断损失评估
  2. 数据损失评估

只要业务层能够控制资金风险，宁愿用户只读到旧数据，也比用户无法访问页面好。

灾备建设

  1. 同机房灾备
  2. 同城双活
  3. 异地数据灾备
  4. 两地三中心
  5. 分布式多活

事故复盘

当一个团队缺乏良好的事故处理机制时，团队容易出现以下问题：

  1. 士气低落
  2. 运维与开发的对立
  3. 隐瞒线上问题

复盘

  1. 初级阶段
    1. 以资深Linux用户身份对线上操作，工作随性，触发故障
    2. 缺乏解决方案和处理思路
    3. 事故复盘不彻底、流于形式
  2. 中级阶段
    1. 使用技术博客阐述具体事故过程、处理团队思路，依赖写作者的表达能力和技术深度
    2. 复盘质量不高，缺乏有效的上下游沟通，不全面
  3. 成熟阶段
    1. ITIL规范框架落地，建设事故管理平台，建立事故处理流程
    2. 将运维、开发、测试、运营加入进来
    3. 针对细节进行执行
      1. 信息整理
      2. 跟进事项梳理

如何提高复盘质量

  1. 事故复盘深度
    1. 解决具体问题
    2. 解决单个业务问题
    3. 解决所有业务同类型问题
  2. 事故复盘报告

事故分析的逻辑和原则

事故分析是一个串行的流程。

  1. 分析监控数据阶段：具体问题节点的监控指标和应用日志
  2. 确定事故影响范围、完成对事故影响的初步评估
  3. 对业务逻辑进行深入分析，聚焦真实的问题节点（物理和逻辑）
  4. 定位事故原因

通过程序化实现事故复盘逻辑，快速故障根因定位，技术点有：

  1. 监控异常指标发现自动化
  2. 线上异常日志和监控指标解读关联分析

事故复盘原则：

  1. 事故复盘需要由事故跟进人主导
  2. 全面且深入的分析

责任划分

  1. SRE团队承担责任：基于运维规范和操作交叉审核
  2. 相关团队承担责任
  3. 第三方承担责任

事后跟进

  1. 细化事故跟进事项
  2. 定期追踪事故跟进事项
  3. 建立事故跟进表

基于事故/事件的学习

  1. 事故案例研讨会
  2. 事故情景模拟

容量管理

目标

  1. 成本控制
  2. 业务支撑

管理方法和策略

容量水位的定义

  1. 容量水位的2/8原则
  2. 系统峰值和容量水位的关系

管理策略

  1. 事前容量规划
  2. 事中容量监控
  3. 事后容量调整

容量分析系统建设

业务负载平台

  1. 了解当前资源总体负荷情况
  2. 每个类名资源的情况
  3. 当前资源瓶颈
  4. 资源的峰值

巡检管理平台

监控系统和CMDB系统

容量优化方式

业务容量优化

资源容量优化

  1. 云主机降配
  2. 混合部署
  3. 混部策略
  4. 网络带宽
    1. 外网带宽
    2. CDN带宽
    3. 专线带宽

架构容量优化

  1. 容灾级别分析和优化
  2. 熔断降级设计
  3. 过期数据的归档和删除
  4. 业务系统的性能优化
    1. 应用层优化
      1. 减少数据库交互
      2. 提升热点缓存命中率
      3. 异步调用
      4. 线程池优化
      5. 快速失败策略
    2. 数据库层
      1. 优化SQL
      2. 合适索引
      3. 读写分离
      4. 事务优化
      5. 分库分表
  5. 其他优化
    1. 测试服务资源机器的优化
    2. 服务器保修替换
    3. 硬件资源的精细化管理
      1. 建立固定的备机和备件池
      2. 定时监控服务器的负载
      3. 业务申请新的资源时先检查备件池

容量预案

  1. 明确的信息
  2. 操作简洁
  3. 操作安全可靠
  4. 预案的监控和后续评估
  5. 提前储备资源进行应急支撑

总结

容量管理是一个复杂的系统工程，不仅需要在策略、方法、方式上进行定义、明确和落地，还需要再组织、管理、流程上统一进行配合、协同。

  1. 设定容量管理目标
  2. 建立专门的容量管理虚拟项目团队和相应负责人
  3. 展开容量管理策略优化相关的业务和技术培训
  4. 建立容量管理的考核和奖惩机制，并持之以恒坚持下去。

用户体验

当传统运维团队转变为SRE团队之后，会从业务角度对整体进行稳定性考量，视角不同，考虑的点会更加全面，尤其需要对全站稳定性负责时，SRE团队非常关注运维操作和用户之间的影响关系。在评估运维变更影响时会直接跟进用户反馈数据、客服投诉等多种和业务稳定性相关的问题。同时，SRE团队开发了大量的工具和平台，所以就会引入用户体验的问题。而这个体验分为内部用户体验和外部用户体验。

外部用户体验

判断原则：外部用户反馈的问题是否和运维操作有关。常见问题有：

  1. 页面返回失败
  2. 页面内容错误
  3. 需求不满足

内部用户体验

内部用户反馈的问题虽然没有像外部用户一样直接影响业务，但是它会通过影响内部用户的做事效率，对项目开发的时间成本产生直接影响。SRE重视内部用户体验是为了能有更好的内部工作效率。

影响用户体验的要素

影响外部用户体验的要素

  1. 业务数据正确性
  2. 请求连续性
  3. 请求处理流程正确性

影响内部用户体验的要素

  1. 尽可能简化流程
  2. 隐藏复杂度
  3. 执行快速
  4. 数据可靠

改进用户体验

改进外部用户体验的策略

  1. 应用日志
  2. APM应用监控
  3. 用户投诉
  4. 舆情监控

改进内部用户体验的策略

  1. 数据兼容性
    1. 服务规划节点：内部用户需求调研、快速迭代功能模型让内部用户试用
    2. 服务运行阶段：定期手机内部用户需求，功能进行迭代调整
    3. 服务下线替换阶段：注意数据迁移
  2. 工作流程
  3. 执行效率
    1. 梳理效率低下的节点
    2. 推动自动化
    3. 关注的维度
      1. 执行时间长的任务
      2. 人工介入多的任务
      3. 不断被退回的任务

重点保障

最能体现一个团队运维水平的莫过于用一个重要的业务活动对整个团队的运维支撑能力进行验证。通过对多个重要业务活动的运维跟进，尤其深度稳定性保障，整个SRE团队将获得更快速的成长。

资源准备

容量规划

  1. 综合历史数据计算每个模块的性能指标
  2. 收集所有业务团队的服务器使用情况、服务处理性能，然后进行QPS指标细化
  3. 固化容量评估逻辑

交付规划

  1. 建立部署时间消耗统计信息
  2. 协调压测进度和采购进度
  3. 综合业务活动性能需求和资源消耗需求
  4. 规划服务器采购间隔和批次，拉长采购周期通过折旧计算节约成本

技术优化

SRE团队在整个重要业务活动准备过程中，在技术优化层面的参与度不比开发团队低，相比开发团队遇到问题喜欢选择使用新架构/新设计来解决问题，SRE团队更倾向于使用成熟解决方案去推动问题的解决。

参与运营活动评估

执行重保

准备阶段的工作重点

  1. 活动需求细化阶段：以容量规划和技术评估为主
  2. 准备工作执行期：明确业务模块性能需求，执行业务线压测
  3. 活动准备工作收尾：技术改造收尾、全站压测、模拟线上流量

重要业务活动的变更执行

  1. 变更执行精度要求
  2. 变更执行顺序要求

重要业务活动的运维人力

  1. 对开发团队赋能
  2. 进行工具建设
  3. SRE对重保最终会收敛到：
    1. 资源交付/容量设计
    2. 跨业务线的问题解决和定位

重要业务活动的收尾

  1. 资源的回收、服务的缩容、多余物理服务器的下线
  2. 活动日志数据的备份、分析解读以及监控数据的整理
  3. 对整个活动执行情况进行问题总结提炼

– END —