小米运维讨论

作为一个标题党成员，我可以很负责的告诉你——我真不知道运维自动化怎么做，更不知道怎样才能做好！

• 没有用过borg，仅仅通过论文了解过它，资源隔离和资源调度想想都头大。IAAS、PAAS，如何能够达到no ops，我们正在推广和验证。
• 传说中的运维自动化神器，什么puppet、chef、saltstack、ansible等等，用了一圈还是觉得运维工作很苦逼，谁当年告诉我运维自动化就是喝着咖啡，悠闲的点下鼠标看着成千上百的服务自动变更……
• 有幸做了几年的运维平台，对运维自动化思考过很多，讨论过很多，也完成了一些大大小小的项目。不过都不能说是什么成功案例，但可以把失败的经验分享给大家。

web化 ≠ 自动化

• 看到很多运维工程师拼命的把自己的运维脚本/工具web化起来，总觉得做个工具不够酷、不够自动化，必须要在上面套一个web端，能够在web页面点击一下才是真正的自动化，在终端上敲一个命令就很土鳖。
• 大多数情况下，仅仅是通过web传几个参数，调用最原始的命令行工具/脚本，然后再获取结果展现在web端。好处呢？有权限管理、有统计、有视图，恩，写PPT总结的时候还能截个图show一下给老板看

例子1： CT（ControlTower）

CT能够替代crond，用来解决任务关系依赖的任务调度系统，这个想法真的鹅妹子嘤~~~!

比如：线上有A,B,C三台服务器，分别有任务1,2,3

1 2 3 4

任务 1 10 : 00 运行      任务 2 11 : 00 运行，但运行时需要下载任务 1生成的数据，否则会运行失败      任务 3 13 : 00 运行，需要依赖任务 2插入到数据库的数据，否则会运行失败      当上述这样的任务依赖非常多时候， 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7.... -> n时，如果某个环节出现问题，就会导致最终任务 n无法正常运行。

• 为了解决上述问题，所以有了CT的出现，它可以在web端配置在什么机器上，什么时间，跑什么样的任务，并且可以配置它的上游依赖是什么。完成配置后，CT会把任务和依赖关系推送到对应的服务器的ct-client上，ct-client原理和crond类似，定时运行任务。
• 任务1运行成功后（返回值0做为判断），A机器的ct-client会把消息发送到B机器的ct-client上。B机器ct-client在11:00开始运行任务2，会检查是否收到任务1的成功消息，如果收到则真正开始运行任务2，以此类推

ct-client能够记录每个任务的运行时间、运行失败，进行相应的统计和报警，而且能够在web端绘制出任务流的依赖图，超赞啊~
不用搜了，CT这个产品木有开源。

一大波问题来了……

• 用户说，每次登陆服务器排查和定位问题的时候，能不能提供一个cli工具，方便我查询本机的任务。 这个简单，做个cli工具读取分发到ct-client的任务表，满意了吧？
• 用户又说，能否让我在服务器本地CURD任务。 擦，难度很大，需要提供一个和WEB一样填写和展现直观的方式，而且还要保持web端数据的统一性，还要维护依赖关系……只能让CLI call web-api，然后web再下发任务到ct-client，好大一个圈啊~能!实！现！
• 用户还说，我想在部署的时候就顺便完成crond的添加，有了cli是可以解决，但开发环境、测试环境怎么玩，要进行持续集成，要遵守幂等原则 有完没完啊？ 开发/测试环境经常变，而且很混乱，装个ct-client，通过web管理，还要考虑权限、依赖，不能影响线上正常业务等等，一切变的复杂起来……

愿景是希望服务器上的crond任务都通过web端集中管理起来，可是cli还得支持，还的做的和web一样强大，还得做的比web更加灵活。

另外，为什么任务之间有依赖？ 不同机器之间的任务依赖无外乎就是数据文件/数据表的依赖。 那干嘛要每个任务都配置启动时间？ 任务1完成后pub消息，任务2 sub 任务1消息，然后启动岂不是更好……那是不是有更好的替代方案？
如果想做crond的集中管理和展现，甚至运行时间记录，有很多种方案

例子2： web部署平台

web化部署，高端大气上档次，在web端配置SVN路径、机器列表、启停方式、时间间隔、并发度、暂停方式，点击一个按钮，完成服务部署。

需要的前置条件比较多：

• 程序启停方式标准化，统一的run.sh接口，支持start、stop、restart、healthcheck….
• 服务部署路径的标准化，避免繁琐的配置
• 变更前备份方式的标准化，路径、命名规则、备份方式……
• 服务通过服务树进行管理，可以方便的进行筛选，部署一批同类型的服务
• 所有机器上都一个负责具体命令执行和反馈的agent

完成上述工作，貌似web部署化工作可以启动了，但是线上真实环境和SVN的差异还是非常的大:

• 历史上线上配置文件的变更都是直接在服务器上变更，没有和svn中配置文件一致
• 数据文件，如词典、ip黑白名单之类的没有在svn进行管理，有些还可能通过脚本动态获取最新的数据文件
• 同类型服务，可能由于分组策略、连接下游服务器不同，导致配置也无法统一。

先来看看ops以前是怎么进行服务部署的（注：这里介绍的是一般复杂度的部署，当然越简单的服务部署会越简单，甚至有些服务传个文件就完成了）：

