2.2.1 以业务为中心重塑运维岗位能力

原创

mb5fdcad5445be3 2021-03-08 17:09:45 ©著作权

文章标签 java 文章分类 Java 后端开发

©著作权归作者所有：来自51CTO博客作者mb5fdcad5445be3的原创作品，请联系作者获取转载授权，否则将追究法律责任

摘要：

前面的文章提过运维体系的发展，是一个不断从“组织、流程、平台、场景”四个维度不断适应IT环境变化的过程，整个过程形成了一个运行数字世界的适应性系统。这个适应性系统由不断改进的组件与越来越复杂的连接组成，系统的持续改进目标是为了更高效的适应复杂性、不确定性的变化。在运维适应性系统组件包括硬件、系统软件、业务系统、人、运维效能工具。随着“需求（need）、改变（change）、风险(risk)、适应(adapt)”的循环飞轮的运维能力持续提升，硬件、系统软件的工作更加标准化与自动化，而业务运维复杂性越来越高，运维岗位能力需要以业务为中心，重塑岗位能力。

2.2.1.1 如何适应变化

在1.2章“构建运维适应性系统”中，提到运维适应性系统的建设是一个围绕“需求（need）、改变（change）、风险(risk)、适应(adapt)”4个节点循环，达到能力螺旋上升的飞轮循环。即，运维能力的提升来源于更高（质）、更多（量）、更快（速度）的需求驱动；为了适应新的需求，组织引入新的技术与新方法；新改变通常会产生新的风险；综合优化组织、流程、场景、平台能力，解决风险，形成适应性能力；建立了适应性能力后可以支持更高、更快、更多的需求。本节先看运维面临的变化。

IT部门面临加快交付效率，提升运维质量的挑战。以金融行业为例，按照金融业信息技术“十三五”发展规划目标，“十三五”期间金融经营机构的重点任务主要包括：进一步完善金融信息基础设施，健全网络安全体系，推动新技术应用，深化金融标准化战略，优化信息技术治理体系，提供更加集约、高效、安全的金融信息技术服务。信息化时代，国内领先的金融企业构建了大量的IT系统，并利用了金融信息化契机获得商业上的成功。随着市场复杂性与不确定性不断加快，线上应用的寿命越来越短，以苹果应用市场为例2019年上半年平均每天下架的应用接近2300款应用，环比增长45.58%，前端的应用必须能够快速响应政策环境、监管要求、用户需求才能在不断加快的大背景下获得企业竞争力。但在信息化传统封闭架构下，金融企业IT系统形成一个个垂直的烟囱，缺乏信息互联和共享，为了满足业务日益多样化的需求，主要采用先竖向满足业务，再横向打通，交付业务需求的成本越来越高。所以，如何确保系统稳定和业务合规的前提下，提供敏捷交付管理及业务需求的能力是金融企业IT部门面临的第一挑战。另外，生产系统业务连续性保障形势不容乐观，以证券行业交易所为例，今年以来，全球各地交易所技术故障风险事件频发：德意志交易所于今年4、7月因软件故障导致中欧及东欧几个国家衍生品和股票交易受阻；8月新西兰交易所连续6天收到网络攻击被迫多次中断交易；10月东京交易所因系统切换异常导致全天暂停交易；10月墨西哥交易所因交易引擎断开暂停交易；10月泛欧交易所因中间件系统问题暂停所有产品交易；11月澳洲交易所开盘后交易中断停业一天等。如何在企业快速发展过程中，加强业务连续性保障能力则是第二个挑战。

推动基础架构云化、云原生应用兴起正当其时。交付效率与运行质量的挑战可以转换为：降低运营成本、提供高效弹性、防范信息安全、提高交付效率、保障连续性风险等技术目标，需要引入架构云化、云原生方法三个技术/方法。当前，大部分中大型企业都确定了基础设施层面云计算战略，一些有能力或对信息安全性要求高的企业，重点推进私有云建设，并结合大型云服务厂商提供的公有云或行业机构提供的行业云，形成混合云的运营模式。可以预想，云计算集中了企业资源，通过集约化带来的成本优势，将为企业提供更稳定、高弹性、低成本的基础设施、数据库、中间件，及其它平台层的PAAS组件。伴随着云基础设施的落地，企业不仅是简单的将现有应用系统分步搬上云，也面临如何更好的利用云计算弹性扩展、分布式、按需获取、安全可靠等优点，这就推动了应用架构在开始设计时都要考虑将来能够运行于云环境，由此带动了云原生应用的兴起。对云原生的定义，云原生计算基金会（CNCF）作出以下定义：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格（Service Mesh）、微服务、不可变基础设施和声明式API。”以下摘自互联网中关于云原生的定义、要素、设计理念的图：

