关于运维:运维不简单构建可扩展性的运维体系-IDCF

与一个行业大牛敌人交换时，听到他年老时在思科的一些对于将工作办法升华为方法论，比方“监、管、控”、“新网点”理念，并推动整个行业建设时为之一震。这个触动让我有了让本人的运维常识体系建设做第一次飞跃的打算，即如何将常识体系通过一个主线串起来。

对于这个主线，找过一些敌人做了交换，比方“危险可控”、“一体化”、“更高效更优化的资源配置”、“可扩展性”。因为本人次要身处一线运维团队，所以选了“可扩展性”的主线，接下来打算依据这条主线，不断完善常识体系，指标是体系化的整顿常识体系，次要从组织、流程、工具的可继续整合。

以下这篇《运维不简略》，次要是对运维整体的概览，讲讲对运维的意识，以及一些转型理念思考。

前阵子，跟一个项目经理沟通是否提前半天将变更申请提交过去时，这位项目经理很不了解地问我，“你们运维不就是在生产环境部署个程序这么简略的工作吗？你们又不懂程序，评审不出什么吧？”。运维多年，对运维的这类意识听过很多，它反映了企业里不同的组织团队对运维的意识往往仅限于一些简略操作性的工作，比方生产利用零碎在故障时的重启、利用变更时敲敲命令、平时增删改查数据，或者是办公室和电无关的所有软硬件的应用问题等等。

那么如何了解运维呢？百度百科对运维的解释为：

企业 IT 部门采纳相干的办法、伎俩、技术、制度、流程和文档等，对 IT 软硬运行环境(软件环境、网络环境等)、IT 业务零碎和 IT 运维人员进行的综合治理。

从百度百科的解释看，运维岗位须要一个综合性的技术与治理能力，须要把握大量的方法论与技术栈。

运维广义“运维技术与资源”能够定义为“监、管、控”，技术与资源次要是撑持运维 / 经营的品质、效率、老本的均衡。

以下简略摘录了运维的一些能力要求：

运维标准的落地：以 ITIL、ISO20000、ITSS.1 等方法论，联合内部监管及外部标准的落地；
监管机构的要求落地：了解、疾速响应、落地监管机构的治理要求；
基本保障：配置、监控、利用公布、资源扩容、事件、问题等；
根底能力：网络、服务器、操作系统、数据库、中间件、JVM、利用等根本应用与调优；
业务服务能力：SLA，服务台、业务征询、保护、教训库、等反对能力；
可用性治理能力：巡检、业务零碎连续性、可用性，基础架构及利用零碎的高可用、备件冗余资源；
危险、平安治理能力：操作、审计、监管危险，破绽、攻打管控；
故障治理能力：事件、问题管理水平与能力；
继续交付能力：利用变更、根底资源、办公服务交付能力；
被动优化能力：架构优化、性能响应效率、客户体验等;
应急演练：架构高可用、突发事件、业务故障的架构、计划、文档、人员熟练程度等;
业务撑持：数据保护、数据提取、参数保护等；
运行剖析能力：容量、性能、可用性剖析等；
经营能力：促成业务痛点的发现与解决、客户及业务业务体验等；
老本管制：更好的评估人力、硬件、带宽、软件，节省成本；
运维开发：运维自动化工具的建设，运维开发能力的造就；
其它

不同的企业须要运维的能力会有不同的扩大，上述能力要求每一点扩散出来都将是一个简单的技术栈，比方“根底能力”中的 Linux 操作系统的内核关系图（摘自互联网，如图），或再深刻一些对于 MySQL 优化（摘自互联网，如图），须要运维人员对技术能力深度的要求。

讲到这，必定会有人说上述技术栈的能力要求通常是因为某个运维组织仍处于专家式运维，自动化水平不够高导致。确实，实践上所有运维操作性、命令的工作都能够整合为教训，并通过自动化落地实现，当初互联网企业对外都声称自动化在运维工作覆盖面很高，己经开始迈向智能化，AIOps，甚至提出了 NoOps 的解决方案。

