标签：描述 消息队列 组件 云平台 普通用户 理解 运营 集成 感知
随着公有云（尤其是公有云IaaS）的普及，整个云上运维和传统IDC中的运维还是呈现出比较明显的不同点，我们可以从下面几个角度来理解这种不同点。
一般来说，很多企业的运维部门主要工作包括基础运维（针对企业IT基础设施的运维）、应用运维（针对企业具体业务的运维），较大的运维部门可能还有单独的运维开发，负责为公司运维部门开发运维工具和平台。当用户决定上云（尤其是IaaS公有云），就表示用户已经把基础运维以及相关的工具平台开发工作交付给云供应商，而把应用运维作为整个运维部门的核心。当然，这也符合云计算希望让用户只关注自身业务发展的初衷。如果从宏观上看，这种变迁可以用下图描述：
上图：可以看出，云上用户第一个需要做的改变是把整个运维重心转移到应用运维上。当然，在企业上云过程中不可能一次性完成如上的切换，必然会有一个很长的时间段内有传统IT和云上IT共同存在，共同运维的要求。而且为避免被一家云供应商锁定，企业非常有可能同时采购多家云供应商的服务。所有这一切都需要企业运维部门拥有统一管理不同来源，不同模式的基础设施能力。而且由于不同来源基础设施的自身运维管理能力不同（如公有云IaaS提供的基础设施就比传统IDC的基础设施有更好的自我运维管理能力），这就要求企业运维部门的运维平台能够补齐相应短板，磨平不同来源基础设施的不同。以便能够统一标准化、自动化日常的运维管理操作。当然，在这个过程中，企业运维部门仍然要优先关注应用运维工作，并把基础运维工作尽可能的交给IaaS供应商或者第三方工具。
在企业内部，不同业务IT系统都会用到很多公共组件（如数据库，消息队列等）。由于团队的技术背景不同，业务要求不同，经常会出现这些公共组件选型的不一致性，导致上线后的运维负担非常重。所以，企业内部运维部门的一个重要工作就是把这些公共组件标准化并最终服务化，能够对具体业务部门完全透明。这样即可以降低运维部门自身的运维成本，又可以提高业务部门的开发效率。但在云技术平台出现之前，很多企业的IT运维部门要想完成公共组件服务化的工作并不容易，所以这个想法很多时候只能在有雄厚资源和有很强运维研发能力的公司才能落地。而云计算平台（尤其是公有云IaaS平台）的出现让公共组件服务化的能力惠及所有云用户。例如AWS提供了数据库服务RDS，消息队列服务SQS等。这些服务背后的技术都是经历多年线上业务大规模验证，并且由专门团队运维。用户完全可以信任。有了这些服务化的公共组件，企业运维部门在内部推进业务部门使用标准化公共组件会容易很多。所以，在云上的IT系统选型时，企业运维部门最好能更早和业务部门合作，力争使用云上标准化服务组件，而不是把传统IT系统系统简单搬迁到云主机。如果在企业上云过程中能把握好这一点，其实就能够把上云过程和公共组件标准化和服务化的进程很好统一起来，既能降低运维成本，还能够保证服务质量，加速软件开发工作。
在云计算平台中，无论是存储服务，计算服务还是网络服务都会提供弹性伸缩，按需付费的功能。绝大多数情况下，你可以认为云供应商提供的资源是足够的，把容量管理这个工作交给云供应商。作为云上用户，只需要用时申请，结束时释放即可。对于企业运维团队来说，这一点非常重要。在传统基础设施中，获取基础设施的弹性非常不容易。为此，很多公司运维团队都会在基础设施使用上面制定很多规章制度和流程，以方便进行容量管理和规划。当管理云上基础设施时一定要注意避免这种人为削弱基础设施弹性的流程。相反，运维团队需要把云计算供应商提供的弹性能力充分暴露给业务研发团队，并鼓励业务研发团队为弹性基础设施做设计（如支持状态无关和水平扩展），甚至参与到业务架构中的设计，充分使用如AWS弹性伸缩服务（auto-scaling）等一系列弹性服务。这样一方面可以大幅度降低运维成为（如业务扩容、缩容都能够自动完成），另外也可以满足基础设施成本的弹性需求，降低整个业务的运营成本，提升在市场中的竞争力。
除了弹性，自助式服务成为云上运维非常基本的一个要求。传统IT环境中，部分大型企业可以提供自助式IT基础设施服务，但是对于大部分普通用户来说，这种服务的成本太高（无法预先提供足够的资源池），但是云的出现让这种方式得以普及，任何用户都可以在分钟级别自助获取一个完整系统架构需要的基础设施。自助式基础设施服务在整个IT系统的生产流程中非常重要，因为IT系统的开发、测试、预发和生产都涉及到基础设施。如果能够让这个获取过程完全自助式，一方面可以大幅度提高整个流程的迭代速度，另外一方面也可以减少运维人员在这些方面的时间开销。现在，任何一家企业运维部门在采纳云计算平台的时候最好都先梳理一下自助式平台的需求，在上云的同时把这种自助式基础设施推广到软件研发的每一个环节。或许你会担心自助式平台带来的IT基础设施滥用问题，这个可以通过成本核算来加以控制。运维部门也可以在云平台上层构建自己的基础设施自助平台并嵌入相应成本管控规则。注意，如果需要限制使用，更多的是限制整体成本而不是限制每一项资源的具体使用。只有这样，才能让研发团队充分享受云带来的弹性和敏捷。
无论是传统的ITIL体系还是ITOM领域，运维管理体系的基础都是CMDB（配置管理数据库）。CMDB中保存着整个IT系统的基础设施元数据，并以此为基础支持监控场景、部署场景，日常批量运维场景等等。对于传统IDC中的基础设施，由于变化并不频繁，CMDB的维护更多是通过人工来完成的。但是，在云平台上，所有的基础设施服务都会提供API接口，从而变成了可编程的基础设施。这就为CMDB中的基础设施管理完全自动化提供了前提条件。而云上服务对于弹性的强要求又导致基础设施的变化比传统IDC中频繁得多，这就要求运维管理系统自动感知基础设施变化。所以，可编程的云基础设施必须要融入你的日常运维管理体系中并使用完全自动化的方式进行管理。用户甚至可以通过感知基础设施变化的能力进一步集成自动化部署逻辑。例如，一台云主机启动起来后，运维管理体系能够感知到它的加入，能够按照预先指定的自动化部署脚本对它进行IT系统部署。在部署完成后主动加入系统的负载均衡器，开始服务用户。因为基础设施的可编程，上面整个部署流程完全可以和基础设施实施一体化自动管理。当然，如果要把可变成基础设施融入到运维管理体系中，则需要运维研发部门给自己运维平台对接各种云供应商的API，并需要相关的集成开发工作。如果企业不愿意投入资源完成这种对接，也可以选择第三方工具达到同样的目标。
在云上，运维所追求的目标未变，主要的思路也未变。但是因为云计算带来的基础设施层面变化对于运维的影响也是明确的。在这个过程中，运维需要主动出击，积极适应云带来的各种优势，并积极向上扩展（例如，更多加入cloud native应用的架构设计中，提供自助式IT服务等等），扩大自己的影响力。为适应这个转变，企业运维部门可以考虑重新构建自己的日常运维平台，也可以通过第三方的工具（如FIT2CLOUD提供的一站式运维管理和持续交付平台）更快实现运维体系和云的对接。
标签：描述 消息队列 组件 云平台 普通用户 理解 运营 集成 感知
原文地址：https://www.cnblogs.com/pourrire/p/10080875.html
