在GitLab工作的时光：六年回忆与反思2024年2月8日
2015年10月，我加入了GitLab，并在2021年12月离职，总计工作了六年多。之前我曾提及离开GitLab投身Inko项目，但未详细讲述2015年至2021年间在GitLab的工作经历。原因有二：一是我当时正承受着职业倦怠，无暇回顾过去；二是当时仍受保密协议约束，不确定能透露多少信息，即便可能并无大碍。
直至去年12月保密协议到期，虽然职业倦怠的影响仍在，但我有了重拾这段记忆的精力。本文将分为两大部分：一是根据记忆概述我在GitLab的时间，二是分享我的工作经验所收获的教训。
目录
-
加入GitLab之前
-
在GitLab的日子
- 2015-2017：起航与挑战
- 2017-2018：稳定与发展
- 2019-2021：转型与动荡
-
我学到的东西
加入GitLab之前
加入GitLab前，我在阿姆斯特丹的一家初创公司工作。随着资金紧张，公司不得不采取应急措施，如出租办公空间来维持运营。同时，我觉得自己在技术层面已竭尽所能。业余时间，我还参与了开源项目Rubinius，并考虑将其应用于工作中，甚至确保所有代码都能在它上运行。由此诞生了Oga，一个XML/HTML解析库，作为Nokogiri的替代品。
然而，由于资金短缺和技术问题，我们并未进一步采用Rubinius。因此，我开始寻找可以投入更多时间在该项目上的新职位。期间，我在阿姆斯特丹参加了多次Ruby聚会，还协助了几场Rails Girls活动。正是在这类活动中，我先后两次遇到了Sytse和他的妻子。通过这些接触，我对GitLab产生了兴趣，并向Sytse表达了想为其工作的意愿。2015年夏天，我发邮件给他，提出每周有一天专心研究Rubinius。经过交谈和面试，我于同年10月成为GitLab的第28号员工，负责提升GitLab性能，还有20%的时间用于Rubinius。
2015-2017：起航与挑战
从一周五天办公室工作转为远程全职，起初需要适应。我记得在白天买菜回家，意识到这种生活方式的优点。此外，我曾在沙发上小憩，猫儿相伴，当时的场景至今难忘（请见下图）。
公寓狭小，厨房、客厅和阁楼融为一体。尽管条件有限，我还是购买了一把昂贵的Aeron椅。GitLab虽是远程公司，却保持着社交氛围，定期组织聚会和活动。入职几周后，我们在阿姆斯特丹举办了一场公司集会，之后规模迅速扩大，2016年在奥斯汀的聚会已经无法在一个餐厅角落容纳所有人了。
这段时间，GitLab遭遇了严重的性能问题、频繁的故障、管理不善等初创公司的常见问题，“GitLab太慢”成为用户最常抱怨的问题。Hacker News上对此怨声载道，无论话题为何。GitLab意识到了这些问题，而我被招来解决它们。
面对挑战，我构建了性能监控工具，改进了多个部分的性能。其中一项成果“GitLab性能监控”后来成为官方功能，另一项是针对开发环境的重量级剖析器Sherlock。尽管如此，GitLab对性能优化的需求并不紧迫，且更重视内部反馈而非Hacker News的批评。这导致了内部笑话：想要改变，匿名在Hacker News上抱怨比通过正规渠道有效。
2017-2018：稳定与发展
经过最初的动荡期，GitLab的性能显著改善，公司开始更加重视。招聘流程改进，人员配置得当。性能团队专注于数据库性能并更名为“数据库团队”，预算增加，基础设施工程师也协助建立新的数据库。期间，我开发了GitLab的数据库负载均衡器，显著提升了性能，避免了灾难性事故的发生。遗憾的是，尽管取得了一些进步，但我们未能说服GitLab放弃分片数据库的想法，即使数据表明这不是解决问题的最佳方案。
2019-2021：转型与动荡
2018年底至2019年初，我转入新成立的“交付”团队，因为长期关注性能和可靠性让我感到疲惫。这个团队致力于改进GitLab的发布流程和工具。我们发现从主分支到部署GitLab.com的平均时间长达数天，极端情况下甚至可达三周。主要瓶颈在于社区版和企业版分别存在于独立的Git仓库中，需要频繁的手动合并和冲突解决。于是我们启动了一个项目，将两个版本合并成一个。前端和后端的工作分工明确，不同团队承担相应任务，我负责大部分后端工作，同事负责前端。
此阶段，我们显著优化了发布流程，缩短了部署时间。虽然速度仍有待提高，但将最坏情况下的三周缩短到一天左右，已是重大进步。期间，GitLab取消了以员工为中心的年度峰会，改为传统会议形式，社交氛围减弱。笔记本电脑管理问题也成为争议焦点，公司试图引入远程管理软件，但提出的解决方案过于侵入性，引发了员工反对。最终，公司选择了SentinelOne，要求员工安装该软件，包括个人设备，但我因使用个人台式机而逃过一劫。
这些变化加上个人生活的变化，导致我失去动力，压力增大，工作效率波动。团队经理调任，新经理接手，我们之间关系紧张，随后制定了“绩效增强计划”。这是一个旨在解决问题的程序，以免进入“绩效改进计划”（PIP）。然而，实施过程中并未平衡双方责任，目标也不够明确。计划原定一个月，但经理延长了期限，理由模糊。我决定配合完成，两个月后顺利过关。
这次经历使我认识到可能是时候离开了，因为我和GitLab的发展方向出现分歧，我对现状不满。2021年底，GitLab准备上市，考虑到行使股票期权的时间限制，我选择离职，全身心投入到Inko项目中，利用积蓄维持生计。
所学的教训
总结过往，我在GitLab的经历充满喜忧参半。我为团队的成就和共事的人们深感自豪，也为最后一年的困扰感到遗憾。回顾过去，我不后悔在GitLab工作的决定，如果有机会，我会以不同的方式再次选择。我也依然推荐GitLab作为一家值得工作的公司，尽管它存在问题，但总体表现优于许多其他公司。
以下是我在GitLab工作中学到的一些关键点：
- 可扩展性应融入企业文化
- 让团队更具数据驱动和开发者导向
- “最小可行”需基于数据判断
- SaaS和自托管难以兼得
- 增加人手不一定带来更好结果
- 对Ruby on Rails的矛盾看法
- 快速部署对于组织成功至关重要
- 地域薪资歧视及其影响