客观的讲,通过总结一些工作心得,让自己的运维知识体系的建设有些效果。年初与一个行业大牛的朋友交流时,在听到他年轻时在思科的一些关于将工作方法升华为方法论,比如“监、管、控”、“新网点”理念,并推动整个行业建设时为之一震。这个触动让我有了让自己的运维知识体系建设做第一次飞跃的打算,即如何将知识体系通过一个主线串起来。关于这个主线,找过一些朋友做了交流,比如“风险可控”、“一体化”、“更高效更优化的资源配置”、“可扩展性”。由于自己主要身处一线运维团队,所以选了“可扩展性”的主线,接下来打算根据这条主线,不断完善知识体系,目标是体系化的整理知识体系,主要从组织、流程、工具的可持续整合。
以下这篇为《运维不简单》,主要是对运维整体的概览,讲讲对运维的认识,以及一些转型理念思考。
前阵子,跟一个项目经理沟通能否提前半天将变更申请提交过来时,这位项目经理很不理解的问我,“你们运维不就是在生产环境部署个程序这么简单的工作吗?你们又不懂程序,评审不出什么吧?”。运维多年,对运维的这类认识听过很多,它反映了企业里不同的组织团队对运维的认识往往 仅限于一些简单操作性的工作,比如生产应用系统在故障时的重启、应用变更时敲敲命令、平时增删改查数据,或者是办公室和电有关的所有软硬件的使用问题等等。
那么如何理解运维呢?百度百科对运维的解释为:企业 IT 部门采用相关的方法、手段、技术、制度、流程和文档等,对IT 软硬运行环境(软件环境、网络环境等)、IT 业务系统和 IT 运维人员进行的综合管理。从百度百科的解释看,运维岗位需要一个综合性的技术与管理能力,需要掌握大量的方法论与技术栈。
运维狭义“运维技术与资源”可以定义为“监、管、控”,技术与资源主要是支撑运维/运营的质量、效率、成本的平衡。以下简单摘录了运维的一些能力要求:
其它
不同的企业需要运维的能力会有不同的扩展,同进上述能力要求每一点扩散出来都将是一个复杂的技术栈,比如“基础能力”中的LINUX操作系统的内核关系图(摘自互联网见,图1.1),或再深入一些关于mysql优化(摘自互联网见,图1.2),需要运维人员对技术能力深度的要求。
所以我觉得,随着业务要求越来越高、规模越来越大、监管要求越来越高,纵使外部如何宣称自动化、智能化对运维人员经验、技术、管理能力替代,金融企业内的运维还需要认清实际情况,结合企业的整体战略定位,强调运维团队在运维管理与技术能力的广度与深度,再有侧重、有先后的实现自动化水平。
在未来一段时间里,金融企业的运维岗位仍是一个复杂的、综合性技能的工作岗位。
近年来,随着运维技术的快速发展,各行业的运维水平在得到了较大的提升同时,运维圈的分享也越来越开放,从国外google的SRE理念,到国内新技术领跑者腾讯游戏的蓝鲸、织云,以及借助于各种运维专题的公众号、运维大会有大量的互联网、传统企业的运维组织进行分享。
前面讲过,在企业内部其它团队对运维的认识通常是简单操作,出故障时才会找的同团队,随着信息技术的发展与业务的发展,运维组织痛点越来越明显,企业内对运维组织的不满的声音越来越多,反思一下原因,分外部客观因素和内部因素。
1)外部客观因素
在当前大数据时代,金融企业的运维面临业务规模的不断扩大,业务竞争越来越激烈,监管要求越来越高,数据中心的规模也越来越高,大量新技术、开源架构的引入取代了传统稳定的系统架构等等因素影响。
2)内部因素
网上有一个调查数据,在整个运维成本的分配中,软硬件和网络设备的维护成本占 30%,维护服务成本占30%,内部运维人力成本则占了40%。这里的人力成本包括现在维护、培训、流失与引入等成本,如果将维护服务成本也纳入到人力成本之上,则人力这一块的成本将上升为70%,影响这个人力成本的因素主要有:
作为运维组织中的运维人员同样面临不少痛点,有来自工作时间、工作压力、学习压力、职业发展等等,以下简单罗列:
SRE这个名词最早是从《google sre 运维解密》一书中获得,全称是Site Reliability Engineering,翻译过来就是:站点可靠性工程师。google对SRE的职责描述为:确保站点的可用,为了达到这个目的,一方面他需要对站点涉及的系统、组件熟悉,也要关注生产运行时的状态,为此,他需要自开发并维护很多工具和系统支撑系统的运行,比如自动化发布系统,监控系统,日志系统,服务器资源分配和编排等。SRE是一个综合素质很高的全能手,如果对他的能力进行分解主要有三块:
关于运维开发的理解主要体现在运维工具层面,不同的组织有不同的理解,通常有三类:
外购与自建相结合: 运维开发团队在整个工具体系下,针对部份组件选择性的引入一些成熟的工具体系,同时要求这类成熟的工具需要开放一定的接口或源码支持,对于一些与公司个性强的环节采用自研的方式。这种方式目前逐渐被运一些传统企业,比如金融企业所接受。
总的来说,不管选用上面哪一种方式,运维开发团队都应该有一个整体、统一的一体化工具建设规划,并在建设过程中始终保持对运维工具体系的掌控能力,并在工具体系的上层为其它运维人员提供简易的、可创造性的“开发能力”,比如所见即所得的工具可视化、可定制的运维报表、拖拉拽方式的流程及脚本组件的拼装等运维开发方式。
DevOps一词的来自于Development和Operations的组合,突出重视软件开发人员和运维人员的沟通合作,通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠,他是一种方法论,包含一套基本原则和实践,工具是为有效落实这套方法论提供支持。
在软件全生命周期管理过程中,包括开发,构建,测试,发布,运营,在这个全生命周期管理过程中出现了开发组织与运维组织的部门墙,这是因为开发组织关注需求的实现,希望尽快实现变更;运维组织关注系统运行稳定,而变更又往往是生产应用不稳定的原因。DEVOPS方法论的出现主要是为了解决这个协作问题,以让软件交付更加高效,质量更高,生产端更加敏捷,生产运行过程中的问题能更加高效的反馈到开发,形成一个全生命周期的闭环。随着业务对运维交付能力的时效性要求越来越高,运维组织面临“吃力不讨好”的问题:
DevOps鼓励软件开发者和IT运维人员之间所进行的沟通、协作、集成和自动化,借此有助于改善双方在交付软件过程中的速度和质量。侧重于通过标准化开发环境和自动化交付流程改善交付工作的可预测性、效率、安全性,以及可维护性。
可以从工具链、组织文化、自动化、敏捷看板等角度讲DevOps,比如在目前比较活跃的DevOps36计中,基本覆盖了运维领域很大的一块:
从运维的交付场景看,主要是资源交付与应用交付,基中资源交付以IAAS、PAAS云的建设为主,通过云管平台的工具链将基础设施、网络、硬件、虚拟化、容器、运行中间件等系统软硬件交付能力自动化,并通过CMDB整合DevOps能力环之上的应用场景,实现资源的快速交付。资源交付能力主要在于IAAS、PAAS层的云平台标准化、自动化、平台扩展性等方面的建设程度。应用的快速交付比资源交付更为复杂,应用交付涉及全链路的整合,链路上的节点越多落地的难度越大,因为它不仅涉及技术,还涉及理念的认同与聚焦。应用交付能力要实现,最简单的技术栈工具需要CMDB、应用发布工具、应用版本库、监控工具,上述工具对内要与云平台对接,对外要提供接口给开发、测试工具。当然如开发、测试也能和运维使用同一套发布工具、应用版本库则效果更好,不过,实际实施过程中组织之间还是会有不少冲突,比如开发关注源代码版本管理,测试、运维关注运行版本的管理,需各个组织共同付出共建技术链。
关于运维圈里运营的概念,以转型口号喊得比较多,我对运维当中的运营有业务运营与技术运营两个维度的理解。业务运营是通过功能优化或工具开发等方式解决业务工作痛点,或通过运行分析发现影响业务开展的因素,并推动相关的优化,最终提升业务能力。技术运营则主要从技术角度去降低IT成本,提升IT服务质量与效率。具体的实施内容可以考虑如下:
从上述概括可以看出,当前运维里面的运营,与运维数据密切相关,需要基于运维大数据平台来提升运营质量。
为了进一步说明运营,这里举两个例子:
1)理论
优锘科技CEO的陈傲寒在2016年写过一篇文章《IT:从运维到运营》,虽然己过去1年多,仍是我读过最好的一篇。全文从企业、运维组织角度出发分析什么是运维、什么是运营,再将运营分解到不同角色上的理解与落地的方向,全文均是干货,值得通读,这里只列出一个思维导图。
去年参加了一场腾讯QQ关于DevOps的培训,对于它们提到的一个自救方式的运营手段很有印象。那就是在腾讯QQ逐渐被微信团队替代过程中,QQ技术运维团队是如何通过各种方式去为企业带来效益,比如他们通过运维分析,得到如何更加合理的使用带宽、资源,大大减少了公司在基础设施方面的投入。在金融企业中,也同样有很多空间可以去尝试,比如分析业务痛点,为业务提供快速的策略性的工具来替代重复操作性的业务操作;通过运维数据分析,发现客户体验方面的痛点,推动业务功能的优化等等。
AIOps这个词最早是在2016年由Gartner提出(当然国内很多厂商也提出它们早几年也提出了这个理念)。AIOps是Algorithmic IT Operations的缩写,是基于算法的IT运维,即通过使用统计分析和机器学习的方法处理从各IT设备、业务应用、运维工具收集的数据,从而加强增强运维自动化能力,以便更快、更有效、更全面的实现自动化效果。以下是Gartner提出AIOps的一张图:
Gartner通过使用图1中的图解释了AIOps平台的工作原理.AIOps有两个主要组件:大数据和机器学习。它需要从孤立的IT数据中移除,以便将大量数据平台内的观察数据(例如监控系统和作业日志中发现的数据)与参与数据(通常在故障单,事件和事件记录中找到)相结合。AIO然后针对组合的IT数据实施全面的分析和机器学习(ML)策略。期望的结果是持续的见解,通过自动化产生持续的改进和修复。AIO可以被认为是核心IT功能的持续集成和部署(CI / CD)。
自动化 ,其使用分析和机器学习产生的结果自动创建和应用响应或改进已识别的问题。
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)转型
-从被动救火式向主动精细化转型,专业化分工、主动分析,主动优化,驱动开发,促进DEVOPS的落地;
-从问题驱动向价值驱动转型,以企业业务发展目标为主线,业务体验、服务满意度、促进业务更好发展;
-从操作运维向运维开发转型,通过为运维人员提供运维开发平台,降低运维开发门槛,快速落地一些紧迫的运维工具,降低操作性、重复性的运维工作;
-从依靠经验向智能化驱动运维转型,结合数据分析、知识库、机器学习技术促进运维智能化。
上二节提到运维体系以业务导向,整体部局,组织、流程、工具三位一体,不断审视优化的建设思路,也提出了”主动精细化“、”价值驱动“、”运维开发“、”智能化运维“的转型目标,我们再将这些思路分解到组织、流程、工具的建设中,并归纳为:三大建设,十个文化的实践方法:
组织建设:专业化、精细化、运营化
我们将运维实施主体运维组织理解为组织,理想情况下,优秀的组织应该具备有合适的工作、合适的时间、合适的人、合适的行为四个要素组成。即组织要结合企业实际发展方向,制定符合企业、运维组织、个人发展的工作内容,并选择具备合适的知识、技能、认知、能力的人去完成工作,去实际个人的自我价值。
前面也提到,目前的运维织是一个被动保障业务系统运行,日常计划性工作容易被打断、搁置的工作,这种工作状态下的运维组织往往工作效率不高、容易出现操作风险。为了让运维组织具备可持续改进的能力,需要提高运维组织的工作效率,我们需要将运维工作专业化,整合通用性、操作性的工作,提高工作效率,在释放运维人员工作量后,引导运维人员有计划、可量化的去做更多分析类、优化类、业务运营的主动性工作。
流程建设:标准化、可视化、可量化
大部份运维组织会以内部企业积累的规章制度、外部监管机构的监管要求为基础,依照ITIL、ISO20000、ITSS.1、DevOps的方法论中的一个或多个组合的方式开展运维工作。这些规章制度、监管要求、方法论的整合、落地、持续改进的过程即为流程建设的过程。
流程建设首先需要标准化流程,要先梳理好己有的流程制度,约定工作的流转方式,再通过可视化将流程整合在日常工作中,最后通过流程落地数据的分析与工具建设,持续改善提高流程落地的效率,控制操作风险。
工具建设:自动化、数字化、智能化、服务化
工具的建设也以可持续改进的思路构建,以整合存量资源、引入成熟或开源技术为主,建立一体化的运维工具体系,通过体系化的思路实现运维工具(“监、管、控”)的互联互通,有序建设,实现自动化运维,全面控制风险、提高工作效率、释放人力;通过建立运维数据分析平台,实现数字化运营,提供运维数据集中与治理、主动分析的能力;在数字化运营的基础上通过运维数据挖掘、学习,优化运维或运营场景,向智能化发展;服务化则是以IT服务的方式将运维能力向处输出。
个人公众号:“运维之路” ,欢迎大家交流!
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞15
添加新评论2 条评论
2022-01-02 16:59
2021-04-25 22:37