云原生、DevOps、ChatGPT，真能“杀死”运维？

本文访谈部分源自快猫星云创始人来炜此前访谈分享。6月16日-17日·北京，由来炜出品的《可观测性技术与实践》专题将在WOT全球技术创新大会期间呈现。来自美团、快猫星云、格睿时代...的众多技术大咖们将带来：美团可观测性平台：Raptor建设与实践、帮一千个微服务落地SLO、面向故障处理的可观测性体系建设、云原生时序数据库的挑战和架构设计等精彩分享。

点击阅读原文可了解活动详情，或扫描下方二维码了解WOT更多精彩主题。WOT大会九折期即将结束，现在购票优惠多多。

运维行业没有消亡

Q：有些运维老炮反映公司对运维的价值所知甚少，您是怎么给公司讲清楚运维价值的？

来炜：把工作的价值，如何通俗易懂的给公司管理层讲清楚，并取得理解和支持，是所有中后台技术团队普遍面临的难题，否则失业分分钟的事情，运维工作的价值讲清楚更是难上加难。

从我的朋友圈来看，时不时就会看到劝运维下岗/转行的帖子：比如瑞典马工的《是时候让运维集体下岗了》，振聋发聩，开篇就提到：明人不说暗话：在云原生和DevOps成熟的今天，运维作为一个岗位和团队已经完成了历史任务，应该退出舞台了。

再比如带我入行的井老板，用心良苦的劝导：随着科技的发展，时代的变化，一个岗位的消亡是很正常的事情，及时做好调整和规划才是思考的重心。

但是，运维这个岗位以及背后的运维人，从来都是一次次站在要被淘汰的边缘徘徊，又一次次倔强的起死回生，柳暗花明。他们往往乐于自嘲、主动拥抱危机、敢于求变。回想下，近十年来，云计算也好、云原生也罢、DevOps 也算、SRE 也行，所有这些 IT 的大变革，都是尝试在不断优化和改进“大运维”这个领域。运维这个行业没有消亡，反而是不断进化，生发出了新的内涵。

这说明了什么？说明运维很重要，说明运维也很难！但是如何把这个价值说清楚，我们要从站位、目标设定、投入产出比上来分别着手分析。

运维人：要坚定地和业务站在一起

Q：您觉得运维工作最重要的几个目标是什么？您是怎么落地这些目标的？运维的价值如何更好的得到体现？

来炜：聚焦经典的运维领域，最主要的几个工作职责是：

（1）代码发布和交付（delivery），做好最后一公里的价值交付；

（2）提升架构的可伸缩性（scalability）并付诸实施；

（3）保障系统的稳定性（reliability）并不断改善；

（4）在满足前三项目标的同时，不断优化并降低系统的运行成本（finops）。

如果你发现自己的工作，并不是围绕着以上范畴展开，那么有两种可能，你不是运维或者你的工作超纲了！

明确了工作范畴，说大点就是明确了运维的使命之后，设定目标就相对容易些了，比如：

（1）针对代码发布和交付，可以简单的用发布次数来度量；

（2）针对系统的伸缩性，可以用扩容的时效性来度量；

（3）针对稳定性，我们可以通过观察核心功能的不可用时长来度量；

（4）针对系统运行成本，我们可以计算到每完成一笔核心交易所花费的资源成本和人力成本来表示和追踪。

关于如何体现运维的价值，首先我们运维人要转变的是态度和立场：坚定地和业务站在一起，争取共背业务目标。我举个例子，HR部门，也是属于公司内部后台的不能再后台的部门了，但是我所接触过的优秀的HR中，不管是recruiter、还是hrbp，从来都是把自己当作业务部门的一份子，把业务部门的目标当作自己的目标。当立场一致，大家都是自己人的时候，价值就好说了。

