抵御风险——漫谈运维核心价值和方法论

要明晰什么是运维的核心价值,也就是要弄明白,从整个软件行业运维的角色定位来看,运维的核心价值在哪里?怎样增强自己实现核心价值的能力的问题。

软件产业本质其实还是工业,它的产品和传统的工业产品形态虽然有巨大差异,但其实在生产流程中还是和传统工业有诸多本质的相似之处。如果把软件生命周期看作汽车的生命周期,那么开发工程师就是汽车设计生产人员,负责将汽车(软件)从需求,转为技术设计图纸变为实实在在的产品,主要作用发挥在汽车生命周期的前期。而运维工程师就不同了,运维工程师通常是软件生命周期的中后期才介入的。就像汽车驾驶和维修的人员,而软件用户就像是汽车的乘客。

运维人员要采用一切技术手段和管理手段,保证“汽车”的正常、安全、稳定、高效、舒适的运行,把乘客带向能为公司创收的“目的地”。换言之,开发输出的是有形的产品,运维输出的是无形的服务,即一种为软件消除、控制运行中产生的风险的服务,这和金融领域里“风控”的角色非常类似。所以运维的一切工作和能力建设,都是为了控制风险这个目标为依归。

现在IT行业内运维的工作以机器采购、机房建设、网络规划、系统装机、应用部署、中间件维护、监控处理、自动化运维等多种形态存在,很多人把运维工作看做一种打杂的工作,负责的都是重复又繁杂的工作,甚至很多运维人本身也看不到自身的价值感。

但是,把运维工作的本质理解成一种为软件运行消除和控制风险,就可以很好理解运维工程师为什么承受着这么繁重而且庞杂的工作内容了。开发工程师把软件设计并且开发出来,运维工程师就负责把软件运行好。就像一辆汽车的司机,要把汽车从汽车厂带向正确的方向、一路上规避各种各样的风险,定期对汽车进行检修和保养维护。所以,开发工程师和运维工程师最本质的差别就是,前者生产软件产品本身,而后者围绕前者生产的的产品,提供一系列风险控制的服务。那么,就让我们从风险控制的视角,来思考探究运维工作的核心价值和其方法论。

在软件的“一生”中,就像一个人的生命历程一样,可能面对各种让你猝不及防的风险。只有充分认识风险,才能控制风险。

风险的分类

软件面对的风险多种多样,可以按风险发生的阶段、风险产生的层面、造成的影响大小、导致风险的原因等等不同的维度去划分。为了抓住风险控制这一核心目的,我们就从导致分险的原因这一维度开始着手。

导致风险的原因

先天性风险

所谓先天性风险,主要指的是在软件设计阶段,就存在系统性缺陷引发的风险。需要强调的是,软件设计阶段不仅包括软件的业务逻辑、开发框架、依赖的中间件、数据库,还应包括软件运行的服务器硬件、操作系统、以及网络架构等环境因素。 许多开发者只关注代码的编写,而对软件运行的环境因素知之甚少,甚至不屑了解少学习。任何一个在技术领域有追求的技术人,都应对此保持一种鄙夷的态度,古语有云“不谋全局者,不足以谋一隅”。一个只顾埋头编写业务代码,不掌握软件整体设计逻辑和全部软件生命周期的开发者,终究只配当一个“代码工人”,而无法成长为一个优秀的设计者或者技术leader。

先天性的风险,主要在软件设计阶段,没有经过足够细致周密的技术调研和论证,或者说有些问题,难以在软件上线生产环境之前得到暴露。这很大程度上,就是由于设计软件的技术团队欠缺统领全局的能力。往往这种风险,因为缺乏生产环境那么丰富的业务场景,难以在简单的功能性测试中检查出来。于是,运维往往沦为离这一类风险“最近的消防栓”。但是大多运维工程师没有软件设计的经验,解决起这类问题来也经常显得束手无策。说到底,一个不懂运维的开发团队会给开发“埋坑”,而一个不懂开发的运维团队就不知如何“填坑”。当然,这也是DevOps作为全局“填坑”手段,产生的原因所在了。

