从数字化转型风云到系统运维管理

字数 5329阅读 2078评论 0赞 6

# **作者简介**

80 后一枚，初以存储备份容灾白手起家，昼伏夜出，奔赴在项目救火一线；随后转入基础运维序列，混迹于运营商、金融行间；现尘埃暂定，落叶于某保险公司，负责数据中心相关管理工作，多与服务器存储打交道，和虚拟化、超融合和云相聚一堂，在基础资源架构设计与优化、业务运维方面略有心得。

- - -

# **1、开篇前言**

现今云计算、容器、超融合、大数据技术如日中天， DevOps 、 AIOps 兴起， AI 、 5G 也不断突破、成绩喜人，整个信息行业大步迈向数字化、智能化。技术的冲击无不催动着众多企业的数字化转型进程。然而数字化转型并不是一件容易的事，不仅仅关乎企业在信息战略上的调整、业务及架构上的创新，更要求企业面对转型的冲击实现业务增长与技术输出的软着陆，转型到发展的平滑过渡。信息技术部是企业技术实力的牌面，在数字化转型过程中，更肩负着成功实现转型、全面保障业务的重大责任，而在这支中流砥柱里，运维管理最不容小觑。

笔者曾陆续接触过运营商、保险、证券以及政府等多个行业，熟悉其业务框架和基础架构，借此机会，分享些个人从近几年行业基础架构的发展演进上，对基础架构运维的点滴感悟。

# **2、当下之势**

## **2.1 基础架构的变迁**

2015 年以后，信息技术的发展陡然增速，超融合、私有云 / 私有云、容器、大数据等在架构、版本、功能等方面都有了长足的进步，并打开了企业市场。随着近五年的发展，万兆网络互联呈席卷之势，迅速占领了数据中心。 X86 服务器性能日益强大， SSD 性价比完败机械磁盘，一时间吹起了 AI 赋能、分布式、国产化转型之风。技术的雷厉风行始终是其版本的迭代，传统企业并不追新图快，而是稳中求胜，技术的真正效益还得依靠其在企业落地带来的价值丈量。

最近几年，国际巨头背书、互联网企业助推的分布式生态趋于稳定，从计算、存储到网络各方面衍生的开放架构纷纷亮相，企业级解决方案、产品接踵而至，大数据、超融合、云等开放技术也在传统企业内得以实装。

如今企业基础架构正处在这新旧交接的过渡期。以金融保险行业来说，现阶段多数保险公司新旧架构并存，中国人寿、平安、太平等在内的绝大多数保险公司都开始了私有云、公有云或者混合云的尝试，积极实现云转型。相对于云，在容器和超融合方面，各大保险公司的步伐均已迈入前列， Openshift 、 k8s 、 Rancher 等主流容器及管理平台均在保险行业落地，业务也逐步优化改造以适配新的平台。 Nutanix 、 FusionCube 以及 SmartX 等主流超融合平台也打入了企业数据中心，陆续承载业务系统的运行。大数据平台、 AIOPS/DEVOPS 体系建设，各保险公司或初窥门径、或提上日程、或已小成规模。

新的技术、新的平台纷纷涌入金融行业的信息化建设中，然而我们也应意识到数字化创新道路上的桎梏。由于各保险公司成立较早，业务框架与基础资源架构偏向传统，与当前开放式架构或多或少存在兼容性问题，系统改造、优化升级也不得不考虑在基础建设之中。

金融企业的基础架构战线很长，不少家当可以追溯到大、小型机时代，通过高性能巨型机来支撑业务，又经历了传统三件套服务器存储网络的分流，高性能需求业务与普通业务各执一方，随着服务器虚拟化产品的日臻完善，传统基础架构迎来了第三次冲击，新业务乘上了虚拟化的快车，使得很长一段时间里基础架构呈现三分之势。

若以持续发展的眼光审视传统架构，相对于今天的云、超融合、容器等，传统架构虽然体态庞大，但泾渭分明，在繁杂的物理底层上也保持着规矩可循。新旧架构体系的迭代更替，是一个挑战，更是一份契机。

## **2.2 基础架构的趋势**

纵观近十年的 IT 基础架构的发展，硬件性能翻番，直接奠定了基础架构革新的基础。无论是 INTEL 还是 AMD ， CPU 的性能较之十年前不可同日而语，算力飞跃式升级，强大的算力驱动未来；更低延时、更高 IO 的万兆互联技术全网普及，直接改变了数据网络的格局，带来了分布式的更多可能；性价比更胜一筹的固态硬盘迅速反扑了机械磁盘的市场，显著拔高了存储性能的门槛，彻底改写了数据存储的篇章……计算、网络、存储的突飞猛进直接奠定了信息化的格局，也必将在未来五至十年里呈现各中趋势，运维管理的重心也随之有所偏向。

