云计算时代，运维工程师的逆袭

大家好，我是青云系统工程师施炳文(Steven)，负责控制台、通知系统、告警系统等功能的研发。今天和大家分享的话题是《运维工程所的逆袭——云资源管理》

传统运维中的那些坑

不知道群里各位有没有之前接触过传统 IT 运维的工作？运维工程师，其实，在以前工程师的体系里是相对比较苦逼的工种。不止是因为薪水比别的工程师低一点，还体现在:

我以前有一些朋友做运维工作，其中有一个特别好的朋友在新浪做过四、五年运维工程师，现在正在自己创业。我们交流时，他说现在做运维和以前做运维完全是两个时代的事情，创业也变得更简单了。

他具体说了这几个方面：

现在创业团队中的运维不需要像以前一样，在做一个产品之前，就要先买几百台服务器。100 台服务器，这个数量对大公司来说不是特别大的数字，但是对于一个初创企业来说，几百万的投入决策也许就决定着团队的生死问题。

而且，服务器买来以后还需要进行繁琐的配置。（我的朋友经常自己编译新版本的 FreeBSD，想象一下，把 100 台服务器放在面前，挨个装操作系统。100 台服务器，装操作系统就要一个下午或者更长的时间。）装完后把这 100 台服务器放在机房里，挨个塞到机架上，插上网线、电源线、硬盘，把机器跑起来。

是不是很辛苦？

但是即使是这样，也没有结束，当产品真正上线后需要做的事情更多。比如 A 部门做了一个产品，它需要一些服务器，给他分配了 1-10 号服务器。过一段时间，B 部门也需要服务器部署产品，给 B 部门分配 11-20 号服务器，这些都得记录下来（很多公司是拿个小本子或者 Excel 文件记录）。

但是，当公司的业务规模随着产品的发展越来越大，开发人员越来越多，产品线越来越长，甚至运维团队本身也有老人离职，有新员工入职，资源的管理会变得异常复杂，特别艰难。

最后可能会出现什么情况呢？

想象下，假如您的公司出现一台设备，但是你不知道是做什么用途的，该怎么办？

正常情况，肯定会跑到公司沟通群里喊：“谁在使用这个设备？”

但是当公司很大的时候，运维工程师肯定没法这么做（如果运维工程师自己都不知道某个机架上的某个服务器跑什么业务，业务部门更不知道了，对吧？）所以，传统的IT运维工作其实是相当辛苦的。

云时代的运维的七种武器

但是，随着2012年后云计算的兴起，运维工程师开始逆袭了，不再是以前的苦逼状态，现在大家坐在办公室里喝着咖啡，随手就把运维的活给完成了。

那么云计算到底通过哪些方式来改变我们的运维工作呢？（或者说从我们青云的角度如何来看待云资源的管理？）今天主要给大家分享两个方面的东西：

下面我们先来谈一谈资源的分组隔离与授权：标签、子帐号、资源协作。

2.1

标签

如上图，标签，比较容易理解，给一部分资源绑定一个标签。比如 A 团队用了 10 台服务器，给这 10 台服务器绑定一个标签。B 团队用另外的服务器，给它绑定一个标签。

给同一个资源绑定多个标签可以实现资源的多维度管理。比如说有一些资源用来做测试，给他绑定测试环境的标签，有些资源是线上环境，给它绑定生产环境的标签，还有其他预发布等另外维度的标签。

这些标签都在云系统中记录，永远不会丢失，不会出现之前（用本子或者 Excel 来记录）那种管理混乱的问题。

2.2

子帐号

子账号也是一个给资源做分组的工具。刚才的标签也可以做分组， 有什么区别？

子账号之间资源完全隔离，但可以共享主账号的余额和资源，只要给主账号充足够的余额，子帐号自己就不需要关心充值等问题。后期还可以通过导出消费记录来预估和核算每个部门每个月大概花多少钱，用了多少资源。

2.3

资源协作

资源协作是刚提供的新功能，这个功能会把资源管理的权限更细致化，上面这个截图就是在资源协作中，把一些资源授权给某个用户的操作。

适合什么场景呢？

上面讲到我们如何管理资源。下面我们来谈一谈青云提供的几种自动化运维工具：监控告警，自动伸缩，定时器，Open API。

2.4

监控告警

作为一个工程师，我们平时非常关心资源的状态（尤其是线上环境）。

服务器并不是放在机房就没事了，服务器跟孩子一样，它也会生病、闹脾气，需要时刻关注它的状态。作为运维工程师，一般部署完资源之后，还要给它写配套的监控程序，不同的公司会根据不同的需求写监控程序，然后根据监控得来的数据调整和优化系统。

以前运维部门都有个专门做这个事情的岗位： 运维开发，一帮小伙每天写代码，开发适合自己的监控系统、告警系统。来到现在云计算的时代，云计算提供的服务都是统一的标准，所需要的监控告警等运维工具基本上是差不多的，所以，青云QingCloud 作为云计算服务提供商，直接帮助大家把这个事做完了。

