系统稳定性、研发效率、交互体验是前端工程师最需要关注的三件事。系统稳定性建设要从各个维度不同的层面去着手，这会涉及到开发、规范、流程等各个方面。本文重点介绍稳定性指标和团队规范两部分内容。

稳定性指标

系统稳定性是可衡量的，通常我们在做系统稳定性保障方面的工作时，都会先明确稳定性保障的目标，然后针对这个目标进行任务拆解。

可用性

讨论系统的稳定性指标，不可避免的会提到服务等级协议 (Service Level Agreement, SLA)。在 SLA 中会用一年内系统的停机时间来表示可用性和可靠性，也就是我们经常谈论的 “x 个 9”。

不同的系统对可用性的要求是有差异的，大部分系统或服务的可用性会要求达到 “4 个 9” 或 “5 个 9”，对于 “2 个 9” 的系统是不配谈可用性的。那么，系统的可用性的指标是如何确定的呢，通常我们会强调核心服务的稳定性要达到 “x 个 9”，这就涉及到服务的分级。

几年前，美团技术博客发布了一篇《战狼项目：美团点评金融核心交易系统可用性 7 个 9 是这样炼成的》文章，引起了很多人的质疑，因为可用性 “7 个 9” 对应年故障时间只有 3.15 秒，后来这篇文章被修改后重新发布。

故障等级

我们通常提到的核心服务、非核心服务，实质就是服务分级的概念。通常会按服务的重要程度将服务划分为不同的等级，不同等级的服务对系统稳定性的要求是不同的。在事故定级的时候，服务的级别会影响故障等级。下图是一个服务等级与故障等级的示意图图，可能与实际情况会有一些出入。

除此之外，事故的持续时间、用户数量、业务损失、社会舆论等各方面的因素都会影响事故的定级，在这里就不做展开讨论了。稳定性保障的指标，有时会以 KPI 的形式出现，比如要求系统或服务整个季度不能出现 P2 级别以上（包括 P2）事故。

稳定性保障通常会分为事前、事中、事后三个阶段。事前阶段重点在于预防和发现问题，事中阶段主要关注于如何止损，事后阶段更多的是复盘和整改。确定了稳定指标之后，需要围绕不同的环节开展具体的工作。我们先从团队规范开始进行讨论。

团队规范

团队规范的作用是指导大家在工作中的行为，避免因为错误的行为而导致事故。总体而言，规范在一定程度上预防了事故的发生。

代码规范

代码规范可以让团队的代码风格统一，提高代码的可读性，避免一些错误的代码产生 BUG。前端经常使用的 JavaScript 代码规范有 Airbnb JavaScript Style Guide、JavaScript Standard Style 等，为开发者展示了好代码的示例。另外，不要纠结于 “行尾是否加分号”、“缩进需要几个空格” 等这种几乎毫无意义的问题。规范是为了让所有人在行为上表现一致，所以势必要舍弃一些个性化的东西。代码规范的落实需要工具的支持，比如用 Eslint 做代码检查。在有些团队，还会在代码上线的 CI/CD 流程中，使用 Sonar 做代码扫描，并给出代码质量报告。

分支管理

分支管理要解决三个问题：Git 工作流、分支部署、Git 规则。如果不把这些问题解决好，那么就有可能出现下面的问题：

• 部署了错误分支

• 其他需求的代码被误上线

• 分支合并时代码丢了

• ... ...

Git 工作流

Git 工作流是用来明确团队的开发协作方式，如果一个团队经常出现 “代码合丢了” 的现象，那十有八九就是 Git 工作流出问题了，要不就是工作流太复杂让人无法掌握。上面的图中列举了 4 种常见的 Git 工作流，分别是：

• master 分支模式，只有一个 master 分支，所有的 commit 直接提交到 master 分支

• feature 工作流，多个 feature 可以并行开发，最终合并到 master 分支

• develop/feature 工作流，feature 分支开发完成之后合并到 develop 分支进行测试，最终合并到 master 分支

• Gitflow 工作流，在 develop、feature 分支的基础上增加了 hot-fix 和 release 分支，适合预定发布周期的场景下使用

分支部署

前端通常会有两种发布类型，一种是基于功能的持续发布，另外一种是基于周期的版本发布。而对应的发布环境有：开发环境、测试环境、预发环境、生产环境等。这些不同的环境发布的代码，是和特定的分支对应的，这与团队选择的 Git 工作流也密切相关。比如，选择了 feature 工作流，那么一般会将 feature 分支部署到测试环境；测试完成后将代码合并到 master 分支进行预发验证；然后发布到生产环境完成上线。

Git 规则

在我们自己的团队中，使用 feature 工作流的方式进行协作，我们将 feature 分支统称为开发分支，并且补充了一些规则：

在阿里巴巴工作期间，曾经经历过上线分支错误的事情。某次上线之后，发现线上的已有的功能不见了，最后排查出是发布了错误的分支。其中一个同学是以 develop 做主干分支发布的，然后将项目交接给了另一个同学，另一个同学使用了 master 发布代码。

Code Review

Code Review 是很多团队都在做的，可以参考谷歌 Code Review 实践，这里不再做讨论。

上线发布

对于上线发布来说，可将其划分五个关键步骤，可以用固定的上线模版来填写。

• 制定发布计划，要明确发布的内容、时间等，特别是服务上线顺序以及回滚方案。

• 周知相关方，通常发布计划会以邮件的方式通知到大家。

• CheckList 确认，将出过问题的点或潜在的风险点要一一确认，排除潜在问题。

• 执行上线，无论是研发执行上线还是 QA 执行上线，都要及时同步上线进度

• 线上回归，只有线上回归通过，才标志着上线完成。

我们在做微信小程序需求时，经常会在上线之后发现忘记将域名加入白名单。之后我们在 CheckList 里面做了明确要求，要做完相关检查确认之后才允许上线。

总结

本文主要介绍了稳定性指标，以及如何从团队规范方面做稳定性保障，后续会从其他方面展开介绍。

关注公众号，及时订阅最新文章