给 GitLab 远程打工惊心动魄的真相 - 28 号员工回忆录

原文链接，作者：Yorick Peterse。GitLab 在 2021 年完成了 IPO，在纳斯达克成功上市，而且确实是没有地址（参见下图）。

---

我 2015 年 10 月加入了 GitLab，在那儿打了六年工，在 2021 年 12 月离开。 尽管之前我写过离开 GitLab 去 Inko 的事情，但从未讨论过在 2015-2021 年间为 GitLab 工作的经历。有两个原因：

1. 当时我疲劳过度，没有精力回顾我生活中近六年的时间
2. 我仍受到 24 个月 NDA（保密协议）的约束，不确定能否在不违反协议的情况下讨论多少内容，尽管这可能并不会引起任何问题

NDA 去年 12 月已经到期，虽然我怀疑自己仍在和疲劳过度带来的后果斗争，但现在有更多精力回顾我 GitLab 的时光了。

本文将分为两个主要部分：根据我还记得的内容概述我的 GitLab 时光以及基于工作和经验所学到的一些东西。

大纲

• GitLab 之前
• 2015-2017
• 2017-2018
• 2019-2021
• 经验教训
  • 可扩展性需要成为公司文化的一部分
  • 团队需要由数据和开发者驱动
  • 没有数据，无法确定最小可行性产品 MVP 长啥样
  • SaaS 和自托管互不相容
  • 更多的人不意味着更好的结果
  • 对于使用 Ruby on Rails 的矛盾心理
  • 部署代码所需的时间对组织的成功至关重要
  • 按照地域定薪资是一种歧视
• 总结一下

GitLab 之前

在加入 GitLab 之前，我曾在阿姆斯特丹的一家小型初创公司工作。像大多数初创公司一样，在我离职前的几个月里，公司开始资金短缺，不得不采取一些极端的解决方案，比如出租部分办公空间。与此同时，我觉得自己在技术层面已经做了想做和能做的所有事情。

与此同时，我还利用业余时间参与 Rubinius 项目，并考虑过在某些场景使用它，确保我们所有代码都可以顺利运行。这也促进了 Oga 的诞生，一个作为 Nokogiri 替代品的 XML/HTML 解析库。

不幸的是，资金短缺以及各种技术问题意味着我们从未推动 Rubinius 的使用。多种因素叠加，我开始寻找新工作，至少这样我可以花更多时间来改进 Rubinius，使其足够稳定以供人们在生产环境中使用。

在此期间，我参加了阿姆斯特丹各种 Ruby 见面会，并协助组织了几次 Rails Girls 研讨会。 在其中一个研讨会上，我遇到了 GitLab CEO Sytse 和他妻子，并再次在之后另一个研讨会或 meetup（应该是，但我记忆有点模糊）。通过这个机会，我了解到了 GitLab 并对去那里工作产生兴趣。

2015 年夏天，我给 Sytse 发邮件，表示希望为 GitLab 工作并询问他们是否愿意我每周一天用于开发 Rubinius。随后进行了一些谈话和面试，我于 2015 年 10 月以第 28 号员工身份开始就职于 GitLab。我负责提高 GitLab 性能，并被允许将 20% 的时间投入到 Rubinius 项目中。

在职期间，我参与过很多团队，拥有很大程度上自主权，多年间向 10 位不同经理汇报过，差点使公司濒临倒闭，构建了 GitLab 至今仍然使用着各种关键组件，目睹公司从 30 多名员工增长到约 2000 名员工，并最终陷入倦怠状态，或者用荷兰俗语说: "Lekker gewerkt,pik!"（干得好，笨蛋！）

2015-2017

我之前那份工作的 last day 是 9 月 30 日，一个星期三，紧接着第二天我就开始在 GitLab 工作。也就是说我从每周五天在办公室工作变成了每周五天远程办公。虽然以前也在家工作过，主要是当火车因为积雪或树叶而停运，适应新的安排还是需要一点时间。

