大数据系统平台项目售后服务及运营方案

大数据系统平台项目售后服务及运营方案目录TOC\o"1-3"\h\u8140大数据系统平台项目售后服务及运营方案 114789一、方案编制目的及原则 5206021.1、方案制定原则 68112二、组织体系 6298242.1、项目运维工作小组 6310792.2、项目运维工作小组人员清单 7165402.3、现场应急处理工作组 724142.4、运维质量分 7130792.4.1、运维服务质量指标 8193172.4.1、运维服务满意度指标 97484三、标准化运维流程 1016493.1、服务标准 10249973.1.1、服务工作时间 10133783.1.2、响应时间 10219363.1.3、故障恢复时间 1050603.1.4、保密条款 10265903.2、需求管理流程 1082593.3、变更处理流程 10312103.4、主动运维服务 10168031、服务报告 1153372、系统性能排查 11252833、软件监控 1236714、项目风险识别 12183905、客户回访 1212820四、运维及驻场服务内容 1332874.1、健康检查 13222784.1.1、检查列表 13133744.1.2、操作系统检查 18183614.1.3、数据库检查 19124374.1.4、中间件服务检查 21240774.1.5、大数据相关检查 26265424.2、深度巡检服务 27302394.2.1、平台资源配置 27257294.2.2、自动告警 30146334.3、日常问题及BUG处理 35217564.4、信息资源调研支持 3521964.5、需求变更收集和反馈处理 3569844.6、平台小版本升级 35211564.7、共享交换前置区维护 36139114.8、资源监控与容量评估 3695624.8.1、实时监控 3691374.8.2、告警提醒 37147164.8.3、统计分析 37114824.8.4、优化分析 38161114.9、业务上线支持 38258084.10、资源目录动态维护 38155534.11、数据维护服务 39323544.11.1、采集数据建模入库服务 39108974.11.2、数据处理（清洗、比对、转换）服务 39108774.12、数据交换运维服务 39220794.12.1、公司数据调研服务 39260134.12.2、公司数据目录梳理服务 3924.12.3、公司的数据采集方案支持服务 3956364.12.4、公司的数据采集服务 40103334.13、数据共享运维服务 40103404.13.1、数据中心数据根据需求提供数据接口服务 4098654.13.2、公司数据需求提共享库数据服务 4018224.14、技术交流 4049334.15、技能传递服务 40266994.16、重大活动运维服务 4013113五、数据备份 4143845.1、常规备份 4195415.1.1、备份策略 41249505.1.2、备份实施 42318615.1.3、备份文件验证 45205955.1.4、恢复实施 45272535.1.5、存储空间估算 4629905.2、容灾备份 4817165.2.1、相关概念说明 48133805.2.2、应用系统容灾目标 48244755.2.3、应用系统容灾需求分析 49209155.2.4、MySQL数据库容灾实现方案 50119065.2.5、应用程序容灾实现方案 5342205.2.6、应用系统灾备恢复预案 5631475.2.7、容灾建设资源需求清单 5721204六、安全密钥处置管理 57132566.1、管理机制简述与建议 573059（一）工程阶段 572131（二）后续建议 57252786.2、业务系统访问账号管理 5726366.3、服务器访问账号管理 58160966.4、数据库访问账号管理 59287586.5、账号变更及密钥变更管理 5915250七、技术支持 6049877.1、专家保障 6055257.2、电话咨询 6035107.3、远程协助 6156907.4、现场响应 619575八、故障处理 61193058.1、业务SLA定级 62137518.2、故障级别 6274208.3、故障处理流程 637808.3.1、处理故障需注意以下事项 6345978.3.2、故障为以下问题的处理流程 639186九、应急保障 64277279.1、现场应急处理 64107119.2、系统应急保障 65144679.2.1、机房故障 65214169.2.2、电源故障 6556149.2.3、设备故障 6562499.2.4、主备倒换故障 66265639.2.5、安全攻击 6774969.2.6、系统卡顿 68230849.2.7、平台无法登录 68178569.2.8、附件无法上传下载 6866439.2.9、API网关故障 6929519.3、数据应急保障 7099109.3.1、误删数据 7056519.3.2、库表资源异常 7149099.3.3、部门数据交换异常 71206079.4、网络应急保障 72307429.4.1、网络故障 72108389.5、报告与总结 72374十、护航保障措施 721424910.1、本地化服务 72481310.2、组织及人员保障 721404410.3、必备资料 732410610.4、数据保障 732099110.5、安全条款 73325410.6、宣传、培训和演习 732447910.7、定期巡检 741962210.8、服务监督 7418298十一、服务报告 753064911.1、周报 75447411.2、月报 752423611.3、季报 75662711.4、年报 752695611.5、运维例会 7531641十二、运维进度安排 7530729十三、运维涉及表单 76253413.1、客户需求确认单 76696913.2、客户需求评估单 771566113.3、需求变更申请单 77549213.4、需求变更实施单 782109613.5、客户需求结案单 79246613.6、故障分析报告 79701213.7、现场维护确认单 803141813.8、服务器巡检报告 811180213.9、培训签到表 811286713.10、季度/年度维护服务总结报告 812140013.11、客户拜访单 81方案编制目的及原则确保各公司办公系统信息安全和数据安全，提高应对突发事件的组织指挥能力和应急处置能力，最大限度地预防和减少突发信息安全事件及其造成的损害，确保系统的安全畅通，为客户提供及时、有效、稳定的服务。方案制定原则本方案主要针对应用系统、服务器及数据库软件制定合理科学的维保策略。方案的制定遵循以下原则：本项目的最终目标是保证业务系统的安全和可靠运行。包括计算机系统的可靠运行和业务数据的安全保证，我们将动用一切有效的措施手段，力求业务系统万无一失，我们的目标是：“非正常性停机时间为零”。重在措施：注重预防，我们将在传统的被动式服务的基础上提供主动式的服务，和客户一起做好系统的监控维护工作。采取以预防为主的策略，把故障隐患消灭在萌芽中。服务组织，服务组织管理和流程管理是项目成功得关键。我们将在责任工程师（项目经理）的统一调度下，指挥技术、应用、商务及服务监督人员，在售前、服务实施、售后的各个环节紧密与客户方配合追求最佳性价比：服务的级别意味着客户的成本，我们在保障高标准服务的前提下，努力通过精心组织、精心实施来降低客户的成本，同时为客户提供更多的增值服务。组织体系项目运维工作小组成立项目运维工作小组，团队成员不少于10人。组长由运维部主管工程师担任，指定为项目售后服务接口人。副组长由开发部、实施部各相关部门技术骨干担任。成员公司由项目开发组成员，项目实施组成员等组成。小组的职责：负责系统运行维护管理工作；研究制定系统信息安全应急处置工作的规划、计划和政策；协调推进系统信息安全应急机制和工作体系建设；指导协调各类应急工作组开展对信息安全突发事件的应急响应与处置工作；对系统信息安全事件的响应作出正确的判断和决策等。根据项目特点决定驻场人员个数，驻场人员不少于4人，负责驻点运维工作，包括相应系统的管理和运维，运维人员提供工作日5*8小时的现场驻场服务，严格按客户的工作日要求进行出勤。项目运维工作小组人员清单无现场应急处理工作组现场应急处理工作组，在出现安全事件后，对计算机系统和网络安全事件的处理提供技术支持和指导，遵循正确的流程，采取正确快速的行动作出响应，提出事件统计分析报告。现场应急处理工作组由以下各方面的人员组成：管理方面包含项目经理，以及相关成员、部门负责人。主要确保安全策略的制定与执行；识别网络与信息系统正常运行的主要威胁；在出现问题时决定所采取行动的先后顺序；做出关键的决定；批准例外的特殊情况等。技术方面应包含开发部技术人员，实施部技术人员等主要负责从技术方面处理发生问题的系统；检测入侵事件，并采取技术手段来降低损失。运维质量分共享开发平台软件运维质量分由服务质量和服务满意度两部分构成，分别占有总分的90%和10%，总分100分。服务质量以默认100分为基准，当出现一项不满足项进行扣分，出现多次不满足时可以重复扣分。客户满意度以默认100分为基准，当出现一项不满足项进行扣分，出现多次不满足时可以重复扣分。总体得分＝(服务质量得分/100)×90＋(客户满意度得分/100)×10。从服务质量、服务使用满意度两个角度衡量，这些级别构成了以三星级为最高级，一星级为最低级的层次结构。级别对应实际评估值区间三星★★★90≤X＜100二星★★75≤X＜90一星★60≤X＜75注：X为按照本方法进行评估而获取的评估分数值。运维服务质量指标包括应用系统运维服务、数据运维服务、安全管理服务、故障应急服务4个方面，包含7个内容：共享开放平台功能维护、数据运维、数据入库与出库、信息安全管理及数据标准制定、应急预案建立及使用机制、技术支持人员、故障及时修复机制，具体指标如下所示。服务分类服务内容扣分原则否（次）应用系统运维服务（20分）共享开放平台功能维护（20分）项目组是否每日检查系统运行情况、数据库运行情况并每周、每月、每季度、每年反映项目运维情况？是，不扣分；否，每次扣除1分（10分）协助进行数据调研工作，完善政务资源目录；在相关平台系统的应用功能不能适应业务需求时，运维方应及时安排技术人员进行软件功能的修改或升级。分值10分，未完成一次扣2分。数据运维服务（30分）数据运维（10分）建立数据质量和安全的防护机制。分值10分。数据质量问题未及时推进每1个扣1分。按周期备份数据，每少1次或备份数据不全扣1分。发生数据泄露，扣10分，并追究后续责任。数据入库与出库（20分）各委办局提交数据后，接口数据和数据库同步要求实时入库；前置机数据要在1个工作日内完成数据入库。各委办局数据共享审批完成后，要在2个工作日内完成数据出库的相应工作。分值20分。未按时完成一次扣1分。安全管理服务（10分）信息安全管理及数据标准制定（10分）建立信息安全保障和业务流程体系，与数据处理专职团队及人员签订保密协议；根据主流数据库及中间件技术标准，制定符合相应数据格式的统一标准。分值10分。未签订保密协议扣5分，未制定统一标准扣5分。故障应急服务（40分）应急预案建立及使用机制（10分）建立应急预案，并在遇到紧急事件时使用应急预案。分值10分。未建立应急预案扣10分，遇紧急情况未使用应急预案一次扣2分。技术支持人员（10分）技术支持总人数应不少于4人，并应在半小时内响应。分值10分。未在半小时内响应1次扣2分。故障及时修复机制（20分）应保障共享开发平台运行平稳，如出现故障应及时修复，分值10分。每出现1次影响委办局正常使用的故障，扣1分，在1小时内未修复的，再扣1分；每出现1次影响项目正常使用的故障，扣5分，在半小时内未修复的，再扣2分；出现重大故障，在1天内未修复或被资源使用方书面投诉并确认的，1次扣10分。总体得分满分100分运维服务满意度指标服务满意度指标是衡量服务提供机构服务质量的综合指标，是从甲方角度评价服务产品或服务质量的一种指标体系，具体指标如下所示。项目服务使用满意度指标否/次运维人员服务满意度运维人员的服务态度和服务意识的满意度（10分）运维人员对事件及处理问题的响应速度（10分）运维人员对系统问题诊断及处理结果满意度（10分）运维人员专业水平满意度（10分）运维人员服务管理规范性的满意度（10分）系统满意度系统稳定性满意度（10分）系统运行速度满意度（10分）系统操作方便性（10）数据服务满意度数据处理质量满意度（10）数据服务质量满意度（10）总体得分满分100分标准化运维流程服务标准服务工作时间项目最终验收前提供对系统提供维护服务，对已经上线运行的系统提供5*8小时运维服务。自验收之日起提供不低于1年的现场支持服务。7*24*365电话、网站、电子邮件等方式受理服务请求或帮助客户解决技术问题。响应时间现场服务时间为5*8小时，其余时间接到报修后30分钟内予以实质性响应，工程师1小时内到达服务现场。故障恢复时间一般性故障在2小时内做出故障诊断和恢复，复杂故障在4小时内恢复。保密条款本公司将严格遵循保密协议，凡涉及客户的机型配置、IP地址、软件等信息不得向第三方泄露，维护过程中如需涉及客户系统的数据信息，必须先通过客户方认可，维护工作的数据信息（无论是打印或介质上的数据信息）不得带离客户工作现场。需求管理流程执行需求管理流程。变更处理流程执行变更处理流程。主动运维服务在维护工作前，本公司工程师须提前24小时（紧急故障处理除外）向客户项目主管提出书面的维护申请。内容包括维护的目的、操作工程师、操作步骤、涉及系统硬件变更、涉及系统软件变更、预计操作所需时间、申请操作所需时间等内容。待得到客户项目主管书面批复后维护工作方能开始，且所有操作必须有客户方代表在场。如维护工作需要使用移动介质，则必须事先在本地进行病毒检查，经客户方确认方可使用。维护操作必须事先做好操作方案并制定应急方案，必须严格掌握控制操作时间。所有操作记录须存档并长期保留。主动改进服务方向：及时发现维护人员在项目维护过程中的问题，要求改进。方式：服务报告、系统排查、软件监控、事项风险识别、客户回访。服务方式：1、服务报告每月项目刷选人员通过维护事项发生的频率测算各项目所需服务报告的类型，发出邮件通知要求不同的项目需要产生周报、月报、季报提供给客户。年终需产生年报提供给客户。通过月报汇总近阶段项目运行情况和问题处理进展，让客户了解维护人员的工作内容和职责。一方面让客户认可维护人员的工作；另一方面客户对项目问题进展有质疑或工作内容有遗漏等情况，可根据月报中提供的部门管理人员的联系方式进行沟通，方便部门及时发现问题进行协调，降低项目维护的风险。频率：每周有5个及以上维护事项需整理周报发送给客户；每月有5个及以上维护事项需整理月报发送给客户；每季有3个及以上维护事项需整理季报发送给客户；所有项目年终需整理年报发送给客户。系统性能排查在做服务器巡检的同时排查系统中是否存在执行耗时长的语句，及时进行处理。主动排查和处理系统中存在执行慢的语句，对系统进行优化，并对此项记录整合至月报中，提升客户体验。步骤：（1）维护人员在做服务器巡检时需检查数据库中语句的执行情况，项目的巡检事项中除了反馈巡检报告外，还需反馈系统性能排查的结果和处理过程。（2）sql通过sqlProfiler进行跟踪处理。（3）对刷选出执行时长超过3秒的语句，通过增加索性等方式先自行处理，若没有效果，把问题在巡检事项中描述清楚，可直接把事项转给开发人员，要求开发优化语句。（4）完成后处理后，需把跟踪出的语句、处理过程、最终结果整理在月报的“监控和排查处理”栏中。3、软件监控每天定时访问系统，一旦系统不能访问，维护负责人会在公司OA中收到邮件提醒，及时进行处理。及时发现系统不能访问这类严重情况，争取在客户联系维护人员前就处理完成，让客户感受到维护人员对项目的主动关注。4、项目风险识别部门经理每半个月发起部门内维护项目风险收集邮件，维护负责人罗列所有正在处理中或已经处理完成但仍存在风险的维护事项，并根据提供的风险判断标准，描述有风险的事项，收集后部门经理针对风险事项安排协调。及时发现维护项目中资源协调困难、处理进度缓慢等情况，由部门经理通过沟通协调或逐级上报等方式，控制项目风险。步骤：（1）每半月提醒人员发出邮件提醒各部门对维护事项进行风险排查。（2）部门安排维护人员在2工作内把处理中维护事项和风险点进行反馈。（3）汇总人员汇总部门内维护人员反馈列表。（4）部门经理了解事项的风险点，通过提供建议、沟通协调、逐级上报等方式控制项目风险。5、客户回访重点项目由组长或部门经理和维护负责人一起去客户现场拜访，普通项目安排条线专人进行电话回访，了解项目的维护情况，及时调整和改进维护过程中的问题。通过客户回访，了解项目的维护情况，及时调整和改进维护过程中的问题。（1）部门安排采集重点和普通项目列表。（2）部门经理和组长对项目列表进行审核，对重点项目安排好去现场的人员和日期。（3）针对现场拜访的项目：（3.1）维护负责人登记“拜访”类维护事项，跟组长或部门经理一起去现场拜访。（3.2）现场拜访需登记现场签单，完成后拍照上传至对应事项。（3.3）整理现场拜访采集到的问题，发出相关事项跟进处理。若有新增需求发邮件提醒商务并安排开发人员进行评估。运维及驻场服务内容健康检查对应用系统和部署应用系统的服务器每一个月进行一次巡检，对应用软件自身的风险进行排查处理，对第三方的设备导致业务系统的风险，提出相应的建议和改进方案，巡检结束后提供《巡检报告》。巡检报告期提供给客户负责人，客户对于巡检报告的任何疑问可以联系项目负责人。检查列表序号检查点是否必要检查类型完成状态一．操作系统相关Linux系统1服务器启用系统防火墙必要人工2服务器时间设置同步开启必要人工3查看系统时间是否正常（特别是内网服务器，无法同步时间的情况）必要人工4查看计划任务，是否有非公司业务任务可选人工5检查监听端口，查看是否有非公司业务端口可选人工6检查进程，查看是否有可疑进程可选人工7检查登录信息可选人工8检查passwd文件，查看是否有可疑用户可选人工9sudoer中是否有可疑用户可选人工10root密码策略是否包含字母大小写、数字、特殊字符和长度大于8位必要人工11设置密码最大尝试次数及超过错误次数封禁策略必要人工12root密码过期天数设置可选人工13检查/etc/hosts文件，是否被篡改可选人工14系统端口开放必要（红线）人工二．数据库相关MySQL15检查服务器是否为linux必要人工16限制MySQL的访问IP来源，只允许业务服务器才能通过网络连接必要人工17修改MySQL的默认端口必要人工18检查MySQL是否以mysql用户进行启动必要人工19检查mysql用户的权限，仅对mysql的datadir有权限必要人工20检查mysql用户的权限，不能以普通用户的方式登录系统必要人工21检查MySQL的root账号是否可以被远程访问，除了MHAManager服务器和监控服务器以外，禁止root用户远程登录必要人工22检查/etc/f中是否包含密码必要人工23数据库是否开启加密可选人工24数据库是否做了定时备份必要人工25数据库是否做了异机备份必要人工26确保业务程序的数据库连接使用普通用户权限，而非root权限必要人工27确保业务程序使用的用户权限仅在业务自己的数据库，而不能读取其他数据库必要人工28确保mysql的root密码策略是否包含字母大小写、数字、特殊字符和长度大于8位必要人工29确保业务系统的用户的密码策略是否包含字母大小写、数字、特殊字符和长度大于8位必要人工30确保数据库有完整的备份策略必要人工三．中间件相关Tomcat31检查tomcat版本必要人工32隐藏Tomcat和访问404页面时的版本信息必要人工33删除Tomcat目录下，docs、examples、hostmanager、manager、pspframe、ROOT应用必要人工34检查JVM是否使用server参数启动必要人工35检查服务器环境是否安装JDK环境必要人工36不可以使用多个虚拟主机部署应用必要人工37关闭war包自动部署的功能必要人工38以非root用户启动应用必要人工39tomcat下禁用不安全的http方法必要人工Nginx40检查nginx版本必要人工41禁止使用Nginx正向代理必要人工42禁止nobody对所有目录的读取权限，对网站目录的读取权限必要人工43限制访问nginx下的txt文件或则log文件必要人工44禁止列出nginx目录下的文件夹必要人工45禁止nginx在错误页面显示版本信息必要人工Redis46检查redis版本必要人工47不建议公网环境下redis直接对外提供服务必要人工48绑定网络监听的IP地址必要人工49给redis添加密码必要人工50使用非root权限启动Redis必要人工四．大数据相关51业务系统密码复杂度必要人工52业务系统双因素认证必要人工53Web安全模块必要人工54https证书必要人工55检查是否部署nginx反向代理必要人工56业务系统高可用可选人工57检查超时断开空闲会话必要人工58系统最大并发连接限制必要人工59单个用户多重并发限制必要人工60平台监控必要人工61检查业务系统JDBC连接数据库是否传输加密必要人工62检查数据交换平台JDBC连接数据库是否传输加密必要人工63Kong组件启用https必要人工64检查Kong接口是否开启日志审计必要人工Linux操作系统检查服务器时间设置同步开启查看系统时间是否正常（特别是内网服务器，无法同步时间的情况）查看计划任务，是否有非公司业务任务 检查进程，查看是否有可疑进程 检查登录信息 检查passwd文件，查看是否有可疑用户 sudoer中是否有可疑用户 root密码策略是否包含字母大小写、数字、特殊字符和长度大于8位设置密码最大尝试次数及超过错误次数封禁策略root密码过期天数设置 检查/etc/hosts文件，是否被篡改 系统端口开放数据库检查限制MySQL的访问IP来源，只允许业务服务器才能通过网络连接修改MySQL的默认端口检查MySQL是否以mysql用户进行启动检查mysql用户的权限，仅对mysql的datadir有权限检查mysql用户的权限，不能以普通用户的方式登录系统检查MySQL的root账号是否可以被远程访问，除了MHAManager服务器和监控服务器以外，禁止root用户远程登录检查/etc/f中是否包含密码数据库是否开启加密 数据库是否做了定时备份 数据库是否做了异机备份 确保业务程序的数据库连接使用普通用户权限，而非root权限确保业务程序使用的用户权限仅在业务自己的数据库，而不能读取其他数据库确保mysql的root密码策略是否包含字母大小写、数字、特殊字符和长度大于8位确保业务系统的用户的密码策略是否包含字母大小写、数字、特殊字符和长度大于8位确保数据库有完整的备份策略中间件服务检查Tomcat检查tomcat版本隐藏Tomcat和访问404页面时的版本信息删除Tomcat目录下，docs、examples、hostmanager、manager、pspframe目录检查JVM是否使用server参数启动

