| 编辑推荐: |
本文主要介绍DevOps&AIOps（智能运维）解决运维痛点，IT运维具有多种商业模式，企业如何选择适合的运维模式，希望对您的学习有所帮助。
本文来自于CSDN,由火龙果软件Alice编辑推荐。 |
|
当前，云计算、大数据、人工智能等IT技术迅猛发展，国家信息化建设逐渐深入，信息系统已成为企业核心竞争力的重要部分。因此，IT运维作为信息系统稳定、安全、高效运行的保障，获得了越来越多的关注。随着微服务、容器等新型IT技术实践逐渐成熟，以及业务需求的快速变化，IT运维也在不断探索着新模式、新实践。
一、IT运维中存在的痛点
在日常IT运维工作中存在着大量重复的工作任务，这些任务有的复杂繁琐数量大，有的严重依赖执行次序，有的需要等待各种条件具备之后方可执行。尽管IT运维管理技术在不断进步，但实际上IT运维人员并未真正解放，目前许多企业的系统开启和关闭、系统更新升级、应急操作等绝大多数工作都是手工操作的。即便简单的系统变更或软件复制粘贴式的升级更新，往往都需要运维人员逐一登录每台设备进行手工变更。尤其是在云平台、大数据和海量设备的情况下，工作量之大可想而知。而这样的变更和检查操作在IT运维中往往每天都在发生，占用了大量的运维资源。通过自动化的作业工具，将运维人员从简单重复的工作中解放出来，减少误操作风险，带来了系统的稳定、安全与效率提升。IT运维需要进一步提升效率要实现：
（1）日常巡检自动化：
日常巡检工作内容简单却占用了IT运维人员的大量时间。日常巡检自动化可以将硬件状态，设备负载，系统时间，磁盘空间，线路流量，数据库表空间使用率、网络设备的端口状态、流量等进行自动巡检，并形成符合用户要求的巡检报告。
（2）配置管理自动化：
自动从生产环境中提取配置库信息，自动更新到配置库中，保持配置库和生产环境的一致性。要实现对配置库的自动更新和同步，需要对应用系统进行标准化改造，比如规范化的安装路径、统一版本等，这将有助于工具能提取到应用程序配置项的基本信息，最终实现配置项和属性的自动更新。
（3）应用部署自动化：
使用自动化平台图形化流程编辑器创建组件流程。根据平台提供的插件，实现和流行工具的集成，不需要任何编程就能快速定义部署逻辑。可以使用相同的流程，将相同的应用程序部署到多个环境。这进一步帮助节约时间并提高效率，并对应用程序和部署流程进行尽早验证。自动化平台的分布式代理模型可以在数千台机器上同时运行部署流程。
（4）容灾切换操作自动化：
以容灾作业流程的方式实现容灾切换流程批量自动执行。通过双活数据中心为业务系统建立双活模式，实现自动化切换，尽可能减少宕机时间。
（5）故障预测智能化：
主动容错技术，能够基于对系统历史状态以及当前行为的分析，生成告警预测的结果模型，判断系统是否即将产生故障，协助系统规避故障或尽早采取故障恢复措施。同时，告警信息经过智能关联分析模块的训练，能够发现告警之间的关联关系以及故障的发生概率，对告警进行预测。故障预测可以使运维人员在日常工作中变被动响应为主动，提升系统的整体运行质量。
（6）故障自愈：
故障自愈流程包括感知、止损决策、止损三个阶段。其中感知阶段依赖监控系统的故障发现能力，止损阶段依赖流量调度系统的调度能力。故障自愈可提升企业的服务可用性和降低故障处理的人力投入，实现故障从人工处理到无人值守的变革。
（7）自动扩缩容：
可以根据应用的负载情况自动调整集群容量以满足需求。当集群中出现由于资源不足而无法调度的Pod时自动触发扩容，从而减少人力成本。当满足节点空闲等缩容条件是自动触发缩容，节约资源成本。
（8）智能问答知识库：
是知识库的最新形态，具有知识挖掘、知识管理、知识关联、知识推理与建模、智能检索、自主学习和训练等功能。智能知识库改变了故障处理模式，既提高了故障上报的准确性，又简化了信息交互的中间环节，有效降低故障处理时间，提升工作效率。
（9）智能发布变更：
能够管理海量规模的发布变更过程，具备自动化部署、分级发布和智能变更策略等功能。用户通过UI/API配置整个变更过程的执行策略，由专门的执行系统解析策略并自动执行批量及其的变更。分级发布将变更过程以实力组为单位划分成多个阶段，每个阶段引入自动化的检查用例，只有检查通过才能执行下个阶段的变更，有效增强对变更过程的管控，降低异常影响，加快异常恢复速度。
除此之外，通过引入智能模板生成、智能变更检查等智能策略，降低使用门槛，提升复用性，降低人为操作的失误率。
二、DevOps&AIOps（智能运维）解决运维痛点
越多的企业正在经历从手工运维，流程化、标准化运维向自动化运维、DevOps甚至AIOps转型的过程。据中国信通院2019年调查显示，DevOps已经在我国逐步落地实践，46.65%的企业已经通过DevOps在一些方面取得了局部收获。新型信息通信技术的快速突破与深入应用，使得IT运维也产生着日新月异的变化。企业对自身IT运维能力所处的发展阶段不清晰，缺少体现现代IT运维能力的标准，以帮助企业明确自身所处发展阶段，明确发展目标。目前，国内外流程化、标准化运维已存在ISO20000、ITIL等最佳实践及相关标准，但自动化运维、DevOps、AIOps等IT运维阶段的相关标准体系仍然有待完善。
1、DevOps（研发运营一体化）助力企业实现软件生命周期的全链路打通，持续运营与优化。
企业对云计算、大数据、微服务、容器化等新技术的应用逐渐深入，相关业务架构复杂度提升，产品迭代快速、频繁，IT运维进入DevOps阶段。在此阶段，通过对持续集成、自动化测试、持续交付、持续部署等多种相关技术的运用，版本发布周期大幅缩短，效能获得提升。与此同时，IT运维通过监控管理、事件管理、变更管理、配置管理、容量和成本管理、高可用管理、业务连续性管理以及体验管理等技术运营手段，实现了信息系统的质量提升与业务优化。DevOps将软件全生命周期的工具全链路打通，结合自动化、跨团队的线上协作能力，实现了快速响应、高质量交付以及持续反馈。
2、AIOps（智能运维）阶段尝试将AI技术及海量数据应用于运维场景。
随着业务的快速变化、海量数据积累以及AI技术在IT运维中的应用，IT运维将会进入智能运维（AIOps）阶段。由于AIOps实际应用及落地时间还很短，目前主要处于在运维数据集中化的基础上，通过机器学习算法实现数据分析和挖掘的工作。主要应用场景包括：异常告警、告警收敛、故障分析、趋势预测和故障画像等。IT运维正在探索AIOps更多的应用场景，并将建设多场景串联的流程化免干预运维能力。未来AI中枢将为企业运营和运维工作在成本、质量、效率等方面的调整提供重要支撑。
三、当前都有哪些运维模式？
当前各行业、企业规模以及企业决策差异，IT运维具有多种商业模式，主要有如下四种。
（1）免运维模式，高度成熟的商业产品往往具备免运维的特点。例如：除了具备高度的可配置化能力以外，还需具备守护进程实现自监控、日志回收、常见故障处理以及自我优化功能。所以，当企业购买、安装部署以及联调后，基本不需要提供后续运行维护支持。
（2）外包运维模式，是指IT系统由IT运维服务提供商提供日常监控、运行维护、升级等保障服务。在单体应用、私有云以及公有云等不同建设场景下，分为IT运维服务外包和购买云服务两种模式。在单体应用、私有云建设模式下，企业通常采用运维服务外包的模式，大多采取驻场服务，部分企业会采取定期或者按需到场、远程运维；对于使用公有云服务、部署在公有云的场景，则通常选择购买云服务来解决一站式运维保障。中型以下规模、安全等级不高或受限于行业特性的企事业单位，往往会采取IT运维外包模式。
（3）自有团队运维模式，是指IT系统由内部人员来完成日常监控、运行维护、升级等保障服务。互联网企业、大中型传统企业或者安全等级较高的企事业单位，即使采购了第三方的运维工具，也要求组建企业自有的运维团队。在这种模式下，随着运维经验、运维团队以及能力建设的提升，通常会持续开发出适配企业自身情况的运维工具。有的企业会将运维前置到需求评审环节，实现开发运维一体化。例如：对于运营商等超大规模企业，甚至会考虑跨域的能力规划、平台建设和能力建设，提高IT运维的自主、可控、高效以及集约化运维。
（4）混合运维模式。是指企业和IT运维服务提供商都参与到IT上线前后的运维工作中。通常情况下，服务提供商是系统集成商或软件原厂商；当项目完成交付时，他们与企业共同提供运维服务。企业主要任务是运维管理，而IT运维服务提供商的主要任务是运维执行，两者共同目标是提供可持续的运维服务和
四、企业如何选择适合的运维模式？
针对不同企业选择适合你们企业的运维模式，需要认真评估你的软件的交付机制以及运维团队左移和右移的程度是你选择采用何种
DevOps 分合策略，以及 DevOps 实践是否成功的关键因素。DevOps 的分与合，与运维工作的左移右移，云技术的发展，云原生标准的统一有极大关系，DevOps
概念可以在很多层面上得到体现。
合理利用开源工具实现IT运维降本增效成为挑战 近年来，开源项目由于其开放性、易管理、低成本等优势逐渐被企业所认可并应用。然而，企业在通过开源工具实现IT运维降本增效的道路上也面临多方挑战。一方面，由于开源软件更注重功能，对安全方面的管理较为放松，企业面对关键性或安全性要求较高的操作时依然无法使用开源产品。同时为了使其依赖库被信任，企业通常需要自建白名单来控制第三方包的引入，大大降低了业务更新速率。另一方面，相比闭源软件，企业在使用开源软件的过程中更多需要自主完成实施、管理和技术支持工作，对企业的自身能力做出了更高要求。
1、从人员管理层面看 DevOps
要想实践 DevOps 的分与合，必须要配置上合适的团队配置。这里有若干种配置的分类：
第一种模式属于 Dev 和 Ops 分的比较彻底的类型，这种人员模型可以适配业务运维左移程度较少，交付流程较为标准化的场景，运维团队制定流程，流程和运维服务共享给所有开发团队。
第二种模式属于 Dev 和 Ops 合的比较彻底的类型，这种人员模型可以适配业务运维左移程度很高，基础设施运维右移程度也很高的场景，基本上实现了每个开发团队配合云就能完整实现闭环，已经没有传统意义的独立运维部门。
第三种模式属于 Dev 和 Ops 部分分开、部分合并的类型，这种人员模型可以适配业务运维左移程度较多，但基础设施运维右移程度较少的场景，适用于希望能实现开发团队闭环，又对云基础设施有信任问题，需要自建基础设施（例如私有云，或基于公有云的私有基础设施）类型的团队，这种模式跟第二种模式的唯一差异是是否有自主基础设施运维团队，在超大规模
DevOps 建设私有云的场景多见。
第四种模式属于 Dev 和 Ops 的合并已经达到极致，可以完全无运维团队工作，在使用云基础设施和合适的开发工具基础上就可以实现开发团队内完整闭环，例如全量使用
Serverless 技术，无需担心负载均衡，弹性扩缩容，监控等基础设施工作。
没有哪个模式是完美的，在实践自己的 DevOps 人员配置的时候，要想清楚自己的实际场景，当想清楚自己的人员配置的时候，要想保持高效就要考虑这些人与人之间信息如何流转顺畅。
2、从工具系统层面看 DevOps
DevOps 的协作文化目的是提升团队的效能，而自动化工具是必备的，好的工具体系应该是整合的、角色切面的、自动流转的。工具系统目标是顺畅精准的传输信息并且高效的执行机械化操作。
整合性：DevOps 的开源、商业软件有很多款，然而大多数软件系统之间都是弱整合状态，很多都是宣称支持
OAuth 或者 LDAP 用户体系就算整合了，这里面的差距还很大，例如 Jira 的项目和 GitLab
的项目，GitLab 的项目与 TestLink 的测试计划，这些实际的概念在不同的系统之间都遵从着不同的产品设计哲学，实际上弱整合的工具系统在提升团队信息流转效率上并没有太大帮助。
角色切面：好的 DevOps 工具系统应该像是一个为工厂量身定制的生产流水线，各个角色各司其职，关注精准的信息，执行标准的操作，输出标准的结果。在弱整合的工具系统里可能不同系统的用户、角色、权限设计都有很大差异，难以实现角色切面。例如一套基于
Jira + GitLab + Jenkins + Kubernetes 的体系，运维角色应该加入
Jira 的项目中么？产品经理是否需要关注 Jenkins 的 Job 执行状态？
自动流转：自动流转是为了解决重复性的机械劳动而设计的，要想具备自动流转的特性，整合性和角色切面也必须设计的非常好，开发完毕到提测自动部署，测试通过到自动发布，在设计好流程和标准后都是一些机械化的重复劳动。
工具系统不是万能的，有时候你会发现有了好的人员结构、信息流转方式、整合性的工具系统，实践起
DevOps 还是有一定困难，那你可以看看技术架构。
从技术架构层面看 DevOps
技术架构对 DevOps 的影响主要体现在构建、部署、运维环节。不同的软件类型，技术架构在这三方面是有很大差异的。例如单机手游，只有构建和发布市场，基本不存在部署、运维环节。而微服务架构
SaaS 化的多租户云服务在这方面就复杂的多。
这里以典型的服务器端应用的技术架构升级过程来作简要分析，例如对于一个基于
Spring 框架写成的 Java Web 应用，其发展历程可能是这样的：
单体 Tomcat：构建一般使用 IDE 配合 Maven/Gradle，少许团队会使用
Jenkins 之类的进行自动化构建 war 包，部署往往选择 scp/sftp 形式进行发布，停机部署，需要运维人员专门人工操作，容易出现错误
多实例 Tomcat + Nginx 负载均衡 + 动静分离：构建开始变的复杂，前端的
js css 等需要进行独立的压缩和上传，部署过程有很多运维团队开始选用 Ansible 之类的便于管理
Nginx 的复杂配置文件和多实例并行发布，Ansible 等工具为自动化的发布提供了诸多便利，但仍然要求运维人员去撰写难以维护的
playbook 和服务器的基础软件环境
前后端分离 + 容器化：当以 Docker 为代表的容器技术开始流行的时候，团队开始尝试构建的结果不再局限到
war 包层面，可以把前端和后端分别构建出 Docker 镜像，以 Docker 镜像作为标准交付，但服务的配置信息、扩缩容能力，健康检查等问题仍然困扰着运维团队
微服务化架构 + 容积集群部署：以 Kubernetes，Istio
Service Mesh等为代表的容器集群编排和微服务技术开始逐步进入大家的视野，部分团队开始尝试让开发团队自主通过
Kubernetes 工作负载 Yaml 文件、ConfigMap 等形式管理配置信息，使用 Service
配合微服务的流量控制体系进行灰度控制、服务降级、熔断处理、标准化健康检查监控等。
Serverless 无服务器架构：以 Serverless Framework、AWS
Lambda、Knative 等为代表的新一代无服务器架构的服务器端应用已经帮助一些技术领先的团队实现了进一步的去运维化，后端开发只需要按照云函数的定义要求进行少量的声明或者配置，即可实现全套的
CI/CD、负载均衡、弹性伸缩、生产级别高可用等能力。
云的发展也映射着技术架构的变迁，也引领着基础设施运维的右移，大致分为三个阶段：
VM/虚拟机 实现了去硬件化 Hardwareless
Container/容器 实现了去操作系统化 OSless
云函数/Serverless 实现了去服务化 Serverless
每一种技术架构的 DevOps 的实践模式是有差异的，分与合的程度也不一样。仔细品味这些技术架构的特点，认真评估自身团队业务运维左移和右移的程度，就可以选择出合适的人员管理模式、选择适合自己的工具系统，形成顺畅、精准的信息流转，从而让
DevOps 的实践取得实质性成果。
五、成功实现DevOps持续部署需要你的团队能力
持续部署是软件交付的一种形式，常用于服务器端软件的交付，在这里我们以
CODING CD + Kubernetes 来简要讲述一个服务器软件持续部署模式，我们需要我们运维团队具备如下能力：
1、业务运维部分左移：
常规发布、配置管理等基础业务运维左移到开发团队
2、基础设施运维部分右移：
基础计算资源由云全托管，直接使用云的 Kubernetes 集群，负载均衡器，数据库等
3、开发团队和运维团队分离：
运维团队更多的是制定业务运维规范标准和流程，在云的基础上层进行更高层次的基础设施运维，如制作业务监控体系，信息安全，日志系统等
4、整合式 DevOps 系统：
直接使用 CODING 提供的集敏捷项目管理，测试管理，代码管理，持续集成，制品库，持续部署为一体的
SaaS 服务
5、简单的微服务技术架构
未引入如 Istio 等高级微服务架构（引入微服务架构的持续部署跟此示例类似，但细节过多，不适于在此文详述），使用
Docker 镜像 + Kubernetes
你的运维团队适合哪种模式，能否成功实践DevOps？还需要结合企业的特点进行选择。
|
