运维常见问题及解决策略

运维常见问题及解决策略

运维工作是项目工作的延续，是公司项目管理系统中的最后一环。接手运维工作也有一段时间了，遇见过各种各样的客户，处理过各种各样的问题。在解决问题的过程中，发现每类项目都会有相似的问题出现，比如安全漏洞问题、后续系统接入的协助问题、产品出现BUG等等。那么，每一类问题也都有它对应的解决方式和注意事项。

本文将对运维工作中常见的问题进行分类，并总结常用的解决办法和注意事项，同时为制定运维管理制度提供思路以及解决办法。

运维工作理解

与一般工作相比，运维工作的特别在于突发性、时间不规律性和紧迫性。运维工作通常是出现问题后由客户反馈而来的，问题都是突然发生的且没有预兆，那么出现问题的时间就更是不确定不规律了，即便是运行了一段时间的系统，也可能突然触发一些未知的BUG，由于这些BUG会影响到生产环境，也就体现了运维工作的紧迫性。

由于是生产环境，每次升级替换都需要在客户使用频率低的时候进行调整，通常是周末或者半夜的时候，所以熬夜加班也是运维工作必然面临的挑战。

1工作目的

项目运维的目的要从两个层面来理解，一方面项目运维是项目实施的必要环节，开始于项目上线确认之后，截止于公司与甲方的合作终止，主要是为了延续项目价值，保障收款，积累产品经验等等；另一方面是保持与客户的沟通协作，为后续项目的持续开展提供基础，同时工作中的一些成果可以考虑作为人天抵扣到后续项目中。

2工作要求

对待客户要注意能够解决的事情尽快解决，当下不能解决的事情要做好工作排期，对客户生产环境影响大的问题，要第一时间反馈给公司领导寻求资源，同时做好客户的安抚工作。

由于运维人员对于程序的把握未必是那么到位的，很多时候需要记录问题并寻求资源。运维工作需要的详细记录包括提报时间、问题类型、解决耗时，交互人等等，一些影响比较大的问题，要做情况说明，记录下当时的事情经过，改动事项等等，这些都会为后续的运维以及产品改进提供思路。

常见问题分类

在运维过程中，客户主要问题分为两类，咨询类的问题主要是客户在产品的基础使用以及特定业务场景的灵活使用上遇到的问题；产品BUG报修类的问题根据产生BUG的原因可分为操作问题、环境问题和产品问题等等。

1方案咨询类

此类问题在项目交付之初比较常见，以产品的基础使用为主，也有一些是新业务场景不知道如何适配。在这个阶段，客户通常只有对场景的描述或者是思路，需要我们据此给出具体的解决方案。

这个阶段对于公司的价值体现在扩展产品的业务适应性，记录下产品适用的主要业务场景以及各类业务场景的解决方案，在宣讲时可以作为问题提问宣讲人。

2项目协助类

由于公司承接的大多是集成类项目，因此很多时候是以运维作为中转的核心，因此当有新系统接入或者是第三方系统改造时，需要运维协助提供数据或技术支持。

在这个阶段对于公司的价值主要是掌握、验证第三方对接的技术，提升水平。

3产品BUG类

这类问题伴随项目运维的整个周期，产品BUG类问题与产品改造类问题非常相似，很多时候产品改造本质上就是对BUG进行处理，这里要注意的是，对于项目问题只做项目级调整，产品级调整要根据公司的战略来执行。

在这个阶段对于公司的价值主要是测试产品BUG，修复产品，提升性能。

4产品改造类

产品改造类要区分于产品BUG类的是，产品改造类主要是客户针对实际场景，对于产品提出了新的需求。产品改造类问题的解决通常是在与客户需求确认过程中，提出替代性的解决方案，通过简单的开发来实现的。

在这个阶段对于公司的价值主要是扩展产品功能，提取集成需求，为后续产品升级迭代提供方向。

问题处理方法

