购买
下载掌阅APP,畅读海量书库
立即打开
畅读海量书库
扫码下载掌阅APP

Chapter 8
第8章
数字化运维思维模式

思路清晰远比卖力苦干重要,心态正确远比现实表现重要,选对方向远比努力做事重要,做对的事情远比把事情做对重要。

——李嘉诚语录

因为思维模式不同,同一件事不同的人做,结果也会截然不同。思维模式的定义是:思维借以实现的形式,比如概念、判断、推理、证明是不同的思维形式。用通俗的话讲,思维模式是观察及处理问题的方法,通常会决定一个人的认知与行为。数字化运维不仅是技术平台、流程、组织架构、岗位能力的重构,还需要组织文化的改变。好的组织文化应该能够推动组织或员工的好的思维模式的形成,而好的思维模式又可以辅助组织数字化的落地。

8.1 主动运营思维

相比传统运维主要以“数据不丢,系统不宕”定义的IT运维为目标,围绕“控底线、优服务、提效能、降成本”的主动运营思维,能够更全面、更准确地实现企业与IT系统的核心价值。

1.IT运营

运维英文单词“Operation”翻译成中文是运营,运营比运维的含义更广且更符合企业的价值创造。很多运维组织提出从运维到运营转型的思路。从定义看,运维领域的运营属于企业内部管理方向。

前进保险是美国一家知名的汽车保险公司,1991年公司的销售额是13亿美元,2002年是95亿美元。分析师发现近7倍增长的主要原因并不是产业迅速增长,或开发了一个很好的保险产品,或雇用了强大的销售团队,或收购了其他市场,以及大量投放广告……真正的原因是前进保险有更好的运营管理模式,提供的产品价格更低、服务更好,把顾客从其他对手那里吸引了过来。比如它引入了“立即响应”理赔系统,即更快到达现场,更快理赔,因为理赔更快,索赔人不用多费口舌就能得到服务,可以减少因不满意而解除合同的情况,服务周期缩短也降低了成本。同时更快的理赔推动了现场理赔检测欺诈能力的提升,参与理赔的人少了,甚至索赔金额也降低了,因为索赔人更快得到赔偿的同时也会接受较少的赔偿金。

从前进保险公司的例子可以看到,运营管理主要目标可从提升业绩、提高效率、降低成本、提高服务水平、控制风险等多角度开展,即控风险、提效能、降成本、优服务、促体验。参考企业运营管理的概念,将企业运营管理的“质量、效率、成本”三要素应用于运维管理领域,可以为IT运营归纳一个定义:以业务为本,以稳健运维、风险可控为底线,从组织、流程、工具、场景四个维度构建一套标准化、可扩展的运维管理体系,持续提升服务水平,提高企业效能,降低成本。接下来以IT运营的“控底线、优服务、提效能、降成本”4个关键目标为主线介绍主动运营思维。

2.控底线

所谓底线,即超越了这个界限,事物就会发生质变,产生不可估量的危害。运维组织是企业业务连续性保障部门,业务中断或体验下降都预示着企业面临资金损失、用户流失、监管考核等风险。运维组织最重要的是守住基本底线,再考虑在底线基础上追求“高线”,即需要先有底线思维,明确哪些工作是组织必须达标的,再考虑服务、效能、成本。从IT运营角度看底线的管控,要了解哪些工作是底线,哪些基础设施与信息系统是关键对象,加强底线工作精细化程度。当然,底线管控并不代表运维组织被动应对,而应以奋发向上的积极防御思维,从底线发力,通过工具建设更好地落地底线工作,将部分人力从底线工作中释放出来,去追求IT运营的“高线”。某银行数据中心以“业务为本、运行可控、数据不丢、系统不宕”为根基,很好地说明了底线思维在运维组织中的重要位置。控底线可以考虑从以下工作出发去推进。

健全流程机制 :包括问题解决过程管理机制、服务交付管理机制、关系过程管理机制、控制过程管理机制,以及生产系统稳定性相关的管理机制。

可用性架构保障 :包括数据备份的可用性、备份环境的可用性、架构高可用性、应用架构可靠性等。

