俗话说“小洞不补，大洞吃苦”，也许你辛辛苦苦把老项目们都照顾得妥妥贴贴，但新项目有可能引入新隐患，一着不慎，满盘皆输，所以对新项目、新团队、新公司要做好清单管理。下面这个可靠性成熟度评估模型就是一个很好的工具。

一.前言

十年来，历经窝窝、云纵、禧云，从五城到一百五十城再到29省自治区直辖市，从日活十万订单到一千万笔交易，与此同时我们也经历过服务雪崩和黑客入侵，不止一次经历过机房长时间不可用和基础性网络服务全国停摆，深知技术保障如履薄冰。服务的不稳定对业务有致命打击，一线战士辛辛苦苦谈下来的商家，服务稍一波动就可能彻底丢失了。

图1-1 我们提供高可靠性高并发技术保障，可覆盖各种IoT场景与千万级交易

大型互联网公司一般会设置一个专门的SRE（Site Reliability Engineering）小组，由于常年横向支撑多公司、多项目，所以小组成员对稳定性保障问题域有深入理解，对稳定性保障重要性有深刻认识，对线上问题的类型、解决实践有更为全面的理解和思考，有能力形成最佳实践的理论、工具或服务，为业务产品研发团队提供理论和工具的支持，并进一步在此基础上将稳定性保障解决方案产品化。

稳定性保障有什么理论和工具呢？我举一个例子，阿里巴巴内部有一个“安全生产三板斧”的概念：

可灰度：应用在发布的过程中，运维平台一定要有发布策略，包括单批、分批、金丝雀等发布策略；同时还要支持流量的灰度；批次间也要允许自动/手动任选。可观测：发布过程可监控，白屏化实时查看发布的日志和结果，及时定位问题。可回滚：允许人工介入控制发布流程（异常中止、一键回滚）。

我们会发现这三板斧里既有流程规范，也有工具（灰度发布和可视化监控大屏）。

我们就是做SRE抓总的，有责任对生产环境的工程项目（无论是Java还是其他开发语言，主要是后端工程）做可靠性评估和评级。根据评估结果做清单管理，进一步要求业务技术团队有的放矢地整改，避免新团队带入新隐患。

下面我讲解项目可靠性成熟度评估模型如何使用。

二 量化分级篇

首先，项目可靠性成熟度评估的英文为：

Project Reliability Maturity Assessment Model，缩写为PRMM，代号PR妹妹～

其次，PRMM把项目管理能力成熟度划分为四个等级，自低向高依次为初始级、受管理级、稳健级、量化管理级，不同等级代表一个企业或一个产研团队的应用服务稳定性和可靠性的成熟度水平不同。

四级（即最高级）：量化管理级项目可靠性能够进行量化分析和监控三级：稳健级项目实际运行的可靠性已经被当作实现BU（Business Unit，业务单元）绩效的重要组成部分，而不仅仅是上线就万事大吉，在各个层面都有标准化措施、流程和工具促进项目可靠性的规范二级：受管理级BU已经意识到项目可靠性的重要性，根据策略要求做了初步的管理一级：初始级项目可靠性主要是靠人员责任心保证，没有统一的管理流程规范和工具保障，主要是被动式的管理

最后，评估流程主要分为三个阶段：

1.差距分析：按照模型对项目做差距分析；

2.能力提升：与业务产研团队共建项目可靠性管理小组，做好培训，建立规范，提供工具，完善制度，尤其是针对评级低的项目要求尽快整改，整改之后才能上线，确保生产环境不出现薄弱环节；

3.重新评估：根据整改结果不断修正可靠性成熟度等级，早日提高到最高的量化管理级。

三 评估指标篇

PRMM定义了网络、系统、业务应用、代码发布、业务安全、运维资源管理、数据库资源管理和帐号资源管理八个能力域以及31个评估指标，并以系统架构，安全生产，业务安全，资源管理作为四个核心域评价维度。

