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

大数据系统平台项目售后服务及运营方案 1一、方案编制目的及原则 61.1、方案制定原则 6二、组织体系 62.1、项目运维工作小组 62.2、项目运维工作小组人员清单 72.3、现场应急处理工作组 72.4、运维质量分 72.4.1、运维服务质量指标 82.4.1、运维服务满意度指标 9三、标准化运维流程 3.1、服务标准 3.1.1、服务工作时间 3.1.2、响应时间 3.1.3、故障恢复时间 3.1.4、保密条款 3.2、需求管理流程 3.3、变更处理流程 3.4、主动运维服务 1、服务报告 2、系统性能排查 3、软件监控 4、项目风险识别 5、客户回访 四、运维及驻场服务内容 4.1、健康检查 4.1.1、检查列表 4.1.2、操作系统检查 4.1.3、数据库检查 4.1.4、中间件服务检查 4.1.5、大数据相关检查 204.2、深度巡检服务 204.2.1、平台资源配置 204.2.2、自动告警 4.3、日常问题及BUG处理 284.4、信息资源调研支持 294.5、需求变更收集和反馈处理 294.6、平台小版本升级 294.7、共享交换前置区维护 294.8、资源监控与容量评估 294.8.1、实时监控 4.8.2、告警提醒 304.8.3、统计分析 4.8.4、优化分析 4.9、业务上线支持 4.10、资源目录动态维护 4.11、数据维护服务 4.11.1、采集数据建模入库服务 4.11.2、数据处理(清洗、比对、转换)服务 4.12、数据交换运维服务 4.12.1、公司数据调研服务 4.12.2、公司数据目录梳理服务 334.12.3、公司的数据采集方案支持服务 4.12.4、公司的数据采集服务 4.13、数据共享运维服务 4.13.1、数据中心数据根据需求提供数据接口服务 334.13.2、公司数据需求提共享库数据服务 334.14、技术交流 4.15、技能传递服务 4.16、重大活动运维服务 345.1、常规备份 5.1.1、备份策略 345.1.2、备份实施 5.1.3、备份文件验证 375.1.4、恢复实施 5.1.5、存储空间估算 385.2、容灾备份 5.2.1、相关概念说明 5.2.2、应用系统容灾目标 405.2.3、应用系统容灾需求分析 415.2.4、MySQL数据库容灾实现方案 435.2.5、应用程序容灾实现方案 5.2.6、应用系统灾备恢复预案 485.2.7、容灾建设资源需求清单 49六、安全密钥处置管理 6.1、管理机制简述与建议 49(一)工程阶段 49(二)后续建议 496.2、业务系统访问账号管理 496.3、服务器访问账号管理 6.4、数据库访问账号管理 6.5、账号变更及密钥变更管理 7.1、专家保障 7.2、电话咨询 7.3、远程协助 7.4、现场响应 8.2、故障级别 8.3、故障处理流程 8.3.1、处理故障需注意以下事项 8.3.2、故障为以下问题的处理流程 9.1、现场应急处理 9.2、系统应急保障 9.2.1、机房故障 9.2.4、主备倒换故障 9.2.5、安全攻击 9.2.6、系统卡顿 9.2.7、平台无法登录 9.2.8、附件无法上传下载 9.3、数据应急保障 9.3.1、误删数据 9.3.2、库表资源异常 9.3.3、部门数据交换异常 9.4、网络应急保障 9.4.1、网络故障 9.5、报告与总结 十、护航保障措施 10.1、本地化服务 10.2、组织及人员保障 10.4、数据保障 10.5、安全条款 10.6、宣传、培训和演习 10.7、定期巡检 10.8、服务监督 十一、服务报告 11.5、运维例会 十三、运维涉及表单 13.1、客户需求确认单 13.2、客户需求评估单 13.3、需求变更申请单 13.4、需求变更实施单 13.5、客户需求结案单 13.6、故障分析报告 13.7、现场维护确认单 13.8、服务器巡检报告 7313.9、培训签到表 13.10、季度/年度维护服务总结报告 13.11、客户拜访单 73一、方案编制目的及原则服务组织，服务组织管理和流程管理是项目成功得关键。我们将理)的统一调度下，指挥技术、应用、商务及服务监督人员，在售前、服务实施、售后的服务的级别意味着客户的成本，我们在保障高标准二、组织体系成立项目运维工作小组，团队成员不少于10人。根据项目特点决定驻场人员个数，驻场人员不少于4人，负责驻系统的管理和运维，运维人员提供工作日5*8小时的现场驻无共享开发平台软件运维质量分由服务质量和服务满意度两部分构成，分别占有总分的90%和10%,总分100分。服务质量以默认100分为基准，当出现一项不满足项进行扣分，客户满意度以默认100分为基准，当出现一项不满足项进行扣总体得分=(服务质量得分/100)×90+(客户满意度得分/100)×10。对应实际评估值区间二星★★一星★注：X为按照本方法进行评估而获取的评估分数包括应用系统运维服务、数据运维服务、安全管理服务、故障应7个内容：共享开放平台功能维护、数据运维、数据入库与制定、应急预案建立及使用机制、技术支持人员、故障扣分原则否(次)(20分)台功能维护(20分)项目组是否每日检查系统运行情况、数据库运行情况并每年反映项目运维情况?是，不扣分；否，每次扣除1分(10分)协助进行数据调研工作，完善政务资源目录；在相关平台系适应业务需求时，运维方应及时安排技术人员进行软件功能值10分，未完成一次扣2分。(10分)建立数据质量和安全的防护机制。分值10分。数据质量问扣1分。按周期备份数据，每少1次或备份数据不全扣1分。发生数据泄数据入库与出库(20分)各委办局提交数据后，接口数据和数据库同步要求实时入1个工作日内完成数据入库。各委办局数据共享审批完成后，要在2个工作日内完成数据出库的相应工作。分值20分。未按时完成一次扣1分。理及数据标准制定(10建立信息安全保障和业务流程体系，与数据处理专职团队及人员签订保密协议；故障应急建立应急预案，并在遇到紧急事件时使用应急预案。分值1制(10分)案扣10分，遇紧急情况未使用应急预案一次扣2分。员(10分)技术支持总人数应不少于4人，并应在半小时内响应。分值1内响应1次扣2分。复机制(20应保障共享开发平台运行平稳，如出现故障应及时修复，分值10分。每出现1次影响委办局正常使用的故障，扣1分，在1小时出现1次影响项目正常使用的故障，扣5分，在半小时内未修复的，再扣2分；出现重大故障，在1天内未修复或被资源使用方书面投诉并确认的，1次扣10运维人员的服务态度和服务意识的满意度(10分)运维人员对事件及处理问题的响应速度(10分)运维人员对系统问题诊断及处理结果满意度(10分)运维人员专业水平满意度(10分)运维人员服务管理规范性的满意度(10分)系统满意度系统稳定性满意度(10分)系统运行速度满意度(10分)系统操作方便性(10)数据处理质量满意度(10)数据服务质量满意度(10)三、标准化运维流程项目最终验收前提供对系统提供维护服务，对已经上线运行自验收之日起提供不低于1年的现场支持服务。7*24*365电话、网站、电子邮件等方现场服务时间为5*8小时，其余时间接到报修后30分钟内予以实质性响应，工程师1一般性故障在2小时内做出故障诊断和恢复，复杂故障在4小时内恢复。据信息(无论是打印或介质上的数据信息)不得带离客户工作现场。在维护工作前，本公司工程师须提前24小时(紧急故障处理除外)向客户项目主管提◆每周有5个及以上维护事项需整理周报发送给客户；◆每月有5个及以上维护事项需整理月报发送给客户；◆每季有3个及以上维护事项需整理季报发送给客户；(1)维护人员在做服务器巡检时需检查数据库中语句的执行情况，项目的巡检(2)sql通过sqlProfiler进行跟踪处理。(3)对刷选出执行时长超过3秒的语句，通过增加索性等方式先自行处理，若(1)每半月提醒人员发出邮件提醒各部门对维护事项进行风险排查。(2)部门安排维护人员在2工作内把处理中维护事项和风险点进行反馈。(3)汇总人员汇总部门内维护人员反馈列表。(4)部门经理了解事项的风险点，通过提供建议、沟通协调、逐级上报等方式(1)部门安排采集重点和普通项目列表。(2)部门经理和组长对项目列表进行审核，对重点项目安排好去现场的人员和(3)针对现场拜访的项目：(3.1)维护负责人登记“拜访”类维护事项，跟组长或部门经理一起去现场(3.2)现场拜访需登记现场签单，完成后拍照上传至对应事项。(3.3)整理现场拜访采集到的问题，发出相关事项跟进处理。若有新增需求四、运维及驻场服务内容序号型态12服务器时间设置同步开启3查看系统时间是否正常(特别是内网服务器，无法同步时间的情况)45检查监听端口，查看是否有非公司业务端口678检查passwd文件，查看是否有可疑用户9sudoer中是否有可疑用户root密码策略是否包含字母大小写、数字、特殊字符和人工二.数据库相关限制MySQL.的访问IP来源，只允许业务服务器才能通过网络连接修改MySQL.的默认端口检查mysql用户的权限，仅对mysql的dat检查mysql用户的权限，不能以普通用户检查MySQL的root账号是否可以被远程访问，除了MHAManager服务器必要人工必要人工确保业务程序的数据库连接使用普通用户权限人工确保业务程序使用的用户权限仅在业务自己的数据库，而不必要人工确保mysql的root密码策略是否包含字母大小写、数字、特殊字必要必要人工人工必要人工隐藏Tomcat和访问404页面时的版本信息必要人工删除Tomcat目录下，docs、examp检查JVM是否使用server参数启动必要人工人工不可以使用多个虚拟主机部署应用必要人工关闭war包自动部署的功能必要以非root用户启动应用禁止nobody对所有目录的读取权限，对网站四.大数据相关业务系统高可用系统最大并发连接限制②查看系统时间是否正常(特别是内网服务器，无法同步时间的情况)⑦sudoer中是否有可疑用户⑧root密码策略是否包含字母大小写、数字、特殊字符和长度大于8位⑤检查mysql用户的权限，不能以普通用户的方式登录系统⑦检查/etc/f中是否包含密码11确保业务程序的数据库连接使用普通用户权限，而非root12确保业务程序使用的用户权限仅在业务自己的数据库，13确保mysql的root密码策略是否包含字母大小写、数字、特殊字符和长度大于8位于8位②隐藏Tomcat和访问404页面时的版本信息⑦关闭war包自动部署的功能⑨禁用不安全的http方法④限制访问nginx下的txt文件或则1og文件①使用HTTPS加密协议传输②检查业务系统JDBC连接数据库是否传输加密4.2、深度巡检服务结合用户指定的监控协议发送心跳包，检测被监控应用是否存活，例如如则平台会向指定地址发送一个HTTP请求，如果返回200或者302则代表该应用是存活的。在概览视图中我们可以快速的查看到平台为使用者准备的几个较为重要的值，以最常用的Tomcat为例，使用者可以快速的查看到，当前Tomcat容器每秒的请求并发数，已经当前工作线程数量，和JVM内存使用。在概览视图中这些数据默认为当前最新的值，点击最右侧会根据服务器的CPU自动适配响应的进程数，如上图所示，使用在详细监控视图中还可以获取到Nginx组件网络流供的redis镜像默认配置10000个连接在容器概览中可以查看到当前容器的状态，以及使用的CPU和内存情况，这确的是，如果没有限制CPU和内存量，则列表中显示的使用率都是相对于主机的资源，例如，内存使用50%,则表示，当前容器使用的内存占整个主机的50%。容器网络的使用量：提供该容器网卡的接收速率内容(此操作不会清除日志)中文名称号值处理类别应用访问时间1、通过查看应用日志是否有内存使用率是否过高及数据库的资源使用率是否11、通过查看tomcat服务本身11、通过查看容器所在主机本身是否运行否正常1、通过查看应用日志是否有1、通过查看应用日志是否有主机磁盘空闲51、按实施巡检规范处理，清1、通过查看主机内所有容器利用率情况，然后查看利用率高的容器中应用日志是否1、通过查看主机内所有容器利用率情况，然后查看利用率高的容器中应用日志是否11、检查主机网络是否联通2、检查主机开机状态，联系机房管理员云平台控制查看主机根分区空闲11、按实施巡检规范处理，清1b1、远程所在主机查看服务运否正常数b1、查看是否有连接泄露，具体做法远程主机输入命令：ss<por>替换为项目现场真实的端口，默认为27017,然后将输出的列表发给项目开mongodb数据库连接使用率b1、查看是否有连接泄露，具体做法远程主机输入命令：ss<port>替换为项目现场真实的端口，默认为27017,然后将输出的列表发给项目开1、查看是否有连接泄露，具<port>请将<port>替换为为1433,然后将输出的列表11、远程所在主机查看服务运否正常1、查看是否有连接泄露，具<por>请将<port>替换为为1433,然后将输出的列表1、查看是否有连接泄露，具<port>请将<port>替换为为1433,然后将输出的列表1、查看是否有连接泄露，具体做法远程主机输入命令：ss<port>替换为项目现场真实的端口，默认为3306,然后11、远程所在主机查看服务运否正常1、查看是否有连接泄露，具体做法远程主机输入命令：ss<port>替换为项目现场真实的端口，默认为3306,然后1、查看是否有连接泄露，具体做法远程主机输入命令：ss些ip连接，然后进行进一步分析11、通过查看所在容器状态是否正常3、通过查看nginx日志是否有异常提示，或发送给开发1、查看是否有连接泄露，具真实的端口，默认为1521,然后将输出的列表发给项目e1、清理无用数据或进行扩容11、远程所在主机查看服务运否正常1、查看是否有连接泄露，具真实的端口，默认为1521然后将输出的列表发给项目1、查看是否有连接泄露，具真实的端口，默认为1521,然后将输出的列表发给项目11、通过查看所在容器状态是否正常否有异常提示，或发送给开1、查看是否有连接泄露，具<por>替换为项目现场真实的端口，默认为5672,然后将输出的列表发给项目开发21、通过监控页面查看消息数量1、查看是否有连接泄露，具体做法远程主机输入命令：ss<port>替换为项目现场真实的端口，默认为5672,然后1、查看是否有连接泄露，具<por>替换为项目现场真实的端口，默认为6379,然后1、查看是否有连接泄露，具体做法远程主机输入命令：ss<port>替换为项目现场真实的端口，默认为6379,然后将输出的列表发给项目开发11、远程所在主机查看服务运否正常1、通过查看tomcat日志是否tomcat服务状态11、通过查看所在容器状态是否正常2、通过远程容器查看tomcat3、通过查看tomcat日志是否redis的AOF文件大小1、清理无用数据或进行扩容●系统出现的问题在响应后2个工作日内给出问题处理时间●不影响系统正常使用的bug问题24小时内给出解决方案，3个工作日内解决●影响系统正常使用的bug问题2小时内恢复，2个工作日内找出问题原因并给出问题解决时间●严重影响系统正常使用的bug问题1小时内恢复，1个工作日内给出问题原因并给出问●对于7个工作日内无法解决bug问题告知最晚完成时间并在规定时间内完成●新增或变更需求3个工作日内给出解决方案●新增或变更需求给出任务完成时间，并在规物理资源监控实现对共享开放平台物理资源运行状态的监控。保提供数据库运行状态的监控，包括数据库内存、数据库表空间提供对共享开放平台分布式计算集群中间件、消息中间件、应逻辑资源监控对整个共享开放平台下运行的所有逻辑资源的运行(CPU、内存等)、网络流量、运行周期、运行服务器等调度状态。通过告警提醒能够实现对共享开放平台运行异常状况的及时处理告警提醒为共享开放平台提供告警生成、告警自动告警触发项和处理人员(如开发人员、系统负责人员等)。统计分析提供按周期对共享开放平台的物理资源、析。依据分析结果，形成对共享开放平台资源使用情况的定量、系统性能分析是对共享开放平台的资源(物理资源、逻辑资源、应用资源等)运行状行的详细日志，具备完善的日志汇总和采集能力的集成，以共享开放平台的监控优化分析是对其监控结果进行的分析总结。结果为共享开放平台的稳定运行及共享开放平台资源的●公司新增数据资源在公司提供数据的情况下，7个工作日内完成数据资源建模●公司新增数据资源在数据建模完成后，7个工作日内完成数据入库●对于入库数据给出合理的数据处理方案●数据处理方案确定后，7个工作日内完成数据处理方案的配置公司新增数据资源在7个工作日内安排人员调研并形成调研报告。公司新增数据资源在调研并形成调研报告后3个工作日内对数据资源及数据资源元数公司新增数据资源如果需要采集方案支持的在7个工作日内给出合理的数据采集方案。公司新增数据资源在采集方案确定后，积极催促各公司提供数据(一周上门一次，3个工作内打一次电话)并每周向电政办汇报各公司数据提供情况。公司新增数据资源在公司提供数据的情况下，7个对于数据中心提出的某一数据资源目录提供接口服务，7个工作日完成接口配置工作。对于公司在共享平台提出的数据申请，在7个工作日内完成共享库共享工作。五、数据备份备份内容，主要分为以下4类：4.应用系统流水线(即应用子系统部署包)。2.异机备份工具针对Linux服务器上的异机备份操作，我们采用开源的rsync进行异机备份。定时将每天通过Xtrabackup新增的数据库备份文件以及通过NFS传输存储的非结构化数据，通过差异备份方式备份到异机备份服务器上Linux服务器上的NFS文件服务器，我们采用开源的rsync进行异机备份。定时将每天新增的非结构化数据，通过差异备份方式备份到异机备份服务器上。NCR_3INCR6继续增量备份以INCRWEEKX:X表示一年的第几周，脚本会自动计算，不需要人为建立。周一继续增量备份周日以INCR_1为基础继续增量备份继续增量备份5为基础1.每周日晚上22点，数据库开始进行全量备份；2.每周一到周六的晚上22点，数据库进行一次增量备份。周六周六继续增量备份周五以INCR_5为基础周四周三WEEK_X:X表示一年的第几周，脚本会脚本安装后，即使当日非周日，脚本在第一次执行时也会进行判断并进行一次全量备份。、结构化数据备份实施脚本说明：、结构化数据备份实施步骤、异机备份实施脚本、结构化数据异机备份实施步骤交换节点数据库部门前置数据库行tail-fbackup.log命令，查看备份日志的最后几行，如果显示completedOK!则代表异机备份主要使用rsync工具。rsy、结构化数据恢复实施脚本、结构化数据恢复实施步骤交换节点数据库部门前置数据库、非结构化数据、应用系统部署包恢复实施步骤、本地备份存储空间估算间(天)(GB)大小(GB)五年后(GB)五年后求(GB)台数据库7放平台71交换节点数据库增量71部门前库增量717非结构化数据1永久应用系统部署包 1永久=规划1台异机备份服务器对共享交换平台相关数据进行异机备份。规划7T(规划5年)●以上场地保持7*24小时运作●数据实时复制●所有备用设备达到就绪(待命)状态，具备快速替代生产环境的能力按照国家平台统一标准指标要求，系统恢复时间目标RTO为30分钟，恢复点目标RPO约等于零(尽可能无数据损失)。1.mysql数据库(需要)2.reids缓存服务(暂不需要)redis中虽然存储了数据，但是这些都是数据库数据的复制或者用户会话生成的临时数3.nas存储(暂不需要)增量为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,换算为带宽则为应用系统使用了多达上百台服务器、每个服务器内都有1个或多个效可能要重启系统，这个人工操作很难保证每次、MySQL数据实时同步技术原理redologfisu户请求连接Master服务器，并请求从指定binlog日志文件的指定位置之后发送binlog日志内容。(日志文件名和位置就是在配置主从复制任务时执行changemaster命令时指定的)IO线程根据Slave服务器的IO线程请求的信4.返回的信息中除了binlog日志内容外，还有本次返回日志内容后在Master服务5.当Slave服务器的IO线程获取来自Master服务器上IO线程发送的日志内容(即中继日志)文件(mysql-relay-bin.xxxxxx)的最末端，并将新的binlog文件名能告诉Master服务器需要从新binlog日志的哪个文件哪个位置开始请求新的及时的把relaylog文件中的内容解析成在Master端曾经执行、MySQL容灾部署架构1.现有单机房中，为了保证MySQL的高可用，使用了MySQLMHA集群方案，通过搭建1主(MySQLMaster)1从(MySQLSlave)和一2.在双中心的架构方案下，需要在灾备机房中，与主机房搭建一套同样的MySQL3.为了实现主备数据同步，在主备机房的2套数据库节点上，设置开启MySQL4.为了避免主备机房2套系统同时写入造成数据不一致问题，需要确保备用系统不能写入数据，比较稳妥的做法是，将备用系统设置为关闭(待命)状态，只有等灾备本地本地将镜像存储到仓库Docker提供了一个很简单的机制来创建镜像或者更新现可以把容器看做是一个简易版的Linux环境(包括root用户权限、进程空间、用户空间和网络空间等)和运行在其中的应用程序。PaaS运维控制台是为应对复杂架构系统快速部署运维，基于Docker技术而研发、镜像仓库容灾方案技术实现项目A复制策略初始复制增量复制(删除)项目A、应用程序容灾备份实现1.在主机房搭建一套PaaS运维控制台，同时搭建好流水、应用系统灾备恢复实施步骤.1、灾备准备工作.2、灾备恢复实施系统运维人员在接受切换指令后，按照系统重要等级(一级、二级、三级)顺序更新和启动、应用系统灾备恢复耗时估算系统名称量时总耗时并发启实际耗时放平台1分钟10分钟25分钟中心的资源需求按照现有系统部署资源1:1比例配备。六、安全密钥处置管理6.1、管理机制简述与建议(一)工程阶段(二)后续建议6.2、业务系统访问账号管理客户项目组p结果2.对需要登录PaaS平台的人员单独开设账号，并做好权号要在1个工作日内进行删除；号请账申创建客户创内部单次处罚200元。项目组项目组客户账号创建化密码以及简单密码，项目组成员离场后其账号要在1个工作日内进行删除；3.所有人员在任何时间不可在正式库执行全表更新(没有where条件的update操内部单次处罚200元。服务器账户密钥及数据库密钥要求包含大小写字母+数字进行设置，不低于8位。重要参数七、技术支持配备专属的高级技术专家进行1V1的驻场服务以及各项资源的协调处理工作。电话响应包括且不限于以下3个方面：我方设立24小时技术援助电话，并安排有经验的工程师受理问题。当系统出现故障或八、故障处理目录管理系统1小时内提出解决方案、4小时内修复1小时内提出解决方案、4小时内修复交换监测系统1小时内提出解决方案、4小时内修复安全管控系统1小时内提出解决方案、4小时内修复1小时内提出解决方案、4小时内修复1小时内提出解决方案、4小时内修复系统接口1小时内提出解决方案、4小时内修复响应时间1小时申告，即时响应的基本功能不能实现或全面退化的故障；或在运行中出话将维护人员从家中叫到办公室。申告，即时响应务部分功能失效，少量用户报障。确保在恢复时间目标内完成5x8小时接受申确保在恢复时间目标内完成四级5x8小时接受申该等级的事件对业务的影响很小，且也不影响用户的日常工作。系统查询和报表信息等功能都能正确保在恢复时间目标内完成8.3、故障处理流程已知是否影响否为服务器硬件、网络或者系统软件故障问题。2、通过日志分析、监控告警分析及案例等方式进行排查确认。续的整体排障工作。首先需进行判断是否影响业务的运行，根据故障的类别选择对应方式处理。下，可以关闭优先级较低的业务系统释放资源，优先恢复优先级较高的业务系统系统。在处理故障时，操作如涉及服务器、存储设备、网络设备等关键物理设备的，需经信息中心同意后，方可进行操作。2、若为网络问题，需及时反馈客户方进行协调网络管理人员进行排查处理。3、若为软件系统功能故障，通过后台日志打印的报错判别，无法判别需开发人员处理情况需及时联系系统开发人员进行处理。4、对于无法直接判断定位为软件、硬件、网络故障或者多方均可能存九、应急保障9.2、系统应急保障2、云平台根据停电时间评估UPS能否支撑。确定是否执行服务器停机操作，并告知甲项目组。同时停电期间每30分钟确认一次供电恢复时间是否有延迟。3、项目组安排专人与云平台联系，30分钟确认一次，如需要停机，按反向代理-应用程序-5、项目组确认系统是否正常