e-works数字化企业网  »  文章频道  »  基础信息化  »  运维管理

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

2017/12/3    来源:运维派    作者:佚名      
关键字:运维团队  运维自动化平台  
我给中小型运维团队的定义是整个团队人数(所有运维工程师 + 运维开发工程师)为 20 人以下,一般这样的团队,能为自动化投入的资源也许就 1、2 个开发人员。
    前言
 
    我给中小型运维团队的定义是整个团队人数(所有运维工程师 + 运维开发工程师)为 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。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