运维挑战:如何构建复杂环境下的适应性系统

网友投稿 1215 2022-10-04

本站部分文章、图片属于网络上可搜索到的公开信息,均用于学习和交流用途,不能代表睿象云的观点、立场或意见。我们接受网民的监督,如发现任何违法内容或侵犯了您的权益,请第一时间联系小编邮箱jiasou666@gmail.com 处理。

运维挑战:如何构建复杂环境下的适应性系统

“我们渴望构建一种能够描述市场、顾客及组织等世界万物的模型,并利用它为未来制定完美的战略。但很不幸,那是做不到的,而且永远做不到。未来具有VUCA特性,即波动性(volatility)、不确定性(uncertaninty),复杂性(complexity)和模糊性(ambiguity)。没有哪个哪个模型能够永远适用,相反我们必须保持敏捷、行动迅速,培养创造性思维,接受敢于尝试的文化。”

----(彼得 汉森)

所幸,人类社会一直在遇见问题、解决问题、适应环境的一个能力螺旋上升中发展。比如,牛顿的物理定律虽然解释了从星球运行到苹果落地的所有事情,但无法解释非常非常小或速度非常非常快的事物,所以人类发现/产生了量子力学和相对论。在金融企业,为了应对环境、市场、政策、业务的变化,信息技术发展经历了电算化、信息化、数字化转型三个阶段发展。站在数字化时代,从运维体系角度看运维适应性系统,它包括了大量系统部件,比如各类不同角色的人、团队、软件、硬件等,部件之间通过越来越复杂的技术架构、业务逻辑、协同关系串起来形成复杂的协同网络,为了保障运维适应性系统能够稳定、高效、安全,运维组织一直持续推动单节点的可靠性、可用性、适应性,同时利用“整体大于局部之和”的思路去实现更加完善的协同网络,达到支撑企业转型传递下来的运维价值创造。

本篇尝试从复杂与适应性系统相关内涵、运维面临的复杂性因素、如何建立运维适应性系统3个角度提出相应观点。

1.2.1 关于复杂

在数字化转型理念大行其道的今天,我们经常会听到“复杂”、“不确定性”等词,所以在开始进入运维体系适应性系统前,先聊点还原论、复杂学、适应性系统的事情,让我们可以更好的理解这些名词背后的意义。

还原论,百度百科的定义是:还原论是一种哲学思想,它认为复杂的系统、事物、现象可以将其化解为各部分之组合来加以理解和描述。还原论思想认为世界的本质在于简单性。可以说还原论是我们工作及生活中最基础的思维模式之一,是因果关系的极致反映。现实中,我们一直致力于让自己工作与生活能更加简约、单纯、有序,比如我们描述技术方案时,会分解为“痛点分析、政策或业务背景、调研分析、目的与目标、整体解决方案、技术方案、关键技术、投入产出、短期计划、中长期展望”的方法;在产品设计时,会分解为使用的用户旅程分析、客户价值主张、精益创新等方法;在工具的使用上,我们 使用的结构化思维的思维导图等等。

但是,随着人认知的不断前行,环境复杂性不断加大,越来越多的问题无法简单用还原论的因果关系、分解描述解释。比如单摆与双摆,单摆可以完美的用重力学理论得到验证,有一个规律性轨迹,但是在单摆下再加一个单摆形成双摆之后,它的轨迹变成这样(点播放看轨迹):

与双摆轨迹类似的,大家可能听过蝴蝶效应一词,是美国气象学家爱德华·洛伦兹在1963年在一篇提交纽约科学院的论文提到(来自百度百科):

“一个气象学家提及,如果这个理论被证明正确,一只海鸥扇动翅膀足以永远改变天气变化。”在以后的演讲和论文中他用了更加有诗意的蝴蝶。对于这个效应最常见的阐述是:“一只南美洲亚马逊河流域热带雨林中的蝴蝶,偶尔扇动几下翅膀,可以在两周以后引起美国得克萨斯州的一场龙卷风。”其原因就是蝴蝶扇动翅膀的运动,导致其身边的空气系统发生变化,并产生微弱的气流,而微弱的气流的产生又会引起四周空气或其他系统产生相应的变化,由此引起一个连锁反应,最终导致其他系统的极大变化。

