中小型运维团队如何设计运维自动化平台_影响运维平台设计

原文链接：中小型运维团队如何设计运维自动化平台

前言

我给中小型运维团队的定义是整个团队人数（所有运维工程师 + 运维开发工程师）为 20 人以下，一般这样的团队，能为自动化投入的资源也许就 1、2 个开发人员。

BAT 等大公司的 DevOps 平台功能涵盖的范围非常全面而且各种高大上，这么庞大的体系对于中小型运维团队，要靠手头顶多 2 名运维开发工程师来实现落地就懵了，不知该从何入手。所以往往大部分中小型运维团队要么传统人肉运维黑路走到底，要么指望公司咬牙上 DevOps 商业服务。

然而，仅靠购买商业服务也未必能完全解决问题，主要原因有：

1 . 历史项目成本考虑：商业平台不支持个性化，历史项目未必能直接对接商业平台，需要通过运维与业务侧均重构以适应商业平台，对接成本甚至高于自建平台，且要高速运行的业务侧停下配合也并不靠谱；

2 . 商业机密数据的考虑：商业平台会存储运维 / 部分业务相关数据，这对于安全要求较高的行业来说，自建平台的可控度更高；

然而，中小型公司的自建平台大多都算是重复造轮子，虽然各家业务情况各异，但也有可以抽象成可复用的架构体系，这也是商业自动化平台的价值所在，如果团队是 10 人以下且没专职开发人员再且业务技术历史债务不重的情况下，选择商业服务也不失为明智之举。

我们经常看到各种大厂的自动化平台一般包含且不限于以下内容：CMDB、配置中心、管控平台、数据平台、CI/CD、作业平台、容器管理、扩容缩容、辅助运营、监控中心 等等，各种高大上词汇让人目不暇接。

由于中小型团队的用人成本必须控制得极其精确，一般不会有太多人力资源投入到自动化平台的开发，所以必须找出最核心功能，以达到快速落地投入生产环节使用为目的。我们不可能对上述功能点面面俱到，这样只会让自己无从下手。

其实最核心的功能模块只有两个：CMDB（配置平台）和作业平台。我们作为中小型的运维团队，其实能把这两部分完成即可满足 80% 的业务需求，在此基础上，再根据自身业务需求再考虑开发其他高级扩展功能如 CI/CD、数据分析、业务监控、辅助运营等。

项目背景

需求驱动导向，大家也不会因为上线一个小项目就招人做自动化平台，在什么情况下我们才需要做自动化平台呢？

去年，随着手游项目的发展，公司业务需求处于一个飞速增长的阶段，在短时间内已经发展到将近数十个项目（含各种渠道、平台、分区），业务形态各异，包括页游、手游、站点、app 等，这样众多的项目运维管理成本非常高，传统的运维管理方式很难高效率、高质量地管理和把控如此多的产品和项目。

随着虚拟化、云、微服务等技术的发展，再加上有众多的云服务提供商（阿里云、腾讯云、UCloud 等），应用程序的底层运行环境愈发多样化，各种运维对象都需要通过一个平台进行统一的操作和管理。

为了应对以上问题并高质量完成运维保障服务，我们必须做到：

• 通过平台统一管理所有运维对象，对项目组、对运维部门的所有操作都程序固化；
• 实现所有项目的持续集成、自动化部署、项目组自助操作以提升发布效率和降低故障率；
• 有一个完善的配置中心为所有运维自动化的底层数据和配置基础，驱动所有运维脚本、工具、组件正常运行；

如何达成目标

明确了目标之后，你会发现这三个目标正好对应三个运维术语：标准化、流程规范化和 CMDB。

• 标准化：从主机名、IP、操作系