阅读 2227

第二届搞基建|芋头 - 如何在大前端团队实现基建价值突破

下期预告

前端早早聊大会目标成为用得上、听得懂、抄得走的技术大会,计划 2020 年办 >= 15 期,由前端早早聊与掘金联合举办,前端早早聊大会行程动态、录播视频/PPT/讲稿资料下载请关注 「前端早早聊」 公众号跟进。

你的支持,是早早聊办下去的唯一动力!

还想听哪方面的分享,直接加 Scott 微信: codingdreamer 提需求吧!


第十三届|前端搞构建专场,8-15 即将直播,9 位讲师(宋小菜|百度|政采云|腾讯|天猫精灵|蚂蚁|淘宝),👉报名地址


本文是第四场讲师 - 芋头的讲稿文字版,来看看他是如何讲的,视频及 PPT 未来在公众号放出。

第一部分 个人和团队介绍

个人介绍

  • 大搜车资深技术专家
  • 大无线相关架构、创新团队管理
  • 从业 10 年,做过和带过前端、客户端、服务端
  • 热爱分享,活跃于技术社区
  • 没梦想,有活干就很开心了

团队介绍

  • 300 左右无线相关开发人员
  • 整体创新和沉淀意识在集团内也是非常突出的
  • 综合型团队较多,上升空间大
  • 从 17 年开始就成立几十人的无线基础设施团队
  • 前端、客户端、Node.js 领域均有较为成熟的基础沉淀

个人和团队职责变化历程

公司 13 年开始组建开发团队不久之后我就加入了,最开始负责公司的前端开发相关事宜,因为我以前就是在天猫做前端的。不过虽然主业是前端,但是我当时一直觉得自己应该是要走全栈道路的,首先因为开发完整的应用,肯定不止是前端一个角色的事情,另外就是前端的生态当时已经开始显露出边界扩展的苗头,特别是 Node.js 的火热,所以在团队还没有引入过多技术栈和做过多沉淀的时候,我自己率先去做了这方面的沉淀,具体就是花了大量的时间去学习和实践 Node.js 开发,而且是奔着完成完整的产品的前后端开发去的,虽然最后没有说对 Node.js 的底层挖掘有多深入,但是的确让团队具备了初步的使用 Node.js 做开发的条件。当时在公司刚启动的过程中,分工不是特别明确,还自学并做过一段时间的 Java 开发,这个经历对我来说也是很重要的,这些都是团队后来扩展价值边界的基础,所以探讨基础设施建设,为长远沉淀的思路是贯穿始终的,是一切的基础。

从这张路线图来看,其中最重要的几个拐点:

  • 开始有意识的沉淀
  • 开始用 Node.js 做业务
  • 开始做数据可视化业务
  • 开始整合客户端开发
  • Node.js 下沉基础服务
  • 架构常态化、体系化
  • 集团业务多样性,团队分散
  • 基础设施体系化、产品化、边界拓展
  • 综合型团队

最终团队的沉淀和发展,一个是这个过程中的契机决定的,一个是公司业务发展状况决定的,一个是自我沉淀的意识决定的,同时也是团队积累的方法论决定的。

这里我们不展开其他话题了,主要是这些过程,大家可以参考,可以拿去映射自己的公司,自己的团队,用以说服老板,为老板提供思路等。

现在团队大体的情况

我们团队的组织架构其实一直在演化,有时候可能半年两次的调整频率,背后也是有一些原因在里面的,这个等会儿会有专门的探讨,这里是我们过年之前大体的组织组成,其实可能 2 周后就不是这样了,最近我又有一些新的思路,可能变化会很大。

首先,我负责的团队是偏基础设施输出的,但是又不是那么绝对,为什么会是这样的组织结构呢?是多种原因造成的,一个是团队在做技术设施过程中,尝试直接影响业务,最终做的一些创新的方向,演变成了创新平台(类似于创新实验室的定位,通过技术挖掘直接改变业务进程),另外一部分是纯粹的架构是很难稳定的独立存在的,所以基础设施团队在到达一定阶段之后,需要和业务有一些交叉的边界,特别是前端领域,千万不能一条绳子上栓死,不管做什么最终衡量价值一定是对业务、商业的影响,在前期,团队和业务爆炸增加,很多架构上的问题需要专人解决,一旦解决可以大幅提效,但是当核心痛点得到解决之后,打磨和挖掘是需要的,但是如果大量人力还是耗在一些需要做但是不紧急的事情上,价值会慢慢削弱,所以,作为布局的人,需要认清这方面的事实。

