谁来拯救，亦或拯救了谁？

白鳝的洞穴 2023-02-14

274

昨天关于《运维的意义》的文章谈到研发与运维的关系问题，引发了一些朋友针对这个问题的交流。实际上我做过十年研发，之后的工作一直从事的是运维领域的工作，因此在我的世界里总是充满了研发拯救运维的期待。十多年前《Oracle通讯》和我约了一篇稿子，题目是《性能优化从需求分析开始》。当时我正焦头烂额地帮助运营商、银行、大型制造业等客户处理各种各样的系统优化的问题。面对糟糕的数据库设计，任性随意的SQL语句，真的希望把那帮研发人员抓起来揍一顿才够解气。因此在我的认知里是十分矛盾的，一方面希望研发尽可能不要让运维单独承受项目建设过程中的一切错误，因此在数年前，我也在我的一些客户那里推动“系统上线前合规性检查”这项工作；另外一方面我也知道，要让研发与建设完全靠谱，交付高质量，低运维成本的系统，在大多数传统行业中基本上是无望的。

上图是2008年我给一个国企的IT部门画的一张图，其中的重点是在下面两边的两个圈子，通过严管工程验收和软件验收测试，从而御敌于国门之外，尽可能让运维部门少背锅。实现第一步目标后再将运维的触角前推，积极参与系统设计，甚至参与需求开发工作，从而解决运维中的痼疾。实际上这个想法在大多数传统行业企业中极难实现。有些企业确实加强了前期设计，但是很快这块蛋糕也落入了研发单位的手中，最后换汤不换药，因为研发单位天然是更注重研发的优雅与低成本的。

随着IT技术的发展，云平台的广泛应用之后，DEV与OPS的融合才真正成为可能。二者融合之后是不是真的能够解决以前的传统顽疾呢？DEVOPS一度热度很高，并且这个热点到现在还在持续，不过现在IT部门的领导已经不再像前几年一样认为DEVOPS能够解决一切了，因为既然存在融合就说明必然存在鸿沟。挖沟容易填坑难，DEVOPS也不是一蹴而就的。

昨天一下飞机就去参与一个项目的交流，交流的双方有软件开发人员，也有项目交付团队的负责人，还有平台提供商的技术人员。通过这个交流我发现，当我们运维希望开发来拯救的时候，实际上开发与交付也在希望平台能够拯救他们。平台提供者自以为他们能够拯救一切的时候，研发与运维发现平台并不是万能的。当运维人员希望研发多考虑运维的时候，研发人员并不想做运维，甚至也不想因为加入运维需要的指标采集而加大研发的工作量。

不管怎么样，标准化与平台化是解决研发与运维矛盾的必然之路，云平台的出现为解决以前这个问题提供了可能性，是粘合DEV与OPS的粘合剂。只不过用过粘合剂的人都清楚，我们能够买到的商业化批量生产的胶水虽然都号称能坚固地粘合物品，但是实际效果都不太理想。无论是公有云还是商业化的、开源的云平台，都只能有限的融合二者。IT能力很强的企业会根据自己的自身特点来研发适合自己的平台，不过大多数企业只能采用商业购买的方式来采购自己的云平台，因此DEV/OPS之间的很多坑还是需要研发或者运维来填补。

在填坑方面也是有技巧的，从哪挖土，填哪种土，如何压实，是否考虑到了水土流失，都体现了填坑者的能力。而最为科学的方法是基于数据与模型的。让研发与运维都能在一个指标体系和模型体系下去考虑问题，让研发与运维能够在同一个维度上思考是十分困难的事情，但是也是必须的。自动化、数字化是一切的基础。只有构建出较为准确的数字化模型，自动化才能更为精准的解决研发中的问题，运维也才能够更好的理解系统运行的内部状态。

数字孪生是实现DEVOPS的终极形态中必然存在的基础技术。随着模型能力的提升，研发的变更可以直接以模型的方式被重新计算，随之而来的容量、负载、性能等都可以在孪生体上得以展现。这样建设部门可以提前为应用变更准备资源，运维部门也可以动态调整各种监控阈值，计划部门则可以自动更新今后几年的投资计划。这些假设在很多人看似虚无缥缈，遥不可及。不过随着IT部门数字化的深入，企业在IT运营上的管理的精益化，我想这个场景在未来必然会出现。

devops it运维自动化

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

谁来拯救，亦或拯救了谁？

评论