在写字楼、商场甚至小区里，WiFi信号满格却连不上，或者刚连上就断，这种情况太常见了。很多人以为是AP（无线接入点）数量不够，其实问题可能出在软件更新和系统维护的流程上。
上线像送外卖，不能只管送到
开发团队把新版本发出来，就像厨师做好了饭。但要是运维不接招，或者交接混乱，这顿饭就送不到用户手里。比如某次商场做促销，临时加了优惠页面，结果WiFi后台更新后没重启服务，导致大量用户连接失败。不是代码写得不好，而是发布过程没人盯。
持续交付讲的是“随时能发”，但发完能不能用，得靠运维兜底。两者之间如果只是扔个包、回个消息就完事，迟早出问题。
自动化脚本比微信群靠谱
以前有个项目，每次更新都靠开发在群里喊：“@运维，新版本传网盘了！”运维再手动下载、部署、改配置。中间一旦漏看消息，或者配错了参数，现场WiFi就开始抽风。
后来改成CI/CD流水线，代码一合并，自动构建镜像，推到测试环境跑一遍连通性检查，没问题就通知运维确认上线。运维点一下按钮，更新就在非高峰时段静默完成。整个过程不需要人传话，也不怕谁请假。
deploy-wifi-service {
stage: deploy
script:
- docker build -t wifi-api:$CI_COMMIT_SHA .
- kubectl set image deployment/wifi-api api=wifi-api:$CI_COMMIT_SHA
only:
- main
}配合不是开会，是共用一套语言
开发说“服务起来了”，运维听到的是“端口监听了、健康检查通过了”。所以双方得约定好什么叫“交付完成”。比如必须提供日志路径、监控指标、回滚方案，而不是一句“你试试看”。
某高校宿舍区升级WiFi认证系统，开发提前把部署文档写进代码仓库，包含每个接口的作用、预期响应时间、常见错误码。运维按图索骥，出了问题直接查对应模块，不用再打电话问人。
线上就是战场，配合决定反应速度
有一次展会现场，突然一半区域断网。排查发现是配置文件漏了一个字段，导致新AP无法注册。如果是过去，得等开发改完重新打包，再传给运维重装——至少两小时。现在有自动回滚机制，运维一键切回旧版本，网络十分钟恢复。同时开发在隔离环境修好问题，重新走流程发布。
这种快速响应，靠的不是个人英雄主义，而是交付流程中早就设计好了协作节点。每一次发布，都是一次默契的接力。