还有像沙丁鱼群、蚁群、人体免疫性系统等都呈类似的复杂性。百度百科对复杂科学定义如下:复杂科学是研究自然界中各类系统复杂性的一门科学,专指复杂系统中的复杂性,研究复杂系统在一定规则下如何产生宏观有序的组织和行为。复杂性有非线性、不确定性、自组织性、涌现性的特性,我们运维经常提到混沌测试中的“混沌”属于复杂性科学的一个表现,初始条件的一点点变化,造成结果巨大影响,导致系统不可预测。

当然,复杂科学不仅仅是对简单还原论的否定,而是为了针对社会中复杂性,提出在复杂环境下提高洞察能力、决策效果的系统性分析方法。或者说,复杂的系统,仍然体现秩序,很多复杂性中存在“在不存在中央控制的情况下,大量简单个体自行组织成能够产生模式、处理信息甚至能够进化和学习的整体”。复杂适应系统具有适应性,因为个体和集体的行为会随着微观事件或事件集合的发生而进行变异或自组织。复杂适应系统可以看做是“相似且部分连接的微观结构”形成的“复杂宏观集合”,可以适应不断变化的环境,提高作为“宏观结构”的生存能力。

接下来我们看看VUCA的四个特性含义。波动性(volatility)是指企业或生活将面临越来动荡、干扰越来越多以及波动性不断增长;不确定性(uncertaninty)是指我们不确定客户、业务、市场会发生什么变化,就算是原来相对确定的事情也会衍生大量不确定的应对行为;复杂性(complexity)是指一件小事可能会产生巨大影响,而且这些小事的输入因素越来越多;模糊性(ambiguity)是指事物并非只有一个答案,或非0即1。针对VUCA的特性,行业通常会为IT提出能力提升的要求,比如:以客户为中心,以价值创造为核心,加快速IT交付速度,提升协同的敏捷、提升支持业务创新效率、加强技术创新引领、建立试错的文化、建立协同网络等。

对还原论、复杂学、复杂适应性系统、VUCA的介绍,不是为了否定还原论,相反目前看运维体系的各个组成部分仍是遵循因果关系的还原论;也不是为了说明复杂与不确定性的存在,而是希望借助更为系统性的方法论,站在整个运维体系角度分析各个运维体系参与元素的作用,更好的利用“整体大于局部之和”的思路去实现更加完善的协同网络,以此更加从容的应对企业数字化转型过程中产生的新挑战与新机遇。

1.2.2 运维适应性系统面临的复杂因素

企业运维体系的发展,是一个不断从“组织、流程、平台、场景”四个维度不断适应IT环境变化的过程,整个过程形成了一个IT世界的适应性系统。

在上一篇关于企业数字化转型下运维关键价值创造的文章中,我提出了围绕“提高业务连续保障水平”、“提升业务交付效率”、“辅助提升客户体验”、“提升IT运营服务质量”四点推进相应工作。本节中从价值创造角度分析一下运维适应性系统的入参有哪些复杂性因素。

价值1:业务连续性保障

上一篇我用鱼骨图梳理了影响业务连续性的要素(见下图),可以看到影响业务连续性要素很多,且这种影响要素随着业务发展、外部政策变化、企业内部转型战略与举措实施将会不断扩大。

以技术架构的演进为例。以往金融企业的架构主要以单体烟囱式架构为主,这种架构系统逻辑简单,开发设计灵活,短时间即可快速上线。但是随着业务需求变化、系统数量增加、系统间上下游链路增加,企业技术架构向服务化架构转变,服务化又从SOA向微服务方式演进,具体实现上则从集中式ESB向每个服务都引入ESB部分功能转变。可以看出,虽然我们在分布式软件架构层面强调软件能力重用、业务抽象、去耦合、平台化、标准化、自动化,但是对于运维而言,服务化架构的变化不可避免的应用链路节点增加、逻辑关系更加复杂,让运维面临更大挑战。为此,运维需要推动运维组织能力前移,优化工作流程,建立更加复杂的工程能力,比如自动化发布系统、持续增强监控体系、加强故障发现能力、探索数据分析能力,构建弹性伸缩的基础设施能力等。

