认识达内从这里开始

稳定性是软件运维管理中需要重点关注的一个软件测试指标，而本文我们就通过案例分析来简单了解一下，软件开发稳定性规范都有哪些要求。

1、研发流程规范

研发流程规范，指的是一个需求从提出到完成的整个过程应该是怎样流转的。一般的需求研发流程包括：产品提出需求、技术预研、需求评审、技术方案设计、测试用例评审、技术方案评审、测试用例评审、需求开发、CodeReview、需求测试。不同公司根据情况会有所调整，但大差不差。

在这个流程中，与研发相关的几个比较重要的节点是：技术方案设计及评审、测试用例评审及评审、需求开发、代码测试覆盖率、CodeReview。我们上面提到的几个影响稳定性的因素，就是因为没有做好这几个节点的工作导致的，包括：

未测试需求直接上线

上线的需求产品不知道

上线的新需求有bug

上线后没有线上验证

系统设计方案存在缺陷

系统代码实现存在缺陷

如果能够处理好上述几个节点，那么就能够极大地降低研发流程导致的问题。这里每个节点都有很深的学问，这里就不展开讲了，我们主要说个思路。

发布流程规范

发布流程规范主要是为了控制发布权限以及频率的问题。

在项目初始，为了快速响应业务，一般权限控制都很松，很多人都可以进行线上服务的发布。但随着业务越来越多、流量越来越大，相对应的故障也越来越多，到了某个时候就需要对权限做管控，并且需要对需求的发布频率做控制。

对于需求发布流程来说，一般有几种发布方式，分别是：ReleaseTrain方式、零散发布方式。ReleaseTrain意思是固定时间窗口发布，例如每周四发布一次。如果无法赶上这次发布时间，那么就需要等到下次发布窗口。零散发布方式，指的是有需要就发布，不做发布时间控制。但这种方式一般只在项目初期发挥作用，后期一般都会收紧。

除此之外，发布流程中都会设有紧急发布流程，即如果某个需求特别重要，或者有紧急漏洞需要修复，那么可以通过该流程来紧急修复，从而避免因未到时间窗口而对业务产生影响。但一般来说，紧急发布流程都比较麻烦，除非迫不得已不然不要审批通过，不然ReleaseTrain方式可能会退化成零散发布方式。

高可用设计

高可用设计指的是为了让系统在各种异常情况下都能正常工作，从而使得系统更加稳定。其实这块应该是属于研发流程规范中的技术方案设计的，但研发流程规范更加注重于规范，高可用设计更加注重高可用。另外，也由于高可用设计是非常重要，因此独立拿出来作为一块来说说。

对于高可用设计来说，一般可分为两大块，分别是：服务治理和容灾设计。

服务治理就包括了限流、降级、熔断、兜底、隔离等，这一些考虑点都是为了让系统在某些特殊情况下，都能稳定工作。例如限流是为了在上游请求量太大的时候，系统不至于被巨大的流量击垮，还可以正常提供服务。

容灾设计应该说是更加点的设计了，指的是当下游系、三方、中间件挂了，如何保证系统还能正常运行?可以说容灾设计比起服务治理，其面临的情况更加糟糕。例如支付系统终是通过A服务商进行支付的，如果A服务商突然挂了，那我们的支付系统是不是就挂了?那有什么办法可以在这种情况(灾难)发生的时候，让我们的系统还能够正常提供服务呢?这就是容灾设计需要做的事情了。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。