检查服务器环境是否安装JDK环境不可以使用多个虚拟主机部署应用关闭war包自动部署的功能

以非root用户启动应用禁用不安全的http方法Nginx检查Nginx版本禁止使用Nginx正向代理

禁止nobody对所有目录的读取权限，对网站目录的读取权限限制访问nginx下的txt文件或则log文件

禁止列出nginx目录下的文件夹禁止nginx在错误页面显示版本信息Redis检查Redis版本不建议公网环境下redis直接对外提供服务绑定网络监听的IP地址给redis添加密码使用非root权限启动Redis大数据相关检查使用HTTPS加密协议传输检查业务系统JDBC连接数据库是否传输加密检查数据交换平台JDBC连接数据库是否传输加密深度巡检服务平台资源配置服务端服务器巡检每日安排人员定时监控服务端主机服务器运行状态，监控内存、cpu、磁盘使用率及读写速率情况、网卡收发速率等相关重要参数值；协调服务器资源管理方定期提供管理平台服务器阶段时间内运行状态监控报告，发现异常时及时进行排查处理。确保服务端服务稳定运行。客户端主机服务器状态监控每日安排人员通过管理平台进行监控主机的运行状态，对cpu、内存、运行情况、磁盘空间使用情况何读写情况、网卡接收、发送及磁盘分区情况进行监控。同时需定期检查客户端与服务端的连通性，确保整体服务的稳定性。应用监控应用创建时会让我们自动生成监控地址，在平台监控平台体系中，平台会根据监控地址，结合用户指定的监控协议发送心跳包，检测被监控应用是否存活，例如如果指定了HTTP，则平台会向指定地址发送一个HTTP请求，如果返回200或者302则代表该应用是存活的。在应用监控视图中可以查看到该应用的状态,此处需要注意的是，如果在此处需要注意如果应用监控填写的监控地址正确无误的话，若发现应用监控存在异常，需要立刻检查是否该应用下所属的容器与虚拟机应用正常运转，因为如果报出异常说明你的应用已经停止了服务。服务监控对服务的监控是对一个托管于应用的性能监控最直观的地方，在服务监控中包含了很多基础组件的监控指标，对日常的运维与管理提供相关数据依据。点击菜单【综合监控】-【服务监控】即可打开服务监控概览视图，在该界面中，我们可以根据系统概览视图快速的过滤出关心的系统，并以此快速的选出我们需要监控查看的服务。在概览视图中我们可以快速的查看到平台为使用者准备的几个较为重要的值，以最常用的Tomcat为例，使用者可以快速的查看到，当前Tomcat容器每秒的请求并发数，已经当前工作线程数量，和JVM内存使用。在概览视图中这些数据默认为当前最新的值，点击最右侧的详情页面按钮即可查看针对每一个组件的更多监控指标。点击查看详情按钮即可打开服务监控详情查看页面，如下图所示，以Tomcat为例：巡检人员可以在概览页面中获取到如下指标：JVM的使用内存信息Tomcat配置的最大线程数与当前工作的线程数信息Tomcat进出流量统计:该值需要与实际的机房网卡带宽作为比较，如果宿主机的网卡带宽是属于百兆的网络，那么这里的最高值也就只有百兆。请求总数:Tomcat接收到的请求总数，该数值中包含成功请求(状态为200或302)和错误失败请求数量(状态为50x)。请求数:Tomcat接受到并正确处理响应的请求数。错误数:Tomcat接收到请求，但是为正确的处理返回50x的请求数。请求最大处理时间:该值统计了所有的请求中处理时间最长的一个请求耗时请求平均处理时间:该值表示Tomcat自启动后处理所有的请求平均耗时。使用者可以通过Tab页面切换不同的视角对服务进行监控，如下所示，我们可以切换至请求信息页面，即可查看到所有的请求数据，以线状图的形式统计所有的历史数据。介绍平台中常用的一些服务的监控指标及其意义。Nginx服务监控在服务监控页面概览中，使用者可以获取如下监控指标：进程数:Nginx服务启动的工作进程数，默认情况下该值配置为auto，Nginx会根据服务器的CPU自动适配响应的进程数，已获得较高的性能连接数:该指标指明当前Nginx与前端包含多少个KeepAlived连接，该数值越高越好。请求数:该值表示Nginx每秒钟接受的请求数处理数:该值表示当前Nginx每秒钟正在处理的请求数丢弃数:该值表示当前Nginx每秒钟未处理请求数访问成功数:该值表示每秒钟Nginx成功代理的请求数访问失败数:该值表示每秒钟Nginx未成功代理的请求数点击详情页面即可查看到更加详细的监控指标，以及使用折线图形式绘制出的历史值变化曲线。如上图所示，使用在详细监控视图中还可以获取到Nginx组件网络流量收发情况等信息：运行时间:Nginx组件自启动到查看监控时，运行时长，每次重启Nginx服务该时间都会进行一次重置接收速率:Nginx组件每秒钟接收到的请求流量发送速率:Nginx组件每秒钟发送出去的请求流量切换相应的Tab页面即可查看相应的监控指标，以请求信息为例，使用者的可以查看到小时、天、周、月等不同监控范围内的数值波动Redis服务监控在服务监控页面概览中，使用者可以获取如下监控指标：访问地址:从此处可以快速获取到redis的访问地址与端口信息。连接数:从此处获取到当前连接到redis的服务端的连接数，在默认配置中提供的redis镜像默认配置10000个连接刷新时间:最近一次获取redis监控指标的时间key总数:表示当前redis服务中包含的key总数命令数/s:表示当前redis每秒钟执行的命令数命中率:表示当前redis服务中执行get/hget等命令操作时快速命中key的百分比，该数值越大越好集群:该字段表示当前redis服务的模式，standalone表示当前节点为单实例模式，cluster表示当前服务模式为集群模式点击详情页面即可查看到更加详细的监控指标，以及使用折线图形式绘制出的历史值变化曲线：分配内存:该监控指标表示当前操作系统预分配给redis服务的内存,该值不表示所有redis已使用的内存：使用内存:该监控指标表示当前redis占用的内存值AOF状态:该值表示是否开启AOF持久化，标记为开启AOF大小状态才有监控值存在RDB最近保存时间:该值表示当前最新一次保存内存镜像快照的时间切换不同的tab页即可以查看监控指标历史值信息。容器监控本节主要如何在平台中监控业务容器的运行状态，主要包括容器使用的CPU、内存、磁盘读写与IOPS、容器日志等。在WEB管理面中依次进入【综合监控】-【容器监控】即可打开主机状态概览界面，概览界面包含两个组成部分，系统分类树视图和容器概览视图，点入界面默认显示所有容器状态，用户可以选择左侧的系统目录树，则只显示与所选系统相关联的容器状态。如上图所示。在容器概览中可以查看到当前容器的状态，以及使用的CPU和内存情况，这里需要明确的是，如果没有限制CPU和内存量，则列表中显示的使用率都是相对于主机的资源，例如，内存使用50%，则表示，当前容器使用的内存占整个主机的50%。如上图所示，通过容器监控详情页面主要提供如下几个监控指标容器网络的使用量：提供该容器网卡的接收速率和发送速率，公司是Mb/s，此处需要明确，无论是桥接或者HOST模式启动的容器，该值只代表该容器使用的网络速率容器磁盘的使用量：提供容器读取速率与写入速率,公司是MB/s，IOPS是没有公司的，此处需要明确，对于单独挂载数据卷进入容器，监控其读写使用需要监控数据卷所在磁盘的用量，而非此处的值。如上图所示，点击【查看监控详情】按钮即可以曲线图的形式展示容器监控指标的历史值，同主机监控一样，通常情况下我们建议，评定某一个值达到瓶颈不要单单只是查看一个监控指标的瞬时值，而是应该查看该监控指标在监控时间段内的平均值或连续值。在平台中，将容器的日志分为两种三种类型:容器启动日志-boot.log：该日志记录了Docker启动一个容器的日志。容器标准输出/错误日志：该日志记录了容器启动过程中标准输出与标准错误输出日志，从当中可以找到容器启动后立即停止的问题(请区分容器启动不了和容器启动了但是内部程序无法访问的区别)。容器内应用程序日志：该日志是容器内程序(例如Tomcat产生的wrapper日志)产生的日志，框架业务程序的报错日志都记录在这里。ECAgent启动日志：该日志记录了平台ECAgent启动容器时使用的参数信息。与主机日志监控方式类似，平台提供如下即可日志查看操作。如上图所示，使用者可以在页面中选择需要查看的日志内容，在页面上方，平台提供给大家五种查看日志的操作：下载:点击此按钮可以将当前查看的日志下载至本地目录中清空页面内容:对于日志输出较多的程序，使用可以清楚页面中的内容重新获取最新的内容（此操作不会清除日志）停止刷新:对于输出日志较多的程序，页面会不断的滚动显示日志，点击此按钮即可停止实时输出滚动启用刷新:与停止刷新按钮操作相反数据库监控在监控数据库的实质就是在数据库中预埋入一段存储过程，所以在添加的数据库监控时，请确保监控的账户具有DBA权限，否则平台无法实现对数据库的监控，下面以MySQL为例配置一个数据库监控，首先点击【部署编排】-【数据库管理】按钮进入数据库监控配置页面，点击【新增数据库】按钮添加数据监控，如下图所示，请确保在数据库用户名和密码处填写具有DBA权限的账户。配置完成后点击保存按钮，等待平台采集监控指标值。配置完数据库后用户可以在【综合监控】-【数据库监控】菜单中查看到刚才添加的数据库监控状态，在概览页面中可以查看到数据库的概要信息。点击详情按钮即可查看到当前数据库详细的监控信息。点开详情页面可以看到当前MySQL数据库的监控详情信息，如下图所示，从监控指标中我们可以获取到当前数据库的连接数，数据库缓存使用量等等监控指标。自动告警平台提供系统运行健康度指标的实时监控和自动告警功能。系统以下健康指标到达告警阈值后，会立即发送告警信息到运维人员账号，并记录告警的详细信息，供运维人员排查问题原因。中文名称比较符号比较值类型处理类别处理建议应用访问时间>=3000apprsptime1、通过查看应用日志是否有异常提示，或发送给开发进行排查

