IT运维大牛万字自述：道尽十多年血泪史与转型自救路
时间：2022/5/26 14:30:30浏览次数：975
运维大牛万字自述：道尽十多年血泪史与转型自救路
与一个行业大牛的朋友交流时，在听到他年轻时在大厂的一些关于将工作方法升华为方法论，比如“监、管、控”、“新网点”理念，并推动整个行业建设时为之一震。这个触动让我有了让自己的运维知识体系建设做第一次飞跃的打算，即如何将知识体系通过一个主线串起来。
关于这个主线，找过一些朋友做了交流，比如“风险可控”、“一体化”、“更高效更优化的资源配置”、“可扩展性”。由于自己主要身处一线运维团队，所以选了“可扩展性”的主线，接下来打算根据这条主线，不断完善知识体系，目标是体系化的整理知识体系，主要从组织、流程、工具的可持续整合。
以下内容，主要是对运维整体的概览，讲讲对运维的认识，以及一些转型理念思考。
一、运维不简单
前阵子，跟一个项目经理沟通能否提前半天将变更申请提交过来时，这位项目经理很不理解地问我：“你们运维不就是在生产环境部署个程序这么简单的工作吗？你们又不懂程序，评审不出什么吧？”
运维多年，对运维的这类认识听过很多，它反映了企业里不同的组织团队对运维的认识往往仅限于一些简单操作性的工作，比如生产应用系统在故障时的重启、应用变更时敲敲命令、平时增删改查数据，或者是办公室和电有关的所有软硬件的使用问题等等。
那么如何理解运维呢？百度百科对运维的解释为：企业IT部门采用相关的方法、手段、技术、制度、流程和文档等，对IT软硬运行环境（软件环境、网络环境等）、IT业务系统和IT运维人员进行的综合管理。从百度百科的解释看，运维岗位需要一个综合性的技术与管理能力，需要掌握大量的方法论与技术栈。
运维狭义“运维技术与资源”可以定义为“监、管、控”，技术与资源主要是支撑运维/运营的质量、效率、成本的平衡。以下简单摘录了运维的一些能力要求：
图1.1
图1.2
讲到这，肯定会有人说上述的技术栈的能力要求，通常是由于某个运维组织的仍处于专家式运维，自动化程度不够高导致。
的确，理论上所有运维操作性、命令的工作都可以整合为经验，并通过自动化落地实现，现在互联网企业对外都宣称自动化在运维工作覆盖面很高，己经开始迈向智能化，AIOps，甚至提出了NoOps的解决方案。
关于这些互联网企业的自动化对日常运维工作真实的覆盖面暂时无法考究，但以我的经验看，至少金融企业的自动化覆盖面还有很长的路要走，且肯定还会很大一部分工作很难自动化，毕竟工作类型太多，在有限的投入上只能集中力气去做投入产出比更高的运维自动化。这里再以一个运维工具思维导图（图1.3）简单列示一些常规的运维操作，可以看出其实很难有一套能解决所有运维操作的工具平台。
图1.3
所以我觉得，随着业务要求越来越高、规模越来越大、监管要求越来越高，纵使外部如何宣称自动化、智能化对运维人员经验、技术、管理能力替代，金融企业内的运维还需要认清实际情况，结合企业的整体战略定位，强调运维团队在运维管理与技术能力的广度与深度，再有侧重、有先后的实现自动化水平。
在未来一段时间里，金融企业的运维岗位仍是一个复杂的、综合性技能的工作岗位。
二、运维之痛
近年来，随着运维技术的快速发展，各行业的运维水平在得到了较大的提升同时，运维圈的分享也越来越开放，从国外Google的SRE理念，到国内新技术领跑者以及借助于各种运维专题的公众号、运维大会有大量的互联网、传统企业的运维组织进行分享。
1、组织之痛
前面讲过，在企业内部其它团队对运维的认识通常是简单操作，出故障时才会找的团队，随着信息技术的发展与业务的发展，运维组织痛点越来越明显，企业内对运维组织的不满的声音越来越多，反思一下原因，分外部客观因素和内部因素。
1）外部客观因素
在当前大数据时代，金融企业的运维面临业务规模的不断扩大，业务竞争越来越激烈，监管要求越来越高，数据中心的规模也越来越高，大量新技术、开源架构的引入取代了传统稳定的系统架构等等因素影响。
2）内部因素
网上有一个调查数据，在整个运维成本的分配中，软硬件和网络设备的维护成本占 30%，维护服务成本占30%，内部运维人力成本则占了40%。这里的人力成本包括现在维护、培训、流失与引入等成本，如果将维护服务成本也纳入到人力成本之上，则人力这一块的成本将上升为70%，影响这个人力成本的因素主要有：
2、个体之痛
作为运维组织中的运维人员同样面临不少痛点，有来自工作时间、工作压力、学习压力、职业发展等等，以下简单罗列：
三、自救
1、SRE
SRE这个名词最早是从《Google SRE 运维解密》一书中获得，全称是Site Reliability Engineering，翻译过来就是：站点可靠性工程师。Google对SRE的职责描述为：确保站点的可用，为了达到这个目的，一方面他需要对站点涉及的系统、组件熟悉，也要关注生产运行时的状态。
为此，他需要自开发并维护很多工具和系统支撑系统的运行，比如自动化发布系统、监控系统、日志系统、服务器资源分配和编排等。SRE是一个综合素质很高的全能手，如果对他的能力进行分解主要有三块：
2、运维开发
关于运维开发的理解主要体现在运维工具层面，不同的组织有不同的理解，通常有三类：
总的来说，不管选用上面哪一种方式，运维开发团队都应该有一个整体、统一的一体化工具建设规划，并在建设过程中始终保持对运维工具体系的掌控能力，并在工具体系的上层为其它运维人员提供简易的、可创造性的“开发能力”，比如所见即所得的工具可视化、可定制的运维报表、拖拉拽方式的流程及脚本组件的拼装等运维开发方式。
3、DevOps
1）DevOps概述
DevOps一词的来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠，他是一种方法论，包含一套基本原则和实践，工具是为有效落实这套方法论提供支持。
在软件全生命周期管理过程中，包括开发、构建、测试、发布、运营，在这个全生命周期管理过程中出现了开发组织与运维组织的部门墙，这是因为开发组织关注需求的实现，希望尽快实现变更；运维组织关注系统运行稳定，而变更又往往是生产应用不稳定的原因。
DevOps方法论的出现主要是为了解决这个协作问题，以让软件交付更加高效，质量更高，生产端更加敏捷，生产运行过程中的问题能更加高效的反馈到开发，形成一个全生命周期的闭环。随着业务对运维交付能力的时效性要求越来越高，运维组织面临“吃力不讨好”的问题：
2）运维实践中的DevOps
可以从工具链、组织文化、自动化、敏捷看板等角度讲DevOps，比如在目前比较活跃的DevOps36计，基本覆盖了运维领域很大的一块：
图1.4
从DevOps的落地效率来看，需要将DevOps进行聚焦，聚焦到交付能力上，这方面，行业里比较标准化的评估是去年底由中国信息通信研究院，联合一些互联网企业、运维社区，以及一些金融、传统企业联合进行编制的DevOps标准（券商行业中华泰参加了编制）。从这个能力模型公布出来的一些介绍看，标准对DevOps范围比较克制主要以交付能力来分解敏捷开发、持续交付、技术运营、应用架构、组织架构，这和最早的DevOps能力环比较吻合：
图1.5
从运维的交付场景看，主要是资源交付与应用交付，其中资源交付以IaaS、PaaS云的建设为主，通过云管平台的工具链将基础设施、网络、硬件、虚拟化、容器、运行中间件等系统软硬件交付能力自动化，并通过CMDB整合DevOps能力环之上的应用场景，实现资源的快速交付。
资源交付能力主要在于IaaS、PaaS层的云平台标准化、自动化、平台扩展性等方面的建设程度。应用的快速交付比资源交付更为复杂，应用交付涉及全链路的整合，链路上的节点越多落地的难度越大，因为它不仅涉及技术，还涉及理念的认同与聚焦。
应用交付能力要实现，最简单的技术栈工具需要CMDB、应用发布工具、应用版本库、监控工具，上述工具对内要与云平台对接，对外要提供接口给开发、测试工具。当然如开发、测试也能和运维使用同一套发布工具、应用版本库则效果更好，不过，实际实施过程中组织之间还是会有不少冲突，比如开发关注源代码版本管理，测试、运维关注运行版本的管理，需各个组织共同付出共建技术链。
4、运营
关于运维圈里运营的概念，以转型口号喊得比较多，我对运维当中的运营有业务运营与技术运营两个维度的理解。业务运营是通过功能优化或工具开发等方式解决业务工作痛点，或通过运行分析发现影响业务开展的因素，并推动相关的优化，最终提升业务能力。技术运营则主要从技术角度去降低IT成本，提升IT服务质量与效率。具体的实施内容可以考虑如下：
图1.6
从上述概括可以看出，当前运维里面的运营，与运维数据密切相关，需要基于运维大数据平台来提升运营质量。
为了进一步说明运营，这里举两个例子：
1）理论
优锘科技CEO的陈傲寒在2016年写过一篇文章《IT：从运维到运营》，仍是我读过最好的一篇。全文从企业、运维组织角度出发分析什么是运维、什么是运营，再将运营分解到不同角色上的理解与落地的方向，全文均是干货，值得通读，这里只列出一个思维导图。
图1.7
2）实战
参加过一场腾讯QQ关于DevOps的培训，对于它们提到的一个自救方式的运营手段很有印象。那就是在腾讯QQ逐渐被微信团队替代过程中，QQ技术运维团队是如何通过各种方式去为企业带来效益，比如他们通过运维分析，得到如何更加合理的使用带宽、资源，大大减少了公司在基础设施方面的投入。
在金融企业中，也同样有很多空间可以去尝试，比如分析业务痛点，为业务提供快速的策略性的工具来替代重复操作性的业务操作；通过运维数据分析，发现客户体验方面的痛点，推动业务功能的优化等等。
4、AIOps
AIOps这个词最早是在2016年由Gartner提出（当然国内很多厂商也提出它们早几年也提出了这个理念）。AIOps是Algorithmic IT Operations的缩写，是基于算法的IT运维，即通过使用统计分析和机器学习的方法处理从各IT设备、业务应用、运维工具收集的数据，从而加强增强运维自动化能力，以便更快、更有效、更全面地自动化效果。以下是Gartner提出AIOps的一张图：
图1.8
Gartner通过使用图1.9中的图解释了AIOps平台的工作原理。AIOps有两个主要组件：大数据和机器学习。它需要从孤立的IT数据中移除，以便将大量数据平台内的观察数据（例如监控系统和作业日志中发现的数据）与参与数据（通常在故障单，事件和事件记录中找到）相结合。
AIO然后针对组合的IT数据实施全面的分析和机器学习（ML）策略。期望的结果是持续的见解，通过自动化产生持续的改进和修复。AIO可以被认为是核心IT功能的持续集成和部署（CI/CD）。
图1.9
6、AIOps与自动化的关系
AIOps很火，所以对AIOps和自动化做了一些对比。暂以一句话作个区别：AIOps是基于对运维数据（日志类、指标类数据等）的机器学习，进一步解决自动化成本高或无法解决的问题，属于运维自动化的优化，细化一下区别有：
虽然行业内的智能运维理念十分火热，但实际落地成效上还主要处于研究阶段。从运维工具技术解决方案的角度看，对于智能的解读也有差别，如果将智能的特点解读为具备“模拟人，具备自学习，能够从数据中获取知识，进而进行预测/决策”来判断是否智能，智能是自动化的一个辅助手段，自动化才是终态。
建立在这个认识下，我们首先需要通过自动化手段解决痛点，提高工作效率，控制风险；利用运维数字化的建设为运维智能化提供数据、数据计算的能力；在自动化、数字化水平得到一定程度后，再通过人工智能的技术去解决自动化手段解决起来费力或无法解决的局部问题，让自动化具备智能的水平。
四、体系
1、运维的可持续改进
在管理领域，戴明推出的PDCA循环可以解释运维体系需要具备的可持续改进的能力条件。
PDCA循环为四个阶段，即计划（plan）、执行（do）、检查（check）、调整（Action），即在实际工作开展过程中，把各项工作按照作出计划、计划实施、检查实施效果，然后将成功的纳入标准，并不断循环改进的过程。
将这个思路引入到企业的运维体系中则是针对企业业务发展的需求，制定运维体系的整体发展目标，通过不断改进的措施提高运维工作效率、控制风险，以达到更高效、更优化的资源配置，进而推动业务的发展。要做到运维体系的可持续改进，需要做到以业务导向，整体部局；组织、流程、工具三位一体；不断审视优化。
1）P：以业务导向、整体部局
运维的最根本作用是保障IT数据的连续性，这里的IT数据包括业务，以及反映业务的数据，或者换句话可以表达为：网络不断、系统不瘫、数据不丢。随着业务对IT系统依赖程度越来越高，运维又会承担更高的期望，也就是运维向运营的转化，这就需要从业务角度去不断完善运维，以促进业务为大目标，要明白“IT for IT”是为了更好的“IT for Business”。
有了这个目标，那我们的运维体系的构建就需要与企业业务的发展保持同步，要让运维体系具备可持续改进的能力。
另外，可持续改进的过程不应该是大拐弯的方式进行改进，而应该不断的小调整，这就需要确保首先要建立一个整体、全局的运维体系，对运维各项工作做一个整体的规划，把眼光看得更远，往往可以更好的把控当前。
2）D：组织、流程、工具的三位一体
可持续改进的运维体系需要让运维的组织、流程、工具三位一体的作用，比方说：提高工作效率，需要组织的专业化分工、流程的标准化、工具的自动化配合作用；推动业务的发展，既需精细化运维分析、业务服务、运营等维度的工作资源投入，也需要有工具的建设来减少操作性的工作来释放人力，需要工具提供更高效的数据来源。
这里说的组织主要是从运维人力资源的分工、团队建设、工作目标导向、运维KPI等；流程是指以成熟的运维方法论为主体，结合企业和外部监管的规章制度、企业业务发展需要，而落地的标准化工作方法；工具既包括狭义运维的“监、管、控”，也包括运营体系所需要数字化、智能化的工具平台。
3）C+A : 不断审视优化
在实际工作过程中，审视检查的过程很容易被忽略，但实际上最大的收获可能就来自于这个总结、归纳的过程中，这也是可持续改进的运维体系的关键所在。
比方说，运维组织可以考虑在必要环节增加横向的优化团队；运维流程也需要定期对流程的落地进行分析，并对规章制度进行查漏补缺、删减不合理的流程规范、调整无法执行的规范要求；工具的建设要不断的分析工具的使用覆盖率，如何提高覆盖率，分析是否提高了运维的效率，还是带来了反作用等分析，并不断调整优化工具的建设。
2、转型思路
在提出可持续的运维体系前，我们先归纳一下运维组织常见的运维痛点，以提出运维转型的思路，再看看如何构建一个可持续改进的运维体系来支撑运维转型。前面的运维之痛中提到了 “救火”、“背锅”、“低价值”、”重复操作“等标签，我们归纳下己有特点再看转型：
1）特点
图1.10
3、构建运维体系
上二节提到运维体系以业务导向，整体部局，组织、流程、工具三位一体，不断审视优化的建设思路，也提出了“主动精细化”、“价值驱动”、“运维开发”、“智能化运维”的转型目标，我们再将这些思路分解到组织、流程、工具的建设中，并归纳为：三大建设，十个文化的实践方法：
1）组织建设：专业化、精细化、运营化
我们将运维实施主体运维组织理解为组织，理想情况下，优秀的组织应该具备有合适的工作、合适的时间、合适的人、合适的行为四个要素组成。即组织要结合企业实际发展方向，制定符合企业、运维组织、个人发展的工作内容，并选择具备合适的知识、技能、认知、能力的人去完成工作，去实现个人的自我价值。
前面也提到，目前的运维织是一个被动保障业务系统运行，日常计划性工作容易被打断、搁置的工作，这种工作状态下的运维组织往往工作效率不高、容易出现操作风险。
为了让运维组织具备可持续改进的能力，需要提高运维组织的工作效率，我们需要将运维工作专业化，整合通用性、操作性的工作，提高工作效率，在释放运维人员工作量后，引导运维人员有计划、可量化的去做更多分析类、优化类、业务运营的主动性工作。
2）流程建设：标准化、可视化、可量化
大部分运维组织会以内部企业积累的规章制度、外部监管机构的监管要求为基础，依照ITIL、ISO20000、ITSS.1、DevOps的方法论中的一个或多个组合的方式开展运维工作。这些规章制度、监管要求、方法论的整合、落地、持续改进的过程即为流程建设的过程。
流程建设首先需要标准化流程，要先梳理好己有的流程制度，约定工作的流转方式，再通过可视化将流程整合在日常工作中，最后通过流程落地数据的分析与工具建设，持续改善提高流程落地的效率，控制操作风险。
3）工具建设：自动化、数字化、智能化、服务化
工具的建设也以可持续改进的思路构建，以整合存量资源、引入成熟或开源技术为主，建立一体化的运维工具体系。
通过体系化的思路实现运维工具（“监、管、控”）的互联互通，有序建设，实现自动化运维，全面控制风险、提高工作效率、释放人力；通过建立运维数据分析平台，实现数字化运营，提供运维数据集中与治理、主动分析的能力；在数字化运营的基础上通过运维数据挖掘、学习，优化运维或运营场景，向智能化发展；服务化则是以IT服务的方式将运维能力向外输出。
与一个行业大牛的朋友交流时，在听到他年轻时在大厂的一些关于将工作方法升华为方法论，比如“监、管、控”、“新网点”理念，并推动整个行业建设时为之一震。这个触动让我有了让自己的运维知识体系建设做第一次飞跃的打算，即如何将知识体系通过一个主线串起来。
关于这个主线，找过一些朋友做了交流，比如“风险可控”、“一体化”、“更高效更优化的资源配置”、“可扩展性”。由于自己主要身处一线运维团队，所以选了“可扩展性”的主线，接下来打算根据这条主线，不断完善知识体系，目标是体系化的整理知识体系，主要从组织、流程、工具的可持续整合。
以下内容，主要是对运维整体的概览，讲讲对运维的认识，以及一些转型理念思考。
一、运维不简单
前阵子，跟一个项目经理沟通能否提前半天将变更申请提交过来时，这位项目经理很不理解地问我：“你们运维不就是在生产环境部署个程序这么简单的工作吗？你们又不懂程序，评审不出什么吧？”
运维多年，对运维的这类认识听过很多，它反映了企业里不同的组织团队对运维的认识往往仅限于一些简单操作性的工作，比如生产应用系统在故障时的重启、应用变更时敲敲命令、平时增删改查数据，或者是办公室和电有关的所有软硬件的使用问题等等。
那么如何理解运维呢？百度百科对运维的解释为：企业IT部门采用相关的方法、手段、技术、制度、流程和文档等，对IT软硬运行环境（软件环境、网络环境等）、IT业务系统和IT运维人员进行的综合管理。从百度百科的解释看，运维岗位需要一个综合性的技术与管理能力，需要掌握大量的方法论与技术栈。
运维狭义“运维技术与资源”可以定义为“监、管、控”，技术与资源主要是支撑运维/运营的质量、效率、成本的平衡。以下简单摘录了运维的一些能力要求：
- 运维规范的落地：以ITIL、ISO20000、ITSS.1等方法论，结合外部监管及内部规范的落地；
- 监管机构的要求落地：理解、快速响应、落地监管机构的管理要求；
- 基本保障：配置、监控、应用发布、资源扩容、事件、问题等；
- 基础能力：网络、服务器、操作系统、数据库、中间件、JVM、应用等基本使用与调优；
- 业务服务能力：SLA，服务台、业务咨询、维护、经验库、等支持能力；
- 可用性管理能力：巡检、业务系统连续性、可用性，基础架构及应用系统的高可用、备件冗余资源；
- 风险、安全管理能力：操作、审计、监管风险，漏洞、攻击管控；
- 故障管理能力：事件、问题管理水平与能力；
- 持续交付能力：应用变更、基础资源、办公服务交付能力；
- 主动优化能力：架构优化、性能响应效率、客户体验等；
- 应急演练：架构高可用、突发事件、业务故障的架构、方案、文档、人员熟练程度等；
- 业务支撑：数据维护、数据提取、参数维护等；
- 运行分析能力：容量、性能、可用性分析等；
- 运营能力：促进业务痛点的发现与解决、客户及业务业务体验等；
- 成本控制：更好地评估人力、硬件、带宽、软件，节省成本；
- 运维开发：运维自动化工具的建设，运维开发能力的培养；
- 其它
图1.1
图1.2
讲到这，肯定会有人说上述的技术栈的能力要求，通常是由于某个运维组织的仍处于专家式运维，自动化程度不够高导致。
的确，理论上所有运维操作性、命令的工作都可以整合为经验，并通过自动化落地实现，现在互联网企业对外都宣称自动化在运维工作覆盖面很高，己经开始迈向智能化，AIOps，甚至提出了NoOps的解决方案。
关于这些互联网企业的自动化对日常运维工作真实的覆盖面暂时无法考究，但以我的经验看，至少金融企业的自动化覆盖面还有很长的路要走，且肯定还会很大一部分工作很难自动化，毕竟工作类型太多，在有限的投入上只能集中力气去做投入产出比更高的运维自动化。这里再以一个运维工具思维导图（图1.3）简单列示一些常规的运维操作，可以看出其实很难有一套能解决所有运维操作的工具平台。
图1.3
所以我觉得，随着业务要求越来越高、规模越来越大、监管要求越来越高，纵使外部如何宣称自动化、智能化对运维人员经验、技术、管理能力替代，金融企业内的运维还需要认清实际情况，结合企业的整体战略定位，强调运维团队在运维管理与技术能力的广度与深度，再有侧重、有先后的实现自动化水平。
在未来一段时间里，金融企业的运维岗位仍是一个复杂的、综合性技能的工作岗位。
二、运维之痛
近年来，随着运维技术的快速发展，各行业的运维水平在得到了较大的提升同时，运维圈的分享也越来越开放，从国外Google的SRE理念，到国内新技术领跑者以及借助于各种运维专题的公众号、运维大会有大量的互联网、传统企业的运维组织进行分享。
1、组织之痛
前面讲过，在企业内部其它团队对运维的认识通常是简单操作，出故障时才会找的团队，随着信息技术的发展与业务的发展，运维组织痛点越来越明显，企业内对运维组织的不满的声音越来越多，反思一下原因，分外部客观因素和内部因素。
1）外部客观因素
在当前大数据时代，金融企业的运维面临业务规模的不断扩大，业务竞争越来越激烈，监管要求越来越高，数据中心的规模也越来越高，大量新技术、开源架构的引入取代了传统稳定的系统架构等等因素影响。
- 运维组织的角色
- 业务对运维服务质量的要求
- 外部监管要求
- 业务并发要求
- 数据中心规模增大
2）内部因素
网上有一个调查数据，在整个运维成本的分配中，软硬件和网络设备的维护成本占 30%，维护服务成本占30%，内部运维人力成本则占了40%。这里的人力成本包括现在维护、培训、流失与引入等成本，如果将维护服务成本也纳入到人力成本之上，则人力这一块的成本将上升为70%，影响这个人力成本的因素主要有：
- 运维能力模型
- 运维规范化
- 运维精细化程度
- 运维目标
- 自动化能力
2、个体之痛
作为运维组织中的运维人员同样面临不少痛点，有来自工作时间、工作压力、学习压力、职业发展等等，以下简单罗列：
- 7*24小时制的工作时间
- 高度压力的工作
- 被动的工作
- 对工作的认识
- 职业压力
三、自救
1、SRE
SRE这个名词最早是从《Google SRE 运维解密》一书中获得，全称是Site Reliability Engineering，翻译过来就是：站点可靠性工程师。Google对SRE的职责描述为：确保站点的可用，为了达到这个目的，一方面他需要对站点涉及的系统、组件熟悉，也要关注生产运行时的状态。
为此，他需要自开发并维护很多工具和系统支撑系统的运行，比如自动化发布系统、监控系统、日志系统、服务器资源分配和编排等。SRE是一个综合素质很高的全能手，如果对他的能力进行分解主要有三块：
- 熟悉系统架构与运行状态
- 熟悉运维涉及的管理方法
- 运维开发+产品经理
2、运维开发
关于运维开发的理解主要体现在运维工具层面，不同的组织有不同的理解，通常有三类：
- 完全自建
- 外购开发资源或工具产品
- 外购与自建相结合
总的来说，不管选用上面哪一种方式，运维开发团队都应该有一个整体、统一的一体化工具建设规划，并在建设过程中始终保持对运维工具体系的掌控能力，并在工具体系的上层为其它运维人员提供简易的、可创造性的“开发能力”，比如所见即所得的工具可视化、可定制的运维报表、拖拉拽方式的流程及脚本组件的拼装等运维开发方式。
3、DevOps
1）DevOps概述
DevOps一词的来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠，他是一种方法论，包含一套基本原则和实践，工具是为有效落实这套方法论提供支持。
在软件全生命周期管理过程中，包括开发、构建、测试、发布、运营，在这个全生命周期管理过程中出现了开发组织与运维组织的部门墙，这是因为开发组织关注需求的实现，希望尽快实现变更；运维组织关注系统运行稳定，而变更又往往是生产应用不稳定的原因。
DevOps方法论的出现主要是为了解决这个协作问题，以让软件交付更加高效，质量更高，生产端更加敏捷，生产运行过程中的问题能更加高效的反馈到开发，形成一个全生命周期的闭环。随着业务对运维交付能力的时效性要求越来越高，运维组织面临“吃力不讨好”的问题：
- 吃力： 花费大量时间在应用部署的操作性工作中。这部分部署变更包括新功能的上线以及修复功能BUG两方法。
- 不讨好： 操作性的工作越大，带来的操作风险越大，有这样一个统计，如果手工运行5条命令的情况下，成功部署的概率就已跌至86%；如需手工运行55条命令，成功部署的概率将跌至22%；如需手工运行100条命令，成功部署的概率将趋近于0（仅2%）。
2）运维实践中的DevOps
可以从工具链、组织文化、自动化、敏捷看板等角度讲DevOps，比如在目前比较活跃的DevOps36计，基本覆盖了运维领域很大的一块：
图1.4
从DevOps的落地效率来看，需要将DevOps进行聚焦，聚焦到交付能力上，这方面，行业里比较标准化的评估是去年底由中国信息通信研究院，联合一些互联网企业、运维社区，以及一些金融、传统企业联合进行编制的DevOps标准（券商行业中华泰参加了编制）。从这个能力模型公布出来的一些介绍看，标准对DevOps范围比较克制主要以交付能力来分解敏捷开发、持续交付、技术运营、应用架构、组织架构，这和最早的DevOps能力环比较吻合：
图1.5
从运维的交付场景看，主要是资源交付与应用交付，其中资源交付以IaaS、PaaS云的建设为主，通过云管平台的工具链将基础设施、网络、硬件、虚拟化、容器、运行中间件等系统软硬件交付能力自动化，并通过CMDB整合DevOps能力环之上的应用场景，实现资源的快速交付。
资源交付能力主要在于IaaS、PaaS层的云平台标准化、自动化、平台扩展性等方面的建设程度。应用的快速交付比资源交付更为复杂，应用交付涉及全链路的整合，链路上的节点越多落地的难度越大，因为它不仅涉及技术，还涉及理念的认同与聚焦。
应用交付能力要实现，最简单的技术栈工具需要CMDB、应用发布工具、应用版本库、监控工具，上述工具对内要与云平台对接，对外要提供接口给开发、测试工具。当然如开发、测试也能和运维使用同一套发布工具、应用版本库则效果更好，不过，实际实施过程中组织之间还是会有不少冲突，比如开发关注源代码版本管理，测试、运维关注运行版本的管理，需各个组织共同付出共建技术链。
4、运营
关于运维圈里运营的概念，以转型口号喊得比较多，我对运维当中的运营有业务运营与技术运营两个维度的理解。业务运营是通过功能优化或工具开发等方式解决业务工作痛点，或通过运行分析发现影响业务开展的因素，并推动相关的优化，最终提升业务能力。技术运营则主要从技术角度去降低IT成本，提升IT服务质量与效率。具体的实施内容可以考虑如下：
图1.6
从上述概括可以看出，当前运维里面的运营，与运维数据密切相关，需要基于运维大数据平台来提升运营质量。
为了进一步说明运营，这里举两个例子：
1）理论
优锘科技CEO的陈傲寒在2016年写过一篇文章《IT：从运维到运营》，仍是我读过最好的一篇。全文从企业、运维组织角度出发分析什么是运维、什么是运营，再将运营分解到不同角色上的理解与落地的方向，全文均是干货，值得通读，这里只列出一个思维导图。
图1.7
2）实战
参加过一场腾讯QQ关于DevOps的培训，对于它们提到的一个自救方式的运营手段很有印象。那就是在腾讯QQ逐渐被微信团队替代过程中，QQ技术运维团队是如何通过各种方式去为企业带来效益，比如他们通过运维分析，得到如何更加合理的使用带宽、资源，大大减少了公司在基础设施方面的投入。
在金融企业中，也同样有很多空间可以去尝试，比如分析业务痛点，为业务提供快速的策略性的工具来替代重复操作性的业务操作；通过运维数据分析，发现客户体验方面的痛点，推动业务功能的优化等等。
4、AIOps
AIOps这个词最早是在2016年由Gartner提出（当然国内很多厂商也提出它们早几年也提出了这个理念）。AIOps是Algorithmic IT Operations的缩写，是基于算法的IT运维，即通过使用统计分析和机器学习的方法处理从各IT设备、业务应用、运维工具收集的数据，从而加强增强运维自动化能力，以便更快、更有效、更全面地自动化效果。以下是Gartner提出AIOps的一张图：
图1.8
Gartner通过使用图1.9中的图解释了AIOps平台的工作原理。AIOps有两个主要组件：大数据和机器学习。它需要从孤立的IT数据中移除，以便将大量数据平台内的观察数据（例如监控系统和作业日志中发现的数据）与参与数据（通常在故障单，事件和事件记录中找到）相结合。
AIO然后针对组合的IT数据实施全面的分析和机器学习（ML）策略。期望的结果是持续的见解，通过自动化产生持续的改进和修复。AIO可以被认为是核心IT功能的持续集成和部署（CI/CD）。
- 广泛和多样化的IT数据源，如日志类的设备日志、系统日志，应用日志、运维操作日志；指标类的监控性能指标、事件。
- 具备针对海量数据处理与分析的运算平台，能够从现有的IT数据生成新的数据和元数据、计算和分析还消除噪音，识别模式或趋势，隔离可能的原因，揭示潜在问题，并实现其他IT特定目标。
- 算法 ，充分利用IT领域的专业知识，更适当，高效地处理数据。
- 机器学习 ，从根据算法分析的输出和引入系统的新数据自动更改或创建新的算法。
- 可视化 ，以易于消费的方式向IT行动提供洞察和建议，以促进理解和行动。
- 自动化 ，其使用分析和机器学习产生的结果自动创建和应用响应或改进已识别的问题。
图1.9
6、AIOps与自动化的关系
AIOps很火，所以对AIOps和自动化做了一些对比。暂以一句话作个区别：AIOps是基于对运维数据（日志类、指标类数据等）的机器学习，进一步解决自动化成本高或无法解决的问题，属于运维自动化的优化，细化一下区别有：
- 概念
- 实现思路
- 门槛高度
- 如何整合
虽然行业内的智能运维理念十分火热，但实际落地成效上还主要处于研究阶段。从运维工具技术解决方案的角度看，对于智能的解读也有差别，如果将智能的特点解读为具备“模拟人，具备自学习，能够从数据中获取知识，进而进行预测/决策”来判断是否智能，智能是自动化的一个辅助手段，自动化才是终态。
建立在这个认识下，我们首先需要通过自动化手段解决痛点，提高工作效率，控制风险；利用运维数字化的建设为运维智能化提供数据、数据计算的能力；在自动化、数字化水平得到一定程度后，再通过人工智能的技术去解决自动化手段解决起来费力或无法解决的局部问题，让自动化具备智能的水平。
四、体系
1、运维的可持续改进
在管理领域，戴明推出的PDCA循环可以解释运维体系需要具备的可持续改进的能力条件。
PDCA循环为四个阶段，即计划（plan）、执行（do）、检查（check）、调整（Action），即在实际工作开展过程中，把各项工作按照作出计划、计划实施、检查实施效果，然后将成功的纳入标准，并不断循环改进的过程。
将这个思路引入到企业的运维体系中则是针对企业业务发展的需求，制定运维体系的整体发展目标，通过不断改进的措施提高运维工作效率、控制风险，以达到更高效、更优化的资源配置，进而推动业务的发展。要做到运维体系的可持续改进，需要做到以业务导向，整体部局；组织、流程、工具三位一体；不断审视优化。
1）P：以业务导向、整体部局
运维的最根本作用是保障IT数据的连续性，这里的IT数据包括业务，以及反映业务的数据，或者换句话可以表达为：网络不断、系统不瘫、数据不丢。随着业务对IT系统依赖程度越来越高，运维又会承担更高的期望，也就是运维向运营的转化，这就需要从业务角度去不断完善运维，以促进业务为大目标，要明白“IT for IT”是为了更好的“IT for Business”。
有了这个目标，那我们的运维体系的构建就需要与企业业务的发展保持同步，要让运维体系具备可持续改进的能力。
另外，可持续改进的过程不应该是大拐弯的方式进行改进，而应该不断的小调整，这就需要确保首先要建立一个整体、全局的运维体系，对运维各项工作做一个整体的规划，把眼光看得更远，往往可以更好的把控当前。
2）D：组织、流程、工具的三位一体
可持续改进的运维体系需要让运维的组织、流程、工具三位一体的作用，比方说：提高工作效率，需要组织的专业化分工、流程的标准化、工具的自动化配合作用；推动业务的发展，既需精细化运维分析、业务服务、运营等维度的工作资源投入，也需要有工具的建设来减少操作性的工作来释放人力，需要工具提供更高效的数据来源。
这里说的组织主要是从运维人力资源的分工、团队建设、工作目标导向、运维KPI等；流程是指以成熟的运维方法论为主体，结合企业和外部监管的规章制度、企业业务发展需要，而落地的标准化工作方法；工具既包括狭义运维的“监、管、控”，也包括运营体系所需要数字化、智能化的工具平台。
3）C+A : 不断审视优化
在实际工作过程中，审视检查的过程很容易被忽略，但实际上最大的收获可能就来自于这个总结、归纳的过程中，这也是可持续改进的运维体系的关键所在。
比方说，运维组织可以考虑在必要环节增加横向的优化团队；运维流程也需要定期对流程的落地进行分析，并对规章制度进行查漏补缺、删减不合理的流程规范、调整无法执行的规范要求；工具的建设要不断的分析工具的使用覆盖率，如何提高覆盖率，分析是否提高了运维的效率，还是带来了反作用等分析，并不断调整优化工具的建设。
2、转型思路
在提出可持续的运维体系前，我们先归纳一下运维组织常见的运维痛点，以提出运维转型的思路，再看看如何构建一个可持续改进的运维体系来支撑运维转型。前面的运维之痛中提到了 “救火”、“背锅”、“低价值”、”重复操作“等标签，我们归纳下己有特点再看转型：
1）特点
- 被动救火式，以被动保障业务系统运行，日常计划性工作容易被打断、搁置；
- 问题驱动式， 以系统可用性、可靠性、业务请求等问题驱动运维工作；
- 操作运维，重复性、操作类点主要工作量的运维模式；
- 经验式运维，由人工经验驱动的运维模式，尤其是一些经验丰富的老员工的离职在短期内会对运维质量带来一定的冲击。
- 从被动救火式向主动精细化转型，专业化分工、主动分析，主动优化，驱动开发，促进DEVOPS的落地；
- 从问题驱动向价值驱动转型，以企业业务发展目标为主线，业务体验、服务满意度、促进业务更好发展；
- 从操作运维向运维开发转型，通过为运维人员提供运维开发平台，降低运维开发门槛，快速落地一些紧迫的运维工具，降低操作性、重复性的运维工作；
- 从依靠经验向智能化驱动运维转型，结合数据分析、知识库、机器学习技术促进运维智能化。
图1.103、构建运维体系
上二节提到运维体系以业务导向，整体部局，组织、流程、工具三位一体，不断审视优化的建设思路，也提出了“主动精细化”、“价值驱动”、“运维开发”、“智能化运维”的转型目标，我们再将这些思路分解到组织、流程、工具的建设中，并归纳为：三大建设，十个文化的实践方法：
1）组织建设：专业化、精细化、运营化
我们将运维实施主体运维组织理解为组织，理想情况下，优秀的组织应该具备有合适的工作、合适的时间、合适的人、合适的行为四个要素组成。即组织要结合企业实际发展方向，制定符合企业、运维组织、个人发展的工作内容，并选择具备合适的知识、技能、认知、能力的人去完成工作，去实现个人的自我价值。
前面也提到，目前的运维织是一个被动保障业务系统运行，日常计划性工作容易被打断、搁置的工作，这种工作状态下的运维组织往往工作效率不高、容易出现操作风险。
为了让运维组织具备可持续改进的能力，需要提高运维组织的工作效率，我们需要将运维工作专业化，整合通用性、操作性的工作，提高工作效率，在释放运维人员工作量后，引导运维人员有计划、可量化的去做更多分析类、优化类、业务运营的主动性工作。
2）流程建设：标准化、可视化、可量化
大部分运维组织会以内部企业积累的规章制度、外部监管机构的监管要求为基础，依照ITIL、ISO20000、ITSS.1、DevOps的方法论中的一个或多个组合的方式开展运维工作。这些规章制度、监管要求、方法论的整合、落地、持续改进的过程即为流程建设的过程。
流程建设首先需要标准化流程，要先梳理好己有的流程制度，约定工作的流转方式，再通过可视化将流程整合在日常工作中，最后通过流程落地数据的分析与工具建设，持续改善提高流程落地的效率，控制操作风险。
3）工具建设：自动化、数字化、智能化、服务化
工具的建设也以可持续改进的思路构建，以整合存量资源、引入成熟或开源技术为主，建立一体化的运维工具体系。
通过体系化的思路实现运维工具（“监、管、控”）的互联互通，有序建设，实现自动化运维，全面控制风险、提高工作效率、释放人力；通过建立运维数据分析平台，实现数字化运营，提供运维数据集中与治理、主动分析的能力；在数字化运营的基础上通过运维数据挖掘、学习，优化运维或运营场景，向智能化发展；服务化则是以IT服务的方式将运维能力向外输出。
- IT服务外包
- IT采购
- 弱电工程
- 系统集成
- 网络安全
咨询电话：
021-51697581
扫一扫，关注官方微信实时掌握逾仕最新动态
Copyright 2005-2025 逾仕科技（IT服务外包/系统集成）, All Rights Reserved 备案／许可证号：
沪ICP备09088264号-6