非功能性故障
非功能性故障
原文：https://medium.com/hackernoon/non-functional-failure-489013986d50
在我过去 10 年的学习中，有一件事最为突出。
非功能性故障是软件中最危险的技术风险。
敏捷的设计允许变化，鼓励实验。如果你正在试验你的设计、用户体验或技术，你应该做好失败的准备。通过失败，你会学到更多，允许创新，之后会有更好的产品。我们从受控实验中期待这一点，但当整个服务失败时，我们就陷入了困境。我们必须提防的正是这种宏观失败。
宏失败
credit: NFR 陷阱。陷阱是相信你的团队不会有非功能性问题，因为你有“非功能性问题”。
有些人获得了性能优化。他们测试、分析并解决问题。但是当真正的用户开始使用他们的服务时，他们会遇到性能问题。不幸的是，这些人经常陷入 NFR 陷阱。
NFR——非功能性需求——没有描述真实用户对服务的真实使用水平。相反，非常复杂、难以理解和详细的需求是由一个聪明的软件架构师构建的，他不了解用户需求或用户上下文。
有了服务设计和敏捷开发，我们现在关注用户和他们的需求，用用户故事而不是业务需求来表示。然而，非功能性需求通常表现为一系列关于系统性能、安全性、可用性、可访问性、可用性、可维护性和业务连续性的抽象陈述。它们是抽象的，因为它们与用户无关(不好)，对大多数人来说意义不大(不好)，并且难以测试(非常不好)。
通常 NFR 是分开保存和引用的，但很难证实或批准。NFR 通常源自带有不适当崇敬的模板。以这个 NFR 模板为例。这是许多团队延续的典型特征，但不幸的是这还不够。
两个例子
让我们看两个常见的例子来理解为什么传统的 nfr 是不够的。问问你自己每一个对用户来说意味着什么。
可用性必须不低于 99.9%
这意味着系统应该在 99.9%的时间内可用(工作)，除非它停机进行定期维护。
这有几个问题。当用户需要时，它与可用性无关。如果高峰使用是在早上，但是服务只在白天使用，那么可用性在早上是业务关键的，在下午是重要的，而在晚上不是必需的。
计划内停机将如何影响用户？在 NFRs 中很少看到计划停机，但用户并不关心这一点——任何形式的停机都意味着他们无法使用该服务。因此，对于 24x7 服务来说，了解用户可以容忍的范围以及最大限度减少或零停机时间的设计非常重要。
你怎么能确定 99.9%是必要的呢？这些数字被猜测，被建筑师写在 NFR 上，并且再也没有被质疑过，这并不罕见。一个更好的问题是，当服务不可用时，对用户有什么影响？他们有什么选择？设计一个应急方案或降低服务的高影响领域的复杂性(以允许更容易的冗余)可能会更好地为您的用户节省时间，而不是关注正常运行时间阈值。
90%的页面请求必须在 1.5 秒内完成
这是一个尝试，描述你的服务应该如何响应基于流行网站的经验。它的编写是为了让用户相信你的服务将是“快速”的。在会议上可能已经花了很多时间讨论目标应该是 1.5 秒、2 秒、3 秒还是什么。但这不是没有抓住重点吗？
当然，关键是要了解你的用户期望什么样的性能？什么样的性能水平可以让他们毫无障碍地使用你的服务？为了理解这一点，有必要与用户交谈，与他们一起进行有效的研究，并分析性能数据。您的服务的某些部分可能是时间关键的，而其他部分则不那么重要。使用它来区分服务中关键特性的优先级，避免像上面那样的一般化页面响应时间目标。
当你这样做的时候，确保你通过测试来验证实际的性能。
测试它，不要只是要求它
确保特性得到的衡量是至关重要的，尤其是对于性能而言。性能测试比性能需求更重要。这是因为如果你正在做，你可以很容易地基于测试结果和用户研究迭代和优化性能。团队对特性的主动性能测试应该成为新常态。并且结果甚至可以用于指导用户可接受的性能。
尽管有风险，你的测试可能会提供虚假的信心。为了帮助避免虚假的性能测试，您需要确保存在许多现实因素。
- 对生产规模的基础设施进行测试。如果这是一项新服务，在生产环境中进行测试会更好。
- 使用生产规模的数据集进行测试，最好是生产数据或匿名生产数据。
- 测试峰值负载时的响应时间。您希望您的服务在最糟糕的一天也能像最好的一天一样响应迅速。这意味着在峰值负载下进行测试。
- 确保测试是端到端的。响应时间测试通常只在数据中心的边缘进行(很大程度上是因为它更容易测量)。然而这并不能帮助你的用户。
- 确保测试基于用户设备调节连接和客户端性能。如果有大量用户使用旧设备，速度低于宽带，他们的性能会大大降低。
因此，我们已经看到，NFR 往往过于抽象，很少考虑用户的环境。让我们撕掉 NFR，从以用户为中心的、可测试的、团队开发的常规方面的非功能性需求开始。
非功能性特征
在敏捷开发中，通过将非功能性视为特性，可以将其规范化。正如我们已经看到的，许多非功能性对用户体验有很大影响，因此可以写成用户故事。或者，诸如绩效预期等正交特征可以作为验收标准集成到您的故事中。
什么时候做这件事最合适？贝塔。在测试阶段，您将构建一个端到端的服务，并开始将其用于生产数据。只要确保你的非功能特性是在 Beta 测试的开始时在你的 backlog 中开发的。一直等到测试阶段接近尾声是一种失败的邀请。
在 Kainos，我们为进入测试版的团队编写了一些指南。这些是由一群 Kainos 技术架构师写的，他们已经看到了非功能性故障的低点。这些将有助于指导你应该考虑的一些更重要的非功能特性。
- 您有一个包含非功能特性的 Backlog。
- 您有一个 Backlog 来确保功能故事的操作(实时运行)方面得到考虑。
- 你有一个开始私人测试的生产环境。
- 您有一个部署管道来快速构建、打包和发布产品特性。
- 您有一个部署管道来快速构建、打包和发布补丁到生产环境中。
- 您已经投资于构建、测试和部署(应用程序和基础设施)的自动化。
- 您有工具来了解您的用户正在使用该服务做什么。
- 你有雄心勃勃的规模和业绩目标。不要满足于历史高峰。除了这些性能目标，您还对您的服务进行了负载、压力、带宽和浸泡测试。
- 您已经测试了所有集成点(服务的内部和外部)的性能、规模和稳定性。
- 您需要对性能、应用程序和基础设施进行监控，以了解您的服务在做什么。
- 您可以发出警报，主动发现性能和稳定性问题。
- 您正在将日志信息聚集到一个中心点，并使其对所有开发人员可用。
- 您计划对真实用户进行可访问性测试。
- 您了解服务及其数据的安全分类，以及这对开发、测试和生产意味着什么。
- 你有冲刺阶段的安全测试或安全专家的常规检查点。
- 实时操作所需的应用程序和基础架构的安全控制存在于管道中的所有环境中。
- 您可以向各种浏览器和设备交付服务。
- 您知道如何在不包含敏感配置的情况下开源您的代码库。
- 您能够测试您的服务的故障，并且知道如果部件不可用，它将如何响应。
- 您已经与客户讨论并商定了数字服务的应急方案，并在适当的情况下优先考虑预先建立应急方案的工作(在有严格期限的情况下尤其重要)。
终点
让我们在为公民和客户构建数字服务时不要自满。宏观失败对每个人都不好，让我们努力避免它。
感谢@ johnsrudwick 非常友好地编辑了这篇文章，使之更具可读性。
同样值得称赞的还有《20 点》的合著者凯诺斯建筑师事务所的一群人:罗里、戴维.麦克格拉德、加雷思·沃克曼和卡伊姆欣·格拉汉姆。
如果你有兴趣在 @KainosSoftware 与我们一起开发伟大的软件，我们正在 招聘。
黑客中午是黑客如何开始他们的下午。我们是 @AMI 家庭的一员。我们现在接受投稿并乐意讨论广告&赞助机会。
要了解更多信息，请阅读我们的“关于”页面、在脸书上给我们点赞/发消息，或者简单地说， tweet/DM @HackerNoon。