那段时间有一个特别深刻的记忆是我白天提着袋子买菜回家，并意识到白天做这件事比下班后晚上回家时更惬意。

另一个记忆是和我的猫一起在沙发上小憩，当时拍下了这张照片：

是的，那是荷马辛普森拖鞋。

当时我租住的公寓不大，只有一个小厨房、一个小客厅和一个小阁楼，也就是说我的客厅同时兼作卧室、客厅和办公室。虽然这不是很理想的布局，但那时我只能负担得起这个，也许昂贵的 Aeron 椅子与此有关。

尽管 GitLab 是一家完全远程公司，但它也是社交型公司，经常举行聚会和活动。例如，在我加入后几周，公司在阿姆斯特丹举办了一次聚会，白天进行各种活动，并在晚上共进晚餐：

当时，整个公司还可以塞进餐厅的一个角落里。

不久之后，GitLab 迎来了第一次暴发式增长，大约新增了 100 名员工（应该是？我的记忆有点模糊）。到了 2016 年奥斯丁的下次公司聚会时，一个餐厅的角落已经不够了：

在这段时间里，也有一些负面经历。GitLab 遭受了糟糕的性能、频繁的宕机（几乎每周都有），管理不善以及许多其他初创企业面临的问题。这导致「GitLab 运行缓慢」成为用户最常抱怨的问题之一。尤其是在 Hacker News 上，人们总是喜欢抱怨它，无论原始话题（例如新功能公告）是什么。当然 GitLab 意识到了这一点，他们聘请我的其中一个原因就是要解决这些问题。

这是一个挑战，特别是因为 GitLab 没有足够的性能监控基础设施。顺便说一下，并非言过其实：当时唯一运行的服务只有一个 New Relic 试用账户，只允许监控一个或者两个服务器的情况（我们那时总共应该有 15-20 台服务器）。这意味着任何数据进来都不会准确反映情况，并且使得测量和解决性能方面存在困难。

使得解决这些问题变得更加困难的是 GitLab 的要求：我们使用的工具都必须对自托管客户可用，并且最好开源（或者甚至可能属于硬性要求，我记不清了）。这意味着我不仅需要改进性能，还需要构建首先提高性能所需工具。同时，在公司内部写出高效代码（或者至少不会极度缓慢）没有被视作优先事项。GitLab 还倾向于更多地听取 Hacker News 上关于投诉而非内部投诉的声音。由此产生了一个内部流传笑话：如果你希望某事改变，请匿名在 Hacker News 上吐槽，这比通过适当渠道提出更有效。

接下来数月时间里我努力改善性能、构建必要工具、尝试改变公司文化/态度以便随着时间推移真正实现改进，并处理 GitLab 对已做出改进并不满意所带来的挑战。我清楚地记得至少进行过几次视频通话，在其中差点忍不住对 Sytse 大声吼叫起来，还好从未真的发生过。

尽管面临这些挑战，我还是设法建立了必要的工具，并在各个部分改进了性能（其中一些是很重要的，其他则不那么重要）。这些工具成为一个名为「GitLab 性能监控」的官方 GitLab 功能，尽管多年来已经发生了很大变化。我另外构建的一个工具是 Sherlock，一个用于开发环境的高级分析器。

在此期间，GitLab 开始意识到仅靠一个人无法解决这类问题，特别是如果性能不是公司其余部门的首要任务。由此带来的变化之一是，我不再直接向 Sytse 汇报，而是作为新性能团队的成员向专门的经理汇报，并且该团队有预算可以雇佣更多人员。我记不清具体预算数额是多少了，但并不多：可能只有两个或三个人。考虑到公司总规模以及其主要关注点是尽可能推出更多功能而言，这远远不够，但却算得上一个开始。

我的第二年中很大一部分时间都花在了这支团队中，在那里稍微有些喘息空间。我继续争取获得更多资源，并将良好性能作为新代码所需满足条件之一进行倡导，但结果参差不齐；同时我们整个团队也在持续改进性能。

