运维管理和项目管理有个本质的区别。项目管理是能主动掌控且有一定buffer的，表面上是有业务方在施加各种压力，但实际上的节奏始终在由项目经理自己掌控。运维管理不出问题的时候大家可以不慌不忙，出了问题则往往没有后路。所以运维管理实际上是被动的，且会隐藏很多未知的风险。因此，做好运维管理的关键点就在于：保持危机意识，化被动于主动，以此获得所负责系统的彻底的掌控权。接下来的举措如下：
一．系统管理
1、关键因子识别：彻底识别影响系统稳定的关键因子（含配置、网络、服务器、信息安全、数据库、关键数据表、程序流程、业务功能、并发量、数据量、点击量等）
2、关键因子监控盲点识别：根据关键因子清单识别我们目前监控的盲点并采取对应的弥补措施
3、人工巡检趋势管理：人工巡检内容需建立标准（合格、预警、异常）并做趋势管理、预防性维护管理措施
4、人员权限统一管控：关键用户权限实现分级统一，系统管理员权限分级统一（数据库、堡垒机、中间件、应用）（纳入发布文档形成闭环）
5、配置清单识别与更新：系统配置清单全集，业务功能与系统配置清单的对应关系（如功能、配置、服务器）（纳入发布文档形成闭环）
6、数据字典清单调整与更新：建立以业务逻辑为主线的数据字典清单（纳入发布文档形成闭环）
7、人性化的日志分析
二．日常管理（三清一评一库）
1、日常问题清单-定期内部会议
2、发布执行问题专项清单-按需会议（与积分管理形成闭环）
3、疑难杂症及重大事故清单-定期会议与一追到底的管理机制（需与复盘表、经验案例库形成闭环，复盘表的模板需建立）
4、功能设计评审会议
5、疑难杂症及重大事故清单的经验案例库建设
三.发布管理
1、发布事项清单及执行管理机制建立：明确代码发布的全部关键事项（如DHR模板等）及管理流程，责任到角色/人（DEV->QAS->PRD）
2、发布评审定期会议（正式会议评审）
3、扩大变更的定义
主动变更：代码主动发布，后台数据修改；
被动变更：主数据的变化、ERP、服务器、网络、信息安全
4、发布文档的各节点要求需继续更新完善（需与其他管理要求的输出形成闭环）如数据库字典有无更新、配置清单有无更新、权限管理有无更新、人工巡检内容有无更新、回退方案及发布前的版本等
5、鼓励互相挑战（业务向业务挑战、业务向开发挑战、开发向业务调整）
6、相关发布评审会议的参与
7、需参与系统相关的其他部门的变更评审会议（如信息安全、网络、服务器、ERP、PI等）
四.人员管理
1、积分管理制度（针对开发、业务，需涵盖追责管理）
2、人员能力对齐
人员与系统的能力矩阵衡量关系（针对开发、业务，建立人员能力对齐标准）
3、交叉培训与轮岗机制（针对业务，实现人员能力对齐）
4、团队凝聚力及持续改善建设
四分钟团队日常会议（一分钟赞美，一分钟自我改善，一分钟重点问题与风险，一分钟好的点子）
五.应急管理
应急管理预案（资源协调和向上汇报的标准；对外资源协调的时间切入点；统一指挥和绝对执行）
六.文档管理
1、运维FDS全局更新
2、变更实现文档的再度思考（如何与运维FDS进行闭环）
对于系统是否有掌控性的标准在于能否回答下面三个问题：
第一个：系统用1年后大概会是个什么速度，2年后，5年后又是个什么速度；大概什么时候我们就要开始重做系统等
第二个：什么样的变更会导致什么样的问题，回退方案是否清楚？
第三个：没有任何的主动变更，系统会不会有问题？