3.1 系统架构核心域

系统架构维度下评估指标与能力域对照关系为：

下面逐一做简要解释和案例说明。

3.1.1网络能力域

评估项有点像尽职调查的问题清单，被调查者可以用“有”还是“无”来回答。如果回答“有”，则需一并提供资料证明。

PA01 网络拓扑图

请提供网络拓扑图。我们将从网络架构上评估当前架构是否有优化空间，从网络冗余、安全性上展开评估。

PA02 网络入口是否有安全限制规则

如果有端口访问的安全限制，请提供安全策略。

如果有防火墙就提供防火墙策略，如果是阿里云的网络防火墙或者安全组等，提供对应的规则即可。

以禧云信息为例：

1.只开放必要端口如80和443所有人访问；

2.部分需开放端口通过白名单控制。

PA03 网络是否有监控系统

云计算时代一般都有监控系统，请列出针对网络的监控项、告警阈值和告警方式。我们将从监控的可观测角度看监控是否缺失，以及是否有优化空间。

PA04 是否有使用网络防护安全产品

如果有，请简要说明各项安全产品的安全策略。

进一步说明：

1.网络安全防火墙（ids+ips）

2.Web应用防护墙（Web Application Firewall，简称WAF）

3.高防（DDoS防护）

3.1.2系统能力域

PA05 系统架构图

请提供系统架构图。我们将从系统的角度来确认当前系统架构是否还有优化空间，比如考察这些维度：

1.当前系统是否有一定的自愈能力。

2.是否具备机房级别容灾能力，如主备机房、多活机房等。

3.检验系统架构是否存在单点故障。

以禧云信息智慧中学项目为例进行说明：

图3-3 智慧中学交易场景的系统架构图

如上图所示，环境中有四个机房：主机房，从机房，数据机房，应急机房。

餐饮门店的客户通过智能设备发起点餐或收单请求，第一次请求将默认访问基础域名，而基础域名指向主机房，所以请求将进入主机房。主机房会判定客户真正的业务归属机房以及对应的分片，将对应的动态域名下发给智能设备。智能设备以后的请求都将访问动态域名，请求会直接进入对应的机房以及分片。业务应用都运行在分片的容器集群上。

客户的业务归属机房和分片，可以通过控制台动态调整。调整后，可以快速通知到智能设备，从而做到秒级切换客户流量。

主机房与从机房的多活数据（包括数据库数据和Redis缓存数据）保持实时双向同步。主机房和从机房的业务数据变化都会分发到数据机房（即数据湖），所有大数据计算都在数据机房完成。这样，我们天然地做到了数据多地实时备份。如果主机房和从机房都相继不可用，则客户还可以让用户用手机App扫应急收银码，交易请求将在应急机房完成，这是最后的底牌。

所以，本系统依托于容器化部署，拥有一定程度的自愈能力；依托于异地双活系统，拥有机房级别的容灾能力；系统各个角色包括数据湖，都是集群化部署，没有单点故障。

PA06 不同系统之间是否具备网络物理隔离的能力

如果有，请简要说明当前的物理隔离策略。

进一步说明：

1.当某些系统出现异常后，可能会对其他系统造成影响，建议隔离。

以禧云信息售卖机项目为例，它与智慧中学业务做了以下网络隔离：

a) 出口隔离，创建不同的交换机，增加新出口IP，将新交换机映射到其他出口；

b) 本业务和原业务，不共用入口SLB；

c) 使用不同的安全组，进行网络隔离，将两个业务物理隔开。

PA07 目前使用的虚拟化技术

请提供当前使用的虚拟化技术，并且提供当前虚拟化技术使用的管理平台都实现了哪些功能。

进一步说明：

1.建议使用容器化技术，管理会更灵活，并且有一定的自愈能力。

2.如已使用了容器化技术，需一个管理平台对整体的应用进行编排管理。

以禧云信息为例：