应急保障 :包括应急预案、监控发现、应急演练、应急操作工具、应急协同机制与工具等的完备程度。

常规例行保障 :包括常规巡检、监控响应、变更交付、IT服务请求响应、问题过程管理等工作的落实。

IT风险保障 :包括保障数据安全,防止信息泄漏,强化对信息资产的保护,确保业务稳定持续运营,提升业务创新与合规的落地能力等。

3.优服务

运维组织以IT服务输出形式,为企业非IT部门提供IT支撑。优服务即提供更快、更好的服务交付体验。不同岗位的运维人员需要根据岗位特点主动丰富服务内容,并通过工具提升服务体验。优服务要先从IT服务的广度扩大IT服务范围,再从IT服务的深度细化服务内容(细化服务内容有助于服务标准化),并通过工具辅助服务落地,为用户提供数据化体验。

建立主动服务文化 。一线运维人员的工作主要以事件驱动的被动式为主,服务消费方需要自己找到具体运维人员处理。这种被动式工作通常效率低下,服务交付碎片化,IT资源缺乏统筹协调,无法形成合力。作为企业里的后台服务团队,运维组织为企业的业务、应用、所有中前后台人员提供IT服务,需要强调主动服务的意识,建立主动服务文化。

丰富服务内容 。丰富服务内容的广度与深度,服务广度即服务类型数量的增加,服务深度即服务质量的提高。在广度上,运维组织需要进行服务梳理,比如用户类、数据类、资源类、办公支持类、权限门禁类、资产管理类、运维开发需求类、自助服务请求类、其他常规工作类等,梳理服务后用服务目录进行整合。在深度上,运维组织需要持续对服务能力进行总结,梳理从服务申请到交付整个过程的最佳实践,将经验标准化,寻求更高效的解决方案。

将服务线上化 。在人力资源基本不变的情况下,既要提供更多的IT服务,又要提高服务质量,就需要服务线上化,提高存量人力资源的单位产出。服务线上化通常需要先梳理组织能够及需要对外开放的服务,将相关服务标准化,再将标准化服务通过自动化或自助方式上架到服务目录,并线上化管理服务的交付。

形成服务持续优化 。优服务是一个持续改进的工作。判断服务是否需要进行优化,需要建立服务质量可量化的相关数据指标体系和可持续优化的机制。

4.提效能

效能的定义是:有效的、集体的效应,即人们在有目的、有组织的活动中所表现出来的效率、效益。效率是指单位时间完成的工作量,需要提高运维组织中每个人的工作产出,或利用IT服务提高企业其他组织的工作产出;效益是指一项工作的成效,即提供了正确的服务,服务的产出符合企业发展目标,且服务的效果可量化。提效能需要从“做对的事”和“用正确的方法做事”两个维度推进。

做对的事 。做为组织产生真正效益的事,比如运维组织的生产保障底线工作的落地、为业务人员提供IT资源服务、为业务人员提供IT运营分析服务。为确保做对的事,运维组织需要结合运维在企业中的价值创造有针对性地选择正确的方向,再统筹建设,保持团队向心力。以平台建设为例,企业很容易采用百花齐放、烟囱式的建设方式,这种建设方式虽然能快速满足短期运维需求,但由于不具备扩展性,当规模增大时平台往往会成为负担。所以,平台研发团队要兼顾全局目标与短期需求,制定一个可持续的解决方案。

用正确的方法做事 。提效能涉及对内与对外两方面。对内,工具的使用可以大大提高运维效率,比如操作自动化是模拟人日常工作的动作,减少重复性运维操作,代替针对大量运维对象或海量数据计算的重复性运维操作。对外,为运维组织外的研发、测试,以及业务部门提供IT资源支撑,一是要更快地满足消费方对工作效率提升的具体诉求;二是主动挖掘影响工作效率的因素,主动提供提高工作效率的解决方案。在提高对外工作效率层面上,运维组织有资源与技术优势:一方面运维人员接触生产,有生产运行第一手资料;另一方面相比业务人员,运维人员更懂计算机,知道什么样的工具或功能优化是能做的。企业要推动运维人员找业务人员沟通,将业务人员在业务效率上的痛点转化为IT运营服务需求,比如建立与业务部门同事的沟通机制,利用生产运行数据分析潜在影响效率的环节等。

