|
|
|
|
|
公司应遵照现行的政府网站内容管理系列制度及工作流程完成以下工作。
|
|
|
|
按照政府网站内容管理规范，完善和改进政府网站主站及机关各子网站建设和管理工作；进行网站的日常内容采集、加工、上传、分发、管理；完成年度内不少于一次的网站改版工作。
|
|
|
|
英文版网站内容维护，包括网站内容翻译、互动留言收集整理翻译、英文信息发布等。
|
|
|
|
|
|
|
|
|
|
|
|
国家重大节日、重大会议、重大事件期间的24小时编辑响应服务。
|
|
|
|
|
|
|
|
|
|
现场日常巡检服务是公司对政府数据库设备进行全面检查的服务项目，通过该服务可使客户获得设备运行的第一手资料，最大可能地发现存在的隐患，保障设备稳定运行。同时，公司将有针对性地提出预警及解决建议，使客户能够提早预防，最大限度降低运营风险。
|
|
|
|
|
|
公司安排定期（每月／每天／上午下午各一次）例行巡检和预防性维护，内容包括：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（9）系统错误报告的分析、记录和清理（每天／次）。
|
|
|
|
（10）及时更换损坏的或有潜在故障的部件（每月／次）。
|
|
|
|
（11）设备物理检查（包括机体、风扇、风道及过滤器等）与清洁（每月／次）。
|
|
|
|
（12）针对巡检工作应提交完善的巡检报告，并且存档、编辑成册，每月月初提交，以便日后清查。
|
|
|
|
（13）网站数据库的巡检工作，网站数据库日常监控，每日至少2次，分上下午分别进行。
|
|
|
|
|
|
|
|
（2）周报、月报、季报、半年报、年报等总结性报告。
|
|
|
|
报告内容包括：检查内容、操作步骤、检查结果、操作人、操作时间、意见与建议等。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
按照政府网站技术规范和安全管理规范，对网站应用软件、中间件以及数据库进行日常安全性检查。
|
|
|
|
|
|
按照政府网站技术规范和安全管理规范，定期对服务器操作系统进行安全性检查以及进行系统杀毒；负责内网论坛（discuz）安全；负责网页防篡改软件（IGuard）安全。
|
|
|
|
|
|
按照网站技术规范和安全管理规范，对网站数据库进行定期备份以及备份恢复验证，保证数据的安全性、准确性、完整性和可用性。网站数据备份及数据恢复，根据网站情况目前均采用本机进行数据备份及恢复。
|
|
|
|
|
|
|
|
|
|
（3）每日分别于上、下午对服务器进行巡检，并于当天提交运维监控报告。
|
|
|
|
|
|
（1）网站访问监控。在网站访问监控功能中，系统监控内容包括网站名称、网址、监控类型、最后检测时间、响应时间及本日产生的上传下载流量等。单击“查看”后可查看更详细的网址监控项目，包括响应时间、连接数、网络流量，以及浏览用户在网站提交的纠错内容等。
|
|
|
|
响应时间。每间隔指定时间Ping指定的网址，并从返回的值中计算指定网站的响应时间。
|
|
|
|
监控详情：单击菜单“网站访问监控”→“网站访问监控详情”，系统在列表中显示每个已经添加并指定需要监控的网址，并在列表中显示该网址的响应时间。
|
|
|
|
数据采集：系统按照在“监控网址管理”中的设置，按指定间隔Ping出该网址的响应时间，并将数据保存至监控数据库中。
|
|
|
|
|
|
监控详情：单击菜单“网站访问监控”→“网站访问监控详情”，系统在列表中显示每个已经添加并指定需要监控的网址，并在列表中显示该网址的当前连接数量。
|
|
|
|
数据采集：系统按照在“监控网址管理”中的设置，按指定间隔测试该网址的当前连接数量，并将数据保存至监控数据库中。
|
|
|
|
网络流量。每间隔指定时间，取得并统计指定网站的网络流量，上传和下载流量分别显示。
|
|
|
|
监控详情：单击菜单“网站访问监控”→“网站访问监控详情”，系统在列表中显示每个已经添加并指定需要监控的网址，并在列表中显示该网址的累计网络流量。
|
|
|
|
数据采集：系统按照在“监控网址管理”中的设置，按指定间隔测试该网址的累计网络流量，并将数据保存至监控数据库中。
|
|
|
|
网站页面纠错。在特定（或全部）页面嵌入脚本，当浏览的用户发现页面内容有误时提交后，管理员可以从此功能中发现有误的内容并根据实际情况修正。
|
|
|
|
监控详情：单击菜单“网站访问监控”→“网站内容纠错”，系统在列表中按日期显示每个页面链接及提交的错误内容，以供管理员参考并更正。
|
|
|
|
数据采集：当浏览的用户发现页面内容有误时，可以通过选中内容然后按一个快捷键（如Ctrl+Enter）提交，页面直接保存相关信息至数据表中。
|
|
|
|
统计分析。针对网站监控中的各项指标进行统计分析，统计的条件包括时间范围、网址及指标值范围等。
|
|
|
|
监控情况统计表：统计指定时段内，网站各项监控指标的监控值。
|
|
|
|
监控预警趋势表：统计指定时段内，网站监控指标的统计值及趋势走向，同时以表格和图表形式展示。
|
|
|
|
监控预警统计表：统计指定时段内，全部（或指定）网站中，已经产生的（邮件或短信）预警的次数。
|
|
|
|
监控网站管理。添加需要监控的网站，从网址或IP确定需要监控的网站页面。可以选择哪些设备需要发送告警信息。预警级别分为两级，预警级别（蓝色）及告警级别（红色），达到告警级别后系统将按设置发送邮件或短信对管理员进行提醒。
|
|
|
|
可以更改每个网址的序号，在网址访问监控界面列表显示时，以序号为顺序升序显示。勾选“是否监控”并保存后，系统开始以指定的频率读取相关的监控数值并保存。
|
|
|
|
（2）设备监控。在设备监控界面中，列表显示了全部设备的最近一次监控情况，包括设备名称、IP、最后检测时间、各项监控数值及设备状态是否正常等。可以在左上方选择不同的分组以关注不同分组的设备，也可以勾选右上方的“仅显示异常服务器”以迅速找到运行异常的设备。
|
|
|
|
Ping返回时间。每隔一段时间，首先Ping设备判断设备是否能正常连接，以及连接所需的时长等，较长的返回时间或无响应通常表示设备可能已经发生故障。
|
|
|
|
监控详情：单击菜单“设备监控”→“设备监控详情”，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的Ping返回时间。
|
|
|
|
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的监控数值，并将数据保存至监控数据库中。
|
|
|
|
CPU使用率查询。每隔一段时间，检测目标计算机上CPU的使用率情况。CPU使用率反映的是当前CPU的繁忙程度。
|
|
|
|
监控详情：单击菜单“设备监控”→“设备监控详情”，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的CPU使用率情况。
|
|
|
|
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的CPU使用率，并将数据保存至监控数据库中。
|
|
|
|
CPU负载。每隔一段时间，检测目标计算机上CPU的负载情况。CPU负载指某段时间内占用CPU时间的进程和等待CPU时间的进程数，这里等待CPU时间的进程是指等待被唤醒的进程，不包括处于wait状态进程。
|
|
|
|
监控详情：单击菜单“设备监控”→“设备监控详情”，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的CPU负载情况。
|
|
|
|
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的CPU负载，并将数据保存至监控数据库中。
|
|
|
|
内存使用率。每隔一段时间，检测目标计算机上内存情况。内存使用率指已经使用的物理内存与全部物理内存的比率。
|
|
|
|
监控详情：单击菜单“设备监控”→“设备监控详情”，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的内存使用率情况。
|
|
|
|
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的内存使用率，并将数据保存至监控数据库中。
|
|
|
|
磁盘空间使用率。每隔指定时间，检测目标计算机上磁盘空间使用率情况。
|
|
|
|
监控详情：单击菜单“设备监控”→“设备监控详情”，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的磁盘使用率情况。
|
|
|
|
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的磁盘使用率，并将数据保存至监控数据库中。
|
|
|
|
网络流量。间隔指定时间，检测目标计算机上网络流量情况，包括网络上传流量与网络下载流量。流量可简略反映计算机的网络传输流量是否在正常范围内。
|
|
|
|
监控详情：单击菜单“设备监控”→“设备监控详情”，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的网络上传下载流量。
|
|
|
|
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的网络流量，并将数据保存至监控数据库中。
|
|
|
|
系统进程数。每隔一段时间，检测目标计算机上系统进程数量。系统进程数量表示当前监控的计算机在运行中的进程，进程越多，通常占用的CPU及内存资源也越多。
|
|
|
|
监控详情：单击菜单“设备监控”→“设备监控详情”，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并显示该计算机设备的系统进程数量。
|
|
|
|
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的，并将数据保存至监控数据库中。
|
|
|
|
统计分析。针对设备监控中的各项指标进行统计分析，统计的条件包括时间范围、设备名称及指标值范围等。
|
|
|
|
监控情况统计表：统计指定时段内，设备各项监控指标的监控值。
|
|
|
|
监控指标趋势表：统计指定时段内，设备监控指标的统计值及趋势走向，同时以表格和图表形式展示。
|
|
|
|
监控预警统计表：统计指定时段内，全部（或指定）设备中，已经产生的（邮件或短信）预警的次数。
|
|
|
|
监控设备管理。添加需要监控的设备，从IP及端口唯一指定需要监控的设备，并加以描述。可以选择哪些设备需要发送告警信息。预警级别分为两级，预警级别（蓝色）及告警级别（红色，达到告警级别后系统将按设置发送邮件或短信对管理员进行提醒。
|
|
|
|
可以更改每个网址的序号，在网址访问监控界面列表显示时，以序号为顺序升序显示。
|
|
|
|
在列表中可以设置每个设备的分组信息，如“外网服务器”“内网服务器”或“网络设备”，以查看监控情况时能迅速查看及判断设备监控情况。
|
|
|
|
勾选“是否监控”并保存后，系统开始以指定的频率读取相关的监控数值并保存。
|
|
|
|
（3）应用服务监控。监控指定应用服务（如Apache、WebSphere及Tomcat等）的运行情况，并对无法连接的应用服务，以及监控指标超过指定阈值的情况进行邮件或短信告警。
|
|
|
|
对于WebSphere的监控，很可能无法取得相关的监控项目值，在这种情况下可能需要通过Tivoli Performance Viewer工具来获得监控项目和数据。
|
|
|
|
（4）数据库监控。监控指定数据库实例的运行情况，并对无法连接的数据库，以及监控指标超过指定阈值的情况进行邮件或短信告警。
|
|
|
|
|
|
公司按照网站技术规范和安全管理规范，对网站应用软件、中间件以及数据库进行日常安全性检查。确保网站能够正常访问；确保网站内容正确，发布内容一致；确保网站动态应用正常，并能够提供正常的服务。
|
|
|
|
针对政府门户网站系统，我们采取有效的方法防止网页被攻击或恶意篡改，杜绝因攻击而带来的恶性事件发生。针对更为重要的信息数据，我们更需要提高安全防护的水平，确保网站系统的数据不被恶意修改，敏感的数据不被非法访问或泄露。具体内容从以下几个方面进行阐述。
|
|
|
|
（1）阻断应用攻击。采用专业的应用防护设备进行防护，通过对输入内容的过滤及请求过滤实现对网站的保护。防止跨站脚本攻击、SQL注入等常见攻击。
|
|
|
|
（2）屏蔽安全隐患。为了防止服务端敏感信息泄露，我们通过对现有网站的敏感信息进行屏蔽，如备份文件的下载、敏感数据库下载，管理后台的外网尝试等，另外还屏蔽编写程序过程中遗留下的程序注释，对服务出错信息进行有效屏蔽。
|
|
|
|
（3）防止网页篡改。应用网页防篡改系统有效的防护机制，实时监测网站服务器的相关信息是否被非法更改，一旦发现被改则第一时间通知管理员，并形成详细的日志信息。但对外仍显示篡改前的正常页面，用户可正常访问网站。事后可对原始文件及篡改后的文件进行本地下载比较，查看篡改记录，恢复被篡改的页面。
|
|
|
|
（4）网站服务器以及网络安全性检查。公司按照网站技术规范和安全管理规范，定期对服务器操作系统进行安全性检查以及进行系统杀毒；负责内网论坛（discuz）安全；负责网页防篡改软件（IGuard）安全。确保网站网络连接正常；定期对服务器操作系统进行安全性检查以及进行系统杀毒，确保服务器设备正常，对具有安全隐患的设备及时更换，并向相关领导及时汇报。
|
|
|
|
|
|
公司按照网站技术规范和安全管理规范，制定科学有效的数据备份与灾害恢复计划，对政府门户网站内容管理平台范围内要求的网站、应用及数据进行备份。
|
|
|
|
根据网站情况目前采用“某容灾备份系统”为主、服务器数据备份及恢复为补充的方式。具体情况如下。
|
|
|
|
|
|
（2）文件备份：每月进行一次服务器完全备份，重要服务器每天有1次增量备份，非关键业务每周进行1次增量备份。部分占用存储量大的业务按空间进行相应调整。
|
|
|
|
（3）数据库备份：每天进行增量备份，每周进行一次完整备份。部分关键业务可以进行两次完整备份。
|
|
|
|
|
|
（1）备份数据按每日备份一次。备份到存贮空间服务器的备份数据存放期为一个月，本机备份数据存放期为一年，备份数据保存量由各个服务器的可用空间决定。
|
|
|
|
|
|
网站互动内容管理服务器相关应用数据及Oracle数据。
|
|
|
|
|
|
（2）备份数据每日备份一次。备份到存贮空间服务器的备份数据存放期为一个星期，本机备份数据存放期为一年，备份数据保存量由各个服务器的可用空间决定。
|
|
|
|
|
|
|
|
|
|
（3）备份数据每日备份一次。备份到存贮空间服务器的备份数据存放期为一个星期，本机备份数据存放期为一个月，备份数据保存量由各个服务器的可用空间决定。
|
|
|
|
网站内网论坛管理服务器相关应用数据及MySQL数据。
|
|
|
|
|
|
|
|
网站公众留言相关公众留言应用数据及Oracle数据。
|
|
|
|
全国工业生产许可证查询服务器相关应用数据及Oracle数据。
|
|
|
|
|
|
公司按照网站技术规范和安全管理规范应对黑客攻击，保证网站防篡改系统正常运行且发挥作用，确保网站不被黑客攻破，防止黑客篡改网站内容及数据的破坏。
|
|
|
|
公司定期监控系统访问记录，及时查找异常访问记录并查找原因，消除隐患；并及时修复不安全漏洞，消除隐患；定期出具服务器运行情况及被攻击情况报告。
|
|
|
|
（1）工作时间内，发现黑客攻击应在第一时间通知具体责任人。
|
|
|
|
具体责任人接到通知后，应详细记录有关现象和显示器上出现的信息，将被攻击的服务器等设备从网络中隔离出来，保护现场。同时通知总负责人，召集相关技术人员共同分析攻击现象，提供解决方法，主机系统管理员和应用软件系统管理员负责被攻击或破坏系统的恢复与重建工作。视情况向领导汇报事件情况。
|
|
|
|
（2）非工作时间内发现的攻击事件，值班人员应首先立即切断被攻击外网服务器的网络连接，并做好相关记录；然后通知具体责任人按流程处理。
|
|
|
|
网站在运维过程中出现的系统故障，公司应进行紧急处理和故障修复。在故障处理和修复过程中，公司负责系统故障分析、问题定位并提供系统故障修复方案，主管单位认可后执行系统故障修复方案，在系统故障修复方案中涉及购买的第三方服务，需负责协调第三方服务人员配合公司进行系统故障恢复。
|
|
|
|
故障恢复后，需要对故障的发生、处理过程和结果进行记录，并形成故障报告，汇报给主管单位。
|
|
|
|
|
|
|
|
发生安全事件时，公司人员需1小时内到达现场，一般及较大故障要在1小时内恢复网站页面的正常浏览；对于特别重大而涉及面广的安全事件，要在4小时内恢复网站页面的正常浏览。
|
|
|
|
发现网站页面和各司局站点页面无法浏览；被黑客攻击等故障现象，经验证之后立刻给网站管理处打电话报告情况，判断为黑客攻击情况得到领导指示，可用VPN关闭XXX8.11和XXX8.12，并第一时间赶到现场。
|
|
|
|
|
|
首先进行事件定级。信息安全突发事件级别分为四级：一般（Ⅳ级）、较大（Ⅲ级）、重大（Ⅱ级）和特别重大（Ⅰ级）。
|
|
|
|
一般（Ⅳ级）：指能够导致较小影响或破坏的信息安全事件。
|
|
|
|
较大（Ⅲ级）：指能够导致较严重影响或破坏的信息安全事件。
|
|
|
|
重大（Ⅱ级）：指能够导致严重影响或破坏的信息安全事件。
|
|
|
|
特别重大（Ⅰ级）：指能够导致特别严重影响或破坏的信息安全事件。
|
|
|
|
对于处理故障时间，遇到信息安全突发事件按以下四个级别执行。
|
|
|
|
|
|
|
|
|
|
|
|
故障解决后24小时内，提交故障处理报告。说明故障种类、故障原因、故障解决中使用的方法及故障损失等情况。
|
|
|
|
“Ⅳ/一般”级别的信息安全事件由部门通过预警信息沟通，自行处置。
|
|
|
|
当项目实施小组成员得到“三级／较大”“二级／重大”“一级／特别重大”级别的信息安全事件的报告时，应报请网站处领导，启动应急预案并进入相应的应急响应工作程序。
|
|
|
|
在“三级／较大”“二级／重大”“一级／特别重大”安全事件发生或可能发生的情况下，按照以下流程进行处理。
|
|
|
|
（1）项目实施小组向网站处领导通报信息安全事件情况，得到指令后立即启动相应的应急处理程序。
|
|
|
|
（2）项目实施小组及时向网站处领导报告信息安全事件的发展情况，网站处领导应将情况及时上报中心主任。
|
|
|
|
|
|
（1）应急处理领导小组。职责：组织编制应急处理方案、领导指挥应急处理过程，向上级部门汇报处置情况。
|
|
|
|
（2）值班巡检小组。职责：根据日常巡检制度对系统进行巡检和监控，发现问题及时根据预案启动应急流程。
|
|
|
|
（3）应急处理小组。职责：执行应急处理措施，向应急领导小组汇报处理过程和结果，并填写应急处理记录。
|
|
|
|
（4）系统运维小组。职责：在非应急状态下负责系统的功能更新、安全加固，并根据环境配置变化及时更新应急处置手册并进行培训。
|
|
|
|
当接到报警电话，项目实施小组系统工程师迅速做出判断并验证故障现象。例如：发现XXX网站页面和各司局站点页面无法浏览；被黑客攻击等故障现象，经验证之后立刻给网站管理处打电话报告情况，判断为黑客攻击情况得到领导指示，可用VPN关闭XXX8.11和XXX8.12，并第一时间赶到现场。
|
|
|
|
|
|
|
|
当收到发送的服务器报警短信息后，第一时间联系应急处理领导小组，请示相应处理意见。如有网络可以进行相关页面查看，查看是否出现相关问题。
|
|
|
|
得到相关指示要求处理时，最快时间到达现场进行相关业务排查。
|
|
|
|
|
|
①查看服务器是否正常连通，检查相关服务器ping服务（如：ping XXX8.22）。
|
|
|
|
②如果正常能够ping通，检查访问服务器的进程是不是正常（如：ps - ef|grep tomcat）。
|
|
|
|
|
|
|
|
内网浏览器访问XXX8.47和XXX8.49是不是正常，如果正常说明属于网络的问题，如果不正常说明是服务器的问题。
|
|
|
|
XXX.47和XXX.49查看iguard服务进程，查看命令为：
|
|
|
|
|
|
|
|
查看一下CPU及其负载情况。查看命令为：top是不是负载过高引起系统运转缓慢。
|
|
|
|
查看一下硬盘占用空间是不是已经满了。查看命令为：df-h查看空间是不是已经写满。
|
|
|
|
|
|
|
|
|
|
|
|
如果Apache服务有问题，可以进行重新启动，命令如下。
|
|
|
|
|
|
如果iguard进程出现问题，可以联系相关iguard厂商协助解决。
|
|
|
|
|
|
内网浏览器访问XXX8.153/wcm是不是正常，如果正常说明XXX服务正常，如果不能访问需要查看相应服务器服务是否正常。
|
|
|
|
登录XXX.153查看tomcat进程是否正常ps-ef|grep Tomcat。查看iguard发布端是否正常ps-ef|grep iGurad。
|
|
|
|
|
|
|
|
如依然不正常可以联系工程师协助解决。如igurad不正常可以联系iguard工程师协助解决。如遇到重大情况无法及时解决，将发布系统维护中index.htm页面暂时替换首页进行发布。等待问题解决后，按领导指示进行相应替换为正常页面。
|
|
|
|
|
|
|
|
查看相应的日志文件alert-201209XX。log进行分析。
|
|
|
|
|
|
|
|
查看相应tail -f catalina.out或者more catalina.out文件日志。
|
|
|
|
查看CPU及其负载状况，执行命令为：top查看是否运转正常。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
发生安全事件时，应急处置工作人员30分钟内到达现场（判断为黑客攻击情况，并得到领导指示，可用vpn关闭XXX8.11和XXX8.12），一般情况下一小时内解决故障，恢复运行；对于有些特别重大而涉及面广的安全事件，也要在4小时内解决，不能解决的要及时上报中心领导，并说明原因和处理办法，需要请求中心支援的及时向中心领导报告。
|
|
|
|
|
|
|
|
故障现象。服务器无法正常连接，且设备面板指示灯有异常提示（细节参考服务器随机文档）。
|
|
|
|
检查及处理方式。观察服务器指示灯信号，并根据设备随机手册查找故障说明。
|
|
|
|
处理方式——检查设备的网线、电源线、光纤线缆是否松脱。如外接设备无松脱现象，应尽快联系设备售后服务机构现场处理，不得随意拆卸设备部件自行维修。
|
|
|
|
|
|
注：此类故障发生概率一般较小，且通常会被总部先监控到。但当发生网站无法访问的故障时，维护人员应先排除是否由此类故障的可能性之后，再进行下一步排查工作。
|
|
|
|
故障现象。互联网访问链路中断，网站服务器无法被外部访问到。故障现象是内网访问网站正常，但不能通过互联网访问网站。
|
|
|
|
检查及处理方式。检查服务器自身服务是否正常运行在服务器控制台桌面（注意：指通过服务器设备直连的显示器、键盘、鼠标等设备访问服务器）。
|
|
|
|
打开IE或其他Web浏览器，访问XXX88.10，如能正常显示首页，则表示服务器自身服务运行正常，可能是网络故障引起。
|
|
|
|
|
|
|
|
如果返回超时，则表明网络故障可能发生在机房，请联系运行处协助处理。
|
|
|
|
如果返回正常，则表明网络故障可能发生在上一环节，可能是前端的负载均衡设备工作异常或网络链路中断，请同时联系运行处处理。
|
|
|
|
|
|
故障分析。当前网络环境正常，但无法通过内、外网访问网站首页。客户端浏览器显示网站无法访问之类的错误提示。
|
|
|
|
导致该故障的可能原因有：服务未启动或启动了错误的Apache版本。系统自带软件防火墙或安全策略干扰。
|
|
|
|
|
|
分别登录到两台Web服务器（XXX.47/XXX.49）的远程SSH终端或服务器控制台终端，并切换到root账户，输入如下命令：
|
|
|
|
|
|
如果返回结果表明无httpd进程运行，需要重启Apache服务，操作命令为：
|
|
|
|
|
|
如经过以上方式的排查，仍未能解决问题，则可能是Apache配置错误导致网站服务工作不正常，可通过error_log文件进行详细检查。
|
|
|
|
|
|
故障分析。网站能访问，但响应极其缓慢，打开网页时间远超正常范围。
|
|
|
|
导致该故障的可能原因有：服务器磁盘设备故障导致I/O性能低下；服务器网卡故障；网络设备或线路繁忙；服务器忙于处理大规模的并发请求（很可能是DDoS攻击）；IHS自身不稳定导致资源耗尽而不能正常工作。
|
|
|
|
检查及处理方式。检查机房网管监控中是否有网络流量异常现象。检查服务器硬盘指示灯是否有故障提示。检查当前的CPU和内容占用情况，观察httpd进程是否占用资源过多，操作命令：
|
|
|
|
|
|
检查服务器当前tcp连接情况，观察对80端口的访问请求是否过多（正常情况一般在1000以下）。
|
|
|
|
|
|
断开网线后，在服务器控制台桌面访问XXX88.10，如果访问速度正常，则表明服务器软、硬件工作正常。
|
|
|
|
|
|
故障分析。网站能访问，但网站中页面与后台发布信息不一致。
|
|
|
|
导致该故障的可能原因有：WCM发布引擎未能正常生成HTML静态页面；文件未能正常同步到Web服务器中；未能正常监控到WCM发布目录中文件变化情况。
|
|
|
|
检查及处理方式。直接访问WCM服务器XXX88.10，检查页面是否更新正常。如果WCM服务器中网页也未能正常更新，可重新在WCM中发布页面，或重新启动WCM服务器。如果WCM服务器中网页更新正常，则登录到XXX.153服务器SSH终端，检查文件iguard服务是否工作正常：
|
|
|
|
|
|
|
|
|
|
如果监控服务已经在运行，则检查Web服务器端iguard服务是否工作正常。
|
|
|
|
通过SSH终端登录到XXX.47/XXX.49中，检查iguard服务是否工作正常。
|
|
|
|
|
|
如以上方式均检查无问题，可在iguard服务器端，运行同步命令强制同步，并观察是否有错误信息输出。同时检查Web iguard服务器端中是否有错误提示。
|
|
|
|
|
|
故障分析。网站能访问，但网站搜索引擎页面出现错误信息且无法正常返回查询结果。
|
|
|
|
导致该故障的可能原因有：搜索引擎中未正常配置搜索相关路径反向代理；搜索引擎服务运行故障。
|
|
|
|
检查及处理方式。检查IHS配置文件是否加入对XXX8.21服务器的反向代理。
|
|
|
|
|
|
|
|
|
|
如已经正确配置，则检查文本搜索引擎是否工作正常，并重启相关服务。
|
|
|
|
|
|
|
|
导致该故障的可能原因有：WCM集群中的应用通过NFS方式共享文件，如果某一节点中未能正常装载（mount）上／opt/XXXWCMV65/WCMData目录，则可能造成用户无法访问上传的文件。
|
|
|
|
检查及处理方式。分别登录到XXX.20和XXX.42服务器中，检查相关目录是否绑定到NAS存储中。
|
|
|
|
如发现未能正常绑定，则重新运行mount命令。mount-tnfsXXX.20:/opt/XXXWCMV65/WCMData//opt/XXXWCMV65/WCMData/。
|
|
|
|
|
|
故障分析。网站能访问，但登录“工作平台”出现系统异常页面。
|
|
|
|
导致该故障的可能原因有：WCM集群中的应用工作不正常。
|
|
|
|
检查及处理方式。登录XXX8.20或XXX8.42集群服务器执行命令ps-ef|grep Tomcat查看Tomcat服务。重新启动Tomcat服务。
|
|
|
|
|
|
|
|
为提高突发事件应急响应水平，应急领导小组应定期组织一次预案演练；检验应急预案各环节之间的通信、协调、指挥等是否符合快速、高效的要求。通过演练，进一步明确应急响应各岗位责任，对预案中存在的问题和不足及时补充和完善。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
应急小组各角色根据模拟事件说明自己的工作，操作步骤，汇报对象；
|
|
|
|
|
|
|
|
|
|
|
|
应急小组负责人宣布应急工作完成，安排值守人员，解散应急小组；
|
|
|
|
|
|
|
|
将按照信息中心要求，完成与政府门户网站及内容管理云服务平台运维相关的技术支持工作。包含但不限于以下内容。
|
|
|
|
负责对网站软、硬件系统进行风险评估及性能优化，提出系统优化可行性方案，经业主认可后，负责完成系统优化实施工作。
|
|
|
|
针对网站改造部署及迁移工作，制定系统改造方案、系统迁移及安全加固方案，内容管理平台改造的各种实施方案，主要包括环境测试方案、内容管理平台测试方案，环境切换测试方案；完成相关测试环境的搭建与维护，以及切换测试和正式切换工作。
|
|
|
|
负责对系统升级及网站年度改版所涉及的软件功能二次开发的实施工作。
|
|
|
|
|
|
|
|
我方将对政府网站内容管理云服务平台的软、硬件系统进行风险评估，性能进行分析，增加系统扩容性，并提出性能优化可行性计划。与在信息中心认可相关计划的基础上，完成相关实施工作。同时实现与其他系统接口的对接。
|
|
|
|
|
|
针对网站改造部署及迁移工作，制定系统改造方案、系统迁移及安全加固方案，内容管理平台改造的各种实施方案，主要包括环境测试方案、内容管理平台测试方案，环境切换测试方案；完成相关测试环境的搭建与维护，以及切换测试和正式切换工作。
|
|
|
|
应用软件的运维开发涉及对现有系统的改造，再通过软件测试阶段后，我们已经能够评测新建功能是否能够满足门户网站的实际需求，针对不同的版块我们将定制不同的过渡方案（新增功能上线试运行方案）。
|
|
|
|
我们坚持原系统备份策略，即在新功能上线后出现系统异常、原有功能出错等故障时，应及时实施系统回滚，恢复到系统原有状态。
|
|
|
|
|
|
公司负责对系统升级及网站年度改版所涉及的软件功能二次开发的实施工作。
|
|
|
|
在二次开发工作中，我们将提供专业的页面美工人员，结合的实际需求，为各业务系统设计和美化页面版式，制作LOGO和页面动画等。
|
|
|
|
对二次开发实现的功能，公司负责测试工作，具体内容如下。
|
|
|
|
将以修复的程序和新增功能模块部署在测试环境中，通过各种测试手段和测试流程对其进行包括：单元测试、功能测试、性能测试、压力测试、安全测试等。
|
|
|
|
测试过程由运维经理全权负责，制定详细的测试方案，待测试完成后提交测试报告给信息中心，由信息中心决定此已修复程序或是新增功能模块是否上线使用。
|
|
|
|
|
|
按照要求，完成与网站运维相关的日常工作。包括但不限于以下内容：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
做好标记，方便维护。鉴于本项目涉及局域网内部的计算机与网络通信设备相对比较多，包括测试机等，网线繁多，如果发生故障了也不知道是哪条线搭哪条线，所以对于连接计算机与路由器的网线要做好标记，在路由器端要标示连接哪台主机，在计算机端要标示是连接到路由器的哪个端口，以方便维护工作。
|
|
|
|
为路由器提供一个良好工作环境。在路由器的说明书中厂商已经明确了路由器正常运转的环境指标，所以在使用的过程中应尽量为路由器提供一个符合厂商规定的环境指标的工作环境，不然的话将影响路由器的正常工作，甚至还有可能会损坏路由器。一般需注意的是电源的电压、工作温度、存储温度、工作的相对湿度、存储的相对湿度等方面。
|
|
|
|
防电磁干扰。数据在传输过程中，会受到多方面因素的影响，电磁干扰就是其中主要的一个方面，例如音箱、无线电收发装置等设备若与路由器靠得太近的话，网络信号将可能会受到外界辐射的影响，因而尽量把路由器放在一个独立的地方，离那些会产生电磁干扰的设备远一些。
|
|
|
|
在路由器通电过程中，不要随意插拔。当路由器加电以后，就尽量不要进行带电插拔的操作，因为这样的操作很容易造成电路损坏，尽管有很多路由器的生产商已采取了一定的防护措施，但仍需分外注意，以免对路由器造成不必要的损坏。
|
|
|
|
做好防雷击措施。如果没有相应的接地保护措施，路由器就很容易遭受雷击等自然灾害的破坏，严重影响网络的稳定运行。所以要切实做好防雷击措施，用户可以通过做好设备接地装置和安装有效的防雷保护系统这两种方法来防雷击。
|
|
|
|
防断电。最好的方法就是为路由器配备性能优良稳定的UPS电源系统。UPS电源可以有效解决电网存在的诸如：断电、雷击尖峰、浪涌、频率震荡、电压突变、电压波动、频率漂移、电压跌落、脉冲干扰等等问题，若为路由器配备了UPS电源系统后，就不用再担心电压的不稳或者是突然断电会使路由器遭受损坏了。
|
|
|
|
尽量避免撞击、震荡。当路由器受到撞击和震荡时，有可能造成路由器设备的零部件松动，甚至会直接造成硬件损坏，因此在移动路由器后重新安装时，建议最好把路由器固定在特定的机架上，这样做不仅可以避免路由器受到撞击、震荡，还可以使线缆不易脱落，确保路由器正常通信。
|
|
|
|
有效预防路由器遭受静电的入侵。静电放电时很容易对路由器造成硬件损坏，随着网络设备芯片工艺的不断进步，芯片的速度和功能都有所提升，但芯片却变得更加脆弱。一个不太高的静电电压就能将晶体管击穿，一个不太大的静电电流就能将连线熔断，而静电是无处不在的，静电是网络设备的无形杀手，所以要对路由器进行有效的维护，必须采取正确的防范静电的措施。具体的做法有以下两点。
|
|
|
|
（1）路由器应保持良好的接触，要有可靠的接地装置。
|
|
|
|
（2）对于一些气候干燥的地方（如北方地区）在干燥季节应适当使用加湿器，保持空气的一定湿度，以避免静电在设备、办公设备和网络使用人员的身上大量积累。
|
|
|
|
定期进行路由器的数据备份。在网络设备中路由器使用量比较高，网络是否通畅需要对路由器进行定期检查；路由器中配置了大量的网络划分数据和网络配置数据，防止路由器损坏造成的配置丢失，需要对路由器配置数据进行备份，当路由器出现故障可以及时进行替换，减少因录音配置而浪费的时间。
|
|
|
|
|
|
用户权限检查。为防止无关人员访问系统，Administrator/root密码仅限少数人知道；所有用户不允许远程登录；新建用户单独用户可以远程登录。
|
|
|
|
系统服务检查。为防止系统不必要服务引起问题，停止所有不必要服务。
|
|
|
|
系统状态指示灯。为确认系统运行正常，检查人员每日一次到机房，观察系统前面板上的指示灯。如果所有指示灯为绿色或不亮，为正常。则在报告上标明正常。如果有指示灯为黄色、橙色或红色，则说明系统异常。在报告上标明异常，并立即通知此系统负责人。
|
|
|
|
文件系统空间使用情况。为了保证文件系统的使用率不超过96%。检查人员每日一次执行命令查看文件系统的使用率，如果所有文件系统的使用率小于96%，为正常。则在报告上记录其使用率。如果有文件系统的使用率大于或等于96%，则在报告上标明异常。并通知此系统负责人。如果有文件系统的使用率达到100%，要立即通知此系统负责人。如果有文件系统的使用率虽然没有达到96%，但其使用率每天增长超过2%，则需要在报告上注明。
|
|
|
|
CPU、内存、I/O、网络。为了记录系统负载状况，以备故障处理参考。检查人员每日一次检查CPU、内存、I/O、网络状况，并在报告上记录获得的数据。
|
|
|
|
错误日志。为确认系统运行正常，检查人员每日一次执行命令查看系统日志中是否有硬件报错信息。日志信息中无硬件报错信息，为正常，则在报告上标明正常。如果有硬件报错信息，则说明系统异常，在报告上标明异常，并立即通知此系统负责人。
|
|
|
|
双机热备软件运行情况检测。为了确认双机热备软件运行正常。检查人员每日一次执行命令查看双机热备软件运行状况。如果状态为正常，则在报告上记录其正常。如有异常，请通知此系统负责人。
|
|
|
|
系统整体使用情况周报。对每周系统运行情况作整体评估，发现问题，提出改进方案。检查人员每周记录一次系统整体使用情况周报，在报告中记录评估情况，记录发现的问题，并提出改进建议。
|
|
|
|
系统备份。为了对主机操作系统做磁带备份，以备系统崩溃时可以快速恢复，维护人员每月一次使用磁带对操作系统进行备份，并将备份好的磁带妥善保存。
|
|
|
|
填写报告。对于硬件故障，需填写“故障记录单”，对于系统参数调整，需填写“系统调整记录单”。
|
|
|
|
|
|
不必停止应用的参数修改，包括备件支持在线更换、参数修改可立即生效，且不影响应用软件的正常使用两种情况。
|
|
|
|
必须停止应用的修改，包括备件更换必须停机、必须停止应用软件后才可修改参数、参数修改重启后才能生效等情况。
|
|
|
|
不必停止应用的维护。更换时间必须在业务空闲时段。不得在正常工作时间内进行。如有实验用机，系统参数修改最好先在实验用机上实施，确认不会造成不良影响。
|
|
|
|
必须停止应用的维护。事前与业务系统维护工程师、中间件工程师、数据库工程师共同制定实施计划。若非紧急，尽可能安排在定期检修时进行。尽可能不在正常工作时间内进行。
|
|
|
|
填写报告。对于硬件故障，需填写“故障记录单”，对于系统参数调整，需填写“系统调整记录单”。
|
|
|
|
|
|
检查INSTANCE状态。每天定时登录各数据库服务器，通过SQL语句检查数据库INSTANCE状态，并填写每日数据库维护报告。如果发现INSTANCE状态异常，则进行检查处理并填写故障处理报告。
|
|
|
|
检查警告日志等文件。每天定时登录各数据库服务器，通过vi检查数据库警告日志文件，并填写每日数据库维护报告。如果发现警告日志文件有ORA-?????和WARNING错误，则进行检查处理并填写故障处理报告。
|
|
|
|
检查SQL*NET日志文件。每天定时登录各数据库服务器，通过vi检查数据库警告日志文件，并填写每日数据库维护报告。如果发现警告日志文件有错误，则进行检查处理并填写故障处理报告。
|
|
|
|
检查数据库会话情况。每天定时登录各数据库服务器，通过SQL语句检查会话情况，确认是否有死的会话占用数据库资源，并填写每日数据库维护报告。如果发现异常会话，则进行检查处理并填写故障处理报告。
|
|
|
|
检查表空间使用情况。每天定时登录各数据库服务器，通过SQL语句检查数据库表空间的使用情况（表空间名称、总大小、已用空间、未用空间、使用率、空闲率），并填写每日数据库维护报告。如果发现表空间有异常，则进行检查处理并填写故障处理报告。
|
|
|
|
监控数据库文件状态。每天定时登录各数据库服务器，通过SQL语句检查数据库各表空间数据文件的使用情况（数据文件名称、状态），并填写每日数据库维护报告。如果发现数据文件有异常，则进行检查处理并填写故障处理报告。
|
|
|
|
监控数据库临时表空间。每天定时登录各数据库服务器，通过SQL语句检查数据库查看数据库中临时表空间文件的状态（如被误删除），并填写每日数据库维护报告。如果发现临时表空间异常，则进行检查处理并填写故障处理报告。
|
|
|
|
监控数据库回滚段表空间。每天定时登录各数据库服务器，通过SQL语句检查数据库回滚段表空间数据文件的使用情况（数据文件名称、状态），并填写每日数据库维护报告。如果发现。回滚段表空间有异常，则进行检查处理并填写故障处理报告。
|
|
|
|
监控数据库联机日志。每天定时登录各数据库服务器，通过SQL语句检查数据库联机日志文件数据文件的使用情况（组别、是否归档，状态，归档时间），并填写每日数据库维护报告。如果发现异常，则进行检查处理并填写故障处理报告。
|
|
|
|
监控数据库JOB。每天定时登录各数据库服务器，通过SQL语句检查JOB运行状况，并填写每日数据库维护报告。如果JOB运行异常，则进行检查处理并填写故障处理报告。
|
|
|
|
监控数据库数据文件的I/O情况。每天定时登录各数据库服务器，通过SQL语句检查数据库数据文件IO是否正常（数据文件名、物理读，物理写），并填写每日数据库维护报告。如果发现某个数据文件I/O异常，则进行检查处理并填写故障处理报告。
|
|
|
|
检查文件系统使用情况。每天定时登录各数据库服务器，通过执行df-k名令，取得各文件系统的使用情况，并填写每日数据库维护报告。如果发现有异常增长或空间使用率过高，则进行检查处理并填写故障处理报告。
|
|
|
|
监控数据库服务器性能。每天定时登录各数据库服务器，通过使用vmstat，iostat，glance，top等命令监控CPU、IO、内存等方面的系统性能，并填写每日数据库维护报告。如果发现系统性能较低时及时预警，则进行检查处理并填写故障处理报告。
|
|
|
|
逻辑备份。每天定时登录各数据库服务器，通过查看备份服务器上的备份日志，并填写每日数据库维护报告。如果发现没有成功备份，则进行检查处理并填写故障处理报告。
|
|
|
|
逻辑备份恢复测试。每天定时登录各数据库服务器，通过回复测试服务器对备份文件进行恢复，并填写每日数据库维护报告。如果发现没有成功恢复，则进行检查处理并填写故障处理报告。
|
|
|
|
检查对象增长情况。每周定时登录各数据库服务器，通过执行SQL来检查大表、分区表、大表索引、分区索引的增长情况，并填写每日数据库维护报告。如果有异常增长，则进行检查处理并填写故障处理报告。
|
|
|
|
监控top sql情况。每周定时登录各数据库服务器，通过执行SQL来检查是否有需要优化的SQL语句，并填写每日数据库维护报告。如果有效率低下的SQL语句，则进行检查处理并填写故障处理报告。
|
|
|
|
数据库空间扩展。每周根据每天的表空间增长情况报告分析出合理的表空间增长趋势，确定扩表空间方案。并填写数据库维护报告。
|
|
|
|
系统健康检查。每周定时登录各数据库服务器，通过执行SQL来检查数据文件、控制文件是否正常，并填写每日数据库维护报告。如果有异常，则进行检查处理并填写故障处理报告。
|
|
|
|
检查无效对象。每周定时登录各数据库服务器，通过执行SQL来检查无效的数据库对象、不起作用的约束、检查无效的trigger等，并填写每日数据库维护报告。如果有无效对象，则进行检查处理并填写故障处理报告。
|
|
|
|
将所有的警告日志存档。每周定时登录各数据库服务器，为减少文件系统使用，便于查看告警日志及对历史问题的回顾及跟踪，定期备份清理所有告警日志。并填写数据库维护报告。
|
|
|
|
物理备份。每周定时对各数据库服务器，对数据库进行物理备份。如果备份有异常，则进行检查处理并填写故障处理报告。
|
|
|
