如何减少线上的故障率

这个话题其实很大，而且也很普遍，为什么我今天又拿出来说一说呢？因为过去有很多看起来很有道理的解决方案，其实对于小公司团队并不适用。

工作前10年，我都呆在大厂，大厂可以用很严格的执行流程和体系来保证，比如单元测试覆盖率不达到70%，不让上线。而过去4年，我在创业公司，发现大厂那套东西，拿过来是没法直接用的，所以我来说一说。

大厂的办法都是很道理的，但在小团队都有各种“水土不服”：

1. 建立明确发布时间点，减少需求的频繁变更次数：

1.在创业团队，虽然也有明确的发布时间点，但是却无法“阻止”各种临时发布，而且由于一些需求的产生，本身就是拍脑袋来的，在发布当天都难免会改多次。

2. 创业公司的需求很多都是倒排，发布时间很难与常规发布点吻合。

2. 加强发布和代码质量审核

1. 正如#1所说，让核心的开发人员停下手上的任务来推行代码审核，有很多实际的困难。以我的经验，能够做到自始自终高质量执行的团队比较少，很容易变成虎头蛇尾。

2. 对公司流程和团队执行力的依赖太大。

3. 招聘高水平的工程师

1. 高水平的工程师不是那么好招的，这不比当时在大厂，有络绎不绝的简历，名校+ 精准背景匹配。

2. 创业团队缺乏品牌号召力，同时成本是需要控制的。

3. 高水平的选手，需要与之配套的流程和工具，否则短期内无法提升项目的质量。

对于一个小团队，制定技术方案，以达到减少线上的故障率的目的，还需要满足以下几个约束条件：

1.充分利用现有人员，不大幅度增加成员

2.学习成本比较低，能短期内产生明显效果

3.投入成本控制在一定范围

对应的解决方案：

1.制定简单明了的接入规范,  不是为了让工程师做更多的手动工作，而是要让每位工程师做的每一项工作必须要接入我们的自动化流程中。

2.充分利用和集成现成的各种工具，例如，Sonar + Jenkins + 蓝鲸 + ZMON + Grafana，等到一定熟练的阶段，进行个性化的二次开发。

3.自动化执行，最大化的减少人工干预。

总而言之，尽量制定出一些客观标准，通过工具代替人检查代码+发布版本+线上处理。

靠自动化的工具，去降低的人的依赖，努力将业务之外的技术开销降低到最小。

最后说几点心得：

1. 不建议一上来就要用上所有的工具，循序渐进，先解决一个痛点，再拓展到更多的点。引入一个新的工具，需要增加团队的学习成本，要做到可控。

2. 同样的，开始的时候，也不可能用上一个工具的所有特性和选项，摸石头过河，等熟悉了，再增加投入。

3. 自动化运行真的很重要，无论是测试，发布还是预警。组合了这么多工具，靠人来驱动的成本太高，如果不能自动运行产品，那么以后是无法持续的。

4. 使用这些工具的目的，是守住线上产品的“底线”，同时流出更多的时间给团队，让我们能提升产品的“天花板”。

描二维码或手动搜索微信公众号【架构栈】： ForestNotes

欢迎转载，带上以下二维码即可

                     

点击“阅读原文”，所有【架构栈】近期的架构文章汇总

↓↓↓