2014年9月，我们开始调研Docker容器技术，评估各种落地方案的可行性。2015年5月，基于Mesos+Marathon的容器云平台测试环境上线，搭载自研的TouchStone容器管理和监控平台。2018年1月，镜像仓库更换为Harbor。2019年8月，随着k8s的越来越大行其道，我们启动k8s架构调研。2020年1月，TouchStone适配了k8s，能够同时管理k8s和Mesos两种集群。2020年1月，k8s架构上线，实现双架构集群无缝对接迁移。注意，我们自行搭建k8s集群，并未使用阿里云的k8s服务。

PA08 应急预案及演练

请提供当机房发生重大事故的应急预案。

进一步说明：

1.是否编制有应急预案，并定期执行演练。

2.是否有平台或工具可以快速切换到灾备机房。

以云纵的异地双活切换流量演练为例：

提前写好双活切换的各种预案，事先准备好验证切换成功所需要的数据，如验证交易成功与否的门店ID和收款二维码，不能临时抱佛脚。所有业务线的双活管理入口、域名切换入口，运维和技术负责人都要提前准备好，不要临时在群里问。每隔一段时间就要认真做一次演练。一定要保证双机房都有测试商户，而不是临时找测试商户。日常就要做到双机房商户流量七三开或六四开，确保真的是双活，而不是主备。

所以云纵的质量控制部就编制了一份《多活平台切机房演练操作手册》，定义了两个演练场景：

1.模拟阿里云华北机房宕机，机房流量切到阿里云华东机房。

2.华北机房恢复正常，部分流量迁回华北机房。

PA09 系统变更管理

请提供业务系统数据和配置的变更流程。

进一步说明：

1.变更操作是否经过审核后进行变更。

2.是否有工具记录变更过程，并且可以快速回滚。

3.变更操作是否有记录，可回溯历史。

以禧云信息为例：

我们有工具和流程双重保障。这其中的工具，指的是数据库自动化运维平台（内部代号iDB）、运维自动化平台（内部代号SimpleWay）和多机房Redis集群运维自动化管理平台（内部代号Discache），这也是大型互联网公司所重点关注的IT基础设施。它们可以做到两点：第一，确保生产环境的变更操作，有审核记录，有操作记录，能回滚，第二，用户岗位职责与系统用户权限相符合，责权利对称。

图3-4 iDB里的DDL变更管理

如上图所示，iDB的变更管理可以做到：

•帐号权限控制：业务工程操作数据库的帐号在iDB里申请和分配。写帐号只有insert、delete、update和select权限，无alter、drop和truncate等DDL权限。读帐号只有select权限。

•帐号密码控制：研发人员只是在 iDB 里为应用访问某个环境里的数据源申请工程帐号而已，部署和上线发布对他来说是透明的，工程的配置文件里密文密码是我们自研的另一个研发协作平台（内部代号CloudEngine）在构建应用镜像的时候自动完成填充的。

•数据查询权限：研发人员只允许通过iDB查询线上数据，并保留登录和查询记录。

•数据订正权限：研发人员只允许通过iDB提交DML语句，验证语法正确性、是否使用索引、分表操作是否包含路由字段和单条影响行数等规则，在DBA审核后生成备份并执行，误操作可回滚。

•表结构修改权限：研发人员只允许通过iDB提交DDL语句，验证语法后经DBA审核后执行。这种DDL操作也支持回滚。

图3-5 Discache里的数据变更管理

如上图所示，Discache的变更管理可以做到：

•手动变更KV有审核：通过选定相应项目的相应机房的Redis实例，研发人员只允许通过Discache提交数据变更命令，由SA审核通过后，由系统执行，并支持回滚。

•内存变更有审核：还可以通过Discache变更Redis实例的内存配置。

PA10 数据备份管理

请提供业务数据库和核心业务日志的备份策略。

进一步说明：

1.数据备份策略

2.数据是否有异地备份

3.是否定期进行备份的有效性验证及恢复测试

