关于这个主线，找过一些朋友做了交流，比如“风险可控”、“一体化”、“更高效更优化的资源配置”、“可扩展性”。由于自己主要身处一线运维团队，所以选了“可扩展性”的主线，接下来打算根据这条主线，不断完善知识体系，目标是体系化的整理知识体系，主要从组织、流程、工具的可持续整合。

以下内容，主要是对运维整体的概览，讲讲对运维的认识，以及一些转型理念思考。

前阵子，跟一个项目经理沟通能否提前半天将变更申请提交过来时，这位项目经理很不理解地问我：“你们运维不就是在生产环境部署个程序这么简单的工作吗？你们又不懂程序，评审不出什么吧？”

运维多年，对运维的这类认识听过很多，它反映了企业里不同的组织团队对运维的认识往往仅限于一些简单操作性的工作，比如生产应用系统在故障时的重启、应用变更时敲敲命令、平时增删改查数据，或者是办公室和电有关的所有软硬件的使用问题等等。

那么如何理解运维呢？百度百科对运维的解释为：企业IT部门采用相关的方法、手段、技术、制度、流程和文档等，对IT软硬运行环境（软件环境、网络环境等）、IT业务系统和IT运维人员进行的综合管理。从百度百科的解释看，运维岗位需要一个综合性的技术与管理能力，需要掌握大量的方法论与技术栈。

运维狭义“运维技术与资源”可以定义为“监、管、控”，技术与资源主要是支撑运维/运营的质量、效率、成本的平衡。以下简单摘录了运维的一些能力要求：

不同的企业需要运维的能力会有不同的扩展，同进上述能力要求每一点扩散出来都将是一个复杂的技术栈，比如“基础能力”中的Linux操作系统的内核关系图（摘自互联网，图1.1），或再深入一些关于MySQL优化（摘自互联网，图1.2），需要运维人员对技术能力深度的要求。

图1.1

图1.2

讲到这，肯定会有人说上述的技术栈的能力要求，通常是由于某个运维组织的仍处于专家式运维，自动化程度不够高导致。

的确，理论上所有运维操作性、命令的工作都可以整合为经验，并通过自动化落地实现，现在互联网企业对外都宣称自动化在运维工作覆盖面很高，己经开始迈向智能化，AIOps，甚至提出了NoOps的解决方案。

关于这些互联网企业的自动化对日常运维工作真实的覆盖面暂时无法考究，但以我的经验看，至少金融企业的自动化覆盖面还有很长的路要走，且肯定还会很大一部分工作很难自动化，毕竟工作类型太多，在有限的投入上只能集中力气去做投入产出比更高的运维自动化。这里再以一个运维工具思维导图（图1.3）简单列示一些常规的运维操作，可以看出其实很难有一套能解决所有运维操作的工具平台。

图1.3

所以我觉得，随着业务要求越来越高、规模越来越大、监管要求越来越高，纵使外部如何宣称自动化、智能化对运维人员经验、技术、管理能力替代，金融企业内的运维还需要认清实际情况，结合企业的整体战略定位，强调运维团队在运维管理与技术能力的广度与深度，再有侧重、有先后的实现自动化水平。

在未来一段时间里，金融企业的运维岗位仍是一个复杂的、综合性技能的工作岗位。

近年来，随着运维技术的快速发展，各行业的运维水平在得到了较大的提升同时，运维圈的分享也越来越开放，从国外Google的SRE理念，到国内新技术领跑者以及借助于各种运维专题的公众号、运维大会有大量的互联网、传统企业的运维组织进行分享。

前面讲过，在企业内部其它团队对运维的认识通常是简单操作，出故障时才会找的团队，随着信息技术的发展与业务的发展，运维组织痛点越来越明显，企业内对运维组织的不满的声音越来越多，反思一下原因，分外部客观因素和内部因素。

1）外部客观因素

