IT系统运行维护方法及策略

IT 运维服务体系的建议追从“易使用、易汇总、易管理”的先后顺序，由重到轻的依次解决客观存在的问题，以便最大程度的加快 IT 运维服务体系的建设的目标。运维服务体系由运维服务制度、运维服务流程、运维服务组织、运维服务队伍、运维技术服务平台以及运行维护对象六部分组成，涉及制度、人、技术、对象四类因素。

运维制度是规范运维管理工作的基本保障，也是流程建立的基础。运维服务组织中的相关人员遵照制度要求和标准化的流程，采用先进的运维管理平台对各类运维对象进行规范化的运行管理和技术操作。

IT故障定位指诊断故障直接原因或根因，故障定位有助于故障恢复动作更加有效。故障定位通常是整个故障过程中耗时最长的环节，定位的目标围绕在快速恢复的基础上，而并非寻找问题根因，后者由问题管理负责。通常大部分可用性故障，要借助运维专家经验的假设判断或已知预案的执行得到解决，但仍有部分故障，尤其是性能、应用逻辑、数据故障需要多方协同与工具支持。

在数据中心里，很多技术运维人员往往能够对已知的故障有敏锐的发现能力，可以根据自己遇到过的故障现象快速找到问题的根因。更为资深的专家能够从一些普适性的故障现象中通过系统的内在原理猜测出某个现象背后可能的原因。根据故障的表象判断可能的诊断路径是一个运维技术专家所必须具备的能力，这些能力往往是通过大量的运维案例不断的积累下来的。这也是专家有别于普通运维人员的地方。准确的数据采集实际上也是需要依靠运维知识的。

例如，如果我们要做故障分析，其中需要使用到CPU资源的使用情况，我们该如何采集数据呢？找某段时间里CPU的使用率的平均值还是最高阈值？如果出现CPU使用率100%就一定有问题吗？实际上并不是这么简单的，CPU突然出现的尖峰实际上大多数是无害的，不一定会对我们的系统产生不利的影响。只有长期CPU使用率都处于接近高位，此时CPU才有可能存在资源不足的瓶颈，影响系统的性能。

一、运维处理原则

IT系统运行过程中，难免会出现问题或故障，故障处理的原则归结起来就是两个：

⚫ 所有措施或方法都是以迅速恢复业务优先

⚫ 系统BUG或匹配需要及时升级并优化

1.1. 恢复业务优先

恢复业务优先是指，不管在任何情况下，也不管任何级别的故障，都要先做到恢复业务，这个和故障定位不同，也有很多人会产生歧义，觉得如果不找到问题的根源，如何能恢复业务，下面我举一个例子简单的例子：

如果应用A和 B系统联调时，如果最终是失败的，这时我们要如何寻找问题并解决？

（1）从A应用的服务器去ping B应用的网络，如果端口，网络联通，那么直接绑定B服务器的hosts。

（2）排查问题，寻找A到B之间会经过哪些环节，找到其中的出问题的环节，包括跨服务器区、跨网段等，比如HA连接异常，进行重启或者扩容恢复。

通常情景，第1种方法时间会短，如果A和B之间是跨机房访问，那么方法一排查时间会更长，虽然破坏了A到B之间的架构平衡，但是能马上见效，这就是我们所说的以恢复业务优先。

1.2. 及时升级

这个比较好理解，任何故障在发生时，对故障的影响任何人只能做一个简单的预测，所以要及时升级到你的领导那里，让他掌握第一手的信息，协调资源，如果有如下情况，那么必须马上上升：

非常重要的业务的严重以上的告警故障，比如网银交易系统、主机CPU超阈值等等；

2. 有明确业务影响，例如双11或618促销、国庆或重要节假日等业务突发指标波动；

3. 处理时效明显超长（时效参考故障处理时效定义）；

4. 安全升级包或设备或方案厂家已经大的升级系统；

5. 系统性的问题、监控中心或者关联系统已经关注到并受到这个故障影响。

二、运维方式

根据运维工作的需求和运维响应时间要求决定建设完整的运维计划并确定服务的标准，以现场软硬件巡检为主，增强运维计划的执行力，通常数据中心等的运维工作流程如下：

（1）建设完整的运维计划：在整个运维过程中，计划是整个工作流程的核心，按照计划先行的原则，依据本年度工作计划制定分项工作计划和时间维度计划，并按流程、按计划进行实施和保障。

（2）现场巡检的重要性：现场巡检计划是运维工作计划的重点，通过现场巡检能够发现系统薄弱环节、关键业务节点、存在的隐患，尤其是对制定应急预案及备品备件计划至关重要。

（3）执行力的重要性：运维计划的执行是运维工作的重点，在运维计划执行过程中，应严格按照流程规范开展运维，并注重控制以降低运维风险。针对运维执行情况，应定期向用户进行反馈。

（4）运维服务标准：签订售后服务承诺函，与客户约定服务级别，对于所承诺的服务级别包括提供的资源（备品和备件等）、提供的方案应严格按约定执行

三、运维处理方法论

IBM在云时代的新运维方法论叫做CSMO（Cloud Service Management and Operations），这个方法论有四个主要的来源：

