过程，故障和问题可用帮助开发和运维的管理者提高整个团队的效率，知道如何解决开发和运维过程中出现的事件。

过程

在谈过程之前我们先来看一个例子。小张进入新公司，在他正式工作之前需要熟悉公司的软件开发环境，一位同事告诉他如何安装开发环境以及如何配置代码访问地址还有各种的服务器地址。如果每次有新人入职，这位同事都要这么做，那么效率就低下了。大家可以回想一下我们在开发过程中都会遇到类似的问题，大家看起来很忙碌其实做了很多效率低下的事情。如果提供一个给入职员工“软件环境配置手册”让手册上面告诉他标准的安装步骤和每个步骤可用资讯的同事，这种行为就可以提高效率，减少新员工入职花费的资源和时间。这个环境配置手册就是软件开发中的一个“过程”。在软件开发过程中会有很多像上述一样需要重复完成的工作，这些工作内容大致差不多。例如：安装环境，编写代码，签入代码，发布应用等等。这些约定俗成的操作我们都可以成为一个一个的过程。作为团队的管理者，我们可以对这些过程进行定义，甚至是标准化，为的是提高整个团队的生产效率。

过程就是把本来已经固化的操作步骤和涉及到的相关人，通过经验总结的方式按照一定流程组合起来，组成有先后次序以及对应相关人的文档。所有的执行该工作的人都按照这个过程文档来做事。团队的成员都可以来维护和生成这个的文档。

大家可以根据自己团队的情况，定义小而美的过程文档。可以根据产品，开发，质量来分类。对每个分类进行编号，每个节点编号都对应一个或者多个过程文档用来协助开发。根据个人经验团队达到10人以上的时候过程文档就可以很大提高生产效率。这些文档可以维护到团队自己的wiki上面，现在有很多工具帮助我们完成这些事情，例如：confluence，石墨文档。都是在线的文档，方便成员的查看和修改。

故障

故障的定义就是“任何降低服务质量的事件”。例如：服务不可访问，程序响应延迟，服务器挂掉。对于故障的管理我们需要遵循以下几个步骤。

D（Detect）检测：通过监控或者与客户联系来检测故障的发生。

R（Report）报告：报告故障发生的具体情况，这里可以根据故障的严重级别分层级报告给不同的人或者部门。如果小的故障可以在组织内部解决，大的故障需要升级让更高的负责人知晓。

I（Investigate）调查：调查故障，并且列出接下来需要做些什么。这里需要开发和运维的同事合作完成。

E（Escalate）升级：如果故障在短时间无法解决，需要将故障升级，让更高级别的经理和部门知道。同时请求更加广泛的援助。

R（Resolve）解决：解决故障，并且记录解决故障的整个过程。可以在每天的会议上作回顾和推进。

问题

问题简单的说就是“故障的根源”。我们可以回想一下在我们处理故障的时候，比如某服务挂掉，一般的思路是分析具体什么问题导致的，这个问题就是“根源”。但是，这样的分析往往是非常花费时间的，实际情况这个服务可能对应的业务很重要，需要马上恢复，这时我们往往会采取更加快捷的方式恢复服务，例如重启服务清除服务缓存等措施。这样的动作可以在最短时间恢复业务。但是，如果要彻底杜绝此类问题再次发生，我们就需要做深入的原因分析，例如：服务挂掉的原因是日志磁盘写满造成的（我的假设）。那么我们就需要对日志的写入以及清除做后续的解决方案。只有对根源问题的彻底解决才能让此类故障不再发生。还有一种情况这个故障是有多个问题造成的，或者一个问题造成了多个故障。这里都需要我们做深入的分析，但是这些分析都是需要时间的，显然在业务高效率和高可用的今天是无法给我们太多的时间。这也就是为什么需要在故障解决之后，要做问题分析的原因。从另一个维度来看，故障是紧急的事情，问题是重要的事情。

故障和问题的生命周期

故障和问题是相依相生的，故障是问题的表现，问题是故障的根源。故障紧急，问题重要。

从上图的故障，问题的生命周期可用看出。当出现故障的时候就出现了问题，当故障解决以后该故障是不能关闭的。只有问题，定位并且解决关闭以后，这个故障才能被关闭。也就是说根源的东西解决了，这个故障才算完全解决，否则还有再次出现故障的可能。

总结：通过过程定义开发过程中的标准化动作，通过故障和问题来解决开发运维中出现的事件。故障是表现，问题是根源。