5.降成本

在IT项目生命周期中,大约80%的时间与IT项目运维有关。有效的成本管理将是IT运营的重要工作内容。运维组织在企业中是后台支撑部门,是偏成本的部门,因为运维涉及各类成本,包括:

硬件资产类成本,比如机房、电、硬件服务器、服务器内的资源、运营商带宽、公有云IaaS服务等。

软件类成本,比如系统软件、数据库、中间件、应用系统的维保、许可等。

运营工具项目建设成本,比如监控、ITSM、日志工具等项目建设成本。

人力资源成本,比如运营组织内部人员、关联供应商、外包合作方的人力成本。

对IT运营成本管理是指在保障企业业务稳定、安全、有效运行的基础上,通过规范IT运营、优化资源配置、提高运营效率,达到降低IT运营成本的目的。但运维成本管理存在以下难点。

运维组织定位不明确,缺乏对中长期成本管理的规划 。业务人员在使用饮水机、打印机、电话、电脑过程中遇到问题,运维人员是否要支持?是否和电有关的问题都可以找运维人员?这类工作如果做当然能提高IT服务满意度,但安排运维这类专业性较强的员工做这类琐碎的工作,投入产出比并不高,这类工作更适合由物业或后勤专职人员去做。之所以出现花大力气做这种不擅长工作的问题,主要原因是对运维组织的定位不明确,成本管理优先级不清晰。另外,很多企业的成本核算是采用谁支出谁负责方式,这导致IT资源投入比较零散,很难进行整体优化建设。这种“头痛治头、脚痛治脚”的资源管理模式看起来短期内支出少,但长期看来会导致大量资源浪费,成本更高。

缺乏成本管控的标准化流程 。前面提到运维组织以IT服务方式为企业提供IT支撑,需要有完善的服务流程,可对服务的申请、受理、交付、反馈进行整合。但很多运维组织因为数字化程度不够高,标准化流程不够多,管理层的精细化要求无法有效落地,IT人力资源成本居高不下。以问题咨询为例,很多应用运维人员每天被各类临时问题所困扰:一方面无法集中精力做计划性工作,主要做一些治标不治本的事情;另一方面容易形成信息孤岛,工作效率与质量无法量化。同时,专家式处理方式缺少明确的升级标准、合理的故障优先级机制、问题持续跟踪与优化机制,导致服务满意度下降。

缺少成本分析与优化工具,无法量化并提升成本管理水平 。要做好成本管理,需要有反映成本的数据,并有实时成本与历史成本交叉比较的工具。由于很多运维组织并没有建立成本分析工具,而是通过专家粗略的估算进行成本管理,很容易出现成本预估过高或不足的问题,无法直观、准确地量化实时成本与历史成本,也就无法有针对性地进行成本优化。

结合上述困难,在降成本方面,企业需要做好以下工作。

明确运维组织定位,整体规划,提高数字化程度 。从企业发展方向与技术能力角度,明确运维组织的定位与建设目标,匹配适度的IT资源投入,从管理与技术两个角度进行整体规划,选择合适的落地方式。数字化程度的提升需要管理与技术双管齐下,将管理手段平台化、技术手段指标化,让不同角色的人具备全局把控和局部深入的能力,比如将运维组织关注的服务响应时间、可用率、故障处理时长、服务工单数量、业务用户满意度等进行量化,将量化数据作为绩效管理的参考值,推动运维组织持续提升IT运营水平。

