当前位置：首页 > news >正文

怎么做企业网站建设东莞seo建站投放

news 2025/11/1 10:45:50

怎么做企业网站建设,东莞seo建站投放,wordpress伪静态很慢,做网站的工作要求本文将分享 B 站数据质量保障体系的建设和实践。文章将关注数仓和建模的相关方法论#xff0c;讲解 B 站数仓平台团队在数仓建设和建模过程中所做的工作#xff0c;并分享质量保障方面取得的成果。一、背景目标首先#xff0c;分享一下 B 站数据质量保障的背景和目标。 …本文将分享 B 站数据质量保障体系的建设和实践。文章将关注数仓和建模的相关方法论讲解 B 站数仓平台团队在数仓建设和建模过程中所做的工作并分享质量保障方面取得的成果。一、背景目标首先分享一下 B 站数据质量保障的背景和目标。 B 站数据建设的历史演进可以分为四个阶段。数据库阶段。在这个阶段B 站处于初创阶段业务也在初步发展中数据逐渐受到各方的重视。这一阶段的质量保障重点在于设计测试用例、验证数据正确性并进行数据库的监控和调优。数据仓库阶段。这个阶段的出现是因为随着业务的发展各方对数据的需求也日益增加更加关注 OLAP 相关的需求。随着业务的复杂性增加我们意识到单一数据库无法满足需求。这一阶段更加注重数据的完整性、准确性、一致性和及时性的保障。数据平台阶段。随着中国互联网浪潮的兴起数据量急剧增加随之进入了数据平台阶段。在传统的 OLAP 分析系统如TeraData和 SaaS 传统分析系统中面对大数据场景数据无法有效地服务于应用分析体系。因此我们逐渐引入开源生态系统如 Hadoop 和相关开源组件。这个阶段更加关注保障架构的质量包括链路的可用性和数据加工链路的多样性以及实时链路。中台阶段。不仅要承接前三个阶段的数据和需求还要着重解决业务问题和数据化的核心需求。在这个阶段业务逐渐多样化要求能力服务化和数据智能化。在质量保障方面兼容了前三个阶段的内容并基于这些内容展开了一些延展讨论。这将是接下来分享的重点。这里想强调的一点是数据质量保障是持续发展的。只有了解不同阶段的背景和目标才能更好地实现数据质量保障。 B站数据中台当前数据架构如下图所示。整体上分为四个层次自下而上分别是数据源、数据平台、数据中台和数据应用。数据源包括多个相关的服务系统如账户系统、埋点系统、CRM 系统和第三方系统等。这些系统为我们的数据仓库提供持续的数据这些数据通过数据平台进行集成并具备离线和实时的能力将数据导入到数据仓库体系中。在部分场景下我们推进全域数据的中心化建设。在此基础上再进行相应的主题域拆解这是互联网行业常见的主题域划分包括用户主题、交易主题、内容主题、营销社区等。此外我们还进行了更多类似于分析项的体系化建设。在数据应用层面可以简单地分为 PC 端和移动端的数据应用。我们着重关注埋点分析看板包括增长、运营、内容等方面的数据展示。我们可以看到数据的流转管道即数据管道已经扩展得非常庞杂。与传统的数据仓库不同质量保障不再仅仅基于单一的 OLAP 系统而可能涉及多层次、多组件、多团队甚至多部门之间的合作和沟通以推进保障工作。随着业务的发展对数据质量保障的需求也日益增加。下图中展示了一些来自与我们合作频繁的团队的反馈这些反馈涉及到日常合作中经常出现的问题。这进一步证明了数据质量保障的需求随着业务的发展而增加。我们收集到的反馈包括但不限于以下几点首先分析看板的页面显示数据没有展示透出这可能会影响用户体验。其次分析师可能会反馈某天的数据指标为零是否合理因为这可能会影响他们的业务决策。此外开发同学也有数据质量方面的需求比如夜间的值班报警电话频繁响起起夜率爆表等这会严重影响同学们的正常作息。基于以上情况我们抽象出三个方面的核心保障痛点数据使用方希望数据能够按预期时间产出并且数据准确可信。在故障发生时希望能够快速恢复不影响正常使用。作为数据建设方我们需要根据业务发展的时间推演确定哪些数据是用户真正关注的优先进行强保障而对于长尾部分可以适当降级。开发同学也希望了解用户对数据质量和时效性的具体要求。管道方是与数据仓库协同配合的兄弟团队他们对于流转到其管道中的数据也有保障需求。因为作为数据链路的上下游相关方任何一个节点出现问题都可能导致数据不准确数据质量不达标。他们的诉求更多是在极端情况下的恢复响应要求以及不同场景的保障要求。总体目标是通过持续改善数据质量减少事故纠错成本降低数据使用风险并提升业务服务满意度。让我们进一步深入探讨了解质量问题产生的根本原因。我们进行了一些梳理将其分为四个部分技术原因。数据经过多个层次的加工才得到最终结果因此不同链路的标准制定对于数据质量至关重要。这包括模型设计的合理性是否充分理解数据的业务含义并根据此进行相应的数据加工以获得准确的结果。此外数据采集和清洗过程是否符合标准规范也是关键。业务原因。数据主要承载业务的表达。脱离了业务场景数据往往就不再有任何价值。因此如果对业务理解不到位包括业务流程的变更没有及时了解都会影响最终数据质量的展现。管理原因。首先流程管理是否足够完善是一个重要方面。其次团队成员是否具备足够的质量保障意识也很关键。第三奖惩机制的设立也是必要的。因为质量保障是一个严肃的话题一旦出现问题我们需要有明确的责任分配计划以引起大家对此事的关注并确保日常数据的持续保障。推进方面的原因。一旦确立了相关标准我们需要将这些准则明确地推进到各个工作的细节中以确保历史相关问题不再重现。此外长期的可持续优化策略对于数据质量的保障也非常重要。根据以上对问题原因的梳理我们总结了三个主要方向上的痛点首先是整体数据质量保障的范围和目标不够清晰。这体现在各个团队对需要保障的数据范围缺乏清晰的认识有些链路甚至没有进行日常的保障。并且保障分级不够准确导致无法区分不同能力投入的保障需求。随着数据建设的推进架构变得越来越复杂。保障目标没有拆解到相关团队导致这些团队没有进行相应的保障工作影响了数据保障的最终结果。另一方面的痛点是无法衡量保障效果。我们上学时都对分数有着深刻的体验分数可以衡量学习的好坏。同样的逻辑也适用于数据质量保障但我们无法衡量我们的保障工作对整体目标的贡献。其次是当前保障推进到什么阶段缺乏相应的指标来指导和持续优化需要持续衡量的方法论。第三个方面的痛点是整个保障机制的规范性还不够完善大多是单点保障。然而当前的发展趋势是数据上下游链路需要协同解决这些问题。基于刚刚介绍的背景、痛点和发展趋势我们总结出了四个重点的保障目标。第一个保障目标是准确识别核心场景并支持数字化的效果衡量以提升待办事项的信息化水平。第二个保障目标是确保数据满足四个基本原则完整性、准确性、一致性和时效性。同时还需要满足各个用户实际场景的定制化需求。第三个保障目标是确保数据保障贯穿整个数据生命周期的全链路。包括事前、事中和事后涵盖数据的生产、传输、加工、组装和服务等各个环节。第四个保障目标是基于日常保障工作的经验沉淀方法论并推进数据中台相应的工具能力建设支持在预防、响应、处理、恢复和复查等阶段高效地解决问题。二、体系架构基于上述目标我们以质量数仓建设为基础构建三大核心能力完备的质量保障体系、数字化驱动持续优化以及高效的故障处理能力。 1、质量数仓建设首先我们引入相关的保障服务数据统一数据仓库的建设并依托数据中台的能力快速构建数仓架构。完成数仓架构后我们将以数仓质量数据为指引描述相应的保障问题并支持决策数据的使用。同时数仓的数据将支持日常的数据检测和分析等工作以消除事前的问题。数仓还有一个核心的保障工作即与相关团队协商保障目标并进行衡量和拆解。整个架构可以分为四个层次自下而上分别是数据源、数仓建设、分析项目建设和最终的应用。在质量数仓的数据源层包括了告警服务、基线服务、DQC服务、血缘数据、事件管理和值班系统等相关的数据服务系统。我们将这些系统的数据统一导入到数仓中并进行相应的分层建设。在分层方面我们进行了明细层、进度汇总层和高度汇总层的区分。在这些分层中我们将保障效果的数据进行抽象包括异常清单和告警情况并进行相应的数据建设最终呈现在看板上。这为数仓团队和横向团队提供了数据能力包括质量分运营看板、实时保障看板和告警归因看板等一系列数据服务能力。在质量数仓的基础之上接下来是三个核心能力。 2、完备的质量保障体系第一个核心能力是完备的质量保障体系。目标是确保数据满足用户要求。各方需要对数据质量负责并按照标准监控数据质量。我们会沉淀规则库为实现保障目标提供服务并推进可持续改进计划。这一核心能力可以进一步拆解为三个部分。第一部分是构建监测体系。在这个体系中我们将通过数据资产的定级来触发加工链路的卡点校验并进一步监控数据风险点。这包括常见的数据保障实体、基线任务和模型并通过这些来衡量数据质量的效果。其次是构建质量分衡量机制并支持从多维度的视角进行衡量。最后是制定保障规则并识别各个数据资产的待优化项。在这个过程中有两个重要的方面需要提及第一个方面是卡点校验规则库这个规则库主要涵盖完整性、一致性、有效性和及时性等与数仓传统卡点校验相关的内容我们在此基础上将进一步扩展到埋点、集成、加工、组装、出仓和 API 服务等相关环节第二个方面是建立事故归因知识库这个知识库主要用于归因相关的问题并结合告警和恢复工具的能力提高用户解决问题的效率降低异常成本。第二部分是部门间的协同保障。数据中台的链路已经相对复杂因此如何与数据中台的上下游相关方协同合作共同制定符合 SLA 保障标准的机制并形成跨团队的保障机制是非常重要的保障环节。这里重点介绍夜间值班的情况。夜间值班的流程包括紧急跟进、原因定位、数据恢复和影响通知。数仓团队的值班同学会触发卡点校验的告警监控。一旦触发我们会立即采取止损措施并评估数据是否对业务产生潜在影响。如果有影响我们会及时通知相关方并将问题转交给兄弟团队进行跟进和数据恢复。恢复完成后我们会再次通知相关业务方并对整个事项进行归档。第三部分是推进日常运营。日常运营化是指周期性地同步基于质量数仓产出的保障核心指标和目标的情况确保其达到标准。同时我们会定期回顾过去一段时间的历史问题并进行规则的沉淀和归类以避免类似问题的重复发生。我们会定期确定保障项目的效果推动代办人员进行相应事项的完善。在推进过程中我们对保障目标进行了抽象并确定了衡量和提升的方法。基于当前中台的核心衡量维度我们关注数据的完整性、一致性、准确性和告警响应度以及监控的覆盖率、作业稳定性、时效性和链路保障率等方面。我们还基于八个维度构建了质量分满分为 100 分并将其拆分为多个维度。通过质量分我们可以衡量当前保障工作的进展和目标。接下来我们将基于质量分来分发待办事项。例如对于模型监控覆盖率方面我们会提醒相关人员进行相应的操作如配置完整性检查和逐渐重复检查。 3、数字化驱动持续优化第二大核心能力是数字化驱动的持续优化。在这一部分我们主要关注在构建基于源数据的数仓体系后的决策判断。我们的推进策略按照以下链路进行管控首先是构建衡量指标然后进行现状分析的描述接着基于数据发现问题并提出解决方案最后持续跟进优化效果。整体目标是通过数字化的衡量来驱动质量保障并持续提升保障效果。 4、高效的故障处理能力第三大核心能力是高效的故障处理能力。根据过去的保障实践经验质量问题是难以避免的。在面对质量保障问题时我们需要快速响应将问题最小化甚至在短时间内实现快速恢复以确保用户无感知。这是一个重要的方向。基于此我们进行了一些功能支持和方法论的设计。从数据开发的视角提供了机械风险诊断、告警能力优化、故障恢复系统和规则配置系统等。另外从底层服务的视角致力于构建一键恢复的故障链路、分级全链路保障和统一运维值班机制。目标是通过日常保障实践来沉淀方法论持续打磨产品能力提升数据质量标准。同时我们也致力于优化故障响应效率降低夜间值班的成本。三、案例分享接下来分享B站在保障方面的一个实际案例。以上是数据开发的正常流程包括任务上线、日常跑批的监控覆盖以及可能触发的告警。在发生问题后我们会进行相应的响应和数据恢复并推动问题的归档。在开发阶段我们面临的问题是线上待保障的任务较多。目前我们已经有超过五千个核心任务但整个保障事项的监控覆盖率不足 50%。此外我们还存在监控覆盖缺乏审批规则和发布流程相对不完善的问题。在值班阶段我们面临的问题是值班响应的 SOP 流程不完善跟进效率较低。夜间故障信息同步链路也不完善。同时我们的夜间值班率较高达到了50%左右。这意味着每周大约有三到四天需要有同学进行夜间值班来响应故障。由于故障经常发生恢复时间较长人力投入也较大。在复盘阶段我们发现许多问题并不是由数仓的日常操作引起的同时也有一些反复出现的保障问题。总结起来这些问题可以归结为三个方面数据链路过长且组件过多不知从何处着手进行保障当前的保障指标表现不佳能推进到什么程度心里没底不知是否有推进套路可以借鉴。在初始阶段大家的保障意识薄弱。随着时间的推移我们逐渐进入了起步阶段推进人员开始意识到保障的重要性。随着保障工作逐步推进形成了方法论进而建立了相应的分级保障机制。之后逐渐进入了基于质量数仓的量化管理阶段。我们可以基于特定的指标对事项进行拆解并衡量数据目标的达成情况从而推动持续优化的工作。整个推进思路按照以下三个步骤进行推演数据链路的拆解、保障分级的建设以及全生命周期的覆盖。在数据链路拆解环节我们将中台链路简图进一步抽象成数仓的建设流程。包括从埋点数据转入数仓加工数仓模型校验和数据服务构建API 构建最终将数据出仓给服务应用。在这个过程中我们还可以抽象出保障的数据实体。当前的中台保障实体包括埋点、离线和实时项目任务模型表、Kafka 主题模型字段数据指标数据基线以及数据基线 API 等相关实体。保障分级建设。在许多公司和数仓建设的初期阶段对保障的意识可能不够完善。随着业务的发展大家逐渐认识到质量保障的重要性。在实施保障分级的链路中我们按照以下方法论进行迭代推演确定分级标准评估数据现状完成数据的分级并基于分级推动持续优化。预期的收益是能够梳理出整个核心保障链路的数量并推进重要分级保障场景的覆盖率。通过这样的工作我们可以明确讨论哪些数据是重要的并与相关的上下游方制定相应的保障策略。刚刚我们也提到了保障分级建设的思路。全生命周期的覆盖。前文提到了基于数据实体的抽象针对这些抽象后的实体我们将跟进相应的事前、事中和事后的保障机制。事前阶段包括埋点数据的准备、开发阶段的监控标准以及发布阶段的准备工作。在事中阶段我们会进行卡点校验、值班机制的执行以及事故的修复工作。在事后阶段我们重点关注事件的反馈、保障的衡量进行事后复盘并沉淀到知识库中。这里再介绍一个B 站保障中存在的痛点问题即公司层面进行机房迁移工作时对数仓保障施加了巨大压力。由于各个组件服务的混部部署机房迁移会导致极大程度出现告警并且一旦出现告警由于基础服务的原因会导致全链路的击穿。因此在多重原因复合的情况下进行告警原因归类成为迫切需要解决的问题。项目挑战在于单次告警计算涉及全链路并触发大量告警同时涉及所有任务的 OWNER。在极端情况下连续五周工作日的夜间值班率达到 80%以上。这种情况下数据异常和修复成本都极高峰值时达到单次事故 80人天。基于上述情况我们首先将所有的告警梳理到数仓的相关链路中并对其原因进行归类。通过原因的归类进一步确定问题是由平台方、工具方还是数仓相关原因引起的。基于这个归类我们建议优先推进解决这些主要问题并与相关方对齐优化方案和规则的后续覆盖。通过保障体系的建设和推进我们的整体保障情况符合预期。事件数在三个季度的优化过程中呈下降趋势降低了 50%。事件捕获率趋近于 100%数仓起夜天数也呈下降趋势降低了55%。核心基线破线数逐步收敛近三个季度中逐季累降。起夜人次相较于保障之前已经下降了59%。夜间耗时也下降了 86%。结合保障分级的推进我们也清楚梳理了核心场景的范围并进行了相应的保障率的推进达到了 100%。在整个保障推进过程中我们也发现了一些问题。保障的入手比较困难因为保障事项本身具有一定的学习成本并且涉及的范围较广。同时如何选择合适的推广路径也是一个较大的问题。推进落地比较困难。目前一些相关规范的推进仍然依赖人工的推动需要有更好的方法来提高效率。可视化效果不足。正如之前提到的我们通过质量分来衡量保障情况但还需要更好的可视化方式来展示结果。工作仍然容易陷入运动式治理缺乏可持续的效果。我们在 B 站数据平台部门贡献了方法论并开发了相应的治理平台。通过这个平台我们可以衡量规则、代办事项以及未完成操作的同学并嵌入到平台组件中以支持快速点击、覆盖和响应。四、未来展望未来的工作主要分为两个方向。第一个方向持续扩大保障范围丰富保障策略继续践行数据化驱动的方法在保障存量可控的基础上持续提升增量覆盖优化。第二个方向理论结合实践持续推进工具化能力迭代支持完善沟通机制。最后随着质量保障工作的发展我们希望从最初的手工操作阶段逐渐进入信息化阶段进而推进到智能化阶段。在智能化阶段随着保障方法论和规则库的沉淀丰富通过产品化能力支持最终做到质量保障可描述、好衡量、易操作。五、问答环节 Q:数据质量分有八项规则构成但每个表的规则、数量、规则重要性都不一样。怎么做到所有表的拉齐? A:在B站我们按照五个分级等级进行数据质量保障重点关注线上数据如 BOSS看板和公司级分析产品。基于此我们制定了各个保障分级的规范标准。例如针对线上服务的数据模型我们制定了一系列质量规则。除了基础规则如表组件的唯一性规则配置和表行数规则配置我们还推进了基于该模型上游埋点数据的规则如一致性校验和跨省校验。同时针对最高优先级的分级场景我们还配置了及时性规则以验证线上服务的基线情况。对于较低级别的分级场景我们仅配置基础规则以确保基本模型的可用性。 Q文中提到了一个实时任务是部署在一个系统平台的 Flink任务。如果不是在不同的平台维护怎么拉齐评估整体的数据质量 A:在过去的一段时间里我们重点推进了解决一个问题即在不同平台配置的情况下我们无法获取相关信息的挑战。在B站内部由于涉及跨部门的情况不同部门的调度系统也存在不一致性。为了解决这个问题我们的推进思路是将易购平台的原始数据信息同步到质量数仓中基于相同的链路进行规范和代办事项的梳理。并按照规范的数据格式进行整理。整个链路可以复用最终可以呈现类似于质量分和代办事项的结果。 Q复盘的时候出现最多的是什么问题有什么加速排查的工具吗 A:第一个问题在复盘过程中最常见的问题取决于不同阶段。在保障的初级阶段最常见的问题是告警爆炸或告警湮没的情况即告警数量非常多。在这个阶段我们面临的问题是如何从大量的告警中提取有效的告警。针对这个问题我们的重点工作是首先如何有效地降低告警数量同时确保现有规则的生效和保障结果不受影响其次针对无效告警的原因进行进一步分析以不断调整保障规则的内容。有些规则内容可能会随着时间和迭代的过程进行更替。第二个问题我们正在与协同的产品团队和开发团队一起重点推进即加速排查工具的开发。这是为了解决告警数量过多的问题。我们的目标是建立一个事故知识库并基于该知识库进行合理的告警分发。通过这个知识库的分发我们可以将告警合理地分发给相关的团队从而减轻数仓层面的值班压力。这样相关团队可以更快速地进行排查和处理。
文章转载自：
http://www.morning.ptzf.cn.gov.cn.ptzf.cn
http://www.morning.rcgzg.cn.gov.cn.rcgzg.cn
http://www.morning.mxptg.cn.gov.cn.mxptg.cn
http://www.morning.kmbgl.cn.gov.cn.kmbgl.cn
http://www.morning.nrydm.cn.gov.cn.nrydm.cn
http://www.morning.lkbdy.cn.gov.cn.lkbdy.cn
http://www.morning.rdfq.cn.gov.cn.rdfq.cn
http://www.morning.fqmcc.cn.gov.cn.fqmcc.cn
http://www.morning.wgbmj.cn.gov.cn.wgbmj.cn
http://www.morning.pbksb.cn.gov.cn.pbksb.cn
http://www.morning.tklqs.cn.gov.cn.tklqs.cn
http://www.morning.prgnp.cn.gov.cn.prgnp.cn
http://www.morning.lqjlg.cn.gov.cn.lqjlg.cn
http://www.morning.xnpj.cn.gov.cn.xnpj.cn
http://www.morning.sldrd.cn.gov.cn.sldrd.cn
http://www.morning.yodajy.cn.gov.cn.yodajy.cn
http://www.morning.bnjnp.cn.gov.cn.bnjnp.cn
http://www.morning.qmkyp.cn.gov.cn.qmkyp.cn
http://www.morning.jmdpp.cn.gov.cn.jmdpp.cn
http://www.morning.dfltx.cn.gov.cn.dfltx.cn
http://www.morning.xhddb.cn.gov.cn.xhddb.cn
http://www.morning.nmkfy.cn.gov.cn.nmkfy.cn
http://www.morning.zshuhd015.cn.gov.cn.zshuhd015.cn
http://www.morning.mzwfw.cn.gov.cn.mzwfw.cn
http://www.morning.fxxmj.cn.gov.cn.fxxmj.cn
http://www.morning.nlysd.cn.gov.cn.nlysd.cn
http://www.morning.qxlgt.cn.gov.cn.qxlgt.cn
http://www.morning.srwny.cn.gov.cn.srwny.cn
http://www.morning.wnpps.cn.gov.cn.wnpps.cn
http://www.morning.pkwwq.cn.gov.cn.pkwwq.cn
http://www.morning.sjzsjsm.com.gov.cn.sjzsjsm.com
http://www.morning.djpzg.cn.gov.cn.djpzg.cn
http://www.morning.wjhnx.cn.gov.cn.wjhnx.cn
http://www.morning.rhmpk.cn.gov.cn.rhmpk.cn
http://www.morning.hxpsp.cn.gov.cn.hxpsp.cn
http://www.morning.ngcth.cn.gov.cn.ngcth.cn
http://www.morning.kndt.cn.gov.cn.kndt.cn
http://www.morning.rcbdn.cn.gov.cn.rcbdn.cn
http://www.morning.xjmpg.cn.gov.cn.xjmpg.cn
http://www.morning.mdjzydr.com.gov.cn.mdjzydr.com
http://www.morning.nkkr.cn.gov.cn.nkkr.cn
http://www.morning.dkbgg.cn.gov.cn.dkbgg.cn
http://www.morning.wjxyg.cn.gov.cn.wjxyg.cn
http://www.morning.mwhqd.cn.gov.cn.mwhqd.cn
http://www.morning.pjtw.cn.gov.cn.pjtw.cn
http://www.morning.qgdsd.cn.gov.cn.qgdsd.cn
http://www.morning.playmi.cn.gov.cn.playmi.cn
http://www.morning.kdnrc.cn.gov.cn.kdnrc.cn
http://www.morning.cbnjt.cn.gov.cn.cbnjt.cn
http://www.morning.kndyz.cn.gov.cn.kndyz.cn
http://www.morning.hbxnb.cn.gov.cn.hbxnb.cn
http://www.morning.ppghc.cn.gov.cn.ppghc.cn
http://www.morning.hxgly.cn.gov.cn.hxgly.cn
http://www.morning.xnzmc.cn.gov.cn.xnzmc.cn
http://www.morning.mmplj.cn.gov.cn.mmplj.cn
http://www.morning.jrsgs.cn.gov.cn.jrsgs.cn
http://www.morning.nwzcf.cn.gov.cn.nwzcf.cn
http://www.morning.bsjxh.cn.gov.cn.bsjxh.cn
http://www.morning.bnzjx.cn.gov.cn.bnzjx.cn
http://www.morning.jrqbr.cn.gov.cn.jrqbr.cn
http://www.morning.wclxm.cn.gov.cn.wclxm.cn
http://www.morning.ycmpk.cn.gov.cn.ycmpk.cn
http://www.morning.jgmdr.cn.gov.cn.jgmdr.cn
http://www.morning.ksggl.cn.gov.cn.ksggl.cn
http://www.morning.kxbry.cn.gov.cn.kxbry.cn
http://www.morning.zkqsc.cn.gov.cn.zkqsc.cn
http://www.morning.wddmr.cn.gov.cn.wddmr.cn
http://www.morning.hbxnb.cn.gov.cn.hbxnb.cn
http://www.morning.tkyxl.cn.gov.cn.tkyxl.cn
http://www.morning.wjtwn.cn.gov.cn.wjtwn.cn
http://www.morning.spfq.cn.gov.cn.spfq.cn
http://www.morning.hffpy.cn.gov.cn.hffpy.cn
http://www.morning.sgwr.cn.gov.cn.sgwr.cn
http://www.morning.jkpnm.cn.gov.cn.jkpnm.cn
http://www.morning.fglth.cn.gov.cn.fglth.cn
http://www.morning.nzcys.cn.gov.cn.nzcys.cn
http://www.morning.wgdnd.cn.gov.cn.wgdnd.cn
http://www.morning.tzzkm.cn.gov.cn.tzzkm.cn
http://www.morning.ltqzq.cn.gov.cn.ltqzq.cn
http://www.morning.stpkz.cn.gov.cn.stpkz.cn

查看全文

http://www.tj-hxxt.cn/news/267819.html