研发效能之环境管理


“谁把我的环境给重新部署了?”

“我的环境里边的数据怎么不对了?”

“谁能帮我把线上的配置同步一下到线下?”

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

环境的分类

网络类型环境

从网络环境的可访问性区分,研发效能涉及以下三种环境:

研发效能之环境管理插图

 

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

 

IT、运维和安全的小伙伴一般更愿意从网络的可访问性去划分环境,因为这样可以划分资源、设置访问策略、进行安全检测等。

用途划分环境

对于产研团队来说,我们通常从环境的用途来划分环境,一是和自己角色相关,研发用研发环境,测试用测试环境;二是通过用途区分好理解。至于能否打通,是否受限一般由底层基础设施团队来维护,大家都不太关心。对于我们研发效能团队来说,我们一般会维护一张各个环境互联互通、安全网络策略的表格,让各方心里都有数。万一出现访问性的问题,相关人员也能自己排查。

研发效能之环境管理插图1

 

  • 开发环境:一般用 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,大家一起交流沟通,共同进步。

文章来源于互联网:研发效能之环境管理

THE END
分享
二维码