2、通过查看应用容器cpu，内存使用率是否过高

3、通过查看应用相关中间件及数据库的资源使用率是否过高应用状态!=1appstate1、通过查看tomcat服务本身是否正常

2、通过查看应用日志是否有报错提示容器状态!=1dockerstate1、通过查看容器所在主机本身是否运行

2、通过查看容器实时日志是否正常容器cpu使用率>=90dockercpu1、通过查看应用日志是否有异常提示，或发送给开发进行排查容器内存使用率>=90dockermen1、通过查看应用日志是否有异常提示，或发送给开发进行排查主机磁盘空闲<=5hostdisk1、按实施巡检规范处理，清理无用数据或扩容磁盘主机cpu使用率>=90hostcpu1、通过查看主机内所有容器利用率情况，然后查看利用率高的容器中应用日志是否有异常提示，或发送给开发进行排查主机内存使用率>=90hostmen1、通过查看主机内所有容器利用率情况，然后查看利用率高的容器中应用日志是否有异常提示，或发送给开发进行排查主机状态!=1hoststate1、检查主机网络是否联通，尝试ping或远程

2、检查主机开机状态，联系机房管理员云平台控制查看或机房检查主机根分区空闲<=1hostdisk1、按实施巡检规范处理，清理无用数据或扩容磁盘mongodb数据库状态!=1mongodbstate1、远程所在主机查看服务运行状态