专业化分工,标准化IT服务流程 。面面俱到的专家式运维会导致工作出现瓶颈,沟通成本过高,因此须根据团队规模适当地进行专业化分工。专业化分工以“纵向+横向”的管理方式进行,纵向的职能型团队负责延续各专业线的主要职能,横向的项目型团队集中资源负责支持并推动职能型团队提高工作效率,提高效益。专业化分工有助于专项成本优化,比如负责IT资源平台的团队建设资源交付与管理工具,负责具体资源交付的团队基于平台提供的能力加快资源交付,同时通过平台评估资源使用情况,有针对性地进行资源成本优化分析。专业化分工的同时,需要建立标准化IT服务流程,确保IT运营工作有序高效地落地。针对标准化IT服务流程的选择,企业可以考虑以传统的ITIL、ITSS等为基础,结合自身文化特点个性化调整,在实践中不断完善日常工作机制,比如针对生产问题管理的痛点,考虑设立IT运营服务台,将运行值班、故障监控、接受请求、工单派发及问题解决过程中的监测等工作内容集中在服务台。这种流水线式的工作一方面将部分运维人员从被动式工作中分离出来做计划性优化工作,另一方面有助于经验的积累,丰富知识库,集中资源进行服务优化工作,提高工作效率与服务质量。同时,这种工作方式也可以打通原来的信息孤岛,实现信息共享、文档管理,降低因个别人员流失导致组织服务能力缺失的风险。

有针对性地进行成本分析,持续优化成本管理 。成本优化需要工具的支持,如自动化工具的引入可以替代运维人员重复性工作,提升单位人力产出,弹性的IaaS与PaaS平台有助于硬件资源的配置。另外,组织还要推动成本优化文化建设,鼓励或奖励专业条线的运维人员主动进行有针对性的成本分析,评估成本支出趋势,推动成本优化,比如应用运维人员可以分析IT资源与网络带宽的使用情况,评估是否可以缩容,甚至可以从应用架构或设计角度评估优化资源方案的可行性,比如采用CDN减少网络投入,用互联网访问替代专线,采用微信或消息推送减少短信费用的投入,优化图片格式减少带宽使用等。

由成本中心向效益中心转型 。前面三点是针对运维组织自身的成本优化、服务质量的提升,最后一点从提高投入产出比角度出发。以往运维组织是一个成本中心,这点与业务部门相比尤其突出。针对这个问题,有两个解决思路可以借鉴:一是像腾讯运维团队提到的,通过主动对应用运行数据进行分析,提出优化方案,辅助业务更好地开展,或为业务人员快速构建自动化工具(偏管理自动化),提高业务人员工作效率;二是像一些大型金融企业一样建立行业云,以多租、资源集约模式为同业输出IT服务,或建立集团云或平台体系,为子公司提供IT服务支持,扩大IT服务范围。

8.2 事件驱动思维

事件驱动思维对于运维组织管理是一大利器。很多工作将内部或外部生产故障、IT风险事件、合规管理、外部监管、公司政策、公司领导决议等作为触发因素来推动组织机制快速落地。

1.软件领域的事件驱动

软件层面的事件驱动是指在持续事务中,决策生产者以触发事件方式,将事件信息或决策信息发布出去,应对事件的消费者获得信息后进行具体的事务操作执行。理解软件工程层面的事件驱动,能够让运维组织更加理解事件驱动的内涵,并借鉴软件工程上的抽象总结,用事件驱动串联起多个运维工作场景。

在软件领域有事件驱动架构(Event Driven Architecture, EDA)。Gartner将EDA定义为“一种设计范例,软件开发组织响应收到的一个或多个事件通知并执行”。由于事件驱动具备更好的扩展性,可以平衡代码的可维护性、性能和扩展性,伴随着万物互联时代海量终端传感器与数据的增加,事件驱动能很好地契合这样的场景。

比如,当我们在路边打开打车App时,App就会触发很多事件,比如定位你的位置、获得目标地址、查找附近车主与车辆定位、推送车主信息、实时反馈车辆位置、路线信息、行驶过程中持续监控路线情况等,事件信息则通过手机、平台交互。采用事件驱动方式,平台决策处理的应用只须向事件总线订阅消息,当新的订单或路况变化时,订单分配与路线修订的应用只须根据事件总线的消息响应执行。而原来的请求方式则需要订单分配或路线修订应用主动去询问订单。在打车这个案例中,EDA的架构带来以下好处。

让用户、司机实时感知订单进度,增强反馈,并加强平台的数字化管理能力。

