🎱2x18 让我来看看谁还在手工搬砖？

忙碌了整整两个月后，终于能有点时间静下心来写点东西。文人骚客经常说“艺术灵感来源于生活”，这一点笔者是感同身受的。“把解决方案看成一件艺术品，工程师就是艺术品的铸造者。”这是笔者经常挂在嘴边的话。

言归正传，今天晓冬想继续聊一聊“自动化”这个课题。在日常生活和工作中，“自动化”的身影无处不在。比如：

某工程师正在参与一个虚拟桌面的实施项目，按照SOW的分工，他需要完成AD用户和组的配置。那么问题来了：

1.如果只有50名用户，那动动鼠标、敲敲键盘，工作就完成了。

2.如果有200名用户，工程师可能会考虑找个脚本来自动运行，自己只需要提供符合格式要求的名单即可。

3.如果有500名用户，工程师一定想找个自动化的脚本来执行。

这就是摆在各位“打工人”、“搬砖工”面前的一个无法回避的命题：当需要重复一些标准化的工作时，我希望有“自动化工具”来为我提供便捷。

来说个笔者经历的真实项目吧：

IT需要为最终用户提供几百台各式各样的虚拟机，这些虚拟机涉及不同的硬件分配，不同的操作系统，固定的IP地址分配，还需要安装特定的软件应用……

面对这种体量的“私有云”，如果是采用“纯人工”的方式进行，那IT的工作量无遗是巨大的。

这其中涉及到不同团队之间的沟通与协作，也涉及对最终用户需求的“确认”和“落实”。在理想的情况下，如果流程进展顺利，那么大致的情况应该是这样的：

但往往真实的情况是：

1.最终用户在申请中对于硬件需求、操作系统小版本等信息的描述模棱两可，造成系统管理员经常返工。

2.网络管理员对于地址的分配缺乏有效的管理手段，经常出现“你PING一下这个地址有没有在用，没有在用啊？那就用这个吧！”的情况。

3.应用管理员需要进行一系列安全加固的配置，接着是针对应用软件的安装、调试和重启等工作。这个过程往往充斥着繁琐的步骤、突发的意外和BUG…….

4.安全管理员非常顺利地上线了防火墙策略，但是最终用户反馈特定的端口被禁用了，原因是提交的申请中遗漏了某一关键应用需要使用的特定端口…….

若真的如此，一个应用的上线时间短则三天，长则半月，这当然会严重影响IT的成效，也一定程度上降低了最终用户对IT服务的满意度，更影响了企业核心利益。这其实就是“手动搬砖”带来的弊端：复杂易出错、涉及团队多造成交付时间冗长、经常返工造成效率低下。

那么基于vRealize Automation(后文称vRA)“自动搬砖”是如何来一一解决这些问题的呢？接下来，我们不妨从IT的视角来回答这个问题。

0x01.IT与最终用户的关系定义

良好的“IT人员与最终用户之间的关系”，有点类似于“卖家”和“买家”的关系。试想一下，当我们中午想去M记或者K记吃快餐的时候，无论是偏向于单点还是套餐，我们都是根据店家提供的“菜品清单”来点单消费。这种机制对于买卖双方来说，都是有利的。对于卖家来说，将自己提供的服务，以“目录”的形式呈现给消费者，可以避免重复无效的反复沟通。对于买家来说，根据自己的需要，选择贴近自己需求的服务。平台通过合理的计费模型，卖家IT最终提供合理的“账单”，买家最终用户在享受了服务之后，也自然乐意为之埋单。

0x02.“菜单”的制定者

在笔者经历的项目中，“菜单”，也就是服务目录的制定者，往往是企业的系统管理员。他们在充分调研并且理解最终用户需求的基础上，提供满足最终用户需求的各类服务。比如：

IT经过调研，无论是正式环境还是测试环境，最终用户只使用CentOS7.9或者Ubuntu18.04这两种操作系统。同时对于硬件的需求大致可以分为4个级别—一些PoC测试的虚拟机对于资源的要求不高，而实际生产的虚拟机对于资源有严格的限定。

基于上述需求，管理员就可以在vRA上进行“菜单”的制定，包括：

定义映像模板，并且与vCenter上的虚拟机模板进行映射对应。

通过这种方式，系统管理员只需要维护CentOS7.9和Ubuntu1804两套模板即可。系统管理员或者应用管理员，可以将基本配置(如分区)、基础软件(如文本编辑器VIM)、安全加固措施(如CentOS开启SELinux等)进行统一的设定，减少重复的工作量。这就好比是“菜单”中的主食，是用户最基础的需求。

有了主食，根据最终用户的“喜好”，还需要定义“风味”，vRA配置中的Flavor属性就提供了这种可能。

管理员可以定义Flavor映射，将vRA提供的Flavor风味偏好与实际vCenter提供的硬件资源进行匹配。

过这样的方式，用户按需提交申请，IT按需提供服务，规避了“手动搬砖”出现的各种信息不对称的可能性，提高了交付效率。

vRA最终将Images与Flavors以“菜单选项”，也就是“服务目录”的方式提供给最终用户进行选择。实现的方式自然是基于YAML的蓝图，相对于“手动搬砖”，vRA带给系统管理员的改变在于“使用标准化与规划化来约束服务申请与交付”。

通过上图不难看出，vRealize Automation就是让IT的工作流程规范化、标准化、流程化。而相对于“手动搬砖”来说，管理员多了“需求调研”“架构设计”“流程设计”“蓝图设计”的工作，但获得的收益将会随着企业云平台规模的增大而越发明显。这也从一定角度上反映了只有IT重复的工作达到一定的量后，自动化才会逐渐成为最迫切的需求。

0x03.“菜单”的配菜者

