Serverless会让DevOps消失吗？

我先说结论吧：DevOps不会消失，但它干的活儿，真的在变。 这感觉就像汽车普及了，马车夫不是失业了，而是得去学开车、学修车，甚至去设计更快的公路。

以前我们搞DevOps，那是真得“上得厅堂，下得机房”。半夜被报警短信吵醒，顶着黑眼圈去机房重启服务器，或者对着密密麻麻的监控图表找哪个Pod又OOM了。那种对底层资源的“掌控感”很强，但也真是累。

Serverless来了，它干了件什么事儿呢？它把“服务器”这个最底层的抽象，给打包藏起来了。对我们来说，就好像从自己盖房子、通水电，变成了直接租用精装修的公寓，拧包入住。你不需要关心墙里的电线是怎么走的，水管是哪家公司的，你只管在房间里布置你的家具（也就是你的业务代码）。

那原来DevOps的兄弟们都去干啥了？

• 从“救火队员”变成“城市规划师”：不用天天盯着CPU使用率是不是爆了，而是去思考：我们的函数冷启动时间怎么能优化到100毫秒以内？各个Serverless服务之间的权限边界怎么划分最安全？事件驱动的架构怎么设计才能更优雅？这些问题的层次，其实更高了。
• 关注点从“基础设施”漂移到“应用本身”：以前可能30%的精力在业务逻辑，70%在伺候环境。现在可能倒过来。我们有更多时间去琢磨怎么做好灰度发布、如何设计更健全的故障熔断和降级策略、怎么把可观测性做得更细致——毕竟，你看不到服务器了，但应用本身的健康度反而更重要了。
• 拥抱“平台工程”：这是个大趋势。公司内部需要有人搭建和维护那个让所有开发同学都能愉快使用Serverless的“自助平台”。怎么把云厂商的Serverless服务封装得更易用？怎么集成内部的监控、日志、权限体系？怎么制定最佳实践和规范？这些活儿，本质上就是更高级、更聚焦的DevOps。

一个真实的“阵痛”

我们团队去年试着把一个小的活动页面迁移到Serverless架构上。一开始大家可开心了，再也不用预置容量，流量来了自动弹，感觉走上了人生巅峰。但很快问题就来了。

有一次活动峰值，某个函数的并发实例数飙升，它依赖的一个第三方API突然扛不住了，响应变慢。结果你猜怎么着？因为函数超时，自动重试，反而发起了更多请求，雪崩了。那一刻，我们几个对着控制台一脸懵，传统的服务器监控图表没了，我们熟悉的排查路径断了。

后来花了大力气，重新梳理了链路追踪，给函数配置了合理的超时与重试策略，并加上了完善的降级逻辑。你看，服务器管理的负担是轻了，但对分布式系统设计、容错能力的要求，一点没少，甚至更高了。 DevOps的技能树，在这里点向了新的分支。

所以，别慌

说到底，DevOps的核心思想是啥？是开发和运维的协同，是快速、可靠地交付价值。这个目标从来没变过。Serverless只是提供了一个更强大的“武器”，让我们能更专注于这个目标本身，而不是在给武器保养上花费太多时间。

它不会让DevOps消失，只会淘汰掉那些只停留在“手工操作服务器”层面的工作方式。这对我们每个人来说，其实是个好消息。意味着我们可以从重复性的体力劳动中解放出来，去解决更有挑战、也更有价值的问题。

老王，下次撸串，我请你。咱们不聊退休，聊聊怎么给你的K8s集群也加上点Serverless的敏捷劲儿，怎么样？