稳定性保障所需的一些措施

要严格保证SLA,SLR,很多人会拆解为降低MTTD,MTTR,网上关于他们的定义很多,比如:

  • Mean Time To Detect(MTTD)=(故障得到定位的时间-故障提交时间)的平均值
  • Mean Time To Restore /recovery (MTTR) = 故障恢复时间的平均值

MTTR不够清晰,加上二者并未覆盖所有阶段,因此我拆分为如下六个阶段: 0. 预防

  1. 发生到发现
  2. 发现到响应
  3. 响应到定位
  4. 定位到解决
  5. 复盘与改进

当然,在实际工作中往往会先尝试优先恢复业务,再去定位。但就日常的工作开展而言有个范畴会好一些,而且将上述环节做好,可以在极端情况下业务没办法先恢复我们只能按部就班一步步排错时,提供更多支撑和帮助。为此我当时还画了个图。。

比如,0-1都很依赖监控和报警,老生常谈但做好却又很难,比如监控的覆盖率在深度上就少不了APM类的能力,在广度上,就要与时俱进,保持与当前架构的一致,比如:

  • 引入PrometheUS后就逐步淘汰zabbix上重合的基础监控。
  • 引入k8s后就需做容器、相关组件、事件的监控。
  • 健全日志系统后就开始着手日志监控

这里我们实践了k8swatch

而报警方面,则是几个基本功能:确保能发出去,知道发给谁,别发太频繁,有记录。

  • 多渠道告警,各渠道均有备份
  • 容量保障,不同渠道可能有限额,需根据此做保护。
  • 若有些报警不知道具体接收人,应根据类别、tag实现人员关联
  • 通过缓存等手段做一些基本的降噪。
  • 做记录

这里我们实践了alert-speaker 比如,3响应到定位,除了丰富的经验还要有趁手的工具:

当SRE收到告警,开始定位或尝试解决问题,首先需要弄清楚故障的来龙去脉,上下文,或说是关联的资源。 这里我们实践了chatops实践

当然,除了响应式的准备工作,还可以主动出击将问题扼杀在萌芽中,面对不稳定因素,作出计划去升级或优化代码以解决,总之在稳定性保障这条路上,要做的还有很多,慢慢更新。。