Dorado 2000 偶发控制器故障（控制器重启、双控切换、单控脱管）通常不是单点硬件损坏，建议按"先取证、再定位、后替换"的顺序排查。1. 先固定证据：在 DeviceManager 的「监控-事件/告警」中导出故障时间点前后 24 小时的事件日志，记录每次故障的精确时间、控制器 ID（A/B 控）、是否有 SBB／BBU／风扇／电源告警，以及当时的 IO 压力（IOPS、时延）。偶发问题如果不在故障瞬间取证，事后很难复现。2. 检查供电与散热链路：双控设备偶发重启最常见的原因是机柜供电瞬时跌落或 PDU 单路掉电，导致双控前后脚重启。请核对两路 PDU 是否分属不同 UPS，测量故障时段是否有市电切换记录；同时确认机柜进风温度与风扇转速无异常。3. 检查控制器间心跳与后端链路：确认双控之间管理网／心跳网无丢包，后端 SAS/NVMe 环路无误码（查看链路误码计数是否持续增长）。链路亚健康会触发控制器隔离保护，表现为"偶发故障"。4. 版本与已知问题：核对当前存储 OS 版本，Dorado 系列对控制器重启、BBU 充放电异常、SBB 单板亚健康都有专门的补丁修复。建议升级到官方推荐的最新稳定版本，并执行一次健康检查（巡检报告）。5. 硬件侧：若事件日志中出现 SBB、BBU 或内存 ECC 相关告警，即使控制器已恢复正常，也应安排窗口更换对应单板；单板亚健康是"偶发"故障最典型的来源。6. 若以上均无异常，请在故障发生后 24 小时内收集完整日志包（含控制器串口日志）提交华为云技术支持，由后端分析控制器重启原因码。日志越完整，定位越快。

从标题看是 CCE 里的 Pod 访问内网 GaussDB 实例不通，建议按"先分辨现象、再查网络、后看白名单与认证"的顺序排，基本能定位到具体一层。1. 先分辨是"不通"还是"被拒"进到业务 Pod 里执行：nc -zv 实例私网IP 端口（GaussDB 端口以实例详情页为准，常见 8000）。结果是超时，属网络层不通；结果是 connection refused，说明端口没有监听或被拦截；能连上但报 no pg_hba.conf entry，说明网络通了、卡在白名单。2. 网络层核对 VPC 与组网方式确认 CCE 集群和 GaussDB 在同一区域、同一 VPC。跨 VPC 必须建对等连接或企业路由器，并在两端路由表都加上对端子网路由，缺一端就不通；内网实例不要用公网地址去连。还要注意 CCE 的容器网络模式：云原生 2.0（VPC 网络）下 Pod 有独立子网 IP，出方向源地址是 Pod IP；隧道网络下访问外部走节点 SNAT，源地址是节点 IP。这直接决定下面要放通哪个网段。3. 安全组与实例白名单，两处都要加GaussDB 实例绑定的安全组，入方向需放通数据库端口，源填节点子网或 Pod 子网 CIDR；同时到 GaussDB 控制台的连接管理/账号白名单里，把同一网段加进去。这是最常见的坑——安全组通了但白名单没加，报错就是 no pg_hba.conf entry for host。只放通节点 IP 而实际源地址是 Pod IP（或反之），同样连不上。4. 认证与客户端参数建议用 openGauss 兼容驱动（org.opengauss.Driver），连接串写全 host、port、database（默认 postgres）、user，SSL 按实例设置选 disable 或 require；连接池的超时设 5~10 秒，避免排障时一直挂住看不出错误。5. 按报错反查超时→安全组/路由/VPC；refused→端口写错或实例未监听；password authentication failed→账号密码或库名不对；no pg_hba.conf entry→白名单；SSL error→客户端未按要求开启 SSL。另外若只在容器内偶发失败，再补查 CoreDNS 解析是否稳定、有无 NetworkPolicy 禁止出方向。

