工作了有一段时间了，也解决了些技术问题，有些已经写在了blog上。
今天我不想谈具体解决了什么问题，想探讨下解决问题的过程，这是个软素质，不比技术弱多少。
首先我个人觉得，解决技术问题需要有三个过程。
1. 发现问题
2. 定义问题
3. 解决问题
# 发现问题
发现问题的人，可以是产品、可以是技术、可以是运营。
发现问题后，技术人员需要根据问题去跟进，发现出现问题的原因。
导致问题的原因可能有多个，我们逐个找出来，为后面定义问题奠定基础。
# 定义问题
发现问题并定位出问题后，我们需要的是定义要解决的问题。
上面说了，导致问题的原因可能有多个，我们需要根据问题的重要程度去分清轻重缓急，定义出所需要解决的问题的边界。
毕竟 人的精力是有限的，我们需要将有限的精力投入到更大的产出比上去。
比如运营发现server启动时间过长了，这只是个现象，我们需要根据现象去找启动时到底什么原因引起了服务恢复时间过长。
1）机器不行
2）io 密集
3）cpu 密集
4）server 有 bug，比如死锁了？
在这个问题上，我们需要根据问题，找出解决的方案来，并评估各个方案的实现代价。
一般来说，和你技术Leader讨论，准备解决方案以3个为宜，描述好优缺点，让他们给予一定的参考（包括公司资源、实现难度、可扩展性等方面）、
# 解决问题
着手实现的过程中，需要考虑有如下几点
1）时间节点
问题的解决是有时间节点的，时间节点的考量影响着方案的解决，比如C++可能重，脚本语言可能更快捷些。
2）可扩展性
实现的方案具有一定的扩展性，在时间节点满足的情况下，适度给予一定的抽象性，以满足未来的需求
3）健壮性
主要是程序的容错性，程序不可能没有bug，如果出现了bug该怎么办。
有两个思路，一个是通过代码层面尽可能的容错，考虑各个潜在的边界，代价较高
另一个是最多服务节点备份、服务快速重启恢复等策略将损失减少到最小。
4）可评估性
问题怎么才算解决？解决到什么程度，需要有具体的方法。
我这边遇到的有两种，一种是运营观察现象（问题被解决），一种是程序自己打日志
a）如果是一个新的需求，则可以通过日志的方式（有的产品会给出具体日志的统计需求，有的不会）
b）如果是旧问题的修复或改进，则可以通过一些有用的日志来评估。
通过上面的分析，大家可能发现了，解决问题只占一个项目的一部分。
有些技术人员往往看中了实现，去解决问题，说自己功劳大。但在解决问题上，有大量的工作需要与他人协助完成。
在一个公司，往往定义问题的人不需要太多，真正解决的问题的人，其实也不需要太多，但需要精进强干，因为他们负责这系统的实现，
一个坏的实现，临时解决了一个问题，但却会引入更多的新问题。我想有些公司，控制面试的门槛，原因也在于此。
希望今后以定义问题人的心态去解决问题，用解决问题的四个原则去解决解决问题。