在咱们聊企业级 SaaS 产品安稳性之前咱们先界说一下这儿的企业级 SaaS 产品是什么,安稳性是什么。

1. 企业级 SaaS 产品

根据各家研报的界说,企业级 SaaS 是指以企业客户为服务方针,经过 SaaS 交给形式,向企业用户供给办理软件的服务。主要具有网络供给,会集保管、按需供给及服务化四大特征。

  • 网络供给 是指 SaaS 产品大多布置在云端,每个客户运用产品的方法,经过互联网进行分发;
  • 会集保管 是指运用「多租户构架(Multi-Tenant)」,依靠对数据库分区/分表(其间的一种完成方法)来完成阻隔操作,逻辑上阻隔,物理层面是同享的。对私有化布置的客户,会单独处理;
  • 按需供给 是针对中小企业的需求,中小企业的需求在短时刻内有较大幅度的改变,特别是一些快速增加的发展类企业;
  • 服务化 是指 SaaS 企业按月/年付费的商业形式,其中心的增加逻辑在于继续服务的才干,这也是 SaaS 企业的中心竞争力,第一次交给产品仅仅整个客户生命周期的起点。

以上 4 个特征能够让客户享有开箱即用、较低本钱、实时更新以及按需订阅的长处。

1.1 SaaS 产品和 C 端产品的区别

SaaS 端产品面临复杂的事务场景和用户场景,因而进行细节规划时,有必要重视建模、笼统、人物、权限等问题。除了运用者本身的功用需求以外,还需求考虑办理者或许决策者的办理需求。C 端产品面临的场景相对单一,而且运用者是相对独立的单个用户,因而不用关心人物、权限办理,而要重视用户的体会,需求在交互规划上投入很大精力。除此之外,在付费决策、运用场景、专业度的等待值、安全等方面都有不同:

  • 付费决策人不同,C 端产品的运用者和决策者基本重合,而 SaaS 产品的决策者和运用者绝大部分或许是不同的两波人;
  • SaaS 产品绝大部分在作业场景,而 C 端产品大部分在日子或文娱场景;
  • SaaS 产品重视功用 > 体会,需求能协助他处理作业场景里边的问题,体会反而是其次;
  • SaaS 客户花了钱,对安稳性要求会更高,关于问题的容忍度会变低,乃至有些要求会写到合同中去,当呈现可用性问题时会有补偿的状况;
  • SaaS 客户关于专业服务的等待值不同,他们关于问题期望是有更专业的人员和更专业的方法来处理,如包含专业的服务,专业的产品,专业的流程,专业的人员,专业的交给,专业的客情保护和沟通话术;
  • SaaS 客户关于产品安全、数据隐私、阻隔等方面有更高的要求;
  • SaaS 产品交给仅仅整个客户生命周期的起点,中心的增加逻辑在于继续服务的才干;
  • SaaS 客户更看重服务进程中 SaaS 企业的专业体现。

1.2 阻隔性

以阻隔性为例,企业级 SaaS 产品关于阻隔性的要求也纷歧样,咱们看一下 AWS 关于阻隔性有更细致的要求,总结起来有如下 3 点:

  1. 阻隔不是可选项,是产品的基本要素,体系需求确保有处理方案来供给阻隔性;
  2. 身份验证和权限办理不等于阻隔,它仅仅阻隔的一个环节,在这个环节后边需求构建关于开发人员视野之外的阻隔战略,并作为默许项;
  3. 阻隔不等于要求彻底的物理阻隔,能够基于同享资源模型的多租户逻辑,关于有特殊要求的能够供给物理资源级别的阻隔。

考虑一下,为什么会有阻隔性的需求

SaaS 服务往往会服务于多家企业,企业与企业之间的数据需求彻底阻隔,不同的企业其量级,需求各有差别,当一家企业运用出问题时不能影响别的一家企业,比方某个企业触发了一个 BUG,这个 BUG 不能影响别的企业的运用,或许一家企业的数据量特别大,不能由于家企业的数据核算影响别家企业的核算,特别是有一些离线核算逻辑的时分。咱们在运用云服务的时分也会遇到宿主机超卖的问题,这其实也是一种阻隔性做得不到位的状况。

以上这些是咱们了解到的一些关于 SaaS 企业的界说和特性。

做产品安稳性的建设和咱们平时做一个需求相同,先要搞清楚需求方是谁,需求的价值是什么。