补充一份可落地的上传与校验清单，按"先规范、再通道、后校验"三步走，能避开大部分导入失败：1. 上传前先对齐目录与元数据规范具身数据按 episode 建独立目录：raw/ 放 mp4 或 hdf5 原始序列，meta/ 放 json（相机内参、采集频率、起始时间戳、关节顺序）。一条 episode 一个目录，不要在同一目录混放多条。采样率务必与机器人控制频率一致（常见 30Hz），否则后续标注时间轴会整体漂移。2. 按体量选择上传通道单文件小于 2GB、条数少：网页端"数据管理-上传"直接传，注意保持网络稳定，中途刷新会丢失已传分片。整批数据或大文件：走 OBS 中转——先传到与平台同区域的桶，再用"从 OBS 导入"，目录层级会原样映射为 episode 结构，比浏览器上传稳定得多，也不会产生公网流量。3. 常见失败与定位①"加载失败"多数不是网络问题，而是 meta json 缺必填字段或时间戳单位混用秒与毫秒；②上传后 episode 列表为空，先查路径是否含中文、空格或特殊字符，统一改成英文加下划线；③条数少于预期通常是分片仍在合并，等状态由"处理中"变"已完成"再统计；④同名文件会静默覆盖旧数据，导入前确认版本号。4. 入库后的抽样回放在标注工具里打开首帧与末帧，确认视频与关节序列时间对齐、无黑屏或丢帧，再进入标注；发现错位先改采样率与起始时间戳重导，不要直接在标注侧修补。

排查 MySQL 时间字段不自动更新的思路created_at / updated_at 在 UPDATE 后没有按预期刷新，通常不是 bug，而是字段定义或语句写法导致的，按下面顺序排查基本能定位。1）先看表定义是否带自动更新属性：SHOW CREATE TABLE t\G。只有 updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 这种带 ON UPDATE 的定义才会在行数据真正变化时自动赋值；只写了 DEFAULT CURRENT_TIMESTAMP 而没有 ON UPDATE 的列，UPDATE 时不会刷新。2）确认这次 UPDATE 是否真的改了行。ON UPDATE CURRENT_TIMESTAMP 仅在列值实际发生变化时触发，如果整行数据没有实质变化（例如把字段设置成与原值相同），MySQL 认为行未变更，时间列不会更新；需要强制刷新就只能显式写 SET updated_at = NOW()。3）注意显式赋值会覆盖自动逻辑，把时间列写进 SET 子句时以你给的值为准，比如 SET updated_at = updated_at 就等于冻结该字段。4）TIMESTAMP 受会话时区影响，SELECT @@time_zone, @@system_time_zone; 两个会话时区不一致时，写入和读出来的值会差几个小时，看起来像"没更新"。跨时区业务建议统一用 DATETIME 由应用侧生成时间，或在连接串固定 time_zone。5）MySQL 5.6 与 5.7/8.0 的默认值不同：explicit_defaults_for_timestamp 在 5.6 默认 OFF、5.7 起默认 ON，同一个建表语句在两端表现可能不一致，从旧版本迁移过来的表要重点核对。6）如果走 ORM（MyBatis-Plus / Hibernate 等），确认自动填充注解是否生效，常见问题是更新时把时间字段置为 NULL 或压根没带上该列，最终 SQL 里没有这个字段。建议先把实际执行的 UPDATE 语句和 SHOW CREATE TABLE 结果贴出来，基本一眼能看出是定义问题还是语句问题。

这是典型的渲染时机问题：requests 拿到的只是服务端返回的骨架 HTML，数据是浏览器执行 JS 后二次请求接口再渲染上去的。按可行性从高到低，有四种做法。一、优先找后端数据接口。打开开发者工具的 Network 面板，过滤 XHR/Fetch，刷新页面后看哪些响应是 JSON，把 URL、请求方法、入参、Cookie/Token 抄下来直接复刻。注意两类坑：一是接口带 sign、timestamp、nonce 之类的签名参数，需要逆向那段 JS 或直接复用页面里已生成的参数；二是接口依赖登录态，必须带上有效 Cookie。二、用无头浏览器渲染。Playwright 或 Puppeteer 都可以，关键是等待条件要写对：优先 waitForResponse 等目标接口回来，其次 waitForSelector 等目标元素出现，最次才用固定 sleep。拿不到内容常见原因有三个：等待条件太早、目标元素在 iframe 内部、页面懒加载需要滚动到底部才请求。三、处理反爬与稳定性。无头浏览器容易被识别，至少要设置合理的 UA、视口大小，必要时注入 stealth 脚本；批量采集要控制并发、加随机延时、准备代理池，并对超时和空结果做重试与告警。四、工程化建议。把“取数”和“解析”解耦：取数层返回完整 HTML 或接口 JSON 并落盘缓存，解析层单独写，出问题能快速定位是取数失败还是结构变了。同时对选择器做兜底，页面改版时不至于全量失效。如果只是偶尔抓一两个页面，用无头浏览器脚本足够；如果站点 JS 特别重、反爬成本高，也可以直接选用支持渲染的采集服务，但长期看自建链路的可控性更好。

