七爪源码：软件工程中的可靠性

为不可靠的场景构建软件和流程

尽管软件行业已经看到了许多创新、成就、复杂的系统和经验丰富的老手，但与其他领域和实践相比，它还显得如此年轻。

在某些情况下，构建软件本身可能是微不足道的，但为了提供真正最先进的质量，我们首先必须对其进行工程设计，这不仅关乎服务，还关乎其背后的团队和人为因素。

没有它，我们是否可以建立质量体系是值得怀疑的。

软件可靠性

可靠性是描述质量软件的特征之一，并概述了好与坏之间的区别。

可靠的软件是能够容忍故障甚至无故障的系统。

它是在给定环境中给定时间段内组件无问题操作的概率。

在考虑可靠系统时，有一句话让我印象深刻：

可靠性是拨动开关，知道灯会亮起。

可靠性不是另一个衡量标准，但它本身就是客户体验系统的方式。

这不是静态特性。从某种意义上说，它是动态的，系统可以承受各种情况下的故障，无论是预期的还是意外的。

弹性是方式，可靠性是结果。

如果没有弹性，系统就不可能可靠，反之亦然。

根据您居住的世界的哪个部分，您可能经常听到这两个词可以互换使用。尽管如此，它还是有一些区别。

软件系统的弹性实际上是通过它可以承受和减轻威胁的好坏程度和程度以及恢复的速度来衡量的。

将软件系统标记为可靠需要我们确保组件的操作和设计到位。

无论行业、公司规模、优先事项和客户如何，每个人都希望他们的软件组件和平台始终能够正常工作。

可靠性设计

设计和构建可靠的软件是每个相关人员的责任，无论是 UI/UX 设计师、产品经理、工程师、架构师，还是底层基础设施和硬件提供商。

为了使软件可靠，首先必须将其设计为：

在预测和不可预测的情况下，组件必须保持功能。

建立可靠的系统是为了值得信赖。

在服务、组件或产品的设计阶段——我们已经开始努力争取可靠性。

设计缺陷通常会导致混乱和不必要的复杂性，并可能为脆弱的解决方案奠定良好的基础。

在概念阶段，您可以使用两种可靠性模型：

软件可靠性目标设定

软件可靠性计划计划

将可靠性作为目标，在设计、概念和开发过程中审查和分析决策，甚至在您开始交付产品之前，结果就会大大改善。

利用其他用于设计可靠性的技术，例如：

“可靠性设计”本身就是一个模型，通常是卓越设计的一部分。

常见威胁

我们挥手识别常见威胁，以改进系统并将其设计为具有适应性并准备好缓解问题。

每个系统的一组常见威胁可能如下：

该列表是一个非常粗略的列表，并且可以达到相当程度。

可靠性通常与软件系统中的一切对与错有关。所有可能导致它失败的因素本质上都是威胁，从安全性、糟糕的设计和有限的硬件资源到不正确和不可预测的问题。

根据经验，故障是由以下原因引起的：

伟大的软件易于维护、简单、有效和健壮是有原因的。但它必须像这样设计和建造。

缺乏从故障中恢复的能力也是一个主要因素，并且经常影响系统的可靠性。

克服障碍

我们所有人都会遇到成千上万次无法正常工作的软件。

它不会中断，它不会抛出一个标志，通知你有一个错误——但由于某种原因，它只是没有按照它的明确意图去做。这意味着不公平、糟糕的设计和对其行为的零预期，并尖叫着“我不擅长我应该做的事情”。

可靠性也被设计到产品和流程中。

透视就是一切。首先，从用户的角度来看你的软件。使用它，试一试——满足消费者的需求。

从技术角度改进您的产品，然后处理您的流程并研究可以改进的地方。

始终分析您的软件、功能、威胁、错误、事件和问题。

从技术上讲，需要结合以下所有实践和概念，以便我们改进我们的软件：

可靠的软件不是一天建成的，也不是一天证明的。必须实现可靠性，您设计、构建和改进系统的方式都是其中的一部分。

失效模式和影响分析

有许多框架和模型可以帮助您克服问题、分析和改进您的解决方案。

其中之一是失效模式和影响分析。 FMEA 是一个系统的、主动的框架，用于识别可能的故障及其影响。

这是一个审查组成系统的组件和部件的过程，并让您识别故障原因和影响。

FMEA 是可靠性工程的核心任务。

许多公司和 区没有这样的模型，但仍在努力追求高质量、稳定性和可靠性。

它只是让您识别：

事件指标

故障、中断和错误——全因停机并影响系统的可靠性。

跟踪与事件相关的指标是必须的。事件管理、检测、诊断、解决和预防都是工程部门的 KPI。

就 KPI 而言，其中只有以下几个：

只有当你有了这些，你才能真正了解哪些部分可以改进，无论是每个团队、产品、服务，还是整个工程部门层。

待命轮换

无论您有专门的支持团队，还是您的开发人员支持内部组件，您都需要随叫随到的轮换。

事实证明，它有益于您的软件质量和可靠性。

对待命期间处理事件所花费的时间进行衡量也是产生更多洞察力的非常有用的方法。

尽管如此，世界上所有的 KPI、度量和指标都无法取代上下文。事件是独一无二的，统计数据有时是陷阱。对事件的上下文感知分析是必须的，而且通常只需要一点常识。

警

拥有指标来分析您的组件非常棒，甚至在客户注意到问题之前就拥有实时警 非常棒。

可靠性不仅仅体现在软件中，还体现在背后的团队中。

为了向消费者提供可靠性，需要提醒和响应问题。缓解是关键——在问题爆发之前检测到问题，您的客户甚至会注意到它，让您描绘出完全不同的画面，并使您能够防止事故发生。

警 是必须的。根据经验，您会惊讶于警 带来的好处。试试看哪些渠道最适合您：

许多成功的公司都具备所有这些。警 与监控一起成为全公司范围内的举措是值得的。

六个西格玛

六西格码设计，或 DFSS — 是软件工程中的一种系统方法和模型，其目标是实现可靠性。这是一个产生高质量和改进质量的过程。

六西格码将使您拥有：

所有这些都是可靠软件的先决条件。这又允许您合并一个 DMAIC 循环，即 Design-Measure-Analyze-Improve-Control 的缩写。

软件可靠性有很多概念、因素和方面，但希望以上总结了其中的一个很好的部分。这个故事的目的是阐明已经确立的概念，但也阐明一些鲜为人知的概念。软件可靠性只是工程的一部分，但从本质上讲，它本身就是一门科学。

我希望你喜欢这个故事并且觉得这个故事很有趣，无论你是工程师、建筑师、经理还是设计师。关注并订阅我的时事通讯，以继续关注更多类似这样的故事。

感谢您的阅读！