对于这些互联网企业的自动化对日常运维工作实在的覆盖面临时无奈讲究，但以我的教训看，至多金融企业的自动化覆盖面还有很长的路要走，且必定还会有很大一部分工作很难自动化，毕竟工作类型太多，在无限的投入上只能集中力量去做投入产出比更高的运维自动化。

这里再以一个运维工具思维导图，简略列示一些惯例的运维操作，能够看出其实很难有一套能解决所有运维操作的工具平台。

所以我感觉，随着业务要求越来越高、规模越来越大、监管要求越来越高，纵使内部如何声称自动化、智能化对运维人员教训、技术、治理能力代替，金融企业内的运维还须要认清理论状况，联合企业的整体策略定位，强调运维团队在运维治理与技术能力的广度与深度，再有偏重、有先后地实现自动化程度。

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

近年来，随着运维技术的疾速倒退，各行业的运维程度失去了较大的晋升，同时，运维圈的分享也越来越凋谢，从国外 Google 的 SRE 理念，到国内新技术领跑者以及借助于各种运维专题的公众号、运维大会，有大量的互联网、传统企业的运维组织进行分享。

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

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

运维组织的角色：绝大部分运维组织都是老本部门，企业对运维组织的器重水平通常不如开发组织，更不用说是前台业务部门。这方面造成了运维部门的规模通常增长很慢，以 Google 为例，在《Google SRE 运维解密》一书中提到，因为 Google 的数据中心规模急剧扩充，零碎越来越简单，而运维人员规模又跟不上，所以他们的运维组织采纳组建 SRE 的运维开发团队实现自救。
业务对运维服务质量的要求：越来越多的金融业务己从线下走到线上，为了博得更多用户的青眼，一方面，业务要求更多、体验更佳的业务性能；另一方面业务对利用公布的交付速度有了更高的要求。前者会产生更简单的零碎设计，后者须要更高效的利用公布反对，两者都会对系统响应效率、稳定性带来影响。
内部监管要求：长期以来，为了防备金融风险，监管机构对金融企业放弃强监管的形式，十九大之后，监管对金融企业的信息技术的稳定性、规范性有增无减。在强监管下，信息系统的稳定性有了进一步保障，但也给运维组织带来更高的要求，主观上也加大了工作量，及因为标准流程带来的工作效率的降落。
业务并发要求：用户量的减少，营销流动一直推出，须要零碎具备更高的并发解决能力要求，企业一直引入大量分布式、开源架构代替传统绝对成熟稳固的架构来满足业务须要，这些变动都给运维能力带来挑战。
数据中心规模增大：数据中心的多核心建设，云化，去 IOE，分布式架构的引入使得利用零碎规模成倍增大。

网上有一个考察数据，在整个运维老本的调配中，软硬件和网络设备的保护老本占 30%，保护服务老本占 30%，外部运维人力老本则占了 40%。这里的人力老本包含当初保护、培训、散失与引入等老本，如果将保护服务老本也纳入到人力老本之上，则人力这一块的老本将回升为 70%，影响这个人力老本的因素次要有：

运维能力模型：ITIL、ISO20000、ITSS.1 是运维畛域中比拟成体系化的方法论（目前更为火爆的 DevOps 更偏向于是一种思路），其中只有 ITSS.1 提出了运维能力模型的概念，但在量化运维人员具体能力的实际操作上也比拟难落地。也就是说你很难评估一个运维人员如何做才是做得优，如何是中，如何是差，这些评估通常比拟主观，这也主观影响了运维人员一直减少技能、优化工作效率的能源。
运维规范化：组织扩充到肯定规模，以口口相传的传授，联合个体责任心、工作习惯为主的形式容易呈现操作危险，且无奈进行量化绩效治理，治理标准无奈落地。
运维精细化水平：组织通常是从纵向职能型的形式造成，这种形式能造就全能型、经验丰富的专家式人才，这些专家式人才利用教训能疾速解决职责下的惯例问题，且效率比拟高，适宜小型的组织。随着组织的一直壮大，面对的问题越来越简单，技术要求越来越多，一方面很多人不能满足这种专家式人才的要求；一方面也会产生很多重复性的工作；同时对于人员散失带来的影响比拟大。这时候就须要将纵向工作精细化，再辅助横向人员对工作进行继续优化。
运维指标：运维的指标往往以被动式的指标为主，被动解决故障、被动解决问题、被动提供利用交付、被动节省成本等，这种被动式的运维指标导致计划性工作不够，不足继续一直的自我优化，须要被动提高效率、品质，降低成本，并由运维向被动经营指标去转变。
自动化能力：IT 软硬件体量宏大，且增长迅速，手工操作的机器工作太多；运维数据越来越多；故障定位越来越难，人工教训依赖高；监控伎俩不够及时、全面；利用公布、资源交付效率低下；没有被动的容量、性能剖析、体验剖析能力……这些都是常见的一些痛点。

