首页 > IT生活 > 论运维自动化的正确姿势
2015
05-30

论运维自动化的正确姿势

采用积木模型搭建自动化运维

1.png

接下来的自动化建设,先是构建不同的积木,最后就是搭建积木的过程。

一般我会从利益最大化的自动化平台建设开始,比如说持续集成,因为会跨越研发、测试和运维等多个团队,并且这个过程可以强制植入运维规范。通常会分成三部分:

  •     做规范和标准化

  •     把架构公共化、服务化

  •     做服务精细化、无状态化

2.jpg

其实自动化很多都是和标准化及业务技术架构紧密相关的,目前正在 UC 按照这套思路推进,已经进入到第二阶段,部分业务进入到第三阶段。

越到后面,其实我们就发现自动化平台就变得越来越简单。构建面向业务或者场景的服务,只是利用不同的积木搭建模型而已。

对于无状态化,我的理解是服务不依赖某个中心,某个节点、某个进程。我们现在采用的策略是从业务的核心路径逐级去梳理,识别单点,但对于一个庞大的系统来说,根本无法完成,最后我们上线名字服务中心,自动化绘制访问流,基于业务或者服务级别,提出高可用的要求,比如双中心、服务降级,过载保护等标准。

目前我们也正在挑战用积木搭建模型的过程,和一些大公司运维平台比起来,我们起步相对较晚。

另外,我觉得还有一点非常重要,运维团队和个人能力模型,决定了自动化运维能走多远。现在业务运维团队都让他做运维研发的事情,但是和业务相关的研发,平台公共类还是在运维研发组。最终希望运维团队往价值运维和优化运维转型转变,低价值运维就是苦逼的代名词。

还有,要找到核心的矛盾点,有些运维实际是要 CMDB 作为基础的,必须解决数据准确的问题;有些是运维效率不高,低价值活动多的问题。这个时候就要找自动化做突破口了。但一定要服务于整体的运维目标,运维从一些低价值活动中释放出来,方能做优化类事务。

3.jpg

运维自动化的方法论

    场景驱动,一定要找到自己的场景支撑,不要随意跟随别人所说,特别是一些开源的方案不一定能适合自己的企业实际

    全局驱动,给出一个自动化平台的全局目标,像 cloudliu@腾讯游戏 说的智能化运维,这样才能分解出我们阶段性的目标是如何

    分而治之,但提前做好提供 API 的服务接口设计,有些系统建设不是运维完成,比如说架构及服务那块,什么 RDS、图片存储服务等等,特别是比较看重的名字服务

    自底向上,需要知道自己的地基是什么,然后在做面向业务场景的自动化调度平台,而不是反过来

    最后是插件化,这个更多是讲面向业务的自动化调度平台的一个服务插件化,可以接入更多的服务进来

    边界也要清晰,不要越界去做一些事情,比如说我们以前做应用发布系统,最后想在这个系统内做自动服务调度,这个就不合适,应该是上层调度系统去做的事情

为什么会有运维自动化工具?

自动化运维平台可以分不同阶段来积累,尤其是公司小的时候,最初公司只有几台服务器服务器时候,我们最多搞的是脚本—自动执行脚本,开始在单台服务器上运行

随着公司业务的发展,开始有集群了,Web 一台搞不定了,需要考虑到横向扩展,这时候可能有多台同应用的服务器,我们这个时候可能考虑到脚本在单台服务器执行效率太低。这个时候大家会想是不是有更好的办法,在一台服务器上去推送脚本在所有的服务器去完成工作?答案是肯定的,这个时候各种各样的运维工具应运而生了。

运维自动化工具怎么选?

    案例一:从 Puppet 到 SaltStack 的过渡

    先开始我们一致想推 Puppet 试试,把现在所有项目的脚本结合起来跑,因为通过 Puppet 可以快速的下发脚本到设备上。

    后来发现 Puppet 也能搞但是过于庞大。庞大的意思是指:游戏的迭代很快,更新快,每个项目都不一样。很有可能 Puppet 部署上去还没用几天,项目就结束了。

    后来想有没有更加快速部署,分分钟搞定的工具,尝试了 SaltStack 和 Ansible。

    在 SaltStack 用过一两个月后,发现后这个蛮适合快速部署。安装 yum 直接搞定,配置非常简单。游戏项目的人员也很喜欢。

    Ansible 也 OK,但是它需要服务器直接做 SSH 验证,大家都反感做 SSH 认证,这跟我们的工作类型有关,因为游戏项目有的是自己的,有的服务器是别人维护的,如果所有的都弄一个 Key 认证,安全性就有问题,也不能每个项目产生一个 Key,然后分发到所有的服务器。有一次我们一天启了 800 多台 Server,如果分发 Key 的话,就得搞死人了。

    相比之下,SaltStack 的操作步骤更加简化,因为把 SaltStack 安装好,模板直接克隆就可以了,这是在云平台上进行操作,同样如果云平台没有一个好的用户体验平台,那也得搞死人。

    案例二:为什么选择 Ansible?

    我来说一下我们的应用场景,我们的服务器是在安装初始化后提供给第三方合作厂商使用的,这种场景下在服务器端部署 Agent 就不太合适,一是第三方可能会在机器上部署自己的 Agent,有可能引起冲突,二是无法保证 Agent 不会被第三方干掉,但我们还需要对机器进行必要的监控以及资源数据采集,所以这种情况下我们最好的选择是直接通过 ssh 来进行相关的监控和部署操作,因为 Ansible 好的一点就是不需要装客户端,通过 Ansible 的 API 进行简单的二次封装,整合到我们的运维管理平台。

    案例三:为什么我们抛弃自动化工具,选择自研发?

    我经历的几家都没有用 Puppet,主要是包的配置文件管理的问题太复杂。不同的集群(比如说 IDC1、IDC2),不同的用途(比如说容灾)都不一样。而且在这些公司中都是有运维支撑的,在语言选择上没有什么好说的,腾讯是 PHP、YY 是 Python、UC 是 Python,我团队内部是 Python 和 Ruby。

    我个人对研发团队和业务运维研发的边界划分是,研发团队负责平台型的研发,比如说 DNS、LVS 管理,而业务运维就开放面向业务的运维平台,比如说持续集成,去年我就尝试让三个业务运维同事转型做运维研发,当然还是要做运维。一直强调业务运维自身需要以做手工活为耻,以自动化为荣。我一直理解运维研发能力是业务运维人想象力的翅膀

    所以我在选型的时候,一般都跳过配置管理工具,自己研发。在 YY 是这样,在 UC 也是这样。因为工具的选择肯定是只选适合自己的,不一定选择最好,功能最多的。




最后编辑:
作者:tshare365
这个作者貌似有点懒,什么都没有留下。
捐 赠您的支持是博主写作最大的动力,如果您喜欢我的文章,感觉我的文章对您有帮助,请狠狠点击

留下一个回复