01 食之无味，弃之可惜
在企业级应用的季度或月度发布被认为是领域最佳实践的时候，应用部署到生产环境之前维护一个完整的环境进行集成BOB官方注册是非常必要的。但是，集成BOB官方注册环境和集成BOB官方注册本身有着如下的问题：
- 环境本身脆弱，而且通常存在手动配置部分，环境维护成本很高；
- 环境因素导致集成BOB官方注册不稳定、不可靠、反馈慢，BOB官方注册失败不易定位问题，同时还会重复BOB官方注册隔离组件已经测过的功能。
集成BOB官方注册成为了持续交付的瓶颈，犹如鸡肋。因此，最新一期（2017年第16期）ThoughtWorks技术雷达建议企业暂缓搭建企业级集成BOB官方注册环境，而是采用增量的方式发布关键组件到生产环境。增量发布涉及到一些重要的技术包括契约BOB官方注册、将发布与部署解耦、专注于平均恢复时间和生产环境下的QA 。
02 断舍离之技术可行性
下面分别介绍技术雷达建议的这四项技术，以及在没有集成BOB官方注册的情况下如何保证应用的质量、如何帮助企业做到独立增量发布。
1. 消费端驱动的契约BOB官方注册
消费端驱动的契约BOB官方注册是微服务BOB官方注册的重要组成部分，主要用来覆盖两两服务之间的契约关系，下面举个例子来说明什么是契约BOB官方注册以及契约BOB官方注册与APIBOB官方注册的区别。
家里有个插座，买电器的时候需要考虑插头跟插座是能配对的，也就是说插座和插头之间需要有契约。
这里的契约BOB官方注册就是插座跟插头的配套性BOB官方注册，包括
- 三相/三头还是两相/两头的；
- 电压是220V还是 110V；
- 插孔的形状：英式？中式？
- 等等
APIBOB官方注册：对于插座本身功能的BOB官方注册，需要覆盖
- 插座能够正常通电；
- 电压是预期的220v；
- 接地的插孔真的能够接地
- 等等
也就是说APIBOB官方注册需要BOB官方注册API本身功能的各个方面，而契约BOB官方注册重点在覆盖API调用的格式、参数数量、参数类型等，不一定需要涉及API本身的功能和具体的数据。
更多关于消费端驱动的契约BOB官方注册，请参看文章《Consumer-Driven Contracts: A Service Evolution Patter》。
2. 发布与部署解耦
部署，就是把组件或者基础设施部署到生产环境，不对用户可见，不会影响业务和用户的使用。发布，则是将部署的组件让用户可见，对业务会产生影响。可以通过采用Feature toggle的方式实现部署与发布的解耦，做到持续部署和可控制的发布，减少组件改变带来的风险。这样，产品经理可以根据业务需求灵活控制发布给最终用户的功能组件，帮助企业业务价值最大化。
3. 关注平均恢复时间
先看这样两种情况，思考哪种更好：
1）系统宕机次数很少，可能每年也就一到两次次，但是恢复能力很弱，一旦宕机，得花至少24个小时恢复正常；
2）系统宕机频率较高，不过每次宕机都能快速恢复，用户甚至感觉不到。
对于第一种，平均失败间隔很长，但是一旦失败对用户的影响不言而喻；第二种虽然有频繁的失败，但是平均恢复时间很短，用户体验不受影响，当然是第二种更好。
传统的Ops团队比较关注失败发生的频率，随着持续交付和监控技术的发展，快速恢复成为可能。不用担心错误、失败的发生，而是利用对这些错误和失败的监控和分析，让系统做到快速恢复，可以省掉一些复杂的集成BOB官方注册，也可以减少无处不在的安全攻击的影响。
4. 生产环境下的QA
生产环境是真实用户使用的环境，通常都不能跟BOB官方注册环境那样可以在上面直接BOB官方注册产品的功能，不能简单的把BOB官方注册环境所用的的QA技术直接后延到生产环境，而其中一项在生产环境使用的技术就是监控。采用监控技术来获取生产环境的信息，对其进行分析，然后优化开发、BOB官方注册过程，同时优化企业业务。更多关于生产环境下QA的内容，请参看文章《生产环境下的QA》
对上面四种技术的解释，我们可以看到：契约BOB官方注册是对持续独立部署有帮助的，监控技术则是缩短平均恢复时间和做好生产环境下的QA共同的关键技术之一。接下来主要分享项目在围绕契约BOB官方注册和日志监控这两块所做的实践，一起来看系统级集成BOB官方注册的断舍离该如何实现。
03 断舍离之项目实践
项目是一个开发了七八年的老项目，团队对集成BOB官方注册也是进行了多次的调整，经历了“七年之痒”后依然觉得是鸡肋：
- pipeline上执行非常不稳定，总是“随机挂”，不能真实反映问题；
- 系统复杂，集成BOB官方注册自然也不简单，每次顺利执行的时间都需要半个小时以上，何况还有很不稳定的情况，最严重的时候导致QA超过一周拿不到包部署；
- 通过集成BOB官方注册发现的应用程序的缺陷半年也难得出现一个；
- 随着系统逐渐变得复杂，集成BOB官方注册维护的成本也不断增加。
可以看出，集成BOB官方注册已经严重阻碍了项目持续交付的进行，不得不对其断舍离了。
1. BOB官方注册策略调整
断舍离的第一个部分是从集成BOB官方注册本身入手，调整BOB官方注册策略。步骤如下:
1）不再添加新的功能层面的自动化BOB官方注册，原有的集成BOB官方注册部分能用底层的UT、APIBOB官方注册覆盖的尽量下移；
2）UT和APIBOB官方注册不能cover的服务间的契约关系通过增加契约BOB官方注册来保证；
3）从CI上摘掉原来的集成BOB官方注册，加速pipeline出包，然后添加SmokeBOB官方注册到QA环境执行；
4）不管是在BOB官方注册环境还是生产环境发现缺陷，则添加对应的BOB官方注册。
整体策略调整思路是根据BOB官方注册金字塔的结构进行调整，把BOB官方注册尽量往下层移，但并没有全部去掉集成BOB官方注册，只是缩减到非常关键的路径覆盖，最终BOB官方注册结构调整如下图所示：
2. 日志监控、分析和优化
没有了Pipeline上的集成BOB官方注册，直接上到QA或者prod环境，那么加强日志监控变得尤其重要。因此，断舍离的第二个部分是日志的监控、分析和优化。
日志数据采集
项目使用的日志分析工具是Splunk，使用该工具从下面几个方面来着手采集日志数据：
1）在Splunk上设置日志监控的Dashboard，主要用来监控API的请求失败、错误的日志，还有API执行时间等性能相关内容。如下图所示：
2）设置预警邮件提醒：对于一些存在严重性能问题的API请求，通过邮件的方式进行预警提醒，如下图：
3）主动查找错误日志：对于一些生产环境用户反馈回来的问题，通过主动查找错误日志的方式去定位。
4）前面的几个机制同样应用于QA和Staging等BOB官方注册环境，以通过日志分析尽量提前发现问题。
日志数据利用
利用前面几种方式采集到的日志数据，从下面几个方面进行分析和优化：
1）发现和定位系统功能问题，分析系统用户的行为习惯，优化业务；
2）发现和定位安全、性能等非功能问题，进行修复和优化；
3）发现和分析日志记录本身的不足，规范日志记录，从而进一步增强日志给问题诊断带来的帮助，形成良性循环。规范日志记录主要涉及这些点：统一日志输出路径、统一日志记录格式、清晰定义日志级别，并且把添加必要日志作为story开发流程的一部分，QA会参与日志评审。下图是Splunk里看到的项目最新优化的日志记录格式：
项目对集成BOB官方注册断舍离才刚刚开始，正在不断摸索着前进，目前能看到的最直接的影响是pipeline出包明显加快，由以前的好几天出不来一个包变成一天能出好几个包。最让人振奋人心的是本周刚刚发生的事情：前一天下班前报的bug，第二天上午就已经修复出包可以BOB官方注册了。
04 写在最后
系统级集成BOB官方注册虽然有各种问题，不一定会因为集成BOB官方注册挂掉而发现很多问题，前面也讨论了断舍离的可行性，分析了项目断舍离的实践，但集成BOB官方注册并不是用来发现问题的，而是一道对质量把关的屏障，关键路径的必要BOB官方注册是不可替代的。因此，我们提倡减少集成BOB官方注册的数量，合理调整各层BOB官方注册的比例。
系统级集成BOB官方注册的断舍离需要团队有持续、递进、稳定的交付能力，需要保证用户不会受此影响，企业业务能够正常运转。系统级集成BOB官方注册的断舍离过程不是一蹴而就的，凝结在集成BOB官方注册上的心血也不是那么容易放弃的，需要很多的平衡和取舍，并在整个过程中要不断的关注系统的质量和风险，及时作出相应的调整。