2、使用对应工具检测连接是否正常mongodb数据库当前连接数>=700mongodbconn1、查看是否有连接泄露，具体做法远程主机输入命令：ss-tunp|grep<port>请将<port>替换为项目现场真实的端口，默认为27017，然后将输出的列表发给项目开发进一步排查mongodb数据库连接使用率>=80mongodbconn1、查看是否有连接泄露，具体做法远程主机输入命令：ss-tunp|grep<port>请将<port>替换为项目现场真实的端口，默认为27017，然后将输出的列表发给项目开发进一步排查mssql数据库当前连接数>=700mssqlconn1、查看是否有连接泄露，具体做法远程主机CMD中输入命令：netstat-an|findstr<port>请将<port>替换为项目现场真实的端口，默认为1433，然后将输出的列表发给项目开发进一步排查mssql数据库状态!=1mssqlstate1、远程所在主机查看服务运行状态

2、使用对应工具检测连接是否正常mssql数据库最大连接数<=800mssqlconn1、查看是否有连接泄露，具体做法远程主机CMD中输入命令：netstat-an|findstr<port>请将<port>替换为项目现场真实的端口，默认为1433，然后将输出的列表发给项目开发进一步排查mssql数据库连接占用率>=80mssqlconn1、查看是否有连接泄露，具体做法远程主机CMD中输入命令：netstat-an|findstr<port>请将<port>替换为项目现场真实的端口，默认为1433，然后将输出的列表发给项目开发进一步排查mysql数据库当前连接数>=700mysqlconn1、查看是否有连接泄露，具体做法远程主机输入命令：ss-tunp|grep<port>请将<port>替换为项目现场真实的端口，默认为3306，然后将输出的列表发给项目开发进一步排查mysql数据库状态!=1mysqlstate1、远程所在主机查看服务运行状态