在当前大数据时代，金融企业的运维面临业务规模的不断扩大，业务竞争越来越激烈，监管要求越来越高，数据中心的规模也越来越高，大量新技术、开源架构的引入取代了传统稳定的系统架构等等因素影响。

越来越多的金融业务己从线下走到线上， 为了赢得更多用户的青睐，一方面，业务要求更多、体验更佳的业务性能；另一方面业务对应用发布的交付速度有了更高的要求。前者会产生更复杂的系统设计，后者需要更高效的应用发布支持，两者都会对系统响应效率、稳定性带来影响。

长期以来，为了防范金融风险，监管机构对金融企业保持强监管的方式，十九大之后，监管对金融企业的信息技术的稳定性、规范性有增无减。在强监管下，信息系统的稳定性有了进一步保证，但也给运维组织带来更高的要求，客观上也加大了工作量，并由于规范流程带来的工作效率的下降。

用户量的增加，营销活动不断推出，需要系统具备更高的并发处理能力要求，企业不断引入大量分布式、开源架构替代传统相对成熟稳定的架构来满足业务需要，这些变化都给运维能力带来挑战。

数据中心的多中心建设，云化，去IOE，分布式架构的引入使得应用系统规模成倍地增大。

2）内部因素

网上有一个调查数据，在整个运维成本的分配中，软硬件和网络设备的维护成本占 30%，维护服务成本占30%，内部运维人力成本则占了40%。这里的人力成本包括现在维护、培训、流失与引入等成本，如果将维护服务成本也纳入到人力成本之上，则人力这一块的成本将上升为70%，影响这个人力成本的因素主要有：

ITIL、ISO20000、ITSS.1是运维领域中比较成体系化的方法论（目前更为火爆的DevOps更倾向于是一种思路），其中只有ITSS.1提出了运维能力模型的概念，但在量化运维人员具体能力的实际操作上也比较难落地。也就是说你很难评价一个运维人员如何做才是做得优，如何是中，如何差，这些评价通常比较主观，这也客户观影响了运维人员不断增加技能、优化工作效率的动力。

组织扩大到一定规模，以口口相传的传授，结合个体责任心、工作习惯为主的方式容易出现操作风险，且无法进行量化绩效管理，管理规范无法落地。

组织通常是从纵向职能型的方式形成，这种方式能培养全能型、经验丰富的专家式人才，这些专家式人才利用经验能快速解决职责下的常规问题，且效率比较高，适合小型的组织。随着组织的不断壮大，面对的问题越来越复杂，技术要求越来越多，一方面很多人不能满足这种专家式人才的要求；一方面也会产生很多重复性的工作；同时对于人员流失带来的影响比较大。这时候就需要将纵向工作精细化，再辅助横向人员对工作进行持续的优化。

运维的目标往往以被动式的目标为主，被动处理故障、被动解决问题、被动提供应用交付、被动节省成本等，这种被动式的运维目标导致计划性工作不够，缺乏持续不断的自我优化，主动提高效率、质量，降低成本，并由运维向主动运营目标去转变。

IT软硬件体量庞大，且增长迅速，手工操作的机器任务太多；运维数据越来越多；故障定位越来越难，人工经验依赖高；监控手段不够及时、全面；应用发布、资源交付效率低下；没有主动的容量、性能分析、体验分析能力……这些都是常见的一些痛点。

作为运维组织中的运维人员同样面临不少痛点，有来自工作时间、工作压力、学习压力、职业发展等等，以下简单罗列：

运维人员的节假日是不完整的，通常节假日需要运维值班保障或在家通过VPN远程操作、或和家人团聚时还远程指导进行故障应急；运维人员上班时间不同普通工作，为了不影响业务，应用发布、基础设施变更、演练等工作都会放到晚上，对客的业务系统还可能要安排到深夜。这种随时可能发生，随处理可能要处理的工作状态是其它行业所不具备的痛点。

“如履薄冰”很好的形容了运维的工作状态，因为任务一个生产操作都可能对业务带来影响，所以运维的操作必须十分谨慎。同时在运维故障处理过程中，运维人员需要面临着来自业务、客户、开发、领导的各层的压力下，冷静地完成故障处理，是一个高压的工作状态。

