团队拓扑

去年，我们与 1850 多个工程组织进行了交谈。大多数人正在计划或已经在构建内部开发人员平台。以下是我们看到这些团队陷入的最艰难的教训和谬误。平台工程、内部开发者平台和开发者自助服务总体上是一个快速增长的趋势。根据

“平台工程”正在迅速成为新的 DevOps 或 SRE。几乎每天我们都会听到有一个公司正在构建内部开发人员平台或控制平面。我们都已经建立了多年的应用/网络平台 - 企业内部：ticket驱动，裸机，交货时间长 - 第一代PaaS：自助服务、基于虚拟机、一刀切、

企业的IT部门被很多事情困扰着，但过度的复杂性一定是在名单的首位。任何试图描述平均IT景观的努力，最终都会在应用、硬件和相互依存关系中变成无法解读的意大利面条。这几乎就像企业IT受到热力学第二定律的制约，该定律的结论是一个（孤立的）系统中的熵永远不会减少--在最好的情况下它可能是恒定的，但通

我们是一家拥有 80 名开发人员的公司的平台团队。我们使用 Github Actions 为 CI、EKS、RDS 运行一个普通的技术堆栈，没什么特别的。我们在这个系统上运行多个应用程序，所有微服务。管理层明确的方向是建立一个开发人员平台，可以帮助工程师端到端自助服务： 回滚

大多数团队是从高级战略或目标直接跳到产品实施阶段，也就是用产品的成功与否来衡量战略的成功或失败，其实这中间有很多步骤：最成功的团队总会这样做： 1.决策出一个战略 2. 将战略转化为模型 3. 添加最小可行性的测量 4. 确定杠杆点 5

微服务、容器编排等的兴起带来了新的工程挑战。许多组织已经成立了平台工程团队来承担这些责任。 什么是平台工程？平台工程可以让程序员以更简单的方式将软件交付给用户。实际就是运维平台，运维监控平台。平台工程是DevOps和业务程序员

它是供团队协作、集思广益、绘制流程等的在线白板。它易于学习且使用起来很有趣，因此任何人都可以参与并分享他们的想法。FigJam是技术堆栈的图表类别中的一个工具。据报道，有11家公司在其技术堆栈中使用FigJam，包括Modanisa.com 、Productboard和Roo

在过去的十年中，工程和技术组织已经融合了一套通用的最佳实践来构建和部署云原生应用程序。这些最佳实践包括持续交付、容器化和构建可观察系统。与此同时，云原生组织已经从根本上改变了他们的组织方式，从大型部门（开发、质量保证、运营、发布）转移到较小的独立开发团队。这些应用程序开发团队由两个新

用于定义团队 API 的模板。基于Matthew Skelton @matthewskelton和 Manuel Pais 

Zach Lloyd曾是谷歌的首席工程师，负责谷歌表单团队。之后，他在《时代周刊》担任临时CTO，现在是一家建立基于Rust的终端的创业公司的CEO。他还在出版一本手册，记录他作为CTO/工程经理的管理风格。这是他关于他看到的工程师所犯的最大错误的一个帖子的摘要。 <

James Currier是 NFX 的普通合伙人，这是一家总部位于旧金山的种子期风险投资公司。很多早期创始人问我们：哪些指标对我的创业公司真正重要？在投资了数百家公司并自己建立了 10 多家公司之后，我们总是回到技术初创公司的 5 个核心指

产品管理是对回答 5 个核心问题的追求。为什么？Why -- >愿景做什么？What -- >策略做的目标是什么？Who -- >分割何时交付？When -- >路线图如何做到？How -- >规定

对于那些刚刚进入云原生领域的人来说，在一个完全云原生的组织中大规模“左移”的概念可能听起来很未来。对于在生产环境中运行 Kubernetes 多年的云原生领导者来说，左移正在顺利进行。北欧的初创挑战者银行 Lunar 就是这样的组织之一。本文讨论Lunar 的架构、开发人员对生命周期

谷歌有一个 API 问题。正如他们在 2016 年的论文“大规模 API

如何在敏捷世界中交付可靠的架构？这是一种创建适应不断变化的架构的方法。有很多关于敏捷架构的文章，但我认为我们还没有一个公认的实践。好的架构必须考虑许多不同的观点（技术和人的），并不断地权衡一个与另一个。 MVP 论点有

这篇博客探讨在联邦政府内部实施产品管理，尤其是在数字领域。加拿大就业和社会发展部 (ESDC) 是一个服务部门，大多数加拿大政府部门也是如此。ESDC 通过50 个计划提供服务，以提高所有加拿大人的生活水平和生活质量。其中之一是“就业银行Job Bank”计划。