1. 在原有已运行的环境上，先备份整个目录（可能会剔除log、data文件），一个批量的ssh操作。 注: 公司的ssh批量工具，关联产品线、服务、机器编号等,如：对im产品线，se服务，所有机房，所有编号的机器执行cmd命令 lhck *-im-se-* 'cmd'。当然，机器名也支持各种筛选。 BTW，给运维人员介绍一个工具怎么批量生成机器名，怎么筛选，各种复杂的组合。这是几个意思？
2. 批量分发需要的bin、conf，如果conf各个机器都不完全一直，还有可能用sed替换，或先本地生成每台服务器对应的配置文件，分别分发
3. 停监控，开始每台执行停止服务、替换文件、启动服务、检查日志和服务关键点的批处理操作，也是用lhck

把线上配置统一在SVN管理，难度很大，就算费了很大功夫完成一个服务，但如何保证后续所有配置内容变更都必须以SVN中为基础，保持一致。 可是开发环境、测试环境、preview环境的配置怎么整，整一个WEB化的配置管理中心？

在以前部署方式没有做任何改变的情况下，web部署平台出来：

• 选择需要部署的服务树节点，提供筛选功能
• 选择服务本次变更的版本，因为之前已经在服务树上把服务和SVN关系进行了绑定
• 只能在线上已运行服务的基础上，做增量上线，替换每次需要升级的bin，不影响data、conf、log
• 提供一个web化的配置文件编辑器，每次发起部署任务前，先把线上每台机器的配置文件拉回本地进行批量编辑
• 因为之前做了服务启停标准，所以只需要配置stop,start，还是restart等命令执行顺序即可
• 可以设置暂停点，如部署完第一台服务器后暂停，运维人员观察确认后再批量执行
• 支持与监控系统联动，在部署该服务器时，暂停该服务器上对应的服务监控，部署完成后调用healthcheck和开启监控，如果发现问题则暂停批量任务。
  有部署任务汇总统计，有每个部署任务详细的部署进度和日志，能够和监控系统联动，支持各种串并型组合，提供各种视图，看起来还不错呦~~~

第一版出来了，在几个产品线几个模块上试用，效果还不错，60%的更新bin文件，修改简单配置都能完全满足。还提供操作模板功能，经常的操作定义成模板，下次操作调出来改一下升级版本，点击部署即可。
领导们很开心，OPS也很想试用，部署自动化有解了，部署效率提升了，开始全面推广！

这个时候，一大波问题又来了……

• 那女孩对我说，有些服务比较特殊，启停前需要执行一些特殊任务，比如拉数据，清理cache等。 好的，提供命令执行接口，可以定义在服务部署的各个阶段
• 那女孩对我说，不同机房相同服务，希望可以机房间并行，机房内串行部署。 小意思，支持
• 那女孩对我说，一次想部署2个服务可以吗？ 行，可以支持
• 那女孩对我说，2个服务在不同机器上，想在一个单子发起上线 好滴
• 那女孩对我说，2个产品线之间联动的服务怎么部署，比如A，B2个服务属于不同产品线，他们之间需要联动部署，能发一个单子吗? 囧~~~~
• 那女孩对我说，web配置修改，没有sed或vi编辑批量编辑方便，没有diff功能，能做吗？ 尽量满足，招了一个超级FE来实现，就差TMD实现web端sed或vi了
• 那女孩对我说，每次部署的时候，如果某台机器失败，我还有登陆服务器去查看详细原因，要打开一个web端做部署，还要再打开一个终端，能实现web终端吗？ 技术上可以做，不过是不是有点过了？
• 那女孩对我说，部署的时候，还需要配置crond(或CT)、修改监控、修改xxx，修改xxx，能不能把这些系统的表单也做到一个上线单中，不用来回在各个web平台上修改 成~~~~~我..满足你
• 那女孩又对我说，部署操作单是否可以和公司的上线申请流程合并，这样只需要发一次，审核完成后点部署就可以。 满足你~！ 找PMO求支援、求联动，大爷们说：没空，排期到7个月后。 -_-|||
• 那女孩还对我说，简单的操作，比如修改一个配置参数，或者只操作一台机器，我直接登服务器修改，3分钟不到，用web部署我需要填写一单子，选项好多好复杂，好麻烦； 复杂的操作能支持，但填写一个单子需要2个小时，各种检查、配置，我写成脚本，写成步骤手工做，也就半个小时完成了。 It's enough!

女孩，你还有完没完！用户虐我千百遍，我待用户如初恋~ T_T

没有改变部署方式，没有从本质上解决问题，只是把以前工具批量操作的方式变成了web化，而且还有投入更大的成本，还需要有超级FE、超级PM、超nice客服，跌跌撞撞一路走来……
这仅仅是把批量的运维部署变成了web化、可视化，还要填写繁琐的操作单，不是真正意义的自动化。
web端的部署平台的确解决了一部分部署的问题，但还做的远远不够，属于外挂型的部署系统

这么牛B的公司，部署原来做的这么挫，别偷笑……这的确是发展的过程。如果你还没遇到，只能说明运气好、规模和复杂度没达到；或者在一开始你们就有超牛B的架构师，把部署行为早早就规范和定义出来（呵呵，不过我真不信）。

本章总结

• 不是抵触web化，如果是通用的东西当然web化很好，但更希望WEB是一个展现端、触发端。
• 例如PAAS，没有web端，你的服务已经可以很好的部署、容灾，方便的进行扩展和监控。有了web端，你可以更直观、更方便的查看和管理，但一切都依赖它底层所提供的API。
• 目标是自动化，还是web化，为此你需要在完成底层基础的前提下，再额外投入精力进行web端的开发，优美的界面，良好的交互，还要再投入大把大把的精力在用户易用性上。 别抬杠~亲，监控类产品肯定需要web端