[博客翻译]在Gitlab工作的体验如何呢？

在GitLab工作的时光：六年回忆与反思2024年2月8日

2015年10月，我加入了GitLab，并在2021年12月离职，总计工作了六年多。之前我曾提及离开GitLab投身Inko项目，但未详细讲述2015年至2021年间在GitLab的工作经历。原因有二：一是我当时正承受着职业倦怠，无暇回顾过去；二是当时仍受保密协议约束，不确定能透露多少信息，即便可能并无大碍。

直至去年12月保密协议到期，虽然职业倦怠的影响仍在，但我有了重拾这段记忆的精力。本文将分为两大部分：一是根据记忆概述我在GitLab的时间，二是分享我的工作经验所收获的教训。

目录

1. 加入GitLab之前

2. 在GitLab的日子

   1. 2015-2017：起航与挑战
   2. 2017-2018：稳定与发展
   3. 2019-2021：转型与动荡

3. 我学到的东西

加入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的数据库负载均衡器，显著提升了性能，避免了灾难性事故的发生。