从“悲剧”的几个运维场景谈谈运维开发的痛点

运维工作中只要牵扯到运维开发，要去推动这件事情势必会有几类问题需要解决：

1. 提高运维意识。从下到上，从上到下的工作都要做，对上运维工作的价值和含金量可以得到认可，对下我们的工作能够提高效率解放自己。比如对于运维开发，我可以配合和协调，有技术困难可以解决，但是我不会追着别人去学习某些技术，因为这种事情会变味，运维意识里有这个，那么这个事情的意义就大不同。

2. 要有明确的运维目标。这里说是明确，光有规划不行，要有明确的运维目标，这个目标换个角度来看就是我们工作的痛点，解决了工作的痛点才是对我们自身意识的提升，这样也能解释实现运维目标的意义。

3. 要有明确的时间窗口。有了目标，需要我们安排指定的时间窗口来做，如果没有时间范围，那么事情的进度和质量就难以追溯和保证。

我在这个事情上栽了很多的跟头，而且会发现事情变得越来越不可控。就好比我的期望是6，达到的结果是2，反差越大，发现改进的空间很大，以至于我会陷入一个死循环，我会想出很多的改进方法和建议，但是这些方法和建议就会抽象成为一系列的改进任务，这些任务涉及前端，后端和设计，于是乎，每一个点我都需要确认，沟通，落实，然后事情的进度就慢下来了，对待运维平台，要有「疯狗」一样的执行效率，我还记得这句话，有时候都会反问我这么坚持做这个事情，到底为了什么，对我们有什么好处，甩甩手放弃算是轻松了，就这这句话支撑了我：当你想要放弃的时候,想想当初为什么要开始。

我们来切入正题，即一个“悲剧”的部署安装场景，到底是不是悲剧，碰到了那些问题，如何来解决，当时是怎么纠结的，可以听听我的想法。

先来说一下实例部署的场景。

假设下面就是一个初步的安装部署页面。

要实现这个功能有一些目标能够达到。比如我们目前能够实现页面调用脚本内容，我们来看看有哪些需要注意的地方，或者容易让人纠结的地方。

首先这个需求是否符合预期，可能不是很好理解，比如我们的需求是部署一套数据库软件，那么内核参数需不需要调整，系统参数要不要初始化统一配置，数据库额外的插件是否需要安装，备份是不是要配置，监控是不是要部署，元数据是不是要自动生成。还有一点，这个环境是不是已经有实例，如果有，那么/etc/my.cnf的默认配置就需要重新调整了，这样一来，这个看似简单的页面就不满足需求了，于是我们扩展之后做收敛。上面的功能都是基础需求，我们都需要考虑，但是不是所有细节都需要统一执行，比如内核参数优化可能初始化执行一次就可以了。所以我们需要对脚本化的工作做到细化，能够实现模块化的功能，这样就牵扯到一些逻辑的改动和优化。

当然从前端来说，一个难点就是日志的执行结果回传，能够基本达到刷新的效果。这个需求对很多运维来说，是比较难实现的。所以可以抽象为两个难点，一个是进度的显示，一个是日志的显示，其中日志的显示是重中之重。

看起来脚本化的工作差不多了，假设我们花了一些功夫做了定制和改动。那么接下来的事情就是脚本的执行了。还是要引用之前画的一张图。

比如我们要做环境的部署，那么执行路径可能是ops(运维平台）-

然后来说一下数据查询的需求，其实这是一个很基础的需求。能够通过界面显示出数据来，满足一定的查询需求。但是有面临一堆的问题和不确定的需求。

比如我要实现数据查询，执行路径按照上面的图来看可能就是ops-

当然可以纠结，也可以做改进，我们就可以明确的梳理边界，比如我们解决的是运维部署，那么我们就聚焦在这个地方，看看需要投入多少的人力和时间成本来解决。一个一个初步解决，能够快速迭代出来一些效果。反之就会发现是一点一点的迭代，但是都在完善，都没有成型的结果。