以禧云信息为例：

我们设定通过脚本自动备份，将备份相关信息记录到iDB系统中，每周会做备份的可恢复性自动检查。

位于IDC机房的自建数据库集群的备份机制是，通过脚本自动备份，将备份相关信息记录到iDB系统中，每周会做备份的可恢复性自动检查。

阿里云的数据备份，则使用阿里云自带的“备份恢复”功能。

PA11 系统监控

请提供系统架构图中涉及到的每个应用服务的（资源和服务）监控项及告警阈值。

进一步说明：

1.资源监控的监控项以及阈值（CPU、内存等）

2.服务的监控项以及阈值（服务状态等）

3.是否有告警通知方式（邮件+短信+钉钉或微信）

4.核心告警是否有语音通知

5.告警系统是否配置可视化监控大屏

6.核心系统是否通过人工或工具定期巡检，并且生成IT资源报告

7.定期是否会对核心业务数据库进行性能巡检，找出问题进行优化

8.系统使用的SSL证书，是否有过期监控，并且通过工具在到期前自动替换

3.1.3业务应用能力域

PA12 应用是否支持多节点部署

从冗余度出发，应用要坚决避免单点。

PA13 应用是否有开发规范文档

请提供开发规范系列文档。

进一步说明：

1.代码开发规范

2.日志路径统一

3.应用端口分配流程规范

4.应用是否都配置了健康检查地址

5.内部各应用间的调用是否是通过内网域名调用

以禧云信息为例：

内部有《Java编码规范》，同时技术团队也遵循阿里巴巴Java开发手册（华山版）。

我们的应用写日志，都是统一的文件路径：

<fileNamePattern>/data/application/logs/工程名字/service/common-service.log.%d{yyyyMMdd}</fileNamePattern>

日志内容也遵循统一的JSON格式，便于ELK等各种日志工具解析。

应用端口分配通过我们自研的研发协作平台（内部代号CloudEngine）做申请和登记，如下图所示。

图3-6 CloudEngine里的端口申请

应用服务都配置有健康检查地址。

应用服务之间的调用包括访问数据库和Redis，都走内网域名。

PA14 应用是否有监控

如果有，请提供当前监控规则以及策略。

进一步说明：

1.业务日志是否搜集到统一平台，便于研发排查问题

2.是否通过工具定期汇总业务异常日志并进行告警

3.是否有应用健康状态监测等

4.是否配置了核心业务指标的监控告警，如交易笔数、通道支付成功率等

PA15 业务保障

如果有业务保障平台，请提供业务保障的功能。

进一步说明：

1.业务数据是否可视化，通过平台可以看到当前业务的运行情况

2.当业务系统出现异常，是否有平台可以对业务进行降级、熔断和限流，保障核心业务的基本可用性

3.核心业务应用是否接入全链路监控，通过全链路平台快速定位问题

以禧云信息为例，建设了一个业务保障平台：

•多场景多维度实时监控大盘

•可视化数据

•业务健康度分析

•端到端全链路追踪

它可以让我们从宏观到微观的秒级监控下钻。

案例一，单一维度下钻

其实多数时候人们只想关注某一维度的分布情况，比如按应用、按工程、按机房、按请求URI、按商户、按门店、按设备等看分布。

案例二，网络质量监察

我司的客户分布在大江南北，如何快速定位出哪些食堂网络环境糟糕呢？不能等客户告诉我们。我们可以从请求量级筛选（系统推荐和自定义）、dns/http/ssl/tcp/mqtt耗时情况、趋势发展等诸多因子中分析出餐饮中心网络情况，哪怕是学校食堂的一次网络抖动，都可以被我们侦测到。不仅能分析出网络问题，而且还能下钻到请求链路上的任何阶段，比如是DNS、TCP、SSL、首包响应时长等，并分析出受影响的终端设备。

PA16 应用弹性扩缩容

请提供应用扩容缩容的方案。