开放式架构体系与开源化产品已在各企业内部扎根，基础架构也从传统框架向多种开放式架构设计多路并进，数据中心内部多种架构形态还将持续许久。依托现今的架构格局，着眼当下信息技术的发展，不妨大胆揣度下未来几年基础架构设计、业务支撑的走势：

Ø  分布式架构兴起

算力驱动未来，更强大的算力也意味着更多的生产力。传统架构受制于体系设计，无法实现灵活、便捷的扩展。然而计算存储网络技术的齐头并进，给予了分布式的架构更多的青睐。分布式不仅放大了计算存储网络扩张优势，真正实现了动态架构、灵活扩展的能力，而且相对于传统架构，综合成本可期，其阶段性的效益价值更容易为企业所接受。同时从业务角度方面分析，在业务框架不变的基础上，分布式更能优化业务的整体表现力，通过合理拆分业务逻辑，细分业务功能角色，给予了更充足的弹性空间，更符合业务的发展曲线。

随着金融行业大力发展互联网业务，分布式的需求势必进一步扩大，凭借灵活的架构也会在未来占据更多席位。

Ø  轻量化的业务支撑

在近两年里，容器产品的盛行也引发了企业对业务支撑模式的思考，很长一段时间里，数据中心都是依赖传统架构提供服务能力，或者凭借虚拟化去支撑业务的需求。但在传统框架内，资源的实际利用效率低，尤其是对中小型业务系统的支撑。传统架构大处着眼，对业务系统的支撑大而全，无法做到小而精，而一些轻量级的产品，如轻量级容器应用、数据库等却能很好的满足这块需求，通过弹性扩展横向增加性能，向上业务支撑灵活、可大可小。企业 2B 及互联网方向业务剧增，中小型业务系统占比上升，轻量化业务支撑的需求也会同步增长。

除此之外，轻量化产品上线前期，对业务架构的改造也在一定程度上优化、升级了业务的整体性能表现。上层应用集群的分解、业务数据结构的改造分离，逐渐淡化了前端后端、前台后台的固化模式，使得业务整体模式也更符合现今业务迅猛发展的需要。

Ø  全栈技术的联动

在云、容器、超融合、大数据等多重开放式架构的混战下，企业虽然享受着架构生态的红利，但管理者也意识到管控精力逐渐被分化，成本开销日益放大，多方独立的局面不能持续，平台与运维的矛盾迟早要解决。 2019 年“全栈”的理念被多次提出，云、容器、大数据的一体化平台应运而生，管理平面生态逐渐走向全栈化。企业内部的各项基础资源、产品技术的隔离日益弱化，计算存储网络的联动更加频繁。

不仅如此，开放式架构的带动下，运维管理的界限逐渐模糊。传统架构中，服务器、存储、网络、安全，专岗专人，各司其职。开放架构下，计算存储网络即独立又联合，各功能上下游牵扯、组件间多层封装。若系统出现异常，必须多方协调，全局排查，因而“一专多能”的角色要求至关重要。

## 2.3 运维管理的挑战

随着基础架构的转型，新的平台和技术不断涌入，运维管理面临着不少挑战，接下来笔者以系统运维岗为例进行说明：

## a   运维管理横向维度拉伸

在传统运维中，系统运维岗位主要负责数据中心基础软件系统（如虚拟化、云等）的运维工作，主要是保障底层平台的稳定运行。基础架构适时转型，运维管理的横向维度也进一步拉伸，更多基础系统（如 HCI 平台、云管平台甚至是容器云平台）加入了系统运维的岗位中。

随着管理面的扩大，系统运维的难度也随之提升。首先是技术的拓展上，新产品都在传统技术层面上引入开放式架构技术，进行了不同程度的融合升级，例如 HCI 在传统虚拟化基础上加入了超融合底层承载分布式计算与存储。其次与其他运维的联动上，开放式架构的功能丰富、组件多、逻辑复杂，这也导致系统运维与其他维面的多处接壤，间接增加了运维的难度。以云管平台的运维为例，门户层由于服务级联常与 ITSM 运维交互，功能层因对接多种数据库常与 DBA 照面等。最后是角色定位的转变，传统运维由于职能纯粹一般实行专人专岗，而在数字化转型的趋势下，开放式架构更需要“一专多能”的角色定位，尤其是云管、容器这类关联性极强的平台运维，不仅需要底层计算存储网络的基础，更依赖云管、容器产品本身的技术储备以及运维边界上的理解与沟通。

## b 运维上下游渗透

随着开放式架构的演进，平台的各项功能逐渐抽象化、服务化，系统运维横向维度拉伸，其各处上下游的界限也逐渐模糊。这一思想在云和容器上体现得淋漓尽致。