提高平台应用程序开发和迭代速度,更利于组件封装,做到低耦合和高内聚。

分布式、异步、实时通信,并定义高、中、低优先级的任务响应。

人机协同,可以更快地发现问题,并驱动问题的解决。

从技术平台角度看,在2020年,笔者遇到一个VANTIQ厂商,它提供了事件驱动的平台解决方案,大概思路如下。

边缘终端提供实时采集的数据,并上报事件驱动平台,平台支持海量、实时流式的数据处理;

用户可以在平台采用低代码的方式加工数据,支持编写数据加工脚本,支持在编排过程中即时看到响应效果;

根据数据处理,实现执行环节的事件驱动。

VANTIQ这个解决方案的关键词有实时、异步、解耦、海量连接、海量数据处理,是一种实时分布式流程协同运行方案,主要特点包括:能够受理(推拉)海量事件的实时消息处理,支持数据加工流程灵活编排,支持流程脚本编写,支持规则触发事件的多种响应,支持低代码事件编排与管理,为机器提供服务化的事件驱动服务。

2.运维领域的事件驱动场景设计

运维组织可以参考软件层面的事件驱动模式,设计运维领域的事件驱动场景。以监控告警为起点的事件驱动场景设计思路如下。

基于告警事件触发告警应急处置,包括告警事件后的故障管理、告警不及时响应的时效性管理、告警不及时处理的公示升级、事后告警复盘、告警策略优化等。

如果监控告警识别为故障,触发基于生产故障的事件驱动,包括故障识别、故障申报、故障定位、故障处置、故障恢复、故障复盘等。

故障恢复后,触发故障复盘事件,包括技术架构层面是否涉及架构、功能逻辑的优化,组织层面是否涉及职责不明确,流程层面是否涉及工作规范未执行到位、应急处置协同不畅,平台层面是否涉及监控覆盖面不到位、自动化操作工具遗漏,故障演练、灰度发布、混沌工程等执行到位等。

在复盘架构分析层面,触发技术架构层面的事件驱动,包括系统架构高可用设计、冗余设计、无状态设计、故障隔离设计、过载保护设计、有损服务设计、支/关键路径与关键节点设计,以及可维护性涉及的日志、监控等数据服务输出是否到位,如果涉及关联风险,还要进行问题管理或风险提示。

发现风险问题后,触发事件风险揭示的事件驱动,包括分析事件风险,挖掘潜在风险,建立风险规避机制,触达相关风险处理、阅知人员,并建立持续跟进风险规避任务。

从上面的例子可以看到,事件可以作为运维启动的触发因素。善用事件驱动可以将多个工作场景串联在一起。同时,在工程角度,针对不同场景的工作,借鉴软件层面的事件驱动,让工具接收事件数据,根据标准化事件规则,响应事件决策,并由人或机器进行决策的执行,建立全数字化事件驱动能力。

3.将事件驱动应用于管理

在现代事件管理学科中,事件可以指一套具有既定目标、以独特而相互关联的任务为前提,在某一时限内,集成一定的人、财、物、技术等,开展公众性、社会性、服务性活动。为了推动运维体系的发展,组织需要持续调整架构,优化工作流程,建设技术平台,推动场景的落地。这些工作会给员工日常工作带来改变,而改变容易引发阻力。为了有效落地,组织可以借助事件驱动的事中应对与事后分析来实现,比如:

监管机构传递新的指导意见;

行业其他机构遇到风险事件;

生产故障后的复盘会,尤其是重大业务连续性事件;

合规整改事项;

公司战略转型事项;

公司领导提出的工作指示;

一次重要的工作汇报;

在必经的工作流程节点中加入希望应用的机制。

借助事件驱动思维,应对不确定性危机事件的有效方案是主动挖掘、应对事件。一方面,提前制定相关规章制度,明确角色,收集全面的事件数据,进行风险评估和机会挖掘,与组织数字化生态建立连接,推动事件在系统和人之间进行快速流转,对事件保持敏感并抓住机会;另一方面,在应对事件中,借助事件关注度高、资源汇集等特点,推动组织架构、流程标准、技术平台的落地;同时,在事件复盘中,习惯对事件进行分析,并总结规律,这是惯性思维,在此阶段推动的改进工作更容易得到大家的接受。总之,在一个平淡的工作主线上,要擅于发现事件产生的水花,顺势而为,让水花加大工作成效。