目前来看,我们团队现在的整体组织架构是比较健康的:

  • 基础设施,这部分已经比较成熟,更多是标准化、打磨、产品化。
  • 基础服务,Node.js 的练兵场,也是直接影响业务的前沿阵地,当然一些小的基础服务也很成熟了,大的基础服务,还需要服务公司云平台、PaaS 平台的建设输出,这是具有长远价值,而且很深刻的事情。
  • 创新实验室,高精尖,探索业务最前沿,利用基础沉淀大幅提升业务能力,也是团队边界探索的前沿阵地。
  • 业务团队,前后端一体团队,一个是利用基础设施更快的孵化业务,一个是成为基础设施的试炼场,双赢,同时也是团队承担更多责任的突破口。

第二部分 核心基建介绍

本节,我会简单罗列一下我们的基建覆盖场景,因为内容太多,所以没有把内容展开,也没有讲某个领域我们具体做了什么,我会适当展开一下,大家感兴趣可以会后找我,或者只是把这个当做一个目录参考。

对于我们做过的基建,我也简单的做了一下分类:

  • 应该有的:最基本的,必备的,行业常见的,完整的,专人负责的,到了某个阶段必须要有的基础设施。
  • 日常沉淀:可以没有,但是有了可以在某个领域提效的,通过长时间有意识积累出来的,偏最佳实践的基础设施。
  • 影响生存的:做不好,这个领域就混不下去的,例如 Node.js 基建。
  • 创新探索的:端的领域拓展,全栈领域拓展,创新价值探索的,往往是一些看起来可有可无,但是可以给业务带来巨大想象力的事情。
  • 产品化探索:慢慢将基础设施产品化,而不是纯粹是技术方面的输出。

具体内容,这里不展开了,这个章节还是希望能够提供一个索引目录,当大家没有思路的时候,可以从这里面寻找一下是否有可参考价值的内容。

另外,在这些目录之外,简单总结下经验:

  • 从日常痛点中挖掘基建内容
    • 时刻抱有沉淀意识,不管是大到大型系统,还是小到一个方法,时刻考虑提效、复用、可维护
    • 培养有以上意识的人,给予足够空间和引导
  • 主动挖掘业务痛点
    • 不要等待别人指派任务,经常停下来看看业务上、商业上、产品上,有没有通过技术手段可以高效解决的问题,例如偏创新的沉淀,业务不敢想或者想不到,我们站在他们的角度去想想
  • 适当时机打造正规军
    • 正规军需要有正确的职责定义,需要自我挖掘和解决问题,强调产品思维,团队价值可感知
  • 边界试探
    • 行政上,向上说服,或者是技术上,不断打破边界是非常必要的,最基本的,不要给自己设界

第三部分 典型项目简介

除了提供以上的目录索引之外,虽然鉴于时间有限,不能针对某些内容展开详情,如果是这样,可能每个事情都可以讲 1 个小时,但是又想既然提到这些内容,还是应该简单展开几个内容,表面介绍一下,可能会给听的同学带来一点更具体的价值,所以这一章节,我想简单介绍下几个事情的大体解决思路或者方案,正好关注某一块事情的同学可以借鉴或者探讨。

移动标准容器和移动平台

现在很多互联网公司的业务都是基于移动端开展的,所以移动端的基础设施是很重要的,而移动端的发展趋势,整体又是在向跨端开发的方向演进,不管是 H5,还是 RN,还是现在流行的 Flutter,我们把这类业务运行的环境成为“容器”,容器和容器之间偏向于独立,每个容器是一个业务单元或者一个运行环境,之间通过路由调度,另外也通过路由可以和 Native 原有的生态互相调度,可以说“容器”是承载移动端业务最核心的部分,其他基础设施要么隐藏其后,要么直接和它关联,容器是业务和基础设施之间互通的唯一出口。

针对容器这块,初期我们做了大量的工作,把公司大部分移动端业务都从 Native 开发转移到 H5 和 RN 的技术栈上,其实使用 H5 和 RN 本身并没有太高的技术壁垒,只是把问题放到场景里就会变得复杂,团队的构成,业务的性质和量,组织架构,都会带来很多问题需要解决,而作为基础设施的开发,需要不断去平衡和解决这其中出现的问题,克服重重困难把方案落地,最终解决根本的痛点。

