河流排水溯源监控系统方案建议书

官网：https://haomo-tech.com

作者：毫末科技

邮箱：hxg@haomo-studio.com

微信二维码

1 系统概述

随着我国经济的快速发展，以及人民生活水平的不断提高，工农业废水和生活污水的排放量逐年增加，使得城市河道受到了严重的污染。

城市河道污染主要来源于生活污水、工业废水、农业废水及雨水4个方面。城市河道严重污染带来的水环境恶化问题不仅影响着城市的正常发展，对城市居民的健康和城市生态安全也构成了严重威胁。解决城市河道水质污染问题，恢复河道的生态功能和社会功能，已成为确保城市可持续发展的关键。

我国的水质分类为:I,II,III,IV,V和劣V,共五类。 河流水质各项指标国家标准是III类。

• I类主要适用于源头水、国家自然保护区。
• II类 主要适用于集中式生活饮用水地表水源地一级保护区、珍稀水生生物栖息地、鱼虾类产卵场、仔稚幼鱼的索饵场等。
• III类 主要适用于集中式生活饮用水地表水源地二级保护区、鱼虾类越冬场、洄游通道、水产养殖区等渔业水域及游泳区。
• IV类主要适用于一般工业用水区及人体非直接触的娱乐用水区。
• V类 主要适用于农业用水区及一般景观要求水域。

企业偷排漏排比比皆是；现在的企业至少80%以上没有执行或严格执行达标排放。目前企业的偷排手段主要包括：

• 常年偷排：暗管
  • 中途接管，分流直排。
  • 暗设阀门，伺机偷排。
  • 私改设计，施工预留。
  • 大量蓄水，隐蔽偷排。打深井、挖大坑、埋长管。
• 临时偷排：卡车倾倒等（很难检测，可以对比供水量和排水量）

为了持续、有效的预防、监督偷排，需要有在线监测手段。主要包括以下两大方法：

• 进出水量监控。供水和排水相比对。
• 水质在线监测。多项监测指标多维度监控。

2 系统目标、意义及预期成果

河道水质在线监测是水资源保护工作的重点任务，是预防污染、水质预警的最重要的手段之一。通过自动在线监测仪器对水质进行无人值守实时监控，并利用现代信息技术、网络技术等主流技术进行数据采集、传输和存储，及时、准确地掌握水质状况和动态变化。水质在线监测系统体现了水环境监测技术手段的科学化和现代化，对环境保护决策部门及时做出有效水污染防治和管理等方面均有重要的意义。

本系统的目标是构建一套集监测、预警、溯源及信息化管理功能为一体的河流水污染预警溯源信息化监控系统，实现示范河段水环境质量的实时监测、污染超标预警及污染来源追溯等功能，为水务部门河道管理和决策提供有力的支撑和技术示范。

• 第一阶段目标：根据水务部门的关注重点，研究设计合理、科学的水污染预警溯源信息化监控系统架构，初步探索河流水污染监控信息的采集与传输、污染预警预报及其污染物源头定位等功能实现原理。
• 第二阶段目标：对典型河流开展详细调查，包括河道水文水质、周边土地利用，重点污染企业分布、入河排水口分布等，科学布设监测点位，实时监测河流水质信息，分析水质特征，采集河流水污染特征因子。研究不同企业的排水水质特点，采集河流沿线重点工业污染企业水质特征，构建水环境特征污染指纹图谱库，为开展水污染预警溯源定位提供支撑。
• 第三阶段目标：建立一套河流水污染预警溯源信息化监控系统，对多类、多源、异构的水污染信息进行管理，实现水污染的实时预警管理、污染物的溯源决策监控，为水污染信息的实时监测、准确分析、早期预警、及时处置提供全面的技术支撑。

预期成果：

• 构建一套集监测、预警、溯源及信息化管理功能为一体的河流水污染预警溯源信息化监控系统；
• 开展河流水污染预警溯源信息化监控系统构建研究；

3 系统需求

3.1 监测指标

河道水质在线监测一般采用浮标式监测系统。监测浮标是一种现代化的水质监测手段。采用浮标观测技术，可全天候、连续、定点地观测气象、水文等内容，并实时将数据传输到岸站。水质监测浮标可以将水质分析仪表、数据采集传输系统、供电系统等高难度集成在浮标上，浮标投放于湖泊、水库、养殖场等环境，故探头式的分析仪表最为合适。

常规理化五项：

• PH（重要）
• 温度（重要）
• 电导率（重要）
• 溶解氧（重要）
• 浊度（重要）

有机物污染指标：

• COD（重要）

营养盐指标：

• 氨氮（重要）
• 总氮（重要）
• 总磷（重要）

藻类监测指标：

• 叶绿素
• 蓝绿藻

特殊监测指标包括：

• 酚
• 氰
• 砷
• 铅
• 铬
• 镉
• 汞
• 有机农药

3.2 溯源分析

河水污染传播的过程中，涵盖以下几个重要元素：

• 源：污染源。排污企业、农田、居民住房等。
• 网：雨污管网。
• 厂：污水处理厂。
• 站：水质监测站。

溯源分析模块的建设，需要做到以下几点：

• 经济性：需要合理安排检测点位、合理规划监测指标，已达到最少的监测点、最少的监测指标，达到期望的监测效果。
• 持续性：需要全天候在线监测。
• 精准性：需要可以根据监测结果，精准溯源到污染源。

为了有效的开展溯源分析，需要在溯源分析模块中记录以下信息：

• 潜在污染源的基本信息、污染物信息；
• 排水管网地理拓扑信息；

对于每一次产生的污染超标告警信息，都可以自动计算出潜在的污染源，并做系统记录。

3.3 告警管理

不同级别的水质，有不同的水质标准：

告警管理包含以下几个组成部分：

• 告警触发条件：以国家水质标准为触发阈值。触发的规则，根据不同的监测指标和监测环境进行设置，例如连续n次超标告警、连续n分钟超标告警、一次超标即告警等。
• 告警对象：哪个监测点位、哪个监测项产生的告警。
• 告警接收组：告警信息发送给哪些人。
• 告警接收方式：以什么样的形式发送告警。包括邮件、短信、钉钉等。

所有的告警，均需要进行有效的处理，以达到最佳的监控效果。告警的分级处理流程，需结合对应环保部门的实际情况进行设定。

3.4 可视化及报表

为方便环保监督人员使用系统进行办公，需要提供直观的可视化工具及便捷的报表工具。

可视化的内容包括：

• 地理信息的可视化；
• 管网拓扑的可视化；
• 水质监测的时序可视化；

报表工具的内容包括：

• 图、表结合的报表呈现；
• 不同维度的报表分析；

4 方案建议

4.1 系统业务架构规划

4.1.1 总述

结合以上需求，可以将排水溯源监控系统划分为四层：

各层之间的关系如下图所示：

对上业务结构的说明如下：

• 传感层：传感设备接入灵活，可支持任意流量及水质传感数据的接入，而无需做过多的二次开发（传感器的传输协议可能需要单独开发）；
• 数据层：采用InfluxDB工业实时数据库，支持大数据量的状况下的高并发插入、大数据读取、数据压缩等特性。可支持PB级别数据存储。为了增强溯源分析的信息检索效果，需要将地理位置的相关音视频文件录入到本系统中。
• 后台服务层：采用Docker容器化部署方式，实现灵活的水平扩展，以支持高性能写入及分析操作。
• 用户层（Web/Mobile）：用户应用层支持用户的二次开发（提供Rest API）；Web具有所有的系统功能，Mobile的功能在Web的功能上进行了裁剪。

4.1.2 PC端业务架构

