导语 | 贝壳用户需求和用户量的不断增长，对系统的高可用性提出了更高的要求，服务端的质量保证工作该如何开展？本文是对贝壳找房-基础平台中心-质量平台赋能部总监——项旭老师在云＋社区沙龙online的分享整理，分享一些关于架构的新思想，希望与大家一同交流。
一、贝壳业务带来的质量挑战
1. 贝壳产业互联网的业务特点
如上图左上部分是买房的业务场景与电商业务场景的对比，电商经过选购、下单、接单、配送、完成，几步就能把商品买了，但房产交易中的环节就非常复杂。
比如处理二手房，先四处寻找房源，找到后进行委托，让经纪人去代看，房子合适了会签约，再房屋核验、资质审查，对方可能会进行解抵押，再网签，这时需要做房屋评估，之后面签、批贷、缴税、过户，领取房产证，客户还会抵押到银行，再放款，最后还有一个物业交割才会结束。这其中有多类角色协同，跨部门，跨组织，甚至和政府打交道。
二手房只是其中一个业务领域，贝壳的业务还有新房、装修、租赁等各种业务形态；从业务视角来看它贯穿业务前台、中台、saas服务、基础设施多个领域，共同完成一次房产交易。
中间是贝壳的业务架构，前端通过 C 端的贝壳、链家的 APP、M、PC、小程序为C端用户提供服务，通过 B 端的 Link、A+等APP、PC 服务为经纪人提供作业平台。在重点场景中有 400 电话、IM 的即时通讯。整个流程中，我们会有搜索推荐、VR实勘、交易平台等等。
下面是 SaaS 中台，围绕着房源、客源、经济人，多个环节一起工作。最下面是基础设施，有楼盘字典、安全风控、大数据、基础架构，有各种各样的技术设施支撑房产交易的运营。
最右边是技术架构上，我们现在用户触达层有 android，ios app，小程序，PC/M站，IoT， 接入层是网关，流量和业务网关，服务层多使用微服务架构，存储层等以redis，mq，hadoop 等开源的组件为主。
通过对贝壳业务架构、技术架构以及业务场景来分析，贝壳的业务特点如下：
（1）业务复杂
链路长，线上线下角色多，数据量多且复杂。
（2）形态多样
从 IoT 到直播领域，VR，到大数据，机器学习，到服务亿万用户的各种应用，横跨多种领域和应用形态。
（3）技术多变多样
贝壳业务发展非常快，伴随着业务组织调整也多；同时也有非常多的框架和组件版本；伴随着业务发展需要需要非常多的重构，升级工作。
（4）微服务化
贝壳的一个变化流程从采购软件到自研单体到微服务，业务底层基础设施日均几十亿的调用，也让技术迭代非常快，基本已全面拥抱微服务。由于业务的特点，所以我们在高性能，高可用和安全上有特别的要求。
2. 贝壳业务带来的挑战
上述详细了介绍贝壳业务特点，这样的特点会带来各种挑战：
（1）微服务下的量变质不变
微服务从 soa 发展过来，被越来越多的企业 it 生态所采用，它高内聚，低耦合的特征，丰富的开源组件，确实可以让业务需求快速被交付出去。但对测试来说挑战更大了，模块变多了，发布变多了，测试一次任务变复杂了，回归轮次和范围变多，环境更不稳定， 同时我们还要保持高性能，高可用。
（2）历史债务协同非标的质量损耗
多种技术栈，多类重构，会持续放大我们的回归工作量，不一样的研发工作，协同交流方式，都会加大我们的质量损耗。
（3）复杂业务下的测试数据，环境与回归
产业互联网由于线上线下的结合，再加上微服务的技术体系，测试数据，环境搭建和回归的难度更加大了，一次测试需要有房源，客源，经纪人，合同，楼盘等多个系统配合，严重的情况会涉及到几百个字段联调，怎么快速构造环境和数据验证逻辑正确性，这些都非常挑战我们的基础设施建设。
（4）跨多领域质量解决方案
由于形态多样，和之前提到的组织变化快，我们在历史上有很多质量领域的问题和解决方案尝试，如：移动端的，页面的，服务端的，性能的，接口等等，如何复用能力和抽象共性，而不是不是散点的解决，非常考验我们的质量架构设计能力。
质量问题涉及各环节、各角色，系统全面且高可用的提升质量和效率要靠体系化建设。
二、贝壳质量体系
贝壳质量体系的建设，分成理论、策略和信息来进行讲解。
1. 贝壳质量体系建设-质量三段论
各类业务、产品形态的质量保障的底层逻辑都是类似的，分成看的见的质量，难看见的质量和看不见的质量。
看的见的质量好感受，比如这个工厂流水线的成品，是好的，坏的。
难看见的是中间这个车床的过程工艺，机械臂的规格，抓取的力度，流水线的速度，这些因素可能会导致最后的成品的好坏，这是需要仔细观察才能看见的部分。跟古代的行军打仗一样，一次战役的胜利，可能在兵操演练，沙盘推演这些过程细节中决定了，最后打的一刻只是过程的检验，好的质量也是一样的，这一部分难看见，但需要被看见。
最后是看不见的那一部分， 也是很关键的一部分。 好的质量在最初的设计，研发的编码，架构选型，产品的交互，需求设计，异常的考虑在最开始被设计好的。质量意识能力会带来好的过程，最后是好的质量、好的交付物，好的交付物又会通过平台通过中间的过程工艺平台和交付物质检的平台推动整个质量意识的提升。
我们的质量体系建设也是围绕这几部分展开的，技术，产品形态有千种变化，这个背后的逻辑是一致的。质量体系也是按这个来构建。
2. 贝壳质量体系建设-策略
我们通过这个框架策略明确了质量部的目标，做事原则，和岗位角色，分工协作机制。
最下面的是大家做事的原则层， 我们希望通过标准化，线上化，平台化来做质量建设，以平台带动组织的质量能力，并且通过各项指标让组织能自我迭代。
最终大目标是通过业务 QA 推进组织转型升级，通过技术促进商业价值健康快速交付，组织最后的质量要高，而质量是所有人努力才得到的。
细节方面，最底层的质量意识会标准化贝壳产业的全流程规范，从需求到发布，全流程规范化、标准化，质量赋能体系也会有质量分、质量培训等等，提高质量意识。
3. 贝壳质量体系建设-细则
这里有四张网， 分别对应看得见的质量检查平台 KeTest， 难被看见的过程工艺部分KeOnes，和质量意识提升部分，以及线上运营能力部分。
（1）KeTest平台
KeTest 平台统一质量和解决方案标准，把各专项能力一站式提供，为全集团赋能，整体对各业务做质量保障，尤其产业互联网在自动化回归，数据，环境，高性能，高可用等部分做深入的能力建设。
（2）KeOnes平台
KeOnes 平台从开发编码到发布全环节打通协同能力，解构了产研 28 个环节，数十个系统信息孤岛，并通过 ci，cd 流水线能力，集成 KeTest 的质检能力建设 4 道质量闸门，在各环节快速反馈质量问题，通过 KeTest，KeOnes 绝大部分质量问题能在线下环节发现。
（3）线上环节
在线上环节，我们通过自动化巡检，监控，预案演练，熔断，限流，降级等能力保障线上运行的稳定性。
（4）线下环节
在线下环节，我们会持续做质量意识提升的事项，标准制定，考试通过，培训，活动从源头提升人和组织的质量能力。
每一部分具体怎么做呢？下文将会详细为大家展开。
三、贝壳质量体系建设
1. 基础设施建设 - KeTest质量平台
KeTest是为贝壳集团整体质量提供的一站式解决方案平台，类似QA的工作舱，核心提供5大能力，解决方案层面，为各业务形态，提供工具，测试策略，环境，执行计划，结果通知，帮助各业务团队快速搭建质量解决方案, 质量能力能快速到一个标准水位。
质量学院是整体大家的知识大脑和经验仓库，也和质量素养具体活动，认证等打通。质量开放服务提供api辅助在消息，指标统计，基础测试框架等通用逻辑部分，质量工具提供10余种专项能力，比如自动化，性能，数据构造等，质量度量通用分析质量建设能力水位线。接下来会把里面核心中比较有特色产能功能、特色专项的进行介绍。
2. 基础设施建设-sosotest
微服务化架构下接口特别多，链路长，模块也多，回归成本，自动化建设成本都很高，sosotest提供了多模式的使用方式适合不同能力的测试人员，和不同场景的业务，能快速编写自动化用例。
目前自动化用例制作支持网页和python后台编写的模式，也支持http，dubbo多种协议类型，同时提供mock，用例录制，自动生成等能力，解决链路长，模块多的情况，在此基础上，自动化用例也和持续集成，自测，线上巡检深度整合发挥价值。
目前用例数有4.6W，全集团87%的业务线在使用sosotest，其中也有不少研发贡献的用例,某些业务线近30%用例由研发贡献。基础类的服务100%已经接入。
3. 基础设施建设-KeDiff平台
Diff测试在大型互联网系统比较常用，所以我们调研了业内的流量回放方案后，自助研发了基于流量回放的Diff测试平台-KeDiff。
平台流量采集是通过公司的监控系统获取到线上日志，为了减少对服务影响，我们采用的是离线方式。针对日志解析后，首先在基准环境回放3次，获取到一些动态变化的噪音，比如时间戳等参数，然后分别在对比环境和基准环境回放，将请求返回的json进行对比，并去除噪音，最终输出差异报告。这就是Diff平台的实现原理。
截止目前，Diff平台承接了贝壳65个子系统，110个服务的业务，完成数2600+次回归测试，执行过1370万+条Case，测试效率提升50%。
未来，Diff平台还有三大规划；第一拓展更多协议的支持，例如Dubbo协议、Rpc协议；第二Diff报告的完善，通过代码覆盖率进行更精准的测试分析；第三Diff平台与质量中台和KeOnes系统的打通，成为QA测试中的质量卡点和更便捷的提效工具
4. 基础设施建设-虚拟城市
虚拟城市是另外一个解决产业互联网线上线下链路长，角色多，非标体系环境比较有特色的建设。
google之前有sandbox 沙盒测试的概念， 贝壳打造了一个全业务的沙盒，从数据底层，到终端业务，这个环境贯穿始终，涉及几十个系统，有超过5000+测试账号，线上巡检，验收，问题复现都可以用这个环境来验证，同时也应用在新业务，比如开城等全线上测试， 运营同学也利用该环境来宣讲、演示。
5. 基础设施建设-环境治理+数据构造
（1）环境治理
微服务架构下，环境治理也是老大难的问题：配置维护难 、扩展成本高 、环境使用乱。
我们构建了测试容器云平台，提供统一的环境治理能力，底层封装了K8S，在编译构建，配置管理，测试数据管理及环境扩展等方面有相应的支持。也在借鉴泳道的模式，有一套主干环境，每次特性修改，只拉起对应工程的环境，其他模块去连主干环境。目前接入的项目有1000+， 有效环境1600+。
首先，配置管理上，平台提供多语言类型配置标准化模板抽象方案，配合各业务方进行配置改造，平台实现一套环境内的配置模板自动实例化。
其次，环境扩展上，结合容器化技术，实现服务及外部资源无需申请，提供配置管理和服务基准库解决方案，实现环境一键复制，快速扩展，动态伸缩。
最后，在环境管理上，提供不同类型环境的使用规范和约束，统一管控，包括路由配置，环境占用，自动部署，回滚等机制。
目前全公司接入项目1000多个，有效环境套数1600多套。
（2）数据构造
长链路，多角色，非标的业务特性，让一次测试的数据构造变得比一般业务更加麻烦，海豚平台一站式提供测试所需数据的平台。通过这个平台，把所有测试同学的数据准备的经验和复杂的流程沉淀下来，让一个普通的qa，以及rd、pm都能直接使用，快速的构造出数据，使数据构造工作变得更轻松和高效。
平台的优势：
第一，是低门槛。熟悉业务的测试同学添加功能后，其他不熟悉业务的人也可以方便的造数据，他只要知道自己想要什么数据，就可以构造出来。
第二，是灵活性。平台有多种构造数据的方式，灵活组合数据配置单。并且平台有提供给外部的接口调用，用于自动化case等。
第三，是可视化。所有人构造的数据内容和执行情况、平台的使用情况的流量统计，都能一目了然。
平台的整体架构：主要的3个组成部分：环境信息部分、构造方式部分，数据生成部分。
环境信息部分，统一维护数据构造所依赖的一些基础信息；构造方式部分，支持数据构造的多种构造方式，如sql执行、dubbo请求、http请求、kafka消息、redis操作等，复杂的构造场景可能还需要这些构造方式的组合形式。
6. 基础设施建设-性能测试平台
贝壳服务端性能测试平台 KePTS 是面向贝壳服务端业务的一站式性能测试数据构造和性能测试执行的压测平台。
KePTS旨在持续简化性能测试执行的工作，让开发和测试同学可以将更多的精力回归到关注服务端性能问题本身。
KePTS的优势：
（1）数据自动化
业务压测数据的构造的有效性、真实性和快捷性，一直以来都是贝壳服务性能测试的痛点，KePTS支持从服务端日志按照定制规则筛选请求，自动构造为线上压测请求，执行压测的同学只需编辑简单的规则，就能生成压测数据用于压测。
（2）脚本自动化
KePTS底层依赖的发压能力了来自开源压测工具grinder，发压使用groovy脚本。为降低压测执行门槛，方便非JAVA背景同学快速上手，KePTS封装了多种典型的压测场景作为模板，并根据压测数据自动生成压测脚本，降低压测工具的使用门槛。
（3）灵活可扩展
压测数据节点和发压节点灵活可扩展，适合全链路级别的线上压测，赋能贝壳多个方向的核心服务端业务。
基于KePTS，服务端性能测试效率提升超30%，执行和支持了104次全链路及线上容量，支持超过300次各类线下压测和故障演练，拦截150+性能问题拦截，助力贝壳服务端性能容量类故障数的持续收敛，打造高质量的贝壳服务端中后台。
7. 基础设施建设-KeMtc
KeMTC 平台是贝壳移动端测试一站式工具平台，为贝壳移动端提供通用的自动化测试方案。
从上至下看，数据化度量是衡量KeMTC的效果和业务应用平台的程度的，主要用来指导平台解决问题的能力和平台的升级改进。
如通过发现Crash问题数量，来衡量客户端的稳定性；通过自动化case数，来衡量客户完成自动化的能力；通过云真机的使用次数，来衡量云真机的提效能力；通过平台的访问量、项目接入量，来衡量平台的认可程度。
流程提效，作为KeMTC当前的目标，主要关注当前产研过程的各个环节，部分环节可以通过KeMTC进行提效。蓝色的部分就代表，可通过KeMTC的能力，可以优化的流程环节。绿色指通过其他平台可以进行提效。KeMTC主要关注于蓝色的流程点。
App稳定性、自动化等4个专项平台是KeMTC的核心能力工具，每个工具平台又有其针对的解决问题的手段。
拓展能力和公共能力，作为核心能力的补充项。拓展能力指在开发这4个工具过程中，延伸出的非计划内的功能，可以作为未来更多工具项的切入点。公共能力是指几个工具项通用的一些功能，也是可以给其他工具可使用的功能。底层就是公司内的一些基础设施了。
以上是一站式平台一部分的能力项做的介绍，接下来会对难看见产业协同过程的平台做介绍，包括对它的应用也重点讲讲CI / CD的部分。
8. 规则-产研协同平台-Ke Ones
中间是CI / CD流水线的建设，下面是数据AI，从需求、测试、线上目标，CICD流水线分四五个阶段，拆分出来几十个环节，为什么要做KeOnes这件事？
首先是协同方式不同，有时不停开站会，对质量来说，过程质量损失特别多，信息传递会失真，所以我们统一搬到了线上，对CI / CD也重新做了标准化的建设。
需求阶段项目迭代、需求做了管理，研发阶段会支持CR、环境搭建、测试准入，测试阶段会做自动化测试、专项测试，发布阶段之前发布也有多个系统，把它统一到一个发布系统，为这个发布系统导入各项能力。
比如怎么去做发布、健康度检查，如何预发、销售量、全量。线上运营跟线上监控打通，这是CI / CD的流水线，他的各种能力项跟它是深度结合的，包括性能测试等等跟它也有深度的结合。
CI / CD内部也有个迎合项目，从需求、创建、拉一个分支、合并、发布上线各个环节拆分开都出流水线，每个动作都自动验证，分支拉出来跑一些Case，从中间到要发布上线人工卡点完成后又在另外环境跑，就是把结果反馈快速回馈出来。
比如每次构建会在统一在一个群里，失败也会及时发出通知，群里每天可以看到多少分支创建、拉取，构建有没有问题，是不是可以通过。
规则是代码扫描、自定义的规则进行检查，包括第三方的业务上的规则，都可以里面去检查，也应用了Diff等等各方面的能力项。
9. 质量意识标准建设-贝壳质量指标1.0发布
质量意识非常重要，带着质量意识去做贝壳产业全流程的规范。质量部会对CTO线各个研发产品进行考试，就在一年前，所有的人参加了考试，如何写需求、提测、线上出现故障5分钟之内应该做什么、第一时间如何止损，然后再做什么？一切变成标准化的动作宣布、宣贯、考试，经过考试也方便了产业协同平台不用面对非标业务的场景。
中间是贝壳发布的质量指标白皮书，定义了如何看全环节的质量，各个环节指标究竟要看哪些，这个指标也会跟各个团队的研发对齐。
未来会形成贝壳分，对每个组织和个人通过指标去给评分和评价，全面质量管理的细节，清楚交付质量、构成质量、发布和运营质量，目前非常关注故障和5分钟定位问题的占比和需求变更等。
质量意识建设上也有双环驱动，一部分驱动团队、一部分驱动个人、团队会对其进行质量诊断，由QA对双周的各种质量做诊断，数据是怎么样的、有什么风险、实时的告诉大家，也会展开多种质量活动。
比如去扫描谁改得最多、单测自测怎么样，也会发质量认证。个人会被分配一些质量任务，这些任务完成得好会有质量积分，目前已经开始在启动这件事，找Bug、对ADC进行培训，双环联动，对员工有一些激励和认证和荣誉晋升的加分。
贝壳也做了千人众测，海外版要发行的时候，公司很多人参与众测，线下经纪人、线上法务、财务都参与，也跟研发团队中心一起启动，如果自测得好会颁发自测证书和奖牌，也有一些相关活动，通过各种质量活动提升用户体验和线上系统稳定性形成产业意识关注质量。
故障治理是贝壳里很有特色的地方，有一个一两千人的贝壳消防团队，贝壳发生故障时，消防队第一时间会看到，信息传达非常快，这建立了对线上故障问题处理响应的操作机制，是贝壳的特色，贯彻得很彻底，另外是对故障的定级抓得非常的严格，会让质量的保障得到重视。
四、贝壳质量保障体系未来发展
前面介绍了KeOnes、质量意识提升和工具平台的细节，这部分讲讲保障体系未来的发展。前面做过总结，经过这一年多的建设，从19年的测试研发1：5提升到了1：9.2，故障率下降了74%，SLA达到4个9，吞吐量增长142%。
未来会做些什么？首先是智能化测试，包括做用于自动生成图像的自动化识别，未来更多的去往智能化应用做优化或者是AI、机器学习等方面。
混沌工程也会加强，QA会做故障演练预案，跟研发团队一起做一些提高，看熔断、降级是否足够好，够不够快速，未来也会体系化这件事。
第三部分是Devops升级，借助一些平台上的工作机制来做，目前做了一部分，让线上化之后也有数据，各种指标都可以看到，未来会对devops成熟度去做更精细化的认证管理等。
五、Q & A
Q：出现故障贝壳如何追责、如何防止甩锅？
A：出现故障贝壳怎么追责，这个问题问得特别好，透明真实是第一要素，当故障出来的时候在群的「消防队」立即会爆发出来。我们对QA要求是如果有问题、故障异常等第一时间在大群里面暴露，暴露完了以后，把发生的进度情况在里面透明化。如何防止甩锅，故障谁都不愿意看到，大家相互甩锅是因为觉得故障不好，不希望它发生在自己身上。但是有时不这样，有架构师说，每个故障都是像金子一般宝贵。QA、RD或者不相关架构师，甚至有故障专家组会很真实剖析问题本身，找到根因，理解透彻后和大家对齐，不会因为故障就惩罚，不会有通报批评。
Q：系统发布会自动更新配置库吗？
A：在发布时我们也有变更的流程，不管是一次代码变更、配置变更、数据库变更都会通过一个线上平台发布出去。配置库是不是可以管理起来是吗？这是线上化管理起来的，有一些配置平台去负责，坦率的说我们的配置的平台也有在收敛，我们做太多了，在配置平台比较多的情况下，整个微服务里面在配置中心来做，有些是业务封装是业务线上的平台，所有这些都是可以追溯的。
Q：质量监控体系如何建立？
A：监控有多种监控，前端监控研发团队也有灯塔、海神，QA也有自动化运维，偏业务的监控线上跑。端上有QA的自动化，后端搜集各个服务，服务也有监控、日志也会搜集，查看日志的异常，流量监控检测各种反馈码、定制监控指标，测试的阶段自动化能力通过持续集成跑、自动去跑，有问题可以及时告警出来。
Q：混沌工程什么时候开始，实现效果怎么样？
A：混沌工程刚刚起步，前面也没有真正做，可能会结合研发运维，在低峰时段比如凌晨考虑哪些服务要启动其降级熔断，在上游做一些内容看所有团队对这个响应是不是足够快、是不是工具化的，甚至可以不用消防队资源，但目前还不算特别的成熟的建设，下一次腾讯云分享会对细节做介绍了，争取做得更好。
Q：质量意识建设应该从哪入手？贝壳现在取得了哪些成效？
A：质量意识的建设需要自上而下，需要有团队的氛围。我刚CTO面试的时候谈到百度工程师文化、谷歌工程师文化，好的工程师文化下的质量意识一定是天然好的，如果不是那就需要有很多手段，比如刚来的时候不停普及质量三段论，要参加考试，做完之后85分以上才是通过，甚至要求高层也参与考试，所以入手应该是自上而下的形成团队氛围。
Q：贝壳取得哪些成效？
A：一直在做，成效是故障变少了一些，前面也说了四个9，如果一个研发工程师能够关注到他的代码扫描出来的结果，主动进行修改；如果一次发布是 R D自己能够看到 Ke Ones 各种数据，可以点按纽发出去，这个团队质量已经很强的、文化也很好，我们有很多业务团队研发会写自动化的case，会主动贡献，甚至有时候排名在有些QA排名之上，这是长期活动让其有了这种意识。
Q：混沌工程实现自动化和智能化在贝壳有规划吗，实现难点和关键点有哪些？
A：混沌工程和做的各项Diff、引流，它的实现难点都是不是在质量本身，而在于整个研发体系IT生态是怎样的，监控是不是足够好，对线上的服务运维调度是不是足够的牢固很关键，如果连线上发生的情况都不知道，也无法做降级熔断，我们如果去做混沌工程就是不停埋炸弹，这肯定是不行的，IT生态里面微服务的架构，各方面组件使用得是否规范，关键点是突破这些基础设施。
智能化是有规划的，在移动端的自动化的时候，对图像的识别包括未来做Diff也用一部分的AI，也是开源的，智能化应用场景非常多，包括Diff如何筛选线上流量，流量跟最后运行的代码关系如何关系得上，性能如何自动识别性能优先，这次性能是否通过，也有很多应用场景我们是有规划的我们也在招人。
Q：选择 jenkins 而不选择其他的 如 k8s等的原因是什么？
A：选择jenkins是历史上就用得比较多，持续集成做得比较好的还是jenkins。
k8s是容器化的集成平台，上层的应用平台，包括也有团队最开始没有 k8s，直接用原生的去做事，但是后面逐渐统一。前几年也用docker做环境隔离，其实用docker做事情也依赖于基础架构、IT生态，做容器化需要找好路由关系，这些解决得好就好推进，做路由的时候用各种服务目录，把每个分组做好，标签对应就比较容易。
Q：虚拟城市是不是可以替换预发布环境？
A：虚拟城市没有准备替换预发布环境，虚拟城市有各种用途，预发布各个模块之间也有预发布，虚拟城市是完全从B端、C端到后端完全的打通，线下和线上的应用都非常的成熟，各个业务线、各个模块预发布，比较封闭的环境都无法这样做，所以不能去替换，虽然预发布虚拟城市可以用来做演示，但他们的关系不是完全的一样的，所以没有准备做替换。
Q：贝壳质量部的文化建设是如何进行的，目前还在招聘哪方面的人才，期待加入？
A：这个问题太好了，我们贝壳质量部成立一年多，文化建设非常好，我们有很多活动：去年质量部的活动是去做飞盘，两人三组，包了一个体育场去PK，分了二十个组，各个组PK，大家玩得高兴，组队玩王者荣耀，也有篮球社区，也可以组队踢足球。
我们内部也有微信群，天天斗图和聊天，最近这一年斗图少了一些，因为特别忙，忙也是因为缺少同学、缺各大牛。我们招聘岗位是各方面都是有的，前面提到的混沌工程智能化开发同学就很需要，针对移动端、服务端偏业务，包括对各种质量解决方案特别有理解的同学我们也很需要，把建设持续交付经验可以推动业务团队做变化的这种同学我们也需要，工作两三年的同学想在一个比较不错的组织里面去进行职业生涯成长，贝壳质量部就是很不错的团队，可以帮助做各项提升，我们对P4、P5、P8、P9的同学有不同项目去一起成长，高阶的管理岗位也在招聘，所以岗位非常充分，欢迎大家投递简历，邮箱地址：xiangxu003@ke.com.
