初创公司申请：扩展前真正重要的事项清单

在初创公司的生命周期中，有那么一个时刻，应用程序不再是一个承诺，而是成为一个值得拥有的好问题。用户数量不断增长，基础设施开始受到压力，支持团队收到更多的票证，基础设施也开始出现疲劳迹象。现在是扩大规模的时候，也是许多初创公司做出错误选择的时候。

陷阱很微妙。能够验证这个想法的东西很少能维持增长。证明假设的代码是为了快速而编写的，而不是为了持久。本来就是这样也没关系。错误在于以与发现阶段相同的心态对待规模阶段。

这是为此时此刻的创始人和产品负责人准备的清单。这不是流行技术的列表。这是一系列问题，将健康攀登者与负债攀登者区分开来。

在检查清单之前：您是在扩展还是只是在增长？

增长意味着销售更多。规模不断扩大，但成本、复杂性和工作量却没有以同样的速度增加。它们是不同的东西。

一家初创公司可以将其用户增加一倍，并将其问题增加一倍，这是原始增长，而不是规模。规模是指当用户数量增加一倍并且团队可以处理它时，因为流程、架构和产品就是为此设计的。在升级之前，有必要诚实地了解正在发生的事情。有时，看起来缺乏技术能力实际上是缺乏重点：初创公司正在扩展一些尚未证明其值得的东西。

第一项很少是技术性的。这是一个产品。您知道应用程序的哪一部分负责保留吗？其余用户实际使用哪些功能？

扩展一切都是昂贵且不必要的。大多数应用程序都有一个小核心，可以产生几乎所有的价值，周围有任何人都不会错过的功能。在投资性能和基础设施之前，先确定这个核心。扩展重要的事情；质疑其余的。

成熟的标志是有勇气移除。废弃的功能不是中性的，它会增加维护成本，增加错误面并使用户感到困惑。切割是攀登的一部分。

每个系统都有一个瓶颈，并且它会在负载下出现。问题是您是否会在周六晚上的测试或生产中发现它。

这并不是要求重写所有内容。这是一个在达到极限之前知道极限在哪里的请求。

扩展应用程序而不扩展周围的操作就意味着混乱。更多的用户意味着更多的支持、更多的事件、更多的可靠性费用。

问问自己：是否有事件响应计划，或者每次事故都是临时安排的？部署是否足够安全，可以每天进行多次，还是仍然是一个危险事件？是否有经过测试的备份，不仅是配置的，而且是通过恢复进行实际测试的？凌晨发生故障时，是否明确向谁打电话？

这些问题并不光彩夺目，但它们却是一家能经受住打击的初创公司与一家一直在救火的初创公司的区别所在。可靠性是一项功能，即使用户只有在缺少该功能时才会注意到它。

增长增加了风险面。更多用户、更多数据、更多目标。在巴西，更多的个人数据意味着 [LGPD0] 承担更多的直接责任。

在扩展之前，请回顾一下通常留到以后使用的基础知识：明确定义的访问控制（谁可以查看和执行哪些操作）、仔细处理敏感数据、代码之外的秘密，以及明确您收集哪些个人数据及其原因。通过加载已知漏洞来升级问题也会随之升级。

早期实施的安全保障比事件发生后实施的安全保障要便宜。正确做事的成本总是低于解释为什么不做这件事的成本。

创业文化中存在一种危险的偏见：对规模的迷恋。会议、投资者和创始人的自我意识推动了公司的快速发展。但过早攀登也是一种优雅的死亡方式。

在获得吸引力之前，对分布式架构、[微服务1]和复杂的基础设施进行大量投资，就是针对你还没有遇到的问题进行优化，而忽略了你已经遇到的问题，这证明有人想要该产品。过早的复杂性会像脆弱的代码一样杀死初创公司。

成熟的平衡说起来很简单，但实践起来却很困难：尽可能保持简单，并在数字而不是自我需要时进行大规模投资。扩展是对真实需求的响应，而不是对幻想的预期。

扩展应用程序与技术无关，而与决策成熟度无关。它知道什么值得扩展，系统会在哪里崩溃，什么需要共同成长以及何时说“还没有”。

准备秤的最佳时间是在您需要之前，但要冷静，不要将准备与过度设计混为一谈。一个具有良好扩展性的应用程序是在正确的时间做出好的、小的决定的结果。

如果您的初创公司正在经历这种转变，并且您希望在做出困难的架构和产品决策之前先了解一下外部情况，那么值得交换一下想法。博客上还有其他有关后端、基础设施和产品的文本，这些文本加深了此清单的要点。