前言
我给中小型运维团队的定义是整个团队人数（所有运维工程师 + 运维开发工程师）为 20 人以下，一般这样的团队，能为自动化投入的资源也许就 1、2 个开发人员。
BAT 等大公司的 DevOps 平台功能涵盖的范围非常全面而且各种高大上，这么庞大的体系对于中小型运维团队，要靠手头顶多 2 名运维开发工程师来实现落地就懵了，不知该从何入手。所以往往大部分中小型运维团队要么传统人肉运维黑路走到底，要么指望公司咬牙上 DevOps 商业服务。
然而，仅靠购买商业服务也未必能完全解决问题，主要原因有：
1 . 历史项目成本考虑：商业平台不支持个性化，历史项目未必能直接对接商业平台，需要通过运维与业务侧均重构以适应商业平台，对接成本甚至高于自建平台，且要高速运行的业务侧停下配合也并不靠谱；
2 . 商业机密数据的考虑：商业平台会存储运维 / 部分业务相关数据，这对于安全要求较高的行业来说，自建平台的可控度更高；
然而，中小型公司的自建平台大多都算是重复造轮子，虽然各家业务情况各异，但也有可以抽象成可复用的架构体系，这也是商业自动化平台的价值所在，如果团队是 10 人以下且没专职开发人员再且业务技术历史债务不重的情况下，选择商业服务也不失为明智之举。
我们经常看到各种大厂的自动化平台一般包含且不限于以下内容：CMDB、配置中心、管控平台、数据平台、CI/CD、作业平台、容器管理、扩容缩容、辅助运营、监控中心 等等，各种高大上词汇让人目不暇接。
由于中小型团队的用人成本必须控制得极其精确，一般不会有太多人力资源投入到自动化平台的开发，所以必须找出最核心功能，以达到快速落地投入生产环节使用为目的。我们不可能对上述功能点面面俱到，这样只会让自己无从下手。
其实最核心的功能模块只有两个：CMDB（配置平台）和作业平台。我们作为中小型的运维团队，其实能把这两部分完成即可满足 80% 的业务需求，在此基础上，再根据自身业务需求再考虑开发其他高级扩展功能如 CI/CD、数据分析、业务监控、辅助运营等。
项目背景
需求驱动导向，大家也不会因为上线一个小项目就招人做自动化平台，在什么情况下我们才需要做自动化平台呢？
去年，随着手游项目的发展，公司业务需求处于一个飞速增长的阶段，在短时间内已经发展到将近数十个项目（含各种渠道、平台、分区），业务形态各异，包括页游、手游、站点、app 等，这样众多的项目运维管理成本非常高，传统的运维管理方式很难高效率、高质量地管理和把控如此多的产品和项目。
随着虚拟化、云、微服务等技术的发展，再加上有众多的云服务提供商（阿里云、腾讯云、UCloud 等），应用程序的底层运行环境愈发多样化，各种运维对象都需要通过一个平台进行统一的操作和管理。
为了应对以上问题并高质量完成运维保障服务，我们必须做到：
- 通过平台统一管理所有运维对象，对项目组、对运维部门的所有操作都程序固化；
- 实现所有项目的持续集成、自动化部署、项目组自助操作以提升发布效率和降低故障率；
- 有一个完善的配置中心为所有运维自动化的底层数据和配置基础，驱动所有运维脚本、工具、组件正常运行；
如何达成目标
明确了目标之后，你会发现这三个目标正好对应三个运维术语：标准化、流程规范化和 CMDB。
- 标准化：从主机名、IP、操作系统、文件目录、脚本等一系列运维对象都制定标准规范，业务部门和运维部门都遵守同一套标准，基于这套标准去建设统一的平台。
- 流程规范化：主要是涉及 程序文件打包、开发测试线上环境管理、发布流程 等多部门协作的规范，必须落实到程序固化或者文档固化，打造 Dev 和 Ops 之间的标准交付环境。
- CMDB：这是一切运维自动化体系建设的基石，其它如配置管理、作业执行、资产管理等需要基于 CMDB 才能形成体系，构建完善的运维对象生命周期和操作闭环。
标准化
标准化包含的范畴非常多，从最简单的操作系统版本、主机名、IP 段、系统帐号密码到软件安装的目录、参数、配置文件等等，也许不同的公司有其特有习惯和历史遗留，所以这个没有一个全业界的统一模式。
现在只需要把贵司的习惯用文档的形式固化下来，再彻底检查生产环境的情况是否满足规范所述，不满足则按规范操作。
对于历史不是太悠久的项目要修正不会太困难，如果连这点都嫌麻烦的话，也不用谈什么运维自动化了。
简单画个思维导图，标准化的范畴主要包含但不限于以下内容：
流程规范化
流程规范化是在建立了标准化之后，为了规范运维内部以及与外部门合作的一系列复杂事件的细节做法，比如要发布新版本、上线新项目、业务扩容缩容等。
这一部分不太容易展开，因为不同公司有自己的做法和习惯，无论是怎样做，请用文档规范和约束各部门人员的行为，这样才能方便程序化和自动化，不然程序就要写多很多 if-else 语句或者需要配置化来兼容各种不规范情况，徒增开发人力消耗。
CMDB
不用赘述，CMDB 的设计肯定是运维自动化建设的重中之重，设计好的话，运维平台的开发可以有事半功倍的效果。
CMDB（Configuration Management Database）配置管理数据库，是记录所有运维对象信息的数据库，所有运维流程需要基于 CMDB 的数据进行操作，形成操作闭环，操作的结果会反馈到 CMDB 中。
此系统提供了一整套接口界面与其它任何需要信息的系统进行对接，这也是设计初衷，将信息从一个统一的、标准的源头输出给各垂直或水平业务功能系统，而运维需要做的就是维护 CMDB 本身基础数据的完整性、准确性，CMDB 与各流程系统、垂直功能系统结合之后实现信息数据一处变更，处处同步。
一个机器下架的操作：
传统方式：通过 SSH 登录到该机器，关闭所有业务程序，关机，在控制列表删除该 IP，下架，登录资源管理系统删除该机器信息。
自动化方式：在 CMDB 中编辑其状态，系统自动调用底层工具关闭服务、关机，并自动将机器信息在 CMDB 中更新状态
区别：传统方式各个步骤都是非原子性，每一步都可能有错漏的问题，如忘记删除控制列表 IP 或者忘记更新资源管理系统信息，运维流程无法达到操作闭环。而真正的自动化方式是应该需要达到操作闭环，无需人工干预。
本文为授权转载文章，任何人未经原授权方同意，不得复制、转载、摘编等任何方式进行使用，e-works不承担由此而产生的任何法律责任! 如有异议请及时告之，以便进行及时处理。联系方式：editor@e-works.net.cn tel：027-87592219/20/21。
文章