8.3 数字化工作空间思维

数字化工作空间是应对工具零散、流程断点、烟囱平台等建设问题的思维模式,需要以员工日常工作场景为中心,围绕“支撑管理决策、激活员工参与、打通协同壁垒、装备条线运营”4个维度建设,让员工在一个全在线的环境中工作。

1.数字化工作空间

经过多年平台化建设,IT组织不缺工具,缺的是全在线的数字化工作空间。由于工具间缺乏互联,没有形成协同网络,工作人员完成一件工作往往需要切换多个系统,甚至有很多工作只能在线下完成,没有留痕。全在线的数字化工作空间由支撑管理决策、激活员工参与、打通协同壁垒、装备条线运营四个维度构成(见图8-1)。构建数字化工作空间,一是需要关注协同效率,从组织协同上进行优化,优化资源配置,利用ChatOps等全在线的连接工具,强化信息传导机制,促进协同;二是建立数字员工模型,利用在线数据构建更加安全、透明的工作环境,整合员工工作数据,形成员工数字镜像,挖掘优秀员工,辅助员工成长,为IT运营管理水平的持续优化赋能;三是赋能,为员工提供全在线的工作装备,即综合运用线上、社交、移动、自动化、决策等工具实现组织连接、资源共享、低效率工作减少,从而激发员工创新,提升团队敏捷应对能力。

运维数字化工作空间同样可以围绕“支撑管理决策、激活员工参与、打通协同壁垒、装备条线运营”4个维度打造相关工具链。 支撑管理决策 是基于运维管理视角,让管理具备数据驱动的“感知、决策、执行”闭环能力。其中,感知能力指察觉运行生产环境的变化,知晓对哪些生产对象的稳定性造成影响;决策能力指运用算法对实时信息进行运行分析,辅助管理者决策;执行能力指确保传导机制顺畅,决策有序落地。 激活员工参与 是基于员工视角,为一线运维员工提供实时在线的工作体验,让员工方便地获取知识与分享信息,为员工提供自动化、线上化运维工具,将员工从操作性工作中解放出来,促进员工向主动提升能力转变。 打通协同壁垒 是从协同角度,围绕CMDB促进IT资源、工具、流程的整合,解除当前运维组织各参与方之间的连接障碍,将工具互联互通,用更加扁平、透明的方式重塑组织连接。 装备条线运营 是从各专业线角度,为运维人员打造“监、管、控、析”等平台工具,再将专业工具融入全在线工作平台,为员工提供一站式工作体验。

图8-1 IT运营数字化工作空间

2.运维数字化工作空间应用思路

构建运维数据平台,提升洞察力与决策能力 。运维涉及大量数据,具体来说可以分为两类:一类是面向生产环境的系统运行数据与反映业务系统运营状况的数据;另一类是IT服务管理过程中产生的工作流程、程序、文档等数据。这些数据存在结构标准化低、量大,且分散在多个工具系统中等特点。以往,在运维管理过程中,组织缺乏在线洞察运营数据的能力,存在管理决策不够透明、不准确的问题。为了提升管理决策能力,组织需要推动工作标准化、线上化、自动化,不断加强数据的沉淀,并利用大数据平台“采、存、算、管、用”的基本能力落地数据资产价值。利用CMDB落地数据资产配置中心,并围绕“监、管、控”工具链采集生产机器实时运行的性能、日志、系统运营等过程数据。针对数据资产的变现,要在数据洞察方面着手,通过数据可视化手段驱动以经验为导向的工作模式向以数据驱动的工作模式转变。在实现上,考虑利用可配置的数据报告与实时看板,结合实际的工作场景进行数据洞察和分析。