变更性风险

曾有幸聆听《SRE Google运维解密》中文版译作者——前谷歌SRE孙宇聪先生的演讲,他演讲中有一个观点让我印象深刻,他说开发的工作目标是对系统进行变更,而运维的工作目标是追求系统稳定,而变更本身就是一种对已有的稳定的系统的破坏。变更就是一种破坏这个观点,可以帮助理解了作为运维角色的很多问题,联系自身,我很快理解当时所负责的版本发布的工作,对于运维角色的意义所在——把变更的风险控制起来。

版本发布只是变更的一种,一个系统变更的元素可以有很多。包括:硬件基础设施、操作系统、开发框架、应用代码、中间件、网络结构、配置文件、数据库。在一个互联网公司,最常发生的变更也最易产生风险的,当要算应用代码、配置文件,以及数据库了。版本发布工程师在发版过程中,往往都要做涉及这三项的变更,可以说版本发布是一项“高危”性质的工作。

控制此类风险,没有什么诀窍,关键就是要减少变更,包括变更的次数和变更的元素和其变化量。但是像版本发布的变更,其变更需求和方案并不是在版本发布过程中产生的,而是在软件需求分析、设计研发阶段产生的,运维工程师要控制其变化量,就只能提前介入到软件需求分析阶段,运维工程师应该争取在项目需求阶段和设计阶段,对导致不可控风险的需求和设计方案,具有一票否决权。

但是在以变化求生存的互联网时代,运维工程师不能成为变化的阻力,在慎重阻挡不合理需求和设计方案的同时,运维工程师更应该给出合理化建议,帮助需求的落地。许多企业完全不让运维参与前期需求评审的工作,认为运维与需求无关这种由来已久的观念,可以说在这个产品迅速变化的时代,已经显得非常不合时宜了。但让人欣喜的是,已经越来越多的企业把运维工程师加入了需求评审会。

还有关键的一点是,在执行变更的过程中,严格制定规范的变更控制流程,杜绝变更方案之外不必要甚至是错误的破坏行为。

人为的风险

传统运维大大小小的事,都需要工程师亲自上阵、手工操作,对人的依赖性非常强。而人的行为能力受知识水平、体力、情绪、性格等诸多因素影响,难以量化、难以预见,更难以将由此带来的风险隐患控制起来。

使用制度来规范人的行为固然有一点效果,但纵使在一些成熟的公司设立了严格的制度,执行的不确定性依然很高。另外,如果依靠制度来将人的行为禁锢得太死,个人认为是不利于人的发展,不利于发挥人的价值。工程师作为高级技术人才,应该充分尊重其作为一个脑力劳动者的价值,使其精力投放在更有创造性的事情上去。

我认为,在运维领域最理想的目标,应该将重复琐碎的工作,都交给机器去做。运维工程师需要做的是:为运维管理及操作提供智力支持,并为自动化运维体系提供持续改进的动力。

实现这个目标是一条漫长的路,但是每一个运维的领导者,都应该带领团队踏上此条漫漫征途!这不是一个可做可不做的选项,在互联网高度普及的时代,对任何一个拥抱互联网的信息系统的维护团队来说,这是运维的必由之路,是选择停滞不前,被随业务剧增的流量暴击,每天疲于救火,应付不迭而累死?还是于崇山峻岭之中,劈开自我解放的光明坦途?答案不言自明。

系统性缺陷引发的风险

系统性缺陷指的是有系统设计时,包括网络架构和应用架构,以及整体环境逻辑设计时,未能充分考虑到各种可能发生的场景。这种风险,往往在日后特定场景下才会暴露出来。内部系统和外部系统风险。

制度流程性风险

制度流程不清晰、不严密,可能造成对风险管控存在“三不管”的责任死角,不能有效管控风险,出了问题互相推诿。处理问题,做不到迅速反应、标准化的机制,造成风险不能快速被修复。