4.1.2 移动端业务架构

4.2 系统技术架构规划

4.2.1 设计原则

本项目建设应遵循如下几点原则：

4.2.1.1 总则

本项目建设应遵循“总体规划、分步实施、逐步优化”的总体发展原则，具体来说， 要规范流程和标准，系统开发和建设必须做到工作标准统一、业务流程统一、服务程序 统一。要采用行业、国家和国际标准化组织制定的有关技术规范和标准。保证信息流传 递快速顺畅，网络运行安全可靠。

4.2.1.2 安全性原则

系统必须具备安全性和稳定性。对于系统级，数据级，应用级，运行管理级设计完善的安全体系。同时，要辅以完整高效的备份恢复方案。

4.2.1.3 前瞻性原则

在系统建设中，要充分考虑未来业务的发展和管理的变化，方便新业务和新需求的扩展和支持，满足未来业务发展的需要。采用当前成熟的技术，符合国际、国内标准的软硬件技术规范。
软件设计思想成熟稳定，充分考虑平台系统与内部及外部系统之间的建设关系以及有可能产生的相互影响，符合金融业务发展需求。

4.2.1.4 扩展性原则

软件、硬件平台在系统容量、处理能力和业务应用等方面应具有良好的可扩充、扩展能力，能够方便地进行系统升级和更新，以适应业务量的不断发展；系统参数化、模块化程度高，局部的变更对系统的影响程度最低，能通过参数设置来对系统进行部分控制。要求系统软硬件升级平稳简单，升级测试简单，新模块上线不影响正常应用。要求系统具备很好的开放性，便于与其他系统对接。要求通过模块标准化设计尽量复用公共 模块，使日后新增应用也可复用公共模块，减少重复开发工作量。

4.2.1.5 灵活性原则

系统业务流程的设计要灵活，满足业务流程创新的需要，减少重复和交叉，以提高工作效率。系统应采用平台化建设方式，做到业务管理、定制与系统监控、维护的相对分离。

4.2.1.6 其他原则

系统设计原则还应包括稳定性原则、解耦拆分原则、抽象化原则、松耦合原则和容错设计原则，如下图所示。

为了达到系统的高可用、高扩展性和高并发的架构目标，需要从应用系统和数据库两个层面对系统进行拆分和扩展，比如在水平方向扩展应用系统的多机集群，通过读写分离和oracle RAC扩展数据的访问性能等，具体如下图所示。

4.2.2 标准化体系设计

4.2.2.1 标准体系建设方法论

标准体系建设的意义、目标及指导思想

标准化工作是组织、协调项目顺利发展的重要手段。通过制定和贯彻执行各类技术标准，就能从技术上、组织管理上把各方面有机的联系起来，形成一个统一的整体，保证项目有条不紊的进行。国内外信息化的实践证明，信息化建设必须有标准化的支持，尤其要发挥标准化的导向作用，以确保其技术上的协调一致和整体效能的实现。因此，标准体系建设具有非常重要的意义，是系统设计和工程建设的重要基石。

信息系统平台建设项目标准体系建设是一个复杂的系统工程，为保证标准体系建设的顺利进行，制定以下总体目标：

• 建立并不断完善信息系统平台建设项目标准体系，为信息系统平台建设项目建设提供支持与服务；
• 制定信息系统平台建设项目关键基础标准，为系统互联互通、信息共享、业务协同、信息安全打好基础；
• 建立信息系统平台建设项目标准贯彻实施机制，为标准的实施提供有效服务。

为了完成信息系统平台建设项目标准体系建设目标，必须本着“统筹规划、面向应用、突出重点、分工协作”的方针，依托现有资源和信息化工作的基础，坚持自主制定与采用国际标准相结合，加强与示范应用的有机结合，强化标准实施与监督力度，为信息系统平台系统项目建设提供强有力的支持、保障和服务。过程中具体遵循的原则为“统筹规划，借鉴经验；突出应用，狠抓关键；急用先上，循序渐进；搭建平台，集思广益；上下兼容，协调发展”。

4.2.2.2 标准体系结构

信息系统平台建设项目标准体系是按照总体技术参考模型和标准体系的定位，充分考虑标准体系的纵横关系制定的。

• 总体标准
  总体标准是指信息系统平台系统总体性、框架性、基础性的标准和规范。具体内容如设计标准体系框架、技术架构体系框架、标准化设计指南等等具有总体性的、原则性的标准和规范。
  总体标准主要是用来指导和约束具体标准（如应用标准体系、应用支撑标准、网络基础设施标准、安全标准、管理标准）的制定。
• 应用标准
  应用标准是标准体系建设过程中最主要的模块之一，涉及内容非常广泛。具体包括：业务标准、数据标准、信息模型标准、应用系统技术要求与接口标准。
• 业务标准
  业务标准主要是针对系统的业务应用需要设定的业务规范和操作标准。标准制定过程主要是通过对业务流程的梳理结合未来业务发展趋势制定相应的符合未来业务发展趋势及管理意图的业务规范和相应的操作标准。
• 数据标准
  数据是信息资源的重要表现形式和信息载体，数据标准是标准体系建设过程的关键环节。数据标准化建设具体包括：
  • 元数据标准：元数据标准是数据标准建设的根基，也是数据标准化建设的前提条件，需要结合实际业务需求以及国家相应的标准和规范制定符合要求的元数据标准；
  • 数据字典标准：数据字典是数据规范管理的重要工具，数据字典的标准制定要结合业务数据特点，基于国家相应的标准以及元数据标准之上制定；
  • 分类编码体系标准：分类编码体系标准化是对数据信息资源进行分析利用的前提，也是业务数据规范的重要依据。具体内容包括，编码规范、代码体系、以及代码变更标准体系；
  • 数据交换标准：数据交换标准是数据信息资源利用的重要标准，是保证数据信息资源有机互联的重要保证；
  • 数据目录体系标准：数据目录体系标准是建立数据资源检索体系的前提条件，是对数据资源规范管理的重要手段和依据。
  • 信息模型标准：信息模型标准，主要是针对信息化建设中业务应用系统的功能模型而制定的相应标准。
• 应用系统技术要求与接口标准 应用系统技术要求与接口标准，主要是针对应用系统建设过程中技术应用的标准体系以及应用系统接口规范的标准体系。
• 应用支撑标准
  应用支撑标准，包括为信息系统平台系统提供支撑和服务的标准，主要有信息交换平台、电子公文交换、消息管理、电子记录管理、日志管理和数据库等方面的标准。
• 网络基础设施标准
  网络基础设施标准，包括为信息系统平台系统提供基础通信平台的标准，主要有基础通信平台工程建设、网络互联互通等方面的标准。
• 安全标准
  安全标准，包括为信息系统平台系统提供安全服务所需的各类标准，主要有安全级别管理、身份鉴别、访问控制管理、加密算法、数字签名和公钥基础设施等方面的标准。
• 管理标准
  管理标准，包括为确保信息系统平台系统建设质量所需的有关标准，主要有工程验收和工程监理等工程建设管理方面的标准。

4.2.2.3 标准化工作任务

根据信息系统平台系统标准体系结构，对信息系统平台系统项目标准化工作需求进行详细分析，信息系统平台系统标准化工作任务包括以下三大部分：

(1)进行标准化总体设计

• 确定信息系统平台系统项目标准化目标。
• 确定信息系统平台系统项目标准体系框架。
• 建立信息系统平台系统项目标准化管理机制。
• 制定信息系统平台系统项目标准化指南。

(2)建立和完善标准体系

• 确定工程可用的我国标准。
• 研究确定拟采用的国际标准和国外先进标准。
• 制定所需的共性、基础性、关键性标准。
• 适时调整标准体系及重点标准制修订项目。

