说实话，我不太喜欢“哪里有问题哪里就有他的身影”的说法。其实我们的工作，最好的状态不是“到处救火”，而是“根本没火可救”。我更愿意说：在团队需要的时候，我会出现在该出现的地方。故障处理的第一现场、技术分享的交流平台、疑难问题排查的台前幕后、项目推进的沟通协调会、深夜执行变更的ECC大厅……这些地方都有我的身影，但从来不是我一个人。运维从来不是单打独斗的活儿。

我们团队有个习惯，遇到技术问题，不光要解决，还要写下来。问题是怎么发现的、排查思路是什么、最后怎么处理的、下次怎么预防……全部整理成文档，放在内部知识平台上。这些年，我陆陆续续写了一百多篇。从技术原理介绍到具体操作流程，从常见故障手册到应急响应清单。新同事来了，不用从头问人，翻翻文档大部分问题就能自己搞定。

有次一个年轻同事跟我说：“你这文档写得比教程还细，我第一次照着做就成功了。”我说：“那是因为我踩过的坑都写在里面了，你就不用再踩了。”这不是什么高尚，一个人踩坑，十个人填坑，太浪费了。我多花一个小时写清楚，后面几十个人就能省几百个小时。这笔账很划算。

我们的工作有一个重要的类型是“变更”。系统要修复故障、要升级、要扩容、要调整参数，都得走变更流程。听起来枯燥乏味，但每一行命令都跟旅客能不能顺利值机息息相关。大家常说“没有变更就没有伤害”，但变更也是保障系统稳定运行的关键工作。

团队里我是安全保障的把关人。有点儿“强迫症”的我，事先怎么检查、事中怎么确认、事后怎么校验，每一步都要写清楚，不能有“差不多就行”。有时候方案被打回去好几次，同事问“至于吗？”，我会说“至于，因为线上环境不是试错的地方。”

还有一条原则：出了问题，不能只是把故障恢复了就完事，必须搞清楚背后的机制原理。为什么会出现这个问题？是配置写错了，还是设计有缺陷？能不能从系统层面优化，让它再也不出同样的问题？

这叫“闭环”。听着像套话，但做起来就是死磕。磕完了，系统的可靠性就涨一点点。一点一点攒起来，就是我们敢说“安全平稳”的底气。

刚入行那会儿，我习惯一行一行手敲命令。后来觉得不对。同样的事儿重复做，不仅累，还容易出错。人该做机器做不了的事，重复的事交给脚本去做。

于是我开始写自动化脚本。原来要花十分钟一条条查的信息，现在脚本跑几秒就出来；原来需要半夜盯着屏幕手动执行的操作，现在写好参数一键触发。标准化、流程化、自动化，这三个词是我保障安全的法宝，但也不是我一个人的。我喜欢跟团队里其他同事分享技术共同进步，让大家掌握了各种技能和处理经验，这种分享精神，让大家都能成为技术能手，让“传帮带”的好风气带动每个人在技术上追求卓越。

把重复劳动交给机器，把人解放出来做更有价值的事。什么更有价值？琢磨怎么让系统更稳、更快、更扛造。

有时候深夜被监控告警叫醒，爬起来连进系统处理，处理完发条记录倒头继续睡。第二天上班，同事说“昨晚那个告警你处理的啊”，我说“嗯，小事”。有时候其他同事有特殊情况临时需要换班，我也会第一时间顶上，逢年过节值个班也早就习以为常。

这种“小事”，对旅客来说就是“什么都没发生”。而什么都没发生，就是我们最大的成功。

回头想想这十二年中工作的点点滴滴，我没想过“奉献”“使命”这些大词，系统交到我手里，我就得让它好好跑着。旅客通过我们维护的系统买票、登机，可能是去见很久没见的朋友，可能是去谈一个意义非凡的项目，也可能是出完差拖着疲惫的身体回到家中。我跟他们都不认识，但因为这套系统，我们产生了奇妙的联结。我把系统守好了，他们就能顺利到达想去的地方。

这事儿挺有意思的。

系统运维是一项平凡普通的工作，也不怎么被直接感受到。但每个深夜亮着的显示屏、每根插得稳稳的网线、每次系统静默的切换，仿佛都是我们在说：“放心飞，后面有我们。”

一个个系统运维工程师作为幕后的工作者保障着系统的稳定运行，这个稳定是无数个夜晚被电话叫醒的报警处理，是无数个夜晚机房和ECC大厅忙碌的身影，是无数个节假日放下休闲娱乐专心值班的工作责任，是无数个工作日始终如一的辛苦建设和细心维护。

我叫马晓平，一名民航业的IT系统运维工程师，我是这众多系统运维工程师中的一员，也是这无数个日日夜夜中的一个身影。

当然也可以叫我“修电脑的”——修什么不重要，只盼系统里的旅客，都能平安落地。