利用IT服务目录,建立所见即所得的IT服务能力 。服务目录的思想来自“云”的思路,即将IT组织能力进行抽象,标准化为IT服务。服务供应方可以采用自组织的方式上架服务,用户可以按需在服务目录上查找自己需要的服务,并进行申请。在服务目录的设计上,为了方便使用,我们可以参考电商系统的设计:当你知道需要什么品牌、什么型号的商品时,你可以在商品目录中找到商品;当你大概知道你想要什么商品时,你可以利用搜索找到商品。所以,服务目录需要包括服务的介绍、服务承诺时效性、负责人、服务处理流程等基础信息,功能上支持用户通过自助式检索申请服务,也可以通过联系IT服务台解决问题。在服务的具体设计上,探索一些体验方面的设计,比如对服务进行打分,服务的在线处理轨迹等功能,提升服务质量。IT服务包括咨询类服务、资源类服务、实施类服务、运行管理类服务、运维研发类服务、综合类服务。

激活职能线上的平台体系 。运维涉及基础设施、服务器、网络、应用、安全等领域,每个领域涉及一些专业化工具。很多金融企业采用商业化产品,且经过多年沉淀,产品已与实际业务融合。重新打造能够覆盖多个专业领域的工作平台并非最佳选择。所以对于专业条线的工具,企业主要是围绕“监、管、控、析”平台,以激活职能线上的平台体系,并基于运维组织的核心价值链在平台体系之上建立场景,在场景中实现平台间的互联互通。

利用时间管理工具,加强员工时间管理能力,提高IT运营管理的执行力 。随着业务的发展,运维成为企业中最繁重的部门之一,员工日常面临各种微信群、邮件的“轰炸”,且由于零散、非计划性工作多,很多计划性工作经常被打断,管理决策很难得到跟进。所以,运维管理需要一个扁平化、可追溯、融入运维场景的工具,一是让员工可以轻松管理自己的工作,实时获知正在处理的工作,量化工作,设置优先级;二是将运维场景工作细化到工作任务子项,推动员工工作全线上化,并以日报方式管理个人时间。时间管理工具要融入运维场景,比如巡检任务、变更流程、每日复盘等都要有任务的要素。

总体来说,数字化工作空间通过提供协同网络,方便运维人员与运维内部跨团队、IT内部跨团队、企业内或外部供应商跨团队,以及生产环境中的软硬件对象、机器人等连接,这样既可按需获取数据信息,保证工作信息安全,还能形成运维工作数字镜像,持续提升运维水平。

8.4 敏捷思维

转型中的企业将会面临“双态”挑战,既要确保当前业务稳健、安全、可靠,又要应对市场快速变化,敏捷高效地进行业务创新,也就是常说的在高速公路上换轮子。运维也面临“双态”挑战,要求运维组织坚守底线思维,在确保业务连续性基础上,满足敏捷交付需求。

1.敏稳双态的由来

在IT领域,国内外都提出敏稳双态的思路。Gartner提出过“双模IT”理念,将IT治理划分为两种模式:模式一强调稳定,能较精确预知,目标是将传统的IT环境进化到数字化环境,更强调可靠性。模式二强调未知的、全新的问题,目标是通过探索、试验来驾驭不确定性,更强调敏捷性。在国内,联想最早提出“双态IT”理念,认为IT可作为支撑企业业务运转的载体和手段。业务的“双态”特征对IT系统建设提出了挑战:一方面,稳态IT主要针对流程固定、行业规范成熟的业务,须采用更加成熟的技术或商业软件与基础设施,重点是风险规避;另一方面,敏态IT主要针对业务创新,探索商业模式,不断试错,须采用开源软件框架等。

2.从《敏捷宣言》看运维

企业价值创造是一个价值传递过程,如果企业数字化转型强调敏捷,那么应通过企业文化传递到运维组织。由于金融企业需确保当前业务稳健开展,且行业对业务连续性要求越来越高,运维组织要思考哪些实践适合标准化、规范化、流程化,哪些实践又适合敏捷化。下面结合《敏捷宣言》看看运维需要关注的点。

《敏捷宣言》

我们最重要的目标,是通过及早和持续不断地交付有价值的软件使客户满意。(注:运维须平衡生产稳定与IT需求交付速度,持续关注IT需求的交付能力建设。)

