vlambda博客
学习文章列表

服务品牌

“品牌是一种提供均质服务的能力”，放在软件领域也同样适用。

软件领域的“均质服务的能力”是什么？我理解他应该是软件系统的在高质量前提下的稳定性，也就是我们在技术层面常说的高可用。

影响因素

影响系统稳定性的三个因素：

1、概率：不稳定因素的出现概率

2、范围：影响的波及范围

3、时间：影响的持续时间

实践方法

本文从软件研发的生命周期的视角，讨论如何实践服务的高可用，这个过程着重主动的面向故障的设计。

另一方面，在一些意料之外的地方，可以借助混沌工程、周期性的压测“被动”的发现问题。

以下主要从研发周期来谈谈个人想法。

各阶段常见的策略

1、参考国内互联网公司（阿里、美团、字节）的研发经验，其研发流程符合软件生命周期管理理论，具体可简化为以下7个阶段：

软件服务的稳定性，其性质更偏向于非功能性需求，因此讨论的重点从技术设计阶段开始递进。

这5个阶段可着手的内容：

1）设计阶段

对于一个业务价值驱动的项目来说，在设计阶段实现业务需求是最重要的，但是对于一个高可用的系统来说，完成业务需求设计只是基础的工作。

需要考虑设计方案的高可用，我们比较推崇的方法是面向故障的设计。

比如：方案涉及到的链路是否存在单点问题；是否具备对不可用服务的自动降级能力；入口流量异常情况下是否具备自我保护的能力；容量评估是否合理；各“渠道”是否存在相互影响的可能。

2）开发阶段

进入开发阶段，在流程正规的公司，核心的业务逻辑和方案确立的情况下，主要的工作内容是业务实现。

这个阶段除了开发者的个人能力之外，通过开发规范去实践也是一种思路。

开发规范的价值在于：通过合理的约束可以让各位开发者，在编码风格，使用习惯上，达成一致而不放任自流。

   a. 规避低水平、无价值的踩坑;

   b. 理解的一致性，认知成本。

规范的管理属性，它消极的一面在于，可能限制部分的创造力和协作效率，这虽然是个管理的难题，但仍然值得推崇的原因有两个：

  a. 相对于小概率出现的高价值创新，对无序行为的约束带来的价值总和会更大；

  b. 优秀的实践是允许迭代的；

3）测试阶段

测试是一门专业的学问，测试阶段对于提升稳定性的思路是尽可能高效、全面的覆盖需求。作为软件交付的“守门员”，高质量、高效率的测试计划是系统稳定的一颗定心丸。

4）部署阶段

据google的统计，超过85%的不稳定因素都是发布变更带来的。部署过程中的兼容性、策略、告警、快速回滚显得尤为重要。滚动发布、蓝绿发布，包括重大变更选择在深夜的原因，其核心因素是为了缩减影响范围。

5）运维阶段

运维阶段在整个软件的生命周期中，相对其他阶段要更长。

互联网从业相对较频繁的人员流动，开发者本身认知的局限，在复杂度背景的加持下，很难感知到系统全貌，因此对于系统的核心业务指标观测能力显得尤为重要；

其次，在业务正常发展的过程中，服务的弹性能力(stateless)可以应对不少的突发状况；

最后，SOP的价值在于事故发生时可以从容应对，但是SOP本身的管理和传达是一个难点。智能运维由于了解不深，且在过往经历中应用较少，暂且不谈。

后记

稳定性作为一个相对的概念，每增加一分都代表成本，不求最佳，只求平衡。

No code; deploy nowhere ~

Reference

https://github.com/kelseyhightower/nocode