其次，价值这个事情，永远都是和“成本投入”相对应的。你如果组建了一个很大的运维团队，人力成本在公司很显眼，那么你就很容易成为老板眼中的“重点关注对象”，也会受到业务方更苛刻的挑战。正所谓，楚人无罪怀璧其罪。客观上来讲，运维团队的资源投入，一定是要和业务收入相匹配的，过高过低都是不健康的，不利于团队发展的。所以，“运维的价值创造”最后会落到运维效率的竞争上来。

最后，关于价值，定量和定性的描述都得有。譬如和行业水平的定量对比，来自公司内业务部门满意度调查的定量数据。也要有比如对公司战略项目支撑中的“存在感”这些定性数据。

ChatGPT或将代替初级运维岗位

Q：ChatGPT这样的AI能力您觉得未来是否有可能解决运维行业的问题？

来炜：首先我们看看，ChatGPT的核心优势是什么？ChatGPT，在知识的丰富度、自然语言理解能力（以及上下文理解）、内容生成能力方面，有着代际的革新。然后，我们再分析下运维行业的核心问题是什么，是缺少领域知识吗？是交互效率低吗？是内容输出难吗？

以上都不是，运维行业所处理的问题，本质上还是一个系统性的工程问题，是为了解决IT系统价值快速交付的问题、解决伸缩性的问题、解决稳定性的问题，是不断提高系统运行维护性价比的问题。

目前来看，云计算、微服务对于运维行业的改变来的要更实质性一些。ChatGPT能有效改善运维行业知识沉淀的问题，或许会很快代替一些初级的运维架构师岗位。

《可观测性技术与实践》专题精彩内容

美团可观测性平台：Raptor建设与实践

美团技术专家任天：Raptor作为美团可观测性平台，不仅融合了前端监控、基础设施监控、应用层监控，同时也给业务提供指标、链路、部分日志监控能力，让业务能够无死角的观测到系统；在耗时检测方面，涵盖了业务端到端耗时、后端整体耗时、中间件耗时等，满足业务各阶段的可观测诉求。作为可观测系统，Raptor每日承载着PB级监控流量，百万的告警策略，覆盖前后端的观测能力，给业务提供及时有效的观测和预警，为业务保驾护航。

本次分享，主要从Raptor整体视角出发，介绍美团可观测体系的建设之路以及应用实践、从监控系统Cat到可观测系统Raptor的演进过程。以及如何支撑美团PB级监控数据，满足业务低延迟、高可用、低成本的诉求。最后针对当前面临新的诉求和挑战，讨论Raptor下一步的工作重点和方向。

面向故障处理的可观测性体系建设

快猫星云COO秦晓辉：服务稳定性保障是一个系统性的工程，建设一个完善的可观测性体系，是稳定性保障的基础，而稳定性保障也是可观测性体系服务的最重要的场景。然而目前企业内部普遍面临着一个痛点，虽然各种观测数据都有了，但在故障发现、故障定位上仍然存在发现慢，定位难，协同难等问题，在稳定性保障上技术团队经常处于被动。很多企业可能已经不缺少数据，但缺少的是将数据价值在稳定性保障领域发挥出来的产品、方法和最佳实践。

快猫星云团队总结了解决企业可观测系统落地问题的三大要素：数据、平台、场景。假如把建设一套面向稳定性保障的可观测系统比喻为做一道好菜，那数据就是食材，平台就是炊具，场景就是厨艺。

云原生时序数据库的挑战和架构设计

格睿时代技术副总裁冯家纯：随着企业上云和云原生基础服务的发展，作为需要存储和处理海量传感器数据的时序数据库也需要往云原生架构迁移。在这一过程中面临诸多挑战：面向弹性设计的 ServerlessDB 架构；海量规模的时序数据在高并发读写下的可用性和稳定性挑战；时序数据特有的高基数问题和数据压缩问题；存算分离架构带来的性能挑战；混合时序和分析负载带来的算力隔离和调度问题。

我们在实现 GreptimeDB 这个分布式、云原生的时序数据库过程中，直面这些挑战，并将在本次分享中给出我们的设计选择和背后的思考。

以上精彩内容都将在6月16日-17日·北京的WOT全球技术创新大会期间呈现。

点击可直达大会详情页