DT时代，云上运维的“变”和“不变”

1、背景

    作为一项全新的IT革命性技术，云计算似乎比以往很多新技术的发展速度都要快。在不到十年的时间里面完成了从诞生、早期实践、到最终被普遍接受的整个技术发展周期。如今，无论是云计算中的基础设施云（IaaS），平台云（PaaS）或者应用云（SaaS）都已经广泛进入企业生产环境。按照IDC最新的报告显示，未来5年中，在全球IT行业整体年均增长速度不到2%的大环境下，云计算行业的年均增长速率将超过15%。由此可见，整个云计算行业的发展速度非常迅猛。在国内，阿里云作为最早（2008年）跟进这一潮流的巨头，过去6年里面取得了非常大的成就，成为国内IaaS领域的绝对领先者。

    云计算的一个重要特征就是“开箱即用”，由云供应商提供集中化的运维管理并以服务方式交付给最终用户。这让云用户可以从很多繁琐的日常运维工作中解放出来，真正关注自身的业务发展，从而提升整个行业的运营效率。但是正因为如此，这一年来在IT运维圈里面出现云计算会革命运维的说法，并引发了运维人员危机的大规模讨论。对于运维人员自身的强烈危机感应该点赞，但在讨论运维危机之前，我们不妨先分析一下云技术给运维行业带来了什么样的改变，而哪些又是仍然保持不变。所以，个人在这里就云上运维的变与不变谈谈一些自己的观点。

2、云上运维的不变

    如果回顾历史，除去早期大型企业内部的少部分IT运维人员，中国运维行业的兴起应该是随着互联网行业上个世纪90年代在中国的发展而来。所以，中国的运维行业以互联网运维为主。由于互联网和移动互联网的快速发展，运维从业人员积累了大量的对于运维行业和运维职业的理解。尽管云计算的崛起对于运维行业会带来很多变化。但是，我们在这其中要看到运维行业的自身发展规律以及其中的不变。个人认为这种规律性的不变量至少体现在下面几点：

    ●运维的目标一直未变，即通过高效运营IT系统来提供高质量的IT服务，并最终帮助实现业务价值。这个目标里面包括的三要素，即运营的对象仍然是IT系统，运营的目标是提供高质量IT服务，而运营最终的价值是通过业务价值来体现。对照云上运维场景，可以看出如上三个要素仍然未有任何变化。

    ●运维的主流方法论仍然未变，即通过自动化提升效率，通过数据化实现精细运维。自动化一切的运维方法论无论是在云下，还是在云上都是一直有效，而且都是保证高效运维的核心原则。数据化运维是进行精细运维的前提条件。只有通过数据才能回答IT系统的运营是否高效，提供给用户的IT服务是否高质量，最终的业务价值是否体现出来。

    ●运维的主要场景并未变化，即运维人员面对的日常运维场景仍然是上/下线服务，扩/缩容，批量操作，升级/回滚服务等。而运维人员进行日常运维的主要手段也仍然是监控告警，环境管理和代码部署等。

    ●运维的发展要求也未有变化。整个运维行业的发展都一直在追求更好的IT系统敏捷性和更优的成本结构。诞生于云计算普及之前的DevOps运动就是这个发展要求的重要体现，而且在云上这种新的软件生产方式不但没有被改变，反而更容易得到落实。同时，云平台提供的弹性伸缩、按需付费模式恰恰更好得满足了现代互联网业务对于IT系统敏捷性和弹性成本的要求。

    通过上面的分析，可以看出运维的很多根本性要求并未因为云而发生改变，而这些要求恰恰是运维行业之所以需要存在的根本原因。既然这样，云给运维行业到底带来了哪些变化呢？

3、云上运维的变化

    由于公有云（尤其是公有云IaaS）的普及，整个云上运维和传统IDC中的运维还是呈现出比较明显的不同点，我们可以从下面几个角度来理解这种不同点。

    3.1 应用运维成为云上用户的运维重心

    一般来说，很多企业的运维部门主要工作包括基础运维（针对企业IT基础设施的运维）、应用运维（针对企业具体业务的运维），较大的运维部门可能还有单独的运维开发，负责为公司运维部门开发运维工具和平台。当用户决定上云（尤其是IaaS公有云），就表示用户已经把基础运维以及相关的工具平台开发工作交付给云供应商，而把应用运维作为整个运维部门的核心。当然，这也符合云计算希望让用户只关注自身业务发展的初衷。如果从宏观上看，这种变迁可以用下图描述：