经常会有人形容运维就是一个“消防员”的工作，也就是被动救火的工作，这个形容很贴切，在缺乏一些主动分析、优化、预测性的工作的背景下，运维组织的大部分工作是以被动为主，是负责应急救火、打扫战场、负责收尾的那群默默的人。

运维的人通常会认为自己就是一个背锅的角色，开发程序问题、硬件问题、系统软件问题、业务需求问题都需要运维去解决，而且这些问题对可用性的影响还要运维来承担，这是运维特有的痛点。

运维工作一方面主要是和机器或系统软件打交道，所以相对于开发、项目管理等IT岗位，转型机会的面比较窄；同时，运维岗位中重复操作性的工作占比多，如缺乏引导容易让运维人员产生麻木的状态，失去持续改善的动力；另外，前面也提到运维需要掌握的技能和管理理念很多，对于运维人员的学习能力要求很高。

SRE这个名词最早是从《Google SRE 运维解密》一书中获得，全称是Site Reliability Engineering，翻译过来就是：站点可靠性工程师。Google对SRE的职责描述为：确保站点的可用，为了达到这个目的，一方面他需要对站点涉及的系统、组件熟悉，也要关注生产运行时的状态。

为此，他需要自开发并维护很多工具和系统支撑系统的运行，比如自动化发布系统、监控系统、日志系统、服务器资源分配和编排等。SRE是一个综合素质很高的全能手，如果对他的能力进行分解主要有三块：

SRE需要懂服务器基础架构、操作系统、网络、中间件容器、常用编程语言、全局的架构意识、非常强的问题分析能力、极高的抗压能力（以便沉着高效地排障），他们还需要懂性能调优理论。为了保证系统架构的高可用，SRE甚至会有意识地破坏自己的系统，以提高系统可用性。

SRE需根据企业自身发展需要，清楚运维涉及的各项工作的流程方法论，比如故障处理、应用发布、可用性管理等等，SRE十分重视运维流程的持续改善，比如对故障的追丁溯源，怀疑一切的方式持续改进。

SRE在运行保障过程中的手段更加自动化，更高效，这种高效来源于自动化工具、监控工具的支撑，且他们还需要是这些工具的主要开发者，他们要不断优化和调整，使整个工具箱使起来更加得心应手。为此SRE有一个50%的理念，就是50%用于日常保障，50%用于项目性的工作，这个项目性的工作主要体现在运维开发与运维产品经理的角色。

关于运维开发的理解主要体现在运维工具层面，不同的组织有不同的理解，通常有三类：

运维开发团队利用开源技术结合自身需要进行一定的二次开发，这种方式在互联网企业比较流行，具体的成效大小与何时能起来收效与对这个运维开发团队的整体规划或资源投入有关；

运维开发团队主要是结合企业痛点承担产品经理的角色，设计、跟进、推广工具，这种方式常出现在传统的企业，尤其适用于投入运维开发人员比较少的企业，这种方式是投入收效快，但是对外部资源依赖比较大，不利于后续持续建设；

运维开发团队在整个工具体系下，针对部分组件选择性的引入一些成熟的工具体系，同时要求这类成熟的工具需要开放一定的接口或源码支持，对于一些与公司个性强的环节采用自研的方式。这种方式目前逐渐被一些传统企业，比如金融企业所接受。

总的来说，不管选用上面哪一种方式，运维开发团队都应该有一个整体、统一的一体化工具建设规划，并在建设过程中始终保持对运维工具体系的掌控能力，并在工具体系的上层为其它运维人员提供简易的、可创造性的“开发能力”，比如所见即所得的工具可视化、可定制的运维报表、拖拉拽方式的流程及脚本组件的拼装等运维开发方式。

1）DevOps概述

DevOps一词的来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠，他是一种方法论，包含一套基本原则和实践，工具是为有效落实这套方法论提供支持。