虽然运维问题多种多样，但是每一类都有比较通用的处理方法和注意事项。整体的问题处理要把握一个原则，影响客户当前使用的一定要优先改。客户咨询的问题，给出的答复要需求扩大化；客户提出需要后续协助，能给方案的就先不要自己动手；产品改进类的问题，收集意见及时反馈，尽量不要做调整。

1方案咨询类

咨询类问题默认为高优先级，因为是即问即答的形式，解决的基本点是指导客户工作，而不是参与具体工作。

同时需要注意的是，项目运维阶段不是项目实施阶段，对客户的想法要适当予以婉拒。如果全盘接收，咨询类问题就很容易变为改造类问题，在运维阶段实施产品改造，如果没有后续项目落地，通常是难以收取费用的，因此要特别注意。

2项目协助类

协助类问题默认为中优先级，解决的基本点是客户要有明确的工作意向和思路，我方只是参与部分工作，即我方不是工作的主导部门。

项目协助类常见的问题有项目上线后第三方系统接入、部分项目资料的索取、第三方系统出现问题协助定位等。处理这类问题时要注意，有了结果要第一时间通知客户，以便客户可以继续推动后续工作的开展。

3产品BUG类

产品BUG类问题默认为中优先级，其中影响客户登录的问题，默认优先级是高。解决的基本点是先恢复后修复，一定要保证客户能够正常使用，哪怕是通过屏蔽功能的方式，也要先保证客户的使用，后续再进行调整。

对于产品BUG类问题的即时修复手段主要有屏蔽页面功能、调整数据库数据（修改人员状态）、集群改单机等等，后续要有跟进和落实，针对BUG要制定解决方案，审核通过后再进行修改，修改内容及方案要统一在SVN留存。

4产品改造类

产品改造类问题默认为低优先级，原则上已验收项目不做产品改造，如果有重大安全隐患或者客户比较重要，可以考虑进行产品改造。

产品改造一般是要有商务参与的，但是这部分工作不需要运维人员来考虑，唯一需要考虑的是，改造是项目级改造还是产品统一升级，相关的实施办法与BUG修改要一致。

汇报交互机制

上述问题解决的过程中，一定要保持适当频度的汇报，汇报的对象主要是运维负责人和公司领导。具体包括日常汇报和重点汇报，日常汇报是定期对运维工作的汇报，重点汇报是对高优先级内容的汇报，以及涉及商务问题的请示。

1日常汇报

日常汇报分为日汇报和周汇报，日汇报有专人负责，每天统计运维情况，整理成EXCEL进行汇报，周汇报是对一周内运维情况的总结，针对运维中的重大事宜，要在会议穿透时进行汇报，包括当前的解决进度、解决方法、解决过程是否有突发情况等。

此外，计划定期对项目运维进行一次核定，初步计划是每季度一次，包括对项目运维等级的评定、项目运维情况统计、产品问题反馈等等，具体的汇报格式尚未确定。

2紧急汇报

紧急汇报是针对两种情况，一是影响客户使用的，没有替代方法且自己难以解决；二是对客户影响较大的，比如单点登录异常、系统无法登陆等等。

紧急汇报主要是申请资源，请求协助解决问题，因此一定要快速、简洁、准确地反馈问题。在解决问题后，要向协助人员反馈问题已解决。对于解决问题的过程要有记录，记入重点汇报的工作中。

3重点汇报

重点汇报是对高优先级内容的汇报，必须及时通知到运维负责人及公司领导。例如客户门户登录异常、业务集成同步中断、客户有新的需求需要商务沟通等等。对于修复过程超过0.5天的重点问题，要给出书面记录，记录修复过程以及解决方案，上传至SVN作为备忘。

项目运维工作是项目实施不可或缺的步骤，想要做好运维工作就一定要做到有章可循，这就需要大量的工作积累。由于出现的问题大多在生产环境，要求运维人员快速、准确地定位问题，这就导致运维工作交接困难，新的运维人员往往需要一段时间才能适应。不断地总结、分类、梳理运维问题，可以使运维工作在交接的过程中非常顺利，也可以保证项目后续跟进时，实施人员对项目有充分的理解。