企业级 SaaS 的安稳性需求来自于哪里,是职业,政府,仍是客户,仍是公司要求?

比方金融职业,有一些事务模块关于安稳性的要求来自于政府,是不能打折扣的,做不好,或许会影响公司生死。
又比方在内容相关的职业,假如关于一些涉政、涉黄等内容没能操控住,任其众多,或许会导致产品的下架,这儿的要求相同来自于职业和政府。

回到咱们企业级 SaaS 产品的安稳性,这个需求来自于购买了咱们服务的客户,SaaS 产品处理的是作业中的问题,是生产资料的一种,当生产资料不可用的时分会对其作业产生损坏,比方依赖于某个数据剖析体系的结论,可是数据剖析不能用了,老板要求的陈述就出不来,此时又不或许重新拉数据剖析,只能等,这样或许就会影响用户第二天的的汇报作业等等,后果或许是丢了客户,乃至丢了作业。假如咱们长时刻不安稳,安稳性也将会影响公司的生死。

相关于 C 端用户的数据,SaaS 的数据显得尤为重要,其作为企业财物的一部分,具有有形的价值,乃至是企业的中心财物,比方做代码办理的 SaaS 服务,关于一家软件公司来说,代码便是其中心的财物,假如由于 SaaS 服务数据丢失,或许走漏,关于企业来说将会是影响企业生死的大事端。

2. 产品安稳性

前面更多的是聊需求和需求价值,接下来咱们聊一下产品安稳性详细是指什么,以及怎么做好产品安稳性。

产品安稳性包含三个方面:产品功用的安稳性、数据的安稳性和体系服务的安稳性。

2.1 产品功用的安稳性

产品功用的安稳功用够从功用的上线、改变和下线三个方面来看。无论怎样,咱们在做产品功用的改变时都是以削减打扰用户为前提。

2.1.1 产品功用的上线

产品功用的上线,在上线每个功用的时分都要稳重,想不清楚宁可不做,在咱们习惯了互联网的敏捷形式后,快速迭代,快速试错成为咱们惯例的作业方法,可是关于 SaaS 产品来说,敏捷不再是最重要的点。

关于咱们的客户来说,更重要的是处理一个场景的问题,或许说处理他们作业中的问题,能提升功率。
在咱们上线一个产品功用的时分应该能讲出用户故事。

当有某个产品功用能够处理用户问题后,就不要经易改变其逻辑,由于用户现已或许将这个产品功用做到了作业的 SOP 里边。

2.1.2 产品功用的改变

产品功用的改变包含产品的版别规划、功用发布改变。

关于产品功用的规划或版别办理,需求有特定的节奏,让用户习惯你的节奏。
关于每个版别,做好了,做稳了,把版别发布前前后后的工作做扎实了再渐渐发布出去,给客户一个承受的进程,一个较轻的落地。而且能让客户能快速找到改变了什么,给客户安全感,如 Saleforce 有一个发布阐明(R)help.salesforce.com/s/articleVi…

有节奏的发版,比方 Canvas LMS(一个学习办理渠道) 是每个月的每三个星期六正式发版(Release),每周的周三灰度布置(Deploy),用户可挑选性预览运用灰度布置的功用 canvas release

又如 Salesforce 一年就三个版别,命名为 Spring, Summer,Winter spring-22-release 这儿不仅仅是发版,发版仅仅技能层面的逻辑,这儿的更多的是产品的逻辑,需求左移。

2.1.3 产品功用的下线

产品功用下线,在下线的时分要考虑到怎么承受这部分用户的需求,尽量能有替代方案来承受。

改变办理没有银弹,咱们能做的是操控节奏,以 SaaS 的逻辑来操控改变办理,这儿的办理除了代码的发布,还有线上环境的改变,线上装备的改变等等,强调一点**:在用户的运用期间,不要动任何线上的东西,包含代码,装备,环境等,全部以不影响用户作业为前提。**

当产品功用改变,或许进行大版别晋级时充分考虑用户的操作习惯以及学习本钱,或许你面临的用户在电脑上学会一个操作是很难的一件工作,乃至需求有人专门来训练。每一次的产品改变就需求其训练负责的同学从头来训练一遍。

就算用户量少,也要进行灰度,削减影响范围

2.2 数据的安稳性