(3)加强标准贯彻实施

• 制定标准贯彻措施，加强贯彻的管理与检查。
• 开发相应的标准应用辅助工具。
• 与工程应用紧密结合，推行试行标准并根据试行情况对标准进行完善。
• 建立标准符合性评定机制，确保标准实施的有效性。
• 完善标准咨询与服务体系。

4.2.2.4 标准体系的建设

(1)标准体系建设过程

信息系统平台系统标准体系建设将是一项长期的基础性工作，需要根据信息系统平台系统建设的实际情况进行分阶段实施。根据信息化标准体系建设经验，信息系统平台系统标准体系研究制定过程可以划分为规划、研制、试用验证、培训与宣贯、应用示范、完善与实施等六个阶段，整体过程示意如下图：

(2)标准化工作平台

为了有效推进各阶段工作的顺利开展，必须建立信息系统平台系统标准化工作平台，向参与标准化工作的企业和专家提供所需要的工作环境和全程化的服务。

(3)数据标准化

数据标准化是信息系统平台系统标准化的基础，也是信息系统平台系统标准化的重点和难点。它是建立在对现实业务流程分析的基础上，围绕其业务职能范围，抽取出具有共性的业务模型和业务信息流，将其视图化地表示出来。数据标准化主要包括以下几个阶段：

• 业务建模阶段

是按信息工程的思想方法来重新认识各部门的职能域、业务活动及过程。在这一阶段中，需要各领域的业务专家和业务分析建模专家协同合作，对各领域的职能、业务活动和业务过程进行全面的业务梳理和需求分析，利用已有的业务建模标准和《业务流程设计方法通用规范》，使用业务建模工具和技术，对现实业务需求、业务流程及业务信息进行抽象分析，建立有效的覆盖整个业务领域的业务模型。

• 数据规范化阶段

是数据标准化的关键和核心，该阶段是针对数据元素进行提取、规范化、管理和对信息表示进行规范化的过程。该阶段首先根据业务建模阶段产生的业务模型，基于已有的数据元素标准和数据元素设计与管理规范，进行数据元素的设计与管理，也即数据分析与数据建模，然后产生一套完整的标准数据元素目录。根据所产生的数据元素目录，利用数据元素注册系统，并根据已有的信息表示标准和信息表示及信息分类规则，对数据元素目录中的数据元素进行信息表示规范化的设计，从而产生标准化的信息表示及信息分类目录。

• 文档规范化阶段

是根据业务建模阶段产生的业务模型，并根据数据规范化阶段产生的标准数据元目录和信息表示和信息分类目录，基于相关的文档格式管理法规和基于XML的电子文档格式设计指南，在业务专家、XML文档设计专家及XML文档设计工具，进行电子文档的设计，最终产生用于各类信息资源间信息交换和信息共享的各类电子文档和电子文档模型库，以实现各类信息资源间的信息共享的过程。因此，文档规范化阶段是数据规范化成果及信息共享的关键应用，是将各信息系统及各应用间的孤立信息集成并达到共享的有效途径。

(4)标准体系主要成果形式

信息系统平台系统标准化主要成果是标准文本，项目的文本成果表现为不同的形式：标准化指南、研究报告、技术报告、标准（报批稿）和教材，本项目完成时交付的主要成果及其形式如下：
关键性、基础性标准：本着急用先行，重点解决互联互通和信息共享的问题的原则，信息系统平台系统标准体系建设工作将首先启动关键性、基础性标准的制定工作。这些标准包括在前面的“信息系统平台系统标准化主要主要成果”中的总体标准、应用标准、应用支撑标准、网络基础设施标准、安全标准和管理标准(根据项目实施的实际情况选择实现)。

4.2.3 技术架构

4.2.3.1 技术架构目标

• 高性能

性能是考验一个网站的重要指标，网站响应的快慢直接导致了用户流失的程度。所以在架构设计中，性能是必须要考虑的条件。该架构方案中，我们会主要从前端、后端、存储等所有涉及用户请求的环节中，对于性能进行优化。例如采用负载均衡、动静分离、前端静态资源压缩、分布式服务、分布式缓存、分布式队列、读写分离等相关技术进行网站的调优。在编码过程中，采用多线程编程、异步调用等方式来满足高性能的需求。

• 高可用性

对于大型网站来说，网站宕掉、服务不可用是重大事故。可用性架构设计目标就是在服务器宕机的时候，依然能够保持服务或应用可用。该架构方案中，对于应用服务器，通过3层与7层结合的多级负载均衡组成集群共同对外提供服务，保证任何一台服务器宕机，其他服务依然可用。服务层架构通过分布式服务进行集群部署，保证每个服务都是无状态的，保证服务的高可用。存储层采用数据库读写分离，数据多级缓存，数据库实时备份等操作保证数据读写的高效性以及数据的可用性。

• 可扩展性

系统的需求是不断变化的，系统也随着快速发展，功能不断增多。传统的架构在适应网站的业务不断增长的时候，会出现臃肿的架构，导致维护越来越困难。该方案的目标就是满足网站的可扩展性，在增加新的业务产品时，在不做任何改动或者很少改动的前提下，保障产品的顺利上线运行。方案中，我们会考虑产品之间耦合严重的问题。同时在分布式服务方面，可以满足在增加不同业务产品的时候，只需要复用现有的业务或者增加新的服务，而不影响现有业务的开展，保证服务的可扩展。

• 可伸缩性

在网站面对高并发访问的关键时刻，网站的可伸缩性表现在，是否可以增加新服务器服务器来提供和原来一样的服务，来缓解不断上升的访问压力和存储需求。方案中，采用硬件负载均衡实现3层负载均衡，nginx反向代理作为7层负载均衡组成的两级负载均衡，多台应用服务器组成集群部署，可随意扩展应用服务器。服务层基于分布式服务框架dubbo，将应用的每个模块划分为单独服务，进行集群部署，通过zookeeper做负载均衡管理，在访问压力增加的时候，可通过增加服务器，启动服务来分担访问的压力，保障网站的可伸缩性。

• 安全性

互联网是开放的，各种web工具和数据泄密从未停止。架构的目标就是通过技术手段来实现网站的安全性。本方案中，我们采用前后端分离的架构，前端采用模版引擎，同时应用服务端通过白名单的设置，以及权限的有效控制，防范XSS攻击、SQL注入等工具手段。对分布式的服务调用采用严格的权限校验，避免数据的泄密。同时针对第三方提供的API接口，提供token校验机制、信息加密等手段防范攻击。

4.2.3.2 技术架构图

综合以上设计原则，本系统采用的技术架构如下：

对以上技术架构的补充说明如下：

• 设备层可以通过各种物理接口及协议类型，将数据传入到物联网网关中。常用的物理接口是RS485接口，常用的协议是MODBUS-RTU；
• 物联网网关层支持灵活的接口扩展，并支持多种北向数据传输协议。常见的数据传输协议是MQTT协议，也支持http/socket等协议类型上传；
• 应用后台采用Docker容器技术构建，容器开放接口给其他容器调用，可实现应用后台的灵活扩展；
• 应用后台围绕MQTT服务构建（Broker和Router两种节点）。MQTT服务有很强的扩展性，在水平扩容的情况下，能够支持大量设备的接入；
• 应用后台，将作为一个通用的后台服务，为各类应用端提供多种类型的接口：Rest/WebSocket/MQTT等。

4.2.3.3 部署架构图

以以上技术架构为基础，本系统的不是架构如下：

对以上部署架构的补充说明如下：