欣然面对需求变化,即使在开发后期也一样,为了满足客户需求,敏捷应掌控变化。(注:运维需要建立适应性组织,能够不断适应行业政策、生产环境、技术架构、新技术引入的变化。)

经常交付可工作的软件,相隔几星期或一两个月交付一次,倾向于采取较短的周期。可工作的软件是进度的首要度量标准。敏捷中倡导可持续开发。责任人、开发人员和用户要能共同保持步调,让稳定延续。最好的架构、需求和设计出自组织团队。(注:运维需要针对迭代要求高的客户服务类信息系统构建适应性迭代发布能力,并做好灰度发布、监控、应急处置等能力建设。)

业务人员和开发人员必须相互合作。(注:一要推动运维前移,更早地让运维人员参与信息系统建设;二要加强IT服务供需方的沟通协作,提升IT服务质量。)

激发个体斗志,以他们为核心搭建项目,提供他们所需的环境和支援,辅以信任,从而达成目标。(注:做好岗位分工,集中操作性工作,并通过自动化工具减少操作性工作,为员工的创造性工作提供数字化工作空间。)

不论团队内外,传递信息效果最好、效率最高的方式是面对面交谈。(注:建立更加扁平的协同模式,比如基于ECC的应急指挥协同、基于ChatOps提供协同模式等。)

坚持不懈地追求技术卓越和良好设计,提升敏捷能力。(注:持续提升技术架构的可扩展性、高可用性、可维护性。)

以简洁为本,它是极力减少不必要工作量的艺术。(注:标准化工作流程,简化不必要的流程,自动化必要的流程节点。)

团队定期反思如何提高成效,并以此调整自身的行为。(注:打造复盘文化,比如事件复盘、每日工作复盘、变更复盘等。)

《敏捷宣言》中与运维相关的关键词如下:持续交付、接受变化、IT服务、加强协作、架构可扩展性、自组织、不浪费、加强总结。DevOps思想是敏态的一种方法论,持续交付是最常用的落地方法。

3.敏稳双态下的运维

联想提过IT敏稳双态的思想,指出在企业转型过程中,业务将会出现不同程度的双态特征,即确保现有传统核心业务稳健、有序发展的同时,敏捷、高效地尝试拓展新业务。

稳态 :以ITIL、ISO20000等思想为主,流程固定,使用行业相对成熟的最佳实践,技术架构更加成熟。

敏态 :以DevOps思想为主,通常面向创新,需要快速交付客户需求,具有高频迭代、广泛采用新技术的特点。

由于金融企业对业务连续性的高要求,当前稳态运维模式仍是IT运维的主要思想,敏态运维模式的重点是在稳态运维基础上让IT交付效率与速度不断提升。持续交付是敏态运维的一个实践方法,是在持续集成的基础上完成软件构建,不断将软件持续部署到测试、准生产、生产等环境,并在相应环境中进行操作,目标是将软件产品交付给用户,持续交付业务价值。从持续交付角度看,运维一方面需要更好地适应迭代频率,不断迭代变更;另一方面还要提升高频迭代带来业务连续性风险的应对能力。另外,在敏态模式中,运维组织需要在保障业务连续性基础上,更高效地响应业务需求,构建持续交付的工程能力,并推进运维向发布前环节前移。

有人说运维组织属于不喜欢变化、不善于变化的团队。笔者的观点是,在企业数字化转型大背景下,运维组织应该是变得最快的团队。IaaS云颠覆了基础设施建设、硬件团队工作模式,去IOE改变了基础设施、系统、数据库的技术栈,云原生架构改变了业务运维团队的一些工作职能……这一切都引导着运维组织不断建设数字空间。站在敏捷角度接受变化,运维组织需要围绕企业核心价值,从业务角度去提升运维能力,而不应该丢掉越来越复杂的业务层,下沉到越来越标准化、软件定义的基础设施环境。 LLAdRhk/U5hAzSkpWIbi+haqMyl1z5Bemwz5+UGhr1wJq/ZonupHwnrsOpq4IVtn

点击中间区域
呼出菜单
上一章
目录
下一章
×