本文主要是介绍从哲学层面谈稳定性建设，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
背景
我（姓名：黄凯，花名：兮之）在阿里工作了五年，一直在一个小团队从事电商的稳定性工作。看了很多稳定性相关的文档，很少有能把稳定性说明白的文档。也有一些文档也能把涉及的方方面面说清楚，但是这些方方面面的来源和推导是不提的。我想尝试系统化体系化的讲稳定性讲清楚。因为哲学上讲共性和个性，那么事物都可以按照从共性到个性进行分层描述，我从哲学层面开始讲起，讲到分布式信息化系统层面，希望你能从某个层面获得帮助。能给你稳定性保障一些启发。
下面这个图是从物质拆分到具体信息系统，从物质拆分到基于具体业务的互联网类型信息化系统。我们想搞清楚稳定性是什么要一层层的去分析。
下面这个图是物质的生产过程（实践），从实践拆分到具体业务。其实可以更细，不过本文只挑选几个比较重要的层次讲解，读者可用继续细化。因为物质的生产会影响物质，我们想让生产的物质稳定，要搞清楚生产过程。
哲学层面
定义
从哲学层面讲稳定是物质的一种状态，即事物在持续量变的过程中，对外保持的关系基本不变，那么物质就是稳定的。而稳定性则呈现主观状态，即稳定性是使用物质的人对物质稳定的评价。这就告诉我们不仅要关注物质本身的稳定，还要关注物质不稳定后，尽可能降低使用物质的人的负面评价。通俗的来讲，就是如何让物质不出问题，出了问题如何降低影响面。
特点
所以我们要分析事物的稳定就要看看物质在持续量变过程中哪些对他有影响，改变其对外性质，找到影响稳定的点（出问题的地方）。一个是内部的组成和关系。另外一个是外部环境，外部环境中其他物质和他的关系。对于内部组成，比如一个用了很久的电视，可能里面的电容老化坏掉了，那么电视就坏了，内部模块出问题，导致整个物质发生了质变。对于外部环境，其本质也是影响内部组成而影响物质发生质变。比如现在的电动车在东北低温低区的续航和在南方地区的续航不一样的，其本质还是内部模块的结构发生了变化，但这种变化又是受环境影响引起的。
静态的看：
另外我们动态的看，物质经过产生，使用（可能伴有维护）， 质变（消亡）的过程。此处我们可以看到这些环节从时间上都和物质有交互，都会影响物质的稳定性。
- 物质的产生，可能是自然界自己产生的，或者人通过实践活动生产的，生产的过程如果随意，技术落后，可能导致最终物质不稳定。生产关系如果不能适配生产力，那么生产出来的东西稳定性也可能受影响。
- 使用是一个物质出来给其他角色使用，那么这个物质在其他实践环节，可能就是个工具，那这个工具除了自身的稳定性外，在其他实践环节中能帮助其他实践中的主体取得改造客体的结果也是非常重要的，如果不能帮助其他实践主体达成目标，可能也会被认为是不稳定的，或者是无用的。举个列子你设计了个系统，比如说商家上架售卖的商品不允许随便下架。有一天商家发现他卖的东西亏了，要紧急下架，一下架就报错，对你来说是稳定性的，但是对于商家卖货的逻辑来说，这就是不稳定的了，为啥有时间能下架，有时候不能下架。这也是很多产品，研发人员觉的很稳定，运营觉得很不稳定的原因，因为你没让人家把的实践目的达成。
- 维护本质上是减慢事物质变的过程，通过替换内部组件，维护外部物质的关系达成。比如数据库里面的数据量大以后，可能会出现查询超时等，我们可以替换更高级的数据库硬件，或者做一下历史数据迁移等，尽可能保持对外属性的一致。还有就是物质的性质就是发生变化了，如何保障物质和其他物质的关系稳定。比如技术系统出bug了，有些紧急操作是不是可以通过技术人员去替运营人员做。当然维护由于对系统改动了，也会引起稳定性问题。
- 消亡是指物质发布质变的时候，如何降低对其他物质消极的影响。比如你要下线一个很多年在线的功能，如何降低这个功能下线对依赖这个功能的影响呢。当然也可能成为其他实践改造的客体，成了新的物质。
动态的看
另外稳定性是主观的，我们需要考虑使用者，以及对使用者主观性评价的影响，即生产关系层面的影响。就是有些时间你觉得明明是个小问题，但是使用者认为是个大问题，很可能是这个层面出问题了。我们在设置稳定性指标的时候，即要考虑使用者评价的客观，也要考虑使用者评价的主观。
利益分析
主要角色和利益诉求
物质生产者
- 核心利益诉求：把能满足其他实践活动使用的物质生产出来
物质使用者
- 核心利益诉求：物质要稳定的满足使用者改造客体的诉求。
物质维护者
- 核心利益诉求：物质尽可能少出问题，减慢物质的质变过程。如果出了问题之后能尽快解决，尽可能降低和消除影响面。
物质
- 核心利益诉求：能满足使用者的利益诉求，是生产者价值的体现。
对立统一分析
使用者和物质之间的对立统一
对立：使用者期望在自己实践过程物质保持稳定和物质天然存在量变而最终质变（即不稳定的趋势）之间的矛盾。
统一：物质存在的意义就是上一个实践活动为了满足这个实践活动的需求，和使用者在这个实践活动中对他的需求之间是统一的。
这是这个系统最主要的对立统一，如果这个对立统一不存在，整个系统将失去意义。
生产者和物质之间的对立统一
对立：生产过程的不稳定，不规范，以及物质本质不稳定 与 生产者期望生产出来的物质稳定之间的矛盾。
统一：物质的稳定也是生产者价值的体现和生产者对物质稳定性追求是一致的。
维护者和物质之间的对立统一
对立：维护者期望在自己实践过程物质保持稳定和物质天然存在量变而最终质变（即不稳定的趋势）之间的矛盾。
统一：物质的稳定以及物质稳定的评价是维护者价值的体现。
业务层面
在业务层面物质的产生，是通过公司生产来产生。物质传递到使用者的手中是交付环节。延长物质质变的流程是维护阶段。物质的质变，通常是下线报废来实现的。以及这些环节之间相互关系及其新成的生产关系都会影响稳定性评价，这些关系通常是一个公司内不同部门，不同组织，或者跨公司的组织或者部门。下面从一个业务的流程来分析不同流程对产品最终稳定性的影响。
生产环节
生产主要包括产供销，财税法， 这些环节也会影响最终物质的稳定性。比如原材料质量不合格，那么最终物质可能就比较容易坏。比如钱不到位，服务器不能及时购买，那你线上系统没有足够的机器运行，可能系统的稳定性就满足不了。
交付环节
有些物质对交付要求蛮高的，我们要通过设计合理的交付流程，来保障物质的稳定。比如一个玻璃杯子，如果不注意运输环节（将东西从生产者运到消费者手中），那么杯子可能路上就坏了，可能路上没坏，用几天就坏了。所以针对杯子的运输，我们需要用泡沫包裹，然后让运输人员轻拿轻放等。
使用环节
使用的时候影响稳定性的因素包括使用者使用方法得当吗，物质所依赖的其他物质和环境是符合预期的吗？所以我们出厂产品的时候就会提供说明书，告诉使用者正确的使用方法，也会说明需要的环境和工作条件。
维护环节
维护环境包含两个事情，一个事情是发现可能或者即将损害的某块进行替换或者保养。一个是产品出问题了，如何解决这些问题对使用者造成的影响，一方面是修复这个产品，另外一个就是将影响的方面也给修复或者补偿等。
下线（报废）
有些产品的质变影响可能不大，不需要特别关注，比如一个凳子突然坏了，人最多摔一下。 但是一个汽车如果行驶途中突然坏了，那么造成的影响是巨大的。质变就标志着物质不稳定了，但是我们还是希望它质变的时候带来的影响尽可能少。所以在设计生产环境，也要考虑一下下线（报废） 的时候，如何尽可能减少影响。
互联网信息化系统层面
当互联网企业出现后，区别传统企业生产和使用系统的人基本是跨组织的，生产和运营流程变的非常紧密，基本都是一个组织内部的人，这其实是生产关系发生了改变，适应了进步的生产力，提高了生产效率。同时这也给很多人分析稳定性的时候，不能把生产流程和使用流程区分开，混在一起讲，总感觉讲的不完整，缺点什么。
其实很多文章讲的稳定性主要集中在下面的章节中若干部分。我这儿就不讲的特别深入了，如果你负载那块，需要深入了解的，可以参考其他文章。
下面从整个常见的互联网行业，分布式信息系统的研发过程来看那些环节影响稳定性，如何设计流程，研发工具，改变组织架构来保障最终产品的稳定性。
信息系统研发
研发流程对稳定性的影响
- 需求分析设计
一个无用的产品，稳定性无从谈起。稳定性是一种评价，使用者都不使用，那就没啥稳定的意义。所以作为开发人员一定要去思考产品设计的需求是不是真的解决了使用者的问题，不要浪费时间做无用的系统。
- 技术方案设计
- 开发和代码审核
- 发布流程自动化，规范化
- 发布
- 如何预测问题并消除和防御。
研发生产工具对稳定性的影响
科学技术是第一生产力，好的生产工具，可以降低对研发者的依赖。如果很多流程都是靠人工处理的，比如以前商店结账的时候，都需要人工算，很容易出错。后来有了计算器，求解的过程不需要人操作了，大大降低了出错率，但是产品的单价还需要人输入，还是可能出错。现在计算机+扫码枪的出现，输入都不需要人操作了，直接扫条形码，出错率更低。所以做稳定性工作的同学，要尽可能将研发流中能信息化，自动化的都自动化，甚至包含整个研发流程本身这个流程也要信息化数字化。
研发的人，组织关系
研发者的个人素质，个人知识水平，个人对研发工具的熟练程度都会影响最终产品的稳定性。所以做稳定性建设的同学经常会组织技术分享，研讨会，开设知识论坛等，这些就是通过提升研发者个人知识水平。还有师兄帮带，一方面提升个人知识水平，另外一方面也让研发者尽快熟悉研发工具。还有有些公司（如阿里）会进行价值观建设，就是提升研发者的个人素质，提升个人的责任感，对研发软件系统负责。
研发组织的关系和对应的规则奖惩制度，也会间接影响产品的质量。一个混乱，内部矛盾较大的组织，很大可能研发的软件系统充满各种问题。我们看到公司会给每个研发者打稳定性的分，然后来 调整年终奖的比例。比如一次影响面较大线上故障，可能直接将年终奖归零，这都是通过组织的制度来影响产品质量的。
信息系统交付
交付流程对稳定性影响
你可能把系统交付给普通消费者使用，交付给运营使用，交付给其他B端客户使用。不同的交付对象，交付流程不一样。我观察到，很多开发同学不大关注交付流程，尤其是交付给运营的，认为需求变更发布到线上，就交付完了，没有考虑到如何让运营知道你的新功能上线了，运营怎么用你的新功能，这样如果流程不规范，那么运营会觉得你这个系统不稳定。还有交付给B端客户，很多研发团队的交付流程也不规范，拉个群，一堆开发在群里面，客户提个问题，研发很久不理，也没人跟进。那么客户认为这个交付流程是稳定的。还有和其他系统对接，没有将当前系统的各种异常情况讲清楚，客户没有充分了解，那生产出的最终系统会存在稳定性风险的。
技术对交付稳定性的影响
同理好的交付技术工具，保障了交付质量，从而保障最终物品的质量。比如给客户提供各种异常Case的Mock能力，让客户可以自助的完成各种场景的Mock。客户上线时候通过系统校验客户完成了各种场景的验证，保障上线的质量，从而保障线上系统的稳定性。
交付的人，组织关系
组织关系这块基本同研发流程差不多，这儿不展开讲了。
信息系统使用环节
信息系统本身（使用物）对稳定性的影响
这是一个比较通用的分布式信息系统的架构分层，我们需要再每一层都做稳定性建设，思考每一层会出哪些问题，出了问题需要怎么应对。比如为了因对机房的的问题，我们可能需要多机房部署。为了因为虚拟化计算平台异常，我们可能需要多云部署。对于我们一般的开发人员，能花费大量时间做的事情其实主要在合理使用分布式架构本身和分布式架构保障业务代码出问题之后减少影响这块。这儿简单展开一下。
分布式架构
- 高可用
- 服务治理： 限流，降级，熔断，隔离，负载均衡
- 一致性
- 分布式事务，按照实际业务需求选择，一致性强弱基本和性能成反比。
使用者对稳定性的影响
不同的使用者类型也是需要考虑的，可能是面向C端的消费者，可能是面向B端的企业客户，大概率可能都有。对于面向C端的消费者，易用性一定是第一位，一个不易用的产品，对于消费者来说就是个有问题的系统，不稳定的系统，同时还要系统尽可能兼容C端各种千差万别的环境，不同的手机，系统，网络，温度等等等。但是对于B端来说，B端业务逻辑相对复杂，我们要给B端提供操作手册，SOP要规范，对B端客户的环境相关可以做一些要求。所以我们做稳定性的人，需要考虑C端不同环境的兼容，也需要考虑B端如果不按照手册操作是不是会把系统搞挂。还要考虑使用者的数量，并发等。
线上问题应急
线上问题应急流程对稳定性影响
线上问题会可能影响到使用者（当然有些问题可能不会影响使用者）。我们需要解决如何快速的发现问题，如何降低对使用者的影响，一方面是怎么尽快解决线上问题，一方面是如何将受影响的用户和数据进行修复。我们维护稳定性建设的团队，其实在这一块做的比较多，建设各种可观测系统，添加各种告警。但是出了问题之后，应急预案做的比较少，这儿的预案一方面是止血，一方面是数据修复。还有流程上面，我们可能会根据不同的影响程度，设计不同的响应流程。
技术可以增加线上问题应急的稳定性
通过技术手段可以帮我们加速问题的发现，加速问题的诊断，加速问题的解决，保障应急流程顺畅高效。比如阿里内部会根据影响面自动拉群，拉人，让相关的人参与排查解决问题。
应急团队的人，组织架构对应急的影响
组织关系这块基本同研发流程差不多，这儿不展开讲了。
系统服务下线升级
系统服务下线或者不兼容升级，我们要考虑如何降低对依赖这个系统的人和组织的影响。 从稳定性建设方面来讲，我们需要梳理所依赖它，谁使用它。和依赖方和使用方沟通，我们要下线、不兼容升级，给他们提供相应的解决方案等。
组织关系对稳定性评价的影响
由于系统架构的复杂，基本上不可能一个团队维护整个系统，会有好几个团队（或者跨公司）参与维护。那么这些涉及的团队间的组织关系对稳定性也是很重要的，你依赖的一个重要组件的团队，对你们系统出问题，不积极响应那么解决，也会影响稳定性。
另外如果你的系统是ToB的，那么使用者的关系也可能会影响你系统稳定性的评价，毕竟稳定性是个感受，是个评价。这儿你可以考虑维护好客户关系出发，让系统变的”稳定“，但稳定是事物本质的属性，做好系统的稳定建设是根本。
总结
本文从演绎的角度从顶向下分析了稳定性建设的方方面面。但这并不是否认通过经验归纳的重要性。而是很多人没有机会站在整个公司的角度去看稳定性问题，只是其中的一个维度的某个层面上或者上下几个层面经验的总结，很难新成系统化体系化的结论。本文系统通过本文让大家能从最宏观的角度看待稳定性建设。
这篇关于从哲学层面谈稳定性建设的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
