大型科技公司的内部系统有哪些？软件工程师需要了解的研发工具与管理平台

某海外大型科技公司拥有大量内部系统。对于软件工程师和工程经理来说，了解这些内部系统、研发工具和工程管理平台，有助于更快理解大型技术组织的研发流程、协作方式和交付机制。

当你以软件开发工程师（SDE）或软件开发经理（SDM）的身份加入这类公司时，需要学习并使用一套高度定制化的内部技术栈。这套技术栈与外部客户日常使用的云服务技术栈仍有明显差异。以下是你可能会接触到的一些关键内部系统。

与软件工程师密切相关的研发内部系统

Code：代码搜索与版本控制系统。
Code 是公司内部用于代码搜索和版本控制的系统，底层与 Git 相关。

Crux：代码审查系统。
Crux 是公司内部的代码审查工具。工程师会通过它提交、审阅和讨论代码变更。

Brazil：构建系统。
Brazil 是公司内部长期使用的构建系统。虽然外部关于 Brazil 的一些介绍已经有些过时，但仍然具有参考价值。

Sage：内部问答系统。
Sage 可以理解为公司内部的技术问答社区，类似公司内部版的技术问答平台。

内部 Wiki 系统：知识沉淀平台。
内部 Wiki 系统有一些非常实用的功能。例如，工程师可以很方便地把云监控服务，或早期指标系统 PMET 中的图表嵌入页面，用于说明系统状态、指标趋势或技术方案。

NAWS：原生云服务技术栈。
NAWS 指 Native Cloud，也就是使用当前云服务原生能力构建系统的“现代”技术栈。

MAWS：迁移到云服务后的遗留模式。
MAWS 指 “Migrated to Cloud”，也就是早期从旧系统迁移到云服务后形成的一类遗留技术模式。

许多系统，尤其是零售业务相关系统，正在逐步从这种模式中迁出。MAWS 通常要求通过名为 Apollo 的系统在虚拟机实例上启动服务。而在原生云服务模式下，这种方式基本已经过时。对于 NAWS，工程师通常应该优先使用函数计算、容器服务；只有在确有必要时，才直接使用原始虚拟机实例。

Isengard / Conduit：云账户管理系统。
Isengard 和 Conduit 用于管理云账户。由于系统之间高度隔离，通常每个区域、服务和环境阶段都会对应一个独立的云账户。

有技术作者曾将这类内部账户管理服务称为“最让人又爱又恨的内部云服务之一”。原因在于，这类系统让内部工程师不必像外部客户那样直接处理云账户组织、落地区、账户控制台或单点登录等账户管理方式。换句话说，构建云服务平台的工程师，在内部使用云服务时，面对的是另一套经过内部封装的账户管理体验。

Pipelines：CI/CD 系统。
Pipelines 是支持多阶段部署的持续集成与持续交付系统，通常支持 beta、gamma、prod、local 等部署阶段。

一位内部工程师曾这样描述 Pipelines：

“Pipelines 是公司‘把复杂事情做简单、把困难事情做容易’的典型例子之一。对于只需要部署到三四个阶段的服务来说，比如跨不同区域的 beta、gamma 和 prod，团队可能不会对 Pipelines 有太强感受。但对于那些拥有数百个可部署单元的服务来说，Pipelines 的价值就非常明显。”

LPT：实时流水线模板。
LPT 是 Live Pipeline Templates 的缩写。这是一组 Ruby 库，可用于生成基础设施模板或部署模板，并定义流水线、云账户以及其他脚手架资源。通常，每个服务都会有一个 LPT 包，用来创建所需资源。

基础设施开发工具包：新一代基础设施定义方式。
公司内部正在大力推广使用基础设施开发工具包替代 LPT。不过至少在一段时间内，这类工具的成熟度仍不及 LPT。许多团队正在迁移，也有团队表示，他们尤其喜欢其对 TypeScript 的支持。

2PR：双人审批系统。
2PR 即 Second Person Review，用于对云账户管理、SSH 等敏感系统访问进行第二人审批。未经审批访问相关系统，会自动创建团队工单；如果问题严重，工单可能会进一步升级到管理层。

与组织协作和工程管理相关的内部系统

视频会议系统。
公司内部曾经使用一套自研或深度定制的视频会议系统，同时承担聊天和视频通话功能。后来，聊天场景中更多使用其他协作工具，但该系统仍然被用于视频通话，包括面试通话。

Kingpin：目标和指标跟踪系统。
Kingpin 用于跟踪团队、组织以及公司整体目标，是内部用于目标管理和指标追踪的重要系统之一。

Kudos：员工认可工具。
Kudos 是一个用于给员工颁发表扬和认可的工具。使用者可以附上评论，也可以方便地抄送给被表扬者的经理或其他相关人员。

Connections：员工反馈系统。
Connections 会预装在公司笔记本电脑上。每天开始工作时，它会向员工提出一个简短问题，例如“你对你的经理感觉如何？”或者“你的团队对卓越运营的重视程度如何？”员工通常需要按照 5 分制进行评分。

公司内的每个人每天都会看到同一个问题。汇总并匿名化后的结果会逐级上报给管理层。管理层的目标是持续提升 Connections 评分。相关结果也会与团队分享，团队成员可以继续提供反馈，经理则需要根据反馈采取相应行动。

Forte：绩效反馈流程。
Forte 是面向全员的绩效反馈流程，通常从 12 月底持续到 1 月底。员工会通过 Forte 工具向同事和合作方征求反馈。反馈内容通常较短，一般不超过 60 个词。

Forte 的目标，是帮助员工获得来自不同合作对象的简洁反馈，并为绩效评估、成长讨论和管理决策提供参考。

总结：大型技术组织为什么需要这么多内部系统

大型科技公司的内部系统通常覆盖代码管理、代码审查、构建部署、CI/CD、云账户管理、知识库、目标管理、员工反馈和绩效评估等多个环节。

这些内部研发工具和工程管理系统看似复杂，但它们共同服务于一个目标：让大规模工程组织能够在高度复杂的业务、技术和组织环境中，保持稳定协作、持续交付和可控治理。

当然，并不是所有企业都有必要像大型科技公司一样自研完整的内部工具体系。对于希望系统化提升研发效能的团队，可以借助 PingCode 这类智能化研发管理工具，把团队目标、客户反馈、需求评审、开发、测试、发布和 Wiki 知识沉淀串联起来；而对于更通用的跨部门协作、任务推进、文档管理、日历、审批和工时管理等场景，Worktile 这类项目协作系统也能帮助团队补齐组织协同能力。

对于软件工程师和工程经理来说，理解这些系统的价值，不只是为了掌握某个工具怎么用，更是为了理解大型技术组织如何通过流程、平台和工具来支撑研发效率。