基础设施工程的演进与边界手工/自动化/平台化运维/研发SRE/Infra文章目录基础设施工程的演进与边界手工/自动化/平台化运维/研发SRE/Infra一、手工 → 自动化脚本 → 平台工程1. 手工运维先把事情做完2. 自动化脚本让重复工作可复现3. 平台工程把能力交给使用者二、传统分工研发与运维1. 传统模式的分工2. DevOps 改变了什么三、现代分工Infra、SRE 和平台工程1. Infra建设并维护底座2. SRE用工程方法经营可靠性3. 平台工程把底层能力交付给研发四、实践从职责边界到工程落地1. 按责任边界协作2. 让能力可交付并长期运营一个可落地的实践GPU 节点扩容从一次交付到长期运营3. 沉淀知识并识别工作方向1. 概念知识2. 架构知识3. 操作知识4. 决策知识结语从做事情到建设做事情的系统基础设施工作经常同时涉及运维、研发、自动化、SRE、Infra 和平台工程。它们既不是完全互斥的岗位也不一定代表严格的先后阶段而是在不同层面描述同一个问题如何把底层资源和复杂系统稳定、可重复、可恢复地交付给使用者。可以从三个方向来理解这套体系能力形态手工 → 自动化脚本 → 平台工程传统分工研发负责开发运维负责运行现代分工研发、Infra、SRE 和平台团队共同承担系统生命周期中的不同责任。最终要完成的转变是从亲自“做事情”走向建设一个能够稳定完成事情的系统。一、手工 → 自动化脚本 → 平台工程1. 手工运维先把事情做完在早期基础设施工作往往依靠熟悉环境的人凭经验处理扩容一台机器部署一套 Kubernetes接入一批 GPU配置一次告警处理 DNS、网络或硬件故障。典型过程通常是需求来了 → 找熟悉系统的人 → 查文档和历史记录 → 手工执行命令 → 观察日志 → 人工判断结果 → 协调后续操作 → 补充记录这种方式通常有几个明显特征依赖个人经验容易遗漏步骤过程难以复现故障处理依赖少数专家系统知识存在人的脑子里。手工操作并非没有价值。面对低频、探索性或高度不确定的问题人工判断仍然必要但当同类工作不断重复就应当把其中稳定的部分标准化、自动化。2. 自动化脚本让重复工作可复现Shell、Ansible、Terraform、Helm 和 CI/CD 等工具可以将重复操作固化为脚本或流程。例如扩容 GPU 节点可以由脚本完成创建云资源 → 初始化节点 → 安装驱动 → 加入 Kubernetes → 配置监控脚本比手工执行更高效也更容易保持一致。但“有脚本”不等于“自动化已经成熟”。如果参数仍靠人工准备环境仍靠人工判断失败仍靠人工盯日志结果还要事后补录那么它更多只是操作提效并没有形成完整能力。一个可长期运行的自动化流程至少要处理参数校验幂等执行明确输入和输出超时和重试失败处理回滚策略日志和审计执行结果验证。自动化的重点不是把几条命令拼成脚本而是把一项完整工作变成可重复、可验证、可恢复的流程。3. 平台工程把能力交给使用者当自动化流程逐渐增多团队通常会继续向平台化演进。用户不必直接操作 Terraform、Ansible 或 Kubernetes而是通过页面、API 或 CLI 提交目标云厂商某云 地域某地域 集群训练集群 GPUA100 数量8 张平台在后台负责完成资源申请 → 权限和配额校验 → 资源创建 → 节点初始化 → 加入集群 → GPU、网络、存储验收 → 监控接入 → 资源登记 → 通知用户平台工程的本质是把复杂的基础设施能力封装成研发团队能够理解、调用和反馈的产品。它关注的不只是“能不能执行”还包括谁可以申请是否需要审批任务当前处于什么状态失败后是否可以重试是否支持取消和回滚谁修改了什么资源何时释放成本由谁承担。因此平台工程代表的是从“提供操作工具”到“交付基础设施产品”的转变。二、传统分工研发与运维1. 传统模式的分工在传统组织中研发和运维通常按职能分开研发开发功能、提交代码 运维部署系统、配置环境、处理故障常见流程是研发完成代码 → 交给运维部署 → 运维负责运行 → 出现问题后再协调研发系统规模较小时这种模式尚且能够运转系统变复杂后交接成本会持续上升研发不了解生产环境运维不了解业务行为故障定位依赖跨团队协调发布和运行之间存在责任空白运维团队容易被大量重复工单占据。2. DevOps 改变了什么DevOps 不是要求所有研发都转成运维也不是让一个团队包办所有工作。它首先改变的是责任关系研发不仅负责把代码写出来也应该对代码交付后的运行结果负责平台和基础设施团队则提供标准化的运行能力。业务研发通常应当能够部署自己的服务查看日志和指标配置基本告警执行回滚处理常见故障参与容量和可靠性设计。但这不意味着业务研发要承担所有底层工作例如维护 Kubernetes 控制面设计全公司的云网络安装 GPU 驱动管理底层存储和硬件维护所有团队共用的监控平台。这些通用、底层、复杂的能力应该由 Infra、SRE 或平台团队提供。DevOps 的重点不是让每个人什么都做而是让责任靠近系统的拥有者同时用平台减少重复劳动。三、现代分工Infra、SRE 和平台工程现代工程组织的边界已经不再主要由“写代码”与“做运维”决定而更多取决于目标和责任。1. Infra建设并维护底座Infra 主要负责系统运行所依赖的底层能力云资源、裸机和 GPU网络、DNS 和负载均衡存储、数据库和中间件Kubernetes 集群操作系统、镜像和容器运行时基础监控、日志和发布设施。Infra 并不只是“维护机器”而是用工程方法建设基础设施设计资源架构编写基础设施即代码建设标准集群和节点模板自动化资源交付规划容量和成本处理底层故障设计升级和回滚方案。所以Infra 同时包含研发和运维的工作内容但它研发的对象不是业务功能而是基础设施能力本身。2. SRE用工程方法经营可靠性SRE 关注的是系统是否能够稳定运行可用性延迟错误率监控和告警质量故障发现和恢复速度变更风险SLO 和错误预算事故复盘和持续改进。SRE 不应只是“高级运维”或“专门处理告警的人”。它要做的是减少人工值守降低故障发生的概率并提升系统发现和恢复故障的能力。可以简单区分为Infra 更关注系统由什么组成以及如何建设它 SRE 更关注系统是否可靠以及如何持续证明和改进它实际工作中两者经常重叠。一个团队可以同时负责集群建设、自动化交付、监控告警和故障恢复这时它可以被称为 Infra/SRE 团队。3. 平台工程把底层能力交付给研发平台工程关注的是研发团队如何使用基础设施统一资源申请入口提供标准部署模板编排跨系统工作流集成权限、审批和审计提供日志、指标和任务状态支持失败重试、回滚和人工接管维护文档、API、CLI 和控制台。平台团队更像内部产品团队。业务研发、算法研发和其他技术团队都是它的用户因此衡量标准不只是底层系统是否运行还包括用户能否高效、自助地完成工作。四、实践从职责边界到工程落地团队规模不同Infra、SRE 和平台工程的组织方式也会不同。小团队里一个人可能承担多种职责大团队里这些职责可能拆给不同团队。比起纠结岗位名称更重要的是明确每项能力由谁负责、谁参与以及出现问题时由谁牵头。1. 按责任边界协作可以按照责任对象进行划分业务研发 负责业务功能和业务服务的运行结果 平台工程 负责将基础设施能力包装成自助服务 SRE 负责可靠性目标、观测、恢复和变更治理 Infra 负责云、机器、网络、存储、集群和底层资源 安全 / 成本 / 治理 负责权限、合规、审计、成本和资源策略这不是绝对的组织架构。小团队里一个人可能同时承担 Infra、SRE 和平台工程职责大团队里这些职责可能拆成不同团队。下面是一种实用的责任划分方式领域主要责任者共同参与者云资源和集群Infra平台、SRE部署工具和工作流平台研发、Infra、SRE业务服务可靠性研发、SRE平台、Infra监控和告警SRE研发、平台资源成本Infra、FinOps平台、研发权限和审计安全、平台Infra、研发故障响应服务负责人SRE、平台、Infra可以把核心原则概括为平台提供能力研发对自己的服务负责Infra 对底层资源负责SRE 负责可靠性方法和机制。2. 让能力可交付并长期运营基础设施项目的验收标准不应停留在“脚本能执行”或“页面能提交”。真正需要验证的是用户能否稳定、重复地完成目标。交付对象不是一个孤立工具而是一条可运行、可观测、可恢复的完整路径。例如“建设 GPU 扩容系统”完整流程可能是需求建模 → 定义标准路径 → 建立资源和状态模型 → 开发底层自动化模块 → 编排完整工作流 → 自动验收和观测 → 试点验证 → 平台化运营一个扩容流程至少需要明确输入参数配额和权限资源创建过程节点初始化GPU、网络、存储验收监控接入失败重试回滚方式审计记录最终责任人。“资源创建成功”不等于“资源已经可用”。真正的交付结果应该是资源能够完成预期工作并且具备监控、登记、审计和后续运行条件。一个可落地的实践GPU 节点扩容以“为训练集群增加 8 张 GPU”为例可以把流程设计成提交申请 → 校验项目配额、权限和地域 → 创建或选择云主机 → 初始化操作系统、驱动和容器运行时 → 加入 Kubernetes 集群 → 验证 GPU、网络、存储和调度 → 接入监控、日志和资产登记 → 返回可用状态和节点信息真正落地时还要补齐几个关键细节每一步都有明确的输入、输出和超时重复提交不会创建重复资源流程需要幂等中途失败能够重试无法恢复时能够清理或回滚验收不只检查节点是否Ready还要验证 GPU 数量、驱动版本、容器运行和实际调度用户可以看到申请、执行、失败和完成等状态而不是只能找人询问所有变更都有日志、操作者和关联项目便于审计和成本归属。这套方法同样适用于集群创建、存储申请、发布流水线和证书更新等场景。从一次交付到长期运营试点成功后还应持续观察使用率、失败率、平均交付时长、人工介入次数和资源成本。用这些指标判断流程是否真的减少了重复劳动再迭代模板、配额、告警和文档。3. 沉淀知识并识别工作方向一次项目完成后还应把经验沉淀成别人可以理解、执行和判断的材料至少包含四个层次1. 概念知识回答“这是什么”例如 Kubernetes、GPU 节点、SLO、节点池、工作流、幂等性。2. 架构知识回答“它们如何关联”例如云主机 → 操作系统 → 容器运行时 → GPU 驱动 → Kubernetes Node → 调度器 → 训练任务 → 监控和日志3. 操作知识回答“具体怎么做”包括部署手册、Runbook、故障排查、升级和回滚流程。4. 决策知识回答“什么时候选择什么”例如什么时候扩容、什么时候优化任务、什么时候重试、什么时候回滚、什么时候应该平台化。决策知识往往最有价值也最容易被忽略。实践中可以为每项核心能力维护一份最小文档集架构图、部署手册、参数说明、Runbook、监控面板、故障案例和回滚方案。文档应跟随代码和配置一起变更并通过一次演练验证是否真的可用。与其简单地问“我是研发还是运维”不如先看两个问题主要服务对象是谁长期交付的结果是什么主要交付物更接近的方向业务功能和服务业务研发云、集群、网络、存储Infra工具、平台和自动化工作流平台工程SLO、告警、应急和可靠性机制SRE工单、配置和重复操作传统运维还可以从工作方式判断只是执行运维动作更接近传统运维 把运维动作工程化更接近 Infra / SRE 把工程能力产品化更接近平台工程如果主要工作是建设 GPU、Kubernetes、自动化交付、监控、资源模型和平台“平台型 Infra 工程师”通常是比较准确的定位如果主要关注 SLO、事故响应和可靠性治理则更偏向 SRE。一个人可以同时具备多种能力角色名称只是对主要责任的概括并不是固定边界。结语从做事情到建设做事情的系统可以用四句话总结这套体系运维解决“事情怎么做”。自动化解决“事情怎么重复做”。SRE 解决“事情怎么可靠地做”。平台工程解决“别人怎么自助地做”。Infra 则连接了这些能力它建设底层资源、自动化流程和运行环境并通过平台和 SRE 能力把基础设施变成可交付、可观测、可恢复的系统。因此现代基础设施工程的核心不是区分自己到底属于研发还是运维而是持续回答一个问题我是在重复执行一件事情还是在建设一个能够稳定完成这件事情的系统
基础设施工程的演进与边界手工/自动化/平台化运维/研发SRE/Infra文章目录基础设施工程的演进与边界手工/自动化/平台化运维/研发SRE/Infra一、手工 → 自动化脚本 → 平台工程1. 手工运维先把事情做完2. 自动化脚本让重复工作可复现3. 平台工程把能力交给使用者二、传统分工研发与运维1. 传统模式的分工2. DevOps 改变了什么三、现代分工Infra、SRE 和平台工程1. Infra建设并维护底座2. SRE用工程方法经营可靠性3. 平台工程把底层能力交付给研发四、实践从职责边界到工程落地1. 按责任边界协作2. 让能力可交付并长期运营一个可落地的实践GPU 节点扩容从一次交付到长期运营3. 沉淀知识并识别工作方向1. 概念知识2. 架构知识3. 操作知识4. 决策知识结语从做事情到建设做事情的系统基础设施工作经常同时涉及运维、研发、自动化、SRE、Infra 和平台工程。它们既不是完全互斥的岗位也不一定代表严格的先后阶段而是在不同层面描述同一个问题如何把底层资源和复杂系统稳定、可重复、可恢复地交付给使用者。可以从三个方向来理解这套体系能力形态手工 → 自动化脚本 → 平台工程传统分工研发负责开发运维负责运行现代分工研发、Infra、SRE 和平台团队共同承担系统生命周期中的不同责任。最终要完成的转变是从亲自“做事情”走向建设一个能够稳定完成事情的系统。一、手工 → 自动化脚本 → 平台工程1. 手工运维先把事情做完在早期基础设施工作往往依靠熟悉环境的人凭经验处理扩容一台机器部署一套 Kubernetes接入一批 GPU配置一次告警处理 DNS、网络或硬件故障。典型过程通常是需求来了 → 找熟悉系统的人 → 查文档和历史记录 → 手工执行命令 → 观察日志 → 人工判断结果 → 协调后续操作 → 补充记录这种方式通常有几个明显特征依赖个人经验容易遗漏步骤过程难以复现故障处理依赖少数专家系统知识存在人的脑子里。手工操作并非没有价值。面对低频、探索性或高度不确定的问题人工判断仍然必要但当同类工作不断重复就应当把其中稳定的部分标准化、自动化。2. 自动化脚本让重复工作可复现Shell、Ansible、Terraform、Helm 和 CI/CD 等工具可以将重复操作固化为脚本或流程。例如扩容 GPU 节点可以由脚本完成创建云资源 → 初始化节点 → 安装驱动 → 加入 Kubernetes → 配置监控脚本比手工执行更高效也更容易保持一致。但“有脚本”不等于“自动化已经成熟”。如果参数仍靠人工准备环境仍靠人工判断失败仍靠人工盯日志结果还要事后补录那么它更多只是操作提效并没有形成完整能力。一个可长期运行的自动化流程至少要处理参数校验幂等执行明确输入和输出超时和重试失败处理回滚策略日志和审计执行结果验证。自动化的重点不是把几条命令拼成脚本而是把一项完整工作变成可重复、可验证、可恢复的流程。3. 平台工程把能力交给使用者当自动化流程逐渐增多团队通常会继续向平台化演进。用户不必直接操作 Terraform、Ansible 或 Kubernetes而是通过页面、API 或 CLI 提交目标云厂商某云 地域某地域 集群训练集群 GPUA100 数量8 张平台在后台负责完成资源申请 → 权限和配额校验 → 资源创建 → 节点初始化 → 加入集群 → GPU、网络、存储验收 → 监控接入 → 资源登记 → 通知用户平台工程的本质是把复杂的基础设施能力封装成研发团队能够理解、调用和反馈的产品。它关注的不只是“能不能执行”还包括谁可以申请是否需要审批任务当前处于什么状态失败后是否可以重试是否支持取消和回滚谁修改了什么资源何时释放成本由谁承担。因此平台工程代表的是从“提供操作工具”到“交付基础设施产品”的转变。二、传统分工研发与运维1. 传统模式的分工在传统组织中研发和运维通常按职能分开研发开发功能、提交代码 运维部署系统、配置环境、处理故障常见流程是研发完成代码 → 交给运维部署 → 运维负责运行 → 出现问题后再协调研发系统规模较小时这种模式尚且能够运转系统变复杂后交接成本会持续上升研发不了解生产环境运维不了解业务行为故障定位依赖跨团队协调发布和运行之间存在责任空白运维团队容易被大量重复工单占据。2. DevOps 改变了什么DevOps 不是要求所有研发都转成运维也不是让一个团队包办所有工作。它首先改变的是责任关系研发不仅负责把代码写出来也应该对代码交付后的运行结果负责平台和基础设施团队则提供标准化的运行能力。业务研发通常应当能够部署自己的服务查看日志和指标配置基本告警执行回滚处理常见故障参与容量和可靠性设计。但这不意味着业务研发要承担所有底层工作例如维护 Kubernetes 控制面设计全公司的云网络安装 GPU 驱动管理底层存储和硬件维护所有团队共用的监控平台。这些通用、底层、复杂的能力应该由 Infra、SRE 或平台团队提供。DevOps 的重点不是让每个人什么都做而是让责任靠近系统的拥有者同时用平台减少重复劳动。三、现代分工Infra、SRE 和平台工程现代工程组织的边界已经不再主要由“写代码”与“做运维”决定而更多取决于目标和责任。1. Infra建设并维护底座Infra 主要负责系统运行所依赖的底层能力云资源、裸机和 GPU网络、DNS 和负载均衡存储、数据库和中间件Kubernetes 集群操作系统、镜像和容器运行时基础监控、日志和发布设施。Infra 并不只是“维护机器”而是用工程方法建设基础设施设计资源架构编写基础设施即代码建设标准集群和节点模板自动化资源交付规划容量和成本处理底层故障设计升级和回滚方案。所以Infra 同时包含研发和运维的工作内容但它研发的对象不是业务功能而是基础设施能力本身。2. SRE用工程方法经营可靠性SRE 关注的是系统是否能够稳定运行可用性延迟错误率监控和告警质量故障发现和恢复速度变更风险SLO 和错误预算事故复盘和持续改进。SRE 不应只是“高级运维”或“专门处理告警的人”。它要做的是减少人工值守降低故障发生的概率并提升系统发现和恢复故障的能力。可以简单区分为Infra 更关注系统由什么组成以及如何建设它 SRE 更关注系统是否可靠以及如何持续证明和改进它实际工作中两者经常重叠。一个团队可以同时负责集群建设、自动化交付、监控告警和故障恢复这时它可以被称为 Infra/SRE 团队。3. 平台工程把底层能力交付给研发平台工程关注的是研发团队如何使用基础设施统一资源申请入口提供标准部署模板编排跨系统工作流集成权限、审批和审计提供日志、指标和任务状态支持失败重试、回滚和人工接管维护文档、API、CLI 和控制台。平台团队更像内部产品团队。业务研发、算法研发和其他技术团队都是它的用户因此衡量标准不只是底层系统是否运行还包括用户能否高效、自助地完成工作。四、实践从职责边界到工程落地团队规模不同Infra、SRE 和平台工程的组织方式也会不同。小团队里一个人可能承担多种职责大团队里这些职责可能拆给不同团队。比起纠结岗位名称更重要的是明确每项能力由谁负责、谁参与以及出现问题时由谁牵头。1. 按责任边界协作可以按照责任对象进行划分业务研发 负责业务功能和业务服务的运行结果 平台工程 负责将基础设施能力包装成自助服务 SRE 负责可靠性目标、观测、恢复和变更治理 Infra 负责云、机器、网络、存储、集群和底层资源 安全 / 成本 / 治理 负责权限、合规、审计、成本和资源策略这不是绝对的组织架构。小团队里一个人可能同时承担 Infra、SRE 和平台工程职责大团队里这些职责可能拆成不同团队。下面是一种实用的责任划分方式领域主要责任者共同参与者云资源和集群Infra平台、SRE部署工具和工作流平台研发、Infra、SRE业务服务可靠性研发、SRE平台、Infra监控和告警SRE研发、平台资源成本Infra、FinOps平台、研发权限和审计安全、平台Infra、研发故障响应服务负责人SRE、平台、Infra可以把核心原则概括为平台提供能力研发对自己的服务负责Infra 对底层资源负责SRE 负责可靠性方法和机制。2. 让能力可交付并长期运营基础设施项目的验收标准不应停留在“脚本能执行”或“页面能提交”。真正需要验证的是用户能否稳定、重复地完成目标。交付对象不是一个孤立工具而是一条可运行、可观测、可恢复的完整路径。例如“建设 GPU 扩容系统”完整流程可能是需求建模 → 定义标准路径 → 建立资源和状态模型 → 开发底层自动化模块 → 编排完整工作流 → 自动验收和观测 → 试点验证 → 平台化运营一个扩容流程至少需要明确输入参数配额和权限资源创建过程节点初始化GPU、网络、存储验收监控接入失败重试回滚方式审计记录最终责任人。“资源创建成功”不等于“资源已经可用”。真正的交付结果应该是资源能够完成预期工作并且具备监控、登记、审计和后续运行条件。一个可落地的实践GPU 节点扩容以“为训练集群增加 8 张 GPU”为例可以把流程设计成提交申请 → 校验项目配额、权限和地域 → 创建或选择云主机 → 初始化操作系统、驱动和容器运行时 → 加入 Kubernetes 集群 → 验证 GPU、网络、存储和调度 → 接入监控、日志和资产登记 → 返回可用状态和节点信息真正落地时还要补齐几个关键细节每一步都有明确的输入、输出和超时重复提交不会创建重复资源流程需要幂等中途失败能够重试无法恢复时能够清理或回滚验收不只检查节点是否Ready还要验证 GPU 数量、驱动版本、容器运行和实际调度用户可以看到申请、执行、失败和完成等状态而不是只能找人询问所有变更都有日志、操作者和关联项目便于审计和成本归属。这套方法同样适用于集群创建、存储申请、发布流水线和证书更新等场景。从一次交付到长期运营试点成功后还应持续观察使用率、失败率、平均交付时长、人工介入次数和资源成本。用这些指标判断流程是否真的减少了重复劳动再迭代模板、配额、告警和文档。3. 沉淀知识并识别工作方向一次项目完成后还应把经验沉淀成别人可以理解、执行和判断的材料至少包含四个层次1. 概念知识回答“这是什么”例如 Kubernetes、GPU 节点、SLO、节点池、工作流、幂等性。2. 架构知识回答“它们如何关联”例如云主机 → 操作系统 → 容器运行时 → GPU 驱动 → Kubernetes Node → 调度器 → 训练任务 → 监控和日志3. 操作知识回答“具体怎么做”包括部署手册、Runbook、故障排查、升级和回滚流程。4. 决策知识回答“什么时候选择什么”例如什么时候扩容、什么时候优化任务、什么时候重试、什么时候回滚、什么时候应该平台化。决策知识往往最有价值也最容易被忽略。实践中可以为每项核心能力维护一份最小文档集架构图、部署手册、参数说明、Runbook、监控面板、故障案例和回滚方案。文档应跟随代码和配置一起变更并通过一次演练验证是否真的可用。与其简单地问“我是研发还是运维”不如先看两个问题主要服务对象是谁长期交付的结果是什么主要交付物更接近的方向业务功能和服务业务研发云、集群、网络、存储Infra工具、平台和自动化工作流平台工程SLO、告警、应急和可靠性机制SRE工单、配置和重复操作传统运维还可以从工作方式判断只是执行运维动作更接近传统运维 把运维动作工程化更接近 Infra / SRE 把工程能力产品化更接近平台工程如果主要工作是建设 GPU、Kubernetes、自动化交付、监控、资源模型和平台“平台型 Infra 工程师”通常是比较准确的定位如果主要关注 SLO、事故响应和可靠性治理则更偏向 SRE。一个人可以同时具备多种能力角色名称只是对主要责任的概括并不是固定边界。结语从做事情到建设做事情的系统可以用四句话总结这套体系运维解决“事情怎么做”。自动化解决“事情怎么重复做”。SRE 解决“事情怎么可靠地做”。平台工程解决“别人怎么自助地做”。Infra 则连接了这些能力它建设底层资源、自动化流程和运行环境并通过平台和 SRE 能力把基础设施变成可交付、可观测、可恢复的系统。因此现代基础设施工程的核心不是区分自己到底属于研发还是运维而是持续回答一个问题我是在重复执行一件事情还是在建设一个能够稳定完成这件事情的系统
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