• 各个检测点位，放置一个物联网网关即可；物联网网关通过4G将数据发送到云后台；
• 一个物联网网关，可以支持数十个监测传感器的接入；

4.2.3.4 技术保障措施

• 减少页面http请求

页面过多的http请求会给服务器带来很大压力。通过前端模版引擎、模块化开发策略，采用前端构建工具，对于js、css、图片进行合并、压缩，浏览器只需要加载一次http请求，即可完成资源的加载。
采用前端模版引擎handlebars，可通过预编译将template模版预编译成js文件，进行压缩、合并，极大的提高了前端页面渲染速度。

• 浏览器缓存

设置HTTP头中Cache-Control和Expires属性，设定浏览器缓存。对于已压缩的静态资源文件，采用文件指纹技术，通过构建工具对JS、css文件添加MD5文件指纹，这样保证 每次发版本，文件指纹更新，防止客户端已缓存文件过期导致不同步，如下所示。

• 页面合理布局

通过页面合理布局提高浏览器渲染速度。因为浏览器渲染页面的时候会先下载css文件，因此需要将css文件放到页面的head中。Javascript文件正好相反，由于js文件在执行的过程中，可能会阻塞页面，造成页面加载缓慢，因此js文件需要放在页面底部。如下所示。

• 减少cookie传输

在每次的请求和相应中，太大的cookie会严重影响数据传输，因此在开发过程中，应尽量慎重的使用cookie，减少cookie传输的数据量。
对于静态资源访问，使用独立域名，避免请求静态资源的时候发送cookie，减少cookie传输的次数。

• CDN加速

CDN的本质仍然是一个缓存，而且是将数据缓存在离用户最近的地方，使用户可以最快速去取得数据。图片、文件、css、js文件等静态资源部署在CDN服务，可以极大的改善网页的打开速度。

• Nginx反向代理

通过nginx反向代理服务器，配置缓存功能。当用户第一次访问静态内容页面的时候，静态内容被缓存在反向代理服务器上，当其他用户访问该静态内容时候，直接从反向代理服务器返回，加速请求速度，减轻服务器压力。

• 分布式缓存

和所有服务器都部署相同应用的应用服务器集群不同，分布式缓存服务器集群中不同服务器中缓存的数据各不相同，缓存访问请求不可以在缓存服务器集群中的任意一台处理，必须先找到缓存有需要数据的服务器，然后才能访问。这个特点会严重制约分布式缓存集群的伸缩性设计，因为新上线的缓存服务器没有缓存任何数据，而已下线的缓存服务器还缓存着网站的许多热点数据。
必须让新上线的缓存服务器对整个分布式缓存集群影响最小，也就是说新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据尽可能还被访问到，这是分布式缓存集群伸缩性设计的最主要目标。

• 异步操作

采用消息队列的模式提高性能。传统开发中，将用户请求的数据直接保存到数据库中，在高并发的情况下，对数据库造成巨大的压力，同时也导致请求的相应延迟加剧。针对这种情况，采用消息队列后，用户请求的数据异步的方式发送给消息队列，立即返回相应信息，通过消息队列消费者进程从消息队列中获取数据，异步写入数据库，可以有效改善用户的响应延迟问题。
Google guava提供了一种事件总线（EventBus）的机制,这是一种发布-订阅者模式的组件通信，但组件不需要显式的注册到其他组件中。它的实现原理是通过事件监听者（Listener）监听特定事件，通过事件生产者（producer）管理和追踪监听者，实现事件的分发传递和异步分发的功能。

• 集群部署

在高并发情况下，使用负载均衡技术将一个应用部署为服务器集群，将并发访问请求分发到多台服务器上处理，避免单一服务器因负载压力过大而响应缓慢。
采用分布式服务框架SpringCLoud将业务模块划分为多个服务，每个服务独立部署，部署为集群。采用zookeeper作为服务注册中心，将zookeeper部署为集群，利用zookeeper做负载均衡，将请求分发至不同服务集群，解决负载问题。

• 读写分离

数据库采用主从复制和读写分离机制。可以部署多个从库，定时从主库同步数据。主库作为写库，负责写入操作和少量的对实时性要求高的读操作。从库作为读库，负责读取信息，降低频繁的读操作对写入操作产生的影响，提高数据库吞吐量，解决由慢查询慢写入产生的系统瓶颈。

• 分级管理

运维上将服务器进行分级管理，核心应用和服务优先使用更好的硬件，在运维响应速度上也格外迅速。显然，用户及时付款购物比能不能评价商品更重要，所以订单、支付服务比评价服务有更高优先级。
同时在服务部署上也进行必要的隔离，避免故障的连锁反应。低优先级的服务通过启动不同的线程或者部署在不同的虚拟机上进行隔离，而高优先级的服务则需要部署在不同的物理机上，核心服务和数据甚至需要部署在不同地域的数据中心。

• 超时设置

由于服务端宕机、线程死锁等原因，可能导致应用程序对服务端的调用失去响应，进而导致用户请求长时间得不到响应，同时还占用应用程序的资源，不利于及时将访问请求转移到正常的服务器上。
在应用程序中设置服务调用的超时时间，一旦超时，通信框架就抛出异常，应用程序根据服务调度策略，可选择继续重试或将请求转移到提供相同服务的其他服务器上。

• 异步调用

应用对服务的调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。如提交一个新用户注册请求，应用需要调用三个服务：将用户信息写入数据库，发送账户注册成功邮件，开通对应权限。如果采用同步服务调用，当邮件队列阻塞不能发送邮件时，会导致其他两个服务也无法执行，最终导致用户注册失败。

• 服务降级

在网站访问高峰期，服务可能因为大量的并发调用而性能下降，严重时可能会导致服务宕机。为了保证核心应用和功能的正常运行，需要对服务进行降级。降级有两种手段：拒绝服务及关闭服务。

• 拒绝服务，拒绝低优先级应用的调用，减少服务调用并发数，确保核心应用正常使用；或者随机拒绝部分请求调用，节约资源，让另一部分请求得以成功。
• 关闭功能，关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约系统开销，为重要的服务和功能让出资源。淘宝在每年的“双十一”促销中就使用这种方法，在系统最繁忙的时段关闭“评价”、“确认收货”等非核心服务，以保证核心交易服务的顺利完成。
  • 数据备份

数据备份是一种古老而有效的数据保护手段，早期的数据备份手段主要是数据冷备，即定期将数据复制到某种存储介质（磁带，光盘…）上并物理存档保管，如果系统存储损坏，那么就从冷备的存储设备中恢复数据。
冷备的优点是简单和廉价，成本和技术难度都较低。缺点是不能保证数据最终一致，由于数据是定期复制，因此备份设备中的数据比系统中的数据陈旧，如果系统数据丢失，那么从上个备份点幵始后更新的数据就会永久丢失，不能从备份中恢复。同时也不能保证数据可用性，从冷备存储中恢复数据需要较长的时间，而这段时间无法访问数据，系统也不可用。

• 访问转移

确认某台数据存储服务器宕机后，就需要将数据读写访问重新路由到其他服务器上。对于完全对等存储的服务器（几台存储服务器存储的数据完全一样，我们称几台服务器为对等服务器，比如主从结构的存储服务器，其存储的数据完全一样），当其中一台宕机后，应用程序根据配置直接切换到对等服务器上。如果存储是不对等的，那么就需要重新计算路由，选择存储服务器。

• 数据恢复

因为某台服务器宕机，所以数据存储的副本数目会减少，必须将副本的数目恢复到系统设定的值，否则，再有服务器宕机时，就可能出现无法访问转移（所有副本的服务器都宕机了），数据永久丢失的情况。因此系统需要从健康的服务器复制数据，将数据副本数目恢复到设定值。