在软件全生命周期管理过程中，包括开发、构建、测试、发布、运营，在这个全生命周期管理过程中出现了开发组织与运维组织的部门墙，这是因为开发组织关注需求的实现，希望尽快实现变更；运维组织关注系统运行稳定，而变更又往往是生产应用不稳定的原因。

DevOps方法论的出现主要是为了解决这个协作问题，以让软件交付更加高效，质量更高，生产端更加敏捷，生产运行过程中的问题能更加高效的反馈到开发，形成一个全生命周期的闭环。随着业务对运维交付能力的时效性要求越来越高，运维组织面临“吃力不讨好”的问题：

DevOps鼓励软件开发者和IT运维人员之间所进行的沟通、协作、集成和自动化，借此有助于改善双方在交付软件过程中的速度和质量。侧重于通过标准化开发环境和自动化交付流程改善交付工作的可预测性、效率、安全性，以及可维护性。

2）运维实践中的DevOps

可以从工具链、组织文化、自动化、敏捷看板等角度讲DevOps，比如在目前比较活跃的DevOps36计，基本覆盖了运维领域很大的一块：

图1.4

从DevOps的落地效率来看，需要将DevOps进行聚焦，聚焦到交付能力上，这方面，行业里比较标准化的评估是去年底由中国信息通信研究院，联合一些互联网企业、运维社区，以及一些金融、传统企业联合进行编制的DevOps标准（券商行业中华泰参加了编制）。从这个能力模型公布出来的一些介绍看，标准对DevOps范围比较克制主要以交付能力来分解敏捷开发、持续交付、技术运营、应用架构、组织架构，这和最早的DevOps能力环比较吻合：

图1.5

从运维的交付场景看，主要是资源交付与应用交付，其中资源交付以IaaS、PaaS云的建设为主，通过云管平台的工具链将基础设施、网络、硬件、虚拟化、容器、运行中间件等系统软硬件交付能力自动化，并通过CMDB整合DevOps能力环之上的应用场景，实现资源的快速交付。

资源交付能力主要在于IaaS、PaaS层的云平台标准化、自动化、平台扩展性等方面的建设程度。应用的快速交付比资源交付更为复杂，应用交付涉及全链路的整合，链路上的节点越多落地的难度越大，因为它不仅涉及技术，还涉及理念的认同与聚焦。

应用交付能力要实现，最简单的技术栈工具需要CMDB、应用发布工具、应用版本库、监控工具，上述工具对内要与云平台对接，对外要提供接口给开发、测试工具。当然如开发、测试也能和运维使用同一套发布工具、应用版本库则效果更好，不过，实际实施过程中组织之间还是会有不少冲突，比如开发关注源代码版本管理，测试、运维关注运行版本的管理，需各个组织共同付出共建技术链。

关于运维圈里运营的概念，以转型口号喊得比较多，我对运维当中的运营有业务运营与技术运营两个维度的理解。业务运营是通过功能优化或工具开发等方式解决业务工作痛点，或通过运行分析发现影响业务开展的因素，并推动相关的优化，最终提升业务能力。技术运营则主要从技术角度去降低IT成本，提升IT服务质量与效率。具体的实施内容可以考虑如下：

图1.6

从上述概括可以看出，当前运维里面的运营，与运维数据密切相关，需要基于运维大数据平台来提升运营质量。

为了进一步说明运营，这里举两个例子：

1）理论

优锘科技CEO的陈傲寒在2016年写过一篇文章《IT：从运维到运营》，仍是我读过最好的一篇。全文从企业、运维组织角度出发分析什么是运维、什么是运营，再将运营分解到不同角色上的理解与落地的方向，全文均是干货，值得通读，这里只列出一个思维导图。

图1.7

2）实战

参加过一场腾讯QQ关于DevOps的培训，对于它们提到的一个自救方式的运营手段很有印象。那就是在腾讯QQ逐渐被微信团队替代过程中，QQ技术运维团队是如何通过各种方式去为企业带来效益，比如他们通过运维分析，得到如何更加合理的使用带宽、资源，大大减少了公司在基础设施方面的投入。