与此同时，GitLab 也经历了第一波裁员和离职潮，主要原因是 GitLab 最初招聘了些错误的人才。这意味着 GitLab 从 30+ 增长至（据我所知）130+ 名员工，然后缩减至 80+，再开始增长。

至于 Rubinius：尽管我们试图让 GitLab 在 Rubinius 上运行，我们从未成功过。结合 Rubinius 项目负责人希望将项目带入另一方向以及由此引起 Ruby 社区内争议等因素，我们最终决定放弃 Rubinius 项目；我也停止全力投入其中。这很遗憾，Rubinius 多年来积累了许多优势，却最终受制于项目负责人的管理方式，而无法成功发展。

2017-2018

经过最初 1.5 年的艰难时期，情况开始有所改善。绩效大幅提升，GitLab 开始更加认真地对待这一问题。招聘流程得到了很大改善，就像下棋一样，GitLab 开始将合适的人放在合适的位置上。性能团队的边界也发生了变化：不再专注于总体性能，而是将重点放在数据库性能上，并且作为此举的一部分被重新命名为数据库团队。随着这一变化还带来了更多用于招聘人员的预算，并指定基础设施工程师来协助我们进行例如准备新数据库等工作。

我在此期间构建的一个至关重要功能是 GitLab 的数据库负载均衡器，公告在此。该功能允许开发人员继续像往常一样编写他们的数据库查询语句，而负载均衡器会负责确保不将这些查询发送到副本或主库中。执行写操作后，负载均衡器确保主数据库被使用直到所有副本都可用于已写入更改之前，通常称为粘滞位 (sticking)。引入负载均衡器对性能产生了显著和积极影响，我相信如果没有这个负载平衡器，GitLab 可能会陷入麻烦。我最自豪的是可以透明地引入这个系统。迄今为止我还没有看到一个（更别说 Ruby on Rails）你只需添加到项目中并立即投入使用就好的数据库负载平衡器 。相反，现有的解决方案更像是仅提供了拼图，需要你自己把所有东西粘合起来，1111通常没有任何形式支持粘滞。遗憾的是我们从未想过将其提取成独立库。

这段时间不仅是我在 GitLab 和整个职业生涯中极具生产力和改进的时期，也标志着我在 GitLab 工作中最低谷和最可怕的时刻：1 月 31 日，在经历了一天长时间而紧张的处理许多问题后，直到深夜问题依然存在，我意外 解决了 GitLab 的性能问题删除了 GitLab 的生产数据库。随后发现我们没有任何备份，因为系统很长一段时间都没有运行，并且负责通知我们任何备份错误的系统也未正常工作。最终我们进行了恢复，因为当天我将生产数据复制到我们的演示环境大约六个小时前就已完成这部分工作，尽管过程花费了大约 24 小时。虽然失去约六小时数据无疑是非常糟糕的事情，但如果当时没有做备份会发生什么事情我并不确定。可以说那一天我的心跳停了几拍，并且肯定多了几根白发。

在此期间一个反复引起挫折感的原因是即使引入数据库负载均衡器之后 GitLab 仍希望对数据库进行分片。不仅我、其他工程师以及我的经理认为这种方法并非解决方案所需之处，并且我们还有数据支持这一观点。例如，在 GitLab 中读操作远远超过写操作（比例大致为 10:1），分片只有在写操作明显多于读操作时才有用。此外，我们存储数据量远远不足以证明引入分片技术所需复杂度合理化。 我清楚地记得顾问也说过类似「请勿介意，但是我们有客户负载和存储量高出数个数量级，即使对他们来说使用分片也属于杀鸡用牛刀」。尽管如此，Gitlab 在接下来几年里继续推动该计划，直至管理层做出放弃决定，然后再次提出（只是换一个略微不同名字或想法）到我离开为止。

2019-2021

