我被 Atlassian 裁员了

**TL;DR：** 一位前 Atlassian 工程师在被裁员前回顾了八年的工作历程，详细介绍了他所构建的技术系统——包括 Open Service Broker、一个名为 Sovereign 的 Envoy 控制平面，以及跨多个 AWS 区域的大规模代理基础设施。 ## Atlassian 的面试流程 八年前的面试流程与今天有很大不同。当时包括一个 HackerRank 编程测试（满分通过），随后是两轮技术面试： - **第一轮：** 两位面试官递来一份 Cloudflare 关于自定义域名的白皮书，离开房间约 10 分钟后返回，就白皮书内容进行提问。此外还涉及微服务、架构和容器方面的问题。 - **第二轮：** 基于一次真实的 Atlassian 故障进行排障演练，该故障曾导致拒绝服务，另外还有一道关于基于延迟的 DNS 路由的问题。当时给出的答案——Route 53 根据实际客户端延迟进行三角定位——并不完全准确；实际上它使用地理位置数据库，根据估算延迟来路由 DNS 响应。 - **价值观面试：** 候选人请面试官描述 12 个月后成功的样子。他们描述了一个用于自助式负载均衡器配置的内部应用——类似于 AWS ALB，但面向 Atlassian 内部开发者。一句自信的"我可以用 Python 构建它"就足以拿到 offer。 --- ## 入职头几周：构建 Open Service Broker 加入 Atlassian 常被描述为"从消防水管喝水"——头几周需要吸收海量信息。第一个自我指派的任务，就是构建面试中承诺过的那个东西。 ### 什么是 Open Service Broker？ **Open Service Broker（OSB）** 是一个具有标准化 API 的 Web 应用，作为平台上资源配置的中间件层。OSB 规范发布在 GitHub 上，定义了以下端点： - `/catalog` — 列出所有可用服务和计划及其元数据 - 配置端点 — `PUT`、`PATCH`、`DELETE`，用于创建、更新和删除资源 在 Atlassian 的场景下，开发者将配置文件提交到版本控制系统，由构建服务器获取后部署服务。OSB 将底层基础设施（例如兼容 MySQL 的数据库）从内部开发者那里抽象出来。 ### 实现方式 该 Broker 最初使用 **Connexion** 构建——这是一个 Python 库，可以读取 OpenAPI 文档并自动生成路由处理器。后来迁移到纯 **Flask**，再到 **FastAPI**（目前仍在使用）。 **最终架构：** 1. 客户端向 FastAPI 发送配置请求 2. Web 服务器将任务写入 **SQS 队列**（异步处理） 3. **Worker** 获取任务并执行——创建 DNS 记录、CloudFront 分发、调用外部 API 等 4. Worker 将结果写入 **DynamoDB** 5. 客户端轮询 Web 服务器："完成了吗？"服务器查询数据库后做出响应 --- ## 第二个重大项目：Envoy 控制平面（"Sovereign"） 一位架构师提议用开源云原生替代方案——**Envoy Proxy**——替换 Atlassian 的商业企业级负载均衡器。Envoy 类似于 Nginx，但更现代，并通过 API 支持动态配置——这意味着无需重启代理即可在运行时重新加载配置。 目标：部署大量持续运行的代理，随着服务变化自动动态重新配置，无需开发者手动申请负载均衡器配置。 ### Sovereign 的作用 Sovereign 是 **Envoy 管理服务器**（控制平面）。它已开源并发布在 Bitbucket 上。 Sovereign 运行一个 **FastAPI 应用**，接受两类输入： - **模板** — 对应 Envoy 资源类型：cluster、route、listener 等 - **上下文** — 注入模板的动态数据 启动时，管理服务器读取模板和上下文，然后通过 API 对外暴露。Envoy 代理轮询该 API。当上下文发生变化时，Sovereign 重新渲染模板，并将更新后的配置推送给代理。 **上下文来源包括：** - 配置数据库（由 OSB Worker 写入） - 包含随时间变化数据的 S3 存储桶 ### 端到端配置流程 1. 客户端向 Broker 提交配置请求 2. Worker 执行任务，将新数据写入数据库 3. Sovereign 轮询更新后的数据并重新渲染 Envoy 配置 4. 新配置推送至代理 5. 代理开始按新配置路由流量 --- ## 基础设施：大规模配置代理 有了 Broker 和控制平面之后，下一个问题是：代理本身如何配置？它们是什么，运行在哪里？ ### 基于 CloudFormation 的配置 代理使用 **AWS CloudFormation** 模板进行配置——这是一种基础设施即代码方式，无需手动操作控制台即可创建 AWS 资源。 每次部署创建的资源包括： - VPC 和子网 - 互联网网关 - 安全组 - 密钥对 - IAM 角色 - **Auto Scaling Group（ASG）** - EC2 实例 其他组件还包括： - **NLB**（网络负载均衡器——四层代理） - **ACM**（证书管理） - **Route 53** DNS 记录 ### 规模 该基础设施跨越约 **13 个 AWS 区域**，共部署了约 **2,000 个代理**。 ### AMI 生成 CloudFormation 模板引用 AMI 而非创建 AMI。一个独立流程会生成标准化机器镜像，其中包含代理集群所需的所有关键组件——为这些镜像搭建构建流水线，是后续讨论的下一个重大基础设施挑战。 --- ## 反思 这段视频以技术回顾的形式呈现，面向正在经历裁员或类似职业转型的工程师。其目标既是记录真实的工程工作，也为思考类似架构挑战——或希望避免重蹈覆辙——的工程师提供参考。内容以技术为主，同时也涉及在 Atlassian 工作的一些非技术层面的经历。 --- 来源：https://youtu.be/55pTFVoclvE