在传统运维中，即使是虚拟化或者 IAAS 云，向上支撑的单位还停留在虚拟机层面，不论与开发、应用还是数据库等业务面的交互还存在明显的分界。而随着开放式的架构深入，容器云以及 PAAS 、 SAAS 云的落地，向上支持的精度更加细致，服务的表现力更为强大，基础资源均逐渐抽象化为服务，按需部署。也是这转变的过程中，运维上下游的联系已潜移默化、悄然改变。例如， Rancher 等容器云平台，运维过程中从部署、上线、排障以及优化均已不似传统运维中各岗位单打独斗，而是开发、应用以及运维在业务的每一个环节都要进行充分讨论、沟通、确定，共同协作完成系统框架、交互逻辑、参数配置、部署优化等各项工作。随着分布式架构的推广，业务应用、中间件、数据库精细化拆分的进展，业务各支撑面的黏性将进一步提高。

## c  智能化运维管理

近些年在大数据以及 AI 技术的助力下，系统开发及运维都逐步走向智能化，如 devops/aiops 等智能运维管理平台出现在企业之中，取代了部分人工运维的工作。

在 aiops 平台的管理下，通过对运维数据进行学习训练，将实际问题转化为算法问题，从而自动化处理各类系统运维故障。目前结合 APM 性能数据， aiops 平台已可实现云及容器等平台上应用节点异常检测，实时告警并依靠决策树尝试自动重启修复或动态扩容节点替换故障节点等；在故障预测及瓶颈分析方面，通过对历史基准值的挖掘，预测系统的常态，对关键性能失衡提前告警并给出排查建议；在平台及系统容量预测上，通过对各项资源的投入及实际消耗分析、绘制未来趋势曲线，为系统运维人员的扩容提供数理依据。

# 3、未来之行

随着数字化转型的脚步，运维管理横向以及纵向都发生了质的变化，在横向维度责任范围已然扩大，从传统的虚拟化向 HCI 、容器云以及更高层次的云模型发展。纵向上系统开发、运维以及其他运维更加亲密，走向运管协同的趋势。

面对系统运维岗位的变化，笔者建议以一个基本点两个中心出发、付诸行动：一个基本点即是“技术为本”。作为系统运维，专业技术就是资本：当务之急是对新架构的掌握，提升云、容器、 AIOPS 等知识积累，分布式架构的原理相似相融，云、 HCI 与虚拟化都有着千丝万缕的潜在联系，举一反三、触类旁通；其次做好厂商到运维组的知识转移，以技术交流、管理培训等方式加速运维管理技能的成长，厂商资源是数字化转型前期重要的辅助资源，尤其是针对云及云管这类覆盖面广的平台，合理利用厂商支持夯实产品运维的根基。最后，抓住实干的机会，系统运维修行的两大核心 ----CASE 和项目，跟踪 CASE 是检验个人运维能力最直接、最有效的方式，通过对故障的分析、推理及判断完成理论到实践的转化，增长运维经验。项目是对个人运维管理能力的综合历练，产品测试选型、架构部署、最佳实践是最好的实际检验标准，丰富项目阅历。两个中心即是“一专多能”的定位与“持续赋能”的觉悟。开放式架构盛行，业务下移，开发运维支撑上行，是必然的趋势，不懂业务的运维不是优秀的系统管理员。在实际运维过程中，理解并掌握业务基础将成为运维管理员部署优化、排障定位的有效辅助。系统运维不仅是维持基础系统的稳定，更需要保障与支撑业务的高效运行，而业务系统的最佳实践效果往往依赖系统运维提出业务系统配置及架构优化改良建议。在容器及云服务设计上，资源的 CPU 内存存储配置、应用架构选型、系统的部署方式与实现，需要全面综合系统开发、运维、应用等多位面的协同，业务基础即是连接位面的重要枢纽。

如今随着 devops/aiops 等智能运维管理平台的落地，不免引发对运维管理的另一则猜想：运维和管理都能做到智能、自动化了，那系统运维管理员是否会随着技术发展逐渐被淘汰呢？诚然，必须承认的是： AI 技术及算力的突破确实带来了人工智能的迅速崛起，并且切实解决了一部分基础问题，实现智能化需求。但我们也要意识到， AI 的智能化极度依赖其模型训练积累，智能等级越高，其模型越复杂，训练时间越长，成本越高。在智能化运维平台的催化下，系统运维的职业思考更需深谋远虑，基础运维工作的接力即将由运维管理员交接给 AI ，而运维管理员则向着更高的管理层次迈进。

数字化转型系统运维

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

从数字化转型风云到系统运维管理

添加新评论0 条评论

作者其他文章

相关文章

相关问题

相关资料