风险控制的手段

风险控制的本质是在设计阶段尽可能消灭导致风险的因素,把确实难以彻底消灭的因素,采取技术和管理手段,将其严格限制在可接受、能及时有效应对的范围内。

减少人为:

标准化,自动化运维的日常工作

减少破坏:

变更本身就是一次破坏,控制基础设施变更、软件版本发布过程。最大限度地减少更新的内容、更新的次数,是控制“破坏”型风险的根本之道。

措施:

变更必须要有方案:严格设计、评估变更方案,严格按变更方案执行,不做变更方案以外的多余操作、误操作。

微服务:

近年来流行的微服务架构设计,其核心就一个字——“拆”,将大应用拆成小应用。微服务的优势就在于“小”,因为“小”,它具有以下三点优势:

1.资源利用上:针对不同应用的性能要求特点,给其配置最符合需要的硬件资源,做到对硬件的充分资源;

2.人员职责上:让每个工程师对自己负责的部分充分理解方便工作推进和工作交接;

3.变更环节里:减少总体工程项目代码量的变更,减少了变更带来的风险。

当然微服务化的落地,也可能产生新的风险,譬如微服务之间的调度和通信就需要依赖网络和一些中间件,增加了依赖性,所以微服务必须做到网络和中间件的高可用。

再者,微服务架构设计时,不能一味地为了“拆分”而“拆分”,因为过度的拆分,可能引入新的协调性风险。因而要合理评估和权衡,拆分带来的风险和收益。最后,拆分后对应用服务调用链路的监控、中间件的监控,以及应用的熔断、降级方案必须跟上,来管控协调性的风险。

容器化交付:

Docker近年来成为IT技术圈谈论和实践的技术热点话题。其最大的好处,我认为在两点,其一是,隔离了资源,定制化不同应用之间对资源的需求;第二,正是做到了对应用所需要资源的隔离,将应用和其所依赖的依赖库以及系统环境因素进行了一个打包,所以实现了一次编排,随处运行。

所以,对Docker的使用应该在全流程环境中使用(开发环境、测试环境、灰度环境、生产环境),可以将因运行环境的变化导致的可能风险,降到非常低接近0的水平(理论上能降到0,但是与网络架构和应用服务架构设计时,达到的解耦程度有关);

配置中心:

前文提到的解耦合,配置中心就是解除应用和环境耦合的神器。在版本发布中经常有这样的场景:同一应用的同一配置项,在不同的环境中需要设置不同的取值。在传统的自动化程度较低发布流程中,负责版本发布部署的工程师,需要根据环境的不同,逐个修改配置文件。

一个应用可能有几十个甚至几百个配置项,而一个完整系统可能由数十个甚至上百个应用构成。如果赶上一次涉及应用较多的大版本发布,对部署工程师来说,都是一次对细心和耐心的考验,更直言不讳地说,是一次冒险。

运维工程师可能因误操作,而导致生产事故。所以要减少配置变更,集中式配置中心要和分布式配置文件模版相结合,做到既能对配置做集中式的管理,又可以根据需要,针对单个实例做细粒度的配置管理。

减少权限:

三权分立:

将系统的操作权、分配权、审计权“三权”进行分割,分配给不同的人,互相制约。

分治:

按照不同业务、不同机器、不同集群、不同中间件,分配给不同的团队/人员管理,预防整体破坏的可能性。在中小型公司,此种做法并不完全可行,如不能做到按人的维度,分治,至少做到对账户角色的维度进行分治。

减少入口:

减少对外暴露的入口,可以方便做流量以及安全管控和行为审计。代理服务器、统一API网关、统一管理后台、堡垒机;

减少流量:

互联网行业流量就是金钱,大家都喜欢流量才对,为什么我说要减少流量呢?这里说的减少,并非减少总量,而是让流量均匀流入,减少流量暴增式场景的产生,使得瞬时流量峰值不超过系统承载能力。例如,12306购票从原来一次性放票调整为分批次放票, 淘宝双十一活动从双十一当天延展到半个月,还有我之前公司做活动营销推广短信,也是分批次触达用户。这些措施都降低了流量的瞬时峰值,使其不超过系统的承载能力。

