下面就从“悲剧”的几个运维场景说起运维开发的痛点。工作必须自下而上，自上而下。运维工作的价值和含金量得到认可，我们的工作才能提高效率，解放自己。比如运维开发，我可以配合协调，可以解决技术难点，但我不会追着别人去学某些技术，因为这种东西会变味。如果在运维意识上有这个，那这件事情的意义就很不一样了。要有明确的运维目标。这里说的很清楚，光有规划是不够的，运维要有明确的目标。从另一个角度来说，这个目标就是我们工作的痛点。解决工作的痛点就是我们自身意识的提升，这也可以说明运维的实现。维度目标的含义。必须有一个明确的时间窗口。有了目标，我们需要安排一个指定的时间窗口去做。如果没有时间框架，事情的进度和质量就很难追溯和保证。我在这方面跌跌撞撞，发现事情失控了。就好比我的期望值是6，得到的结果是2，反差越大，提升的空间就越大，这样就会陷入死循环。我会想出很多改进的方法和建议，但是这些方法和建议会抽象成一系列的改进任务，这些任务涉及到前端、后端和设计，所以需要我去确认、沟通、实施每一点，然后事情的进展就会变慢。在与运维平台打交道的时候，我们必须要有“疯狗”一样的执行效率。我还记得这句话，有时候我会问我为什么坚持要做这件事，有什么用，对我们有什么好处？我：当你想放弃的时候，想想当初为什么要开始。进入正题，就是一个“悲剧”的部署安装场景，到底是不是悲剧，遇到了什么问题，怎么解决，当时是怎么纠结的，大家可以听听我的想法。先说实例部署场景。假设下面是一个初步的安装部署页面。要实现此功能，可以实现几个目标。比如我们目前能够实现的页面调用脚本内容，我们来看看需要注意什么，或者容易纠结的地方。首先，这个要求是否符合预期可能不太好理解。比如我们的需求是要部署一套数据库软件，那么是否需要调整内核参数，是否需要初始化系统参数统一配置，是否需要额外安装数据库的插件，是否需要备份是否配置，是否监控是否部署，是否自动生成元数据。还有一点就是这个环境是不是已经有例子了。如果是这样，需要重新调整/etc/my.cnf的默认配置。这样，这个看似简单的页面就不符合要求了，所以我们扩展然后做收敛。以上功能都是基本需求，我们都需要考虑，但并不是所有的细节都需要统一执行，比如内核参数优化可能只初始化执行一次。因此，我们需要对脚本化的工作进行细化，实现模块化的功能，这涉及到一些逻辑上的改动和优化。当然，从前端来说，一个难点就是返回日志的执行结果，基本可以达到刷新的效果。对于很多运维来说，这个要求是很难达到的。所以可以抽象成两个难点，一个是进度的展示，一个是日志的展示，其中日志的展示是最重要的。看起来脚本几乎完成了，假设我们在定制和更改方面付出了一些努力。那么接下来就是脚本的执行了。还是想引用一张我之前画的图。比如我们要部署环境，执行路径可能是ops（运维平台）->CM（中控）->DBServer（服务器），或者ops（运维平台）->DBServer(server)，比如从标准化的角度，ops（运维平台）->CM（中控）->DBServer（服务器）是比较合适的路径，那么脚本是从OPS端触发的，如何到达DBServer端，因为中间需要有一个中转过程，使用paramiko、ansible或者salt都可以完成，但是如何无缝对接是一个难点。从访问管理的角度看，可以抽象成一个接口。好像是一个命令，但是连接起来真的很麻烦。然后说说数据查询的需求，其实是很基础的需求。可以通过界面展示数据，满足一定的查询需求。但是存在很多问题和不确定的需求。比如我要实现数据查询，按照上图执行路径可能是ops->CM->Server->DB。这个路径很长，还是ops->CM->DB。如果选择这条路径，权限如何开启是一个难题。假设有100个MySQL服务器。写个脚本，把脚本批量传送到这100台服务器，在数据库上创建用户，然后打开防火墙权限，看起来很简单，但是你会发现这个方法是错误的。比如里面有主从复制，如果你在从库中执行，主从复制很可能会断开，所以你需要处理更多的复制问题，所以有100台服务器，你需要做一层抽取，就是找出哪些是主库，哪些是从库，但是你很快就会发现判断主从还是很麻烦，因为没有明确的主库标识或MySQL级别的slave，但需要间接获取。直接从主库获取slave信息不够直观。如果我一一确认，我觉得这个方法太low了。如果真的要完全连接起来，会遇到层层问题，这是最尴尬的。最重要的是元数据不够准确。经过大量工作，我发现仍然缺少一些数据。当然，我们可以纠结，也可以改进。我们可以清楚地梳理界限。比如我们解决了运维部署，那么我们就把重点放在这个地方，看需要投入多少人力和时间成本来解决。一个一个的初步方案可以快速迭代产生一些效果。相反，你会发现一点点的迭代，但都是在完善中，没有一个最终的结果。
