刚刚在运维分享群里分享了主题《运维开发流程梳理和思考》，希望有所帮助。

    记得之前梳理过一个运维开发流程，也做了一些实践，从我的认识和理解来看，其实这更适合一个团队内的协作。

    而早期的时候，整个项目的构建和建设主要是我一个人来做，我贯穿了整个项目的开始，不能说是从0开始，也算是从0到1的开始吧。

    首先来说下一个基本的心路历程。通过这个可能对你也有一些借鉴和参考。

    做自动化运维不是拍脑袋想的，而是这个是大势所趋，如果还在手工化，脚本化的阶段，其实整个运维的路基本都能看到头了。而开始提出来到要做的时候，其实也算是受到了蛮多的阻力。

    做一件事情基本上是从上要支持，从下要配合，细节就不说了，总之，从上从下都很难，最后发现有一个目标，但是没法控制过程，所以这是一个随机结果。

    这个事情要做成的概率就太低了，所以早期的时候没有这方面的技术就学，没有哪方面的内容就补，整个过程的迭代会花费一些时间，一方面见效难，很多人都会怀疑这个事情能不能做，如果从上没有明确的资源支持，你会发现就跟一个半创业状态差不多。 

    从下来说，其实主要是运维意识的提高，如果某个事情今天花30分钟能做完，那么改用自动化运维用了5分钟，对很多人来说确实是提高的，但是这个提高的代价对他们来说相对会比较高，所以很多人的想法就是差不多就行了，我也理解这种想法。

    除了意识，还有一点就是技术沉淀方面，要提升一个团队的整体技术能力不是一个人能说了算，也能直接改变的。我最担心的情况就是说出一个想法，其实已经很成熟了，但是我需要做的事情是需要花很多的时间去说服别人，或者有时候别人对你的想法会有一些不大理解。碰到这种情况就两难了，所以有的时候我确实容易上火，事情如果明显达不到我的预期，我就会更加的急躁。有时候都在想到底这么坚持图个什么。

    当然同事相对都是很支持配合的，能够在事务性工作之外给予我这么多的配合其实想想已经很不错了。我觉得一定是某些环节上有些问题或者不够清晰，导致事情很难推动下去。

    第一个是就是事情的形式，多多少少还是得有仪式感和角色带入感，所以一种比较好的方式就是成立项目。做项目要写文档，这个之前觉得会浪费时间，其实细细想来，也是一种工作内容的体现。

    第二个就是运维开发路程的梳理，也是本次分享的主要内容了。

前前后后做了很多磨合，最后也是捡了几个业务场景，每个场景逐个击破，比如部署安装，比如服务开通，每一个功能的标准就是能够支持线上业务，界面丑点没关系，多点击几下鼠标也没关系，关键流程要对，比如权限的开通，不能做侵入性的破坏，不能多也不能漏。

    所以做了一些功能，沉淀下一些思路之后，我觉得运维开发的流程可能要分成几个环节，如果从大了来说，就是前后端开发。

    当然这里的后端开发远比我们理解的要复杂的多。我来细掰扯下。

    第一个阶段就是业务需求的提炼，比如我们现在需要解决的需求是什么，可能一二三四有好多个，但是我们可以按照优先级来排个顺序，哪个是痛点需要优先解决，这个重要性不用再强调了。

    第二个就是梳理脚本，脚本的部分可能和大家的理解有很大偏差，每个运维其实多多少少都会沉淀下来不少的脚本，少则十多个，多则上百个或者是写个工具之类的。

    所以有这么多的脚本或者工具，其实我们可以在这个基础上做提炼，满足当前需求的脚本有哪些，然后不同的方向上可能都会有一些相关的，接下来要做的而就是脚本的标准化，这个是脚本梳理的一个核心点。

    比如运维同学A有10个脚本，有的是shell，有的是Python,没关系，都可以考虑接入，但是我们要指定一个接入的标准，这里我们就要组哦一个接入管理的工作，比如我们统一设置一个目录结构，os,mysql,redis。。。。 然后按照功能在每个目录下放入相应的脚本，结构的部分还可以细化。

    然后我们需要制定脚本的标准，比如参数的使用说明，哪些是必须的，参数的含义，还有调用方式，脚本的返回结果等，这些都要明确，要不从开始就是一团糟。比如其中的一个标准就是脚本在本地是能够正常执行的，能够输出执行结果的标识的。

    如果做了这些工作，后续去接入脚本其实就是一个标准化的工作了，其实放长远来说，其实这个过程单纯的运维也能够参与到整个运维开发工作中了，我们可以不断的merge脚本，尽可能做裁剪和边界划分，最重要的一点，这个脚本的接入管理需要有一个人来专门负责，这样入口是统一的，改进方式后续再细说。

    第三步是REST接口和API化，我们的脚本可以使用很多种方式调用，比如salt,比如ansible,比如paramiko等等，这些都是接入方式而已。其实对于执行结果来说是没有差别的。

    那么我们可以抽象成REST的接口服务，直接出发这个REST的接口就能够完成相应的指定任务。比如一个具体的例子，我们使用Django的rest_framework来做REST接口服务，可以很方便的使用认证体系。

    这里的REST接口这是一个调用方式，不是我们说的重点，我这里说的是REST接口和REST API,这里的重点其实是API的环节。

    比如我们查看防火墙的操作，我们可以输入一些基本参数，就得到一个防火墙信息列表，这个逻辑在Django中是需要在View层中来写的，其实我们可以上移到API层来做。

    这样一来运维同学就可以直接调用REST接口来做调试了，是否满足需求其实通过这种测试就可以很清晰的测试。

    到了这里可能是很多人理解的后端开发了。如果配合上前端，基本就是一个前后端分离的开发过程了，其实我要补充的是，我们可以做的更灵活，全面一些。

    我们在这两个层之间做一些补充。Django的前端其实也还可以用啊，或者自己写也可以，但是我们的使用基础就是纯粹的API,这样一来，view层的逻辑上移，只负责分发和跳转，就能够很方便的和当前的前端方案整合起来。

    如果要做后续的前后端分离这就是一种相对可行的迭代方案，如果再深入一步，其实我们的View层已经只负责最简单的分发任务了，那么这个工作其实我们可以继续抽象，比如把跳转的工作干脆直接放到数据配置中得了，通过前端的配置页面来完成跳转的配合，这样我们就可以在线维护这种看似负责的关系了。

    整个完成的图其实通过下面的描述就会比较清晰了，我画个图先。整个流程图就会是这样