这个问题,在做 RN 落地的时候,体会最为明显,大概讲一下落地 RN 需要考虑的问题:

  • 团队构成,移动端相关业务,客户端居多
  • 业务性质,偏 B 端,业务线多,短期内指数级增长
  • 组织架构,业务线之间关系比较独立
  • 技术问题,平台差异仍然存在,性能和体积等

针对这些问题需要做的解决方案:

  • 面向 Native 开发友好,不需要花大量时间学习 React,甚至 JS,不需要花时间了解 RN 固有的一些机制和问题
  • 面向传统流程友好,开发、部署、联调、提测、发布、更新,原有 APP 的流程习惯尽量不破坏,否则需要改变一大批人的工作习惯
  • 业务粒度控制,业务单元隔离
  • 平台差异抹平,业务变薄,基础变厚,牺牲灵活性,带来标准化等

最终我们对 H5 和 RN 开发的诸多赋能慢慢演化成这些部分。

关于整个移动端开发,除了容器和业务开发比较紧密之外,其实我们的输出是更大的一个整体,这个整体的价值输出,可能不限于开发上的提效,还包含一些产品层面的沉淀,甚至是商业上的沉淀。

移动平台分几个阶段?

  • 第一阶段,偏工程层面,开发标准化,运行环境标准化,平台基础能力标准化
  • 第二阶段,偏产品层面,与业务无关的能力标准化平台化,赋能快速搭建(不止是开发层面)新的业务 APP
  • 第三阶段,偏业务层面,赋能内部 APP 业务层面平台化,应用互通
  • 第四阶段,偏行业层面,平台化 APP 的能力对行业开放,另外助力生态公司快速搭建自己的 APP

这几个阶段不一定是递进,有交合,也要有孵化沉淀的意识,有些事情从现在可能就要考虑未来的形态。

具体可以做哪些事情?我认为核心两个方面:

  • 第一个方面,移动架构的基础沉淀,意义:集团所有业务线 基础复用、H5/RN 跨业务迁移复用、高效标准的工程能力。赋予这些意义的能力,包含:

    • 基础的运行环境(容器/路由/公共组件等)
    • 业务开发提效设施(开发脚手架/持续集成/发布更新)
    • 配套的基本的开发系统(托管/日志/报警)
  • 第二个方面,快速低成本搭建或完善 APP 的能力,于内部、子公司、生态公司、行业公司。赋予这些意义的能力,包含:

    • 开发基础设施层面的快速搭建(包含第一个方面的所有能力)
    • 产品层面的快速搭建(消息中心、闪屏、更新、客服、IM、扫一扫、摇一摇,数据等)
    • 业务层面的快速搭建(业务单元化后在 APP 间无缝迁移,外部业务快速集成等能力)

持续构建和持续部署

接下去介绍下我们再持续集成方面做的尝试,严格来说,我们提供的不是持续集成的流程最佳实践(团队太多,整个流程不急着标准化),而是持续构建和部署的能力。

这里面的复杂度主要是:

  • 技术栈很多,Vue、React、React Native、iOS、Android、小程序、Node.js。
    • 上层抹平技术栈
  • 业务线和项目很多,前端项目接近 1000 个,RN 项目接近 300 个
    • 打包资源要保证
    • 构建部署方式需要标准化、集中化

最终,我们把所有无线的技术栈的集成流程做了抽象,每个技术栈的脚手架来适配,例如:

  • 环境抽象(测试/稳定/预发等)
  • 动作抽象(创建/打包/部署等)

然后把所有这些抽象到一个集中的服务中,提供出 PaaS 服务,上层只需要告诉我项目是什么技术栈,需要做什么动作,其他就可以不关心了,当然我们也有默认的上层最佳实践实现,但是业务也可以自己构建上层的持续集成流程。针对集中打包部署的性能问题,引入 tekton 集群流水线处理任务。

这里,其实我们提供的不是一个持续集成的基础设施,而是持续集成更底层的抽象沉淀,未来它可以适应业务各个阶段不同的诉求,属于基建底层的基建。

Node.js 框架生态

