NoOps

Ops make no ops | Ops的目标是没有Ops,嗯!

论怎么做好运维自动化 1

作者: |   7,472 浏览  | 

本篇文章未经允许,不得转载! 内容未分级,有可能会对部分读者造成不适,还请谅解。

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

  • 没有用过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

  • 为了解决上述问题,所以有了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端

本章节完,后几期可能内容预告:

  • handoff 数据库自动切换工具,不过得征求作者的意见
  • 数据备份系统
  • 关联关系管理
  • 小米的部署思路
  • 小米的运维工具选择

为什么打开不了评论?

35 Comments

  1. wilbur
    2013/09/12 at 4:38 下午

    测试评论

    • 2013/09/12 at 8:49 下午

      评论已打开,好文,大家都讨论讨论!

  2. 2013/09/12 at 10:59 下午

    百度的handoff都来了额,不错

  3. 2013/09/13 at 12:14 上午

    匿名评论,测试。

  4. 匿名
    2013/09/13 at 12:32 上午

    匿一下好了, 作为运维在小公司实践自动化将近一年半,
    最大的感触是光靠运维是没用的……

    自动化的大前提是标准化这个估计没人有意见,对服务进行抽象, 定义其属性包括,你是谁(服务名,配置模板,依赖的服务备份监控等等,参数,提供的服务),从哪里来(安装包),到哪里去(产生的数据)
    服务要有“版本”,怎么去(变更操作)全部基于模板和服务的“diff”(这里已经超出运维的范围需要开发理解了),参照rails db migrations。 这都需要对每一个服务用结构化的语言进行描述,还要有产生diff的工具。

    这样也能对部署工作进行测试了。

    然后建立API, 建立cli, 建立GUI 。

    开发GUI目标是替代手工操作这种很常见, 权限那么大, 必须加上重重的审核,还没办法回调,长远上看必然僵化流程导致低效。

    —-
    从那公司滚蛋的时候我刚定义完到哪里去

    现在精修各种ppt,excel图表技巧,呵呵

    • wilbur
      2013/09/13 at 12:48 上午

      rails的理念很不错,部署起来很方便

      • 匿名
        2013/09/13 at 12:52 上午

        所以谁说运维不是开发~ 这都要在开发框架上动刀了

    • Syupei
      2013/09/13 at 11:17 上午

      Diff本身并不困难,不过diff出来对应的动作可能千奇百怪,不仅仅是去做一两个替换、执行一两个脚本。产品线少时通常不会发现这些事情。越多越复杂,抽象越要往上层走。这也是为什么很多公司在少量产品线用时,喜欢做ui,做Web,等推广了、产品线复杂了,才猛然明白要做减法、要向上抽象,减少特性依赖的原因。这个阶段的自动化已经不再是一个web或任何UI形式的工具,其本身已经具有框架、甚至平台属性,对外也是服务的一种(意味着可细粒度、可组合、API化)。这带来这一阶段的新问题:产品线的特定需求并不会因此减少,那么势必要求研发阶段就予以配合、改造,产品不仅是完成业务功能,要比以往更多的考虑与平台对接的可运维性。

  5. 于鹏飞
    2013/09/13 at 10:08 上午

    期待更新,感同身受,web化≠自动化,从解决问题的本质去思考运维,和开发走的再近一些。运维还需要不断寻求更多的价值。

  6. 2013/09/13 at 11:47 上午

    运帷自动化这个词可能是个错误的定位或者误导,自动化对于运维这个业务来说只是提高工作效率的一种途径,完全的自动化只能靠AI实现,运维业务的多变和复杂只有可以不断学习的人脑处理,我觉得运维应该是一个CTO应该具备的素质,他是一个能从电子方面了解公司运作方式和资源调配的工作,运维的发展方向在最高层面上不应该是自动化,而应该是将网络资源映射到公司在现实世界中的实体结构,目的是快速的适应公司的变化和便于其他部门的沟通和了解。

    • Syupei
      2013/09/13 at 1:24 下午

      好高深,读过MBA的?

      • wilbur
        2013/09/13 at 2:33 下午

        老余……

      • 2013/09/14 at 2:15 下午

        不是高深,其实我是外行,只是有兴趣,这只是作为外行的一个观点,看来我没有深入的了解专业内部还是不适合发表言论,我只是从感性认识说些自己的想法,欢迎拍砖,还是希望大侠帮忙指点一下,我说的不在点子上的地方

        • ming
          2013/10/30 at 10:43 上午

          挺有道理,但理论与实践还是有差距的。从运维工作本身来看,自动化就是目标。

  7. phionis
    2013/09/13 at 12:19 下午

    各种吐槽贵度啊,哈哈哈

    • wilbur
      2013/09/13 at 2:32 下午

      不是吐槽某个具体的公司,而且把失败的经验分享出来,因为看见还有很多公司、很多运维人员前仆后继的往这个火坑里面跳。

  8. 香菜
    2013/09/13 at 2:12 下午

    各种中枪,写的太好

  9. zhangleiop
    2013/09/13 at 2:32 下午

    勾起了我很多回忆..

    • wilbur
      2013/09/13 at 2:35 下午

      雷爷啊,我在反思,呵呵

  10. 李彬
    2013/09/13 at 2:43 下午

    web!=自动化,最多就能算成半自动化。
    自动化的目标是尽量让程序自己完成运行、故障处理等,无需人工的参与。
    web有自己适用的场景,比如一些常用的固定操作集合,封装在web中,提供给一些不太熟悉的用户适用,减少他们的沟通、学习成本。

    个人愚见,欢迎讨论。

  11. suchasplus
    2013/09/13 at 5:42 下午

    擦szop告诉我CT是CronTab的缩写…你妹啊

  12. IT机主子
    2013/09/15 at 8:34 下午

    刚开发完一个监控系统

    躺枪了

  13. 2013/09/16 at 8:30 下午

    我最近在搞web化……

  14. XXX
    2013/09/25 at 6:03 下午

    我个人感觉,自动化应该首先以资产管理平台为核心向CMDB过渡,CMDB对外开放接口,如果运维人员有追求的话,自动化自然而然就慢慢实现了。如果专门成立自动化的部门根本实现不了自动化。

    • wilbur
      2013/09/25 at 8:54 下午

      资产管理最早就应该有,而且度厂的资产管理很庞大,但和最终到自动化是两码事。有信息不等于就可以自动化,个人认为

  15. 小康
    2013/09/30 at 8:11 下午

    全程经历过的那男孩爬过。。,深刻的经验只有经历过血的教训才能真正懂得,层级超过20级的网状ct任务关联、单台机器上几十个模块部署还需要串行重启、成百上千的端口&语义&日志监控、成千上万的handoff切换规则一次网络故障几千条报警手机直接没电关机有木有。。,如果重新来过,如果那时候有paas的选择且能够看的懂,现在的ops又会怎样是怎样的状态。。,可是,没有如果,^_^
    不得不说,经历是一笔财富!对运维尤其是!

    • wilbur
      2013/09/30 at 8:43 下午

      paas也不是万金油,也得周边的支持。有个度吧,全面推广,什么都覆盖,最终只会越走越艰难,我只能说到这里,唉。

  16. chinaxing
    2013/10/10 at 1:09 下午

    没有一个方法是万能的,要找到特定问题的特定解决方法。

    同样,web运维也只能是对于运维的某些场景是适合和最优的,而不是所有。

  17. yocloud
    2013/10/27 at 9:01 上午

    期待续文

  18. 2013/11/26 at 11:10 下午

    看介绍,CT可以用Celery替代

  19. tonyJeff
    2013/12/04 at 11:43 上午

    web其实可以等于自动化的,看一下facebook,google慢慢体会吧,
    有些事只是不愿意去想而已,我们不愿意去做而已,
    批量脚本是自动化没错;自动化的目标是简单,稳定,方便,实时,”傻瓜化“;
    这个后面是要有一套规则来支撑的啊,人机智能交互这个可以给我们些启发;
    有时间简易你学习一下maya,3dmax等看看他们是怎么实现3d动画的 呵呵

    • wilbur
      2013/12/04 at 11:59 上午

      自适应,自发现,可调度,呵呵……

  20. 2014/04/21 at 2:12 下午

    PHPnow 1.4.3 – 2008-01-23
    爱宠部落

  21. 匿了
    2014/06/12 at 1:21 下午

    去年7月份大学毕业,来公司做数据库管理平台,其实跟运维自动化差不多。吊毛不懂,没任何人指点,
    踩了各种坑,自己一个人搞了一年什么都没出来。
    写了cron管理中心,在web上添加任务,通过各个服务器的agent去跑任务,不用服务器上的crond。
    为垃圾场似的一群服务器写web部署,应对各种mysql版本,各种存储引擎。后来发现不事先定好规范,自动化根本没法做。
    现在大家把规范定的差不多了,计划继续做远程部署远程授权,死来想去觉得如果在终端实现这种服务器的批量控制不太难,但是搬到web上会带来好多不稳定因素和大量的工作。可人家就要web界面的,真尼玛蛋疼啊。

  22. 2015/01/18 at 5:15 下午

    同样经过,太多人把自动化==web化,没想过规范化是自动化的基础

    运维至少应该把 30%的时间用来讨论、确定、推广各种规范流程

    把流程规范隐藏在系统中,才是真正的自动化

laiwei 进行回复 取消回复