如果划分下边界，其实就是这样。

    中间的部分就是后端的开发，而右侧的部分是前端的部分。

    这样做的好处是只需要少数的几个人就可以负责某一个方向，而且能够保持持续交付的质量。比如交付的脚本，有了参数的说明和脚本规范，那么接入到API的时候会轻松许多，而在接入前端之前，其实后端就可以开始测试任务了。

相对原来所说的前后端分离，我们加入了中间的逻辑分发接入，可以很快的在本地构建出一个前端的方案，至于独立的前端方案我们完全可以持续的构建。

所以整个的过程就是一个异步开发，不需要串行强依赖。

    而且还有一个好处就是能够充分的融合运维和运维开发。其实在这个过程中运维同学就可以参与很多的角色了。

    纯粹的前后端分离其实也有很多的弊端，一个是沟通成本。在调试的时候可能因为后端API或者逻辑，或者是前端的支持情况，基本不大可能一口气调通的。反反复复可能会做很多次。

    而且前后端分离的一个主要出发点其实是对于代码的复制所带来的维护代价，比如有ios版本，有android版本还有pc版本，如果按照原来的方式，就是快速复制代码，后期引入维护的时候成本巨大，这算是前后端分离的一个主要出发点。

    相比到了我们很多工作环境中，前后端架构要分离，但是前后端的技术不一定完全分离，当然专业的前端可以做高级的前端功能，后端还是需要掌握基本的前端能力，而高级的前端也需要掌握一些后端的技能。

    后续如何改进，其实最近把基础运维的事情搞定，不如部署，服务开通，如果我能够全部通过界面来搞定，完全不需要登录服务器，那么这就是一个初步的里程碑，然后后续就是简化流程，不断的迭代改进了，比如很多抽象出的任务可以组装成一个流程，这就又上升了一个台阶。

    可以打个比方，你去菜市场买菜，顺路去买个早点吃，如果你已经吃过早点了，那么去买菜的时候就不用那么赶了。这里的吃早点就是我们需要先解放基础运维的工作，这个工作做好了，我们再去想其他的事情。

    要不忙忙碌碌，自己的事情都解决不掉，工作的价值也不高，慢慢就会陷入一个恶性循环。

问答:

防火墙还是基于操作系统的iptables？ 添加规则主要就是调用命令去添加？ 防火墙这个主要有什么应用场景？

答：

防火墙这个比较有意思，最近是做了改进和提炼。把防火墙信息做成属性信息。可以标识几个维度（操作人，发起方，操作时间），读iptables信息的时候做成跟读数据库表类似的方式

类似这样

斑*^O^*竹:

最起码知道什么时候添加的  谁提的要求

答：

防火墙信息里的文本备注其实不靠谱，很不好参考。

时间戳和操作员可以做成隐式的，自动录入。就是先做加法再做减法。

斑*^O^*竹:

主要看写备注的时候靠谱不 手工填入的数据

答：

后续可以改进的话，比如根据开通时间排序。。。