When you wake up, the world changes a lot? Bugs abound? Don't panic, clear your mind, and walk.
Statement: The blogger is also very confused about how to solve the problem after being invaded. Today, I read the post of Vyou, and shared my feelings with you.
Attached is the sorting idea:
Problem finding stage
After visiting our application, we found that the reaction speed was very slow. The first reaction was: 1. Is our number of users so large? 2. Is our server capacity enough? 3. Is it a circuit problem? 4. Does the code write inefficient cyclic code? 5. Is it ddos? 6. Was it invaded?
If there is a hypothetical problem, then it should be a bold verification.
Verification stage
Obviously, our first reaction was to think about question 1 and question 2, so we immediately judged the number of users and the capacity of the server through the background.
After confirming that the traffic problem is not caused by the user, you can eliminate problem 1.
After checking the server capacity, it can be ruled out that if the current server is redundant under the current user volume, it can be ruled out that the problem 2
Is it the line problem? This is not conclusive for the time being, unless you just received the relevant information. So we can only try to solve the problem 4
Check the time log of code running to determine the efficiency of the code and whether it affects the operation of the current server. If there is any problem, it can be listed in the TODO table after it is found that it does not affect temporarily, and time can be taken to improve it (usually pigeons). Then the problem 4 can be eliminated
Next, we can only look at the traffic. Judge the traffic problem through the traffic statistics background. If there is a problem with the traffic, you can judge whether it is a real user or a fake user. If there is no problem, we will rule out the possibility of doss
If there is no DOS, but the server is still half dead, you can only check whether there are any exceptions in the server, such as CPU percentage, abnormal traffic, etc. If there is no problem, it is the circuit problem.
Follow the above process step by step to solve the problem.
Midfield summary time
Of course, after I wrote here, I began to reflect on my own way of dealing with the problem. I found that I was really at a half baked level and used the most laborious way to deal with the problem.
In fact, there is another way of thinking:
I found that the server was slow,
1. Go to the server to determine whether the slow is caused by internal reasons of the server, that is, check the CPU operation and memory usage.
2. If there is no problem with 1, you can look at your own code cycle problem and get the database problem
3. If there is no problem in 1 and 2, it is a problem in the network. Then it can be determined that the problem should be in the network, so as to quickly locate the problem.
End
There are many ways to deal with problems. Finally, you should always clear your mind before you start. Don't do it like me, regardless of 321.