在金融企业中，也同样有很多空间可以去尝试，比如分析业务痛点，为业务提供快速的策略性的工具来替代重复操作性的业务操作；通过运维数据分析，发现客户体验方面的痛点，推动业务功能的优化等等。

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）。

关于分层的思路，Gartner这样理解：

图1.9

AIOps很火，所以对AIOps和自动化做了一些对比。暂以一句话作个区别：AIOps是基于对运维数据（日志类、指标类数据等）的机器学习，进一步解决自动化成本高或无法解决的问题，属于运维自动化的优化，细化一下区别有：

狭义的自动化则提运维“监、管、控”的工具。AIOps是将AI技术应用到IT运维领域，需要有学习、类人交互、主动决策的特征。

自动化往往以过程为导向，AIOps则以目标为导向，通过对数据进行学习，得到如何实现目标。

自动化手段有丰富的落地解决方案，适合作为替代标准化的运维操作性工作，即“面”的问题。AIOps目前仍处起步阶段，不是适合替代现有的自动化，而是应该用于解决自动化不能解决或解决成本很高的问题，即“点”的问题。

AIOps并非是要取代现有的自动化运维体系，而是赋予现有体系智能。AIOps就要“学习，了解”自动化工具 ，并且更好地“使用”这些工具，这个过程就是深度集成，它的核心是对这些工具API的自主认知和自主使用。

虽然行业内的智能运维理念十分火热，但实际落地成效上还主要处于研究阶段。从运维工具技术解决方案的角度看，对于智能的解读也有差别，如果将智能的特点解读为具备“模拟人，具备自学习，能够从数据中获取知识，进而进行预测/决策”来判断是否智能，智能是自动化的一个辅助手段，自动化才是终态。

建立在这个认识下，我们首先需要通过自动化手段解决痛点，提高工作效率，控制风险；利用运维数字化的建设为运维智能化提供数据、数据计算的能力；在自动化、数字化水平得到一定程度后，再通过人工智能的技术去解决自动化手段解决起来费力或无法解决的局部问题，让自动化具备智能的水平。

在管理领域，戴明推出的PDCA循环可以解释运维体系需要具备的可持续改进的能力条件。

PDCA循环为四个阶段，即计划（plan）、执行（do）、检查（check）、调整（Action），即在实际工作开展过程中，把各项工作按照作出计划、计划实施、检查实施效果，然后将成功的纳入标准，并不断循环改进的过程。

将这个思路引入到企业的运维体系中则是针对企业业务发展的需求，制定运维体系的整体发展目标，通过不断改进的措施提高运维工作效率、控制风险，以达到更高效、更优化的资源配置，进而推动业务的发展。要做到运维体系的可持续改进，需要做到以业务导向，整体部局；组织、流程、工具三位一体；不断审视优化。

1）P：以业务导向、整体部局

运维的最根本作用是保障IT数据的连续性，这里的IT数据包括业务，以及反映业务的数据，或者换句话可以表达为：网络不断、系统不瘫、数据不丢。随着业务对IT系统依赖程度越来越高，运维又会承担更高的期望，也就是运维向运营的转化，这就需要从业务角度去不断完善运维，以促进业务为大目标，要明白“IT for IT”是为了更好的“IT for Business”。

有了这个目标，那我们的运维体系的构建就需要与企业业务的发展保持同步，要让运维体系具备可持续改进的能力。

另外，可持续改进的过程不应该是大拐弯的方式进行改进，而应该不断的小调整，这就需要确保首先要建立一个整体、全局的运维体系，对运维各项工作做一个整体的规划，把眼光看得更远，往往可以更好的把控当前。

2）D：组织、流程、工具的三位一体

