技术团队应该如何处理线上故障？

点击蓝字 关注我们

故障产生的原因

1987年IBM的大型机之父Frederick Brooks发表了《没有银弹》这篇著名的论文，同时也在他的知名著作《人月神话》中多次引用了这篇论文中的内容。他把软件开发中的困难分为两类： 

• Essence，可以译为本质困难或者主要问题，指的是软件开发中不可规避的问题。就是软件本身在概念建构上存先天的困难，也就是如何从问题领域，发展出具体的解决方案。 

• Accident，可以译为次要因素或次要问题，指的是把解决方案实施到电脑上所遇到的困难。

他认为软件开发中无法规避的四个特性是：复杂度、一致性、可变性、不可见性。他还归纳了在次要问题上我们取得的进步：高级语言，分时系统，统一开发环境。

 

而论文中所提及的复杂度不仅仅会导致技术上的困难，还引发了很多管理上的问题：

• 它使全面理解问题变得困难，从而妨碍了概念上的完整性；

• 它使所有离散出口难以寻找和控制；

• 它引起了大量学习和理解上的负担，使开发慢慢演变成了一场灾难。

软件系统交付到生产环境后的运行，也往往因为论文中所提及的复杂度、可变性以及不可见性等原因，会隐藏很多在特殊场景下出现的问题而导致故障产生。

两种不同在线系统

在讨论故障之前，我们需要将在生产环境中运行的各个系统进行一个简单的分类：基于互联网架构的在线系统、基于传统架构技术的生产系统。这两种系统的区别有如下几点：

1.响应要求不同

互联网架构的在线系统由于其可能面对的庞大请求和业务交易处理，及其故障产生后可能会带来显而易见的损失影响，所以这种类型的系统对故障的响应要求条件会比较苛刻和严格

而传统架构的生产系统，由于其运行状态是面向一个相对稳定、固定的场景，所以在发生故障之后，对应响应需求与互联网在线系统相比较低。

2.架构复杂度不同

互联网架构的在线系统从第一批互联网系统诞生到目前，经历了非常多的变化。从单体应用转变为基于微服务的分布式计算结构；从单一事物处理模式转变为分布式事务处理模型；从性能上满足单机C10K（单机1万Client在线）转变为需要满足C100K甚至更多的要求。这些都直接导致架构技术的变化，从而带来了架构复杂度的不断上升。

而基于传统架构的生产系统，又因为升级运行场景变化不大，访问量等要求并不高。所以整体系统架构上虽然也有不断地提升和变化，但相较于互联网在线系统又存在一个较大的差距。

如何解决故障

前面我们分析了两种不同在线系统的区别，我们来看看不同的在线系统，如果出现线上故障，应该用什么样的技术处理策略来应对。

 

• 互联网在线系统

因为是在公网上对系统进行开放式的访问，所有互联网的用户都有可能会对该系统发起即时的访问请求。在面对某个单一原因而产生的故障导致系统不可访问或服务不正常时，甚至出现诸如订单价格算错而产生大面积的“薅羊毛”事件发生时，这类系统的第一原则就是：根据评级，即时恢复，而不是定位问题。

也就是说，当一个系统发生故障时，根据相应的故障点情况和影响面情况进行评级确认。如果是高等级故障，则需要第一时间进行故障的恢复，而不是对当下的故障根源进行定位。

 

在处理的过程中，技术团队要与运维团队一起配合。对当前的“故障现场”进行备份和保留，可以是对当前的服务器先进行访问隔离，随后立即进行日志备份、应用备份。与此同时对集群中的服务器进行应用版本的回滚或者降级，保证服务能够快速恢复到之前的可运行状态。

如果是非严重级别故障，未来的损失和影响也不大，可以考虑约定时间的方式进行修缮处理。否则还是要进行回滚或降级处理，留给技术团队更多的妥善处理时间。

 

• 传统生产系统

这种系统在发生线上故障时，大部分的情况下可能造成的最大影响，是原有的工作过程无法正常推进而产生间接损失。

比如，负责生产计划安排的PLM系统在日常的运转过程中，可能因为某个原因，导致系统运转不正常。过程中可能也会产生一些诸如物料消耗的直接损失，但更多的应该还是工作流程的停滞而导致的时间压力，所以整体损失程度可控。

但有一种情况属于例外，类似“勒索病毒”感染后对系统造成的不可修复性损失，确实会直接导致系统瘫痪的严重后果。

 

针对这种类型的系统，在处理过程中，有几个重点步骤。

首先就是备份，这个对于任何系统都是一样。只有通过即时备份，才有可能对未来问题的解决和降低数据丢失产生的损失起到关键性的作用。

其次是根据系统业务特性情况，与系统的技术支持团队进行寻求协助。如果是一般常规问题，或许会立即获得解决的方法和步骤；如果是稍微严重的问题，也可以获得技术团队的支撑直到问题被解决。

关注我们，了解故障处理