在 2018 至 2019 年间，我从数据库团队转入了一个新成立的交付团队，因为我已经厌倦了过去四年一直致力于性能和可靠性工作。此外，现在有多人正在处理性能和可靠性问题，所以我觉得是时候做点新事情了。这个新团队的目标是改进 GitLab 的发布流程和工具，因为当时这方面的状况最好描述为混乱。

例如，我们调查了提交到主分支并部署更改到 GitLab.com 之间需要多长时间。结果显示平均要几天，但在最糟糕的情况下可能要长达三周。主要瓶颈在于 GitLab 社区版和企业版之间存在分离，存在不同的 Git 仓库中，并且需要定期手动合并和解决冲突。这导致我们花费数月时间将两个项目合并为一个项目。虽然我们将工作划分为前端和后端，并让各个团队负责向努力做出贡献，但最终我实施了大部分与后端相关的更改，另一位同事则负责大部分前端工作。

在此期间与团队其他成员一起，在发布流程方面取得了显著进展，并且我们达到可以在几小时内部署更改的阶段。尽管这远远没有达到应有速度，从原来可能需三周的最差情形变成一天是最差情形，也是一个重大进步。

与以往时期一样，这段时间也并非没有动荡和变化。

2018 年是我们最后一次举办以员工为中心的 GitLab 峰会，而 2019 年及其后的几年则更像传统会议形式，更侧重于客户而不是员工。从财务角度来看，组织 2000+ 人的聚会成本极高是可以理解的。从社交角度来看，这是一个损失，因为峰会更商业化的设置远不如旧形式有趣。我对 Sytse 在舞台上跳舞以回应团队赢得比赛或者 Sytse 和他的妻子穿着长颈鹿服装上健身课等美好记忆仍历历在目。这些滑稽事件在接下来的几年中将不再发生。

然后就有了笔记本电脑管理的问题：人们要求公司提供 Mac 笔记本，并基本上可以自行使用它们，或者像我一样使用自己的硬件。多年来，GitLab 管理层开始讨论使用软件远程管理笔记本电脑。在这些讨论中反复出现的问题之一是所提议方案具都有侵入性（例如可能用于记录用户活动），没有任何防止滥用保证，并且员工（很多）提出意见却被忽视，直到关键员工开始向管理施加压力才引起注意。然后计划被搁置，只能在数月后重新开始讨论。

最引人注目的并非所提议改变的内容，而是管理层处理反馈意见方式，以及总体变化散发出为了解决方案寻找问题的感觉。值得一提的是，大多参与此类讨论的人（包括我）都明白需要某种形式笔记本电脑管理（例如防盗），但认为所建议的侵入性解决方案过头了。

GitLab 最终采用了 SentinelOne 作为笔记本电脑管理解决方案。尽管 GitLab 规定雇员必须安装该软件用于访问 GitLab 资源，包括个人设备（至少正在考虑），我（使用自己台式）不知何故成功地避开了，并未被要求安装相关软件，或许由于我未使用公司配发的笔记本电脑，GitLab 忘了核实我的情况。

这些文化变革与我个人生活中的各种变化相结合，导致了动力、工作效率的下降，压力增加以及工作时间不够稳定。团队经理（我认为是我遇到过最好的经理）也转岗到另一个职位，现在由一名新任经理领导团队。我和这位经理相处得并不好，造成了冲突，进而引发了「绩效激励计划 PEP」，旨在在需要「绩效改善计划 PIP」之前将事情重新纠正过来。绩效改善计划旨在作为最后一根稻草来改善员工、工作和雇主之间的关系。

让我感到不舒服的是 GitLab 处理 PEP 的方式：我承认有需要改进的地方，但我觉得问题部分出自新经理的工作方式。管理层向我保证 PEP 旨在同时改善双方状况，并非只专注于我的提升，还包括对经理进行调整。然而实际情况并非如此，PEP 只集中于我的需求做出不同处理，它对所需达成标准也有点模糊不清。原始计划是 PEP 持续一个月，在第一个月结束时我的经理决定延长 PEP 一个月，因为他们认为这是必要的，并未明确说明具体原因。 我选择顺从，并且两个月后完成了 PEP ，管理层认为结果令人满意。

