科技公司上班太难了：熬人的不是加班

科技公司上班太难了，难的地方基本不在工时表上。真正磨人的是那种一天被切成七八段、每段都要重新进一次状态的感觉。代码写到一半被拉去对需求，回来刚把上下文捡起来，告警又响了。等晚上十点终于没人打扰，活儿才干得动——于是外人一看，你天天走得最晚，白天的可用时间早就碎掉了。加班只是结果，不是原因。

科技公司上班太难了，难的不是忙，是碎

脑力活有个隐形成本，就是进入状态这一段路。写代码、调配置、排查一个莫名其妙的报错，都要先把一堆东西装回脑子里。有人来问一句「这个多久能好」，你答完，脑子里的东西就掉一半。所以别觉得这是矫情，一个人一天能被打断的次数是有上限的，过了那道线，效率往下掉，还格外累。做运维做开发的都有体会，最舒服的半天往往不是活少的半天，是没人打断的半天。

带过小团队之后我更能理解了。有人看着像在工位上刷手机，其实是在等一个跑得很慢的构建；有人走开十分钟，是去楼梯间躲开那个一直喊他名字的工位。这些都不算摸鱼，是给脑子留口气。反过来，一个团队里最先被耗干的，往往是那个什么都懂一点、谁有问题都去问他的人。

需求改两轮很正常，改完不通知才要命

需求反复这件事本身不致命。这行产品不成熟、市场变得快，改需求很正常。致命的是改了不通知执行的人。我见过上线前一天才发现某个字段的口径换了，前后端各按各的理解做，演示的时候对着客户现场圆场。你说这算谁的责任？都算，也都挺冤。

还有一种更隐性的：需求没动，但默认规则变了。原来那个页面只是看看，现在要绑定手机号；原来导出不限量，现在后台加了限流。没人写在文档里，大家都以为别人知道。这种坑最耗人，它不体现在工时上，体现在你被叫起来解释的那一刻。

告警比老板更会挑时间

老板半夜找你，一年也没几回；告警群一晚上能响好几遍。做站、做云上业务的人应该都熟悉这种节奏。为什么夜里事多？因为跑批、备份、证书自动续期、定时任务，全挤在低峰期干。你白天不给它们排好队、不给它们做好重试和兜底，它们就半夜来找你。

所以后来我养成一个习惯：告警要分级。能白天处理的就攒着，能自动恢复的先让它自己恢复，别什么风吹草动都做成电话打过来。人是肉做的，半夜被拎起来几趟，第二天基本报废，出了错还得你担。

环境一多，人就变成人肉配置中心

测试一套、预发一套、线上还分主备分区域；一个站还要拆成静态资源、应用、数据库、缓存。每套环境一份配置，改参数的时候最怕漏掉某一处。不是人干不了，是这种活的错误率天然就高。这也正是现在讲配置集中管理、讲基础设施即代码的原因，不是为了赶时髦，是怕人靠记性。

小公司更明显。一个「什么都管」的人，手上挂着十几个面板和后台入口。哪天真找不到某个控制台在哪儿，那种心慌比加班难受多了。所以不要笑那些把登录信息、端口、路径整理成一张表的人，那都是被坑过之后才养出来的习惯。

文档不是给领导写的，是给三个月后的自己写的

文档这件事我的态度很朴素：不用写得漂亮，写清楚怎么重启服务、日志落在哪个路径、哪一步最容易踩空就行。比如 /etc/nginx/conf.d 下面到底改哪个文件，证书放在哪个目录，改完要不要 reload。就这几行字，关键时刻能替一个人省下半天，也能让接手的人不至于两眼一抹黑。

上线窗口定在半夜，图的是省事不是拼命

很多公司上线挑凌晨，不是领导喜欢折腾人，是那个时段流量小，出问题影响面小，回滚也方便。麻烦在于第二天还要照常上班，人扛不住。比较靠谱的做法是第二天给人缓一缓，或者拆成两个时段、两拨人盯，别让一个人从头守到尾。公司怎么排班以内部制度和实际情况为准，别拿别人的节奏套自己。

给还想往这行里跳的人几句实在话

第一，把自己一天能被打断几次当回事，主动留一段不响应的时间，哪怕只在群里挂个状态。第二，任何重复三遍以上的操作，想办法写成脚本或者模板。第三，能记录就记录，别指望脑子。第四，学会说不，不是所有「马上要」都必须马上给，先问清楚什么时候真要用。

这行不容易，但也并非不能过。真正把人耗干的常常不是加班那几个小时，是那些看不见边的小事。把这些小事一件一件削掉，加班自然就少了。