作为运维组织中的运维人员同样面临不少痛点，来自工作工夫、工作压力、学习压力、职业倒退等等，以下简略列举：

7*24 小时制的工作工夫：运维人员的节假日是不残缺的，通常节假日须要运维值班保障或在家通过 VPN 近程操作、或和家人团圆时还近程领导进行故障应急；运维人员上班时间不同于一般工作，为了不影响业务，利用公布、基础设施变更、演练等工作都会放到早晨，对客户的业务零碎还可能要安顿到深夜。这种随时可能产生，随时可能要解决的工作状态是其它行业所不具备的痛点。
高度压力的工作：“如履薄冰”很好地形容了运维的工作状态，因为任何一个生产操作都可能对业务带来影响，所以运维的操作必须非常审慎。同时在运维故障处理过程中，运维人员须要在来自业务、客户、开发、领导等各层的压力下，沉着地实现故障解决，这是一个低压的工作状态。
被动的工作：常常会有人形容运维就是一个“消防员”的角色，也就是被动救火的工作，这个形容很贴切，在不足一些被动剖析、优化、预测性的工作的背景下，运维组织的大部分工作是以被动为主，是负责应急救火、打扫战场、负责收尾的那群默默的人。
对工作的意识：运维人员通常会认为本人就是一个背锅的角色，开发程序问题、硬件问题、系统软件问题、业务需要问题都须要运维去解决，而且这些问题对可用性的影响还要运维来承当，这是运维特有的痛点。
职业压力：运维工作一方面次要是和机器或系统软件打交道，所以绝对于开发、项目管理等 IT 岗位，转型机会比拟少；同时，运维岗位中反复操作性的工作占比多，如不足疏导容易让运维人员产生麻痹的状态，失去继续改善的能源；另外，后面也提到运维须要把握的技能和治理理念很多，对于运维人员的学习能力要求很高。

SRE 这个名词最早是从《Google SRE 运维解密》一书中取得，全称是 Site Reliability Engineering，翻译过去就是：站点可靠性工程师。

Google 对 SRE 的职责形容为：确保站点的可用。为了达到这个目标，一方面他须要相熟站点波及的零碎、组件，也要关注生产运行时的状态，为此，他须要自开发并保护很多工具和零碎撑持零碎的运行，比方自动化公布零碎，监控零碎，日志零碎，服务器资源分配和编排等。

SRE 是一个综合素质很高的全能手，如果对他的能力进行合成次要有三块：

相熟零碎架构与运行状态：SRE 须要懂服务器基础架构、操作系统、网络、中间件容器、罕用编程语言、全局的架构意识、十分强的问题剖析能力、极高的抗压能力（以便从容高效地排障），他们还须要懂性能调优实践。为了保证系统架构的高可用，SRE 甚至会无意识地毁坏本人的零碎，以进步零碎可用性。
相熟运维波及的治理办法：SRE 需依据企业本身倒退须要，分明运维波及的各项工作的流程方法论，比方故障解决、利用公布、可用性治理等等，SRE 十分重视运维流程的继续改善，比方对故障的追丁溯源，狐疑所有的形式继续改良。
运维开发 + 产品经理：SRE 在运行保障过程中的伎俩更加自动化，更高效，这种高效来源于自动化工具、监控工具的撑持，且他们还须要是这些工具的次要开发者，他们要一直优化和调整，使整个工具箱用起来更加得心应手。为此 SRE 有一个 50% 的理念，就是 50% 用于日常保障，50% 用于我的项目性的工作，这个我的项目性的工作次要体现在运维开发与运维产品经理的角色。

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