乐观者会认为这可能只是第一个被放入 PEP 的员工，因此管理层必须在实践中找出解决方法。悲观者则对这一系列事件持更消极态度，但这些想法只是留在了自己心里。

在这段经历之后，我意识到也许是时候离开了，因为 GitLab 和我正朝着不同的方向发展，而且我当时对事物的状态感到不满。

这个机会出现在 2021 年底：GitLab 要上市了，考虑到我能行使我的股票期权的时间，意味着我可以在 2021 年 12 月离开。由于荷兰当时期权税收政策的原因，我无法提前离开：行使股票期权意味着必须支付全额所得税（52%）差额费用和估值之间的差额部分，即使该股票并非流动性资产。就我的情况而言，税款金额如此之高以至于无法负担得起它，并迫使我等待直至 GitLab 上市。几个月后法律发生变化，现在你可以选择是在行使时支付税款还是等到股票具有流动性再支付。但问题是如果你推迟缴纳税款直至股票具有流动性，则需根据那个时间点的价值来计算税款，并非基于行使股票期权时的价值。这显然并不理想且存在巨大金融风险，但至少你有选择权。

因此，在获得我的股份后，在 2021 年 12 月辞职全职投入 Inko 项目中，并用我的存款来付账单。

经验教训

历史聊完了，来看看我在 GitLab 工作期间学到的一些东西。要记住的一件事是，这些都基于我的个人经验，因此在某些方面可能是错误的。

可扩展性需要成为公司文化的一部分

GitLab 犯了一个错误，而且在我离开时仍在继续犯错，那就是对可扩展性不够重视。是的，领导们会说这很重要，并确实进行了改进，但它从来没有像其他目标那样成为首要任务。问题的核心在于 GitLab 盈利模式：主要通过客户自行托管 GitLab 企业版而非 GitLab.com 来赚钱。事实上，GitLab.com 的花费比带来的收入多得多。这自然导致对自行托管市场的关注，并且我们在 GitLab.com 上遇到的许多性能问题并不适用于许多自行托管客户。 更加令人沮丧的是，许多开发人员实际上想提高性能，但却没有获得时间和资源去做到这一点。

团队需要由数据和开发者驱动

另一个因素是 GitLab 产品经理主导的特性。虽然一些关键开发人员可能有影响产品决策的能力（只要他们够响且够狠），但主要还是产品经理和总监决定需要做什么。有时这些决定很有道理，而其他时候似乎完全基于「我在 Hacker News 上读到这是个好主意，所以我们必须做它」。

我相信如果 GitLab 早期采用了更简单的层级结构，而不是今天拥有传统多层次层级结构，公司会表现得更好。特别是，我认为应该放弃产品经理这个概念，转而赋予团队领导更多权力，并让他们与用户互动更多。对我来说，产品经理应该做的就是：帮助在技术水平上构建产品，同时也作为团队与其用户之间的联络人。

没有数据，无法确定最小可行性产品 MVP 长啥样

GitLab 的核心原则之一是始终从最小可行性变更 (minimal viable change) 开始。这个想法是交付能为用户带来价值的最小可行性产品 (Minimal Viable Product)。听起来很不错，但实际上，最小的定义在人与人之间并不一致。结果是一个团队可能认为性能或者良好的可用性对于某事物是否可行至关重要，而另一个团队却毫不在意。

实践中，这导致 GitLab 多年来构建了许多并不有用的功能：一个没有人要求且最终被淘汰的无服务器平台、三周内都没人注意到管理 Kubernetes 集群功能失效、我们必须基于 CI 提供解决方案（从而引入了显著延迟）而非使用现有解决方案构建 ChatOps 解决方案，或者只支持创建和查看数据（甚至不能更新或删除）的需求管理功能；这些只是近年来几个例子。

