"Experience" How to solve technical problems

Worked for some time, but also solved some technical problems, some have been written on the blog.

Today I do not want to talk about the specific solution of what the problem, want to discuss the process of solving the problem, this is a soft quality, not less than the weak technology.

First of all, I personally think that there are three processes needed to solve technical problems.

1. Problems found

2. Defining the problem

3. Problem solving

# Discover Problems

The person who discovers the problem can be a product, can be a technology, can be operational.

After discovering the problem, the technician needs to follow up the problem and find out the cause of the problem.

There may be multiple causes for the problem, and we'll find out each one, laying the groundwork for defining the problem later.

# Defining issues

After discovering the problem and locating it, we need to define the problem to be solved.

It says that there may be multiple causes for the problem, and we need to prioritize the problem to define the boundaries of the problem that needs to be addressed.

After all, the human energy is limited, we need to put a limited amount of energy into greater output than up.

For example, the operation found that the server boot time is too long, this is only a phenomenon, we need to look for the phenomenon to start when the cause of the service recovery time is too long.

1) Machine not

2) IO-intensive

3) CPU-intensive

4) server has a bug, such as a deadlock?

On this issue, we need to identify solutions to problems, and assess the cost of implementation of each scenario.

In general, with your technical leader discussion, prepare the solution to 3 appropriate, describe the advantages and disadvantages, so that they give a certain reference (including company resources, difficulty, scalability, etc.),

# Solve the problem

In the process of implementation, the following points need to be considered

1) Time node

The solution to the problem is a time node, and the time-node considerations affect the solution, such as C + +, which may be heavier, and the scripting language might be quicker.

2) Scalability

The implementation of the scheme has a certain degree of extensibility, in the case of time node satisfaction, the appropriate to give a certain degree of abstraction to meet the future needs

3) Robustness

The main is the fault tolerance of the program, the program can not have no bug, if there is a bug to do.

There are two ideas, one is to pass the code level as far as possible fault tolerance, consider each potential boundary, the cost is higher

The other is the maximum service node backup, service fast restart recovery, and other strategies to minimize the loss.

4) can be evaluated

How is the problem solved? To what extent, there is a need for specific methods.

I have encountered two kinds of, one is the operation observation phenomenon (the problem is solved), one is the program itself to play the log

A) If it is a new requirement, it can be logged (some products will give the statistical requirements of the specific log, and some will not)

b) If it is a repair or improvement of an old problem, it can be evaluated by some useful logs.

From the above analysis, you may find that solving a problem is only part of a project.

Some technicians often fancy the realization, to solve problems, to say that their credit is big. But in solving the problem, there is a lot of work to be done with the assistance of others.

In a company, people who often define problems do not need too much, really solve the problem of people, actually do not need too much, but need to be diligent reorganising, because they are responsible for the realization of this system,

A bad implementation temporarily solves a problem, but it introduces more new problems. I think there are companies that control the threshold for interviews, and that's why.

We hope to solve the problem by defining the mentality of the problem, and solve the problem with the four principles of solving the problem.

"Experience" How to solve technical problems