运维工具真的很容易做吗

在从研发转到运维之前，我一直就觉得运维工具这东西，应该是相当简单的，但在我自己带领一个运维工具团队一年多后，完全颠覆了我自己以前对运维工具的认知，才真正明白了运维工具这东西要做好，对技术的要求其实是极高的。

之前之所以觉得运维工具简单，是因为从在线业务系统角度来看，运维工具访问量低，数据量也很小，完全看不到什么技术难点。

在带领一个运维工具团队一年多后，看到的是运维工具系统对技术的要求其实和在线业务系统只是角度不同而已，先看看运维工具系统主要承担的职责：

1. 运维操作的自动化；

2. 线上故障出现时救命操作的执行；

这两个职责决定了在运维工具系统设计时除了功能实现外需要考虑一些非功能特性：

1. 运维操作的自动化

自动化要真正做到，有一个核心的关键指标：成功率，可以想象下，如果一个自动化的运维操作的成功率只能做到60%，那对用的人来说体现出来就是10次操作失败4次，这种情况下多数会造成的结果就是用户就不用了，因为用户会觉得还不如手工操作来得快，因此运维操作要真正做到自动化，必须确保成功率，这点和在线业务系统更不一样，在线业务系统对单次操作的成功率的要求会远比运维工具系统低，而且在线业务为了确保操作的响应时间等，fail-fast是在线高可用系统的基本策略。

一个复杂的运维操作，例如应用扩容机器，和在线业务系统其实很像，也是要操作N个其他的系统，业务逻辑也很复杂，是一次巨复杂的分布式操作，要保障好成功率，就意味着在A调用B出现异常的时候，得决定后续的动作，有可能需要做重试、跳过（有些可能还需要在完成后再异步操作什么的）再等动作，因此运维工具系统在依赖出异常时的处理策略必须做的非常清楚，尽可能确保成功率。

从这点可以看到，设计运维工具系统时需要更加趋向保障单次操作的成功率上，在各种异常出现时需要有各种处理策略，这和设计大多数在线业务系统是完全不一样的。

2. 线上故障出现时救命操作的执行

线上故障出现后，通常会非常依赖运维工具系统来处理故障，例如监控、发布、切流量等等，而如果在故障出现的时候这些运维工具也出问题，那就悲剧了，记得我们在很早以前讨论系统的一个救命招怎么实现时，一开始谈到了好几个高大上的方案，但最后选择了一个极为土的方案，原因就是因为这是救命招，基本就是能不依赖就不要依赖任何其他东西。

按照这样的要求，运维工具系统中如果是对于线上故障出现时属于救命型的操作，必须确保绝对的稳定，不论是小的故障，还是大到机房的故障，救命操作的系统都得保证绝对的稳定。

而且通常来说，一个救命操作看似一个简单按钮，但背后对应的多数都是N套系统的联动，怎么保障这个看似简单的按钮完全的可信赖，背后是有大量的事情需要做的。

因此从对运维工具系统需要承担的职责分析来看，在技术上运维工具系统其实也是有相当高的要求的，怎么样能保障好成功率、救命操作简单按钮的绝对稳定可靠，是运维工具系统必须做到的。

顺带再说下规模的事，简单举一个例子是可能很多小一些的业务场景里很难碰到发布量本身会变得很大的状况，而在我们的场景里曾经多次碰到过发布系统本身支撑能力不够导致的各种临时找办法的状况，因此对于运维工具系统来说，同样也必须做到知道当前系统能够承受的压力范围，以及怎么水平扩展。

所以，小看了运维工具系统的同学们，包括从前的自己，请正视运维工具系统面临的技术挑战，有兴趣的同学欢迎一起加盟来挑战！

最后，再次推荐下6年前黄易山讲在FB的工程管理心得中很重要的一句话：Tools Are Top Priority，文章请点击阅读原文查看。