价值2:提高业务交付效率

对于提升业务交付效率,在运维侧可以利用运维数据分析辅助业务决策、推进devOps中的自动化发布能力、云化基础设施、建立系统退出机制等手段。这些手段的引入,相应的也增加了运维复杂性。以devOps为例,devOps的出现主要是来源于业务部门对软件产品或服务交付速度要求,更多的是站在提升研发管理效率提升角度的解决方案,对于测试或运维则更多是对原来质量、业务连续性保障工作方式的冲击。这里的冲击不仅是运维基于devOps最佳实践的理念在流程、工程项目角度进行建设,而是一整套文化、组织、流程、工具、技术架构的全局建设是否就位。由于很多企业只引入devOps目标,并没有考虑现有底子水平或缺乏全局性的能力建设,导致devOps效果不佳。为此,为了有效落实devOps,运维需要建立集中式的IT基础设施、持续发布的自动化发布工具链、针对互联网系统建立灰度发布能力、补充更加敏感的运行状态与业务运作的感知、利用运行数据反向推动应用技术架构的解耦、调整运维协同的组织架构以及敏捷文化的学习等一系列工作。

价值3、4:辅助提升客户体验、提升IT服务质量

提升IT服务质量或辅助提升客户体验,重点是让运维团队由原来以被动保障的工作思维向主动型的工作思维转变,比如加强客户体验数据分析、加强性能管理能力、模拟客户行为操作监控、混沌测试、建立服务质量管理机制与在线服务交付能力等。这些工作对于现在运维团队而言,是对组织能力、文化思维、角色定位、管理流程、平台能力的重塑。运维需要在现有人力资源基本不变的情况下进行价值创造,就必然涉及让现有运维人员想尽办法让自身从原来简单、重复性、操作性的工作中释放出来,深入到业务层面,借助平台工具、运行数据分析等能力实现能力提升。

通过分析上述四个运维价值创造所面临的复杂因素挑战,我来总结一下运维体系的适应性系统的影响因素(或运维挑战),主要包括以下几点:

技术架构:业务迭代需求、商业模式创新、技术创新等因素,驱动IT能力的持续提升,带来新技术与新架构模式的引入,运维在新技术选择时机、技术成熟度、架构及数据高可用的评估能力、对存量技术架构的影响,以及新技术附带的选择成本等挑战。应用逻辑:越来越复杂的业务逻辑关系、更细粒度的原子服务、外部监管政策要求的风险控制要求等因素,驱动业务逻辑越来越复杂,呈现动则生变的常态化风险,以及新风险引发的组织人员对应用逻辑知识掌握、产品设计、性能容量评估、故障应急、快速恢复、影响分析、故障定位等能力的新要求。变更交付:在线感知客户体验、更快的产品或服务创新、更快的迭代速度、更短的技术评审时间、更复杂的版本管理、无序的变更计划等因素,驱动运维采用更全面的技术平台的建设,交付协同模式的变化,绩效考核的调整等新要求。海量连接:移动化、物联网、开放平台等新业务模式的引入,以及全数字化协同网络的产生,带来海量的数据、海量连接、海量终端,每个连接节点之间在线连接质量以及节点的可用性都将大幅增加运维业务连续性保障的范围,甚至重塑运维业务连续性保障定义。操作风险:外部网络攻击形势、政策法规要求、应急操作管理、应急处置能力、运维操作性工作量大幅增加等因素,带来更多的操作风险。应对更多操作风险带来了更多的自动化工具,自动化工具的引入又带来新的操作风险,以及人员操作技能下降带来的风险。协同机制:devOps、一切皆服务、应用运营等工作模式变化,带来新的协同机制的建立,如何选择合适时机,有节奏的推进组织、流程、平台有序建设,考验运维体系建设者的全局设计与落地能力。技能与文化:新需求、新技术、新机制带来新知识,组织面临建立新的学习型文化以更快适应变化,以及学习型文化对现有人员角色重塑,能力培养等配套机制。外部因素:政策及监管趋严、全线上在线监管等因素,驱动IT运维精细化能力不断提升,需要在现有人力资源基本不变的基础上,分离更多资源进行精细化能力的建设。

