今天处理了一个问题，最后的结果是：做了服务器重启，然后问题就修复了。听起来好没有技术含量的事情。
但是这不是我的风格，我觉得可以就这个看起来没有营养的事情来掰扯掰扯，说点自己的感悟。
第一，这几乎是我们绝大多数人工作生活的一个现状
这个问题可以用很多方式来进行验证，那就是你工作的价值，很多人感觉好像工作里面应该没那么多的问题，应该不会很麻烦，应该会很顺利，或者说这个事情应该很轻松，但是我们似乎也一直很忙，但是最差的状态应该就是不知道忙了一天到底忙了些什么。
就拿今天的这个问题来说，我们发现有一个实例的备份还没有完成，就做了进一步的排查，发现服务器出现了大量的swap,但是实际的swap空间却很充裕，于是查看内核参数，进行调整，然后进行相关实例的重启操作，但是依然不奏效。当然在这个过程中还碰到了很多次命令执行hang住的情况,看起来好像简单的事情，就这样前前后后操作，一个小时就过去了。这几乎就是我们大多数人的工作状态，怎么理解呢，有以下的几个方面来说明。
- 问题是问题，但是不够通用 这个问题从现象来看，是属于比较特殊的，就算解决了，感觉价值和意义也不是很大，但是从结果导向来看，还是要解决，所以需要收起那份浮躁的心，先解决问题再说。
- 会占用很多碎片时间 整个过程的处理会有大量的碎片时间，因为这是一个有多套环境混用的服务，所以会有很多的实例，数据库都会有所不同，你就需要分析一下，到底是哪里出了问题，有没有可能是哪个服务存在瓶颈导致。碰到你不熟悉不了解的环境你需要更多的信息，就需要找更多的人来确认和理解，但是这个过程是异步的，也就意味着你刚想要了解一个信息，但是半个小时过去了，你可能不需要了，或者有了新的idea，你需要逐步去理解本来看起来简单的问题。
- 问题的处理过程不是你一个人就能够控制 如果你得出了一些结论，觉得可以做了，可以修复了，那可不意味着你能够秒级操作完成，因为整个环境是混用的，到底谁在用，谁在维护，很难让所有人都实时支持你，所以你的一个看似简单的需求要得到快速响应是很难的，在工作日通常都是以10分钟为单位计算，而一旦离开公司，几乎都是按照小时为单位计算的。
- 需要按照流程办事 做事情，处理问题还是得按流程办事，哪怕看起来很简单的意见事情，你看到简单，只是因为你理解的简单。流程应该是一个很重要的一环，比如你要做服务启停，不是想做就做，而是要有一个发起流程和相关的告知，这样就是一个处理<->反馈的动态过程，能够互相印证。
- 需要确认A是A 我们工作生活中的很多事情都需要做A是A的确认，这个环节不可避免，一来是环境多了我们记不住，而是我们哪怕记住了，但是环境变化了，我们没有及时发现，归根结底就是容易出故障。
- 问题的影响搞不懂，说不清 重启服务这种事情影响有多大，有时候都很难说的清楚，你觉得你这一环搞定了，但是其他环境可能直接就雪崩了。问题的影响到底有多大，有上游环节和下游环节，这个确认工作也需要多方配合。
第二，要证明错的是错的其实很难，如何证明正确才是真的难
不知道大家有没有发现，我们要证明一个东西是对的时候好像还比较方便，因为我们认识问题的方式大都是按照这种形式来进行的，但是我们处理问题的思路似乎是相反的。
有时候我们要证明错的是错的其实很难，而要更进一步，证明如何正确才是真的难。
就拿这个重启服务的案例来说，我们已经有很多的现象和背景证明服务存在问题了，有系统负载，系统的响应，但是服务的CPU似乎不高，IO消耗也不高，内存剩余尚可，你怎么能够很清晰的证明出来这个系统负载和他们之间的直接关联呢，在这种情况下其实是很难的，即证明错误是错误是很难的，要说这个问题是个问题，无非是配置问题，环境问题，软件bug等，但是如何修复，这里似乎能给出的答案就很难了，
整体上来说，如下的三个方面应该是分析问题时常用的思路和方法。
- 内核配置
- 数据库参数
- 操作系统命令分析
我想我们是很难得出一个重启服务器就能够一定解决问题的结论的。
运维常见三板斧是：重启，重装，回滚。看起来都是很简单的处理，但是里面确实蕴含了一些哲理。
当然这个三板斧不是我说的重点，我来说下三观正的三板斧。
第三，要有正确的三板斧
这三板斧可谓是：可视化，自动化，智能化
当然基础的前提是标准化。我们处理的服务对象如果没有标准化的基线，那么很可能就是千人千面，千人千面带来的问题就是定制化程度高，缺少统一的处理策略，或者覆盖面太大，在这个层面能够尽可能做到千人一面是一种很大的进步。
而在这个基础上可以再去延伸，逐步实现千人千面，这就是服务的属性了，也就是提供更多实用价值的一个入口了。
所以综合来看，这个重启也不吃亏。
