01 运维的初心

可用性是运维的基础，当服务不可用时，运维做的任何工作都是0。

运维可用性能力的三个阶段

1. 救火阶段
2. 防火阶段
3. 放火阶段

救火阶段

核心模块的MTTR（故障恢复时间）不要超过20分钟，这听起来很简单，但在可用性的初级阶段，一般处于这个阶段的运维人员，处理故障流程是：收到告警，连接vpn，定位故障，故障修复，整个流程中，占用时间较长的是定位故障，这取决于对服务间调用关系的理解以及运维经验是否足够多，在这个阶段比较依赖于个人能力。

防火阶段

当处于防火阶段时，运维人员需要更多精力去做预案管理、服务高可用能力、灾备、告警自动化处理、服务降级等事情，处于这个阶段的故障处理流程，一般会在定位故障前，就能发现是哪个服务、哪个模块、哪个机房发生了问题，通过预案、切流等手段先将服务恢复或降级，在这个阶段MTTR时间要远远小于第一阶段，因为服务已经提前做了止损操作。

放火阶段

运维要做的是尽可能的保证线上服务的稳定性，为什么要自己把自己的服务搞死？

一个系统很长时间保持稳定，一定隐藏了着灾难性的故障（黑天鹅事件），稳定了很多年的服务，运维、开发人员无处理经验，会导致大问题。

放火的前提：至少已经度过救火阶段且部分故障已经有明确的操作方法和规范，保证运维的工作已经足够游刃有余。

如何做：前期人工制造故障，进行故障演练。针对线上的服务进行故障演练，通过故障演练可及时发现故障造成影响、故障处理流程是否符合预期。

误区：蓝军负责制造故障，红军负责修复故障。相互之间不可以沟通。否则变成了小孩子过家家，毫无意义。

故障演练流程：切走大部分流量 -> 制造故障 -> 人员介入处理 -> 故障恢复 -> 流量恢复 -> 复盘

长期：通过平台的方式，在不提前通知的情况下，通过平台在线上不定期制造故障（例如netflix的Chaos Monkey系统）。

故障处理的误区：

我们总是在聚焦在防火阶段，不希望我们的系统出现故障这本身没有问题，但是没有任何一个系统可以做到100%可用，我们的系统一定存在某些不稳定因素，当这些因素积累到一定程度爆发出来时，我们的工程师们是否记得如何处理故障？

如果一个极其稳定的系统发生大故障，损失可能是灾难性的。所以防火做好了之后要自己经常去放一些小火。通过主动的制造故障，发现未知的问题和隐患，进而更加的保障系统的稳定性，甚至从软件设计之初就考虑到服务可用性。

通过不断的制造故障，使得系统具备反脆弱性。

02 持续提高可用性

以可用性为目的，我们可以渗透到大量的有价值的工作中。

例如：

1. 线下（开发环境、测试环境、预发布环境）
2. 发布 （灰度发布、分级发布）
3. 快速止损

解决变更带来的可用性隐患

从广义上来说，任何故障都来源于【变更】，变更不仅仅包含代码的变更、环境的变更同时也包含网络的变更、硬盘由正常变更为异常、系统在执行过程中某个指标由于积累到一定程度导致的故障等等。我们需要做的是这些变更在发生时如何快速搞定。

例如平时需要定位问题的时候，很久都定位不出来，最终花了很久才发现是一个很不相关的指标发生异常才引发出来。有经验的人可能凭直觉就能猜到可能是哪个地方发生故障。

靠猜来排查故障会带来两个问题：

1. 没有经验的人无法快速查到问题。
2. 运气成分占比较大，可能猜到也可能猜不到，猜不到的时候MTTR时间就不可控。

如何解决靠猜来查故障？

系统实时状态运行图：通过运维数据可视化、操作标准化，将系统指标、线上配置指标、产品对应的指标通过屏幕进行展示。使得所有变更一目了然，历史指标数据可查（例如grafana+prometheus）。

03 运维的目的

运维工具、自动化、平台化都是手段，但不是目的。

我们的目的是在一个产品漫长的生命周期中不断为产品加强或者发挥出产品的价值，从而提升运维人员对于这个产品的价值。

运维人员如果跟别人的印象只是很辛苦，那并不是运维的价值所在，我们要想办法发现辛苦的源头是什么？是流程不合理？还是运维效率低下？我们应该要功劳而不是靠苦劳博同情。

如何才能体现自己的价值？

日常汇报中不要写做了什么，而要说做了这样的事情，为团队产生了什么样的价值和收益，这件事继续做下去空间是什么，怎样做才是极致的状态。

技术指标不等于业绩指标

qps、load等等都是技术指标。需要想办法转换成产品核心指标（收入、PV、品牌影响力）例如（基于这样的优化，我们整个集群可以承载的产品的数量可以达到什么水平，对应投入的资源成本会发生哪些变化）。

可用性是运维人的脸面，也是这个职位存在的意义，在保证可用性的前提下，不断为产品创造价值。才称得上是一位合格的互联网运维工程师。