中小公司如何启动运维平台构建之路
这里所谓的中小公司，是我的个人定义，服务器数量在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，读者可以自行选择：）
上面提到的机器服务管理、批量执行、权限系统，我们正在搞一个开源版本，有兴趣的可以参与进来