数据的安稳性是企业级 SaaS 产品特别重要的一点,只要确保客户数据的安全性才干持久供给服务,其主要包含以下 4 点:

  • 数据不会乱,主要是指当用户习惯了一些数据的逻辑后,不要轻易的打乱,如一些默许排序规矩,一些分类逻辑之类的;
  • 数据不会丢,数据备份,长时刻存储,关于上传的文件,在满意本钱要求的基础上,尽或许的存下来,假如实在不能存了,也放一个当地,给用户一个出口能够便利获取得到;
  • 数据不会走漏,这块是数据安全的范围,比较常见的问题是不同的租户数据串了,或许不同的用户数据串了,这儿原因或许是代码问题或许架构问题。还有更严重如咱们在网上常常看到的被拖库,如前段时刻上海的数据走漏
  • 数据可追溯,关于用户的操作,有详细的日志,知道数据从哪来的,要到哪去的,当出了问题能够追溯。

2.3 体系服务的安稳性

体系的安稳性包含体系的可用性和功用安稳:

2.3.1 体系的可用性

体系的可用性指在一个给定的时刻间隔内,关于产品体系来说,总的可用时刻所占的比例。咱们一般用 SLA(Service-level Agreement) 约束和描述可用性,其常用方针如下:

  • MTBF:Mean Time Between Failure,均匀毛病间隔时刻
  • MTTR:Mean Time To Repair,均匀恢复前时刻
  • MTTF:Mean Time To Failure,修正前均匀时刻

关于可用性,所要做的工作太多,简略几个字,可用性办理就包含了度量、线上管控、架构办理和研发办理等等。

在互联网职业有个关于线上事端 「 1-5-10 」的准则,即 1 分钟发现,5 分钟定位,10 分钟恢复,假如能做到这个程度,算是及格了。而且这仅仅针对可用性线上事端处理 SOP 中的一个逻辑,咱们要做的工作还有很多。

落到惯例建设中,监控、压测和演练,三个常常要做的操作,可是实际上咱们仅仅重视了监控的一部分及压测的一部分。

关于体系可用性咱们能够做如下一些要害的步骤:

  • 测试并盯梢当时的可用性: 先有度量,确诊咱们可用性的状态;
  • 将手动流程自动化,自动化布置进程:信任代码比人更靠谱,特别是针对重复性事务;
  • 保护和盯梢办理体系中的一切装备:一切和线上相关的都是线上环境,而线上装备的改变往往是高危危险地带;
  • 构建线上问题的快速恢复才干:包含但不限于灰度发布、A/B 试验环境,答应快速更改并进行试验,而且确保假如呈现了问题能够轻松回滚;
  • 将线上问题和体系可用性作为技能团队的中心绩效方针:办理逻辑中有一个中心点你考核什么,大伙儿就会注重什么,人多数是趋利的;
  • 以不断改善应用程序和体系为方针:反软弱、不能由于怕改变带来的危险而中止改善;
  • 服务分级,拟定严格的 on-call 机制,关于中心服务需求在分钟级响应并处理。

2.3.2 体系的功用安稳

体系的功用安稳指在满意用户功用可用的基础上,安稳功用,一起在必定程度上协助可用性的建设。

安稳性和可用性比较,除了重视体系能够无毛病地继续运行时刻,毛病产生的频率,还会重视功用劣化趋势等等。安稳性更重视体系在给定条件下的响应是否一致,行为是否安稳。安稳是对可用性的进一步的要求。

上面聊完了企业级 SaaS 产品和产品安稳性,接下来咱们聊聊怎么持久的做安稳性的办理,如董宇辉教师在直播间谈到初恋时说的:「你不就图我吗?更持久的图我吗?我懂」,关于安稳性咱们也是想持久的图。而且仍是用科学的方法体系来图。

3 基于危险模型的安稳性办理

考虑到安稳性办理是一个长时刻的工作,且是需求继续迭代的,假如仅仅靠人来推动,当人员变动或许作业重点改变时,或许安稳性相关的工作就会陷入阻滞状态。

此时咱们能够把一切的安稳性问题笼统出来,构成危险,咱们经过体系性的继续的辨认危险,并拟定对应的危险缓解方案和应对方案,应该是能够较好的操控整个体系的安稳性状况。

办理危险的第一步是辨认并了解体系中已有的危险。
辨认、符号并对已知的危险摆放优先级,这便是危险模型所要做的工作。

