当企业随着业务的扩展使用越来越多的资源时，如何高效地管理一个或几个巨大的资源集群，使运维工作变得更容易、更简单、更灵活？
今天的内容主要从云资源自动化管理工具入手，体现了云计算在企业级解决方案中相对于传统运维的巨大优势，包括：云资源的分组分类、隔离授权、如何使用高效运维工具(监控报警、自动伸缩)等。
以下是共享文本：
大家好，我是Steven，青云系统工程师，负责控制台、通知系统、报警系统等功能的研发。今天要和大家分享的话题是《运维工程所的逆袭——云资源管理》
一个
传统操作和维护中的那些坑
不知道组内大家之前有没有接触过传统的IT运维工作。实际上，在以前的工程师体系中，操作和维护工程师是一项相对艰苦的工作。不仅因为工资比其他工程师低，而且还在：
运维工程师在线操作系统，平时压力很大，需要7x24小时维护系统正常运行。
平时，在老板和领导眼里的存在感比较低。只有系统出现故障，老板才会突然想到运维工程师。
以前有一些朋友做运维工作，其中有一个很好的朋友在新浪做了四五年的运维工程师，现在正在创业。我们聊的时候，他说现在做运维和以前做运维完全是两个时代，创业变得更简单了。
他具体说了这些方面：
首先，融资相对容易，只要事情做得可靠。
第二，创业主要是轻资产模式，最大的资本投入是人，只要有人。(不需要租用办公室，但办公室和办公设备可以由第三方创业服务提供商租用，财务、法律事务、人力也有专业外包团队。)
第三，IT运维模式的改变(从传统运维到云计算，大幅降低成本)也是今天的话题。
现在，创业团队中的运维在做产品之前不需要购买上百台服务器。100台服务器，对于一家大公司来说并不是特别大的数字，但对于一家初创公司来说，几百万的投资决策可能决定着团队的生死。
而且服务器购买后需要复杂的配置。(我朋友经常自己编译新版FreeBSD。想象一下，把100台服务器放在我面前，一个接一个地安装操作系统。对于100台服务器，安装操作系统需要一个下午或更长时间。安装完成后，将这100台服务器放入机房，逐一插入机架，插上网线、电源线、硬盘，运行机器。
是不是很难？
但即便如此，也没有终点，当产品真正上线时，还有更多事情要做。比如A部门做了一个产品，需要一些服务器，给他分配了1-10台服务器。一段时间后，B部门也需要服务器部署产品，需要将服务器11-20分配给B部门，这是必须要记录的(很多公司拿着小笔记本或者Excel文件记录)。
但是，当公司的业务规模随着产品的发展而增长，开发者越来越多，产品线越来越长，甚至运维团队本身也有老人离职，新员工加入公司，资源的管理就会变得极其复杂，特别困难。
最后可能会出现什么情况呢？
首先，控制和管理各部门使用的资源变得困难(复杂的应用和交付流程)；
二是资源混杂。有时，同一台服务器可能被多个团队使用，运行不同的服务。归根结底，不可能清楚地记录每台服务器上运行的是什么业务。
想象下，假如您的公司出现一台设备，但是你不知道是做什么用途的，该怎么办？
正常情况，肯定会跑到公司沟通群里喊：“谁在使用这个设备？”
但是当公司很大的时候，运维工程师肯定没法这么做（如果运维工程师自己都不知道某个机架上的某个服务器跑什么业务，业务部门更不知道了，对吧？）所以，传统的IT运维工作其实是相当辛苦的。
2
云时代的运维的七种武器
但是，随着2012年后云计算的兴起，运维工程师开始逆袭了，不再是以前的苦逼状态，现在大家坐在办公室里喝着咖啡，随手就把运维的活给完成了。
那么云计算到底通过哪些方式来改变我们的运维工作呢？（或者说从我们青云的角度如何来看待云资源的管理？）今天主要给大家分享两个方面的东西：
一是如何做资源的分组隔离与授权；
二是提供什么样自动化运维工具，让大家更方便的管理这些资源。
下面我们先来谈一谈资源的分组隔离与授权：标签、子帐号、资源协作。
2.1
标签
如上图，标签，比较容易理解，给一部分资源绑定一个标签。比如 A 团队用了 10 台服务器，给这 10 台服务器绑定一个标签。B 团队用另外的服务器，给它绑定一个标签。
给同一个资源绑定多个标签可以实现资源的多维度管理。比如说有一些资源用来做测试，给他绑定测试环境的标签，有些资源是线上环境，给它绑定生产环境的标签，还有其他预发布等另外维度的标签。
这些标签都在云系统中记录，永远不会丢失，不会出现之前（用本子或者 Excel 来记录）那种管理混乱的问题。
2.2
子帐号
子账号也是一个给资源做分组的工具。刚才的标签也可以做分组， 有什么区别？
标签功能只是局限于本身一个账号体系下的资源做维度上的划分。
子账号则适合一个相对比较大的公司，它有多个部门，包括 A 部门、B 部门、C 团队、D 团队，他们分别负责单独的产品线，需要自己单独管理资源，这种情况下可以给他开一个子账号，让他自己创建和管理资源。
子账号之间资源完全隔离，但可以共享主账号的余额和资源，只要给主账号充足够的余额，子帐号自己就不需要关心充值等问题。后期还可以通过导出消费记录来预估和核算每个部门每个月大概花多少钱，用了多少资源。
2.3
资源协作
资源协作是刚提供的新功能，这个功能会把资源管理的权限更细致化，上面这个截图就是在资源协作中，把一些资源授权给某个用户的操作。
适合什么场景呢？
一个公司的两个部门，平时大家做不一样的工作。如果有一天需要相互合作： A 部门有一个任务，B 部门的某个同事可能更擅长，需要他帮助完成。那么， A 部门把相应的资源授权给 B 部门的同事，他在上面做开发部署，当他完成后，再把给他的权限收回。这是一个协作的过程，所有的资源仍然管控在 A 部门名下， B 部门的同事只是个协作的关系。
公司跟外包团队合作， 和上面同理， 可以把资源部署在公司自己的环境下，授权给外包团队来使用和操作。
上面讲到我们如何管理资源。下面我们来谈一谈青云提供的几种自动化运维工具：监控告警，自动伸缩，定时器，Open API。
2.4
监控告警
作为一个工程师，我们平时非常关心资源的状态（尤其是线上环境）。
服务器并不是放在机房就没事了，服务器跟孩子一样，它也会生病、闹脾气，需要时刻关注它的状态。作为运维工程师，一般部署完资源之后，还要给它写配套的监控程序，不同的公司会根据不同的需求写监控程序，然后根据监控得来的数据调整和优化系统。
以前运维部门都有个专门做这个事情的岗位： 运维开发，一帮小伙每天写代码，开发适合自己的监控系统、告警系统。来到现在云计算的时代，云计算提供的服务都是统一的标准，所需要的监控告警等运维工具基本上是差不多的，所以，青云QingCloud 作为云计算服务提供商，直接帮助大家把这个事做完了。
在青云，所有服务在发布之前，我们都会给它加相应的监控告警。并且所有的 IaaS 资源、PaaS 资源，不同的资源监控指标不一样。比如主机，一般我们比较关心它的 CPU、内存、硬盘有没有写满，如果是数据库，可能更关心数据库的连接数是多少，公网 IP 关心进出流量的带宽是多少等等。
我们提供的监控告警也有很多其他更细化的配置（比如生效时间，触发频率），为大家提供更多的选择。
另外，不管是有 2、3 台服务器，还是 50、100 台服务器，并不需要挨个去配置告警服务，我们支持一个监控告警策略，可以批量绑定到多个资源上。（如果后面需要调整监控指标，只需要改策略，点击修改后，所有绑定的资源都会得到相同的更新。）
我们还提供了监控告警的历史记录。因为并不是仅仅在出现故障的时候触发告警就可以了，在一段时间之后，我们也需要根据一周或是一个月的告警历史做分析，分析这些服务器会在什么时间点，因为哪个监控的指标发生告警，通过分析这些数据，就可以知道资源瓶颈容易出现在什么地方，然后做相应的调整。
2.5
自动伸缩
接下来是一个大家更感兴趣的话题，那就是自动伸缩，因为它可以帮大家节省非常多的钱。
如果是传统的 IT 运维，一般产品上线前就需要提前预备资源。假如有一家提供 xx 服务的公司，平时的业务量需要 10 台主机， 那上线前就买 10 台服务器。
但是有个问题： 如果有一天公司的运营部门或是市场部门做推广、抢购等线上活动，用户量会突然上升，到时候可能需要 30 台主机，怎么办？
财务比较宽松的公司，一开始 30 台主机就准备好， 提前购买放在机房，平时 10 台主机开机，应付平时的压力。等到活动开始时，打开另外 20 台主机，30 台主机一起上，应该能解决问题，对吧？
但是又有问题了：
有时候的推广活动可能会出现 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 的方式把青云和自身的运维系统做融合、对接，在运维系统上操作，底层控制青云的资源。
上面这些讲解，主要是想把我们对于自动化运维的理解和思路分享给大家。
更多相关内容请点击阅读原文。
【预告】7 月 28 日，QingCloud Insight 2016 将邀请 50 多位行业专家分享云计算、大数据、机器学习、容器、DevOps、安全等领域的前沿话题，打造一场业界交流、开发者学习、创业创新项目展示的顶级云计算盛会。
名额有限，报名请扫码下方二维码。
- FIN -
