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

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

2017/12/3    来源:运维派    作者:佚名      
关键字:运维团队  运维自动化平台  
我给中小型运维团队的定义是整个团队人数(所有运维工程师 + 运维开发工程师)为 20 人以下,一般这样的团队,能为自动化投入的资源也许就 1、2 个开发人员。

    而服务是机器的一个业务属性,一个机器可以对应多个服务,作为服务的下一级别是进程,比如一个 web 服务会有 nginx、tomcat 等若干个进程,定义一个服务则需要与之关联的进程,进程的主要属性会有进程名称、起停命令、占用端口等。
 
    作业平台
 
    定义
    
    作业是一系列运维操作的抽象定义,任何一个运维操作都可以分解成一步一步的操作步骤和操作对象,不论是发布变更还是告警处理,都是可以分步骤的。
 
    命令: 一个可以独立的操作,最简单的如关服、开服、执行 xx 脚本等;
 
    文件分发: 把指定的文件分发到目标机器的目标路径;
 
    作业: 一系列命令、文件分发的有序组合,作业的步骤可以由 “命令”、“文件分发” 以及 “执行对象” 组成;
 
    举一个相对复杂的操作过程,如更新代码并重启服务:
 
    1 . 对 web:关闭 tomcat (/home/tomcat/bin/shutdown.sh)
 
    2 . 对 server:关闭业务主进程 (/home/server/bin/stop.sh)
 
    3 . 对 web:分发新的站点文件 (scp xxx yyy)
 
    4 . 对 server:分发服务端文件 (scp xxx yyy)
 
    5 . 对 web:启动 tomcat (/home/tomcat/bin/startup.sh)
 
    6 . 对 server:启动业务主进程 (/home/server/bin/start.sh)
 
    可以看出,流程包含了一系列 “对象”-“操作”  的有序的命令以及文件分发的集合。“对象”可以是一个组、一个或者多个 IP,在执行命令时候可以在系统的页面动态指定目标对象。
 
    作业定义时有各种增删改查操作,每个执行过的作业需要记录执行人、执行时间、结束时间、返回值等信息。
 
    执行顺序  
 
    作业需要按顺序执行,当一个步骤成功后才能执行下一个步骤,如果执行失败需要停止运行作业,并保留执行的各种日志。
 
    比如一个作业定义如下:
 
    对 web 组(3 台机器):执行 stop tomcat;
 
    对 server 组(4 台机器):执行 stop server;
 
    对 app 组(2 台机器):执行 stop app;
 
    执行细节是第一步对 web 组的 3 台机器同时发起 stop tomcat 命令,等待 3 台机器全部返回结果后,如果结果返回 0 表示命令执行成功,这时候才继续进行第二步对 server 组的流程。如果第一步返回结果不为 0,则提示流程执行失败,提示需要人工检查,终止后面的流程。
 
    主要对象
 
    下面可以大致画个图勾勒出作业平台的主要对象
 
    作业平台
 
    作业这个概念的提出,即可以将运维工作的各种“变更”、“发布”、“故障处理”等零碎操作分解成一个个可复用、可扩展、可执行的独立操作命令,那么最终平台化的自动调度将成为可能。
 
    开发的时候其界面和操作方式可以参考蓝鲸的作业平台(http://bk.tencent.com/document/bkprod/000119.html ),我所接触过的几个自动化平台(包括商业的和网易内部的)都是应用了类似的设计方式 ,这算是一个经过众多运维团队考验的最佳实践,如果没有什么特殊业务需求,基本可以按这种模式启动以提高开发效率。
 
    然而,每家公司的具体业务形态决定了必然会有差异化的需求,随意列举几个吧。
 
  • 作业权限系统,不同角色用户可操作不同级别的作业;
 
  • 作业运行前确认,比如某测试同事启动作业,需要对应主程或者主策划确认才启动;
 
  • 等待确认超时时间,比如等待 30 分钟,未确认则取消启动;
 
  • 作业异常返回则报警邮件通知到运维组以及对应项目组同事;
 
  • 灰度执行,按作业的设置,先在测试服运行,再到正式服;
 
  • 作业配置克隆,快速搭建新的项目的作业配置;
 
    差异化需求的开发可以在后期慢慢迭代改进。
 
    作业执行情况分析
 
    节约人力预估
 
    因为作业平台是一个让运维定制各种线上操作,封装任意能通过脚本完成的功能,可以供自己或者项目组自助使用,尽可能做到运维无人值守,运维提供解决方案,那么其最大作用就是为运维部门节约人力,杜绝重复劳动。
 
    作业执行作为自动化平台的核心功能,必须挖掘其利用效率,比如根据执行日志统计每天、每周、每月执行次数,执行总耗时等数据,以估算出平台为运维人员节省多少人力。
 
    使用平台前:
 
    项目同事放下手头工作 ->通过邮件或者 IM 通知运维同事执行某项操作 ->运维同事放下手头工作,读邮件或 IM,理解项目同事的操作内容 ->执行操作 ->通过邮件或者 IM 反馈项目同事 ->运维同事返回原来工作 ->项目同事放下工作读邮件或 IM 再返回原工作
 
    使用平台后:
 
    项目同事操作平台直接执行某项操作得到反馈
 
    这个过程对于项目同事和运维同事双方总共至少能节约人力 15 分钟,减少了很多沟通、理解、反馈的时间成本。
 
    对于比较常规的普通操作则无需运维同事干预,除非执行异常才需要运维人员介入。
 
    我们通过统计得知平台每月执行作业的总次数为 N,每次预计节约人力资源 15 分钟(0.25 小时),则每月总节约人力为 0.25*N 小时,假设 N 为 1000,则每月节约运维部门 250 个小时的人力资源。
 
    一个运维人员一天也就工作 8 小时(不加班的话~),一个月为 21*8=168 小时,那么节约 250 小时则约等于 1.5 个运维人员的月工时。
 
    由此可见当作业平台的执行次数越大越能形成规模化,对人力资源的节省效果越有利,假设当 N = 10000 的时候,相当于节约了近 15 个运维人员的月工时,效果还是相当可观的。
 
    平台的执行数据可以利用 echarts 做报表,让运维同事实时查看历史执行次数和预计节约人力。
 
    echarts
 
    图表解析:X 轴是时间,以每个月作为一个时间区间,统计该月一共执行了多少个作业。Y 轴的是作业的执行总次数(蓝色轴,单位次),然后假设每个作业约节约人力 15 分钟,最终计算出每月节约人力总时间(红色轴,单位小时)。
 
    作业异常分析
 
    作业平台可以让运维人员解放了很多劳动力,但是我们也不可能保证每个作业都能正常运行,若在执行异常的情况下,我们可以为异常的原因打上标签,打标签可以根据错误输出关键字匹配自动分类或者人工归类,然后统计各种异常情况的比例,再重点分析并处理异常比例高的情况。
 
echarts
 
    图表解析: 由上图可以看出这是各种异常的数量分布情况,异常的分类是需要运维预先定义并且有足够的区分度。然后根据作业在一个时间区间内统计出各种异常的比例,再利用饼状图可以方便找到比例最高的若干项,如上图是【运维脚本 bug】和【业务代码异常】比例最高,再着重分析解决这类异常的原因来降低运维操作故障率。
 
    总结
 
    运维自动化平台的建设本质是运维团队服务化能力的变现过程,它让我们从大量重复无规律的人肉操作中解放出来,专注于运维服务质量的提升。由于文章篇幅所限,未能和大家全面介绍整个自动化平台的设计思路,按系统的核心程度来划分,最核心的是 CMDB 和作业平台,当完成这两部分之后,次核心的 CI/CD、数据平台、监控平台也可以投入开发,后面的运营辅助、故障自愈、智能扩容缩容甚至 AiOps 等也需要 DevOps 团队继续探索。
 
责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
兴趣阅读
相关资料
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