• 网站发布

网站需要保证7x24高可用运行，同时网站又需要不断地发布新功能吸引用户以保证在激烈的市场竞争中获得成功。通常大型网站每周都需要发布一到两次。
不管发布的新功能是修改了一个按钮的布局还是增加了一个核心业务，都需要在服务器上关闭原有的应用，然后重新部署启动新的应用，整个过程还要求不影响用户的使用和体验。
网站的发布过程事实上和服务器宕机效果相当，其对系统可用性的影响也和服务器宕机相似。所以设计一个网站的高可用架构时，需要考虑的服务器宕机概率不是物理上的每年一两次，而是事实上的每周一两次。也许你认为这个应用不重要，重启也非常快，用户可以忍受每年一到两次的宕机故障，因而不需要复杂的高可用设计。事实上，由于应用的不断发布，用户需要面对的是每周一到两次的宕机故障。

发布过程中，每次关闭的服务器都是集群中的一小部分，并在发布完成后立即可以访问，因此整个发布过程不影响用户使用。

• 自动化测试

代码在发布到线上服务器之前需要进行严格的测试。即使每次发布的新功能都是在原有系统功能上的小幅增加，但为了保证系统没有引入未预料的Bug，网站测试还是需要对整个网站功能进行全面的回归测试。此外还需要测试各种浏览器的兼容性。在发布频繁的网站应用中，如果使用人工测试，成本、时间及测试覆盖率都难以接受。
目前大部分网站都采用Web自动化测试技术，使用自动测试工具或脚本完成测试。比较流行的Web自动化测试工具是ThoughtWorks开发的Selenium。Selenium运行在浏览器中，模拟用户操作进行测试，因此Selenium可以同时完成Web功能测试和浏览器兼容测试。

• 预发布验证

即使是经过严格的测试，软件部署到线上服务器之后还是经常会出现各种问题，甚至根本无法启动服务器。主要原因是测试环境和线上环境并不相同，特别是应用需要依赖的其他服务，如数据库，缓存、公用业务服务等，以及一些第三方服务，如电信短信网关、银行网银接口等。
也许是数据库表结构不一致；也许是接口变化导致的通信失败；也许是配置错误导致连接失败；也许是依赖的服务线上环境还没有准备好，这些问题都有可能导致应用故障。
因此在网站发布时，并不是把测试通过的代码包直接发布到线上服务器，而是先发布到预发布机器上，开发工程师和测试工程师在预发布服务器上进行预发布验证，执行一些典型的业务流程，确认系统没有问题后才正式发布。

• 代码控制

对于大型网站，核心应用系统和公用业务模块涉及许多团队和工程师，需要对相同的代码库进行共同开发和维护。而这些团队对同一个应用的开发维护（开发周期和发布时间点各不相同），如果代码控制环节出了问题，可能将有问题的代码发布上线，将问题带入生产环境，导致系统故障。
网站代码控制的核心问题是如何进行代码管理，既能保证代码发布版本的稳定正确，同时又能保证不同团队的开发互不影响。

• 自动化发布
  网站的版本发布频繁，整个发布过程需要许多团队通力合作。发布前，多个代码分支合并回主干可能会发生冲突，预发布验证也会带来风险，每次发布又相当于一次宕机事故。因此网站发布过程一不小心就会出现麻烦，可以使用火车发布模型规避上述问题。

• 灰度发布

应用发布成功后，仍然可能发现因为软件问题而引入的故障，这时候就需要做发布回滚，即卸载刚刚发布的软件，将上一个版本的软件包重新发布，使系统复原，消除故障。
大型网站的主要业务服务器集群规模非常庞大，一旦发现故障，即使想要发布回滚也需要很长时间才能完成。为了应付这种局面，大型网站会使用灰度发布模式，将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，持续几天才把整个集群全部发布完毕，期间如果发现问题，只需要回滚已发布的一部分服务器即可。

5 系统实施

5.1 实施计划

本系统实施，按照以下步骤执行：

1. 明确监测目的。
2. 进行调查研究。
3. 确定监测对象。
4. 设计监测网点。
5. 安排采样时间和频率。
6. 选定采样和保存方法。
7. 选定分析测定技术。
8. 提出监测报告要求。
9. 制订质量保证程序、措施和方案的实施计划。
10. 部署实时在线监测系统

5.2 准备工作

5.2.1 基础资料收集

• 水体的水文、气候、地质和地貌资料。如水位、水量、流速及流向的变化；降雨量、蒸发量及历史上的水情；河宽、河深、河床结构及地质状况等。
• 水体沿岸城市分布、工业布局、污染源及其排污情况、城市给排水情况等。
• 水体沿岸水资源现状及用途。如饮用水源分布和重点水源保护区，水体流域土地功能及近期使用计划等。
• 历年水质监测资料、水文实测资料、水环境研究成果等。

5.2.2 监测断面和采样点的设置

• 监测断面的布设原则。
• 监测断面设置。
  • 河流监测断面设置。
  • 湖泊（水库）监测断面设置。 采样位置的确定
  • 在对调查研究结果和有关资料进行综合分析的基础上，监测断面的布设应有代表性，即能较真实、全面地反映水质及污染物的空间分布和变化规律；根据监测目的和监测项目，并考虑人力、物力等因素确定监测断面和采样点。
  • 有大量废水排入河流的主要居民区、工业区的上游和下游。较大支流汇合口上游和汇合后与干流充分混合处，入海河流的河口处，受潮汐影响的河段和严重水土流失区。湖泊、水库、河口的主要入口和出口。国际河流出入国境线的出入口处。
  • 饮用水源区、水资源集中的水域、主要风景游览区、水上娱乐区及重大水力设施所在地等功能区。
  • 断面位置应避开死水区及回水区，尽量选择河段顺直、河床稳定、水流平稳、无急流浅滩处。
  • 应尽可能与水文测量断面重合；并要求交通方便，有明显岸边标志。

5.2.3 采样时间与采样频率的确定

• 河流：较大水系干流和中、小河流全年采样不少于6次，采样时间为丰水期、枯水期和平水期，每期采样两次。流经城市或工业区，污染较重的河流、游览水域，全年采样不少于12次。采样时间为每月一次或视具体情况选定。
• 排污渠：全年采样不少于3次。
• 底泥：每年在枯水期采样一次。
• 背景断面：每年采样一次。在污染可能较重的季节进行。
• 潮汐河流：全年按丰、枯、平三期，每期采样2天，分别在大潮期和小潮期进行，每次应当在当天涨潮、退潮时采样，并分别加以测定。涨潮水样应当在各断面涨平时采样，退潮时也应当在各断面退平时采样，若无条件，小潮期可不采样。
• 湖泊、水库：设有专门监测站的湖、库，每月采样不少于1次，全年不少于12次，其他湖、库每年采样2次，枯、丰水期各一次。有废水排入、污染较重的湖、库，应酌情增加采样次数。

5.2.4 采样及监测技术的选择

要根据监测对象的性质、含量范围及测定要求等因素选择适宜的采样、监测方法和技术。

5.2.5 结果表达、质量保证及实施进度计划

对监测中获得的众多数据，应进行科学地计算和处理，并按照要求的形式在监测报告中表达出来。质量保证概括了保证水质监测数据正确可靠的全部活动和措施。质量保证贯穿监测工作的全过程。实施进度计划是实施监测方案的具体安排，要切实可行，使各环节工作有序、协调地进行。

5.2 项目团队

5.2.1 团队结构

5.2.1.1 项目经理

主要职责：