齐全自建：运维开发团队利用开源技术联合本身须要进行肯定的二次开发，这种形式在互联网企业比拟风行，具体的功效大小与何时能有收效与对这个运维开发团队的整体规划或资源投入无关；
外购开发资源或工具产品：运维开发团队次要是联合企业痛点承当产品经理的角色，设计、跟进、推广工具，这种形式常呈现在传统的企业，尤其实用于投入运维开发人员比拟少的企业，这种形式是投入收效快，然而对外部资源依赖比拟大，不利于后续继续建设；
外购与自建相结合：运维开发团队在整个工具体系下，针对局部组件选择性地引入一些成熟的工具体系，同时要求这类成熟的工具须要凋谢肯定的接口或源码反对，对于一些与公司共性强的环节采纳自研的形式。这种形式目前逐步被一些传统企业，比方金融企业所承受。

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

DevOps 一词来自于 Development 和 Operations 的组合，突出器重软件开发人员和运维人员的沟通单干，通过自动化流程来使得软件构建、测试、公布更加快捷、频繁和牢靠，是一种方法论，蕴含一套根本准则和实际，工具是为无效落实这套方法论提供反对。

在软件全生命周期治理过程中，包含开发，构建，测试，公布，经营，在这个全生命周期治理过程中呈现了开发组织与运维组织的部门墙，这是因为开发组织关注需要的实现，心愿尽快实现变更；运维组织关注零碎运行稳固，而变更又往往是生产利用不稳固的起因。

DevOps 方法论的呈现次要是为了解决这个合作问题，以让软件交付更加高效，品质更高，生产端更加麻利，生产运行过程中的问题能更加高效地反馈到开发，造成一个全生命周期的闭环。

随着业务对运维交付能力的时效性要求越来越高，运维组织面临“吃力不讨好”的问题：

吃力：破费大量工夫在利用部署的操作性工作中。这部分部署变更包含新性能的上线以及修复性能 Bug 的办法。
不讨好：操作性的工作越多，带来的操作危险越大，有这样一个统计，在手工运行 5 条命令的状况下，胜利部署的概率就已跌至 86%；如需手工运行 55 条命令，胜利部署的概率将跌至 22%；如需手工运行 100 条命令，胜利部署的概率将趋近于 0（仅 2%）。

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

能够从工具链、组织文化、自动化、麻利看板等角度讲 DevOps，比方在目前比拟沉闷的 DevOps 36 计中，根本笼罩了运维畛域很大的一块：

从 DevOps 的落地效率来看，须要将 DevOps 进行聚焦，聚焦到交付能力上，这方面，行业里比拟标准化的评估是去年底由中国信息通信研究院，联结一些互联网企业、运维社区，以及一些金融、传统企业联结编制的 DevOps 规范（券商行业中华泰加入了编制）。

从这个能力模型公布出来的一些介绍看，规范对 DevOps 范畴比拟克服，次要以交付能力来合成麻利开发、继续交付、技术经营、利用架构、组织架构，这和最早的 DevOps 能力环比拟吻合：

从运维的交付场景看，次要是资源交付与利用交付，其中资源交付以 IAAS、PAAS 云的建设为主，通过云管平台的工具链将基础设施、网络、硬件、虚拟化、容器、运行中间件等零碎软硬件交付能力自动化，并通过 CMDB 整合 DevOps 能力环之上的利用场景，实现资源的疾速交付。资源交付能力次要在于 IAAS、PAAS 层的云平台标准化、自动化、平台扩展性等方面的建设水平。