进一步说明：

1.是否可以通过平台快速地对应用进行扩容或缩容？

以禧云信息为例，有两个地方可以做扩缩容，一个是在TouchStone里调整容器实例数量，另一个是异地双活控制台上在迁移机房流量的时候一键扩容，如下图所示。

图3-7 异地双活控制台里的扩容

PA17 代码管理

请提供当前代码管理方案。

进一步说明：

1.代码是否有备份

2.是否有扫描工具防止公司代码上传到公共代码库（例如github）

以禧云信息为例，首先gitlab代码库做了三地备份，其次，有脚本根据关键词列表定期扫描github等代码托管平台，并做内部通报和追责。

3.2安全生产核心域

安全生产维度下评估指标与能力域对照关系为：

下面逐一做简要解释和案例说明。

3.2.1代码发布能力域

PA18 代码发布流程

如果有流程规范，请提供。

进一步说明：

1.请简要描述代码部署从打包到部署的整个流程

2.部署代码的流程规范（代码发布时间、回滚策略等）

3.是否有重大节假日封机房机制

以禧云信息为例，研发人员通过CloudEngine向SimpleWay提交上线工单，SA或QA在SimpleWay里审核确认工单并在相应的机房执行发布动作和回滚动作。持续集成和持续发布的整个流程都封装在系统里了。禧云信息的质量控制部总监会在重大节假日之前提前一周时间宣布封版封机房，不再允许生产环境发生变更。

PA19 灰度发布

代码发布到生产环境全量部署之前，是否可以进行灰度发布？

以禧云信息为例：

软件发布：SimpleWay里可以做灰度发布，可以按访问IP地址、商户ID等信息导流量到灰度环境

硬件应用发布：通过IoT平台（内部代号太空桥）的应用商店可以做灰度发布，可以限定商户或设备发布

PA20 应用发布的可观测性

代码发布到生产环境后，是否有检测流程？

进一步说明：

1.发布进度/过程日志的观测

2.业务指标曲线的观测

3.是否在核心流程变更之后全员留下来观察各种监控指标半小时

以禧云信息为例：

发布后观察窗口：核心系统发布后，所有参与同学必须一起留下来观察至少半小时，有相应的各种数据大屏，有业务保障平台。测试负责人宣布发布成功，让大家走才能走。

重大变更间隔发布：核心系统重大更新，或者关键组件重大升级，必须错开：第一天升级，第二天观察，第三天再升级，第四天观察。

PA21 CI/CD工具平台

是否有自动化代码发布平台，如果有请提供当前的功能项。

进一步说明：

1.是否包含代码打包编译等

2.是否有发布到灰度环境的功能

3.是否有发布、回滚的功能

4.发布、回滚是否有记录

以禧云信息为例，上述功能都包含在CloudEngine和SimpleWay里。

3.3业务安全核心域

业务安全维度下评估指标与能力域对照关系为：

下面逐一做简要解释和案例说明。

3.3.1业务安全能力域

PA22 所使用的中间件是否有安全策略

如有，请提供安全策略。

进一步说明：

例如ElasticSearch/MongoDB/Redis等常用集群是否有设置密码，且未开通公网访问。很多公司数据泄露就是被黑客组织扫描到了暴露在公网上的Elastic Search和MongoDB。

PA23 研发查询业务数据是否脱敏

业务的敏感数据是否能做到在脱敏后才提供给研发人员查询。

PA24 是否禁止研发人员执行高危命令

如有，请提供相关策略。

进一步说明：

是否有管理工具来禁止研发执行高危命令，例如：

redis的“keys *”。

以禧云信息为例：

Discache阻断：研发人员通过Discache系统对各个机房的Redis实例发起查询，系统会限定查询命令，如禁用“keys *”等。