上述8点复杂性要素每一点都能扩展出更为细化的影响因素,任一个因素的风险事件都可能导致运维体系的重大事故。所以,我觉得运维体系具体组成部分遵循因果关系的还原论,整体上呈现复杂性,需要利用复杂性适应性系统方法,用“整体大于局部之和”的思路去实现更加完善的协同网络。

1.2.3 如何建立运维体系的适应系统

1、以螺旋上升方式建立运维体系的适应系统

站在运维体系这个适应性系统看,包括了大量系统部件,比如各类不同角色的人、团队、软件、硬件等,这些部件之间通过越来越复杂的架构、逻辑、协同关系串起来形成复杂的协同网络,为了保障这个运维适应性系统能够稳定、高效、安全,我们一直持续推动单节点的可靠性、可用性、适应性,同时也希望更好的利用“整体大于局部之和”的思路去实现更加完善的协同网络,达到支撑企业转型传递下来的运维价值创造。运维这个适应系统我借鉴亚马逊价值增长闭环思路(如下图),在这个闭环中的中心是亚马逊零售业务增长的点,业务增长后带来更低的成本,再带来更低价格,又会带来体验、流量、卖家、选择的闭环,是一个螺旋上升的增长能力。

类似的,可以建立一个IT运维能力螺旋上升的适应性系统,即主线是运维能力的持续提升,能力包括业务连续性保障能力、应用交付效率、辅助客户体验提升、提升IT服务质量的综合能力提升。能力的提升来源于更高(质)、更多(量)、更快(速度)的需求驱动;为了适应新的需求,运维组织快速引入新的技术与新方法;改变通常会产生新的风险;综合优化组织、流程、场景、平台能力,解决风险,形成适应性能力;建立了适应性能力后可以支持更高、更快、更多的需求(这个闭环不一定从需求开始,也可以从其它节点开始)。这个能力螺旋上升的能力围绕需求(need)、改变(change)、风险(risk)、适应(adapt)4个节点循环,适应性系统的关键要素是组织、流程、平台、场景。

这个运维体系的适应性系统,可进行分解,以云原生架构为例:

需求:充分发挥云计算的弹性、灵活、自动化优势,使得工程管理和基础设施管理变得更加高效和自治,从而将精力集中到业务创新之中。改变:优化应用的开发架构,容器化基础设施架构建设,加强微服务治理效率风险:新技术引入的时机是合适,新技术不成熟度带来的风险,原有系统改变带来风险,混合云环境和各种跨云/跨平台的运维操作,更加复杂的上下游链路关系适应:运维人员对云原生能力技术及应用上下游关系链路的技能学习,打造云原生的技术中台及配套的协同机制,优化devOps流水线的持续发布能力,云上的监控能力,针对容器PAAS平台的监控能力,自动化全链路的监控及故障发现能力,混沌测试能力等建设工作,形成一个针对云原生运维的工作场景。

2、数字化时代运维适应性系统解决方案的一般性选择方向

虽然说适应性系统根据输入条件不同,而采用不同的应对措施,但在数字化时代,还是可以总结一些一般性的选择方向,比如(以下简述几个方向,具体的内容在后续章节细化):

(1)业务为中心

应用上云解决了运维在基础设施层面的工作量,运维平台能力建设降低了运维操作性工作,这些能力建设一方面是让运维能够更具更稳、更快的技术能力;另一方面是为了让运维能从低价值的操作性工作中释放出来,能够更贴近业务、理解业务,利用运行数据的分析,提升业务连续性及客户体验,确保运维价值交付链路更加高效。围绕业务为中心的思路尤其适合金融企业运维团队,因为金融企业运维团队人员流动性较少,优点是适合业务经验的沉淀,缺点是不适合技能上进行大幅度的转变。所以类型google以运维开发为主的SRE团队可能并不适合金融企业,而应该为金融企业打造一个围绕以业务为中心的SRE团队,不断加深运维SRE对业务的理解,利用组织、流程、平台、场景能力建设,落实“提高业务连续保障水平”、“提升业务交付效率”、“辅助提升客户体验”、“提升IT运营服务质量”的价值创造。