尽管咱们总是想消除危险,可是这样做的本钱通常是无法承受的,无论是从实际本钱仍是从时机本钱的视点来看都是如此。咱们必定有更重要、愈加需求以客户为中心的工作要做,这些工作对咱们的客户、公司来说都有优点,而不是从应用程序中消除你所知道的每一个危险。

办理危险触及对每个危险评价两个值:危险的或许性和危险的严重性。一般来说,严重性是危险产生时的本钱,而或许性是危险产生的概率。一个不太或许产生可是会对应用程序构成非常严重影响的危险,不必定是你想要消除的危险。相同,一个很或许产生可是对应用程序影响很小的危险,也不必定是你想要优先消除的危险。可是,一个很或许会产生而且会导致严重影响的问题,是你需求优先处理的危险。

3.1 危险办理

在聊危险模型之前,咱们先聊一下危险办理。

危险办理(Risk Management)是指怎么在项目或许企业一个必定有危险的环境里把危险减至最低的办理进程。危险办理是指经过对危险的知道、衡量和剖析,挑选最有用的方法,主动地、有目的地、有方案地处理危险,以最小本钱争夺获得最大安全确保的办理方法。

从体系开发的视点看,危险办理包含体系中的危险的方位,确认哪些危险有必要消除,哪些危险能够暂时存在,以及怎么下降这些留存危险产生的或许性和重要性。

危险主要由或许性和严重性两方面组成:

  • 严重性:假如危险产生,所需支付的代价
  • 或许性:危险产生的概率

办理危险便是要办理这两个方面。

3.2 危险模型

危险模型是危险办理的第一步:了解体系中已有的危险,辨认、符号并对已知的危险摆放优先级,终究构成一张包含了体系一切已知危险的当时状态的表格。这便是咱们所说的危险模型。

建立危险模型的进程是辨认危险的进程,在这个进程中咱们需求辨认出体系中已有的危险,并对其进行剖析,符号出优先级、整理当时状态和前史状况。

危险模型构建进程中需求考虑模型的作用范围,是公司级的,团队级的,项目组的,仍是服务级的。

关于一个小公司,能够是公司级的,关于大型一些的公司,能够考虑团队或项目级的。

危险模型至少包含以下一些方面:

  • 严重性/或许性:高中低,先评价严重性,再评价或许性
  • 危险平缓方案:能够运用的或许正在运用的用来下降该危险严重性或许或许性的危险平缓办法。
  • 监控:对该危险的产生是否进行了监控,假如监控了阐明监控的方针,假如没有监控,阐明原因,以及达到监控方针的原因,终究一切的危险应该是要监控起来的。
  • 状态:活泼 / 已平缓 / 正在修正 / 已处理
  • 前史危险状况:该危险在前史上有没有产生过,什么时分,产生频率等
  • 危险平缓方案:当咱们拟定危险平缓方案的时分,需求从严重性最高的项开端,平缓危险不是为了消除,而是为了下降危险的严重性和或许性。并不是每一个危险都要制订危险平缓方案。
  • 危险预案:当危险产生的时分,咱们能够采纳的办法

除此之外,还包含一些惯例的增加时刻,ID,负责人之类的

3.3 辨认危险

咱们参照如上危险模型的项,经过脑筋风暴等方法构建整个危险模型,在进程中能够考虑从如下的一些点中提取危险点:

  • 已知的毛病
  • 有呈现的告警
  • 用户支持的反馈
  • 或许存在的功用问题,或许一些慢 SQL 等
  • 服务间的强弱依赖
  • 一些功用的缺失
  • 服务单点
  • 内部和外部/离线和在线事务的相互影响
  • 服务容量的缺乏
  • 基建发布或扩容等发布操作会影响事务的状况
  • 线上装备/环境/网络等的改变
  • 安全问题
  • 体系或流程的问题,如没有文档,没有沉积,只在某些人的脑袋里边
  • 一些已知的,明确的技能债款

基于上面的逻辑,咱们整理后能够得到一个危险列表,咱们称之为危险模型。

3.4 危险平缓方案

危险模型中的危险平缓方案用来阐明能够进行或许正在进行哪些危险平缓办法,来下降当时危险的严重性、或许性。这儿咱们不需求彻底消除危险,仅仅下降危险产生的或许性和严重性。