JumpServer阻断：JumpServer是一款由Python+Django开发的开源跳板机系统，能够为企业提供认证、授权、审计、自动化运维等基本功能。工程师登录JumpServer后，我们在内部屏蔽了一些高危命令，只要有人执行，系统就会强制阻断，而且系统对任何操作都会有审计和历史记录。

PA25 敏感信息是否加密存储

如有，请提供加密策略。

进一步说明：

例如用户密码是否加密存储

以禧云信息为例：

首先，客户密码是互联网常见的一人一盐加密存储方式，其次，凡是有可能被开放访问的用户和客户的敏感信息，如手机号、身份证号、银行卡号、密钥等，在数据库存储和读取的时候会采用 AES-128 对称加解密，降低万一被拖库后的商业风险。

PA26 开源软件定期更新机制流程

如有，请提供更新策略。

进一步说明：

避免老版本的致命BUG。

以禧云信息为例：

1.定期由运维同学发起检查，与研发同学一起确定哪些升级确有必要，升到哪一个版本

2.在线下环境先升级，观察两周时间，经历几个应用更新周期，由测试同学确认本次升级不影响业务

3.再在线上环境升级，注意一个机房一个机房升级，别一次性把双活机房都升级了。升一个，观察一天，经历完整的早中晚交易高峰时段，再升另一个

PA27 密码管理策略

如有，请提供内部员工的密码管理策略。

说明：

1.密码如何分配

2.如何保证密码强度

3.是否能保证一人一密（不同人持有的密码不一样）

3.4资源管理核心域

资源管理维度下评估指标与能力域对照关系为：

下面逐一做简要解释和案例说明。

3.4.1运维资源管理能力域

PA28 基础资源管理

请说明资源申请流程。

进一步说明：

1.资源申请(虚拟机、Redis、数据库等)

2.资源释放流程

我们将运维基础资源的申请和释放流程都融入了CloudEngine、SimpleWay和Discache里。其中Redis实例的申请如下图所示。

图3-8 Discache里申请新增Redis实例

PA29 证书管理

请说明SSL证书管理流程

说明：

1.证书颁发机构是谁（收费/免费）

2.是否有过期监控及自动更新

以云纵和禧云信息为例：

免费的证书是由SA编写的脚本统一管理，会在过期时间剩余28天的时候自动更新；

收费的证书是GeoTrust证书，由阿里云托管，阿里云会自动更新证书，更新后替换到所有关联的服务上。

3.4.2数据库资源管理能力域

PA30 权限管理

请说明数据库管理帐号的管理策略。

说明：

1.是否分组（是否有独立的运维组和dba组）

2.是否有策略可以限制用户删库等高危操作（注意：有管理权限AliyunRDSFullAccess，就可以直接删除库）

3.密码策略是否符合复杂度要求

4.是否有白名单：指的是只允许指定IP和业务工程所在网段访问相应的数据库

以禧云信息为例，均符合以上各点要求。

3.4.3帐号资源管理能力域

PA31 帐号生命周期管理

请说明员工帐号的管理流程。

进一步说明：

离职员工的邮箱、VPN、阿里云帐号、堡垒机、git等系统帐号是否及时清除？

以禧云信息为例：

首先，员工离职办手续的时候，必须经过运维对接人的签字，运维人员就会将离职员工的相应帐号一并删除。其次，我们通过自研平台IDCenter、SimpleWay配搭开源LDAP服务完成了帐号管理，这样工程师在离职的时候，相关VPN帐号、堡垒机帐号、阿里云帐号就会被一揽子删除，再也无法登录生产环境。

本文出自《禧云信息项目可靠性成熟度评估手册》。禧云信息是是中国唯一千万级日活智慧校园运营商，蚂蚁集团、鼎晖、什么值得买为公司战略股东，同时拥有微信、银联、银行等战略合作伙伴，在SaaS产品（支付交易）、校园增值、媒体业务等方面构筑强劲优势，有望成为智慧校园全生态赋能者。

-END-

用好这个PRMM工具，别让老司机被灰犀牛黑公牛一头顶死。