可持续改进的运维体系需要让运维的组织、流程、工具三位一体的作用，比方说：提高工作效率，需要组织的专业化分工、流程的标准化、工具的自动化配合作用；推动业务的发展，既需精细化运维分析、业务服务、运营等维度的工作资源投入，也需要有工具的建设来减少操作性的工作来释放人力，需要工具提供更高效的数据来源。

这里说的组织主要是从运维人力资源的分工、团队建设、工作目标导向、运维KPI等；流程是指以成熟的运维方法论为主体，结合企业和外部监管的规章制度、企业业务发展需要，而落地的标准化工作方法；工具既包括狭义运维的“监、管、控”，也包括运营体系所需要数字化、智能化的工具平台。

3）C+A : 不断审视优化

在实际工作过程中，审视检查的过程很容易被忽略，但实际上最大的收获可能就来自于这个总结、归纳的过程中，这也是可持续改进的运维体系的关键所在。

比方说，运维组织可以考虑在必要环节增加横向的优化团队；运维流程也需要定期对流程的落地进行分析，并对规章制度进行查漏补缺、删减不合理的流程规范、调整无法执行的规范要求；工具的建设要不断的分析工具的使用覆盖率，如何提高覆盖率，分析是否提高了运维的效率，还是带来了反作用等分析，并不断调整优化工具的建设。

在提出可持续的运维体系前，我们先归纳一下运维组织常见的运维痛点，以提出运维转型的思路，再看看如何构建一个可持续改进的运维体系来支撑运维转型。前面的运维之痛中提到了 “救火”、“背锅”、“低价值”、”重复操作“等标签，我们归纳下己有特点再看转型：

1）特点

2）转型

图1.10

上二节提到运维体系以业务导向，整体部局，组织、流程、工具三位一体，不断审视优化的建设思路，也提出了“主动精细化”、“价值驱动”、“运维开发”、“智能化运维”的转型目标，我们再将这些思路分解到组织、流程、工具的建设中，并归纳为：三大建设，十个文化的实践方法：

1）组织建设：专业化、精细化、运营化

我们将运维实施主体运维组织理解为组织，理想情况下，优秀的组织应该具备有合适的工作、合适的时间、合适的人、合适的行为四个要素组成。即组织要结合企业实际发展方向，制定符合企业、运维组织、个人发展的工作内容，并选择具备合适的知识、技能、认知、能力的人去完成工作，去实现个人的自我价值。

前面也提到，目前的运维织是一个被动保障业务系统运行，日常计划性工作容易被打断、搁置的工作，这种工作状态下的运维组织往往工作效率不高、容易出现操作风险。

为了让运维组织具备可持续改进的能力，需要提高运维组织的工作效率，我们需要将运维工作专业化，整合通用性、操作性的工作，提高工作效率，在释放运维人员工作量后，引导运维人员有计划、可量化的去做更多分析类、优化类、业务运营的主动性工作。

2）流程建设：标准化、可视化、可量化

大部分运维组织会以内部企业积累的规章制度、外部监管机构的监管要求为基础，依照ITIL、ISO20000、ITSS.1、DevOps的方法论中的一个或多个组合的方式开展运维工作。这些规章制度、监管要求、方法论的整合、落地、持续改进的过程即为流程建设的过程。

流程建设首先需要标准化流程，要先梳理好己有的流程制度，约定工作的流转方式，再通过可视化将流程整合在日常工作中，最后通过流程落地数据的分析与工具建设，持续改善提高流程落地的效率，控制操作风险。

3）工具建设：自动化、数字化、智能化、服务化

工具的建设也以可持续改进的思路构建，以整合存量资源、引入成熟或开源技术为主，建立一体化的运维工具体系。

通过体系化的思路实现运维工具（“监、管、控”）的互联互通，有序建设，实现自动化运维，全面控制风险、提高工作效率、释放人力；通过建立运维数据分析平台，实现数字化运营，提供运维数据集中与治理、主动分析的能力；在数字化运营的基础上通过运维数据挖掘、学习，优化运维或运营场景，向智能化发展；服务化则是以IT服务的方式将运维能力向外输出。