常见的危险平缓方案,咱们一些常见的降级战略归于危险平缓方案的主要部分,包含但不限于:

  • 前端降级:应对后端服务不可用或后端服务反常等危险;
  • 缓存降级:应对存储不可用或下流服务不可用等危险;
  • 主备切换:应对主存储不可用等危险;
  • 事务阻隔:应对多事务接入时,单个事务引起的全体服务不可用的危险;
  • 应用限流:应对多事务接入时,单个事务引起的全体服务不可用的危险;
  • 全体限流:应对大流量突发的危险,保障部分用户可用;
  • 容量评价及提前扩容:应对大流量突发的危险,保障必定程度流量下的事务安稳性;
  • 全链路压测:应对全体链接容量纷歧致的危险,防止单点容量危险;
  • 线上问题及用户反馈整理:应对体系中小的危险引起的大危险,如一些体系 BUG,一些没有测出来的问题等等;
  • 线上告警及时处理:应对体系中小的危险引起的大危险,如一些体系 BUG;
  • 扩缩容演练:应对容量冲击时基建没有预备好的危险;
  • 定期压测及容量评价:应对体系演化进程中,代码改变,模块改变导致的容量改变;
  • 功用优化:应对体系中某些服务的功用问题导致的危险;

以上的一些战略仅仅平缓了部分危险,像容量的危险,BUG 的危险,不可用的危险不或许彻底消除,只能平缓,以下降危险产生的或许性,或许下降危险产生时的严重性。

基于以上的一些思路,咱们需求做一些专项和一些机制来确保危险可控。

但危险之所以为危险,是阐明他仍是有或许产生的,当产生时咱们需求做什么呢,这便是咱们接下来要预备的预案。

当危险产生时,咱们方案怎么来处理,这个方案是咱们有预先规划的,是一个体系性的方案。

比方,当容量突发时,开启降级战略或许限流战略等等。

3.5 定期危险回忆,保护危险模型

危险模型是安稳性办理进程的抓手,经过不断的辨认危险,消除危险,平缓危险,不断提高安稳性变好的或许,以终究达到安稳性的方针。

危险评价和应对规划是一个反复重复的进程,不断的迭代危险模型,辨认出新的危险。

当危险模型构建完成后,咱们需求定期逐一危险拉出来 review 一次,咱们能够问咱们自己如下的一些问题:

  • 与前次回忆比较,危险有更严重吗?或许性有更高吗?
  • 接下来会排专人来处理某些危险吗?是否应该组织?
  • 前次回忆组织的事项执行了,对应的危险状况怎么,是否有更新到危险模型中?

问完问题,咱们或许需求有一些实际的举动:

  • 评价是否有新的危险;
  • 删去旧的危险:假如危险现已处理了,能够归档;
  • 评价原有危险模型中的每一项危险,评价其严重性和或许性,假如有变动,对其进行更新;
  • 关于不同的优先级的危险区别对待。

以上的回忆操作咱们主张以某个办理体系来承载,而且这个办理体系是带有通知等功用,以更好的将危险相关的信息周知出去,如 Jira 体系。

写在最终

记得当年「我是歌王」有一段汪涵救场的掌管,从一个观众的视点看,真的牛逼,简直是教科书式,这算是一个超大的线上事端,可是这和咱们的安稳性有什么关系呢,咱们有如下的考虑点:

  1. 为什么会有这个事端产生 – 问原因
  2. 在流程和机制上是否有改善的空间来躲避 – 怎么体系性的躲避
  3. 这个事端有没有其它更滑润的处理方案,削减对用户的影响 – 怎么削减影响
  4. 咱们是否需求英豪 – 线上不该该有英豪

如同扁鹊的大哥相同:「长兄于病视神,未有形而除之,故名不出于家」

最终有一些准则能够辅导咱们安稳性的作业:

  1. 以用户为中心,不打扰,不影响
  2. 灰度,产品灰度,发布灰度,坚持住
  3. 防微杜渐,敬畏线上
  4. 快速发现,快速处理,削减关于用户的影响

重复一句:咱们所做的全部都是以削减对客户的打扰为前提。

在咱们一切的事项中并没有写与组织结构、人才队伍相关的内容,并不是这些不需求,恰恰相反,他们至关重要。下次有时机咱们再聊。

最终,祝大家新年快乐~