建设 RFID 涉密载体管控系统，建议按“先定制度、再定标签数据、最后上设备与平台”的顺序推进，否则很容易变成只买硬件的形象工程。核心要解决的问题主要有五个。一、载体分类分级先行。先把纸质文件、涉密 U 盘、移动硬盘、光盘、涉密笔记本等载体按密级和流转范围分类，明确哪些必须贴标签、哪些只能人工登记。标签里只写入编号、密级、责任人、状态等元数据，绝不写入载体内容，从源头上避免“上系统反而增加泄密面”。二、标签读写安全。抗金属 UHF 标签要选支持口令保护或加密读写、可一次性锁定（写保护）的型号，防止被复制、篡改密级；对高密级载体建议增加防拆标签或双标签冗余，拆下即告警。读写器与网关之间的链路要做双向认证与数据加密。三、业务流程必须重排。RFID 只能解决“载体在哪、动没动”的问题，解决不了“谁批的、该不该出”。要把借出、归还、携出、销毁四个动作在系统里做成强制流程：携出需审批单与门禁通道门联动核验，未审批载体过门立即声光告警并推送保密员；销毁环节用标签注销替代手工勾选，做到账实一致。四、部署方式与数据边界。涉密单位建议本地化部署，管理平台与数据库放在内网，仅在隔离网内做数据汇聚；读写器、智能柜、通道门通过边缘网关接入，网关只上送识别事件，不上送任何文件内容。日志要留存操作人、时间、地点、动作四要素，满足审计与追责要求。五、渐进落地与量化验收。不要一次性全楼铺开，先选一个涉密载体量最大的部门做试点，跑通“入柜—借出—通道核验—归还—盘点”闭环，再推广。验收指标建议包括：盘点耗时下降比例、载体在位率、异常携出发现时长、账实一致率。系统上线后纸质台账可保留一个季度做双轨核对，确认无差异后停用。最后提醒一点：RFID 是识别与管控手段，不是保密管理的替代品。真正决定效果的是密级标识的严肃性、审批流程的执行力和日常审计的密度，技术只是把这些动作变得可采集、可追溯、可追责。

针对「使用API查询CMDB资源的标签」这个问题，梳理一下在 ManageOne 运维面北向对接中把标签查出来的可行做法，供参考。一、先明确标签在 CMDB 里的位置。CMDB 的资源对象是「类型 + 实例」两层结构，标签不是独立资源，而是挂在实例上的属性集合，北向返回时通常在 attributes 或 ext 字段里以 key/value 形式出现。所以查询标签本质是「先按资源类型和实例定位对象，再读取属性集合」。二、鉴权与公共请求头。运维面北向统一走 X-Auth-Token，token 由 IAM 的 /v3/auth/tokens 获取，scope 必须落在运维面对应的 project/domain 上；同时建议带 Content-Type: application/json 和 X-Language（en-us 或 zh-cn），否则部分版本返回的字段名会与文档不一致，容易误判标签字段缺失。三、按实例查询并取标签字段。典型请求：POST /rest/cmdb/v1.0/instances/query，请求体里给出 resourceType（如 vdc、vm、hostgroup）与 filter 条件，例如 {"resourceType":"vm","filter":{"name":"ecs-01"},"limit":100}。响应里的 instances[].attributes 中，标签一般以 tags 或 tagList 键返回，形如 [{"key":"env","value":"prod"}]；如果只看到 id 没有 value，说明当前账号对该资源没有读权限，需要在 OC 上给对接账号授权到对应资源集。四、按标签反查资源。很多对接场景其实是要「列出打了某标签的所有资源」。此时用 filter 里传标签条件，例如 {"tags":[{"key":"env","value":"prod"}]}，注意不同版本对 key/value 的大小写和分隔符敏感，建议先用一次不带 filter 的查询拿到真实字段名，再拼条件。五、常见坑。1）分页：单次返回有上限，务必按 limit/offset 翻页，否则漏实例；2）标签是变更型数据，不建议做全量缓存，按业务 TTL 定时拉取更稳；3）对接账号使用二级 VDC 时，token 的 scope 要落到该 VDC 的 project，否则查到的资源集为空但不报错；4）如果接口返回 200 但结果为空，先排查 X-Auth-Token 对应 domain 与资源所属 domain 是否一致。建议先用 API Explorer 里的 CMDB 实例查询接口做一次最小验证，把真实响应字段打印出来，再固化到对接代码里，比直接按文档字段写映射更可靠。以上基于公开北向对接思路整理，具体 URI 与字段名请以所对接版本的《ManageOne 北向接口参考》为准。 

