系统稳定性方法论 - 序

业务发展是树
系统稳定是根
既要想上发展
也要向下扎根

系统稳定性的重要程度不言而喻,特别是在后互联网寡头平台化时代,任何微小的系统稳定性故障都有可能造成巨大损失。

就拿我所在的出行行业的公司举例,重要的节假日简直成了各位RD的噩梦,五一、国庆节、年三十,虽然节前都会大搞特搞稳定性专项,但总是遵循墨菲定律,bad things always happen… 且每次的故障、再加上竞对推波助澜,都会对公司造成巨大的负面评论,同时也在打击着RD的自信心…

作为一名RD,虽然我不是稳定性这方面的专家,但在平日的工作中也沉淀出了自己的一套方法论,希望大家多多指点!

系统稳定性

很难给系统稳定性下个准确的定义,但我们平时说的最多便是可用性,那么可用性如何评价?最直观的评价方式便是几个9

通俗叫法 可用性级别 全年不可用时长(速记)
基本可用 2个9 99% ≈ \approx 88小时
较高可用 3个9 99.9% ≈ \approx 8.8小时
高可用 4个9 99.99% ≈ \approx 53分钟
极高可用 5个9 99.999% ≈ \approx 5分钟 (简直)

一般大家都是在保证3个9的情况下,追求4个9

如何提高系统稳定系

提高全员稳定性意识

在谈任何其他抓手之前,我认为最重要的是 提高全员稳定性意识,稳定性绝不仅仅只是RD的工作… 在内卷情况越来越严重的当下,负责稳定性的同事最容易被冷落,稳定性的工作在哪儿都是烫手的山芋,所有人都对在追求业务增长而选择性的忽略稳定性;但稳定性是所有业务的根基,稳定性与业务发展同样重要,一荣俱荣一损俱损;

要想改变这种现状,上至CTO下至RD,需要设置共背OKR,让全员参与稳定性建设!

举个稳定性方向的OKR例子

目标 - O 关键指标 - KR
日订单峰值1kw的情况下,保证系统核心链路稳定、无重大线上事故、能够及时感知、定位、解决事故 系统可用性99.99%
无P3以上重大事故
5分钟内感知线上事故,30分钟内止损

稳定性建设4大抓手

降发生

从开发阶段开始,到最后的代码上线,这整个过程中,对各个阶段进行质量把控,将所有异常排除在发生之前

提感知

故障在所难免,所以一定要做到,一旦发生故障,能够及时且精准的告警!

快响应

在接到异常告警之后,能够快速响应、快速定位、快速止损,不要总想着这是谁的锅、如何解决问题,一定要先止损

做复盘

解决了故障,也一定要复盘,为了避免以后再次出现此类事故

下面,我就深入这四个方向,谈谈如何做稳定性建设。

你可能感兴趣的:(方法论,Java,架构,设计模式,稳定性,架构,方法论)