中小公司如何启动运维平台构建之路

96
秦晓辉
1.0 2018.12.15 03:08* 字数 1981

这里所谓的中小公司,是我的个人定义,服务器数量在5000以下的公司。大公司通常都已经走上了这条路,应该不会看我这篇文章了:)

运维平台收益

先说说为啥要开启自动化运维这条路,其实简单,主要目的有二:

  • 业务运行可用可靠
  • 业务迭代既稳又快

我们希望通过构建一整套运维平台,来规范研发的变更流程,来及时发现线上问题,能够快速止损故障,同时把机器管理明白,权限分配清楚,服务梳理透彻。规范化之后,后面做一些统一的服务治理或者一些公共组件/服务,都可以依托平台的元信息来搞,说是基石也不为过也。

从痛点处着手

首先胸中需有丘壑,胸中需有蓝图,运维蓝图可参看我之前的文章:《运维蓝图思考》。知道未来理想状态了,然后低头看现状,最后制定达到理想状态的路径。

有句话说的好,“架构是演进出来的,不是设计出来的”,各个公司的情况各异,需要有针对性的实施。从哪里着手?从自己公司的当前痛点着手。在这个阶段,我个人猜测,可能会有下面的困扰:

  • 有部分机器给了业务A,部分机器给了业务B,需要有个地方来记录这个对应关系,记录机器上面部署了什么服务,接口人是谁,要不然,机器要做什么操作的时候,或者机器报警了,都不知道该联系谁
  • 机器经常要做一些批量操作,批量安装lib,调整配置,查看机器配置,跑个脚本,需要控制权限,业务A的机器只能业务A的同学才能操作,操作历史要可审计,谁干了啥都得有记录。中控机信任关系管理麻烦,批量操作速度慢,结果不好查看不好筛选
  • 安装一些常见软件,比如MySQL、redis、kafka等,不同业务安装的方式、版本、参数配置千差万别,缺少一个最佳实践,也没有很好的沉淀,自己需要自己攒,业务A的同学对这些软件的知识积累,业务B的同学无法享受到
  • 线上出了问题,有很多时候是客户先发现,我们被通知,非常被动。我们的业务有一些营收指标,需要有个系统来看展示历史趋势图,重要业务指标如果下跌也得及时报警。当然,机器硬件出问题,进程挂了等基础问题也是需要及时报警出来的

针对上面的问题,我们可以构建一些基本的平台系统来解决。下面挨个阐述...

服务机器管理

这是第一个系统,记录管理了很多元数据,要求数据准确,其他系统会依赖此系统的数据。系统构建思路:

1,机器要想知道归属哪个团队哪个业务线,部署了哪个服务哪个模块,首先系统里得先有团队、业务线、服务、模块这些概念,要不然机器跟什么关联呢
2,本质上是对机器做了分组,常见分组机制就是一维的扁平分组和多维的标签,类似你的博客系统。可以对一篇博文指定分类,也可以同时打多个标签
3,由于机器可能混部,一个机器需要同时属于多个分组,这种情况用一维的分组就不好描述了,首推标签的方式,标签可以是K=V的方式,K实际是个维度信息,比如dept=sre,service=minos,module=web,假设有5台机器打上了这3个标签,其意为:部门这个维度上来看,这5台机器属于sre这个部门,服务这个维度上来看,这5台机器属于minos这个服务,模块这个维度上来看,这5台机器部署了web这个模块
4,看起来很完美,但是,标签最致命的一点是不够直观,比如我想通过标签搜索机器,首先你得知道有哪些标签,这个是最麻烦的
5,所以笔者待过的四家公司都是用树状结构来描述这个分组关系,相对会直观很多,树的每个节点其实是有业务语义的,类似一个标签,只是这个标签具备了层级关系

批量执行平台

常见的运维批量操作工具有很多,比如pssh、ansible、fabric、salt等,各有优劣,对我而言,他们或多或少存在这些问题:

  • 安全性,不方便和内部权限配置系统整合
  • 效率低,基于SSH的方案通常在大批量操作时比较费劲
  • 结果不好查看,哪些机器成功,哪些机器失败,哪些机器超时,需要做一些工作才能筛选,脚本的输出也不是很好查看
  • 不好审计,哪些人执行过哪些脚本没有历史记录
  • 不好沉淀,可以自己总结一些脚本,但是系统层面没有管理类的支持
  • 没有良好的并发控制、暂停点支持,但业务一般是灰度发布

所以,我们建议自研一套,解决如上问题,构建思路也比较简单:
1,所有机器部署一个agent,用来执行命令
2,agent周期性跟server心跳,询问我有哪些脚本任务要跑
3,拿到要跑的脚本在本地执行,完了将结果汇报
4,server端提供一个web和api让用户来创建任务,展示结果
5,server端提供一个调度模块来调度大批量机器的执行,控制并发度,如果有失败的机器可以及时停下来

监控系统

这是第三个迫切需要构建的系统,由于前面两个要自研,监控有不少开源软件,所以很多情况都是现有监控:)

对于监控系统,我们不能只停留在OS、硬件、进程相关监控上,业务的订单量、库存余量这类直接反应业务健康状况的指标更是尤为重要。由于服务通常有容灾能力,部署多个实例,某个机器挂了,可能影响不大,但是业务指标下跌,比如订单下跌,问题就大了,需要第一时间跟进。

常见的监控系统比如zabbix、nagios、open-falcon、prometheus等,因为笔者是open-falcon的早期开发人员,自然推荐open-falcon,读者可以自行选择:)

上面提到的机器/服务管理、批量执行、权限系统,我们正在搞一个开源版本,有兴趣的可以参与进来

DevOps
Web note ad 1