• 制定项目计划
• 跟踪项目进度
• 协调项目资源
• 汇报项目进度

5.2.1.2 项目管理委员会

我方将为本项目成立专门的项目管理委员会，委员会主要的工作职责是：

• 监督项目过程
• 参与阶段评审
• 听取进度汇报
• 重要事项决策

5.2.1.3 系统架构团队

负责人：技术经理
主要职责：

• 指定技术路线和开发框架
• 为交付团队提供技术支持
• 指导系统部署上线

5.2.1.4 产品组织（产品经理总负责）

产品组织（产品经理总负责）
业务设计团队
负责人：产品经理

主要职责：

• 需求分析
• 内部反馈需求
• 指导系统设计

UED团队
负责人：UED经理
主要职责：

• 用户体验设计
• 视觉效果设计
• 页面原型设计

5.2.1.5 开发组织

负责人：交付经理（下辖若干开发组）
主要职责：

• 根据设计文档进行系统软件功能的开发
• 对测试团队指出的有效缺陷进行修正
• 支持系统上线工作

5.2.1.6 测试组织

负责人：测试经理（下辖若干测试组）
主要职责：

• 制定测试计划
• 设计测试用例
• 执行测试计划
• 提交测试报告
• 推动缺陷解决

5.2.1.7 辅助组织

顾问团队
主要职责：

• 向项目团队提供业务和技术支持
• 向客户提供合理化建议

质量保障团队
主要职责：

• 推动项目过程评审
• 对不符合项进行处理和跟踪
• 协助项目经理管控项目风险

5.3 项目工程管理

5.3.1 项目准备-启动阶段

项目准备阶段的重要作用在于明确任务、了解方法、建立组织、安排资源，全体成员达成对项目的一致认识和理解。
本阶段主要活动如下表：

5.3.2 系统规划-需求阶段

本阶段的目的在于最终确认项目究竟要做什么以及如何集成进原有业务系统中。
本阶段主要活动如下表：

5.3.3 系统规划-设计阶段

本阶段主要任务根据客户需求，进行系统硬件、软件及客户化系统的设计。
本阶段主要活动如下表：

5.3.4 系统实现-软件开发

本阶段主要是要根据系统设计，进行系统功能实现。
本阶段主要活动如下表：

5.3.5 项目测试和验收方法

5.3.5.1 单体测试

• 采用白盒测试
• 关键模块测试达到C0级别
• 网页测试覆盖输入
• 根据资产库常见bug列表进行测试：
• 变量引用的时候,空指针情况的防止,即为空检查.
• 数学运算异常,如除0的情况.数组越界异常,字符串访问过界
• 数据库检索记录,结果记录行数状况的处理.
• 画面显示项目的确认.
• 画面显示项目达到上限时情况的处理.
• 系统出错的时候,异常信息是否正确.
• 数据库连接,游标的处理.
• 数学运算时,数据精度的处理.

5.3.5.2 系统测试

测试规程如下图：

5.3.5.3 性能测试

测试系统的处理能力，一般采用软件进行测试。大连我方的常用软件是loadrunner。 渗入测试是一种比较简单的性能测试。渗入测试所需时间较长，它使用固定数目的并发用户测试系统的总体健壮性。这些测试将会通过内存泄漏、增加的垃圾收集(GC)或系统的其他问题，显示因长时间运行而出现的任何性能降低。测试运行的时间越久，您对系统就越了解。运行两次测试是一个好主意——一次使用较低的用户负载（要在系统容量之下，以便不会出现执行队列），一次使用较高的负载（以便出现积极的执行队列）。
测试应该运行几天的时间，以便真正了解应用程序的长期健康状况。要确保测试的应用程序尽可能接近现实世界的情况，用户场景也要逼真（虚拟用户通过应用程序导航的方式要与现实世界一致），从而测试应用程序的全部特性。确保运行了所有必需的监控工具，以便精确地监测并跟踪问题。

• 峰谷测试

峰谷测试兼有容量规划ramp-up类型测试和渗入测试的特征。其目标是确定从高负载（例如系统高峰时间的负载）恢复、转为几乎空闲、然后再攀升到高负载、再降低的能力。
实现这种测试的最好方法就是，进行一系列的快速ramp-up测试，继之以一段时间的平稳状态（取决于业务需求），然后急剧降低负载，此时可以令系统平息一下，然后再进行快速的ramp-up；反复重复这个过程。这样可以确定以下事项：第二次高峰是否重现第一次的峰值？其后的每次高峰是等于还是大于第一次的峰值？在测试过程中，系统是否显示了内存或GC性能降低的有关迹象？测试运行（不停地重复“峰值/空闲”周期）的时间越长，对系统的长期健康状况就越了解。

5.3.5.4 安全性测试

一个完整的WEB安全性测试可以从部署与基础结构、输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密。参数操作、异常管理、审核和日志记录等几个方面入手。

(1)安全体系测试

• 部署与基础结构
• 网络是否提供了安全的通信
• 部署拓扑结构是否包括内部的防火墙
• 部署拓扑结构中是否包括远程应用程序服务器
• 基础结构安全性需求的限制是什么
• 目标环境支持怎样的信任级别
• 输入验证

(2)如何验证输入

• 是否清楚入口点
• 是否清楚信任边界
• 是否验证Web页输入
• 是否对传递到组件或Web服务的参数进行验证
• 是否验证从数据库中检索的数据
• 是否将方法集中起来
• 是否依赖客户端的验证
• 应用程序是否易受SQL注入攻击
• 应用程序是否易受XSS攻击
• 身份验证
• 是否区分公共访问和受限访问
• 是否明确服务帐户要求
• 如何验证调用者身份
• 如何验证数据库的身份
• 是否强制试用帐户管理措施
• 授权
• 如何向最终用户授权
• 如何在数据库中授权应用程序
• 如何将访问限定于系统级资源
• 配置管理
• 是否支持远程管理
• 是否保证配置存储的安全
• 是否隔离管理员特权
• 敏感数据
• 是否存储机密信息
• 如何存储敏感数据
• 是否在网络中传递敏感数据
• 是否记录敏感数据
• 会话管理
• 如何交换会话标识符
• 是否限制会话生存期
• 如何确保会话存储状态的安全
• 加密
• 为何使用特定的算法
• 如何确保加密密钥的安全性
• 参数操作
• 是否验证所有的输入参数
• 是否在参数过程中传递敏感数据
• 是否为了安全问题而使用HTTP头数据
• 异常管理
• 是否使用结构化的异常处理
• 是否向客户端公开了太多的信息
• 审核和日志记录
• 是否明确了要审核的活动
• 是否考虑如何流动原始调用这身份

5.4 系统验收

系统验收流程如下图：

5.4.1 系统上线-实施交付

实施交付阶段主要流程、活动如下表：

5.5 项目过程管理

5.5.1 过程管理模型

我们采用CMMI框架体系来建立这些过程，以确保项目的开发和交付过程遵循上述标准，并且确保交付的质量。
影响项目成功的因素是多方面的，只有对项目实施的全过程进行全方位的综合控制与管理，才可以保证整个项目高效率，高质量，低风险地运行。
对项目的综合管理主要体现在以下几个方面：风险管理，项目监控、质量管理，沟通管理，变更管理等。

5.5.2 项目监控

通过对项目的跟踪和控制，及时了解项目状况，发现问题，解决问题，主要活动如下表：

5.5.2.1 日常监控

