生产环境缺陷管理

前言

在一个大型团队中，bug协同管理是一件复杂的事情，发布经理要追版本bug，运维同学要评估bug影响范围，开发同学要在多个开发分支同时修复同一个bug，很容易出现bug漏提交、漏确认等生产安全问题。

本团队也出现过一起不同分支漏提交bugfix导致的一起P1故障（最高等级），该bug在生产环境进行hotfix时，漏掉了少量集群导致该二次故障。举个相似的例子，某品牌汽车发现潜在安全隐患进行召回，但却遗漏了某个小地区，偏偏在遗漏的地区，发生了安全事故导致有人员伤亡。

我们基于go-git开发实现了通用化的git-poison，通过分布式源码管理bug追溯、查询，可复制性高，适用于所有git仓库，与分支模式和代码仓库无关。bug管理不依赖人与人之间沟通协调，降低了认知负担。

Bug为什么重复翻车

任何软件都会有bug。即使再全面的测试，再细致的代码review，也不能保证线上的每一段代码都bug-free。但是已经识别到的bug，为什么还会重复翻车呢？归根结底，git多分支开发模式会导致bug扩散。引入bug和发现和修复bug的时间异步，口头沟通确认bug易疏漏。

很多人看到前言的故障可能会认为，这只是“不小心”犯了个错误，下次再“细心”一点儿就好了。其实不是的，在百人规模的团队中，人犯错可以说是必然的。

图1 (Baron Schwartz "Approaching the Unacceptable Workload Boundary")

上图形象展示了人与人之间的协同成本。10人团队的整体协同一次的沟通次数为90/2=45次，那么100人则是4650次。这个次数只是相互协同一次，大多数场景下，由于bug和bugfix是随时出现的，再加上人的失误 (沟通中忘了某些bug等)，所以一般来讲，一个发布流程至少需要前后同步三次，沟通成本巨大。所以谁能打包票，在这个流程中不犯错？只有通过工具来进行自动化管理才能保证从“不做错”到“做不错”。

几个典型翻车场景

场景一：未修复bug代码上线

图2 发布同学多方协同

微服务化盛行，系统各服务独立发布，发布owner也会选择本组比较有经验的同学，但仍旧不能避免开发与发布之间的信息割裂。该类问题有很多种表现形态，举例来说：

• 我是一名开发：我发现了一个新Bug，我得赶紧告诉版本发布负责人，叫停本次版本发布；
• 我是一名测试：我发现了一个新Bug，我需要评估线上该Bug受影响的范围，安排hotfix；
• 我是一名运维：我在调查一个生产问题，我不知道这是不是一个已知问题，我去问问开发；

版本发布同学，作为整个流程的核心人物，在这个繁琐的流程中极易犯错。

场景二：已修复bug但没修全

还有一类情况，就是针对分支开发的代码漏合。

图3 分支开发漏合bugfix

某一分支发现bug时（参考上图branch master），第一时间一定会在master分支上进行修复。然而此时带有该bug的branch1就被遗漏了。该问题在多个LTS（Long Time Support）分支的开发模式中尤其严重，每个版本都需要发布同学double check有无重点bugfix漏合。

场景三：已修复bug线上漏发

这就是前言提到的场景。人为疏漏。

漏发确实是非常大的问题，但是也有客观原因。面对千万级别的生产环境，数十年多个生产版本共存，面临这样的组合爆炸，人肉确认hotfix发布范围不遗漏确实是很大的挑战。

图4 线上多种环境组合，发布同学易遗漏

如上图，假如所有集群按物理ENV分为六组（线上生产远大于此），例子里本次发布bugfix的同学就是漏掉了ENV5的集群，已知bug也刚好在这个分组的集群中再次出现了。

发布卡点Bug信息

因此，应当存在全局角色来维护bug相关信息。任何角色、任何时间、任何地点都能够编辑和访问。

无论是devops模式，还是传统的专职“研发，测试，运维”模式，都会面临负责发布的负责人，单点评估整个版本的bugfix以及确认未修复bug，充当“人肉pipeline”。作为一个分布式系统开发人员，能否使用分布式工具来解决分布式沟通协同的老大难问题呢？

git-poison的出现，不仅能实时在“开发，测试，发布”间同步所有已知问题，还能参与发布卡点，确认当前版本的未修复bug信息，节约人力成本。

图5 多方调用git-poison满足需求

如何使用

git-poison基于go-git的分布式源码管理，实现bug的追溯、查询和反馈，灵活&&可复制性高，适用于任何开发模式以及任意代码仓库。另外，git-poison不依赖人与人之间的协作沟通，减少认知负担沟通成本，自动化精准召回bug中毒域，实现poison commit发布阻塞。

图6 git-poison 投毒/解药/银针 （yum install git-poison）

对于开发者，只需要记住一件事：抓紧投毒！

回到前言说到的P1故障，使用git-poison就能简单有效避免“重复翻车”的场景：

• 值班：线上出现故障，定位问题。使用git-posion投毒。
• 开发：bug修复，使用git-poison解毒。
• 发布hotfix：发布完毕后，使用git-poison银针，确保线上所有带bug的版本，都带有本次的bugfix。

如何实现

每一次投毒/解毒，git-poison的poisons远程git仓库中都会生成/更新一条对应记录。不同代码仓库对应不同分支，隔离不同源的posions信息。

{  "poison":"1q234tre5467gcs7yui8ew13",  "cure":"9875jgbsw32gtx6djri8sofi0h",  "comment":"[to #12345678] service iohang",  "editor":"Iris",}

check-commit则应用了git原生强大的history tree管理。

图7 红色QW为毒药commit下的git历史DAG

如上图，假如我们当前在release分支上，上次的发布commit是B，当前的发布commit是X。通过 git rev-list 可以直接获取到整个DAG（Directed Acyclic Graph）。结合git-poison的记录，若红色的Q和W是没有解药的poison，则git-poison会阻塞本次发布，返回投毒同学以及对应bug的记录文档信息。

假如我们在Dev分支上查询L是否“有毒”，则git-poison会返回“healthy”。

最佳实践

发布减负

图8 发布平台使用git-poison进行卡点

引入git-poison后，在团队的发布流程中，发布平台会调用git-poison自动导入本次版本发布的“Bugfix列表”和“未修复Bug列表”，便于发布经理评估该版本的质量风险，无需再口头追个确认。包括本次发布修复的问题列表，以及是否有未解决的bug。

风险观测

图9 git-poison 联动线上风险展示

运维平台可以集成git-poison来检查线上部署的服务版本是否存在中毒情况。线上风险一目了然。尤其是发现一个新bug后，值班同学可以立即投毒，并通过该页面获取该bug影响的范围。

结语

目前git-poison已经在公司内部开源，团队已经实现、使用并集成到发布平台管理Bug一年多。开发同学本地使用顺畅，学习成本低，发布流程中多次有效阻塞带bug的版本，并为定位bug影响范围提供极大便利。