在青云，所有服务在发布之前，我们都会给它加相应的监控告警。并且所有的 IaaS 资源、PaaS 资源，不同的资源监控指标不一样。比如主机，一般我们比较关心它的 CPU、内存、硬盘有没有写满，如果是数据库，可能更关心数据库的连接数是多少，公网 IP 关心进出流量的带宽是多少等等。

我们提供的监控告警也有很多其他更细化的配置（比如生效时间，触发频率），为大家提供更多的选择。

另外，不管是有 2、3 台服务器，还是 50、100 台服务器，并不需要挨个去配置告警服务，我们支持一个监控告警策略，可以批量绑定到多个资源上。（如果后面需要调整监控指标，只需要改策略，点击修改后，所有绑定的资源都会得到相同的更新。）

我们还提供了监控告警的历史记录。因为并不是仅仅在出现故障的时候触发告警就可以了，在一段时间之后，我们也需要根据一周或是一个月的告警历史做分析，分析这些服务器会在什么时间点，因为哪个监控的指标发生告警，通过分析这些数据，就可以知道资源瓶颈容易出现在什么地方，然后做相应的调整。

2.5

自动伸缩

接下来是一个大家更感兴趣的话题，那就是自动伸缩，因为它可以帮大家节省非常多的钱。

如果是传统的 IT 运维，一般产品上线前就需要提前预备资源。假如有一家提供 xx 服务的公司，平时的业务量需要 10 台主机， 那上线前就买 10 台服务器。

但是有个问题： 如果有一天公司的运营部门或是市场部门做推广、抢购等线上活动，用户量会突然上升，到时候可能需要 30 台主机，怎么办？

财务比较宽松的公司，一开始 30 台主机就准备好， 提前购买放在机房，平时 10 台主机开机，应付平时的压力。等到活动开始时，打开另外 20 台主机，30 台主机一起上，应该能解决问题，对吧？

但是又有问题了：

但是在云上情况就不一样了，只要根据当前的业务按需创建主机既可（如果需要 5 台主机就申请 5 台）绑定自动伸缩的策略，等到搞活动的时候，随着流量上涨，伸缩策略会自动根据上涨的情况添加所需要的主机（比如流量上涨 10Mbps，自动加 2 台主机，如果流量还上涨再加 2 台，如果还不够再加 10 台）。

自动伸缩这个工具让云计算相对于传统的运维无论是从经济上，还是从效率上都更加有意义，不需要为了很多不必要的资源提前买单，也节能环保。

青云目前提供自动伸缩的方式，尽量以最简单的方式提供给大家。只需要在控制台上点两下鼠标，配置几个参数就可以了。

事实上青云系统会根据自动伸缩的策略在后端生成一个 Python 脚本，青云有专门的服务器来运行这些脚本，帮助大家做自动伸缩。

未来会考虑支持让用户自己上传脚本，一些高级用户平时遇到的情况跟普通用户不太一样，有特殊的伸缩需求，那么可以自己配置伸缩脚本，变得更加灵活。

2.6

定时器

以前做运维工程师的时候，做得最多的就是备份。每周、每天备份，每小时备份核心数据。工程师特别讨厌人工操作，因为能用代码、脚本实现的，为什么要用人工？

所以青云提供定时器功能，只要配置好时间周期，它可以定期执行操作或者触发一些行为。

再举个场景： 假如有一个测试服务器，可能不是每天都会使用，只有上班的时候才会用来做测试。那么可以配置一个定时器，如果早上 8:30 上班，配置 8:25 自动开机，如果是 6:30 下班，6:35 自动关机。

这台测试服务器每天只开 8 个小时，也就是上班时间。甚至不用管它，因为它会自动开关机。每天 8 小时，相对于之前开机 24 小时，可以节约 3 倍的成本。

2.7

API

如果我们上面提供自动化运维的工具依然不能满足运维的需求（如果你有一些特殊的运维需求），那么可以试一下我们提供的 300 多个 Public API。

通过 300 多个公开的 API，基本上可以管理和操作青云所有的资源（我以前做过前端工程师，青云的控制台 100% 基于 API 实现，如果觉得它不好用或是有自己偏好，完全可以自己根据 API 写一个控制台）。

CLI 和 SDK 是 Public API 的封装，通过这两个东西可以让 API 用起来更加简练。官方提供 Python 版本的 SDK，例如像创建主机这种操作，只要调用库中的一个方法就可以。

很多公司或是技术能力比较强的公司，一般以前都有自己的运维系统，也可以通过 API 的方式把青云和自身的运维系统做融合、对接，在运维系统上操作，底层控制青云的资源。

上面这些讲解，主要是想把我们对于自动化运维的理解和思路分享给大家。