图1 变迁图

    由上图可以看出，云上用户第一个需要做的改变是把整个运维重心转移到应用运维上。当然，在企业上云过程中不可能一次性完成如上的切换，必然会有一个很长的时间段内有传统IT和云上IT共同存在，共同运维的要求。而且为避免被一家云供应商锁定，企业非常有可能同时采购多家云供应商的服务。所有这一切都需要企业运维部门拥有统一管理不同来源，不同模式的基础设施能力。而且由于不同来源基础设施的自身运维管理能力不同（如公有云IaaS提供的基础设施就比传统IDC的基础设施有更好的自我运维管理能力），这就要求企业运维部门的运维平台能够补齐相应短板，磨平不同来源基础设施的不同。以便能够统一标准化、自动化日常的运维管理操作。当然，在这个过程中，企业运维部门仍然要优先关注应用运维工作，并把基础运维工作尽可能的交给IaaS供应商或者第三方工具。

    3.2 公共组件普遍服务化

    在企业内部，不同业务IT系统都会用到很多公共组件（如数据库，消息队列等）。由于团队的技术背景不同，业务要求不同，经常会出现这些公共组件选型的不一致性，导致上线后的运维负担非常重。所以，企业内部运维部门的一个重要工作就是把这些公共组件标准化并最终服务化，能够对具体业务部门完全透明。这样即可以降低运维部门自身的运维成本，又可以提高业务部门的开发效率。但在云技术平台出现之前，很多企业的IT运维部门要想完成公共组件服务化的工作并不容易，所以这个想法很多时候只能在有雄厚资源和有很强运维研发能力的公司才能落地。而云计算平台（尤其是公有云IaaS平台）的出现让公共组件服务化的能力惠及所有云用户。例如阿里云提供了数据库服务RDS，消息队列服务MQS，事件通知服务ONS等等。这些服务背后的技术都是经历阿里电商系统大规模验证，并且由专门团队运维。用户完全可以信任。有了这些服务化的公共组件，企业运维部门在内部推进业务部门使用标准化公共组件会容易很多。所以，在云上的IT系统选型时，企业运维部门最好能更早和业务部门合作，力争使用云上标准化服务组件，而不是把传统IT系统系统简单搬迁到云主机。如果在企业上云过程中能把握好这一点，其实就能够把上云过程和公共组件标准化和服务化的进程很好统一起来，既能降低运维成本，还能够保证服务质量，加速软件开发工作。

    3.3 弹性和自助式成为基础设施的基本要求

    在云计算平台中，无论是存储服务，计算服务还是网络服务都会提供弹性伸缩，按需付费的功能。绝大多数情况下，你可以认为云供应商提供的资源是足够的，把容量管理这个工作交给云供应商。作为云上用户，只需要用时申请，结束时释放即可。对于企业运维团队来说，这一点非常重要。在传统基础设施中，获取基础设施的弹性非常不容易。为此，很多公司运维团队都会在基础设施使用上面制定很多规章制度和流程，以方便进行容量管理和规划。当管理云上基础设施时一定要注意避免这种人为削弱基础设施弹性的流程。相反，运维团队需要把云计算供应商提供的弹性能力充分暴露给业务研发团队，并鼓励业务研发团队为弹性基础设施做设计（如支持状态无关和水平扩展），甚至参与到业务架构中的设计，充分使用如阿里云弹性伸缩服务（ESS）等一系列弹性服务。这样一方面可以大幅度降低运维成为（如业务扩容、缩容都能够自动完成），另外也可以满足基础设施成本的弹性需求，降低整个业务的运营成本，提升在市场中的竞争力。

    除了弹性，自助式服务成为云上运维非常基本的一个要求。传统IT环境中，部分大型企业可以提供自助式IT基础设施服务，但是对于大部分普通用户来说，这种服务的成本太高（无法预先提供足够的资源池），但是云的出现让这种方式得以普及，任何用户都可以在分钟级别自助获取一个完整系统架构需要的基础设施。自助式基础设施服务在整个IT系统的生产流程中非常重要，因为IT系统的开发、测试、预发和生产都涉及到基础设施。如果能够让这个获取过程完全自助式，一方面可以大幅度提高整个流程的迭代速度，另外一方面也可以减少运维人员在这些方面的时间开销。现在，任何一家企业运维部门在采纳云计算平台的时候最好都先梳理一下自助式平台的需求，在上云的同时把这种自助式基础设施推广到软件研发的每一个环节。或许你会担心自助式平台带来的IT基础设施滥用问题，这个可以通过成本核算来加以控制。运维部门也可以在云平台上层构建自己的基础设施自助平台并嵌入相应成本管控规则。注意，如果需要限制使用，更多的是限制整体成本而不是限制每一项资源的具体使用。只有这样，才能让研发团队充分享受云带来的弹性和敏捷。

    3.4 可编程基础设施融入运维管理体系

    无论是传统的ITIL体系还是ITOM领域，运维管理体系的基础都是CMDB（配置管理数据库）。CMDB中保存着整个IT系统的基础设施元数据，并以此为基础支持监控场景、部署场景，日常批量运维场景等等。对于传统IDC中的基础设施，由于变化并不频繁，CMDB的维护更多是通过人工来完成的。但是，在云平台上，所有的基础设施服务都会提供API接口，从而变成了可编程的基础设施。这就为CMDB中的基础设施管理完全自动化提供了前提条件。而云上服务对于弹性的强要求又导致基础设施的变化比传统IDC中频繁得多，这就要求运维管理系统自动感知基础设施变化。所以，可编程的云基础设施必须要融入你的日常运维管理体系中并使用完全自动化的方式进行管理。用户甚至可以通过感知基础设施变化的能力进一步集成自动化部署逻辑。例如，一台云主机启动起来后，运维管理体系能够感知到它的加入，能够按照预先指定的自动化部署脚本对它进行IT系统部署。在部署完成后主动加入系统的负载均衡器，开始服务用户。因为基础设施的可编程，上面整个部署流程完全可以和基础设施实施一体化自动管理。当然，如果要把可变成基础设施融入到运维管理体系中，则需要运维研发部门给自己运维平台对接各种云供应商的API，并需要相关的集成开发工作。如果企业不愿意投入资源完成这种对接，也可以选择第三方工具达到同样的目标。

4.最后总结

    在云上，运维所追求的目标未变，主要的思路也未变。但是因为云计算带来的基础设施层面变化对于运维的影响也是明确的。在这个过程中，运维需要主动出击，积极适应云带来的各种优势，并积极向上扩展（例如，更多加入cloud native应用的架构设计中，提供自助式IT服务等等），扩大自己的影响力。为适应这个转变，企业运维部门可以考虑重新构建自己的日常运维平台，也可以通过第三方的工具（如FIT2CLOUD提供的一站式运维管理和持续交付平台）更快实现运维体系和云的对接。