运维管理规范

【实例简介】
覆盖基本的运维基础设施，人员，权限，数据安全等主题
级原则的时间框架。当达到下列时间时,如果事件还未解决,将触发升级原则。 d)重复原则:重复事件是指在一个较短时间段(如:30分钟内至1小时),由监控 系统上报的同一个配置项现象相同的事件或一人多人申告的同一来源(系统、应用) 现象相同的事件。 e)复发原则:如果报告的事件与已关闭的事件相同,该事件被认为是复发"的事件 单。这意味着为了解决事件而采取的解决措施失败了。此时应当创建一个新的事件 单,复制原始事件单的内容,并说明此事件为复发的事件。 f)关闭原则:事件在得以成功解决后,需要进行关闭。 (2)事件来源 事件来源 描述 电话 用户通过电话上报事件 电子邮件 用户通过电子邮件上报事件 Web 用户通过Web上报事件 监控工具 主动监控发现并识别的事件 现场 用户现场上报事件 即时工具 用户通过QQ、微信等方式上报事件 (3)事件分类 a)故障桌面类 b)故障基础设施类 C)故障应用系统类 d)服务请求 3/21 e)需求 (4)事件状态 编号事件状态 描述 新建 新开事件记录单,记录事件请求信息 已分派事件已分派给事件处理人员,等待事件处理 234 处理中事件处理人员受理事件后,对事件展开处理 事件信息不完整,或在某些情况下阻止支持人员对 挂起 事件进行处理 5 已解决事件已由事件处理人员解决 6 已关闭事件经用户确认后得到关闭 (5)事件优先级 遵循服务优先级原则。 3、问题管理 (1)问题定义 问题管理的根本目的是消除或减少事件的发生此流程分析发生在「运行环境 的事件,确定最常发生或具有最大影响的事件,找出根本原因,然后制定根本解 决方案或提出临时的变通方案来防止事件的再次发生。所以问题管理和事件管理 有密切的关联关系。 (2)问题来源 编号 问题来源 描述 同一事件反复同一个事件在某个时间周期内会反复发生,可关注对复发 发生 事件的分析。 多个事件相同多个事件表现出来的症状相同或相似,比如网络病毒爆 症状 发导致的大规模网络瘫痪。 对用户业务造成重大影响的故障,可参考影响度优先级定 3单个重大故障 义 4以应变措施解没有找到根本解决方案的事件,以临时的应变措施解决的 4/21 决的事件事件 通过对用户网络设施监控和主动巡检所发现的潜在的需 主动巡检 要讨论和根源分析的重大故障隐患 报表与例会制通过报表分析发现的需要讨论的问题,可以通过月度例会 度 制度,主动提出问题。 (3)问题分类 a)网络类 b)机房类 c)基础应用类 d)应用系统类 (4)问题状态 编号事件状态 描述 新建个问题被记录或创建 2已分派一个问题已被分派给间题分析专家或问题经理 处理中任何一个问题分析专家接受了问题 4 拒绝当经问题分析专家分析,发现派单不正确的时候,问题 分析专家可拒绝该问题,转由问题经理进行重派 问题信息不完整,或在某些情况下阻止问题分析专家对 挂起 问题的处理 该问题单被取消,问题经理做评审的时候,可由于资源 取消 678 或者能力方面的原因取消问题调查 已解决为一个问题找到解决方案或变通方法 关闭问题已经关闭 (5)问题优先级 遵循服务优先级原则。 4、变更管理 5/21 (1)变更定义 变更是指,对公司内部的T设备的忏配匱项(软硬件,数据,基础设施等)进行 增删改查操作,引发生产系统状态改变。 (2)变更类型 变更分为预授权变更(专业组组长审批),标准变更(专业组组长、变更经理审 批),评审变更(CAB审批)和紧急变更。 a)预授权变更 特点:经常实施的,不涉及参数修改,经过长期实践证明对生产环境无影响,风 险极低,且变更实施过程和结果完全可控的变更。 流程控制:由变更管理员受理后,即可实施;若变更方案实施出现异常,则需要 CAB重新审批。 适用范围:影响范围在系统内部的变更走预授权变更,一般适用于由系统內配匱 变更以及新的系统配置而来的变更。 b)标准变更 特点:经常实施的,涉及参数修改,有明确的变更方案,风险较低且变更实施过 程和结果可控。 流程控制:变更管理员受理,组长审批,变更经理审批后才能实施 适用范围:影响范围在信息技术部內部的变更走标准变更,一般适用于由问题需 求,客户需求,软硬件升级,提高工作效率,提高变更质量,提高客户满意度,降低 费用而来的变更。 C)评审变更 特点:不经常实施的,没有成型的方案,变更环境负责,存在实施风险。 流程控制:必须提交详细变更方案,并经过CAB评审之后,才能实施。 适用范围:影响范围涉及业务客户的变更走评审变更,一般适用于核心设备变更 (网络、存储),或由新的业务需要,新的政策法规,新的产品服务,减少对业务影 响而来的变更适用于标准变更 6/21 d)紧急变更 特点:由于|设备故障或者业务紧急需求,需要紧急实施。 流程控制:在实施前,变更负责人通知变更经理,告知变更情況;变更负责人负 责紧急实施,实施后补单,并提供故障分析报告来闭环变更。 活用范围:变更风险等级为E的变更适用于紧急变更。 (3)变更来源 变更原因 说明 问题需求 为关闭产生的问题提出的变更 客户需求 为满足客户的需求提出的变更 新的系统配置 因产生了新的系统配置提出的变更 新的业务需要 因产生了新的业务需要提出的变更 新的政策法规 因出台了新的政策法规提出的变更 新的产品服务 因出现了新的产品服务提出的变更 软硬件升级 因软硬件升级提出的变更 提高工作效率 为提高工作效率提出的变更 提高变更质量 为提高变更质量提出的变更 提高客户满意度为提高客户满意度提出的变更 减少对业务影响为减少对业务影响提出的变更 降低费用 为降低费用提出的变更 (4)变更状态 变更状态 说明 变更申请 变更提出状态 变更审批 变更审批状态 变更实施 变更实施状态 变更评定 变更结果评定状态 变更闭环 变更关闭状态 (5)变更风险等级 7/21 风险 条件 说明 会对很多用户造成影必须立即进行变更。通常此类变更是为了解决系 E响/必须得到领导批|统问题,或防止某种重大问题的出现而改变系统 准 的状况。 系统不能工作 可能会带来后续的问题 -变更失败后的恹复很难或根本无法恹复 高风险影响大 变更失败会对业务造成影响 变更实施流程从未实践过或不可重复 如果变更失败,使用该系统的所有用户将受影响 系统不能工作 可能会带来后续的问题 -变更失败后,需要通过恹复流程恹复 2高风险影响小 变更失败会对业务造成影响 变更实施流程从未实践过或不可重复 -如果变更失败,使用该系统的大多数用户捋受影 响 系统可能不能工作 可能会带来后续的问题 变更失败后,恹复不难并且恹复的成功性高 3中度风险影响小变更失败会对业务造成点影响 该变更流程已被采用过多次,或该流程非常简单 如果变更失败,使用该系统的少部分用户将受影 响 系统能工作 变更对用户没有影响 -变更失败后的恹复流程一定会成功,并且恹复流 程对用户没有影响 4低风险没有影响 变更失败不会有任何影响 在相同的环境中,类似变更已被成功实施多次 如果变更失败,使用该系统的用户不会有任何影 响 8/21 (6)变更流程 变更流程图 变更发起人变更管理员变更主管变更经理 CAB 颔导层变更实逋人变更实施团队变更发起人 形反组织过 交变更中请 变更曰南单 变更受理分 确认为预提板变 指派变更实施 分派含适约小组 烂 审批通过进入 变更实施环节 指派变更实疤 分派含适的小组 实施方案提交 CAB审 史实施片 变甲给埋8 捂交领导层阅 提交结果 是交变更咔请 安并变更 斗填变更中请 5、上线管理 (1)资源分配 项目负责人—信息技术部经理—运维负责人—平台负责人 (2)环境部署 由平台运维(SA、DBA)根据申批后需求操作,后续根据场景自动分配。 (3)安全扫描 安全组对生产环境进行漏洞检查及评估。 (4)高可用测试 对生产环境进行高可用测试 (5)压力测试 通过预估的压力模型进行生产压测 (6)权限回收 9/21 应用运维验证后,生产环境运维接管,修改相关密码接入管控平台 6、请求管理 (1)资源申请 开发负责人—运维负责人—平台运维分配与通知 (2)账号申请 申请人值接上级—运维操作及通知 (3)权限申请 申请人—接上级—运维负责人—运维操作及通知 四、运维制度说明 运维 应用运维系统运维数据库运维平台研发安全运维 1、运维指标 (1)系统可用性 指系统在保证的“应用运行时间”段内,系统正常运行的时间占全部承诺的应用运行时间 的比例下限。 某月某系统的可用性为: (承诺的某月全部运行时间-在承诺的某月运行时间内没有运行的时间)/承诺的某月 全部运行时间x100% 如99%,意味着在承诺的系统应用运行时间段内,至多有1%的时间,系统可能因运行环 境方面的原因,如突发故障,而无法正常运行。此时间从服务提供方或甲方发现业务运行意 外中断(或一个系统意外停止运行)开始,直至业务运行恹复(或系统重新开始运行)的时 间间隔。 (2)事件平均响应时间 (3)事件平均解决时间 10/21 【实例截图】
【核心代码】