Technical support: a technological approach to solving technical problems

Introduction

Any search for a solution to a problem consists of a series of steps regardless of the nature of the problem. Such a technological approach makes it possible to work successfully enough on a problem, even if it is not clear from which side to approach the solution.

Although this article slightly mentions the specifics of local conditions, the process itself is described in a rather abstract way, so it can be used to solve errors in the IT system, at least for troubleshooting consumer electronics, at least for solving interpersonal conflicts ...

Problem identification

It makes no sense to start solving the problem until it is formulated - either the wrong solution is found, or no one needs it. But in any case, the result will be useless, and efforts in vain.

The first thing to do is to identify the problem. Understand what, where and how it works incorrectly. Determine the component of the system that gives an error, get a diagnostic that indicates the presence of a problem.

The result of this step should be the following information gathered:

• Where the error occurred - the name (file) of the form or report, the exact version.
• The error message is literal, a character in a character written with text (for the possibility of a subsequent search, screen shots are not enough for this); if the error is in the log file, then the name and location of the file.
• The environment in which the problem occurred - a productive system, design, test, all of the above.
• Whether the given problem is reproduced, the nature of the reproduction is on all data, on certain data or under specific conditions, a single failure, a floating error.
• The steps that led to the problem, and if the problem is reproduced, they will also be a test scenario.
• Assessing the impact of the problem - the severity of the problem itself and the expected consequences; how many transactions or users are affected; deadlines for decisions and the impact on the closing period; The total amount of transactions affected by VIPs and other factors that are important in the context of the problem.

Information collected should be documented.

The purpose of this step:

• Record the fact of the problem.
• Find and fix the place of the problem in the system.
• The resulting keywords (component name and version, error messages) can be used to search for available knowledge bases - internal systems, Metalink, on the Internet. If a similar problem occurs later, after identifying this new problem, an existing solution should be found with a high probability.

Such a description of the problem is a complete stage of work, the next steps (analysis, search for solutions, etc.) can be continued by another executor or such work can be performed in parallel.

It is easy to assess the quality of this stage. After reviewing this information, you can directly begin to solve the problem, without asking any more clarifying questions.

Problem analysis and search for causes

Once the location of the problem has been identified, you can begin to search for the causes.

Useful techniques in this case are:

• Tracing - allows you to find the code that worked incorrectly or gave an error; will allow you to see that the latter was performed if there is no clear diagnosis of the problem.
• Analysis of the executable code - along with an error message will give a hypothesis why the code does not work as expected.
• Debugging (including diagnostic output) - will allow you to determine whether the assumptions about the logic of work, the values ​​of variables, are met, and to see if the diagnosed piece of code is being executed at all.
• Data analysis (how problem data differs from the rest) - will allow concentrating attention on the code in which the processing of just such different data takes place.

The analysis of the causes and the search for a solution follow the well-known scheme:

• Formulate a hypothesis about the cause of the error.
• We check the formulated hypothesis:
  
  • fix code or data
  • do a test run
• Analyzing the result.
• If the hypothesis is not confirmed - start from the beginning.

The result of this stage should be the found reason for which the problem occurred. The result should be documented.

Documenting the steps for finding and analyzing a problem is also helpful. In the event that a similar, but not exactly the same problem is encountered later, information about such steps will allow for easier analysis - you can take ready-made query templates, skip a number of analysis steps if, as a result of previous work, it was found out that this way is ineffective etc.

Solution preparation

When the cause of the problem is found, it looks for the most appropriate way to fix it. These can be data corrections, corrections in the code, change of settings or, in the most difficult cases, more dramatic changes in the functionality of the system, etc. Some steps can be taken immediately, some (for example, system reconfiguration, functionality refinement, etc.) are left for later. It should not be forgotten that the most appropriate solution may be in an unexpected plane, for example, administrative. The solution to the problem is evaluated by effort, execution speed and efficiency.

It is good practice to document how the problem will be solved, and only then proceed to its implementation, especially if this is not obvious from the context, and preparing corrections will take considerable time.

Naturally, in the preparation process, the solution should be properly tested.

The result of this phase should be a prepared and documented sequence of actions as a result of which the problem will be fixed. Such actions include installing patches, running prepared scripts, manual actions in the system, etc.

If the nature of the problem suggests that the situation may recur, a more universal solution that can be applied in the future with minimal changes is preferred.

Debriefing

After the problem has been successfully solved, the final stage of the work should be carried out. In particular, it is not so rare that at this stage there is really nothing to do. But summing up should be. This stage is aimed at the future - improving the quality and preventing potential problems.

During the final debriefing, the following actions should be taken and questions answered:

• Something was missed or not documented due to lack of time, now you can safely finish everything.
• In the prepared solution for speed, the consequences were eliminated, but not the cause, and the solution needs to be continued (perhaps as part of another task).
• If there was a problem with the data, is there any other data with the same problem that just has not yet been discovered? To correct them now, when we fully understand the problem, is the right time.
• Is there any chance that the problem will recur and will the problem or its consequences cause other problems in the future? What can be done to avoid?
• Is it not necessary to issue a solution to the problem as a universal script, script, write to the FAQ (FAQ) or knowledge base, etc.?
• Should this solution be extended to other instances of the system?

The result of the final stage should be a documented conclusion about what actions should be taken or a decision that no special actions are required.

I would like to emphasize that if no additional action is required, this is also a solution, and it should be documented. Just the lack of final conclusions suggests that the impact analysis was not performed.