凌晨三点，我蹲在工位上看Grafana那个橘红色的“critical”报警，旁边的咖啡杯早就空了，屏幕的光打脸上，跟鬼一样。那是我入职运维开发岗的第二周，第一次独立值班，碰上了Redis主从切换导致的全站超时。当时我脑子里只有一篇现成的应急预案，但真到了手动执行起来，连redis-cli --replicaof都打错了两次。事后复盘，leader没骂我，只问了一句：“为什么我们每次都是靠人出事才想起做点东西？”
很多讲运维开发的文章，张口闭口就是“自动化”、“流水线”、“稳定”。但我觉得这活儿的核心不是把一切能自动化的都自动化，而是让系统变得足够“无聊”。传统运维像救火队员，每天都有新刺激；而运维开发的终极目标，是让系统无聊到没人愿意在群里@你。这个观念跟很多开发同学是冲突的——他们巴不得每个功能都带点“惊喜”，而我们只能一遍遍把“惊喜”摁回去。
举个例子，我们有个老服务，日志经常打错误，但业务其实没事。一开始大家习惯性忽略，后来阈值一调，直接取消这个报错的告警，然后做了个指标来跟踪它出现的频率。一个月过去，发现它偶尔会涨，但也影响不大。于是我把这个频率和发布记录做了关联，最后发现是某个配置项在测试环境被改掉后带回生产导致的。你看，真正的稳定性不是靠删掉报警，而是知道哪个看似“废话”的日志其实是一根神经末梢。运维开发干的活，就是把这些神经末梢接进一个能自我解释的系统里，而不是让大脑每次都亲自去理一遍。
我越来越觉得，运维开发和SRE的边界不重要，重要的是你愿不愿意承认，你写的那些自动化脚本、监控规则、混沌实验，本质上都是在给“未来犯蠢的自己”留后路。别老想着搞一套花里胡哨的AIOps，先把你手头那个告警收敛率提上去，比啥都实在。有次我半夜被电话叫醒，原因是有人跑了个pkill -9 xxx，直接导致另一台机器上所有线程崩了。这种事故，任何方法论都救不了，只有靠流程和人的认知。所谓全新观点，可能就是承认：我们不是要让系统更好，而是要让系统在变好的同时，不让人更累。这世界上的确定性太少，运维开发是唯一一个把“无聊”当褒义词的岗位。
