如何设计
法则一 将成本作为非功能性需求
【简称NFRs），Non-Functional Requirements】。
非功能性需求指定了可以用来评判系统运行的标准，而不是具体的特性或功能。
例如SRE涉及的可访问性、可用性，云上可伸缩性、安全性、可移植性、可维护性和合规性。而这些经常被忽视的是成本。公司可能会此失败，因为它们没有在业务的每个阶段考虑成本——从产品设计到应用开发再到线上运营——或者因为它们没有正确地衡量它而被忽视。
虽然在数学很简单：如果成本高于你的收入，你的业务就有风险。通过产品早期和持续考虑成本影响，系统可以被设计出来平衡特性、上市时间和效率。开发可以专注于维护精简和高效的代码。运营可以微调资源使用和支出，以最大化产品的盈利能力。
法则二 持续性系统确保成本与业务目标相符。
法则三 架构设计是一系列权衡。
在架构设计中，每个决策都伴随着权衡。成本、韧性和性能是通常相互冲突的非功能性需求。俗话说，“一切都会失败，一直都是。”能够抵御失败意味着要投资于韧性，但性能可能要付出代价。找到技术和业务需求之间正确的平衡点至关重要——找到与你的风险承受能力和预算相符的甜蜜点。记住，节俭是关于最大化价值，而不仅仅是最小化开支。为此，你需要确定你愿意为什么付费。
如何度量
法则四 未观察的系统导致未知的成本。雨生点评【可观测的重要性？】
如果没有仔细的观察和测量，系统运行的真实成本将保持不可见。就像一个隐藏在地下室的公用事业表，缺乏可见性会导致浪费的习惯。让计量表更加可见可以深刻改变行为。尽管观察需要投资，但不实施足够的监控是目光短浅的。有句格言警告说：“如果你测量不了它，你就无法管理它。”跟踪利用率、支出、错误等对成本管理至关重要。当关键成本指标摆在工程师及其商业伙伴面前时，更可持续的实践自然而然地出现。持续的检查让你能够发现过度支出，并调整运营以削减开支。投资于可观察性的回报通常远远超过支出。最重要的是，将成本摆在前台可以鼓励可持续的实践。
法则五 成本意识型架构实施成本控制。
节俭架构的精髓在于强大的监控能力，结合优化成本的能力。精心设计的系统允许你采取行动改进机会。为了实现这一点，需要将应用程序分解为可调整的构建块。一个常见的方法是按关键性对组件进行分层。第一层组件是必不可少的；不惜成本也要优化。第二层组件很重要，但可以在不产生重大影响的情况下暂时缩减规模。第三层组件是“锦上添花”的；使它们成本低并易于控制。定义层次使得在成本和其他需求之间进行权衡成为可能。对组件的细粒度控制优化了成本和体验。基础设施、编程语言、数据库都应该是可调的。用收入和利润为目标来构建系统。成本优化必须是可衡量的，并与业务影响相关联。
如何优化 法则六 成本优化是渐进的。
追求成本效率是一个持续的过程。即使在部署之后，我们也必须重新审视系统，逐步提高优化水平。关键是不断提出问题并深入挖掘。编程语言提供了分析代码性能的分析工具，尽管这些工具需要设置和专业知识，但它们使得可以进行细粒度的分析，这可能导致节省几毫秒的变更。看似微小的优化在规模化时会累积成巨大的节省。在运营中，大部分时间都花在运行现有系统上。
有机会对资源使用进行分析，识别减少浪费的机会。在亚马逊，我们持续监控生产中的服务，以了解模式并减少低效率。节俭需要坚持——通过逐步减少延迟和基础设施成本，我们可以优化服务成本。总有改进的空间……如果我们持续寻找。我们今天节省的资金为明天的创新提供资金。
法则七 未受挑战的成功导致假设。
当软件团队在没有面临重大失败或障碍的情况下取得显著成功时，自满可能会滋生。过分自信于那些带来胜利的方法、工具和实践是一种危险的倾向。
软件团队经常陷入这样的假设：他们当前的技术、架构或语言总会是最佳选择，仅仅因为它们在过去工作得很好。这可能会造成一种错误的安全感，阻碍质疑现状或探索可能更高效、更具成本效益或更可扩展的新选择。
在编程语言方面，这种情况经常发生。“我们是一个Java店”是我听到的太频繁的一句话——它可能扼杀创新。未受挑战的成功通过假设培养自满。我们必须始终寻找质疑、优化和改进的方法。
正如格雷斯·霍普（Grace Hopper）著名地说过，英语中最危险的短语之一是：“我们一直都是这样做的。”
参考链接：
https://thefrugalarchitect.com/laws/architecting-is-a-series-of-trade-offs.html