利用的疾速交付比资源交付更为简单，利用交付波及全链路的整合，链路上的节点越多落地的难度越大，因为它不仅波及技术，还波及理念的认同与聚焦。利用交付能力要实现，最简略的技术栈工具须要 CMDB、利用公布工具、利用版本库、监控工具，上述工具对内要与云平台对接，对外要提供接口给开发、测试工具。当然如开发、测试也能和运维应用同一套公布工具、利用版本库则成果更好，不过，理论施行过程中组织之间还是会有不少抵触，比方开发关注源代码版本治理，测试、运维关注运行版本的治理，需各个组织独特付出共建技术链。

对于运维圈里经营的概念，以转型口号喊得比拟多，我对运维当中的经营有业务经营与技术经营两个维度的了解。业务经营是通过性能优化或工具开发等形式解决业务工作痛点，或通过运行剖析发现影响业务发展的因素，并推动相干的优化，最终晋升业务能力。技术经营则次要从技术角度去升高 IT 老本，晋升 IT 服务质量与效率。

具体的施行内容能够思考如下：

从上述概括能够看出，以后运维外面的经营，与运维数据密切相关，须要基于运维大数据平台来晋升经营品质。

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

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

加入过一场腾讯 QQ 对于 DevOps 的培训，对于它们提到的一个自救形式的经营伎俩很有印象。那就是在腾讯 QQ 逐步被微信团队代替的过程中，QQ 技术运维团队是如何通过各种形式去为企业带来效益，比方他们通过运维剖析，失去如何更加正当地应用带宽、资源，大大减少了公司在基础设施方面的投入。

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

AIOps 这个词最早是在 2016 年由 Gartner 提出（当然国内很多厂商也提出它们早几年也提出了这个理念）。AIOps 是 Algorithmic IT Operations 的缩写，是基于算法的 IT 运维，即通过应用统计分析和机器学习的办法解决从各 IT 设施、业务利用、运维工具收集的数据，从而增强加强运维自动化能力，以便更快、更无效、更全面的实现自动化成果。

以下是 Gartner 提出 AIOps 的一张图：

Gartner 通过应用上图解释了 AIOps 平台的工作原理。AIOps 有两个次要组件：大数据和机器学习。

它须要从孤立的 IT 数据中移除，以便将大量数据平台内的察看数据（例如监控零碎和作业日志中发现的数据）与参加数据（通常在故障单，事件和事件记录中找到）相结合。AIO 而后针对组合的 IT 数据施行全面的剖析和机器学习（ML）策略。冀望的后果是继续的见解，通过自动化产生继续的改良和修复。

AIO 能够被认为是外围 IT 性能的继续集成和部署（CI / CD）。

宽泛和多样化的 IT 数据源：如日志类的设施日志、系统日志，利用日志、运维操作日志；指标类的监控性能指标、事件。
具备针对海量数据处理与剖析的运算平台，可能从现有的 IT 数据生成新的数据和元数据、计算和剖析还打消乐音，识别模式或趋势，隔离可能的起因，揭示潜在问题，并实现其余 IT 特定指标。
算法，充分利用 IT 畛域的专业知识，更适当，高效地解决数据。
机器学习，从依据算法剖析的输入和引入零碎的新数据主动更改或创立新的算法。
可视化，以易于生产的形式向 IT 口头提供洞察和倡议，以促成了解和口头。
自动化，其应用剖析和机器学习产生的后果主动创立和利用响应或改良已辨认的问题。

对于分层的思路，Gartner 这样了解：

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

细化一下区别有：

概念：广义的自动化指运维“监、管、控”的工具。AIOps 是将 AI 技术利用到 IT 运维畛域，须要有学习、类人交互、被动决策的特色。
实现思路：自动化往往以过程为导向，AIOps 则以指标为导向，通过对数据进行学习，失去如何实现目标。
门槛高度：自动化伎俩有丰盛的落地解决方案，适宜作为代替标准化的运维操作性工作，即“面”的问题。AIOps 目前仍处起步阶段，不是适宜代替现有的自动化，而是应该用于解决自动化不能解决或解决老本很高的问题，即“点”的问题。
如何整合：AIOps 并非是要取代现有的自动化运维体系，而是赋予现有体系智能。AIOps 要“学习，理解”自动化工具，并且更好地“应用”这些工具，这个过程就是深度集成，它的外围是对这些工具 API 的自主认知和自主应用。

