简介《TC管理员操作手册》是一份面向西门子Teamcenter系统管理员的中文运维指南聚焦TC11、TC12、TC13多个版本帮助读者完成系统安装升级、参数配置、权限管理、数据安全与业务流程定制等核心工作。资源为1个docx文档包体约11.41MB适合按章节查阅和检索。手册共186页内容从系统管理员的职责划分切入详细展开服务器端配置操作包括业务建模器的模板项目创建、部署与更新以及客户端超时退出等Teamcenter参数调整数据管理部分则覆盖新增零组件类型、属性字段新增、默认值设置、下拉列表与必填约束配置、关系类型新建等高频运维场景每项均配有操作路径与步骤说明。对于企业TC管理员、PLM实施顾问和系统运维人员来说这份手册既是新手上手的实用教程也是日常排除故障、优化系统配置的案头参考。目前已有1944人学习使用资料价值受到社区认可。1. TC管理员操作手册没写透的那部分才是日常真正要命的新接手西门子Teamcenter下文统一叫TC管理员的人第一反应都是翻TC管理员操作手册和帮助文档。但手册是分模块写的用户、权限、卷、部署各讲各的真正的问题往往出在模块交界处。比如某公司早上九点全员反馈签入失败日志提示卷空间不足可磁盘明明还剩 40%再比如权限表改了好几遍业务人员那边就是看不到变化。这些问题在TC管理员帮助文档里都能找到零散线索却没人告诉你它们其实指向同一个根源配置和数据分散在数据库、文件卷、安装目录、客户端缓存四个地方排查顺序错了越修越乱。这篇笔记就是把你从“对着手册找按钮”带到“知道自己动的是哪一层”的状态。适合刚接手TC管理员的人、兼职管TC的IT以及正打算从TC11往TC12或TC13升级的团队。2. 先搞清TC管理对象数据库、卷、安装目录与缓存的关系管理TC不像管普通应用登录管理端点几个菜单就行。TC的业务数据和管理配置分散在多个位置管理员的第一课不是学界面而是建立一张“什么东西放在哪里”的图。我建议每位管理员上任第一周先把自己环境的这张图画出来比读三遍手册都管用。TC的配置和业务数据笼统讲有四个去向关系型数据库里存的是用户、组、权限关系、Item主数据、工作流实例、编号规则这部分是元数据文件卷volume里存的是数据集实体文件也就是图纸、文档、装配文件本身安装目录和共享目录里是服务端程序、许可证文件、BMIDE项目、部署包每个用户终端上还有一份客户端缓存和临时文件很多人把它忘了结果清理磁盘时把缓存删了客户端直接白屏。这四个去向的管理方式完全不同。数据库里的内容要靠备份和还原来保护文件卷里的内容要跟着数据库一起备安装目录里的配置改完要重启服务客户端缓存坏了只能重新部署。排障顺序也是按这个来的先确认数据库连接正常再看卷是否可读写然后看服务状态最后才轮到客户端。经验不足的管理员经常反过来查客户端卸了装装了卸问题却在服务器端白忙一个下午。2.1 三类配置的存放位置改哪一层、重启哪一个TC里能改的配置按存放位置大致分三类改错了地方或者漏了重启表面症状很像处理方式完全不同。第一类存在系统表里用户、权限表、命名规则、工作流模板、编号规则。这类配置改完理论上对全库生效。但注意许多配置有缓存层用户怎么刷新都看不到变化时别急着怀疑自己改错先考虑缓存同步。我习惯在管理端确认修改成功后再去找缓存刷新入口。第二类存在安装目录里许可证配置、服务监听端口、卷路径、应用层的参数文件。这类配置改动必须重启对应服务才能生效。某次调整卷路径后我忘了重启文件服务导致新上传的数据集写进了老路径排查时看配置是对的但运行中服务不认。后来养成了习惯改完这类配置立刻记下“需要重启哪个服务”贴在配置变更记录里。第三类存在BMIDE项目里自定义属性、业务对象扩展、数据集类型的扩展定义。这类配置不直接改数据库而是通过BMIDE部署动作发布到目标环境。部署不到位时客户端连上看不到新属性或者报了属性不存在。TC11到TC13都沿用了这个机制只是部署入口在不同版本有调整。另外还有一类容易忽略的“外部文件类配置”设计模板、报表模板、批量导入的脚本常常被放在共享目录。这类文件不在数据库里备份时特别容易漏。我的习惯是在部署图上把这些共享目录单独标注和卷目录放在一起备份。2.2 用管理员视图确认版本、服务与许可证防呆第一步不管是日常巡检还是接受前人移交的环境第一步永远是确认当前环境的身份信息。TC管理员登录管理端后先看版本、补丁级别、许可证、服务运行状态这四样对不上后面做的所有操作都可能落在错误环境上。版本位看错是新手最常见的翻车点。TC11、TC12、TC13的管理界面布局差异不大但底层依赖和服务名有变化。拿着TC11的路径去TC13环境找配置找到了也不敢改因为界面入口收敛过。尤其是一个团队同时维护多个版本的环境管理端首页显示什么版本一定要养成看一眼的习惯。更稳妥的做法是给每个环境做一个标识卡主机名、版本、补丁号、数据库连接串、卷路径、许可证号打印出来贴在工位上。环境多的时候管理端连着测试库却在生产库上做备份检查或者反过来把测试数据当生产数据导出这种事我见过不止一次。标识卡不能靠脑子记脑子在连续加班时会骗你。许可证也要定期看。我习惯每周一上班先确认许可证剩余数量和过期日期。许可证快到期时服务不会立刻停但用户会间歇性登录失败日志里出现许可证相关报错。等到业务部门来反馈再查压力就全在自己这边了。2.3 环境拆分开发、测试、生产连在一起会出什么事团队的TC环境常见做法是至少拆成开发、测试、生产三套。开发环境用来改BMIDE项目、调权限表、试新流程测试环境用来做版本升级演练和数据迁移验证生产环境就是业务在用的那套。三套环境共用一套物理机是很多公司为了省成本做出的选择但这个决定会在后续每一次升级、补丁、备份恢复时反复折磨管理员。先说端口。开发环境占用了默认端口生产环境再启动时同一端口被占服务起来就自动退出。日志里能看到端口绑定失败的报错但同一个报错在不同环境里原因可能不同。再说许可证。TC的许可证通常按站点申请开发和生产共用一套许可证开发环境跑着大型任务生产这边的用户就登不进去业务部门只会找你不会找省钱的人。数据库和卷更不能共用。某公司为了省事开发和生产共用同一个库只是用不同企业site区分。结果一次开发环境批量导入测试数据把生产的Item编号段冲掉了恢复花了两天。我的建议是环境再紧张至少把生产库和开发库的物理存储彻底分开卷目录也必须各用各的许可证如果无法分开就在开发环境贴提醒执行重任务前先确认生产许可证余量。环境拆分这件事决定了你在TC11升TC12、TC12升TC13时的工作量。环境分得清升级可以在测试环境先演一遍风险可控环境分不清只能抱着生产环境直接升步步惊心。3. 用户与权限的日常操作从新建账号到权限表复制用户和权限是TC管理员日常操作里占比最高的一部分也是最容易做出“看似正确实则违规”操作的地方。手册里写得清楚的是界面入口没说透的是组织逻辑TC的权限不是简单地给某人打个勾而是通过“用户身份 组/角色 权限表”三层结构来计算的。实际操作中我见过不少团队在用户管理上走了弯路。比如用中文做用户ID后续做日志排查、数据库查询时到处踩坑比如离职员工账号直接删除结果历史Item的所有者变成未知流程记录的审批人显示为空再比如为了省事把所有用户放进同一个“所有人”的组里导致权限规则互相覆盖用户A刚加的白名单被用户B的组规则覆盖掉。这一章把用户、权限、卷这三块日常操作讲透每一块都能直接照做。3.1 新建用户与离职封禁主组、密码和“删除还是禁用”新建用户核心字段是用户ID、姓名、初始密码、主组。用户ID建议直接用员工工号纯数字或字母不要用中文、不要带空格也别频繁复用已离职人员的ID。姓名可以写“中文名拼音”双份方便显示和检索。初始密码按公司密码策略设定首次登录是否强制改密由管理员在策略里配置建议开着。主组是最容易被忽视的字段。用户登录后默认按主组来归类和分配初始文件夹如果主组设成了“所有人”这类通用组用户的默认工作区、项目文件夹归属、权限来源都会出问题。我这里有个习惯先建组再建用户建用户时直接指定到业务对应的部门组绝不依赖“所有人”组做兜底。离职员工的账号处理我一律建议禁用而不是删除。TC里的Item、流程任务、审批记录都指向具体用户ID删掉用户会让这些历史数据变成“无主数据”后续查询、权限继承、审计导出都可能报错。禁用账号的操作用户无感知历史记录完整权限也立刻收回。禁用前还要确认该用户是否还有未完成的流程任务有的话先把任务转给接替者。批量导入用户时我常用导入功能配合Excel模板一次导入但导入完成后必须逐条检查主组是否被正确映射。导入模板里的组名称差一个空格系统就会把用户放到错误的分组里这种错误在界面上看不出来直到用户报“看不到该看到的项目”才发现。密码策略方面TC11以后的管理端可以设置密码长度、复杂度、有效期。这个策略建议打开尤其是生产环境别为了省事让所有账号共用初始密码。补丁升级后有些站点密码策略会被重置升级验证清单里应当包含密码策略检查。3.2 组、角色与权限表别在原表上直接改TC的权限模型核心结构是对象类比如Item、Folder、Dataset对应一张权限表权限表里定义了不同组/角色对这类对象的可执行操作用户通过“属于某个组、在某个角色下”来获得对应权限。所以调整权限的正确路径是找到目标对象类打开它的权限表看看当前是哪些组和角色在起作用再决定改谁。默认权限表是系统自带的我的建议是永远不要在系统默认权限表上直接修改。正确做法是复制一张新表命名为“xx项目授权版”然后在副本上调整。默认表要被系统内部逻辑引用直接改它轻则影响全库各类对象的默认行为重则升级时被标准包覆盖改动全部丢失。复制权限表这个习惯属于那种“看着多余、关键时刻救命”的操作。权限表里的操作项常见的是读、写、删除、更改属主、变更状态、创建版本等。调整权限时要按业务流来梳理而不是按某个人的需求来打勾。比如设计人员对“在制Item”需要写权限对“已发布Item”只需要读和变更状态这个差异要在权限表里体现出来而不是简单给设计组全部打勾。排查用户权限问题时先确认该用户当前激活的组和角色是什么。TC用户在客户端可以切换自己的工作身份如果用户激活的身份和实际业务身份不一致就会觉得“权限没生效”。我处理过很多“看不到对象”的工单最后八成是用户登录后没有切换角色或者主组映射错误。管理端能看到用户属于哪些组但看不到当前激活的是哪个需要客户端配合确认。权限变更后不生效另一个常见原因是缓存。TC的权限信息会缓存在服务端和客户端两侧修改权限表后用户在已打开的会话里可能还持有旧权限。让用户重新登录通常能解决一半问题剩下的要看缓存服务是否需要刷新。这个坑在第5章细说。3.3 卷管理签入失败的“卷满”不一定是磁盘满TC里的卷volume是文件实体存放的地方。图纸、文档、装配文件在数据库里只存元数据和索引实际文件落在卷目录里。卷管理是管理员最容易忽略的领域因为它不像用户和权限那样天天有人报问题一出问题就是全局性的。签入失败时日志常提示“卷空间不足”。新手第一反应是看服务器磁盘剩余空间但磁盘明明还有 30%。TC的卷有它自己的使用统计卷目录所在磁盘剩余空间不等于卷可用空间因为卷空间是被数据库里已登记的数据集文件占用的。正确的检查路径是管理端查看卷属性看卷的已用空间和使用率而不是只看操作系统磁盘。我习惯把卷分成系统卷和业务卷。系统卷放模板、配置文件、小体积公共资源业务卷按数据类型再拆分比如设计图纸一个卷、办公文档一个卷、导出包一个卷。这样拆分的好处是某个卷满了只影响对应类型的数据签入不会全局瘫痪备份时也能按卷的优先级来分配备份频率。卷路径在配置阶段就要规划好。新加卷时可以调整数据集类型默认写入哪个卷不要试图修改一个正在使用的卷路径来“迁移数据”那样会让历史数据引用断裂。正确的迁移方式是新建卷、调整默认卷指向、再把旧卷上需要归档的数据通过导出导入方式搬过去。直接改路径用户打开老数据时会报“找不到文件”而且这种错误在日志里不直观排查成本很高。磁盘满了怎么办先看哪个卷使用率最高把长期不访问的项目归档到冷存储或者把归档数据导出库外。归档用的是TC的归档工具做好归档记录将来需要回溯时能按归档索引找回。不要直接把卷目录里的文件删掉数据库索引还在文件没了数据就彻底坏了。4. 从TC11到TC13升级与部署BMIDE、补丁和回滚路线版本升级是TC管理员工作里压力最大的一环。TC11、TC12、TC13三代的升级不只是换个安装包那么简单它涉及数据库结构变更、文件卷兼容、BMIDE项目迁移、客户端部署方式变化。准备不充分就动手轻则升级失败回滚重来重则数据库结构变更到一半卡住直接伤及生产业务。这一章把升级前准备、BMIDE部署、补丁回滚三块讲透。先说一个总判断TC升级的复杂度和工作量与你们在BMIDE里做的自定义程度成正比。只用标准功能的团队升级基本是顺走做了大量自定义属性、自定义对象类型的团队升级的重头戏全在数据模型迁移上这部分做不好数据库结构升级完之后自定义字段一片空白业务部门直接懵。所以评估升级工作量时先盘点BMIDE项目的大小而不是先看安装包体积。4.1 跨版本升级前必须备份的内容从TC11升到TC13常见路线是一级一级升先升TC12再升TC13。直接跨大版本升级的支持情况以你拿到的安装包和发布说明为准不要拿网上的老教程硬套。我接手过一个环境前人的升级记录里写着“直接从TC11跳TC13成功”但我复现时在数据库结构升级阶段就卡住了最后只能从备份恢复老老实实走两级路线。跨版本升级走得稳比走得快重要。升级前备份不是起个备份任务就行。我列了一份清单按顺序执行数据库全备、文件卷全备、安装目录里的BMIDE项目导出、许可证配置备份、当前补丁包清单导出。五样全齐才算备份完成。数据库只备库不备卷升级失败回滚时会发现数据能登录但文件全打不开。升级前还要核对硬件和系统环境。新版本对服务器操作系统、数据库版本、客户端位数都有要求。先用测试环境验证生产环境不要直接上。测试环境升级前最好克隆一份和生产一致的库和卷这样演练的结果才有参考价值。演练时记录两个数据数据库结构升级耗时、整体停机时长这两个数字是生产升级排期的重要依据。TC11、TC12、TC13的界面变化不算大真正的差异在部署依赖和配置入口上。许多老教程写的是TC11的操作路径到了TC13里入口已经变了。升级后要拿着当前版本的发布说明重新过一遍管理操作清单比如许可证配置位置、服务管理入口、索引服务状态页别拿旧经验硬套。4.2 BMIDE部署与自定义属性迁移BMIDE是TC的数据模型扩展工具你们公司增加的自定义属性、自定义对象类型、数据集类型扩展都是通过它来部署的。升级中最容易出问题的就是这部分。数据库结构升级完成后标准表都正常但自定义属性可能没有自动带过来需要用BMIDE重新部署。我习惯的流程是升级前从老环境导出BMIDE项目文件保存到独立目录升级完成并确认系统标准功能正常后打开BMIDE导入老项目再执行部署动作。部署动作会在目标环境上生成或更新自定义属性对应的数据库字段。部署时注意目标环境别选错我之前见过有人把测试环境BMIDE项目部署到了生产库一晚上自定义属性全跑偏第二天回滚折腾半天。部署不是只在一台机器上执行。TC13这类多节点部署的环境应用层有多个节点时BMIDE的部署动作需要在所有相关节点上都执行否则客户端连接到另一个节点时看不到新属性。这个坑我踩过部署完在一台服务器上验证正常换一台服务器登录就报属性不存在原因就是只部署了一个节点。部署完成后一定要做一次实际创建数据的验证新建一个对象、填自定义属性、保存、重新打开确认值还在。界面上能看到属性不代表能写入持久化层。验证通过才算部署完成这一步不要省略也不要只靠数据库里查字段存在与否来判断。属性迁移失败的常见报错是“属性类型冲突”。老环境里某个自定义属性是字符串类型新版本的默认属性里恰好出现同名的整数类型升级时就冲突了。遇到这种情况先查发布说明里对标准属性的变更记录再把自定义属性改名避免和标准属性冲突。不要试图通过改数据库类型来硬解那会在后续补丁安装中反复出问题。4.3 补丁安装与回滚的时间点补丁升级比大版本升级频繁得多也更容易麻痹大意。TC补丁的解压、安装、部署、重启一套流程走下来看起来和升级没区别但补丁里常常包含数据库结构变更。凡是带数据库变更的补丁安装前必须做数据库全备这一点没有商量的余地。我见过最典型的翻车场景补丁安装到一半数据库结构变更脚本执行失败安装程序自动回滚但数据库已经被改了一半此时想再装一次补丁因为库结构不完整安装校验直接不通过。唯一的出路就是恢复补丁前的数据库备份。所以备份文件命名要规范我习惯用“环境名日期补丁号”来命名恢复时一眼就能找到正确的那份备份。补丁安装还涉及部署包的同步。客户端连接服务器时会自动从服务器端获取部署内容补丁安装后部署版本变了老客户端没有重新同步时会报版本不匹配。这类报错的原因很直接但用户侧看起来就是“登录不了”“打开白屏”。处理办法是让用户重新获取部署或在服务器端执行部署更新后再登录。回滚的后悔药不常有但必须有。补丁大多不支持直接卸载正确回滚路径是先按官方要求卸载补丁恢复数据库备份再恢复文件卷备份。这三步的顺序不能乱也不能只恢复数据库不恢复卷。回滚后要验证用户能登录、文件能打开、自定义属性还在全绿才算回滚成功。补丁安装的时间点我通常选在业务低峰期的周末凌晨预留出整个白天作为观察期。不要在业务高峰期打补丁哪怕发布说明只写了一句“重启服务”实际重启整个应用层的影响面也远比想象大。5. 管理员避坑翻车率最高的五件事这一章写的是TC管理员圈子里反复出现的高频故障每条都按“现象 → 原因 → 解决”来写。这些坑不见得都在手册的显著位置但遇到任何一个都足以让新手管理员折腾一整天甚至更久。我按自己的经验整理了翻车率最高的五件事供各位同行参考。5.1 清理临时目录后客户端白屏现象为了释放C盘空间把用户终端临时目录里的Teamcenter相关文件夹删了之后客户端启动长时间白屏有的机器直接报资源缺失。 原因TC客户端每次登录都要把服务器端的部署内容拉取到本地缓存缓存被手动清理后客户端在下次登录时找不到本地部署内容需要全量重新下载。网络状况不好或者多人同时触发重新下载时服务器端负载升高客户端看起来就是“卡死”。 解决不要手动去清理客户端的缓存目录。确需清理时选择低峰期在客户端安装目录执行修复或重新部署操作让部署内容重新生成。服务器端也可以主动下发达成新部署让客户端下一次登录时自动同步。清理磁盘空间前先确认目标目录归属别拿TC缓存当普通垃圾文件删。5.2 服务起来就退出端口被占用现象TC服务启动后几十秒自动退出查看日志能看到端口绑定失败相关报错。 原因另一套环境或防病毒软件占用了相同端口。开发和测试装在同一台机器时最常发生两个环境的默认端口完全一样谁后启动谁就起不来。也有过服务器上某个自启动程序占用了TC的监听端口TC服务一启动就被顶掉。 解决先用系统命令查端口占用情况确认进程身份如果端口被其他环境占用修改冲突那一侧环境的监听端口配置然后重启服务。还要检查许可证端口许可证端口冲突的服务端不一定会完全退出但客户端会间歇性拿不到许可证表现比端口冲突更隐蔽。5.3 全文检索越查越慢索引队列积压现象关键字搜索本来秒出结果后来变成几秒甚至几十秒严重时搜索页一直转圈。 原因索引任务堆积索引代理没有及时消费或消费线程卡死。数据量大的站点在业务高峰期文件变更频繁如果索引代理某次异常后没有恢复积压任务会持续累积查询性能线性下降。 解决在管理端找到索引服务的队列状态查看积压数量。积压明显时重启索引代理重启后观察队列是否在消化。如果长期反复积压需要检查索引代理的调度配置和日志错误。日常巡检加一项索引队列检查比用户报“搜不到”时再处理省力得多。5.4 权限改了不生效用户角色缓存作祟现象给某个角色增加了权限业务用户实测还是没有权限。 原因权限信息存在缓存里。用户登录后会话期间持有的权限集是之前拉取的权限表改了也不会实时刷新另一种情况是用户同时属于多个组当前激活的组不是管理员改的那个组权限自然不匹配。 解决先让用户重新登录或切换组/角色确认他当前激活的身份。如果重新登录后仍然不行再检查权限表的配置是否正确应用到了目标组。不要反复改动权限表来试错那样会把权限关系越改越乱。权限表设计时留下变更记录每次改了什么一目了然。5.5 恢复了数据库却打不开文件卷没有一起备现象从备份中恢复了数据库用户和权限都正常但打开数据集文件时提示找不到文件或文件路径无效。 原因备份只备了数据库文件卷没有同步恢复。卷目录在另一块磁盘上数据库还原后元数据指向的文件实体不在或者卷路径已变化引用断裂。 解决数据库和卷的备份必须来自同一时间点恢复时保持原有卷路径不变。路径实在要变先在管理端做好卷路径的重映射再执行恢复。备份脚本里把数据库和卷打包成一个恢复单元恢复时整体执行不要分成两次操作。6. 进阶写一个每天自动跑的管理员自检脚本手册里能查到的都是“怎么操作”但环境健康度要靠管理员自己盯。我建议每一位TC管理员都写一个自检脚本每天早上自动跑一遍覆盖服务进程、卷目录磁盘、临时目录增长这三个最基础的检查项。脚本逻辑不复杂但能帮助每天上班前5分钟掌握环境状态。以下是我常用的自检脚本结构按你自己的环境改配置区即可import subprocess, shutil, socket, datetime from pathlib import Path # 配置区改成你自己环境的值 SERVICES [tc_server, tccs, index_agent] # 服务进程关键字列表 VOLUME_DIRS [D:\\TCData\\volume1, D:\\TCData\\volume2] # 卷目录 TEMP_DIR C:\\Temp\\tc_temp # TC临时目录 THRESHOLD 20 # 磁盘剩余空间最低百分比 REPORT [] def check_services(): # 通过进程列表匹配服务关键字缺失则记录 output subprocess.run([tasklist], capture_outputTrue, textTrue).stdout.lower() for svc in SERVICES: if svc.lower() not in output: REPORT.append(f[服务] {svc} 未运行 {socket.gethostname()}) def check_disks(): # 检查卷目录所在磁盘剩余空间 for d in VOLUME_DIRS: usage shutil.disk_usage(d) free_ratio usage.free / usage.total * 100 if free_ratio THRESHOLD: REPORT.append(f[磁盘] {d} 剩余 {free_ratio:.1f}% 低于 {THRESHOLD}%) def check_temp(): # 临时目录超过 10GB 说明有任务未清理 p Path(TEMP_DIR) if not p.exists(): return total sum(f.stat().st_size for f in p.iterdir() if f.is_file()) if total 10 * 1024**3: REPORT.append(f[临时目录] {TEMP_DIR} 当前约 {total / 1024**3:.1f}GB请人工检查) if __name__ __main__: check_services() check_disks() check_temp() print(f[TC自检] {datetime.datetime.now().strftime(%Y-%m-%d %H:%M)}) print(\n.join(REPORT) if REPORT else 状态正常)这个脚本里check_services 用 tasklist 的输出匹配服务进程关键字SERVICES 列表按你环境里的实际进程名来改check_disks 通过 shutil.disk_usage 获取磁盘剩余比例THRESHOLD 就是报警阈值check_temp 统计临时目录下所有文件的总大小。逻辑都很直白关键在于配置区的值一定要落到你真实的服务器上。把脚本挂到计划任务里Windows 用任务计划程序Linux 用 cron每天上班前自动执行并把输出重定向到日志文件。平时不用刻意去看哪一天日志里出现非“状态正常”的内容再登录环境排查就行。我自己的习惯是脚本里再加两项许可证剩余数量检查、上次成功备份的日志日期检查。许可证快到期或备份任务悄悄失败了这类问题不主动看很难发现等业务人员报就晚了。这个脚本不高深但我靠它抓到过一次索引队列积压——周五下班前还好好的周六索引代理卡了周日积压了上万条任务周一早上脚本报警才介入处理避免了业务高峰期查询卡顿的投诉。做TC管理员比修故障更重要的是让故障在用户发现之前暴露出来。定期自检这个习惯希望帮到你。本文还有配套的精品资源点击获取