2.2.1 以业务为中心重塑运维岗位能力_java

云化基础设施、云原生方法，简化了上层应用的交付效率，但将复杂性落在运维侧。云化基础设施，使得企业不再需要按项目或需求去购买、部署、维护硬件和系统软件，无需资源消费方参与复杂硬件及系统软件的维护，标准化了基础设施、系统软件运维，用自动化替代了原来大量操作性工作。但云化基础设施架构必然面临要对企业原有系统进行改造，由于传统企业大部分重要交易业务系统均采用烟囱部署架构，且运行多年后，现有系统架构越来越复杂，“动则生变，变则异常”己成常态。采用云原生方法，虽然帮助业务快速迭代，但广泛使用的开源技术与分布式节点粒度的分解，也带来了架构的复杂性，交易链路节点数量迅速膨胀，同时软件代码与项目交付流程也发生了改变，都提高了业务运维的复杂性。在技术的应用上，还需要关注新技术的选择时机，很多新技术通常是解决一个软件研发过程的问题，但是新技术的坑需要经过一系列质量内建手段、线上生产事件来填，如何在一个合适的时机引入一个新技术是一个风险。

以业务为中心，推动运维能力提升，配套运维平台化建设是当前行为有效的适应手段。行业不同，对业务连续性的理解并不一样。以google提出的devOps其中一个原则：“愿意承担一部分试错带来的损失”，在金融行业则不适用。以证券实时交易为例，业务停滞一秒均可能带来巨大损失，证券自身的业务特点以及外部监管“零容忍”的要求，信息系统业务连续性的诉求会高于其他行业，确保业务连续性成为证券行业IT 运维的核心任务，业务连续性管理的总体目标是提高公司的风险防范能力、有效地减少非计划的业务中断、防范运维操作风险，对于首次出现的未知异常能够利用工作量化分析并快速定位，确保在重大灾难性事件发生后能按计划恢复业务连续性。在这样的行业背景下，运维团队的角色肯定不能仅会应急三把斧或工具研发的角色，而应该能够深耕业务并运用工程能力的运维角色。运维平台化的作用是对运维的赋能，而不是替代运维，运维平台需要围绕运维组织的“提高业务连续性保障、提升业务交易系统，辅助提升客户体验、提升IT运营服务质量”等价值创造，持续丰富“监管控析”的工具平台体系，不断推进工作线上化、自动化、服务化的落地。

2.2.1.2 从Google SRE到BRE

与传统运维岗位相比，SRE更加强调“可靠性”与“工程能力”。SRE（Site Reliability Engineering，站点可靠性/稳定性工程师），要从其名称看看SRE的岗位角色。S（site），最初代表www.google.com的运维服务，随着团队的扩大，实际上S的范围也扩展到了其它应用系统。R（Reliability），google认为是运维组织要不断的优化系统架构、运维流程，让系统更加可靠，扩展性更好，能更有效的利用资源。可以看出，SRE相比传统运维，明确强调了“可靠性”保障，这推动了SRE聚焦资源落到尽可能增加MTTF（不出故障的时间）和缩短MTTR（出故障后的恢复时间）两个指标上，并围绕这两个关键指标加强系统运行风险排查与解除，并加强风险发生后的应急能力。E（工程师），工程师需要具备有工程能力，在google指需要具备软件研发能力的工程师，能够和业务研发团队共同工作，研发系统以外的额外组件。再看看SRE日常工作：日常需求处理、容量规划、资源部署、监控告警、预案梳理、灾备演练、OnCall值班、应急事件响应、故障处置、影响分析、应急复盘、软件研发、项目站立会、系统设计、项目进度推进、工具落地推广等。可以看到，SRE区别于传统运维岗位的第二个特征是“工程性能力”，狭义的讲是软件开发能力，但又与业务开发有些区别，SRE的开发偏向于提升业务连续性上的研发，业务开发偏向于业务功能研发。（关于SRE的更多信息，我摘一些在《SRE Google运维解密》中一些SRE的观点，见文章结尾，这里暂不展开）

