作为一名解决方案架构师，我在为软件服务公司工作时，因为一个错误的决定而失去了一个价值100万美元的客户。
我们正在创建一个订单管理系统，用于服装补货。从excel和邮件，我们必须过渡到一个适当的系统与角色，状态等问题是，我低估了系统的负载和失败的数据建模，并选择了错误的数据库。 项目开始半年后，客户解雇了我们，服务公司损失了100多万美元的潜在利润。
因此，架构决策至关重要！今天，我们讨论在做出架构决策时面临的最大挑战。
挑战1：缺乏专业知识
假设你开始一个新项目。许多尚未做出的决定之一是数据库。例如，在JetBrains的2022年开发者生态系统调查中，69%的受访者同时使用两个或更多数据库，这意味着大约31%的人使用单个数据库。单一的数据库体验使我们无法做出明智的决策。
当然，在最初的几年里，使用PostgreSQL或Mysql或任何其他经过战斗考验的数据库都不是一个坏的选择。然而，这种策略是闭上眼睛，希望最好的，而不是做出理性的决定。如果情况需要将灵活性优先于模式严格性，则它可能会呈现为假。当然，如果你了解并知道如何使用它，你可以在Postgres中模拟一个带有JSON字段的文档存储。
挑战2：错误的焦点
你刚找到一份新工作，加入了一个新团队。您克隆了主存储库，并立即得出结论：缺乏集成测试，代码质量不佳，端点输入的自定义验证而不是正式的方案。到底是谁写的这段代码
您开始说服团队和工程经理，团队绝对需要立即解决技术债务。每个队员都表示同意，但没有表现出任何兴奋。在我的职业生涯中，我多次看到这种情况，原因总是一样的：一个新成员只是缺乏故事和背景来做出正确的结论。
事实上，部分问题可能是工程师从来不关心或不知道方便的库和工具。然而，真实的原因是，技术债务总是一种权衡。在理解最终画面之前，对技术的过度投资会让你痛苦不堪。有时候，这是一个完全打击解决方案的矫枉过正，因为他们也有自己的复杂性。
挑战3：缺乏或误解需求
有多少次你看到人们从第一天开始使用微服务？或者从Kubernetes集群开始，而不是单个VM，或者至少是一个托管容器服务？互联网上充满了这样的故事，比如“我选择了Kubernetes，作为CTO毁了我的创业公司”。
这不是CV驱动的开发故事。这是一个被误解的需求的故事。工程师会告诉你，他们需要可扩展性，或者他们必须去偏执的安全性。这并不是一个坏的信念：这是他们以前的经验，同时忽略了实际的业务需求。
你预计会有多少客人？负载将如何随时间变化？安全性是首要考虑的问题，而不是速度，让我们说？
在某些情况下，你会知道答案，在某些情况下，你不会。这是正确的-只要你做出合理的假设。
挑战4：分析不足
任何决定都有后果，都有风险。即使是最传统的选择，如PostgreSQL，也有写入放大问题的风险。它也有像次优水平分片的后果。
另一个缺少后果分析的例子是成本计算：好吧，你决定使用Fivetran作为你的数据摄取机制，因为有数百个现成的集成。但是你要付多少钱？在您的特定业务案例中值得吗？
观察到在ADR中做出的决定缺乏这种分析。
挑战5：情感依恋
奥拉夫齐默尔曼强调，工程师重视他们的技术选择。
我在实践中也看到了这一点：人们实际上只会把优点放在他们首选的解决方案上，而只会把缺点放在所有其他选项上。
任何解决方案都有利弊，并作出决定总是关于权衡。