2、使用对应工具检测连接是否正常mysql数据库最大连接数<=800mysqlconn1、查看是否有连接泄露，具体做法远程主机输入命令：ss-tunp|grep<port>请将<port>替换为项目现场真实的端口，默认为3306，然后将输出的列表发给项目开发进一步排查mysql数据库连接占用率>=80mysqlconn1、查看是否有连接泄露，具体做法远程主机输入命令：ss-tunp|grep"3306"查看有哪些ip连接，然后进行进一步分析nginx服务状态!=1nginxstate1、通过查看所在容器状态是否正常

2、通过远程容器查看nginx进程是否正常

3、通过查看nginx日志是否有异常提示，或发送给开发进行排查oracle数据库会话使用率>=80oracleconn1、查看是否有连接泄露，具体做法远程主机输入命令：netstat-tunp|grep<port>请将<port>替换为项目现场真实的端口，默认为1521，然后将输出的列表发给项目开发进一步排查oracle数据库表空间使用率>=80oracletablespace1、清理无用数据或进行扩容oracle数据库状态!=1oraclestate1、远程所在主机查看服务运行状态

2、使用对应工具检测连接是否正常oracle数据库当前会话数>=2000oracleconn1、查看是否有连接泄露，具体做法远程主机输入命令：netstat-tunp|grep<port>请将<port>替换为项目现场真实的端口，默认为1521，然后将输出的列表发给项目开发进一步排查oracle数据库最大连接数<=1800oracleconn1、查看是否有连接泄露，具体做法远程主机输入命令：netstat-tunp|grep<port>请将<port>替换为项目现场真实的端口，默认为1521，然后将输出的列表发给项目开发进一步排查rabbitmq服务状态!=1rabbitmqstate1、通过查看所在容器状态是否正常

2、通过远程容器查看rabbitmq进程是否正常

3、通过查看rabbitmq日志是否有异常提示，或发送给开发进行排查rabbitmq服务消费速率<=80rabbitmqrabbitmq1、查看是否有连接泄露，具体做法远程主机输入命令：ss-tunp|grep<port>请将<port>替换为项目现场真实的端口，默认为5672，然后将输出的列表发给项目开发进一步排查rabbitmq服务磁盘剩余量<=2rabbitmqrabbitmq1、通过监控页面查看消息数量

2、清理无用数据或进行扩容rabbitmq服务内存使用率>=80rabbitmqrabbitmq1、查看是否有连接泄露，具体做法远程主机输入命令：ss-tunp|grep<port>请将<port>替换为项目现场真实的端口，默认为5672，然后将输出的列表发给项目开发进一步排查redis服务已连接>=32768redisconn1、查看是否有连接泄露，具体做法远程主机输入命令：ss-tunp|grep<port>请将<port>替换为项目现场真实的端口，默认为6379，然后将输出的列表发给项目开发进一步排查redis服务连接使用率>=80redisconn1、查看是否有连接泄露，具体做法远程主机输入命令：ss-tunp|grep<port>请将<port>替换为项目现场真实的端口，默认为6379，然后将输出的列表发给项目开发进一步排查redis服务状态!=1redisstate1、远程所在主机查看服务运行状态