Google认为S、R、E三个词中，最关键的是E，可能是因为这个原因，国内很多人把SRE等同于运维开发。站在金融行业，我个人认为如果SRE是金融行业运维岗位能力发展的参照方向，应该以S与R为本，E是手段，或者说应该是“BRE”（Business reliability Engineering）。

首先，前面提到金融行业更加强调业务连续性，运维角色必须懂业务，去掉业务属性，这支运维团队就失去了灵魂。所以一个好的运维人员不仅是能够操作各类监控、应急恢复、咨询解答、变更操作等能力，他还应该是在整个IT团队中具备最全局掌握所负责系统应用部署架构、可用性架构、上下游关系、最小功能模块失效影响、容量性能分析等能力的角色。

其次，从Google SRE由来看，SER是一支独立成长于原有运维团队的组织，也就是这支团队是一支全新投入的人力资源。但金融企业的运维团队通常比较稳定，相比研发团队根据业务需求不断扩大，运维团队规模通常不怎么变化，运维团队的工作能力就像海绵一样挤挤又能承担更多。所以，运维团队的转变重点是对现有运维人员能力建设。

另外，运维团队中资深的工程师比较多。资深说明运维人员沉淀了更多经验，经验有助于在业务连续性保障中更快的定位问题。但从现实情况看，资深也导致个人学习意愿与学习能力的下降，所以让现有运维团队的人都能掌握软件开发能力并不现实，如何既发挥好运维人员的经验，又能促进团队的成长型思维是一个难点。

所以，我觉得运维团队可以基于BRE角色建设，提升业务连续性保障能力，再推动“提升业务交付效率”、“辅助提升客户体验”、“提升IT运营服务质量”的能力建设。如果要勾画BRE角色，可以考虑以下方向：

系统架构师：清楚应用系统部署架构，懂应用逻辑架构，掌握上下游系统、高可用、容灾架构等。
业务架构师：清楚核心业务功能业务逻辑，当核心功能不可用，甚至一笔关键交易异常时，能够及时发现，并快速应急解决，或利用混沌工程加强业务风险点。
可用性工程师：擅于利用工具，落实可用性改进，容量规划，延迟优化，性能优化，业务架构优化，应急演练，应急预案编写等工作。
运营分析师：具备数据思维，能够让系统运行，业务运作，客户体验，流程管理等数字化，并利用掌握的运营数据驱动研发，测试，业务持续优化。
运维操作员：各类监控发现、舆情感知、故障应急、根因分析、系统巡检、咨询反馈、变更交付、IT服务等工作。

2.2.1.3 加强被动性与主动性适应性能力

结合上面提到的“系统架构、业务架构、可用性、运营分析、运维操作”五个维度，如果将运维工作分被动性与主动性两类，可以大致分为：

1、被动性工作：根据事件增加监控指标，加强监控覆盖面，提高监控处理及时性，提升故障应急处置自动化，优化故障应急协同机制，落实故障后问题的闭环跟踪，提高生产变更发布自动化水平，建立生产问题咨询反馈的服务机制等。

2、主动性工作：制定系统架构标准，运维工作前移参与系统设计阶段工作，构建可视化的应用上下游调用链路，持续推进业务逻辑架构评估，加强对业务核心功能及数据的理解，推进混沌测试挖掘系统风险点，落实故障应急复盘机制，推进系统性能与容量、终端拨测、客户体验等分析工作，加强系统效能分析推动低效系统退出机制。

可以看到，被动性工作主要面向传统运维的业务连续性保障工作，线上化、自动化主要是面向被动性工作范围；主动性工作主要是利用运维对架构、业务、运行数据的分析能力，增加运维全局可控能力，数字化、服务化主要是面向主动性工作。

最后，虽然金融企业的BRE不强调软件开发能力，但他要擅于运用运维平台工具来提升被动性与主动性的适应性能力。这里的运维平台工具，则需要由一支独立职能的运维工具研发团队，根据BRE实际的工作场景驱动，构建在线、自动化、数据驱动的工作空间。运维工具研发团队的定位是一支赋能BRE的工具开发团队，需要一些能力：