要确定什么使某事物成为最小可行性产品，需要深刻理解目标受众的愿望。虽然 GitLab 每季度进行用户调查，并且一些团队可以访问有关用户参与度的数据，但根据我的记忆和与其他前同事交谈所学到的情况看来，这些数据更像是偶然使用，并非每个团队工作流程中核心部分。

SaaS 和自托管不相容

GitLab 提供两种产品类型：自托管和 SaaS。我认为大多数公司无法有效地提供这样的设置，包括 GitLab 在内。你不仅会因为赚取更多钱而产生利益冲突（如上所述），而且这两种设置还有不同的要求和更新应用方式。

例如，对于 SaaS，你希望能够快速部署，并处理发生在集中基础设施上的大量数据和工作负载。鉴于大多数自托管实例与 SaaS 提供相比较小，许多解决方案并不能适用于遇到问题时作为 SaaS 以及其对应解决方案的情形。这实际上导致平台许多部分存在两条代码路径：一条是针对 SaaS 版本，另一条是针对自托管版本。即使代码在物理上相同（即你为自托管安装提供某种易于使用的封装器），你还是需要考虑其中的差异。

相反，当你专注于 SaaS 或自托管设置中的一种时，可以将所有注意力都放在为相关设置提供最佳体验上。当然也有例外情况，但它们确实只是罕见例外。

更多的人不意味着更好的结果

就像之前许多其他公司一样，GitLab 在过去几年里雇佣了大量员工，如今拥有超过 2000 名员工。我不知道其中有多少是开发人员，快速浏览团队的页面，看起来应该至少有几百人。众所周知，增加项目中的人数并不能必然提高生产力和结果（参见《人月神话》），然而几乎每家西方初创企业都会忽视这一点，并雇佣数百名开发人员，即使产品实际上并不需要那么多开发者。

我没有数据支持这一点，但我怀疑大多数公司其实并不需要超过 20 名开发者，部分可能需要 20-50 名，只有极少数需要 50-100 名。当跨越 100 个开发者时，请开始考虑是否在进一步雇佣更多人之前要思考你产品范围是否已经失控。

请注意我这里特指软件开发人员。例如如果你正在制造定制硬件，则可能需要更多人来扩展生产流程。销售和支持也是两个领域，在这些类型的工作中通常受益于拥有更多人手，因为此类工作要求较少协调性。

对于使用 Ruby on Rails 的矛盾心理

GitLab 是用 Ruby 和 Ruby on Rails 构建的，这在很大程度上促使它取得了今天所享有的成功。与此同时，当项目规模变大且贡献者经验不同层次时，这种组合也带来了挑战。特别是 Rails 让引入性能不佳的代码变得太容易了。

例如，想显示一个项目列表以及显示项目成员数量的计数器，很容易无意中引入 N+1 查询问题。虽然 Rails（或更具体地说是 ActiveRecord）提供了解决此问题的功能，但这是一种选择机制，最终导致开发人员忘记了这一点。我在 GitLab 头几年解决的许多性能问题都涉及 N+1 查询问题。

其他框架多年来从中吸取教训，并提供更好的替代方案。通常做法是，在任意查询相关数据之前必须先传递数据进去而非随后再进行查询。好处在于如果你忘记传递数据，则会遇到一些错误而不会像按行基础查询数据那样引入性能问题。