尽管行业内的智能运维理念非常炽热，但理论落地功效上还次要处于钻研阶段。从运维工具技术解决方案的角度看，对于智能的解读也有差异，如果将智能的特点解读为具备”模仿人，具备自学习，可能从数据中获取常识，进而进行预测 / 决策“来判断是否智能，智能是自动化的一个辅助伎俩，自动化才是终态。

建设在这个意识下，咱们首先须要通过自动化伎俩解决痛点，进步工作效率，管制危险；利用运维数字化的建设为运维智能化提供数据、数据计算的能力；在自动化、数字化程度失去肯定水平后，再通过人工智能的技术去解决自动化伎俩解决起来费劲或无奈解决的部分问题，让自动化具备智能的程度。

在治理畛域，戴明推出的 PDCA 循环能够解释运维体系须要具备的可继续改良的能力条件。PDCA 循环为四个阶段，即打算（plan）、执行（do）、查看（check）、调整（Action），即在理论工作发展过程中，把各项工作依照作出打算、打算施行、查看施行成果，而后将胜利地纳入规范，并一直循环改良的过程。

将这个思路引入到企业的运维体系中则是针对企业业务倒退的需要，制订运维体系的整体倒退指标，通过不断改进的措施进步运维工作效率、管制危险，以达到更高效、更优化的资源配置，进而推动业务的倒退。要做到运维体系的可继续改良，须要做到以业务导向，整体布局；组织、流程、工具三位一体；一直扫视优化。

运维的最基本作用是保障 IT 数据的连续性，这里的 IT 数据包含业务，以及反映业务的数据，或者换句话能够表白为：网络一直、零碎不瘫、数据不丢。随着业务对 IT 零碎依赖水平越来越高，运维又会承当更高的冀望，也就是运维向经营的转化，这就须要从业务角度去不断完善运维，以促成业务为大指标，要明确“IT for IT”是为了更好的“IT for Business”。

有了这个指标，那咱们的运维体系的构建就须要与企业业务的倒退放弃同步，要让运维体系具备可继续改良的能力。

另外，可继续改良的过程不应该是大拐弯的形式进行改良，而应该一直的小调整，这就须要确保首先要建设一个整体、全局的运维体系，对运维各项工作做一个整体的布局，把眼光看得更远，往往能够更好地把控以后。

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

组织次要是从运维人力资源的分工、团队建设、工作指标导向、运维 KPI 等；
流程是指以成熟的运维方法论为主体，联合企业和内部监管的规章制度、企业业务倒退须要，而落地的标准化工作办法；
工具既包含广义运维的“监、管、控”，也包含经营体系所须要数字化、智能化的工具平台。

在理论工作过程中，扫视查看的过程很容易被疏忽，但实际上最大的播种可能就来自于这个总结、演绎的过程中，这也是可继续改良的运维体系的关键所在。比方说：

运维组织能够思考在必要环节减少横向的优化团队；
运维流程也须要定期对流程的落地进行剖析，并对规章制度进行查漏补缺、删减不合理的流程标准、调整无奈执行的标准要求；
工具的建设要一直剖析工具的应用覆盖率，如何进步覆盖率，剖析是否进步了运维的效率，还是带来了副作用等，并一直调整优化工具的建设。

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

被动救火式，以被动保障业务零碎运行，日常计划性工作容易被打断、搁置；
问题驱动式，以零碎可用性、可靠性、业务申请等问题驱动运维工作；
操作运维，重复性、操作类点次要工作量的运维模式；
教训式运维，由人工教训驱动的运维模式，尤其是一些经验丰富的老员工的到职在短期内会对运维品质带来肯定的冲击。

从被动救火式向被动精细化转型，专业化分工、被动剖析，被动优化，驱动开发，促成 DevOps 的落地；
从问题驱动向价值驱动转型，以企业业务倒退指标为主线，业务体验、服务满意度、促成业务更好倒退；
从操作运维向运维开发转型，通过为运维人员提供运维开发平台，升高运维开发门槛，疾速落地一些紧迫的运维工具，升高操作性、重复性的运维工作；
从依附教训向智能化驱动运维转型，联合数据分析、知识库、机器学习技术促成运维智能化。

