下载文档原格式
运维工作及常见解决方案
1.概述
1.1编写目的
编写本解决方案的目的是对运维人员在遇到问题的时候提供一个可参考的依据。
2.
想解决方案，在去见客户的时候知道如何操作；
⏹负责人给运维人员派工单，运维人员去执行；
⏹执行完之后跟负责人交待此次工作结果；
⏹回复，双方接收
⏹每周的运维工作数据及运维工作报告的电子档须在下周一十点前发送到
负责人邮箱中。
3.运维工作内容
1)终端软件维护
2)网络调整
3)
4)
5)
6)
7)
8)
4.
●
●杀毒软件
●360安全卫士，修复系统漏洞，点击修复，在安装路径中产生一个hotfix文件
夹，然后把工具中的hotfix文件夹里面所有文件拷贝到安装路径下的hotfix
文件夹；
●装常用的工具：Wara,暴风影音，Adobe,QQ,MSN,以及用户要求的免费软件
旧电脑：
●IP设置，每次都要记录IP，在用完之后把IP设置为原来的IP
●旧机器在装系统之前，我的文档及桌面上的文件要备份，用U盘拷贝出来再
装系统（要特别注意财物室的机器重装系统，在装系统之前还需要把C盘里面的某些文件给拷贝出来）
1.1.2软件问题
1.1.3硬件问题。
常见问题及处理方案CPU使用率高的问题通过操作系统命令top topas glance等查看top进程号，确认是系统进程还是oracle应用进程，查询当前top进程执行的操作和sql语句进行分析。
根据进程号获取正在执行的sqlSELECT a.osuser, ername,b.address,b.hash_value, b.sql_text from v$session a, v$sqltext b, v$process pwhere p.spid = &spidand p.addr = a.paddrand a.STATUS = 'ACTIVE'and a.sql_address =b.addressorder by address, piece;数据库无法连接数据库无法连接，一般可能是如下原因造成：（1）数据库宕了（2）监听异常（3）数据库挂起（4）归档目录满（5）数据库或应用主机的网卡出现问题不能正常工作（6）应用主机到数据库主机的网络出现问题。
1、数据库宕了立即启动数据库。
2、监听异常此时一般体现为：监听进程占用CPU资源大；监听日志异常。
此时，立即重启监听，监听重启一般能在1分钟之内完成。
3、数据库挂起立即重启数据库。
4、归档目录满（1）在没有部署OGG数据同步的情况下，立即清理归档日志文件。
（2）如果部署了OGG数据同步，查看OGG正在读取的归档日志文件，立即清理OGG不再需要的日志文件。
5、数据库或应用主机的网卡出现问题不能正常工作。
立即联系主机工程师处理。
6、应用主机到数据库主机的网络出现问题。
立即联系网络维护人员查看。
CRS/GI无法启动对于10g及11gR1版本的CRS问题1、进入/tmp目录下，看是否产生了crsctl.xxxxx文件如果有的话，看文件内容，一般会提示OCR无法访问，或者心跳IP无法正常绑定等信息。
2、如果/tmp目录下没有crsctl.xxxxx文件此时查看ocssd.log文件，看是否能从中得到有价值的信息。
软件系统运维技术中常见问题解决思路分享在软件系统运维过程中，经常会遇到各种问题，这些问题有时会威胁到系统的稳定性和安全性。
为了保证系统的正常运行，运维人员需要具备解决问题的能力和技巧。
本文将分享一些常见的软件系统运维问题解决思路，帮助运维人员更好地应对挑战。
一、系统性能问题1. 性能监控与调优在系统性能出现问题时，首先需要进行性能监控，查看系统资源的使用情况，包括CPU、内存、磁盘和网络等。
通过监控工具收集并分析性能数据，找出系统性能瓶颈所在。
根据监控结果，可以采取相应的优化措施，如增加硬件资源、优化代码、调整配置参数等。
2. 系统负载过高系统负载过高可能是由于请求量大、业务复杂、资源不足等原因引起的。
解决此类问题，可以通过增加硬件资源，如增加服务器数量、使用负载均衡等技术手段分担系统负载。
同时，还可以对系统进行优化，包括数据库索引优化、代码优化、缓存技术应用等。
二、安全问题1. 安全漏洞修复软件系统中存在安全漏洞可能会被黑客利用，危及系统的安全性。
及时修复安全漏洞是运维工作的重要一环。
首先，需要及时关注相关漏洞信息和公告，了解已知的安全漏洞。
其次，要及时更新系统和应用程序的补丁，以修复已知的漏洞。
此外，还应定期进行安全扫描和渗透测试，发现潜在的安全风险并采取措施加以修复。
2. 访问控制和权限管理在软件系统运维中，访问控制和权限管理是保护系统安全的重要手段。
通过设置合理的用户管理机制、角色分配和权限控制，可以限制用户的访问以及操作权限，防止未授权用户对系统数据和功能的滥用。
此外，还可以使用防火墙、入侵检测系统等安全工具，对系统进行全面的安全管理和防护。
三、数据备份和恢复问题1. 定期备份数据定期备份系统数据是防止数据丢失和系统故障的有效措施。
要设置合理的备份策略，包括备份频率、备份内容和备份存储位置等。
备份数据时，应注意选择可靠的备份介质，并确保备份数据的完整性和可恢复性。
2. 数据恢复与故障排除当系统数据丢失或系统发生故障时，需要进行数据恢复和故障排除。
系统运维工程师系统运维故障处理系统运维工程师作为企业中至关重要的一员，负责保障公司信息系统的稳定运行。
而在日常工作中，故障处理是系统运维工程师必不可少的一项技能。
在本文中，将重点介绍系统运维工程师在故障处理过程中应该采取的策略和步骤。
一、故障分析与诊断1. 确定故障现象：首先，系统运维工程师需要与用户或相关部门进行沟通，详细了解故障现象和用户遇到的问题。
同时，对系统的异常日志和报警信息进行分析，以便初步确定故障类型和范围。
2. 故障分类与优先级：根据故障现象的严重程度和影响面，对故障进行分类和确定优先级。
例如，重要的生产系统故障优先级较高，需要紧急处理，而一些服务性系统故障则可以稍后处理。
3. 系统状态分析：对故障系统的状态进行分析，包括系统日志、性能指标等信息的收集和分析。
通过对系统状态的分析，可以找出故障产生的原因和可能的解决方案。
二、故障处理步骤1. 制定故障处理计划：根据故障类型和优先级，制定故障处理的详细计划。
包括需要采取的措施、操作步骤和时间安排等。
2. 实施故障处理：按照制定的故障处理计划，逐步实施故障处理措施。
在处理过程中，应注意记录操作日志和故障处理过程中的关键信息。
3. 故障排除与验证：在故障处理过程中，需要不断进行故障排查和验证。
通过逐一排除可能的故障点，直到故障解决为止。
解决故障后，还需要对系统进行测试和验证，以确保故障完全修复。
4. 修复方案分析与总结：在故障处理完成后，系统运维工程师需要对故障处理过程进行分析和总结。
包括故障产生的原因、解决方案的有效性以及后续预防措施等。
通过对故障的分析与总结，可以提高日后故障处理的效率和准确性。
三、故障处理中的注意事项1. 沟通与协调：在故障处理过程中，与用户、运维团队和相关部门之间的沟通十分重要。
及时、准确地获取故障信息，并与他们保持紧密的沟通和协作。
2. 优先级管理：针对存在多个故障的情况，系统运维工程师需要根据优先级进行处理。
运维服务故障处理方案
以下是一份运维服务故障处理方案：
一、故障分类及优先级划分
1. 按照影响范围和严重程度对故障进行分类，如：系统故障、网
络故障、应用故障、数据故障等。
2. 对不同类型的故障进行优先级划分，以确保优先处理对业务影
响最大的故障。
二、故障监测与报警
1. 建立完善的监控系统，对关键设备、服务、指标进行实时监测。
2. 设置合理的报警阈值，当触发报警时，及时发送给相关人员。
三、故障诊断与排查
1. 收到报警后，根据故障现象进行初步诊断，确定故障类型和可
能的原因。
2. 根据故障类型，采用相应的排查方法，如检查日志、查看系统
状态、进行网络测试等。
3. 对于复杂故障，可借助专业工具进行深入分析。
四、故障修复与恢复
1. 根据故障原因，采取相应的修复措施，如重启服务、更新配置、修复软件漏洞等。
2. 在修复过程中，及时与相关人员沟通，告知修复进度和可能的
影响。
3. 修复完成后，进行测试验证，确保故障已修复且系统恢复正常。
五、故障总结与改进
1. 对故障处理过程进行详细记录，包括故障现象、原因、处理过程、修复结果等。
2. 对故障进行总结分析，找出故障根本原因，并制定相应的改进
措施，防止类似故障再次发生。
3. 定期对故障处理方案进行评估和优化，不断提高故障处理效率
和质量。
通过制定完善的运维服务故障处理方案，企业可以提高故障处理的效率和质量，减少业务中断时间，保障业务的连续性和稳定性。
同时，通过故障总结和改进，可以不断提高系统的可靠性和稳定性，为企业的发展提供有力的支持。
运维系统故障应急处置措施1. 前言本文档旨在为运维团队提供一套应急处置措施，以确保在系统故障发生时能够快速响应和解决问题，保障系统的稳定运行。
2. 故障诊断与定位在发生系统故障时，首先需要进行故障诊断与定位，确定故障的具体原因和位置。
下面是一些常用的方法和工具：- 日志分析：通过分析系统日志、错误日志等可以迅速定位出故障的来源。
- 监控系统：借助监控系统可以实时监测系统运行状态，及时发现异常情况。
- 排查常见故障：熟悉常见的故障类型和解决方案，可以更快速地定位和解决问题。
3. 故障应急处理流程当系统故障发生时，运维团队需要按照以下流程进行应急处理：1. 接收故障报告：及时接收用户或系统报告的故障情况，确保能够快速响应。
2. 快速响应：运维人员需要迅速回应故障报告，确认故障并开始处理。
3. 故障诊断：通过故障诊断与定位，尽快找到故障的具体原因和位置。
4. 启动备份系统：如果存在备份系统，可以通过启动备份系统来保障服务的持续运行。
5. 修复故障：根据故障的具体原因，运维人员需要尽快采取合适的措施修复故障。
6. 测试验证：在修复故障后，运维人员需要进行测试验证，确保故障已经彻底解决。
7. 恢复服务：经过测试验证确认故障已解决后，运维人员可以恢复系统服务。
8. 故障记录与总结：对于每个故障案例，运维团队需要进行记录和总结，以便日后遇到类似问题时能够快速处理。
4. 故障预防与优化除了应急处置措施外，系统故障的预防和持续优化也是非常重要的。
以下是一些常用的方法和策略：- 定期维护：定期对系统进行维护和检查，及时修复潜在问题。
- 自动化监控：使用自动化监控工具实时监测系统运行状态，及时发现并处理异常情况。
- 容量规划：对系统的容量进行合理规划，确保系统能够满足业务需求。
- 持续优化：定期对系统进行性能优化，提升系统的稳定性和响应速度。
5. 总结应急处置是运维工作中非常重要的一环，运维团队需要掌握相应的故障诊断与定位技巧以及快速响应和解决问题的能力。
运维工程师故障排除思路作为一名运维工程师，我们经常需要面对各种各样的故障，这些故障可能来自于服务器、网络、应用程序等各个方面。
在面对故障时，我们需要有一套清晰的排除思路和方法，以便快速定位和解决问题。
下面我将分享一些运维工程师故障排除的思路和经验。
1. 定位故障范围当我们遇到一个故障时，首先要明确故障的范围，是服务器出了问题还是应用程序出了问题，还是网络连接有问题。
通过观察故障的表现和现象，我们可以初步判断故障的范围。
2. 收集故障信息在排除故障之前，我们需要收集尽可能多的故障信息。
这些信息可以包括故障发生的时间、故障的具体表现、相关的日志信息等。
通过收集这些信息，我们可以更好地分析和定位问题。
3. 检查网络连接如果故障范围包括网络连接，我们需要检查网络设备是否正常工作，包括路由器、交换机、防火墙等。
可以通过ping命令或网络诊断工具来测试网络连接是否正常。
4. 检查服务器硬件如果故障范围包括服务器硬件，我们需要检查服务器的硬件状态，包括电源、硬盘、内存等。
可以通过服务器管理工具或命令行工具来查看硬件状态。
5. 检查操作系统如果故障范围包括操作系统，我们需要检查操作系统的状态和配置。
可以通过查看系统日志、运行命令查看系统资源使用情况、检查服务是否正常运行等来排查问题。
6. 检查应用程序如果故障范围包括应用程序，我们需要检查应用程序的配置和状态。
可以通过查看应用程序日志、运行命令查看应用程序的运行情况、检查相关组件是否正常等来解决问题。
7. 使用故障诊断工具在排除故障时，我们可以使用一些故障诊断工具来帮助我们定位问题。
这些工具可以包括网络分析工具、日志分析工具、性能监控工具等。
8. 参考文档和社区如果我们无法解决故障，可以参考相关的文档和社区来获取帮助。
很多时候，我们遇到的故障可能是其他人已经遇到并解决过的，他们的经验和建议可能对我们有很大帮助。
9. 实施解决方案在定位和解决问题后，我们需要根据实际情况，制定并实施解决方案。
如何处理高压运维中的故障恢复在运维过程中，故障是难以避免的。
当高压运维中发生故障时，故障恢复成为运维团队的一项重要任务。
本文将探讨如何处理高压运维中的故障恢复，并提供一些建议和方法。
一、故障排查与分析1. 故障定位：首先，需要通过对问题进行观察和分析，确定故障的具体位置和范围。
这包括软件、硬件还是网络等方面的问题。
2. 数据采集：在确定故障范围后，运维团队应及时采集相关的故障数据，如日志记录、错误信息等，以便更好地分析和解决问题。
3. 故障分析：通过对采集的数据进行仔细分析，找出问题的根本原因。
可以借助一些优秀的故障分析工具和方法，如故障树分析等。
二、快速响应和恢复1. 制定预案：在运维工作中，事先制定好各类故障的处理预案非常重要。
针对不同的故障类型，定制相应的应急方案，明确各个步骤和责任人。
2. 建立沟通机制：故障发生时，及时与相关人员进行沟通，形成故障响应团队，分工明确、高效配合。
可以利用一些在线协作工具，加快沟通效率。
3. 快速响应：一旦故障发生，运维团队应立即进行紧急响应，尽量缩短故障对系统和用户的影响。
例如，暂时停止相关服务、转移流量、切换备用设备等。
4. 故障恢复：根据事先准备好的故障恢复方案，有针对性地进行故障处理，并在故障解决后进行相应的测试和验证，确保系统能够正常运行。
三、优化故障处理流程1. 故障记录与总结：在处理每个故障时，及时记录相关信息，包括故障原因、处理过程、解决方案等。
有效的故障记录与总结有助于提高运维团队的应对能力。
2. 不断优化：根据故障记录与总结的经验，不断优化故障处理的流程与策略，提高故障处理的效率与质量。
可以考虑引入自动化工具和流程，提高操作效率。
3. 举一反三：通过对已有故障处理案例的分析，运维团队可以从中发现一些潜在的问题，并采取相应的预防措施，防患于未然。
结语高压运维中的故障恢复是一项极具挑战性的任务，但经过合理的排查与分析、快速的响应和恢复以及不断的优化，故障可以得到有效的解决。
运维排查故障思路合同甲方（委托方）：_____________________________________地址：_______________________________________________联系电话：___________________________________________法定代表人：_________________________________________乙方（运维方）：_____________________________________身份证号/统一社会信用代码：__________________________地址：_______________________________________________联系电话：___________________________________________为确保甲方系统的稳定运行，甲乙双方本着平等、自愿、协商一致的原则，就甲方系统运维中的故障排查思路与处理方案达成以下协议：一、合同目的1.1 本合同旨在明确乙方为甲方提供的系统运维服务，重点包括故障排查、问题解决及相关技术支持，确保系统在发生故障时能及时、高效地恢复运行。
二、排查故障的范围2.1 甲方委托乙方负责以下系统和服务的运维及故障排查：2.1.1 服务器硬件及网络设备；2.1.2 操作系统及相关软件环境；2.1.3 应用程序及数据库；2.1.4 网络连接、数据传输等基础设施。
2.2 本合同的故障排查主要针对系统崩溃、性能瓶颈、网络中断、应用错误、数据异常等问题。
三、故障排查思路及步骤3.1 **初步判断**3.1.1 乙方应首先确认故障的基本信息，包括故障的发生时间、症状、影响范围以及系统日志的初步分析；3.1.2 乙方应通过检查系统监控工具、日志文件等，初步确认问题的源头（硬件故障、软件问题或网络故障等）。
3.2 **分类定位**3.2.1 根据初步分析，乙方应分类进行问题定位，区分故障发生在硬件、操作系统、网络还是应用程序层面；3.2.2 对于硬件问题，乙方应使用故障诊断工具或手动检查设备状态；3.2.3 对于软件和应用问题，乙方应排查日志、重现错误，并分析软件配置和资源使用情况；3.2.4 对网络问题，乙方应使用网络诊断工具，如ping、traceroute等，确认连接状态和数据传输情况。
事件/ 故障处理应该要有什么思路导读：在讲解事件、故障处理思路前，我先讲一个故障场景（以呼叫中心系统作为一例子）：业务人员反映呼叫中心系统运行缓慢，部份电话在自助语言环节系统处理超时，话务转人工座席，人工座席出现爆线情况。
运维人员开始忙活了，查资源使用情况、查服务是否正常、查日志是否报错、查交易量还有没有,, 时间不知不觉的在敲键盘、敲键盘、敲键盘中过去，但是原因还未定位。
经理过来了解情况：“系统恢复了吗？”、“故障影响是什么？”、“交易中断了吗？” ,,运维人员赶紧敲键盘，写sql ，看交易量；敲键盘，写命令，看系统资源、情况,,最终，定位到问题原因是其中一个功能没有控制返回数量，导致内存泄露。
针对这个故障，业务希望运维能否更快的解决故障的恢复，经理希望制定优化呼叫中心故障处理流程，做了以下几件事：1. 优先故障处理过程的时间——”能通过鼠标完成的工作，不要用键盘“2. 提前发现故障，加强监控——“技术早于业务发现问题，监控不仅是报警，还要协助故障定位”3. 完善故障应急方案——“应急方案是最新的、准确的、简单明了的”4. 长远目标：故障自愈——”能固化的操作自动化，能机器做的让机器做a下面将从故障常见的处理方法开始介绍，再从故障前的准备工作（完善监控、制定应急方案等方式）来解决经理提出的问题，并提出未来解决故障的想法。
1、常见的方法：1）确定故障现象并初判问题影响在处理故障前，运维人员首先要知道故障现象，故障现象直接决定故障应急方案的制定，这依赖于运维人员需要对应用系统的整体功能有一定的熟悉程度。
确认了故障现象后，才能指导运维人员初判断故障影响。
2）应急恢复运维最基本的指标就是系统可用性，应急恢复的时效性是系统可用性的关键指标。
有了上述故障现象与影响的判断后，就可以制定故障应急操作，故障应急有很多，比如：•服务整体性能下降或异常，可以考虑重启服务；•应用做过变更，可以考虑是否需要回切变更；•资源不足，可以考虑应急扩容；•应用性能问题，可以考虑调整应用参数、日志参数；•数据库繁忙，可以考虑通过数据库快照分析，优化SQL・应用功能设计有误，可以考虑紧急关闭功能菜单；*还有很多,,另外，需要补充的是，在故障应急前，在有条件的情况需要保存当前系统场景, 比如在杀进程前，可以先抓个CoR文件或数据库快照文件。
3）快速定位故障原因•是否为偶发性、是否可重现故障现象是否可以重现，对于快速解决问题很重要，能重现说明总会有办法或工具帮助我们定位到问题原因，而且能重现的故障往往可能是服务异常、变更等工作导致的问题。
但，如果故障是偶发性的，是有极小概率出现的，则比较难排查，这依赖于系统是否有足够的故障期间的现场信息来决定是否可以定位到总是原因。
•是否进行过相关变更大部份故障是由于变更导致，确定故障现象后，如果有应的变更，有助于从变更角度出现分析是否是变更引起，进而快速定位故障并准备好回切等应急方案。
*是否可缩小范围一方面应用系统提倡解耦，一支交易会流经不同的应用系统及模块；另一方面, 故障可能由于应用、系统软件、硬件、网络等环节的问题。
在排查故障原因时应该避免全面性的排查，建议先把问题范围缩小到一定程序后再开始协调关联团队排查。
*关联方配合分析问题与第（3）点避免同时各关联团队同时无头绪的排查的同时，对于牵头方在缩小范围后需要开放的态度去请求关联方配合定位，而对于关联方则需要有积极配合的工作态度。
•是否有足够的日志定位故障原因，最常用的方法就是分析应用日志，对运维人员不仅需要知道业务功能对应哪个服务进程，还要知道这个服务进程对应的哪些应用日志，并具备一些简单的应用日志异常错误的判断能力。
* 是否有COre或dump等文件故障期间的系统现场很重要，这个在故障应急前建议在有条件的情况下留下系统现场的文件，比如C0RE∖DUMP或TRAC采集信息等，备份好一些可能被覆盖的日志等。
上述是一般性的故障常见的方法，在重大故障或多方处理的故障出现时，往往小范围的排查不利于快速解决，需要启动紧急处理的流程，建议可以考虑以下沟通：•召集相关人员•描述故障现状•说明正常应用逻辑流程•陈述变更•排查进展，展示信息*领导决策2、完善监控1）从监控可视化上完善完善的监控策略需要有统一的可视化操作界面，在制定完善的监控策略后，故障处理人员需要能够快速的看到相应的运行数据，比如：能够看到一段时间的趋势、故障期间的数据表现、性能分析的情况等等数据，且这些数据可以提前制定好策略直接推出分析结果给故障处理人员，这样就大大提高了故障的处理效率，以呼叫中心系统为例，需要提前配置好以下实时交易数据，以便故障定位：-交易性能数据：平均交易耗时、系统内部模块交易耗时（IVR交易耗时、接口总线交易耗时）、关联系统交易耗时（核心交易耗时、工单系统交易耗时等）IVR交易量、话务量、座席通话率、核心交易笔-重要交易指标数据：交易量、数、工单等系统交易量-交易异常情况数据：交易成功率、失败率、错误码最多交易- 按服务器分析交易数据：按server 统计各服务交易处理笔数，交易总耗时有了以上交易数据，并通过监控按一定频率统计，运维人员在出现故障时，通过鼠标即点击即可看到故障什么时候开始，是系统内部有问题还是关联系统有问题，最突出的交易是哪一支，各服务器交易量是否均衡等情况。
2）从监控面上完善监控最基本的工作就是实现对负载均衡设备、网络设备、服务器、存储设备、安全设备、数据库、中间件及应用软件等IT 资源的全面监控管理。
在应用软件类的监控工作中，不仅需要有服务进程、端口等监控，还需要有业务、交易层的监控。
全面性的应用监控可以让故障提前预警，并保存了影响应用运行环境的数据，以缩短故障处理时间。
3）从监控告警上完善完善的监控策略需要有清晰的监控告警提示，值班人员要以根据监控告警即可作出简单的问题定位与应急处理方案。
比如类似以下的监控短信：22时，【理财应用系统】中【应用服务器LC_APPsvrA 10.2.111.111 】的【前置应用模块】出现【应用端口：9080】不存在，该端口作用【提供理财应用处理（负载均衡部署）】，原因可能为【SERVER服务异常停止】，监控系统己进行以下应急处理【自动执行端口进程启动】，该事件紧急程度【高】。
管理员可以通过短信内容看到哪个系统、哪个应用、哪个模块出了什么问题，可能是什么原因，对业务有什么影响，是否需要马上处理（比如凌晨出现此预警是否可以延迟到次日处理）等信息。
4）从监控分析上完善完善的监控策略不仅需要有实时的数据告警，也要有汇总数据的分析告警, 实时数据分析的告警的重要性不用多说，对于汇总分析的数据则能发现潜在风险，同时也为分析疑难杂症提供帮忙。
5）从监控主动性上完善监控不仅仅是报警，它还可以做得更多，只要我们想办法赋予它主动解决事件的规则，它便有为管理员处理故障的能力。
3、应急方案提前制定好故障应急方案是很有必要的，但在日常工作过程中我们的应急方案遇到一些问题：1）应急方案缺乏持续维护，缺乏演练，信息不及时、不准确；2）应急方案过于追求大而全，导致不利于阅读与使用；3）应急方案形式大于实际使用效果，方案针对性不强；4）只关注应急方案的内容，但没有关注运维人员对方案的理解；针对上述常见问题，我认为应急方案需要做到以下几点：1）内容精&简很多人可能会认为故障出现的形式各种各样，所以应急方案需要涉及到方方面面。
但实际的故障处理过程中，我们可以发现其实我们的应急措施往往重复使用几个常用的步骤，所以我认为应急方案要有重点，如果一个应急方案可以应对平时故障处理80%的场景，那这个应急手册应该是合格的。
过于追求影响应用系统方方面面的内容，会导致这个方案可读性变差，最终变更一个应付检查的文档。
以下是我觉得应用系统应急方案应该有的内容：（1）系统级：能知道当前应用系统在整个交易中的角色，当前系统出现问题或上下游出现问题时，可以知道如何配合上下游分析问题，比如：上下游系统如何通讯，通讯是否有唯一的关键字等。
另外，系统级里还涉及一些基本应急操作，比如扩容、系统及网络参数调整等。
（2）服务级：能知道这个服务影响什么业务，服务涉及的日志、程序、配置文件在哪里，如何检查服务是否正常，如何重启服务，如何调整应用级参数等。
（3）交易级：能知道如何查到某支或某类交易出现了问题，是大面积、局部，还是偶发性问题，能用数据说明交易影响的情况，能定位到交易报错的信息。
这里最常用的方法就是数据库查询或工具的使用。
知道最重要的交易如何检查是否正常，重要的定时任务的应急处理方案，比如开业、换日、对账的时间要求及应急措施。
（4）辅助工具的使用：有时候，需要借助一些工具或自动化工具辅助分析并应急，这时需要有辅助工具如何使用的方法。
5）沟通方案：沟通方案涉及通讯录，包括上下游系统、第三方单位、业务部门等渠道。
（6）其它：上述5 点内容如何都完备，相信这个应急手册己可以解决80%的故障恢复工作2）应急方案是一项持续的工作有了应急方案，如何让运维人员持续去更新是难点。
我认为要解决这个难点，需要先让运维人员经常使用这个手册。
如果一个手册没有场景可以用，那就需要管理者为运维人员创造机会去使用这个手册，比如应急演练。
3）关注运维人员对应用关键信息的认识前两点关注了手册，最后一点我觉得有必要关注使用这个手册的人。
有些运维人员认为应用运维人员没有能力去把应用系统本身的内容了解得很透彻，所以应用运维人员在故障处理过程中的地位很尴尬，运维人员掌握操作权，但却不知道应该操作什么。
对此，我认同应用运维人员不需要掌握应用系统的业务功能，但我觉得就对应用系统本身来讲应用运维人员需要具备以下最基本的能力：（1）知道应用系统这个是干什么的，基本的业务是什么；（2）知道应用架构部署、上下游系统逻辑关系；（3）知道应用下的服务的作用、端口、服务级的应急处理，日志等数据信息如何找到并简单定位。
（4）知道应用系统重要的时间点及任务，比如开业、停业、换日、定时任务的时间点以及如何判断这些任务是否正确（5）知道最重要的几支交易的流程；（6）知道常见数据库表结构，并能使用。
4、智能化事件处理处理方法如下图（详细的智能化涉及监控、规则引擎、配置工具、CMD、B 应用配置库等模块协同工作，具体介绍后续分析）。
