运维开发中有哪些问题

这篇文章主要介绍了运维开发中有哪些问题的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇运维开发中有哪些问题文章都会有所收获，下面我们一起来看看吧。

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

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

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

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

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

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

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

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

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

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

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

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

比如我们要做环境的部署，那么执行路径可能是ops(运维平台）->CM(中控）->DB Server(服务器)，或者是ops(运维平台）->DB Server(服务器),比如从标准化的角度来说 ops(运维平台）->CM(中控）->DB Server(服务器)是一个更合适的路径，那么脚本从OPS端触发，怎么达到DB Server端，因为中间需要有一个中转的流程，可以使用paramiko,ansible或者salt来完成，但是怎么无缝衔接起来就是一个难点，如果从接入管理的角度来说，可能可以抽象成为接口。看起来就是一个命令的事情，但是衔接起来确实是个麻烦。

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

比如我要实现数据查询，执行路径按照上面的图来看可能就是ops->CM->Server->DB，这个路径很长，或者是ops->CM->DB,如果选中是这个路径的话，如何开通权限就是个难题，我们假设有100台MySQL服务器，写一个脚本批量传送脚本到这100台服务器上，在数据库上创建1个用户，然后开通防火墙权限，看起来是很简单的一件事情，但是你会发现这个方式是错误的，比如里面有主从复制，你如果在从库执行了，主从复制很可能就会断开了，那样你就需要处理更多的复制问题，所以有100台服务器，你需要做一层提取，那就是找出哪些是主库，哪些是从库，但是很快就会发现判断主从还是个麻烦，因为MySQL层面就没有一个明确的标识master还是slave,而是需要间接得到。从主库上直接得到slave的信息不够直观，如果我一台一台确认，又觉得这种方式太low,真要完美的衔接起来发现会碰到一层又一层的问题，最尴尬的还是元数据不够准确，忙活一场，发现还是缺了一些数据。

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

关于“运维开发中有哪些问题”这篇文章的内容就介绍到这里，感谢各位的阅读！相信大家对“运维开发中有哪些问题”知识都有一定的了解，大家如果还想学习更多知识，欢迎关注亿速云行业资讯频道。