第一，是ITIL特别是ITIL 4，ITIL4是国际IT服务标准在新时代的最新版本，也是面向敏态IT的全新版本，它在囊括了ITIL V3的特色基础上加入了对于DevOps等的支持；

其次，是敏态IT运维方法论SRE（Site Reliability Engineering，站点可靠性工程），这是互联网及公有云的运维服务方法论；

第三，是Infrastructure as a Code即将基础设施自动化过程、运维以及全球最佳实践和案例等进行整合；

第四，是加强了运维与开发的关联，将IT服务管理的组织、文化、流程与DevOps进行结合。

运行维护服务包括，信息系统相关的网络设备、安全设备、机房基础设施、主机设备、操作系统、数据库和存储设备及其他信息系统的运行维护与安全防范服务，保证用户现有的信息系统的正常运行，降低整体管理成本，提高网络信息系统的整体服务水平。同时根据日常维护的数据和记录，提供用户信息系统的整体建设规划和建议，更好的为用户的信息化发展提供有力的保障。

用户信息系统的组成主要可分为两类：硬件设备和软件系统。硬件设备包括网络设备、安全设备、主机设备、存储设备等；软件设备可分为操作系统软件、典型应用软件（如：数据库软件、中间件软件等）、业务应用软件等。

故障处理一般会分为三个阶段，故障前，故障中和故障后，故障前是指故障的定位分析，故障中是指故障处理过程，故障后是指故障总结，故障总结很重要。

（一）从故障服务来看运维处理故障方法

如果从故障服务来看，运维恢复业务最重要的三个方法是：隔离重启降级

（1）隔离

隔离是指对故障的对象从集群中抽离的过程，目的是让故障对象不在提供服务，隔离的方法包括以下两种，按照常用频率排序：

调整上游权重为零，如果架构上有自检测机制，那么也可以直接停止故障对象的服务，让上游健康探测时效。

通过绑定hosts或者配置路由的方式，绕开故障对象。比如智能路由管理域关闭某一条线路。这里需要注意的是，防止雪崩效应。

（2）重启

重启包括服务重启和服务器重启（os重启）两种，在发生故障中，任何中涉及到的环节，都可以重启来完成，重启的一般顺序是，故障对象>故障对象上游>故障对象下游，一般离故障对象越远，重启顺序越靠后。

（3）降级

降级是指为了防止产生更大的故障所采取的一种预案，一般而言，降级一定不是当下生产的给用户的最优状态，即使没有技术影响，也会或多或少带来一些业务的影响，虽然用户可以通过其他方式临时回复一些业务，但会带来不好的用户体验和一些用户影响。

降级不仅仅是运维的事情，要联合业务研发或者说推动业务研发一起去实施，因此做任何一个项目时，首要考虑的不是这个项目能取得多少业绩，而是要考虑的是，如果出现异常怎么办？

项目如此，核心应用和组件也要如此，作为应用负责人，必须要考虑的是，如果这个对象发生重大故障时，是否有预案可以使用，并且要把这些预案触发条件，执行人等都要明确下来。

降级，从某种角度来说，是运维的最后保命手段，必须要注意。

上述操作方法，尤其是重启和隔离有一个重要的前提，那就是，对象必须是无状态的，如果需要开发重试，那么要求必须是幂等的。对象无状态除非是非常特殊的业务，可以临时存在外，其余是不可以的，所以生产上对象应该只有三种状态：

无状态，这个要占大多数
临时有状态，需要整改
有状态，少量的

（二）从故障影响方去看运维故障处理方法

首先，故障处理过程中会遇到系统故障所涉及的各个内部或外部组织架构，故障处理一般需要有以下三类人同时进行：

⚫ 信息传递者：他们的职责是对故障处理，故障定位传递有效信息，同时对外部传递故障进展信息；

⚫ 故障定位者：他们的职责是当故障处理者方法失效或者需要查找问题根因时，解决故障；

⚫ 故障处理者：他们的职责就是尽快恢复业务。

对于IT运维系统来说，这三类人往往不会同时出现，比如在凌晨值班时，只需要故障处理者处理即可，恢复业务后，第二天由故障定位者去找根因及优化措施。

另外，一个故障发生后，影响方会分为两类：

（1）内部用户

内部用户包括内部应用自身调用问题和内部使用人员发现问题，方法类似外部用户。

（2）外部用户外部用户的处理会比较麻烦，处理的思路是，如何把外部用户转变成内部用户，比如，一个供应商打不开公司的网站，这时要做的是有两个方面：

自己在本地模拟是否可以重现，如果可以重现，那么就不是用户到IDC之间公网问题，是内部系统问题，那么变成内部用户处理。
如果自己在本地模拟不能重现，那么多找几个内部用户模拟，防止自己环境问题，同时，让用户进行hosts绑定到其他入口，排除DNS，一些外网链路问题，如果这时用户在绑定hosts后，访问正常，那么恢复业务，同时可以确认大概率是外部问题。

如果上述两个方面都不行，那么就比较麻烦了，这时要收集一些必要的外部用户信息才能进行处理，比如出口IP，所用客户端版本等等，这里建议收集信息有个模版，一次性完成，因为外部用户处理时效往往会花在沟通成本上。

打赏