研发效能之环境管理

火炏焱焱

“谁把我的环境给重新部署了？”
“我的环境里边的数据怎么不对了？”
“谁能帮我把线上的配置同步一下到线下？”

环境管理是我们日常工作中比较复杂的一环，主要是因为涉及内容比较多，程序、配置、数据都会涉及，如果是开发、测试环境，还会涉及到测试数据造数、系统刷数据、不同的人使用、锁定、转让、释放等问题。下面我将会从环境分类、环境建设的难点，以及最后如何解决这些难点来讲述研发效能之环境建设。
环境的分类

网络类型环境
从网络环境的可访问性区分，研发效能涉及以下三种环境：

• 办公网络环境：公司的内部办公网，也是管控相对比较宽松的网络，可以访问外网。因为部署了各种内部服务，网络环境相对比较复杂
  
• 测试网络环境：用于部署各种测试服务，包括研发测试用的环境，也包括QA的测试环境，可以进行功能测试，也会进行压力测试等，一般都可以和办公网相通，但不与外网互通。
  
• 线上网络环境：与办公网、测试网络隔离，一般不能访问办公网络环境和测试网络等环境。
  

IT、运维和安全的小伙伴一般更愿意从网络的可访问性去划分环境，因为这样可以划分资源、设置访问策略、进行安全检测等。
用途划分环境
对于产研团队来说，我们通常从环境的用途来划分环境，一是和自己角色相关，研发用研发环境，测试用测试环境；二是通过用途区分好理解。至于能否打通，是否受限一般由底层基础设施团队来维护，大家都不太关心。对于我们研发效能团队来说，我们一般会维护一张各个环境互联互通、安全网络策略的表格，让各方心里都有数。万一出现访问性的问题，相关人员也能自己排查。

• 开发环境：一般用 dev 标识，用于开发人员编写代码、调试程序，配置可以比较随意，开发调试方便为主，开启调试模式。代码极其不稳定。
  
• 联调环境：因为联调环境通常是相对比较稳定的一个开发环境，所以通常也是用 dev 标识，主要用于前后端联调接口，通常部署接口相对稳定下来的代码。
  
• 测试环境：一般用 qa 标识，这个环境通常用于测试人员功能测试、缺陷回归。配置尽量和线上环境保持一致。部署要验证的相对稳定的代码，而不是最新的代码。
  
• 预发环境：一般用 pre 标识，用于最后确认功能。一般都直接采用线上的配置和数据，但是仅限确认功能的人使用，不对用户开放。使用时一定要注意以免脏数据产生，影响正常服务。部署经过 qa 验证要上线的代码。
  
• 验收环境：即用户验收测试环境(User Acceptance Testing)，一般用 UAT 标识，通常是由最终软件的用户进行的测试，因此是面向最终用户的测试，结束之后通常就可以发布生产环境了。部署经过 qa 验证要上线的代码。
  
• 生产环境：一般用 prod 标识，部署经过测试、确认的代码，通常不用于功能测试，不开启调试模式。AB测试一般在生产环境下，而隔离比较好的情况下，也可以做性能测试和压力测试。
  

集成测试环境，有的行业也称之为SIT 环境（system integration test），而我们更愿意称之为 QA 环境，简单明了且无需解释，大家都能了解。用 SIT 有很高的解释成本；同理预发环境，也有人用 staging 环境，但总觉得没 pre 更加简单，且能让更多的人了解其用途。 另外一个角度就是，我们公司里大家建设的环境名的统计数据也支持了我们的想法，qa 环境比 SIT 环境数多，pre 环境比 staging 环境多。

环境建设的难点

