Date: Thu, 28 Mar 2024 14:50:57 +0100 (CET) Message-ID: <404826598.3933.1711633857049@static.9.57.119.168.clients.your-server.de> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3932_1111334142.1711633857046" ------=_Part_3932_1111334142.1711633857046 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
WORK IN PROGRESS!!
This page is actually heavily under work, so please keep coming back con= sulting it until the present warning has been removed.
Table of Contents
Facing an issue on the Server's side is not that different that dealing = with problems on the client's one. We are going to use the very same techni= que to troubleshoot the Server that we use to do the clients. Thus also in = this case we are talking about identifying a problem starting= from an incident, that is its sympton.
On the server it can be easier to spot incident as it's possible to read= documentation about the expected behavior and get fast addressed to the wr= ong one the server is performing. Otherwise it can be difficultier to track= down the problem which originated it.
When facing an issue on the server, please take care to collect as many = data on it as possible, using the classical Kepner and Tregoe Help pro= cess, which lists 5 points:
Define the Incident
Describe the Incident
Troubleshooting
Try to solve the incident supposing th= e most probable cause
If failed at point 5, report the incid= ent to the higher level of problem handling service desk=
The server support is performed by PrivateWave only as the third level, so before addressing a new request make sure you:
collect all relevant information
first attempt to troubleshoot
deeper analysis and performs the troub= leshooting
The communication between the second and the third line is carried out b= y a ticketing service. The second line has to report the issue by filling o= ut all fields of the report properly. The third line has to report back usi= ng the same ticketing service updating the problem status. The ticketing se= rvice will report timings as well and will be used as an incidents/problems= database to be consulted by the second level before escalating the problem= .
This is the first phase of the troubleshooting process. The initia= l entry point is the call of the user reporting an Incident. In this phase = the user describes autonomously the issue(s) experienced and the Help Desk = guide him/her to:
This is a platform specific procedure to guide the user collecting the f= ollowing information:
Server version number
Number of Network Interfaces
Network Segregation configuration
<= /li>Possible route specific configurations=
Short description of malfunction
= li>Server name
Is the device supported?
Is the OS version supported?
Is the application installed?
Are the application edition and versio= n OK?
Is data plan option available?
Is Internet connection functioning?
If any of this requirement checks are answered with "no" then the user w= ill be informed about the requirements. This action closes the ticket. Othe= rwise we go to phase 2.
In this phase the Help Desk asks the User to retrieve as many useful inf= ormation as possible, aiming to fill completely the following Incident tabl= e.
|
IS |
IS NOT |
DIFFERENCES |
CHANGES |
WHAT |
|
Similar systems/s= ituations not failed |
? |
? |
WHERE |
|
Where or in which= network does it work? |
? |
? |
WHEN |
|
When does it work= ? |
? |
? |
EXTENT |
|
Which parts and/o= r systems do work well? |
? |
? |
This is a crucial phase as the Help Desk has to figure out the possible = causes of the Incident with the help of the previously collected data. We p= rovide a decision work flow that lists the most common complaints that are = the entry points for the troubleshooting. The following complaints are exam= ined:
C= all Performance |
C= onnection |
A= pplication local issues |
S= erver problems |
User can't = call |
Can't Conne= ct to Server |
Application= doesn't start |
Server is u= nreachable |
Bad Call Qu= ality |
Can't Regis= ter to Server |
Application= closes abruptly or crashes |
Server is t= oo slow answering |
Call interr= upts |
-----------= ----------------- |
Application= hangs at some point |
Can't login= to the Server |
User can't = receive call |
-----------= ----------------- |
Application= disappeared or missing |
Can't find = the User/Callee on the Server |
-----------= ----------------- |
-----------= ----------------- |
Application= goes into an infinite loop |
-----------= ----------------- |
Using the information collected and with the help of the troubleshooting= workflow the Help Desk should be able to list the most probable causes of = the Incident and thus propose to the User the related procedure(s) to try t= he solutions in the provided order. If the first solution fails, it's possi= ble to step to the second one and so on until either the Incident is solved= or the list ends. In the later case the Incident should be escalated to th= e higher level of Service Desk.
Even if the first/second level has found a solution (and so it can close= the Incident reporting success), the Incident must be reported as a Proble= m and passed to the proper team along with the Incident data collected duri= ng the process and the steps taken during the troubleshooting and it should= be still tested for the solution. It would be up to the Problem team to ev= entually close the ticket or perform further investigations or perform prop= er further actions. The same practice should be executed if no workaround o= r solutions has been found and the Incident is still open.
After the Incident has been declared as solved, the answers of the third= level can be:
not a problem: no further actions requ= ired by editor.
workaround identified and provided.
wait for the problem resolution: a sof= tware component upgrade will be provided.
Timings will be provided al= ong with the answers. The second level has to report back to the User and a= sk for the acceptance of the answer.