项目负责人收集项目状态信息：项目负责人和项目成员按照相关规程、标准的规定，在相关记录表格中记入项目的状态信息。项目负责人通过观察、询问等方式获得并记录项目的状态信息。项目成员主动向项目负责人汇报项目中发生的问题，项目负责人记入《问题记录表》 。
项目负责人监督项目状态信息的获取，监督项目成员在需要的记录表格中及时填写数据，监督所填写数据的准确性、完整性、一致性。
日常监控的内容主要包括计划参数(工作量、规模、进度、品质等)、项目承诺、风险管理、资料管理、相关人员参与等。 项目负责人将项目的当前状态信息与项目计划对比，当发生的偏离超过《项目阈值监控表》中的行动阈值时，记入《问题记录表》。
项目负责人对《问题记录表》中的问题进行分析、处理，并跟踪问题处理直到问题解决。

5.5.2.2 项目周/月会

(1)会议前：

• 项目负责人或指定人员通过E-mail发布周会通知
• 项目负责人汇总日常监控的数据和问题。
• 项目负责人分析日常监控的数据，将发现的问题记入《问题记录表》。
• 项目负责人整理需要在会议上通报的共通问题。

(2)会议中：

• 项目负责人主持周会。
• 项目成员向项目负责人汇报任务的进度、品质、生产性等内容。
• PPQA汇报评审和审计发现的主要问题。
• 在会议上发现问题时，项目负责人记入《问题记录表》。
• 项目负责人跟踪项目中发生的问题，就会议前分析出的问题和会议上所发现的问题质询项目成员，将结果记入《问题记录表》。
• 项目负责人主持进行讨论，分析问题原因，确定解决方案，对不能在会议上确定解决方案的问题，须确定问题解决的日程及责任人。
• 项目负责人通报共通问题及解决措施。
• 项目负责人根据计划和问题解决方案安排下周工作。

(3)会议后：

• 项目负责人或指定人员整理周报：包括《周间进度报告书》、《生产管理表》、《项目阈值监控表》、《中日程计划/实际表》。
• 如果需要将周报提交客户等相关人员，项目负责人须根据信息安全要求和其他项目保密要求调整周报中的数据，以确保将适宜的信息传达给适宜的相关方。
• PPQA查阅周报内容
• 部门（副、业务）经理批准周报
• 项目负责人通过E-mail将周报提交客户、高层及相关人员
• 项目负责人整理《会议纪要》，全体成员回览《会议纪要》

5.5.2.3 分析问题

项目负责人或指定人员向相关人员调查，分析问题原因，并记录到《问题记录表》中。需要项目其他相关人员协助分析问题原因时，项目负责人协调相关人员进行问题分析。无法确定问题原因时，项目负责人或指定人员应就问题现象本身确定问题排除方案，并向高一层经理汇报。
项目负责人或指定人员确定解决方案，方案实施的责任人，预计纠正日，并记录到《问题记录表》中。需要项目其他相关人员协助确定解决方案时，项目负责人协调相关人员进行解决方案的确定。 解决方案包括以下内容：

• 范围变更
• 计划变更
• 资源变更
• 过程变更
• 项目相关人员承诺变更
• 标准规范变更
• 工作产品变更
• 其他解决措施
  无法确定解决方案时，项目负责人或指定人员应就问题现象本身确定问题排除方案。排除方案也无法确定时，项目负责人向高一层经理汇报。

5.5.2.4 跟踪问题处理

项目负责人或指定人员监督问题纠正行动的进展状况，一般监督形式如下：

• 日常
• 周会
• 月会
• 其他形式
• 当问题解决方案或问题排除方案不合理时，项目负责人或指定人员须调整方案。
• 当满足以下条件时，将问题关闭：
• 问题已解决
• 项目偏离纠正到阈值范围内
• 问题原因已消除
  当问题无法解决时，将问题挂起，并上报。 项目负责人或指定人员将跟踪结果记入《问题记录表》。

5.5.3 风险管理

风险管理的目的是最大限度地减少项目中各方面可能出现的负面影响，从而尽可能地减小项目的风险。项目的风险管理是通过以下一系列步骤来实现的：

5.5.3.1 风险初步识别

项目负责人可以通过以下手段初步识别风险项：

• 参考《风险列表》中各风险项描述；
• 回答《风险问卷》；
• 查阅相似项目的《项目总结报告》；
• 根据项目信息（客户需求和项目计划等）和实际情况，进一步识别项目在客户、过程、技术、人员、开发环境、组织管理等方面存在的风险，并记录到《风险分类表》中。
  将初步识别的风险记入《风险管理表》。

5.5.3.2 准备风险评估

项目负责人确定风险评估人员（项目内的经验者、PPQA、EPG、业务经理、部门经理、高层管理者、客户等），并邀请他们参加评估；
项目负责人发送风险评估通知和《风险管理表》。
风险评估人员讨论确定风险项，并作如下评估：

• 具体风险情况；
• 分析风险潜在影响；
• 明确风险转化为问题的发生条件；
• 评估风险严重性；
• 评估风险发生可能性；
• 评估风险紧迫性；
• 按照《风险评估标准》,计算风险优先数（RPN）, 将风险按RPN排出优先次序更新《风险管理表》。

5.5.3.3 确定风险缓解措施与应急措施

项目负责人根据项目组实际情况调整警戒线和应急措施线。若RPN高于警戒线，应制定缓解措施：

• 从《风险列表》中获得推荐的缓解措施，根据该项目实际情况适当调整
• 没有可参考缓解措施时，制定缓解措施
• 若风险发生可能性高于应急措施线，则为该风险项制定应急措施 缓解和应急措施包括：变更计划、项目范围、过程和工作产品等并填写《风险管理表》。

5.5.3.4 制定风险应对计划

• 项目负责人指定风险缓解措施实施人；
• 确定风险跟踪的频率或预定跟踪时间，风险跟踪的频率不得低于一个月1次；
• 确定风险再评估的时间间隔，在风险跟踪的过程中对风险进行再评估，以便重新检查可能的风险来源和调整条件，从而进一步发现以前没有注意到的或者还不存在的风险来源并维护《风险管理表》。

5.5.3.5 跟踪风险

• 项目负责人评估缓解措施实施效果，评估风险严重性的等级是否降低，评估风险发生可能性的等级是否降低，评估风险紧迫性的等级是否降低，关闭RPN值；
• 已低于警戒值的风险项在实施缓解措施没有达到预期效果时，项目负责人调整缓解措施、应急措施或调整措施。
• 实施责任人在必要时，重新识别风险，启动风险再评估，调整风险项、风险缓解措施与应急措施。

5.6 质量管理

质量管理和控制是关系到项目能否成功实施且顺利交付的重要保证手段。在项目的管理实施中体现在三个方面：质量保证、质量审计、持续改进。

5.6.1 质量保证

质量保证活动，主要是根据项目遵照的管理规程，编制或引用有关的评审和检查规程以及通过与否的技术准则，由项目团队进行项目活动和工作产品进行评审和检查。
通常进行的评审和检查工作包括：

• 开发计划评审：在开发计划编写完成后必须进行开发计划评审，对工作任务的进度、资源、风险等方面的计划进行评审，确保计划的合理性和可操作性。
• 软件需求评审：在软件需求分析结束后必须进行软件需求评审，以确保在软件需求规格说明书中所规定的各项需求的合适性。
• 概要设计评审：在软件概要设计结束后必须进行概要设计评审，以评价软件设计说明书中所描述的软件概要设计在总体结构、外部接口、主要部件功能分配、全局数据结构以及各主要部件之间的接口等方面的合适性。
• 详细设计评审：在软件详细设计阶段结束后必须进行详细设计评审，以验证文档已经满足在软件需求说明书中规定的所有需求。
• 软件验证与确认计划评审：在软件释放前，要对软件验证与确认计划进行评审，以评价软件验证与确认计划中所规定的验证与确认方法的合适性与完整性。

