揭秘亚马逊内部与众不同的软件开发系统

本文最初发布于 Gergely Orosz 的个人博客。

亚马逊有大量的内部系统。作为软件工程师和工程经理，下面这些值得了解一下。

当作为 SDE（软件开发工程师）或 SDM（软件开发经理）加入时，你必须学会使用亚马逊自定义的技术栈，这和 AWS 客户所使用的技术栈有着惊人的差异。下面这些是你可能会遇到的系统。

与 SDE 密切相关的内部系统

Code：代码搜索和 VCS（Git）。

Crux：亚马逊的代码评审系统。

Brazil： 亚马逊的构建系统。可以看下这篇详细介绍Brazil的文章，虽然已经过时，但仍有意义。

Sage：亚马逊内部的“Stack Overflow”。

亚马逊内部维基系统：该系统有一些令人愉快的特性，比如很容易在页面上嵌入来自 AWS Cloudwatch 或先前系统（PMET —— 性能指标）的图片。

NAWS（Native AWS）：使用现行 AWS 的“现代”技术栈。

MAWS（Move to AWS）：遗留的旧 AWS 系统。

• 许多系统在从这上面移走，尤其是在零售领域。

• MAWS 要求服务通过一个名为的 Apollo 系统在 EC2 实例上启动，这在 NAWS 中基本已经废弃了（你应该使用 Lambda 或 ECS，或者在绝对必要的情况下使用原始 EC2）。

Isengard/Conduit：AWS 账号管理，所有系统都是隔离的，这可以保证每个区域、服务、阶段（stage）都有独一无二的 AWS 账号。

Last Week in AWS编辑 Corey Quinn 将这项服务说成是“他最讨厌的AWS服务”。他写道：

事实上，这是用于配置 AWS 账号的内部系统，这意味着，构建 AWS 的 AWS 工程师管理 AWS 账号的方式与世界上其他人管理 AWS 账号的方式绝缘。他们不需要采用和 AWS Organizations、Landing Zones、Control Tower 或 AWS SSO 一样的方式。这是我对这项服务不满的根本原因。

Pipelines：CI/CD 系统，支持多阶段部署（最多 4 个阶段：beta、gamma、prod、local）。有一位 AWS 工程师这样描述它：

在亚马逊，管道是“把简单的事情变困难，把困难的事情变可能”的最佳例子之一。部署到 3-4 阶段的服务（跨不同区域的 beta、gamma 和 prod）大概并不关心管道。而像大多数 AWS 服务那样，在流水线中有数百个部署单元的服务则对它非常满意。

LPT：动态管道模板。这是一个生成 CloudFormation 或 CodeDeploy 模板的 Ruby 库，它会同时定义管道、Isengard 账号及其他脚手架。通常，每个服务都有一个 LPT 包来创建所需的资源。

AWS CDK：亚马逊在推动使用它代替 LPT，但截至 2022 年初，与 LPT 相比，它还是一个不怎么成熟的系统。大部分团队都在采取行动，有些团队表示，他们特别喜欢它提供的 TypeScript 支持。

2PR：针对敏感操作的第二人审批系统，如 Isengard 和 SSH 登录系统。如果访问系统时没有按要求审批，就会自动创建一个团队违规通知单，这可以升级到管理层。

组织层面的系统

AWS Chime：以前是亚马逊的聊天和视频通话应用程序。现在，亚马逊使用 Slack 聊天，但 AWS Chime 仍用于视频通话，包括电话面试。

Kingpin：团队、组织及亚马逊公司范围的目标跟踪系统。

Accolades：一个通过评价赞美员工的工具，并且提供了方法，可以方便地抄送给经理和其他人。

Connections：在公司笔记本上预装。它会在一天开始的时候提一个简单的问题，像”你觉得你的经理怎么样“，或者”你的团队对卓越运营（OE）的重视程度如何？“，并让你给出满分为 5 的评级。公司里每个人每天看到的问题都一样。

Forte：亚马逊公司范围的绩效反馈流程，从 12 月下旬开始一直运行到 1 月底。员工使用 Forte 工具请同行及与他们共事的人反馈意见。简短的反馈，只有 60 个单词或更少。

汇总后的匿名结果会上传给管理层，他们的目标是随着时间的推移提高他们的 Connections 分数。这些结果会与团队分享，团队会给出反馈，而他们的经理则会据此采取措施。

编程语言

大多数服务都是用 Java 编写的。不过，团队是自治的，他们可以选择任何自己想用的语言和框架。虽然 Java 是主要的，但这些服务中也使用了多种其他语言。

查看英文原文：

https://blog.pragmaticengineer.com/amazon-notable-systems/