核心原则：面向生产的结论必须经过验证。涉及数据库操作、SQL、架构方案、参数调优、迁移升级的内容，作者应在测试/演练环境实际跑通，写清数据库及版本、环境、数据规模与风险点；涉及不可逆操作必须给出备份与回滚方案。

原创技术文章至少两人经手：作者负责实操与写作，版主/审稿人负责核对关键步骤并评估风险。官方文档可引用，但不替代验证。

ITPUB 以数据库（关系型/国产/分布式）、企业架构、开发与运维为核心，强调严谨与生产安全。

技术文章统一用 10 分制做质量评价（用于精华与推荐），由各质量维度加权得出。

未经验证、缺少风险说明的生产类内容，不予高分、不进精华。

文章来源必须在开头标清：

• 原创首发：作者独立完成并在 ITPUB 首发
• 原创转载：本人作品同步，注明出处
• 翻译：取得授权或符合许可，注明原文与链接
• 整理/汇编：基于官方文档等整理，列出来源

几条硬规矩

• 严禁抄袭、洗稿；转载翻译遵守许可并署名
• 厂商软文、产品推广须显著标注并与技术内容分离
• 技术结论不受厂商干预，利益关系须声明
• 涉及数据库厂商的对比评测须口径一致、数据可核

引用数据、结论、执行计划、代码，须写清来源（官方文档/手册/论文/仓库）、版本与日期，有链接附链接；杜绝无源表述。

执行计划、测试结果、对比数据等原始材料应保留，便于读者核验。

发布后发现错误须公开勘误，不得偷偷修改；可能影响他人生产的错误应优先处理。

勘误通道：文章下方「报错/补充」；邮件 edit@itpub.net；私信版主。

原创/精华内容走多级审核：

质量评分 = 各维度评分 × 权重之和；每维度10分制，加总保留一位小数。

权重调整需编辑团队与首席版主审批。

各维度依据可核对证据（是否验证、风险是否闭环、有无真实案例）在 1–10 分评定后加权。设硬门槛：缺验证或缺风险/回滚说明的生产类内容不得进 8 分。

• SQL/方案是否在演练环境实际验证过？
• 数据库版本、环境、数据规模写清了吗？
• 不可逆操作是否给出备份与回滚方案？
• 来源与许可标注了吗？
• 风险点和影响范围说清了吗？
• 引用的数据/执行计划是否有出处？
• 是否存在未验证就下结论的内容？
• 代码块、配图、排版是否清晰？
• 推广性质或利益相关声明了吗？
• 是否设置勘误/补充的反馈入口？

核心验证表

控制变量

所有 SQL 与操作须在与生产同版本的演练环境执行通过，注明数据库类型、版本、隔离级别、数据规模与字符集；执行计划类结论以实际计划为准，不得仅凭经验推断索引行为。

评价口径

运维步骤须按执行顺序给出命令、预期结果与异常分支；高危操作须显式标注风险等级与影响范围。性能类 SQL 须给出优化前后执行计划与耗时对比。

生产红线 · 硬性门槛

核心验证表

控制变量

切换演练须在与生产相同版本和近似规格的环境进行，明确演练范围、观察指标与停止条件；监控、告警与值班联络须在演练前核对，禁止在无回切方案的情况下开始演练。

评价口径

高可用结论以演练实测的 RTO/RPO 数据表述；备份类内容必须包含恢复成功证据，仅有备份任务截图不算验证。须区分自动切换与人工切换的适用条件。

生产红线 · 硬性门槛

核心验证表

控制变量

方案须绑定明确的业务规模与版本前提，关键数据（性能、容量）须有可核对的基准来源；引用行业案例须注明场景差异，避免把不同量级的架构直接类比。

评价口径

评审重点是权衡是否清晰、风险是否闭环、是否可落地；拓扑图之外必须有决策依据与容量测算。对「银弹式」方案（声称无缺点的架构）从严审核。

生产红线 · 硬性门槛

核心验证表

控制变量

正式割接前至少完成两轮端到端演练，割接排期以演练实测耗时为准，不得按理想时长估算；数据校验口径（记录数、checksum、业务抽样）须在演练前固定并经业务方确认。

评价口径

迁移结论须包含一致性校验证据与割接窗口数据；须显式说明增量追平策略、业务停机时长与回滚判定条件。仅描述工具用法而无演练与校验过程的内容按一般教程评定。

生产红线 · 硬性门槛