结论：文生图选型别只看榜单分数，要按业务场景做三件事——明确出图用途、用自有提示词建小样本评测集、再把推理成本和并发纳入决策。一、先分场景。商品图、海报类最看重文字渲染与版式准确性；插画与概念图更看重风格一致性和构图可控；带中文字样的营销物料，要重点测中文渲染水平。二、建自己的评测集。挑20至30条真实业务提示词，覆盖短提示、长提示、含中文字样、多主体、指定风格五类，固定随机种子同条件出图，按可用率打分（可直接商用、微调可用、不可用）。这比任何公开榜单都更贴近你的业务。三、看可控性而不只看画质。检查是否支持参考图与风格参考、局部重绘、尺寸与比例约束、批量出图一致性；工程接入要看API是否支持异步任务、返回图片地址的有效期、并发与QPS限制。四、算综合成本。单张可用图成本等于单次调用单价除以可用率，可用率低的模型即使单价便宜也可能更贵；高并发场景还要把排队时延算进去。五、灰度验证。先小流量A/B，测端到端时延、失败率、人工返工率，再确定主力模型加备用模型的组合。验证方法：同一批提示词在两个模型上各出50张，记录可用率与单张成本，连续跑三天看稳定性，再对比候选方案做最终决策。

结论：文生图选型别只看榜单分数，要按业务场景做三件事——明确出图用途、用自有提示词建小样本评测集、再把推理成本和并发纳入决策。一、先分场景。商品图、海报类最看重文字渲染与版式准确性；插画与概念图更看重风格一致性和构图可控；带中文字样的营销物料，要重点测中文渲染水平。二、建自己的评测集。挑20至30条真实业务提示词，覆盖短提示、长提示、含中文字样、多主体、指定风格五类，固定随机种子同条件出图，按可用率打分（可直接商用、微调可用、不可用）。这比任何公开榜单都更贴近你的业务。三、看可控性而不只看画质。检查是否支持参考图与风格参考、局部重绘、尺寸与比例约束、批量出图一致性；工程接入要看API是否支持异步任务、返回图片地址的有效期、并发与QPS限制。四、算综合成本。单张可用图成本等于单次调用单价除以可用率，可用率低的模型即使单价便宜也可能更贵；高并发场景还要把排队时延算进去。五、灰度验证。先小流量A/B，测端到端时延、失败率、人工返工率，再确定主力模型加备用模型的组合。验证方法：同一批提示词在两个模型上各出50张，记录可用率与单张成本，连续跑三天看稳定性，再对比候选方案做最终决策。

规格选型的核心不是"选大的"，而是把不确定的成本换成可度量的容量。我按"量化基线—定族定规格—成本结构—复盘降配"四步来做，供参考。第一步，先用数据把需求量化。上线前至少采集一到两周的 CES 监控，重点看 CPU 使用率、内存使用率、内网出入带宽、磁盘 IOPS 与写入时延的 P95/P99，而不是平均值。平均值会掩盖尖峰，按尖峰翻倍选规格又浪费。经验做法是按 P99 峰值再加 20%~30% 余量作为初始规格，业务有明显大促的，把历史大促峰值单独作为一条基线。第二步，按瓶颈类型选规格族，而不是只看核数。Web 前端、微服务、中间件代理这类均衡负载选通用型（1:2 或 1:4）；Redis、ES、大堆 JVM 这类内存敏感型选内存型（1:8），否则容易出现 CPU 空闲但频繁 GC；视频转码、离线计算、编译构建选计算型；数据库和消息队列要额外关注云硬盘的 IOPS 与吞吐，普通 IO 盘在小块随机写场景会先成为瓶颈，必要时用超高 IO 或本地盘。网络侧还要看实例的 PPS 和内网带宽上限，网关、NAT、压测机这类小包高并发场景，vCPU 够但 PPS 打满一样会丢包。第三步，把固定成本和可变成本分开处理。长期稳定运行的在线服务用包年包月或预留实例，价格明显低于按量；有明显潮汐的业务用弹性伸缩组，配上定时策略和基于 CPU/队列深度的阈值策略，把最小实例数压到能扛住低谷流量的下限；可中断的离线批处理用竞价（Spot）实例，配合可重试的任务设计；测试和预发环境设置定时关机或资源到期释放，这是最容易漏掉的隐性成本。第四步，把复盘固化下来。每月拉一次监控报表，看 CPU 与内存 P95 长期低于 20% 的实例直接降配，长期高于 70% 或已出现排队时延的先横向扩实例再考虑升配；磁盘和带宽按实际用量单独评估，带宽在峰值利用率低但波动大的场景用按流量计费更划算。降配前先在灰度环境压测，避免把余量削到没有。一句话总结：用 P99 定容量、用规格族匹配瓶颈、用计费模式和弹性策略削峰、用监控复盘持续纠偏，成本和性能就不需要二选一。