(2)自组织驱动

要达到自组织驱动是要建立一个柔性的组织架构,关键要建立学习型文化与组织持续改进的方法论。前者是在组织内建立学习、分享、沉淀、应用的学习闭环;后者是在组织内形成一个清晰、统一、可理解的持续改进方法论,要让方法论能快速融入到组织各个角色的日常工作。同时,组织还要加强横向优化型岗位,落实数字化的目标管理、计划管理、时间管理、绩效管理。

(3)一切皆服务

云的自助式,所见即所得,按需获取,量化服务成本等特点,已在IAAS、PAAS、DAAS上得到验证。XAAS(一切皆服务)是IT运维组织的一个能力建设方向。即,对运维能力标准化,形成服务目录,业务能够像进入电商系统一样,找到自己所需要IT支持的服务,并申请服务,在线获得服务反馈,并利用社交化的手段对服务水平进行评价,推动IT服务质量的持续提升。无论是企业整体战略的以客户为中心,还是一切皆服务的IT服务目录思路,都是以人为本的延伸,利用线上化、自动化的技术提升在线体验质量。

(4)自动化一切

自动化一切是将事件驱动思维模式融入到运维的方方面面,可以从思维、技术两个角度发力。思维角度,即运维组织从一线操作、二线运维、管理岗位,能够对重复性、操作性工作有天然的排斥感,并想方设法用软件方式代替手工操作。技术角度,一是从运维工具层面建立以运维原子脚本、编排任务、调度的基础的自动化操作能力;二是将运维手工操作标准化,线上场景化标准的运维操作,对标准化可脚本执行的操作自动化;三是从运维工作前移,推动应用系统自身自愈或无人值守的可靠性设计。

(5)数据赋能

数据赋能作用主要体现在利用运行数据,获得即时业务及运行状态的感知能力,建立自动化或半自动化的决策能力。具体来说,一是要实现运维协同网络工作的全在线,落地IT运营数据资产,利用运维数据平台强大的计算能力与平台扩展能力,实现数据的采集、传输、存储、处理、治理、反馈、消费的闭环;二是变现运维数据资产,将数据融入到IT运维工作场景中,为运维提供数据驱动的工作能力,包括实时感知系统运行状态,业务状态感知,IT团队协同效率,业务部门的真实需求等信息,辅助决策,形成高效的执行力等;三是实现利用自动化技术,提供人机协同的模式,将可量化、可衡量、可程序化的工作由机器辅助人处理。

(6)场景在线

场景在线,一是要场景驱动,以场景的人、事、时间、协同、环境5要素,配置组织、流程资源,整合“监管控析”的平台能力;二是要在线,在线不仅是线上化,还强调即时协作、随时连接、落地数据资产。

1.2.3 本章小结

1、数字化时代面临VUCA四个特性。

2、运维体系具体组成部分遵循因果关系的还原论,整体上呈现复杂性,需要利用复杂性适应性系统方法,利用“整体大于局部之和”的思路去实现更加完善的协同网络。

3、运维的适应性系统的复杂性输入参数包括:技术架构、应用逻辑、变更交付、海量连接、操作风险、协同机制、技能与文化、外部因素。

4、建立一个IT运维能力螺旋上升的适应性系统,即主线是运维能力的持续提升,螺旋的闭环包括需求、改变、风险、适应。

5、一般性选择方向:业务为中心、自组织驱动、一切皆服务、自动化一切、数据赋能、场景在线。

end。

下一篇:1.3 数智万物下的关键词

上一篇:58怎么玩数据库架构(upyun架构与运维大会速记)
下一篇:运维常见安全问题汇总及剖析 By 乌云
相关文章

 发表评论

暂时没有评论,来抢沙发吧~