每个前端团队都应该关注一下团队在 Node.js 方面的积累和沉淀,Node.js 在我们团队现在发挥着各种各样的作用,其中很多领域不是一天两天的沉淀可以做到的。

例如:

  • 前端生态本身,脚手架、持续集成中的各种服务、资源管理、开发用的服务等,脱不开 Node.js 。
  • 创新应用的探索,不管是偏技术的,还是偏产品的,要完成一个完整价值的输出,服务端总是脱不开的,有了 Node.js 沉淀,任何应用都可以你们自己团队内部孵化,而不需要依赖外部共建。
  • 业务开发或者服务开发,模糊大前端团队边界,公司大了,职位高了,职责会越来越要求综合,你的职责就是解决问题,而不是解决前端问题。

为了做到这些,我们在 Node.js 探索的过程中,一直在刻意沉淀:

  • 早期,在团队内探索,前端生态的,甚至是一些小功能尝试 Node.js 实现。
  • 后来,Node.js 尝试做独立业务,过程沉淀一些最最基础的 SDK 和最佳实践,例如配置管理,异步任务、一些常见库的选型固定等。
  • 后来,Node.js 尝试做底层服务,稳定性和性能要求等加深,慢慢在社区框架上固定选型,上层封装脚手架、配置管理、接口管理、文档管理等。
  • 后来,更进一步模糊和 Java 生态相比的弱势和差异,Dubbo 接入,全链路接入,消息队列,异步任务等完全和 Java 打通(而不是重新造轮子),这个阶段结束时,做技术选型,技术栈的差异已经不成理由。

正是有这些基建,保证了 Node.js 生态的发展,同时间接促进了团队承担更多的责任。

组件库和功能库

最后,分享下比较基础的组件库沉淀吧,这部分沉淀是比较基础的,也是早期做了之后发挥价值比较大的部分,主要分为两部分,UI 组件库和功能组件库。

UI 组件库,我们全部都是自建,当然我并不推荐硬造轮子,自建的主要原因还是配合公司自己的设计规范去做落地,过程中我们也会直接借鉴一些社区组件库的设计来实现,同时,在建设过程中,面向集团内跨业务的一些诉求,我们在所有组件库之上做了一个统一的主题色管理机制,配合 APP 还可以自动切换主题,另外就是做了一些业务组件管理的能力,抛开最基本的 UI 组件,一起共建有一些业务特点的业务组件。

在功能组件方面,更多是来自于业务的沉淀,例如 分享库,整合所有平台的分享能力,然后内置一些分享鉴权的实现等,最终暴露给业务,是一个简单配置即可拥有强大功能的库,基本可以解决公司所有业务的分享相关问题。类似的组件还有很多。

另外,针对组件库和功能库,早期可以投入专门的人力去开发,但是后续维护,需要慢慢向共建转变,这个也是我们的一个经验教训,之前有开发伙伴一直专门负责组件库的开发和维护,投入产出比随着时间推移,会慢慢降低。

创新平台

从 18 年底开始,我就一直在想“端”这个词的另一层含义,前端、客户端、服务端,我们都趟过,但是这还不是全部,我当时就在想“端”可以有更多机会和价值,放眼到行业里,云端、设备端等概念都如雨后春笋般冒出,映射到公司内,技术上、业务上,都有可以匹配的点,所以后来就下定决心,团队边界一定要向设备端这个领域延伸,当然真正的延伸是需要业务上的突破口的,脱离开业务去做物联网去做设备控制意义不大。

后来随着公司业务发展,19 年初的时候,我们敏锐的发现不少新业务想要尝试新颖的销售和营销方式,其中涉及到很多设备的场景,于是我们顺着这些场景去挖掘(甚至比业务看的更超前),慢慢帮助业务实现目标,另外也在设计实现的时候刻意分层,思考未来底层的沉淀和更多场景的赋能。所以后来就有了 SoucheOS 和 Souche IoT 最最基本的基础设施,把设备能力和远程控制能力做了去业务场景的抽象,有了这些能力,我们可以快速在上层适配各种业务场景,并且顺便把集团内的办公设备在线化、测试机在线等支持了。另外这块还有对一些社交软件的控制能力,这个也是基于设备底层能力的挖掘,配合设备平台,可以轻松实现远程和群控。

第四部分 组织架构的探索