5.6.2 质量审计

在本项目中，质量审计定义为部门SQA审计和公司品质部的内审。按其内容和实施方法分为：工作产品审计、阶段活动评审。

5.6.2.1 工作产品审计

• 审计时点

工作产品审计的执行时点由《SQA检查计划》确定。在《SQA检查计划》中应对项目生命周期的什么阶段进行审计及审计的日程进行定义，对阶段产品的审计时点在项目组对该阶段产品的评审活动结束之后实施。

• 审计内容

各阶段工作产品的审计内容由《工作产品审计检查单》列出，如项目有特殊要求可追加或删减《工作产品审计检查单》的审计项目。审计的内容着重于检查工作产品与相关标准、规程符合程度和对项目品质目标值的度量，而不涉及技术方面的问题。

• 审计方法

审计阶段工作产品，如：项目计划书、设计书、源代码、测试结果等，检查其与相关模板、标准的符合性，不合格项记入《不合格项一览表》；查阅阶段产品（待交付产品）的评审记录，如：《评审记录票一览》、《帐害处理票一览》等，对该记录的完整性和可追溯性进行判定，不合格项记入《不合格项一览表》；检查需求变更管理和配置管理的过程文档，是否符合相关规程、标准的规定，不合格项记入《不合格项一览表》；度量项目的品质数据与品质目标值的偏差。

5.6.2.2 阶段活动评审

• 审计时点

评审执行时点由《SQA检查计划》确定，SQA进行的阶段活动评审在项目的相关阶段结束之后，对阶段活动的符合性进行验证。

• 审计内容

各阶段活动评审的内容由《过程评审检查表》列出，如项目有特殊要求可增加或减少《过程评审检查表》的项目。评审内容的焦点在于给出阶段活动的符合性的评价，而不是在技术实现上对项目进行评价。

• 审计方法

正式评审。按照《SQA检查计划》规定的时点，组织项目阶段结束的正式评审会议，根据《过程评审检查表》的评审条目，对项目阶段活动的符合性进行检查和评价，不合格项记入《不合格项一览表》；非正式评审。通过与项目负责人及项目组成员或阶段活动参与人员就相关要素的检查进行交流，获得其对相关标准和规程的执行情况，以判定阶段活动的符合性，不合格项记入《不合格项一览表》。

5.6.2.3 持续改进

对于质量审计活动中发现的问题，需要进行问题分析，制定问题解决方案，跟踪问题的处理进展，实现工程过程和工程产品的持续改进。

• 问题分析

SQA定期（每周周会）分析、跟踪所发现的不合格项的状况，建立《问题状态》和《处置结果》图表，对于不能及时解决的问题提交给部门经理；在项目里程碑处，根据《不合格项一览表》各个开发阶段发现的不符合项的个数，生成不符合项阶段分布图，以了解发生问题的阶段分布情况；在《SQA总结报告中》，根据各类不符合项的汇总数量，生成不符合项类别分布图，分析各种问题所占的比例；

• 跟踪确认

对于不按照规程、标准的要求执行或对规程、标准有抵触而产生的问题，SQA整理填写《SQA提交给部门经理的报告》，提交给部门经理解决，SQA负责对问题的解决进行跟踪确认；对于其他问题，SQA反馈给项目负责人和相关项目组成员解决，SQA进行跟踪确认。

5.7 配置管理

5.7.1 主要活动

• 识别配置

找出需要管理的中间产品，使其处于配置管理的控制之下，并维护他们之间的相关关系。识别配置工作主要由开发负责人完成统筹和规划，由配置管理负责人进行细化。

• 变化控制

变化控制是指记录变化的有关信息（包括变化时间、实施人、变化原因、变化内容等），用以保障配置项及其关系的完整性，进而保证最终产品的质量。变化控制由配置管理负责人维护和记录。

• 状态记录和报告

状态记录和报告是指通过记录各个配置的变化状态，达到记录和报告整个软件的变化过程的目的。通过状态记录和报告，可以实现各配置项不同版本的查找和追溯。配置管理负责人负责定期（每月末）向开发项目经理提交基线状态报告。

• 备份

为最大程度的降低项目的风险，在利用配置管理工具本身具备的备份功能进行本地备份的基础上，规定配置管理负责人要定期的将配置库中的内容备份到异地介质中。

• 审计

在项目中，配置管理审计的范围特指通过记录配置管理工具执行的所有命令，对照各配置项的变化过程，验证和保证配置库中所有配置项的完整性。审计工作由项目负责人/SQA完成。

5.7.2 主要活动实施

• 日常操作

配置管理活动的日常操作check in/check out，基线维护结合具体配置管理工具制定操作规程。

• 配置维护

配置管理员负责配置维护工作，进行配置库的建立、更新、备份、分析、删除、故障后恢复等工作，并负责记录到《维护一览表》中。

• 备份计划

通常情况下，每周周末进行一次远程备份，将当前配置项复制到光盘或其他计算机的硬盘中；当一个基线产品生成后，即进行一次远程备份。

• 备份审核

配置管理员根据备份计划，进行备份，每次备份，填写《备份记录及检查表》；项目负责人在执行备份时间后的下一个工作日，进行备份情况检查，填写《备份记录及检查表》；配置管理员每月 第一个星期五下午对上一次备份（光盘介质备份）进行恢复试验，填写《备份记录及检查表》；配置管理员每半年对备份进行随机恢复试验，填写《备份记录及检查表》。

• 配置报告

配置管理员于每月最后一个工作日，编写《配置报告》；配置管理员依据《用户状态／权限表》，将本月用户及用户权限变化情况记入《配置报告》；配置管理员依据审计的《配置检查单》，将审计中存在的问题和解决情况记入《配置报告》；配置管理员依据《维护一览表》，汇总基线变更情况，判定配置库状态，记入《配置报告》；配置管理员将《配置报告》提交项目负责人，项目负责人在《配置报告》中签字确认。

• 配置审计

项目负责人/SQA根据《项目配置计划》，每月末进行一次配置审计，填写《配置检查单》。

5.7.3 配置管理工具

根据项目特点，可以采用SVN、VSS、CVS作为指定的配置管理工具，并在统一的配置管理服务器上进行。

5.8 变更管理

软件变更流程如下图所示：

6 参考资料

• GB3838-2002《地表水环境质量标准》
• GB5749-2006《生活饮用水卫生标准》
• HJ/T 354-2007《水污染源在线监测系统验收技术规范》
• 《城市黑臭水体整治工作指南》（建城〔2015〕130 号）
• 《关于在湖泊实施湖长制的指导意见》
• 《城市供水水质标准》
• GB6920 水质 pH值的测定 玻璃电极法
• GB7479 水质 铵的测定 纳氏试剂比色法
• GB7481 水质 铵的测定 水杨酸分光光度法
• GB11914 水质 化学需氧量的测定 重铬酸盐法
• GB11893 水质 总磷的测定 钼酸铵分光光度法
• GB13195 水质 水温的测定 温度计或颠倒温度计测定法
• HBC 6-2001 环境保护产品认定技术要求 化学需氧量（CODcr）水质在线自动监测仪
• HJ/T 70 高氯废水 化学需氧量的测定 氯气校正法
• HJ/T91-2002 地表水和污水技术规范
• HJ/T96-2003 pH水质自动分析仪技术要求
• HJ/T101-2003 氨氮水质自动分析仪技术要求
• HJ/T103-2003 总磷水质自动分析仪技术要求
• HJ/T355-2007 水污染源在线监测数据有效性判别技术规范