如果说大部分企业中系统管理员负责向用户提供“菜单”，那么缺少了网络管理员、存储管理员这些角色，同样会造成服务交付的新瓶颈。在笔者经历的项目中，经常会听到网络管理员与用户之间发生这样的对话：

这是中大型云规模的IT人员经常会遇到的问题之一，原因在于：

1. 缺少有效的IPAM手段，没有一个对业务IP地址进行有效管理与分配的平台；

2. 缺少有效的IP冲突检测手段，对于开启了禁PING策略或者临时关闭电源的虚拟机，PING包检测IP是否占用会造成巨大的风险；

3. 强制粗狂的网络资源池分割，缺乏灵活性和可扩展性。

在几年前参加vForum大会交流数据中心网络与安全的时候，我就感叹过“现在的虚拟化早就不是交付几台虚拟机这么简单了！”我们依旧将虚拟机的交付看成一道菜，那么网络、存储、安全等等就是这道菜中不可缺少的调味。

对于网络管理员、存储管理员来说，合理评估现有的硬件资源，并对其进行分类与分配，是整个自动化周期内必不可少的环节。一般情况下，企业内部都会存在两个环境：生产环境与测试环境。生产环境经常采用传统网络架构+高性能数据存储；而测试环境经常采用软件定义网络+普通性能数据存储。但也有相当体量的用户，并不特意区分“生产”与“测试”，同一个vSphere群集也可能同时具有高性能数据存储和普通性能存储。

为了更好地分析自动化带给“配菜者”的变化，我们就从网络管理员的角度来进行分析。网络管理员除了在vCenter上正确配置“分布式交换机”外，还需要在vRA上进行“网络配置文件”的定义：

管理员通过定义网络配置文件，定义网络地址池、IP地址分配原则和基本的网络参数（如DNS、Suffix、NTP等）。

与之前的Flavor、Image相同，Network Profile最终也会被蓝图所调用。其实类似vRA定义的属性，最终都会在基于YAML的蓝图中，以“约束”和“标签”的形式被调用：

在vRA的这种框架下，网络管理员只需要一次定义，就可以满足今后很长一段时间业务扩容的需求。而且不必担心IP地址冲突的问题，vRA的IPAM会自动为业务分配不冲突的网络地址。这是云管平台应该具备的最基本的功能，如下图所示：

管理员定义了172.20.26.0/24地址池，划分的子网规模为28位掩码。

那么当有新应用被创建，需要分配IP地址时，vRA会自动划分出28位掩码的一个子网，提供该应用使用，并且为应用的每一台虚拟机自动分配一个可用的IP地址。

基于上述形式，原先的“缺少IPAM”“缺少冲突检测”“缺少灵活性”问题都因迎刃而解，提升了系统管理员与网络管理员之间的沟通效率。总结地来说，在vRA的框架下，网络管理员是架构层级的IT，而类似最终用户网络的实现(比如创建分段、创建网关设备、网络连通性)等重复性劳动，均可以由vRA来自动化进行。

如上图所示，vRA会自动在NSX上创建T1网关并连接到T0网关，创建分段并连接到T1网关，实现交付置备的虚拟机网络互联。

这种改变避免了“手工搬砖”的繁琐，也减少了出错的概率(在流程编排正确的情况下，vRA这种“机器人”是不会出错的，会严格按照参数的定义去进行交付)。无论对于网络管理员或者存储管理员来说，这都是巨大的改变和减负。

Ax01.“菜单”的消费者

一道菜色究竟好不好，最终的衡量标准还是要消费者来评判。在不考虑vRA本身的部署存在一定的复杂性以及部署成本的前提下，IT人员是没有理由拒绝的。那么，企业的最终用户，会不会认可vRA呢？

显而易见地，无论是对IT人员，还是对最终用户来说，避免长时间反复的沟通与修正，是提升双方效率的关键钥匙。单凭这一点，最终用户就会投“自动搬砖”一票。

除此以外，最终用户所有对“云”的诉求，都可以统一由云管平台来调度和实现。用户只需要通过单一的云管界面来提交申请和享受服务。这个很容易理解，为什么很多人都喜欢用TB？因为他们只需要访问一个App或者网站就可以购买到各种各样的商品，还享受三天包换、七天包退这样的服务和物流配送(某种意义上来说，这是买卖的全生命周期)。方便好用效率高既是产品更新迭代的目标，也是最终用户亘古不变的需求。

既然这道“菜色”如此贴合消费者的口味，自然也会受到消费者的认可和青睐。

写在最后

最后来说说笔者的感受吧。云管理平台百花齐放，但不可否认的是，产品本身的功能也存在一定的差异。如何选择一款好的“自动搬砖”产品，最重要的还是它要贴近需求，能真正帮助IT提高效率。有些时候，IT只希望有“一个工具”来自动创建虚拟机；那么虽然vRA除此以外，还提供了很多很强大的功能，但是不得不说，它带给IT的第二感觉还是“稍显贵了点”(第一感觉当然是强大好用)，此时IT可能就不会选择vRA。这是客观存在的事实，也需要客观地审视和对待。就像笔者在开头说的那样，只有云的体量达到了一定的规模，像vRA这样的产品才会真正成为用户的刚需。再比如，如果只是中小环境需要批量交付虚拟机，用POWERCLI就能实现了。如果只是从IT层面出发，监控虚拟机的性能指标，为出现竞争冲突的虚拟机批量调整内存和CPU分配，那么用vROps就可以了。因此最关键的，还是需要深入了解和挖掘IT以及最终用户的需求，才能对症下药，结合稳定安全的产品，制定合理的解决方案，用最小的成本实现最大的价值才是我们这些“艺术家”的本职工作。