第一，架构审查委员会。大家都知道一个架构一旦被设计出来了以后，就是架构师给大家描述一下他的思路然后程序员就开始往架构里面填写内容了。这个场景其实在很多公司都出现过。因为公司技术最好的可能就是架构师了，老板对技术了解不深，下面的程序员可能水平也一般。这就造成了架构师的技术权威性。如果没有一个审查委员对架构进行审查，特别是大型的项目，会造成架构考虑不周全，不适用的情况。这里就需要经验丰富的专家（内外部）来协助验证架构。
第二，代码审查。这个比较常见，程序员每天开发完成以后check in代码。试想一下如果每个人的代码风格都不一样，以后维护和解决问题效率就会下降。这里我们应该制定代码标准，并且通过程序自动审查和人工审查的方式协助程序员完成合乎标准的代码。
第三，性能测试。如果我们不能了解我们系统能够承受的业务负载是否能够满足我们的业务预期，那么我们开发出来的软件恐怕是没有多少人会用的。所以，这块的工作是必不可少的。
第四，单元测试。说到这里，很多程序员都觉得这个是一场噩梦。特别是业务程序员，业务逻辑写完以后，还有准备那么多路径的单元测试，估计这个测试的时间比写代码的时间都要多啊。不过这个是保证代码质量，程序质量的一道屏障，也是考验程序员功底的地方。
第五，生产监控。一旦我们的程序上到生产环境以后，需要对各个服务，特别是核心服务进行监控。这些服务的健康状况就等于业务的健康状况。对他们的监控是运维服务的基础，也是提高服务质量的基础。
回滚
这个词大家一定不会陌生一旦程序发布失败，或者变更失败我们就会提供回滚流程。如果说障碍的管理是预防风险发生的话，那么回滚就是在风险发生以后的弥补工作。
这里我们需要明确一个概念就是回滚窗口，他是从版本发布到第一个服务访问高峰之间的时间。举个例子，我们做一次发布，当应用发布到服务器的时候，一直到用户开始大规模访问的这段时间。如果说这个时间是1小时并且在发布之后发现应用出现问题，那么说明回滚窗口的时间是1小时，也就是你的团队只有1小时用来回滚应用从而恢复系统正常运行。这个时间是需要在发布之前都预计好的。随着发布规模不同，发布应用重要程度不同，这个时间是不同的。
回滚技术的考虑，详细各位都遇到过这样的情况，在回滚应用的时候由于回滚会造成数据库的更改，让回滚操作显得捉襟见肘。新数据库和老数据库的差距始终让我们犯难。有几个建议可以给大家参考，新数据的扩展尽量放在老数据库的结构中，例如：同一个数据列承载更多的数据含义。（在业务允许的范围内）。或者，如果非要新增字段的情况下，让你的应用（API）同时支持新老两个库的操作。让后就是尽量不要对数据库字段做修改和删除的操作。
回滚成本的考虑，有些应用发布以后发现问题，如果这个问题是马上可以修复的，这个修复时间在回滚窗口时间内的，可以考虑快速修复并且做hotfix的发布。在作出这个判断之前要确定这个问题所牵连的服务，以及这个修复是否会对这些服务造成影响。在做回滚的时候，需要预估这个回滚的时间是否小于等于回滚窗口的时间。或者考虑对一部分的功能做回滚（这里需要对模块做严格的分割和降级处理做支持。）
降级服务降级服务实际上是对回滚的一种补充，或者说回滚的一种特殊处理方式。如果我们发布的时候发现某个服务无法使用了，这个时候回滚的时间又大于回滚窗口定义的时间。那么我们可以采取针对某个服务降级的处理，通过暂时隔离这个服务保证整个系统的可用性。这个在架构设计上需要先考虑，特别是个别重要的服务，他们作为基础服务会有很多其他服务分别调用他。一个这个服务不可用需要在调用方设计开关，并且测试当基础服务/重要服务不工作的情况下。其他服务是否能够通过兜底数据，或者服务开关保证自身的可用性。
总结，障碍管理是为了提高开发过程的质量，回滚是假设无论管理的再严格都会出现问题，那么通过回滚的方式做恢复，服务降级是回滚的特殊处理方式。