减少外部依赖:

所谓外部,不一定是公司以外的系统,也可以指本公司其他团队的系统。我们把掌控能力边界以外的系统,都视为外部系统。外部系统不归属本团队控制,甚至难以做到高度的协同,属于是难以控制的因素,比如调用外部系统(支付、风控、DNS解析、NTP、第三方登录认证等等。有的外部的依赖确实难以摆脱,起码做到与外部系统建立并保持有效的协同机制,比如版本更新信息同步、管控双方调用通道、双方都设置专人对接维护调用关系等等措施。

增强监控:

监控,分为“监”和“控”两大阶段,“监”是能做到对风险信息及时、有效得收集,其粒度和时间密度要能满足控制风险的需要,“控”是对“监”得到的风险信息进行判别处理,其关键在于阀值的设定是否合理和对应的解决方案是否全面有效。我认为,一个完整的监控应该由这么几个部件组成,数据收集器、数据处理器、存储器、仪表盘、阀值、告警器以及监控处理方案组成。

除了数据处理器、存储器和仪表盘不一定必须,其他的部件对于一个完整的监控来说缺一不可。尤其是监控处理方案,常常被忽视,或者说被认为难以设定。但是,缺了处理方案,“监控”就只做到了“监”,缺少了有效的“控”,就不再算一个完整点“监控”。

监控是用来捕捉处理风险的,告警器被过于频繁地触发,就会导致监控处理人变得麻木,从而导致监控丧失效力。合理地设置数据收集器收集策略和阈值大小,建立必要的收敛机制,误报屏蔽机制,是杜绝这种现象的根本。监控和软件本身一样,需要不断改进和优化,才能实现最好的对风险捕捉以及处理效果。

增强性能:

扩容,升级硬件/软件性能,cpu、内存、硬盘容量、io效率、缓存、并发线程数,性能问题往往符合“木桶效应”,系统整体性能由最短板决定。优秀的运维工程师,应该要对每个业务流程涉及到的性能消耗特性,有全面的了解,及时补齐短板,防患于未然。

增强应对的速度:

根据场景变化,能快速地扩容、降级、熔断、恢复、回滚,实现这一目标的三要素是:快速而全面的监控机制、标准的事件处理流程、高度自动化的运维工具。

增强审计:

收集到足够丰富合理的审计信息,建立定期审计的制度,对既往操作行为,查漏补缺,筛查违规操作,对完善制度和流程是十分必要的。

增多备份:

所谓狡兔三窟,数据也应该多做几份冗余。标准的备份方案应该做到“两地三中心”,即在两个城市,拥有三个以上数据中心。每个数据中心,都能做到独立运转。不同数据中心之间,能在较短的时间范围内快速切换,数据灾难发生时,可以将对用户的影响降到最低。其次,配置文件包括应用配置文件,操作系统的配置文件和中间件、数据库,都应该尽量做到备份,同代码一样,引入git等版本管理工具,实现版本化管理。备份要形成制度,根据数据的变化频率,重要程度,确定备份周期和备份方法。备份不可只“备”不“复”,往往很多团队的备份,平日都不做恢复演练,到了真正需要恢复时发现根本无法从备份恢复出数据。所以,需要定期做备份恢复的演练,确定备份文件可用,恢复流程和方法执行顺畅。

增强制度:

增强不是增多制度条目数量,繁文缛节不是一个务实的技术团队的应有风格,而是追求用最简练的办法,增强制度逻辑的严密性和可操作性。把上述原则以制度文件的形式确立下来,凝聚开发、测试、运维和运营团队的共识。

自动化对于风险控制的意义

1.降低人为操作导致的不可控性

2.减少风险控制的成本:包括物质成本和人力成本以及时间成本。

自动化的前提和基础

高度的标准化:

标准化硬件、标准化软件组件、标准化流程制度

方法:

流程高度抽象、功能细粒度切分、模块化/组件化,在这点实践上,比较优秀的案例,当属宝企通IT服务,

宝企通IT服务作为智能化工单系统龙头,拥有多年优化SLA经验,能够有效提高员工对IT的服务满意度。是一款支持SAAS、本地化部署、源码交付的运维工单系统(SAAS免费试用,企业微信--工作台--添加应用,搜索“IT服务”,排名第一的就是)。目前是全网众多企业选择的工单类产品,支持手机验证码或账号验证,员工自助修改域账号密码,具备智能化派单模式工程师响应快减少员工等待时间。自定义知识库可提升工程师专业技能水平,帮助工程师迅速判断员工问题,极大提升员工报单体验。系统还能够大幅提升职能部门可以服务的用户数,有效降低专业人力成本开支,提高业务执行效率,展现工作成果。产品服务好能为用户免费开发个性化需求,连续多年被魔力象0评为leaders位置,市场占有率爆发式增长

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:/a/639200.html

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈qq邮箱809451989@qq.com,一经查实,立即删除!

相关文章

汇舟问卷:海外问卷调查如何闭坑?

大家好,我是汇舟问卷。有很多人问我这行有什么骗局吗?怎么说呢?其实每个行业都是真实存在的,也都有赚到钱的和赚不到钱的,那区别在哪里呢? 在你的源头,也就是教你或者说是代理加盟的上家&#…

机器学习实验 --- 逻辑回归

第1关:逻辑回归核心思想 任务描述 本关任务:根据本节课所学知识完成本关所设置的编程题 #encoding=utf8 import numpy as npdef sigmoid(t):完成sigmoid函数计算:param t: 负无穷到正无穷的实数:return: 转换后的概率值:可以考虑使用np.exp()函数#********** Begin *******…

景源畅信数字:抖音小店新手该怎么做?

在数字化时代的浪潮中,抖音不仅仅是一个分享短视频的平台,更是一个充满潜力的电商平台。对于想要进入这个领域的朋友们来说,开设一家抖音小店无疑是一个既激动又迷茫的起点。那么,作为新手,该如何在这个全新的舞台上立…

笔记 | 《css权威指南》

网络安全色 URL text-indent line-height & vertical-align 字体 font-weight 400 normal 700 bold background-attachment

iOS系统故障怎么办?这三种苹果手机系统修复方法你一定要知道

随着苹果手机使用时间越长,苹果手机有时也会出现系统问题,如卡顿、崩溃、无法启动等。这些问题不仅影响用户的使用体验,还可能导致数据丢失。因此,掌握苹果手机系统修复方法显得尤为重要。本文将详细介绍苹果手机系统修复的常见方…

MyBatis入门(1)

目录 一、JDBC操作回顾 二、什么是MyBatis? 三、MyBatis入门 1、准备工作 (1)创建工程 (2)数据准备 2、配置数据库连接字符串 3、写持久层代码 4、单元测试 (1)使用IDEA自动成成测试类…

UFS协议—新手快速入门(一)【1-4】

本篇旨在为初学者提供关于通用闪存存储(UFS)的快速入门指南。 目录 一、背景介绍 二、UFS 三、半双工和全双工 (1)半双工(Half-Duplex) (2)全双工(Full-Duplex&…

【大模型】fineturn Q-wen

github上下载qwen1_5源码 修改finetun.sh 然后在路径qwen1_5/examples/sft下修改finetun.sh, 内容如下 #!/bin/bash export CUDA_DEVICE_MAX_CONNECTIONS1 DIRpwd# Guide: # This script supports distributed training on multi-gpu workers (as well as single-worker trai…

【HTML】制作一个跟随鼠标的流畅线条引导页界面(可直接复制源码)

目录 前言 HTML部分 CSS部分 JS部分 效果图 总结 前言 无需多言,本文将详细介绍一段HTML代码,图中线条可跟随鼠标移动,具体内容如下: 开始 首先新建一个HTML的文本,文本名改为[index.html],创建好后右…

弱电工程企业项目一体化管理系统解决方案!企智汇项目管理系统

企智汇工程项目管理系统是一款为弱电工程企业量身打造的专业解决方案,旨在帮助企业实现项目管理的数智化、全流程化和一体化。以下是该系统的详细介绍: 1. 功能丰富:企智汇工程项目管理系统支持全周期的项目管理,包括客户管理、招…

火山引擎边缘云亮相 Force 原动力大会,探索 AI 应用新范式

5月15日,2024 春季火山引擎 FORCE 原动力大会在北京正式举办。大会聚焦 AI 主题,以大模型应用为核心、以 AI 落地为导向,展示了火山引擎在大模型、云计算领域的实践应用,携手汽车、手机终端、金融、消费、互联网等领域的专家和企业…

【全开源】班级管家微信小程序(FastAdmin+ThinkPHP)

班级管家微信小程序 班级管家微信小程序,作为一款专注于家校沟通、作业管理、成绩发布等方面的工具,凭借其丰富的特色功能和显著的优势,已经成为广大教师、家长和学生日常学习生活中不可或缺的一部分。 一、特色功能 家校沟通便捷&#xff…

大模型之Ollama:在本地机器上释放大型语言模型的强大功能

LlaMA 3 系列博客 基于 LlaMA 3 LangGraph 在windows本地部署大模型 (一) 基于 LlaMA 3 LangGraph 在windows本地部署大模型 (二) 基于 LlaMA 3 LangGraph 在windows本地部署大模型 (三) 基于 LlaMA…

从“图形可视化”到“图生代码”,低代码平台的新挑战

前言: 低代码平台最大的一个特点就是可视化,将代码采用可视化的方式展示管理。一时间拥有图形化界面的各类系统都挂上了低代码的标签。但更多的代码从业者在使用中却发现,在众多的低代码平台中都是“别人家的代码”其可视化主要是别人家的代…

vmware 17pro17.5 bug 严重,建议升级17.52

近日vmware发布17.52 更新,修复了一个重大BUG. 也就是莫名其妙的CPU跟GPU占用问题。 我的系统是WIN11 跟VMWARE17.5..近日莫名其妙的发现即使什么都没运行,GPU占用也高达20%。开始以为中毒了被拿去挖矿了,后面看到VMWARE的这个更新&#xf…

Matlab:音频处理

用Matlab绘制一段音频信号在时域上的波形图,然后用低通滤波器滤掉噪音并再次绘制 1、导入音频文件 filename X:\1.mp3; % 替换为你的音频文件路径 [x, Fs] audioread(filename); 2、获取音频信号长度 len length(x); 3、计算时间轴 t (0:len-1) / Fs; 4、…

【Pytorch】16.使用ImageFolder加载自定义MNIST数据集训练手写数字识别网络(包含数据集下载)

数据集下载 MINST_PNG_Training在github的项目目录中的datasets中有MNIST的png格式数据集的压缩包 用于训练的神经网络模型 自定义数据集训练 在前文【Pytorch】13.搭建完整的CIFAR10模型我们已经知道了基本搭建神经网络的框架了,但是其中的数据集使用的torchvision…

机器学习云环境搭建

在 https://support.huaweicloud.com/browsertg-obs/obs_03_1003.html 下载对应版本的 OBS Broswer 软件,如图,红框内的为安装文件,蓝色框内的为对应安装文件的校验文件(无需下载) 以 64 位机为例,下载完…

SpringBoot搭建Eureka注册中心

系列文章目录 文章目录 系列文章目录前言前言 前些天发现了一个巨牛的人工智能学习网站,通俗易懂,风趣幽默,忍不住分享一下给大家。点击跳转到网站,这篇文章男女通用,看懂了就去分享给你的码吧。 1、Spring-Cloud Euraka介绍 Spring-Cloud Euraka是Spring Cloud集合中一…