2、使用对应工具检测连接是否正常tomcat服务内存使用率>=90tomcatmem1、通过查看tomcat日志是否有异常提示，或发送给开发进行排查tomcat服务状态!=1tomcatstate1、通过查看所在容器状态是否正常

2、通过远程容器查看tomcat进程是否正常

3、通过查看tomcat日志是否有异常提示，或发送给开发进行排查redis的AOF文件大小aof1、清理无用数据或进行扩容平台通过发送内部消息提醒、记录告警详细日志的方式在平台内部进行告警通知。同时，平台可以对接短信平台或邮箱，提供发送短信或邮件告警服务。告警阈值及告警处理方式，详见下表。日常问题及BUG处理系统出现的问题在响应后2个工作日内给出问题处理时间不影响系统正常使用的bug问题24小时内给出解决方案，3个工作日内解决影响系统正常使用的bug问题2小时内恢复，2个工作日内找出问题原因并给出问题解决时间严重影响系统正常使用的bug问题1小时内恢复，1个工作日内给出问题原因并给出问题解决时间对于7个工作日内无法解决bug问题告知最晚完成时间并在规定时间内完成信息资源调研支持在客户提出配合全市部门公司政务信息资源调研工作时，提供人员、交通、现场等支持。包括数据标准、政务资源目录、上下游应用、以及其他有关本平台的新增业务需求等调研工作。需求变更收集和反馈处理新增或变更需求3个工作日内给出解决方案新增或变更需求给出任务完成时间，并在规定时间内完成任务平台小版本升级提供信息系统软件的补丁升级，补丁升级包括对甲方已有的软件功能的提升、缺陷的修正，根据甲方的需要对软件进行个别的、小规模的修改。共享交换前置区维护专人负责共享开放平台前置区的数据库、交换节点日常巡检维护，保证前置交换节点服务的正常运行，确保数据交换服务的正常运行。配合客户方维护人员处理数据交换前置区的各种故障，包括网络故障、系统故障、数据库故障、安全故障等。在运维服务期间每周至少检查一次前置区的服务器硬件性能及数据交换服务的运行情况。资源监控与容量评估实时监控物理资源监控物理资源监控实现对共享开放平台物理资源运行状态的监控。保障共享开放平台物理资源的稳定运行和高效使用。提供基于主机的硬件和系统的运行监控，包括主机的cpu、内存、磁盘、网络等运行状态的监控。提供基于网络的监控，包括交换机、路由器等网络设备运行状态的监控。提供数据库运行状态的监控，包括数据库内存、数据库表空间、数据文件或数据设备的读写次数、数据库碎片、数据库锁、数据库用户占用资源等情况，对数据库系统进行实时监控，从而确保系统以高性能持续运行具有重要的价值。提供对共享开放平台分布式计算集群中间件、消息中间件、应用服务器等运行状态的监控。逻辑资源监控逻辑资源监控对整个共享开放平台下运行的所有逻辑资源的运行状态进行监控，通过对逻辑资源的监控，可以保障共享开放平台逻辑资源的高效率使用和稳定运行。逻辑资源监控包括如下方面：提供系统进程和应用进程运行状态的监控。提供集群整体运行状态监控，包括进程状态、访问状态等；同时提供对集群节点CPU利用率、内存利用率、网卡、硬盘存储状态的运行监控，帮助管理员尽早发现节点潜在的故障，对集群管理起着辅助作用。应用资源监控应用资源监控提供共享开放平台所有应用资源运行状态的监控。通过对应用资源的监控，可以保障共享开放平台应用资源的稳定运行和高效使用。应用资源监控包括如下方面：提供对共享开放平台进行各种操作状态的监控，以获得更好的负载平衡，并根据全局资源状况进行统一调度。从多租户角度可以监控每个作业设置运行时间点、任务数、资源配额使用情况（CPU、内存等）、网络流量、运行周期、运行服务器等调度状态。提供对多租户资源池使用状况的监控。提供对作业、任务运行所耗费的系统资源进行监控，包括CPU、内存、存储和网络等告警提醒通过告警提醒能够实现对共享开放平台运行异常状况的及时处理，保障共享开放平台运行的稳定性。告警提醒为共享开放平台提供告警生成、告警自动处理等灵活的策略配制功能。根据平台的物理资源、逻辑资源、应用资源的运行状态生成告警数据，并通过短信或邮件方式通知各相关干系人进行处理。前台告警前台告警功能对共享开放平台运行中发生的各项告警进行统一前台视图管理。通过告警、提醒等方式，支撑运维人员快速获取告警详细信息并开展后续告警处理工作。前台告警对共享开放平台运行中所产生的告警进行前台的告警流程处理，并允许配置告警触发项和处理人员（如开发人员、系统负责人员等）。统计分析统计分析提供按周期对共享开放平台的物理资源、逻辑资源、应用资源的使用情况以及对作业运行状态的综合分析。统计分析包含系统性能分析、作业异常分析和资源计量分析。依据分析结果，形成对共享开放平台资源使用情况的定量、直观的认识，为后续平台资源的合理使用及优化提供保障。系统性能分析系统性能分析是对共享开放平台的资源（物理资源、逻辑资源、应用资源等）运行状况提供的分析。共享开放平台的系统性能分析提供面向作业、任务、多租户的系统监控信息的性能分析，并针对CPU、内存、网络和磁盘等维度提供相关性能的分析。系统性能分析为共享开放平台系统性能的正常发挥提供重要的参考。运营维护子系统对共享开放平台的系统性能分析提供日报、周报等统计分析，为运维人员对共享开放平台的维护提供参考。作业异常分析作业异常分析是对共享开放平台上运行的作业状态的监控信息提供的分析。共享开放平台的作业异常分析提供面向作业、任务、多租户的作业异常原因定位，需要提供作业执行的详细日志，具备完善的日志汇总和采集能力的集成，以便于排查作业问题，并提供日常的解决方案建议,为共享开放平台上的作业正常运行提供重要的参考。优化分析共享开放平台的监控优化分析是对其监控结果进行的分析总结。通过对共享开放平台的物理资源、逻辑资源、应用资源和业务层面的作业状态的监控结果进行的汇总、分析，运维管理人员可以优化共享开放平台中的资源运行状况的阈值或者模型。优化分析的输出结果为共享开放平台的稳定运行及共享开放平台资源的合理利用提供重要参考。共享开放平台运营维护子系统提供优化分析日报、周报等，为运维人员对共享开放平台的维护提供参考。业务上线支持每日安排人员对各部门业务人员进行系统使用支撑，对于部门进行目录编制和数据归集上的问题进行支撑，保障目录注册、数据归集和数据治理。每日安排人员对各部门的资源共享需求进行支撑，包含资源的申请、订阅，以及前置库的管理，保障整个平台的资源共享通畅。对于各公司咨询数据交换、平台使用、方案建议积极给予详细解答。资源目录动态维护完善政务资源目录的线上系统，保持实际入库信息情况与在线目录展示情况同步调整、部门共享需求的在线申请、受理、审批等功能正常使用。主要工作如下：部门目录发布持续推进；部门资源挂载持续推进；前置库到中心库数据交换配置；国家、省、市、部门接口二次封装处理；上级数据归集追踪，归集问题协调处理；重要目录数据归集追踪，必要时设置短信预警；部门数据应用总结；部门需求协助、共享协助；资源共享问题排查。数据维护服务对委办局提供到中心的原有、新增数据进行管理，进行数据符合性校验，并推动数据质量问题解决。定期进行数据备份，并对备份数据定期检查。防止各种形式的数据泄露。采集数据建模入库服务公司新增数据资源在公司提供数据的情况下，7个工作日内完成数据资源建模公司新增数据资源在数据建模完成后，7个工作日内完成数据入库数据处理（清洗、比对、转换）服务对于入库数据给出合理的数据处理方案数据处理方案确定后，7个工作日内完成数据处理方案的配置数据交换运维服务公司数据调研服务公司新增数据资源在7个工作日内安排人员调研并形成调研报告。公司数据目录梳理服务公司新增数据资源在调研并形成调研报告后3个工作日内对数据资源及数据资源元数据编目入库。公司的数据采集方案支持服务公司新增数据资源如果需要采集方案支持的在7个工作日内给出合理的数据采集方案。公司新增数据资源在采集方案确定后，积极催促各公司提供数据（一周上门一次，3个工作内打一次电话）并每周向电政办汇报各公司数据提供情况。公司的数据采集服务公司新增数据资源在公司提供数据的情况下，7个工作日内完成交换任务搭建并开始采集数据。数据共享运维服务数据中心数据根据需求提供数据接口服务对于数据中心提出的某一数据资源目录提供接口服务，7个工作日完成接口配置工作。公司数据需求提共享库数据服务对于公司在共享平台提出的数据申请，在7个工作日内完成共享库共享工作。技术交流定期技术交流为了更好的了解客户的技术需求，同时也是我们与客户互相学习、共同提高的机会，我们将不定期的进行技术交流。形式可以是座谈，也可以是讲座和培训。交流内容包括但不仅限于以下：数据管理方面：数据收集、数据传输、数据存储、数据仓库、数据查询、数据血缘、数据安全、数据计算、实时计算。数据应用方面：用户画像、增长黑客、图谱挖掘、机器学习、物联网、人工智能。技能传递服务对于系统使用公司给予细致的培训。培训会议积极配合、会后对参会公司进行指导并给出用户操作手册。重大活动运维服务对于市召开的各种有关平台的会议、展示、宣传和其他活动给予积极的配合，在活动期间根据需要提供足够的人员现场保障。数据备份常规备份备份策略备份内容备份内容，主要分为以下4类：1.PaaS平台、共享开放平台数据库；2.共享交换平台前置数据库；3.非结构化数据；4.应用系统流水线（即应用子系统部署包）。备份工具主要使用到的备份工具如下：1.数据库备份工具此次项目中，共享交换平台和事项管理系统均使用MySQL数据。针对Linux服务器上的MySQL数据库，我们采用Percona公司出品的Xtrabackup进行备份和还原，该工具在大多数的互联网公司均有采用，例如网易、腾讯、阿里等，尤其阿里云的RDS上，采用Xtrabackup进行RDS的备份和还原，上百G的数据可以在几分钟内还原完成。2.异机备份工具针对Linux服务器上的异机备份操作，我们采用开源的rsync进行异机备份。定时将每天通过Xtrabackup新增的数据库备份文件以及通过NFS传输存储的非结构化数据，通过差异备份方式备份到异机备份服务器上Linux服务器上的NFS文件服务器，我们采用开源的rsync进行异机备份。定时将每天新增的非结构化数据，通过差异备份方式备份到异机备份服务器上。备份策略结构化数据备份策略图示1.每周日晚上22点，数据库开始进行全量备份；2.每周一到周六的晚上22点，数据库进行一次增量备份。脚本安装后，即使当日非周日，脚本在第一次执行时也会进行判断并进行一次全量备份。备份实施结构化数据备份实施脚本说明：1.如果是mysqlmha，则将脚本文件拷贝到主节点服务器，通过crontab运行该脚本即可。2.如果是mysql单节点，则将脚本文件拷贝到单节点服务器上，通过crontab运行该脚本即可。结构化数据备份实施步骤备份对象备份位置备份对象位置备份步骤PaaS平台数据库本地磁盘共享开放平台业务数据库MHA本地磁盘交换节点数据库MHA本地磁盘部门前置数据库MHA本地磁盘异机备份实施脚本安装在异机备份服务器（rsync服务端配置）1.安装rsync包：2.编辑rsyncd.conf配置文件3.参数解释：4.创建rsync账号及共享目录：5.创建rsync虚拟账号及密码（可自行修改）：6.启动rsync服务：7.写入到开机自启动脚本中：结构化数据异机备份实施步骤备份对象备份位置备份对象位置备份方式备份步骤PaaS平台数据库共享磁盘增量共享开放平台业务数据库MHA共享磁盘增量交换节点数据库MHA共享磁盘增量部门前置数据库MHA共享磁盘增量非结构化数据异机备份实施步骤备份对象备份位置备份对象位置备份方式备份步骤非结构化数据共享磁盘增量应用系统部署包异机备份实施步骤备份对象备份位置备份对象位置备份方式备份步骤应用系统部署包共享磁盘增量备份文件验证结构化数据备份文件检查将备份脚本加入到计划任务后，需要定期去检查备份情况，以免造成数据丢失。检查备份是否正常的方法非常简单，首先去对应WEEK_X的目录下看是否缺失备份目录，例如上周的备份应该会存在FULL、INCR_1~INCR_6一共7个目录，分别对应一天的全量备份和6天的增量备份，然后去查WEEK_X目录下的backup.log的日志，该日志记录了备份情况，通过执行tail–fbackup.log命令，查看备份日志的最后几行，如果显示completedOK!则代表备份是正常的。结构化数据、非结构化数据、应用系统部署包异机备份文件检查异机备份主要使用rsync工具。rsync自带两种验证方式，当进行同步数据时，数据会分别通过MD5和HASH去验证，这就能保证数据一致。可以用这个特点保证数据一致，也就是完整性。另外可以通过查看日志中是否有错误信息来判断同步是否出现问题，执行tail–f/var/log/rsyncd.log，来查看日志中是否有error信息。恢复实施结构化数据恢复实施脚本说明：1.如果是mysqlmha，则将脚本文件拷贝到主节点服务器，然后再执行该脚本即可。2.如果是mysql单节点，则将脚本文件拷贝到单节点服务器上，然后再执行该脚本即可。结构化数据恢复实施步骤关于数据库的还原需牢记一个原则：不能够在一个正在运行的（线上环境）MySQL数据库上进行还原，需要先停止MySQL，然后将数据根目录中的内容删除，确保成为一个空库，在执行恢复脚本。同时在脚本执行的过程中也会检测数据文件夹是否为空，如果不为空，则会退出恢复过程并给出错误提示。备份对象备份位置备份对象位置恢复步骤PaaS平台数据库本地磁盘共享开放平台业务数据库MHA本地磁盘交换节点数据库MHA本地磁盘部门前置数据库MHA本地磁盘非结构化数据、应用系统部署包恢复实施步骤关于非结构化数据和应用系统部署包的恢复有多种方式，在这里列举几种方式：1.可以在异机备份服务器上手工拷贝所需文件到目标服务器；2.在异机备份服务器上执行scp命令进行文件传输；3.利用rsync工具，将目标服务器作为rsync服务端，将异机备份服务器作为客户端。存储空间估算本地备份存储空间估算说明：本次估算以当前正式环境运行所产生的数据量和增长量进行存储空间估算。备份对象备份位置备份方式数据量（GB）全备周期（天）差备周期（天）保留时间（天）单次全备生成数据量（GB）单次增备生成数据量（GB）数据库大小（GB）五年后备份文件大小（GB）五年后存储需求（GB）五年期PaaS平台数据库本地磁盘全量32G7308M100G1G110G共享开放平台业务数据库MHA本地磁盘增量、全量133GB713520G3G250G800G1.2T交换节点数据库MHA本地磁盘增量、全量17GB713544M3M140G420G600G部门前置数据库MHA本地磁盘增量、全量887GB717102G11G1.5T1T2.5T非结构化数据共享磁盘增量93G1永久200G200G应用系统部署包共享磁盘增量15G1永久16G20G异机备份存储空间估算规划1台异机备份服务器对共享交换平台相关数据进行异机备份。规划7T（规划5年）存储空间用于共享交换平台异机备份。容灾备份相关概念说明灾难：由于人为或自然的原因，造成信息系统严重故障或瘫痪，使信息系统支持的业务功能停顿或服务水平不可接受、达到特定的时间的突发性事件。灾难恢复：为了将信息系统从灾难造成的故障或瘫痪状态恢复到可正常运行状态、并将其支持的与功能从灾难造成的不正常状态恢复到可接受状态，而设计的活动和流程。灾难备份中心：用于灾难发生后接替主系统进行数据处理和支持关键业务功能运作的场所。恢复时间目标RTO(RecoveryTimeObjective)：灾难发生后，信息系统或业务功能从停顿到必须恢复的时间要求。恢复点目标RPO(RecoveryPointObjective)：灾难发生后，系统和数据必须恢复到的时间点要求。应用系统容灾目标目的就是通过建设独立的灾备中心，引入数据备份、实时同步等技术，尽可能的降低灾难性故障导致的系统瘫痪时间和损失。详细的目标要求：建立完备的备用基础设施：有符合介质存放的备用场地有符合备用数据处理系统和备用网络设备运行要求的场地有满足关键业务功能恢复运作要求的场地以上场地保持7*24小时运作数据备份要求：完全数据每天备份一次备份介质场外存放数据实时复制备用数据处理系统：备用与生产的处理能力一致并完全兼容所有备用设备达到就绪（待命）状态，具备快速替代生产环境的能力备用网络系统：与生产系统相同等级备用网络处于运行状态可同时接入主、备中心灾备恢复预案：经过完整测试和演练应用系统容灾需求分析灾难恢复指标要求按照国家平台统一标准指标要求，系统恢复时间目标RTO为30分钟，恢复点目标RPO约等于零（尽可能无数据损失）。容灾建设范围mysql数据库（需要）已明确由第三方提供实时数据同步方案，本建设方案无需考虑。reids缓存服务（暂不需要）redis中虽然存储了数据，但是这些都是数据库数据的复制或者用户会话生成的临时数据，无需持久化，自然也无需考虑备份。当灾备中心切换后，备用的redis集群会在应用系统启动后重新灌入数据。nas存储（暂不需要）暂时考虑由平台方面提供存储同步方案，本建设方案无需考虑Java程序、nginx等这些程序组件本身不是数据，但其配置信息、程序文件也需要考虑容灾备份。双中心数据同步带宽需求测算在容灾需求中，所有主机房做的数据变更操作都要实时的同步到灾备机房，写入数据的同时就会损耗双中心间的网络带宽，做数据传输和同步。所以，瞬时写入数据量的最大值，就是对双中心间网络带宽的需求值。在共享开放平台，数据写入量最大的是数据的汇聚过程，数据量测算：经过统计，每日增量为1199145条，每条按照100KB估算，总大小为117104MB，加上索引数据，总量为原数据的两倍，即234208MB。根据总体流程，数据需在2个小时之内完成入库，故对存储I/O速率需求为：234208MB/2/3600=32.5MB/S，考虑10%左右的预留，最终需求为36MB/S。整个汇聚过程中，数据会录入数据库，2个数据库都需要做数据同步，数据写入量需要乘以3倍，则为36MB/S*3=108MB/S，按此则同步数据量也为108MB/s，换算为带宽则为108*8=864Mbps。额外考虑在数据汇聚时，并发有少量数据写入操作，推荐的带宽量为千兆带宽。技术风险与挑战分析应用系统使用了多达上百台服务器、每个服务器内都有1个或多个应用程序，每个应用程序下又会有成百上千的程序文件。应用程序的容灾的传统做法都可能存在不同程度的缺陷：通过人工方式，在灾备中心按同样的配置架构，部署与生产环境相同的系统。存在的问题：服务器、应用系统数量过多，程序的物理拷贝如有遗漏或一旦出现不同步，就会造成主备环境的不一致，可能造成不可知的问题即使确保备用环境先期一致，随着程序的维护，通过人工方式的迭代更新，难免出现主备环境开始不同步的问题而一旦出现不同步问题，又无有效手段快速比较出差异。为每个服务器各自配置文件系统备份同步，解决主备程序文件不一致，但还是会存在如下问题：服务器数量过多，同步配置本身也可能会错误或遗漏。只能单纯的同步文件，无法同步程序的启停状态。例如用户更新一个配置后需要生效可能要重启系统，这个人工操作很难保证每次都在主备系统中同步做了。往往不能确认，当前主、备系统内各自运行的是否是相同的程序版本。基于上述问题，应提供一个集应用程序文件管理、程序版本管理、配置部署、服务启停的在线平台，才能妥善的解决大型复杂应用下应用程序的同步问题。MySQL数据库容灾实现方案MySQL数据实时同步技术原理MySQLReplication是MySQL非常出色的一个功能，该功能将一个MySQL实例中的数据复制到另一个MySQL实例中。整个过程是异步进行的，但由于其高效的性能设计，复制的延时非常小。MySQL复制功能在实际的应用场景中被广泛的应用于保证数据系统数据的安全性和可扩展设计中。MySQLReplication复制架构：MySQLReplication复制过程：Slave服务器上执行startslave，开启主从复制开关。此时，Slave服务器上的IO线程会通过Master服务器上授权的有复制权限的用户请求连接Master服务器，并请求从指定binlog日志文件的指定位置之后发送binlog日志内容。（日志文件名和位置就是在配置主从复制任务时执行changemaster命令时指定的）Master服务器接收到来自Slave服务器的IO线程的请求后，Master服务器上的IO线程根据Slave服务器的IO线程请求的信息，读取指定binlog日志文件指定位置之后的binlog日志信息，然后返回给Slave端的IO线程。返回的信息中除了binlog日志内容外，还有本次返回日志内容后在Master服务器端的新的binlog文件名以及在binlog中的下一个指定更新位置。当Slave服务器的IO线程获取来自Master服务器上IO线程发送的日志内容及日志文件和位置点后，将binlog日志内容依次写入到Slave端自身的relaylog（即中继日志）文件（mysql-relay-bin.xxxxxx）的最末端，并将新的binlog文件名和位置记录到master-info文件中，以便下一次读取Master端新binlog日志时，能告诉Master服务器需要从新binlog日志的哪个文件哪个位置开始请求新的binlog日志内容。Slave服务器端的SQL线程会实时检测本地relaylog中新增加的日志内容，然后及时的把relaylog文件中的内容解析成在Master端曾经执行的SQL语句的内容，并在自身Slave服务器上按语句的顺序执行应用这些SQL语句，应用完毕后清理应用过的日志。经过了上面的过程，就可以确保在Master端和Slave端执行了同样的SQL语句。当复制状态正常的情况下，Master端和Slave端的数据是完全一样的。MySQL容灾部署架构MySQL的部署架构如图：架构说明：现有单机房中，为了保证MySQL的高可用，使用了MySQLMHA集群方案，通过搭建1主（MySQLMaster）1从（MySQLSlave）和一个管理节点（MySQLManage）来实现。当主节点出现故障时，管理节点会检测到并把数据库连接自动转移到从节点之上。在双中心的架构方案下，需要在灾备机房中，与主