分享完了一些具体的内容,接下去想和大家探讨下在基建过程中的其他演化和思考,首当其冲的是组织架构的变化,平常大家都会讲,技术不分优劣,更重要的是看场景。组织架构就是场景之一,不同的组织架构下可能需要不同的做事思路,也会产生对基建的不同诉求。不过同时,为了做好基建,也需要不断调整组织架构。这里的组织架构可能更多是一内一外,上层组织架构决定了要做什么事情要怎么做事情,而为了做好事情,需要不断调整优化内部组织架构。

内部组织架构调整重点的考量:

  • 基建重点是不断转移的,伴随组织架构的调整
  • 基于技术栈组织,还是基于项目输出组织,看阶段,看团队
  • 纯粹的驱动力人才培养
  • 业务和基建,创新和基础,相辅相成

第五部分 项目管理的探索

基建项目的管理,从来不是一件容易事,这有多方面影响:

  • 角色单一,不像正常项目一样有做规划的、做项管的、做质量的、做销售的,在基建项目里,可能都是一个人
  • 开发人员容易纠结于技术本身,忽略沟通、管理、可控等环节的重要性
  • 技术项目复杂度较高,如何群策群力,同时又能正确一致地决策

所以,我们发现项目管理的几个重点:

  • 如何立项一个有价值的项目
  • 如何推动项目最终实现交付
  • 如何将项目推向你的目标场景和用户,产生最终的价值

在我们团队,做过很多尝试,这里只把一些可能有参考价值的方法介绍一下:

立项

立项包含多个层面,例如方向的确立,项目的确立,迭代的确立。

  • 长远规划
    • 对于方向的确立,例如在做设备平台之前,我们是有对这个事情的想象和探讨的,对我个人来说,偶尔会停下来,排除干扰,思考一下一些大方向的可能性,这些思考会站在一些假设之上,例如我们未来业务会向什么方向倾斜,所以我们未来可能会有个什么平台,最完美状态是什么样的,如何在业务中发挥极大价值,不过这些想象可能永远都达不到,但是价值是可以不断分层和降级的,想的足够远,但是也要分解成阶段回到当下。在我思路比较活跃的时候,我会把这些想法写成“长远规划”,然后讲给团队里的骨干听,探讨一下,或者同步下站在比较高的角度对这些事情的想象,如果你认同,可以参考,把事情一步一步做成,如果不认同,可以发表你的想法

举几个之前长远思考过的几个方向:

  • 开放平台服务 -> 开放平台产品 -> 云平台工作窗口 -> PaaS ISV 工作窗口 -> 服务场景管理编排 -> 移动开放平台等,我们做的当然还远远不够,未来要做什么,可以参考的方向很多。
  • 移动端基础设施->运营平台-> PaaS 开发平台,赋能内部、集团、行业,mPaaS 是可参考的标品。
  • 等等,通常这些思考,会参考行业产品,考察业务、商业上的发展等
  • 调研报告
    • 长远规划可能更偏向理想情况,真正要开始一个项目,需要做更为细致的分析,确保接下去投入的资源是有价值、可持续的
    • 这些事情,其实有点类似于产品经理需要做的事情,做用户调研,需求调研,或者是自己分析出来的痛点,但是在整理想法后,也是需要和对应的业务方勾兑交流,修正思路

这里,其实最好能引入一些产品方法论,例如“用户故事”,需求分析文档,从不同类型的用户的角度,开始分析背景、问题、思路、方案、改进后的用户路径、感受等。我一直想跟大家强调,做技术设施,一定要锻炼自己的产品分析能力,因为没有人会帮你去分析整个事情的来龙去脉,需要靠自己去挖掘方向和需求,如果你还是一直等待需求的出现,那你是走不远的。

  • 可行性方案
    • 最终,在确定一个项目之前,需要有书面可行性方案,并且组织参与者和相关者对可行性方案进行评审,并做修正

不过这些流程都不是绝对的,看项目类型可以适当调整,并不是绝对的所有项目都要经过最细致的流程,有时候,过于细致的流程,虽然可以保证事情的可控,但是也会拖慢进展,有些技术项目,反而是越快越好,需要快速试错,这其中平衡,还需不断调整。

推进