环境建设主要涉及资源、负责人、建设和维护四个方面，当然难点也主要在这四个方面。
1. 缺少硬件资源
很多公司之所以没有开发、测试环境是因为没有硬件资源。没有充足的资源搭建测试环境，这是环境建设的第一个难点。尤其是很多不那么「现代」的公司，比如创建个虚拟机还要申请，走漫长的审批流程，层层审批的。
也有的公司经常把一些配置特别低且过保的机器给开发测试环境用，三天两头出问题，白白浪费了开发测试人员的时间。
2. 缺少明确的负责人员
很多公司线上环境还能保证专人负责，开发环境就是员工工作笔记本，几乎没有QA环境。这种开发、测试环境缺失的主要问题还是在业务负责人对自己业务的理解。没有意识到开发、测试环境建设对研发效率、生产环境质量的影响，也没意识到需要有明确人员负责环境的建设和维护。
3. 耗时长难搭建
每次搭建都需要研发同学申请机器，然后手动在机器上一个一个服务的安装服务，同时还要配置各种中间件，刷入对应的数据等。难搭建耗时长，对于使用方和搭建方都是一种折磨。
4. 缺少后期维护
环境搭建出来后，因为缺少后期维护，环境中的服务版本和线上有所差异，但是其他人又不知道如何更新；线上数据库表结构变化了，也没人同步到线下；某些线上功能，甚至在测试环境都无法回归验证。慢慢环境就会变成无法使用状态，于是开启了又一轮搭建环境的痛苦过程。
5. 缺少复用
假设一个业务有20个微服务，每个微服务一个容器，那么联调、测试、预发、UAT四套环境都完备至少要80个容器；如果有3个QA同学并行测试，都独占环境，那么就要240个容器。这还是微服务较少的情况。如果要是业务复杂起来，微服务数量增多，实例的副本增多，环境套数增多，那么就会占用大量的物理资源。
环境建设最佳实践

针对以上问题，把我们的实践分享给大家。
1. 充足的硬件资源
虽然现在硬件相对人工成本来说已经相当便宜，尤其是有各种云资源可以利用，但是不得不说有些公司依然在资源上不愿意投入。现在一人天500人民币，可以在某云上买一个2核2GB内存50GB的云服务器使用一年。而500人天，月薪1万左右，一个应届生的工资可能都比这还高。如果按照资深工程师去算，更得不偿失。现在和之前硬件价格高企的年代不同了，所以能硬件解决的就尽量不要用人去解决。
前期资源的使用可以粗糙一些，后面可以设置个资源池大家共用，再精细化一点可以针对每个人设置配额。因为每个人使用的资源是不一样的，研发可能1-2套环境就够了，但是并行测试任务较多的QA小伙伴就会需要更多的资源，这个时候配额的上调又需要个流程来完成。我个人总觉得加上审批流的过程是不完美的。
2. 权责清晰的团队
想要把开发、测试环境建设好，关键是要有明确的环境负责人。以往经验来看，谁需要、谁建设、谁负责。

• 开发环境的第一负责人是研发同学
  
• QA环境的第一负责人是QA同学
  
• 线上环境的负责人是团队所有人员，第一责任人是业务负责人。我们不能要求业务的负责人时时刻刻盯着线上环境，但是我们要求业务负责人去建立相应的机制、安排合适的资源和人力去保证线上业务的稳定。这也是业务负责人必须明确的原因之一。
  

为啥线上环境的第一责任人是业务负责人，因为他才能结合多种背景因素做出最恰当的判断。
举个例子
之前我们一般都是晚上下班以后、周五下午、周六日都可以上线。如果仅仅是前端问题，甚至中午都可以上线。那个时候，我们每个人回家都是带着笔记本回去，晚上上完线以后，还要测试，没问题以后才算完。大家虽然很累很赶很忙，但是有一股劲：这是「我」的产品。
后来产品成了「我们」的产品，「老板」的产品，改成了每周五上线，其它时间除非紧急缺陷修复否则不上线，要去团建不上线，老板没审批不上线，周末上线担心发现bug不上线。看似「上线」规范了，实则跑不起来也跑不快。大家看似各司其职，实则是守着自己的领地，却丢了整个的阵地。牺牲了业务，把业务中的问题划归到「流程」「制度」问题。其实这也是一种不作为。

一头狮子占领了一个山头，这就是它的领地，其它狮子就不能进来了，进来了就是侵犯我的领地。阵地作战，大家的目标都是一致的，那就是赢。有利于目标达成的，都可以去实施都可以去干。所以团队要强调有阵地意识，没有领地意识。

