[debian-edu-commits] [Debian Wiki] Update of "DebianEdu/Documentation/en/ITIL/Support" by AlexanderAlemayhu

[Debian Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Debian Wiki" for change notification.

The "DebianEdu/Documentation/en/ITIL/Support" page has been changed by AlexanderAlemayhu:
https://wiki.debian.org/DebianEdu/Documentation/en/ITIL/Support?action=diff&rev1=7&rev2=8

    * requests for information, advice or documentation
    * forgotten password
  
- The examples show some of the common operational disturbances. These are problems that make users turn to ICT contact the school or the Service Desk. IT service must prioritize what must be treated right away, and which problems need more time to resolve. To prioritize which problems need more comprehensive debugging, it is important to log all inquiries about malfunctions. This gives an overview of which disruptions it is most of, neseccary for acting on those areas with most problems.
+ The examples show some of the most common operational issues. These are problems that prompt users to contact the school or the service desk. The ICT service must prioritize what must be handled straight away, and which problems need more time to resolve. To prioritize which problems need more comprehensive debugging, it is important to log all enquiries about malfunctions. Once one has an overview of the most common problems, appropriate actions can be taken.
  
  === Check list ===
  
- We have made a short check list to ensure it has in place procedures and systems for good event handling
+ We have made a short check list to ensure procedures and systems for good event handling are in place.
  
-  * The operator making debugging, is the one that reports the status back to the ICT contact at school and/or user
+  * The operator doing the debugging will report the status back to the ICT contact at the school and/or the user.
-  * The system for logging events must be in place, working both technically and functionally for those working with event handling in schools and at the Service Desk.
+  * The system for logging events must be available and working (both technically and functionally) for those working with event handling in schools and at the service desk.
-  * The system for event logging must be used for nearly all operating events
+  * The event logging system must be used for virtually all operational events.
-  * Statistics of the log of events is made periodically. The statistics used to implement measures which eliminates recuring problems, which irritate users.
+  * Statistics of the log of events should be made periodically. The statistics can be used to identify and eliminate recurring problems, which are irritating to users.
  
  === Planning and implementation ===
  
- To set up a workable system for logging events require something more than installing the system. All in the operations department must use the system. Those reporting errors must also receive feedback on email with a ticket number. This require significant efforts configuring the system for event logging. In addition, one must ensure plain user training of those who receive the requests.
+ To set up a workable system for logging events requires something more than installing the system. Everyone in the operations department must use the system. Those reporting errors must also receive feedback by email with a ticket number. This requires significant efforts in configuring the system for event logging. In addition, one must ensure basic user training for those who receive the requests.
  
- Large and comprehensive plans are not need to put in place a proper event handling. To handle events is a completely standard task for those who work at the Service Desk or as ICT contacts at each school. To set up a computer tool for logging events may require up to a few weeks for a correct configuration, and users may also report events via e-mail and by phone.
+ Large and comprehensive plans are not required to implement proper event handling. Event handling is a completely standard task for those who work at the service desk or as ICT contacts at the schools. Setting up a computer tool for logging events may require up to a few weeks for a correct configuration, and users may also report events via e-mail and by phone.
  
- The user interface to the log system is relatively self-explanatory. So it does not take many hours to start applying. During the daily use of the system one will become more and more comfortable with what should be replied to the logged messages. It is crucial that all in the operations department use the system for logging of operation messages.
+ The user interface to the logging system is relatively self-explanatory, so it should not take too long to get started. Daily use of the system will get users comfortable with what should be logged. It is crucial that everyone in the operations department uses the logging system for operational messages.
  
- === Activities when operating interference occurs ===
+ === Activities related to operational events ===
  
- To get an idea of activities done in relation to a message of an event, we use an example.
+ To get an idea of activities done following a reported event, we use an example.
  
- A user contacts the service office with a problem. Printing does not work, is the message from the user on the telephone. Operations logs event right after the call is completed. The problem with the print becomes a case with a case number (given automatically).
+ A user contacts the service office with a problem, and reports that printing is not working. Operations logs the event immediately after the call is completed. A case is opened for the issue, and automatically given a case number.
  
- Operations at the Service Desk makes a quick analysis. Has the spooler stopped again, or is it something else? There may be missing paper or toner? By examining the spooler looks the operator that it is filled up. She deletes the queue and see if the next job is printed.
+ Operations at the service desk make a quick analysis. Has the spooler stopped again, or is it something else? Is the paper or toner missing? The operator examines the spooler and sees that queue has filled up. She deletes the queue and tests whether the next job is printed.
  
- This time the print queue refilled again. Operations contact school's ICT contact asking to check whether the paper is in place. This is listed in the event log. The ICT contact replies that the paper is filled in, and printing is normal. Case closed, also noted in the system event logg.
+ This time the print queue fills back up again. Operations contact the school's ICT contact asking to check whether the paper tray is empty. This is listed in the event log. The ICT contact replies that they have refilled the paper tray, and printing is normal. The case is closed, and is noted in the system event log.
  
- If the had not started again, toner may be missing or the printer had an error. Was it an error the operator must have scaled problem. Scaling means that some other than the operator or the ICT contact resolves the problem. In this example one needs help from a technician who fix printers.
+ If printing had not started again, the toner might have be missing or there might have been a printer error. If there was an error, operations would have to escalate the issue. This means that someone other than the operator or the ICT contact is needed to resolve the problem - in this example, a technician who can fix printers.
  
- This example shows that it is initiated a whole apparatus to start a printer again. Printers will not work even if you have added more paper in a an empty printer, so one must first examine if toner is missing. If everything seems to be in place, but things still do not work, you must scale the problem. Operating department call an expert in a particular area to fix the error. This time it was a service technician for printers.
+ This example shows the whole workflow that needs to be investigated to get a printer working again. If a printer does not work even after checking that paper and toner are available, the issue needs to be escalated. The operations department must call in an expert to fix the problem - this time it was a service technician for printers.
  
- What was wrong and the fix done is noted in the system for event logging.
+ What was wrong and what the fix was are noted in the event logging system.
  
  === Roles ===
  
- A variety of roles are involved when ICT service processes messages about something doesn't work. In the example above the school's ICT contact and the operator cooperate to solve the printing problem. Had the issue been greater, they have to summon a service technician. If one can't fix the printer, one have to buy new one. If the school must obtain new printer, involving the ICT managers may be needed to get money. Many places the principal who has the last word.
+ A variety of roles are involved when the ICT service deals with reported issues. In the example above, the school's ICT contact and the operator cooperate to solve the printing problem. Had the issue been more difficult, they would have had to call a technician. If the printer could not be fixed, a new one would have to be purchased. If the school needed to buy a new printer, the ICT managers might need to arrange payment. In many organizations, the principal has the last word.
  
- In short, it quickly becomes many who get involved when something does not work. One should basically solve problems there and then. Avoiding involving many who can't help solve the problem. Scaling problems which can be solved locally, becomes quickly more costly. Also because many inquiries are easy to deal with there and then. Other requests involve more complex problems. Then you have to involve more people. Are additional or external help to solve the problem needed, this must as a main rule be clarified with the operations manager. The important thing is to be aware when handling operating events, and using resources in a good way.
+ In short, it is easy for many people to get involved when something does not work. If possible, problems should be solved on the spot, trying to avoid including unnecessary people. Escalating problems which could be solved locally quickly becomes costly. Many inquiries are easy to deal with there and then, but other requests involve more complex problems which involve more people. If additional or external help is needed to solve the problem, this must as a rule be clarified with the operations manager. The important thing is to be aware of these points when handling operating events, to use resources appropriately.
  
  === Key points ===
  
- We have sat up some key points for handling incidents. The points will be helpful to consider whether doing a good job out of measurable and well-defined requirements. Such measurement points are:
+ We have sat up some key points for handling incidents. These points can be helpful in evaluating whether or not things are going well by using measurable and well-defined requirements. Such measurement points are:
  
-  * Total number of operating disturbances.
+  * Total number of operational incidents.
-  * Average time from receiving an inquiry to the issue is resolved, and classified with codes (a well organized operation department has codes for types of events and errors).
+  * Average time from receiving an inquiry to when the issue is resolved, classified with codes (a well organized operation department has codes for different types of events and errors).
   * Percentage of incidents handled within agreed response time (as agreed in the service level agreement).
   * Average cost for each event
-  * Percentage of incidents solved by using the service without going on to the next level with operational
+  * Percentage of incidents solved by the service desk without escalation
   * Events per client machine (workplace)
   * Number and percentage of incidents solved by the operations center without the need for visits to school
  
  === Tools ===
  
- A number of tools can make it easier to handle operational disturbances.
+ A number of tools can make it easier to handle operational incidents.
  
   * Automatic logging
   * Automatic routing of events to the right persons
   * Automatic retrieving of data from the database for configuration management
-  * Phone and email are easy to use together with tools for registering requests and incidents.
+  * Phone and email are used in conjunction with tools for registering requests and incidents.
  
  == Problem Management ==
  
- Problem management is an "investigative" process. Known bugs are most often handled directly by the Service Desk. This is the most common form of event handling. By unknown errors one must investigate what's wrong. This form of debugging requires both common sense and scent. Good operating people use scent to go straight to the problem, find the solution and restore service as quickly as possible so that everything works normally.
+ Problem management is an "investigative" process. Known bugs are most often handled directly by the service desk. This is the most common form of event handling. To investigate unknown errors requires both common sense and instinct. Good operating people use instinct to go straight to the problem, find the solution and restore service as quickly as possible so that everything works normally.
  
  '''Problem management is;'''
  
   * Problem management
   * Checking errors
   * Proactive control to prevent problems
-  * Identify error patterns, using information from for example event management
+  * Identify error patterns, using information from, for example, event management
  
  '''Problem control'''
  
-  * Identify problemes
+  * Identify problems
   * Classify problems
   * Examine/research problems
  
- '''Wrong control'''
+ '''Error control'''
  
   * Identify and register known errors
   * Find temporary solutions if possible
@@ -242, +242 @@

  '''Proactive control'''
  
   * Identify and solve problems and errors before the incident is reported by users.
-  * Using logs, information from event handling to see how problems may arise
+  * Use logs and information from event handling to see how problems may arise
  
  === Procedures for problem management ===
  
- Vi har lagt ved en omfattende samling av problemløsninger og oppskrifter for konfigurering. I løpet av sommeren 2006 vil dette også være lagt ut på Internett. Vedlikeholdet av oppskriftene vil skje av profesjonelle driftsoperatører på skoler, kommunale IT-tjenester og private driftsoperatører. For å gjøre det enkelt å gjøre forbedringer i dokumentasjonen er det hele lagt ut i en wiki som ligger på en Skolelinux-tjener.
+ The manual for Skolelinux/Debian Edu is a comprehensive collection of recipes for solving problems and configure the system. Everything is out on Debian wikipedia pages. Maintenance of the recipes happens with the help of professional operators in schools, municipal ICT services and private players, both professionals and volunteers. See links to the English pages: https://wiki.debian.org/DebianEdu/Documentation/Manuals The pages are also translated to Norwegian bokmål. We are working to link the pages to bokmål too.
  
  The Wiki technology has proven to be a great success for maintaining cataloged information on the Internet. It's easy to contribute and all changes are logged. It is also possible to import OpenOffice.org documents, and export recipes as pdf.