Ruby 本身也是一个我持有不同意见的选择。一方面，它是一种我喜欢使用将近十年的优秀语言。另一方面，其大量使用元编程使得在大型项目中难以使用，即使引入了可选类型。这不是说说，多年前写 Ruby 的静态分析工具 (https://github.com/yorickpeterse/ruby-lint) 时我亲身经历过这种情况。

尽管如此，我不确定除了 Ruby 和 Ruby on Rails 的组合之外会推荐什么替代品。诸如 Go，Rust 或 Node.js 这样的语言可能比 Ruby 更高效，但没有一个像 Ruby on Rails 那样功能强大的框架。Python 和 Django 可能是一个选择，但我怀疑你会遇到与 Ruby 和 Ruby on Rails 相似的问题，至少在某种程度上。如果新的 Web 框架停止困扰于如何定义路由树，并更多地专注于整体生产力，则可能会有所帮助。

对于 Inko 我有一些大致想法该如何处理这个问题，但在开始用 Inko 编写 Web 框架之前还需要做很多其他工作。

部署代码所需的时间对组织的成功至关重要

这是我在加入 GitLab 前就已经知道的事情，因为我在以前的工作中花了大量时间设置良好的部署和测试流水线，但在 GitLab 工作强化了这种信念：你需要能够快速部署代码，即在将更改推送到任何分支/标签/东西后最多一个小时内。 在 GitLab，我们花了大约四年的时间才接近这一点，并且仍有很长的路要走。

除了明显的好处外，例如能够更有效地应对事故（无需热修补代码来解决由于部署需要数小时而导致问题），还有一种激励性好处：能够看到你做的更改实时生效是件不错的事情，因为可以实际看到并使用自己的成果。没有比花几周时间进行一系列更改然后再等两周才能完成部署更令人泄气了。

为达成目标，你需要缩短部署时间以及运行测试套件所需时间。根据应用程序类型和正在测试服务类型，在进行部署时可能会固有地需要一定数量的测试运行时间。 这里重点不是「测试和部署绝不能超过 X 分钟」，而是（作为一个组织）将其视为优先事项，并尽可能快速地按照业务要求进行部署。 尽管显而易见，但我怀疑许多组织在这方面做得远不如他们本可做得那么出色。

按照地域定薪资是一种歧视

在 GitLab 赚的工资受到各种变量的影响，其中之一就是地点。你所在地点对工资的影响也不容忽视。当一个公司有实体办公室并需要在特定区域招聘人员时，根据地点调整薪酬可能是有道理的，否则可能无法雇佣所需区域内必要人员。但对于没有实体办公室、在全球设立法律实体的远程公司来说，在同样经验和责任下纯粹基于居住地支付两个不同人员不同薪水没有合法理由。

举个例子：我离开 GitLab 时，我的年薪约为 12 万欧元，税前月收入约 8500 欧元。对荷兰而言这是一份不错的工资，在家全职工作很难找到提供更好条件的公司。但如果我住在旧金山湾区，我至少会赚取那个数额两倍以上甚至更多。并非因为我能够更好地完成工作或出于其他有效原因，而仅仅因为我生活在湾区而非荷兰。

无论如何解释这件事情都可以看作是一种歧视行为 - 纯粹基于居住地给某人支付较少报酬与他人相比。想想看：如果一个公司因为某人肤色或性别而减少其报酬，则该公司将陷入困境。但以居住地支付较少报酬却被认可？

如何解决这个问题？对企业来说很简单：只需根据岗位要求支付，并非申请者所处位置进行支付即可。无论你给在湾区还是菲律宾的某人报酬，薪水都是每年 10 万美元，对于企业来说成本都是一样的。至于员工们，我唯一的建议就尝试谈判获取更高薪水了，但由此带来困难也许会证明棘手，因为按照位置付费通常意味着企业倔强坚持。我希望有朝一日我们国家法规能跟上这种做法. 一个似乎在这方面做得很好的是 0xide 公司。 与其根据员工所在地支付薪水，0xide 向员工支付相同金额，参阅此帖，我深表钦佩，并认为更多公司应该这样做。

总结一下

回顾过去，我在 GitLab 的时光是积极和消极经历的混合。我为所在团队取得的成就感到非常自豪，也很高兴能与这些人一起工作，但最近一年左右让原本美好的经历变得令人沮丧。我对在 GitLab 工作没有任何遗憾，如果可以重来，我会做出一些改变，因为有了上帝视角。尽管有缺点，我仍然推荐它作为一个值得工作的公司，因为我认为它毕竟比其他许多公司要做得好多了。

---

💡 更多资讯，请关注 Bytebase 公号：Bytebase