基建项目,如果是一个人或者一带一,推进问题可能还不大,但是通常很多会涉及到跨技术栈角色的合作,甚至是跨团队的合作,要保证这样的项目更好地落地,还是需要较为规范的项目管理方式的,其实这里和普通的业务项目没有太大的差别,技术方案评审,排期,接口文档等。

这里提到架构设计,不过说实话,一个系统刚开始的时候,很难给出完整的 C4 架构设计,这里提到的 C4 架构设计,更多是在项目迭代过程中,逐渐梳理细化出来的,用以向外同步信息和内部参考迭代。

另外,一个比较重要的点,是里程碑的分解和制定,基建项目通常体量不可控,如果一开始就设计了一个庞大的完整的方案,交付时间几个月,这时候就要想想里面是不是充满了不可控的风险,这几个月任何事情都可能发生,业务诉求、组织架构、人员变动,所以一定要把目标分解里程碑,每个里程碑有个阶段的产出,注意这里的里程碑不是把一个长的任务直接切开几份变成短的任务,而是每个里程碑你交付的可能都是一个最小可用的整体,早期尽快成型,后期迭代优化增加新特性,要养成分解达成的习惯,而不是一蹴而就。

运营

技术运营也是基建的一个逃不开的比较磨人的话题,特别是对于大一点的团队来说,基建的落地是需要自己去主动推动推广的,对基建的输出的要求不是做个库做个框架这么简单,而是输出一个产品,你需要准备资料,讲清楚来龙去脉,讲清楚你的理解,讲清楚你的优势,建清楚如何使用,形式可能各种各样,文档当然是必备的,白皮书也是需要的(文档更多是介绍如何使用,白皮书是告诉别人为啥要用),分享是基本的但不一定是有效的,工作坊是更有效但是成本较高的,需要自己平衡和探索。另外就是技术运营要是持续性的,而不是一次了事,事不关己高高挂起爱用不用。

下图里我们给团队的产品甚至都订做了文化衫,去强化大家对基建产品的了解

第六部分 其他经验总结

通过刚才讲的一些内容,我们简单总结一下。

要做好基建,较为核心的点:

  • 组织架构保障。不管是最初的先行小组,还是后来专门的基建团队培养,Leader 要做好组织上的保障,为基建争取空间
  • 项目管理推进保障。架构项目的特殊性,需要有方式解决推进管理,确保结果落地
  • 沉淀意识。Leader 自己要非常敏感,同时挖掘培养有沉淀意识的同学,沉淀都是来自于日常工作
  • 贴近业务价值。不要脱离场景造轮子,无法发挥价值,也得不到上下级的认可。

另外,一些细节的注意点:

  • 不要给自己和别人挖坑

    • 不要盲目扩展团队技术栈
    • 完整的开发过程和使用文档
    • 切忌假大空,上来就规划一个平台,最终只有一个烂摊子
    • 适当尝试,适当投入,但也要对风险合理评估,并有规避方案
    • 想的可以尽量远,但是要回到当下根据实际情况分解节奏
  • 但是也要适当造轮子

    • 适合自己的实现,按照自己的路径迭代
    • 磨炼团队技术能力,增加对技术细节的深入,为未来做沉淀
    • 系统思维其实很难养成,需要场景
    • 需要平衡,资源、风险、投入产出比、可持续性,对自己的团队要有一个正确的认知
  • 注重系统思维

    • 学会自己做决策和负责任,而不是执行任务,或者完成交代
    • 更透彻的理解一个问题
      • 不断追问自己为什么要做一个事情
      • 理解的起因是否也是基于某个结论
      • 例如:我要做 xx,因为 xx 业务说他们需要 xxx
      • 为什么要这样做
    • 层次感,规划、系统架构、价值体现方面,随时解耦重组
  • 切忌半途而废

    • 逼自己挖掘深度价值
    • 当然也不要盲目挖掘,确保大方向是对的
    • 慢慢系统化、产品化、尝试打通任督二脉
    • 切忌浮于表面,蜻蜓点水
  • 克服孤独感

    • 热爱、相信、投入、开放
    • 主人翁意识,为输出及其价值负责和决策

第七部分 今日分享总结

最后,大家有问题,可以加我微信探讨,或者在行上约我面聊,感谢大家。

第三期 2020.3.28 在线上直播,主题 「前端搞搭建」,扫码关注「前端早早聊」公众号参与报名: