后话：PipeLine支撑运维自动化

后话：PipeLine支撑运维自动化

读完需 5 分钟 速读需 2 分钟

严谨点

《CI/CD如何支撑运维自动化》主要讲述了我们在运维自动化方面的一些思路与实现方式，但后来经过仔细的琢磨发现应该将此称为“Pipeline如何支撑运维自动化”更为合适，因为我们的核心思路是通过对Pipeline进行编排，来实现不同的运维场景。

在此还有一个关键词：支撑，可能会有运维同学问，为啥不叫“实现”呢？

这个问题真的非常好，因为运维自动化是个很大的概念，这也意味着有很多不同的实现方式，而Pipeline只是其中的一种，故“支撑”而这里更加恰如其分。

请大家理解，如此的咬文嚼字正说明了我对“PipeLine支撑运维自动化”的重视，以及后续切实希望其在真正的工作中能够帮助到我们，这也是这篇“后话”的真正目的。

调研

运维的自动化离不开标准化，因此就有一个比较有趣的话题：

“先自动化再标准化  or  先标准化再自动化 ？”

经过初步的调研结果如下：

当我们在熟悉的领域时，“先标准化再自动化”是我们的第一选择，因为大部分的场景都经历过，知道处理问题的方式与方法。而当我们在不熟悉的领域呢？我们需要先去实践总结，这个过程可能就会选择“先自动化再标准化”。

因此对待这个问题我们要结合实际、理性看待、仁者见仁：

不同的选择在其相应的阶段都发挥着重要作用做比说更重要

在此和大家分享我在进行运维自动化建设过程中坚持的一个理念：

结合公司当前自动化运维水平，以“先自动化，再标准化；边自动化，边标准化；既自动化，又标准化”为理念，实现标准化和自动化能力的交替上升，持续对外输出适合公司的运维技术和能力。

解决方案

通过对运维工作的不断梳理，我们将其总结成了如下的运维场景：

新服务器上架，与CMDB、监控、堡垒机联动同步；操作系统初始化，包括用户、内核、安装源、规范目录、安全基线等；基础组件初始化，包括Java环境、Pyhon环境、Nginx等各种组件；应用版本发布、回滚，此过程与监控联动；应用管理操作，如启动、停止、重启等；监控系统实现服务器、应用等多个维度的监控与管理等

……

针对以上场景，我们如何如何选择解决方案呢？

1.成熟商业产品

虽然在一定程度上能够解决我们的痛点，但……

高额的产品费用额外的人力成本产品的稳定性、扩展性、可持续性熟悉开发框架，满足后续功能扩展

2.自研运维平台

大局观上，功能要向主流标准看齐，但……

向主流标准看齐，需CMDB、ESB（企业服务总线）、对外API等，开发成本高放低姿态，满足兼容性，对接各运维产品的API，差点意思依赖稳定的开发团队，人力成本高最终骑虎难下，难以维护

3.Pipeline支撑运维自动化

结合运维现状，借助Jenkins通过Pipeline对各种插件进行编排，实现各种场景的需求。

BlueOcean

Jenkins官方从用户角度出发，可使复杂的pipeline可视化，快速直观地理解管道状态

扩展共享库

通过共享库可以实现多个项目之间共享流水线，有助于减少冗余并保持代码干净整洁

Pipeline

流水线既可以作为job独立执行，也可以作为一项任务被其他流水线调用

通过以上三个方案对比，如果我们所在的公司没有足够的领导支持、成本投入、稳定的技术团队的情况下，那么"Pipeline支撑运维自动化"方案无疑将是我们优先选择的方案。

案例支撑

由于没有大佬背书或足够的案例支撑，小伙伴们可能对“PipeLine支撑运维自动化”的方案有所质疑，就连我曾经也认为这可能是一条野路子，可当我看到《SRE：Google运维解密》中介绍的Rapid系统时，我就更加确认了这套方案思路是正确的。

Google持续测试系统：Rapid ，每个Rapid项目都有一些工作流，定义了发布流程中的具体动作。工作流可以线性或者并发执行，某个工作流也可以启动另外一个工作流。Rapid将工作请求分发到运行在‍Borg‍系统上的生产服务器。SRE: Google 运维解密

正如Rapid系统介绍，Pipelin支撑起了各个动作的具体实现，各条Pipeline还可以被其他Pipeline调用，非常的灵活。最重要的是还可以和Borg（Kubernetes 前身）结合，为我们后续在云原生领域的运维也提供了有效支持。

Kwok:开源的 IT 管理系统

PipeLine支撑运维自动化：系统监控级原子模块

运维思索：自动化运维体系如何入手？

Jenkins 和 CMDB竟然着了DNS的道

事件推送网关: “让基础设施建设动起来”

运维思索：接地气的运维自动化建设