前文提到运维体系以业务导向，整体布局，组织、流程、工具三位一体，一直扫视优化的建设思路，也提出了“被动精细化”、“价值驱动”、“运维开发”、“智能化运维”的转型指标，咱们再将这些思路合成到组织、流程、工具的建设中，并演绎为：三大建设，十个文化的实际办法：

咱们将运维施行主体运维组织了解为组织，现实状况下，优良的组织应该具备有适合的工作、适合的工夫、适合的人、适合的行为四个因素。即组织要联合企业理论倒退方向，制订合乎企业、运维组织、集体倒退的工作内容，并抉择具备适合的常识、技能、认知、能力的人去实现工作，去实现集体的自我价值。

后面也提到，目前的运维织是一个被动保障业务零碎运行，日常计划性工作容易被打断、搁置的工作，这种工作状态下的运维组织往往工作效率不高、容易呈现操作危险。为了让运维组织具备可继续改良的能力，须要进步运维组织的工作效率，咱们须要将运维工作专业化，整合通用性、操作性的工作，进步工作效率，在开释运维人员工作量后，疏导运维人员有打算、可量化地去做更多剖析类、优化类、业务经营的主动性工作。

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

流程建设首先须要标准化流程，要先梳理好已有的流程制度，约定工作的流转形式，再通过可视化将流程整合在日常工作中，最初通过流程落地数据的剖析与工具建设，继续改善进步流程落地的效率，管制操作危险。

工具的建设也以可继续改良的思路构建，以整合存量资源、引入成熟或开源技术为主，建设一体化的运维工具体系，通过体系化的思路实现运维工具（“监、管、控”）的互联互通，有序建设，实现自动化运维，全面管制危险、进步工作效率、开释人力；通过建设运维数据分析平台，实现数字化经营，进步运维数据集中与治理、被动剖析的能力；在数字化经营的根底上通过运维数据挖掘、学习，优化运维或经营场景，向智能化倒退；服务化则是以 IT 服务的形式将运维能力向外输入。

起源：运维之路
作者：广发彭华盛
【作者】彭华盛，广发证券数字化运维研发团队负责人。超过 10 年的金融畛域运维工作，期间负责参加企业运维组织、流程、工具的建设，包含各类重大业务零碎我的项目与数据中心工程性我的项目的施行，数据中心标准化工作流程构建，运维工具体系的布局与研发、数字化转型钻研与施行相干等工作，对金融畛域的运维有较全面的了解。近年来专一数字化转型钻研，摸索推动数字化技术与业务转型双轮驱动的协同模式，推动业务数字化转型。平时喜爱钻研新技术、新理念、思维模式、产品设计等等，乐于分享。腾讯 TVP 成员。
申明：文章取得作者受权在 IDCF 社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。

6 月每周四晚 8 点，【冬哥有话说】开心一“夏”。公众号留言“开心”可获取地址

0603 无敌哥《IDCF 人才成长地图与 5P》（《端到端 DevOps 继续交付 (5P) 精品课》第 1 课）
0610 冬哥《带你玩转翻新设计思维》
0617 无敌哥《麻利项目管理到底是个啥》
0624 冬哥《VUCA 时代的麻利领导力》

关于运维:运维不简单构建可扩展性的运维体系-IDCF

一、运维不简略

二、运维之痛

2.1 组织之痛

1）内部客观因素

2）外部因素

2.2 个体之痛

三、自救

3.1 SRE

3.2 运维开发

3.3 DevOps

1）DevOps 概述

2）运维实际中的 DevOps

3.4 经营

1）实践

2）实战

3.5 AIOps

3.6 AIOps 与自动化的关系

四、体系

4.1 运维的可继续改良

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

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

3）C+A : 一直扫视优化

4.2 转型思路

1）特点

2）转型

4.3 构建运维体系

组织建设：专业化、精细化、经营化

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

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