那些没人看见的打工人时刻：论"隐形劳动"的自我修养
那些没人看见的打工人时刻：论”隐形劳动”的自我修养
今天是周四，上海的天气说变就变。早上出门的时候还晴着，中午就开始飘雨。这种天气让人有点犯困，坐在工位上对着屏幕，眼睛不自觉地就飘向了窗外。
窗外是什么？是陆家嘴的高楼，是来来往往的人群，是这座城市永不停歇的节奏。地铁在地下穿梭，外卖小哥在街头飞驰，写字楼里的灯一盏一盏亮起来。
我有时候会想，这座城市里有多少人，正在做着和我一样的事情——对着屏幕，敲着键盘，处理着那些”看起来很简单但其实很复杂”的隐形劳动。
什么是”隐形劳动”？
说起来，我们的工作里有多少是”看得见的”？
比如你写了一段代码，上线了一个功能，这个成果是可以量化的——commit 记录在案，代码行数可查，功能文档可查。这种工作，你可以说”今天我完成了XXX”，写在周报里也是有分量的。
但还有更多的工作，是没法写进周报里的：
- 这个 bug 为什么之前没发现？因为上次有人改了个配置没通知我，我花了两个小时排查。
- 这个服务为什么这么稳定？因为我半夜爬起来处理了一次故障，但没人知道。
- 这个流程为什么这么顺？因为我把之前踩过的坑都填平了，但新人只觉得”本来就该这么顺”。
- 为什么这台服务器从来没出过问题？因为我每周都在凌晨默默更新补丁、清理日志、监控告警。
这些工作，我管它们叫”隐形劳动”。
隐形劳动的特点是：你做了没人看见，但你不做马上就会出问题。
就像家里的电一样——你从来不感谢电线，因为电”本来就该有”。但如果哪天真停电了，你才会意识到，平时习以为常的东西，原来是需要人维护的。停电的时候，你才会想起那个在背后默默维护电网的人。
运维工作就是这样。服务器正常运行是”应该的”，没人会发邮件表扬你。但如果服务器崩了，第一时间找的就是你。”服务器怎么又挂了？”——这句话大概是每个运维都听过无数遍的。
今天我做了哪些”隐形劳动”？
说起来，今天做的事情还挺多的，但如果你要我写进周报，我能写的大概只有两三条。
剩下的时间，都花在了一些”看起来没什么但其实很重要”的事情上。
第一件事：整理了一个配置文件
上午花了一个多小时，把某个服务的配置文件重新整理了一遍。为什么要整理？因为之前维护的人换了好几个，每个人的习惯不一样，导致配置文件的格式乱七八糟。有些参数重复设置了，有些参数设置了但根本没用，还有些参数你知道它存在但不知道是干什么的。
这种情况，大概每个运维都遇到过。一开始接手一个服务，看到配置文件里密密麻麻的参数，有种”这是啥这又是啥”的感觉。你不知道哪些是关键的，哪些是可以删的，哪些是”前任”留下的历史遗产。
这种事情，做了没什么”功劳”，但不做的话，以后每次排查问题都要多花时间。你得先搞清楚这个参数是干啥的，才能判断它是不是问题所在。
我花了一个多小时，把配置文件里的每一个参数都过了一遍。有些参数我知道是干啥的，有些不知道——不知道的就上网搜，搜不到的就结合日志和现象推断。最后整理出了一份”参数说明表”，以后再遇到问题，直接翻表就行，不用再一个个查了。
你说这算不算工作？当然算。但你要我写进周报，我只能写”整理配置文件若干”。一个”若干”，包含了多少心血，没人会知道。
第二件事：更新了一个文档
下午花了大半个小时，把某个操作流程的文档更新了一下。不是因为文档丢了，而是因为流程变了，但文档还是老版本。
比如之前的流程是”先启动服务A，再启动服务B，最后启动服务C”。但现在变成了”服务C要在服务A之前启动，否则会有连接问题”。这种变化，如果你不看代码、不问人，根本不知道。
是谁改的？可能是半年前某个同事。他当时改了代码，但忘记更新文档了。或者他更新了文档，但更新在了另一个地方，而你看到的是旧版本。
这种”文档和现实不一致”的问题，大概是最常见的隐形劳动。你不能怪之前的同事，因为他们的工作重点是”把事情做成”，不是”把文档写好”。写文档这种事情，做了不显眼，不做也没人催，所以很容易被无限期推迟。但这种”债务”积累多了，后来的人就要还——而且还的时候往往是在出问题的时候。
我这次更新文档，就是想把之前积压的一些”文档债务”给还掉一些。不求写得多完美，只求”文档和现实一致”，这样下次遇到问题，至少有个地方可以查。
第三件事：排查了一个莫名其妙的问题
这个问题很有意思。某台服务器的应用日志里，每隔几分钟就会有一条 WARNING。WARNING 的内容是”连接池可能会满”。
这个 WARNING 已经存在了很久，之前的人都选择忽略它——毕竟只是 WARNING，又不是 ERROR，服务也没实际受影响。告警群没炸，值班手机没响，好像一切正常。
但我今天突然想知道：这条 WARNING 是什么意思？是真的有问题，还是误报？还是说，连接池真的要满了，只是还没到临界点？
查了半天，发现是代码里有一个阈值设置得太低了。每隔几分钟触发一次，刚好卡在临界点上，所以会打印 WARNING。但因为阈值太接近临界值，稍微有点波动就会触发。
这个问题，严格来说不算”故障”，但它确实是一个隐患。如果哪天流量真的上来了，这个阈值就会成为瓶颈——连接池满了，新请求进不来，开始排队，排队时间长了超时，超时多了服务就不可用了。
链条就是这样断的。一个小问题，积累到一定程度，就会变成大问题。
我没有改代码——因为这涉及其他部门的同事，需要走流程、需要排期、需要测试——但我把这个问题记录了下来，准备下周开会的时候提一下。
这种”发现了但没解决”的工作，最让人纠结。你知道这是个问题，但你不能马上改，因为改代码需要流程、需要排期、需要其他团队的配合。但如果你不记录下来，这个问题可能就会被遗忘，直到有一天变成真正的故障。
所以我选择记下来。记在日报里，记在问题清单里，记在这篇博客里。
隐形劳动的”好处”
说了这么多”隐形劳动”的坏处，也来说说它的”好处”吧。虽然这些”好处”听起来有点阿Q，但有时候需要给自己找点心理安慰。
第一，它让你的工作”不可或缺”
隐形劳动虽然看不见，但它让你的工作变得”不可或缺”。
你可以不写代码，不做项目，但如果所有隐形劳动都不做了，系统马上就会出问题。服务器没人维护，会崩。网络没人优化，会慢。配置没人整理，会乱。文档没人更新，会过时。
这种”不可替代性”，是职场安全感的重要来源。
你可能没有牛逼的背景，没有光鲜的项目经历，但你在这个位置上，知道这个系统是怎么跑的，知道出了问题应该找谁，知道哪些地方有坑——这些”隐性知识”，不是靠学历或者证书能换来的，是靠时间堆出来的。
就像家里的老物件，你知道它怎么用，坏了怎么修。虽然不值钱，但离了你还真不行。
第二，它让你积累”隐性经验”
隐形劳动的另一面，是隐性经验。你踩过的坑、填过的雷、排查过的问题，都是宝贵的经验。
这些经验不是从书里学来的，而是从无数次”只有你知道的”时刻里积累的。比如：
- 这个问题，之前某台机器遇到过，当时是怎么解决的？
- 这个配置，不能用默认的，得改成多少多少才行？
- 这个告警，看着吓人，其实可以忽略，是误报？
- 这个时间点，不适合重启服务，因为有个定时任务在跑？
它让你在面对新问题的时候，能够快速判断”这个我之前见过”。这种判断能力，是区分”普通运维”和”资深运维”的关键。
新人在遇到问题时，需要从头排查，步步推理。老人在遇到问题时，可能一眼就能看出问题所在——因为他们见过类似的情况，知道这种”症状”通常对应哪种”病因”。
经验的积累，靠的是无数次”只有你知道的”时刻。每解决一个问题，就是给自己的”经验库”添加一条记录。
第三，它让你的周报”看起来很闲”
好吧，这个不算好处。但你要是学会用”隐形劳动”填充周报，你会发现自己突然变得”忙”了很多。
“本周完成了配置整理工作，优化了3个服务的启动流程”——听起来很厉害对吧？但实际上就是花了两个小时整理配置文件，然后更新了一下启动脚本。
“排查并解决了3个历史遗留问题”——听起来更厉害了。但实际上就是查了两个小时日志，然后发现是某个阈值设置得太低了。
周报嘛，有时候就是”文字游戏”。同样的事情，换个说法，看起来就不一样了。
当然，这不是教你”摸鱼”，而是教你”更准确地描述自己的工作”。隐形劳动也是劳动，只是它比较难以量化而已。
隐形劳动的”自我修养”
说了这么多”隐形劳动”，最后也想给自己打打气。
第一，学会记录
隐形劳动最大的问题，是做完就忘了。下次遇到同样的问题，又要重新排查。
所以，学会记录很重要。哪怕只是一个简单的笔记：”今天发现XXX服务的连接池阈值设置偏低，可能会在未来成为瓶颈”——这条记录，可能在未来某一天救你一命。
我现在有一个习惯：每天写日报的时候，会把当天排查的问题都记下来。问题现象、排查过程、解决方案，一两句话就行，不用太详细。重要的是”以后再遇到，知道去哪里找答案”。
有时候我还会把一些”临时解决方案”记下来，标注”临时”两个字。因为有些问题暂时没法根治，只能先用 workaround 顶着。这些 workaround，如果记不住，下次遇到又要花时间回忆。
第二，学会”可视化”
隐形劳动虽然不好量化，但你可以尝试让它”可视化”。
比如每次处理完一个问题，简单记录一下：问题现象、排查过程、解决方案。这样积累下来，你就有一份自己的”问题排查手册”。以后遇到类似问题，直接翻手册就行，不用从头排查。
我还尝试用”时间线”的方式记录：今天处理了一个什么问题，花了多长时间，是自己解决的还是求助别人的。这样积累下来，能清楚地看到自己的”成长轨迹”——以前一个问题要花一天，现在可能只需要一小时。
有时候我还会画一些简单的流程图，把排查问题的思路画出来。这个问题是什么症状，可能的原因有哪些，应该怎么排查，排查的顺序是什么——这些东西，画出来之后思路会清晰很多。
第三，学会接受”没人看见”
这是最重要的一点。
隐形劳动之所以叫”隐形”，就是因为它不会被所有人看见。你不能期待每次做好事都被表扬，就像你不能期待每次服务器正常运行都被发奖金。
打工人的心态要放平：做了这件事，是为了对得起自己的专业，而不是为了得到别人的认可。
当然，如果你的领导是一个懂行的人，他会知道你的价值。但如果遇到一个只看周报、只看结果、不看过程的领导，那也没关系——你自己知道就行了。
价值的衡量，不应该只靠别人的评价。你做了多少事，你积累了哪些经验，你解决了哪些问题——这些，你自己心里有数。
晚上：写给同样在做”隐形劳动”的你
写到这里，已经快晚上九点了。
今天的天气有点闷，窗外的雨不知道什么时候停了。抬头看看办公室，已经没剩几个人了。隔壁工位的老王不知道什么时候走的，零食袋还留在桌上。
我今天做了什么？说起来很简单：整理了一个配置文件，更新了一个文档，排查了一个小问题。没有什么”惊天动地的大项目”，没有什么”史诗级的技术攻关”，没有什么”从0到1的创新”。
但这些”隐形劳动”，让我的系统在明天会更稳定一点，让我的文档在以后会更好用一点，让我的同事在遇到问题时会少踩一个坑。
这就是我的工作。
在上海这座城市，打工人的价值不只是写在代码里的那些，更是藏在配置文件里、泡在文档里、埋在排查过程里的这些。
隐形劳动，不丢人。
它是专业的一部分，是责任的一部分，是”对得起自己”的一部分。
明天继续加油吧。
作者：小六，一个今天做了很多”隐形劳动”但周报可能写不满三行的普通打工人
题图：Picsum Photos，授权可商用