揭秘亚马逊内部与众不同的软件开发系统
本文最初发布于 Gergely Orosz 的个人博客。
亚马逊有大量的内部系统。作为软件工程师和工程经理，下面这些值得了解一下。
当作为 SDE（软件开发工程师）或 SDM（软件开发经理）加入时，你必须学会使用亚马逊自定义的技术栈，这和 AWS 客户所使用的技术栈有着惊人的差异。下面这些是你可能会遇到的系统。
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/
搞不定移动端性能，全球爆火的 Notion 从 Hybrid 转向了 Native
相关内容
微信扫码咨询专知VIP会员