01 运维的初心
可用性是运维的基础,当服务不可用时,运维做的任何工作都是0。
运维可用性能力的三个阶段
-
救火阶段
-
防火阶段
-
放火阶段
救火阶段
核心模块的MTTR(故障恢复时间)不要超过20分钟,这听起来很简单,但在可用性的初级阶段,一般处于这个阶段的运维人员,处理故障流程是:收到告警,连接vpn,定位故障,故障修复,整个流程中,占用时间较长的是定位故障,这取决于对服务间调用关系的理解以及运维经验是否足够多,在这个阶段比较依赖于个人能力。
防火阶段
当处于防火阶段时,运维人员需要更多精力去做预案管理、服务高可用能力、灾备、告警自动化处理、服务降级等事情,处于这个阶段的故障处理流程,一般会在定位故障前,就能发现是哪个服务、哪个模块、哪个机房发生了问题,通过预案、切流等手段先将服务恢复或降级,在这个阶段MTTR时间要远远小于第一阶段,因为服务已经提前做了止损操作。
当处于防火阶段时,运维人员需要更多精力去做预案管理、服务高可用能力、灾备、告警自动化处理、服务降级等事情,处于这个阶段的故障处理流程,一般会在定位故障前,就能发现是哪个服务、哪个模块、哪个机房发生了问题,通过预案、切流等手段先将服务恢复或降级,在这个阶段MTTR时间要远远小于第一阶段,因为服务已经提前做了止损操作。
放火阶段
运维要做的是尽可能的保证线上服务的稳定性,为什么要自己把自己的服务搞死?
放火的前提:至少已经度过救火阶段且部分故障已经有明确的操作方法和规范,保证运维的工作已经足够游刃有余。
如何做:前期人工制造故障,进行故障演练。针对线上的服务进行故障演练,通过故障演练可及时发现故障造成影响、故障处理流程是否符合预期。
误区:蓝军负责制造故障,红军负责修复故障。相互之间不可以沟通。否则变成了小孩子过家家,毫无意义。
故障演练流程:切走大部分流量 -> 制造故障 -> 人员介入处理 -> 故障恢复 -> 流量恢复 -> 复盘
长期:通过平台的方式,在不提前通知的情况下,通过平台在线上不定期制造故障(例如netflix的Chaos Monkey系统)。
我们总是在聚焦在防火阶段,不希望我们的系统出现故障这本身没有问题,但是没有任何一个系统可以做到100%可用,我们的系统一定存在某些不稳定因素,当这些因素积累到一定程度爆发出来时,我们的工程师们是否记得如何处理故障?如果一个极其稳定的系统发生大故障,损失可能是灾难性的。所以防火做好了之后要自己经常去放一些小火。通过主动的制造故障,发现未知的问题和隐患,进而更加的保障系统的稳定性,甚至从软件设计之初就考虑到服务可用性。通过不断的制造故障,使得系统具备反脆弱性。
02 持续提高可用性
以可用性为目的,我们可以渗透到大量的有价值的工作中。
例如:
-
线下(开发环境、测试环境、预发布环境)
-
发布 (灰度发布、分级发布)
-
快速止损
解决变更带来的可用性隐患
从广义上来说,任何故障都来源于【变更】,变更不仅仅包含代码的变更、环境的变更同时也包含网络的变更、硬盘由正常变更为异常、系统在执行过程中某个指标由于积累到一定程度导致的故障等等。我们需要做的是这些变更在发生时如何快速搞定。
例如平时需要定位问题的时候,很久都定位不出来,最终花了很久才发现是一个很不相关的指标发生异常才引发出来。有经验的人可能凭直觉就能猜到可能是哪个地方发生故障。
- 没有经验的人无法快速查到问题。
- 运气成分占比较大,可能猜到也可能猜不到,猜不到的时候MTTR时间就不可控。
系统实时状态运行图:通过运维数据可视化、操作标准化,将系统指标、线上配置指标、产品对应的指标通过屏幕进行展示。使得所有变更一目了然,历史指标数据可查。(例如grafana+prometheus)
03 运维的目的
如何才能体现自己的价值?
技术指标不等于业绩指标