对待运维平台，要有「疯狗」一样的执行效率

从去年发起里程碑来做自动化平台的事情到现在，已经几个月过去了。在这段时间里，其实我的心态是很焦灼的。

其实从很多维度来说，做运维平台的事情，从不明朗的需求和定位开始，很难有说服力。

如果用业务价值的一把标尺来衡量，那基本没戏；如果从做这件事情的难易程度来说，很多人算是从入门到放弃；当然还可以有很多维度。

最直接的一个痛点就是纯运维的开发技能不够好，纯开发的运维背景不够，所以两者能够结合起来，算是一种互补，当然做这个事情要投入的精力，还有毅力，你们自己尝试去推动体验一下，还是有收获的。

如果说这个事情的转变，我觉得虽然慢了很多拍，好歹这个事情算是提上日程了，但是落地的情况虽然差强人意，相比于去年底的时候，已经有了很大转变。这里面要做一些工作，从上到下，从下到上。从上到下，就是从一个更高的角度来和领导谈这个事情，从意念上达成一个共识，在这个地方我觉得我犯了一个错误，那就是如果已经有很多显而易见的事实，我觉得就不需要去说服别人，说服领导了，但是恰恰在这个点上，我们还是要做一些推动力的，这个时候很可能就是信息不对称，我们认为重要，领导认为一般，结果导致了结果有了较大的偏差。

另外从下到上，其实就是事情怎么去做，算是一些具体的分工和安排了，最纠结的莫过于没人，没技术了。其实这个还不算最糟糕的，最糟糕的是大家认为这个事情还不够重要，先保持现状吧。这种时候我很焦躁，我们的价值在哪里。

原来是感觉有很多事情可以做，但是必要性不大，结果有了一些阶段性的讨论之后，基于各种因素吧，发现事情一旦有了转机，你就会发现有很多的事情可以做，值得做了。

所以车轮子转了起来，我觉得好歹就是进步了。

以上的可以理解是牢骚，也可以理解是一个苦逼的心路历程。对我来说，抱怨不够，要做解法，所以前期我的投入会很多，以至于我感觉我现在就是做运维开发的了。

运维开发以后怎么走，我觉得我们可以看看Google的路，运维开发一个很不错的方向：SRE

SRE的特质有两条：

1.对重复性，手工性的操作有天然的排斥感

2.有足够的技术能力快速开发出软件系统以替代手工操作

SRE的经验法则

“SRE团队必须将50%的精力花在真实的开发工作上”。

所以开发了几个月，平台搭建起来了，有了初步的系统功能，有了元数据的基本功能，做了一些基本功能的调试和使用，我发现事情开始有了变化。

我画个图来表达一下。

这可能是我眼中的运维平台，无论是数据库运维平台还是系统运维平台，大概念就是运维平台，我希望有树干（好的架构），绿叶（支持丰富的功能），果实（有产品的亮点）

结果做着做着发现好像和自己预期的不一样了。

发现是这样的情况，其实事实上比这个还要糟糕。

这是什么，有时候自己都犯嘀咕。对我来说，把以前的工作全盘否定也不太公平，所以，我决定做需求和功能的收敛。期望达到的这样的一个效果。

这是不是树，首先可以肯定说是，抓住几个亮点，有了好的设计，那么后续的工作要衔接起来就是一个迭代的过程。

所以我希望的结果是这样的，那些果子可能是一些目前要解决的痛点。

所以在我的脑海里闪出了一句话，可能听起来不大好，我决定叫它是“疯狗一般的执行速度”。

有了前面的思考之后，我发现其实我虽然实现了一些基本功能，但是面对复杂的运维场景的时候还是有些乏力。

我又画了一个图，这次是个技术图。通过这个图我可以做很多的总结和思考。

假设通过左侧的运维机器要访问数据库，有很多中路径可做。

中间的是中控机器，也可以理解是代理服务器，右上角的是DB服务器，右下角的是DB服务器中的数据库。

比如通过运维机器来访问数据库，我们有很多的路径可选。

如果面对的场景不确定如何能够做到一种灵活的插件方式呢。

我计划分成几个维度，运维机器-Ops,中控-CM,DB服务器-host,DB实例-DB

那样下来就可以拆分，比如ops_to_cm

cm_to_host,host_to_db,ops_to_db,ops_to_host等等

对于每一个路径或者分支我们可以使用多种技术来实现，到时候串联起来即可，比如Ops_to_db如果使用程序脚本逻辑的方式，那么sql的方式就满足不了了，我们可以使用ops_to_host,host_to_db,或者加一层中控，ops_to_cm,cm_db来实现，

当然方法有很多种，我们来适配即可。

所以这个地方如果抽象出来，然后单独实现，我觉得能够解决一些通用的问题，所以在这里我把它做概念提取，这就是一个工具管理的功能。

上面的方式其实主要侧重点是接入管理，如果我们做针对性的管理，比如系统管理，数据库管理，其实就可以做很多的细分了，这样一来，我们拼接出的工具就好比是一个乐高玩具，堆叠出很多的玩法来。

我设计的一个初步的demo是下面这样的。

说到这里一定要提一下原型设计的重要性，这个也是我走过的弯路之一。

这是我最近整理的一个运维开发的流程图。原型设计还是很重要的，如果原型设计没想明白就开始很具体的数据库设计，那么后面要返工的可能会非常高。

这个图建议大家好好理解一下，可能我的理解有偏差，希望你能够提出宝贵的建议来。

所以把之前的工作如果再做一层高度的提取，我觉得要做的应该会分为两大部分，一部分是通用平台，另一类是业务运维支持。

所以通用模块我的想法应该是能够普世很多业务场景，我们经过讨论，目前补充的会是下面的一些通用模块。

而从基础运维来说，比如数据库运维来说，就是一些具体的业务场景了，比如:

1. 数据库一键部署
2. 数据库备份模块
3. 数据库恢复模块
4. 一键搭建从库模块
5. 服务开通模块

基础打牢了，后面可以做高可用，分布式，SQL审核等等。

这些工作有些已经做差不多了，有些还没有开始，所以要继续我开始说过的，我们需要“疯狗一般的执行效率”

所以这个里程碑里我计划要实现的就是这些基础的事情。如果这个时候我强调这是一个很重要的转折点，大家可能就理解了。

通用模块中我比较喜欢的是任务调度，我觉得如果做好，能做太多的事情了，甚至会激发出一些很亮点的功能，当然我现在想的很好，手底下不停使唤，所以我还是会做好规划，看看能做到什么程度。

这个月过去，小半年就过去了，如果还是在打口号，在提思想，我觉得就太失败了。有句话说得好，快就是慢，慢就是快，你太慢了所以觉得哪里都快，你太快了觉得哪里都慢，可能就是这个道理吧。我很喜欢做事情主动能拼的同学，我不喜欢追着别人做事情，要达到初步的预期，我觉得有两点分享下，一个是做事情需要有明确的目标和计划，比如这个月我要实现基础的功能，那么我来拆分，本周，下周，下下周要做的事情。第二就是deadline,做事情没有截止日期，结果简直没法提。

以上就是我的一些基本想法，很多事情听起来确实泛泛，需要不断的细化和梳理，要不时间花了，事情没成，我觉得太不值了。

我的分享就到这里。谢谢大家。