3. 一键搭建环境
环境的搭建必须方便、快捷，这样才能提高所有产研团队的效率。但是很多公司在这一块都很薄弱需要改进。很多公司生产环境都治理得不是很好，何况开发和测试环境。
一个业务的环境不能只有几个人能搭建出来，不能手动修改很多配置才能跑，这样做是十分危险的。这个时候我们需要一键可以把环境拉起来且可以使用，使用完毕后即可释放的功能。哪怕用 Jenkins 搞定也可以，但必须要快、可重复、可重现。
我们的作法：

• 首先，我们使用 k8s 搭建了一个资源能自动伸缩的底层基础设施
  
• 其次，我们自己的应用中心有环境搭建所需要的各个服务的定义
  
• 接着，我们还有各个服务对应的编译、构建、部署流水线
  

有了上面的条件，我们就可以一键把涉及的所有服务代码下载、构建后自动部署、部署后服务启动、自动检测、接入监控日志告警，接入服务大盘。
说一千道一万，光有好的规范机制是不行的，还是要落到实处，需要平台来落实它、承载它；平台有用、易用又能更好支持规章制度。
4. 专人维护
比环境搭建还困难的就是环境维护。环境搭建出来只是一时之功，但是要想让一个环境能起到作用，随时可用，日常的维护是必不可少的。比如更新应用的版本，更新配置文件，更新数据库表结构，刷数据库中的数据。有的人想用但是没能力没资源维护，有的人能维护但是业务压力大没时间没动力去维护, 不出几天环境就不能用了。如果想用，又得花费很大的工作量去修复或者重新搭建。
我们开发环境主要是研发同学维护，测试环境都是QA小伙伴维护。因为一键可以部署出环境，所以是谁搭建也就无所谓了。极大减少了搭建耗时，提高了工作效率。
5. 资源独占和泳道相结合
资源复用这个问题只有环境大量的被创建和使用，现有的资源无法满足需求的时候才会有环境复用的烦恼。目前大多数公司（99%）的公司还都没有这个烦恼，因为这些公司的难点还在创建、维护环节；但是剩下的那1%的公司一旦有这个烦恼就是个大烦恼。

• 现在的环境已经占用了太多的资源，不能再采用独占的策略了。
  
• 公司的业务太复杂了，已经很难重新搭建出一套完整的环境。
  
• 依赖的服务已经超出了使用者可维护的范围，使用者已经无法维护依赖的环境了，需要交给服务所有者来维护。
  

小业务简单服务独占环境
小业务的环境好搭建且独享，易用好用，缺点就是牺牲了一些资源，服务无法复用。我始终认为只要环境可以快速创建、快速验证、用后即焚，独占的环境是最理想的。不用过多的流程审批、协调方面的管控。
大业务复杂业务复用环境：
之所以想复用环境，是因为业务比较复杂，尤其是微服务框架下服务个数多，调用链路长，我们已经无法把所依赖的环境全部快速搭建出来，且配置完毕后能正确访问，我们只能依赖于其它方来维护这些环境，而我们对其形成依赖。另外一个原因就是这些被依赖的服务本身依赖和部署做的十分糟糕，无法可以通过一种简单的方式部署且能快速启动，里面可能在程序部署后还需要大量的手动操作。
现在比较成熟的是泳道。阿里、美团等公司内部都有自己的内部实现。大家可以深入了解一下。

对服务链按需求进行分组复制，并实现逻辑、物理的隔离，使得不同需求的服务链运行在相隔的物理机器上，逻辑上如同游泳场中的泳道。

当然泳道也不是完美的解决方法，对业务有侵入，且中间件也需要很好的处理和配合，才能让泳道发挥作用。
本文小结

本章主要讲述了环境的分类，环境建设过程中的难点和环境建设的最佳实践。环境建设是一个非常见功夫的事情，需要大量的人力物力长期的投入，不是一朝一夕就能完成的事情。放眼望去，国内能做到各种环境一键拉起即用的少之又少。这也给了我们一个很大的提示，这里有很大的空间，大有可为。
如果各位也有这方面的问题，欢迎和我们联系，关注scmroad，大家一起交流沟通，共同进步。

似念似恋

动动小手，点赞转发在看三连 关注 scmroad，了解最新研发效能发展动向, 加我进入「DevOps研发效能」