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

Wed Apr 15 18:16:37 UTC 2015

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=13&rev2=14

  
  Previously, enquiries were written in paper logbooks. Today software is used to record the enquiries. In English, this is called "Request Tracker". It is crucial for operations to log enquiries. This is basically for error handling, user requests, and prioritization of the various incidents. Log entries are important to prevent recurring errors. Because operational events are periodically reviewed, an assessment of fixes and priorities can be made. The log also provides a basis for improving the service by debugging problem services and applications based on what users perceive as problematic.
  
- Thus the log of requests is a basic and necessary tool both for users and the service desk. There are several freely available systems for logging requests with good documentation <<FootNote(RT Essentials: http://www.oreilly.com/catalog/rtessentials/chapter/index.html
+ Thus the log of requests is a basic and necessary tool both for users and the service desk. There are several freely available systems for logging requests with good documentation <<!FootNote(RT Essentials: http://www.oreilly.com/catalog/rtessentials/chapter/index.html
- )>>. Skolelinux Drift uses RT <<FootNote(RT Essentials: http://www.oreilly.com/catalog/rtessentials/chapter/index.html
+ )>>. Skolelinux Drift uses RT <<!FootNote(RT Essentials: http://www.oreilly.com/catalog/rtessentials/chapter/index.html
  )>> to handle requests.
  
  One important thing when starting up support is not to get too tough a start. Do not try to achieve everything at once; bet rather on "quick wins" that keep the user informed, and aim for quick response times. It is also important to clarify who the service desk should forward events to, if they can not solve the issue themselves. The support desk must also check whether there will be disruptions for the user. This makes it quick and easy to give feedback.
@@ -143, +143 @@

  Examples of operational disturbances may be:
  
   * Programs
-   * the office program (OpenOffice.org) does not start
+   * the office program (!OpenOffice.org) does not start
    * the web browser (Firefox) crashes
    * the hard drive is full
   * Hardware
@@ -246, +246 @@

  
  === Procedures for problem management ===
  
- The Skolelinux/Debian Edu manual is a comprehensive collection of solutions for solving problems and configuring systems. Everything is on the Debian wikipedia pages. Solutions are maintained with the help of staff in schools, municipal ICT services, professional individuals and volunteers. See links to the English pages: https://wiki.debian.org/DebianEdu/Documentation/Manuals The pages are being translated to Norwegian bokmål. We are working to link the pages to bokmål too.
+ The Skolelinux/Debian Edu manual is a comprehensive collection of solutions for solving problems and configuring systems. Everything is on the Debian wikipedia pages. Solutions are maintained with the help of staff in schools, municipal ICT services, professional individuals and volunteers. See links to the English pages: https://wiki.debian.org/!DebianEdu/Documentation/Manuals The pages are being 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 to and all changes are logged. It is also possible to import OpenOffice.org documents, and export documents as PDF.
+ The Wiki technology has proven to be a great success for maintaining cataloged information on the internet. It's easy to contribute to and all changes are logged. It is also possible to import !OpenOffice.org documents, and export documents as PDF.
  
  == Configuration Management ==
  
@@ -281, +281 @@

  
  === Planning and installation ===
  
- The configuration of the computer network is connected to the architecture. Much of the planning is done with Debian Edu. This is because it may take both 3 and 4 weeks to set up servers with corresponding service level with Windows server, RedHat or other GNU/Linux distributions. Debian Edu takes this with 1-2 hours. If you want a fixed IP address for the network a professional uses ½ hour extra on this. This is because web services are set up with reusable names.
+ The configuration of the computer network is connected to the architecture. Much of the planning is done with Debian Edu. This is because it may take both 3 and 4 weeks to set up servers with corresponding service level with Windows server, !RedHat or other GNU/Linux distributions. Debian Edu takes this with 1-2 hours. If you want a fixed IP address for the network a professional uses ½ hour extra on this. This is because web services are set up with reusable names.
  
  What then must be planned is which additional user program to use, and which subsystems should interact with Debian Edu. It may, for example. be that the school has an electronic whiteboard.
  
@@ -343, +343 @@

  
  Even what may look like a small insignificant change message can have major consequences for if the change is implemented. We have examples of schools that have a stable Debian Edu network where all the programs work. A test version of a popular program crashing constantly, is installed, and Debian Edu get blamed.
  
- An example is schools that have installed the test version of the latest OpenOffice.org before the program was finally finished. Several thought it could be fun and try out. The problem is that the test editions are usually released to find errors and instability in applications. They are not intended for production use
+ An example is schools that have installed the test version of the latest !OpenOffice.org before the program was finally finished. Several thought it could be fun and try out. The problem is that the test editions are usually released to find errors and instability in applications. They are not intended for production use
  
  In production, the general rule is that you don't install test versions of software. Most operators recommend using the next to latest version of a program intended for production. After 6-12 months are usually the worst errors picked out of a new main version of an application.
  
@@ -367, +367 @@

  
  For some it may be boring with proper release management. You do not use the latest new every time something new comes. But often there is not room for the extra time in the operations department to handle a flood of complaints when new software fails. High uptime require established technology, Linux expert David Elboth states in Linux Magazine (1/2004). He writes:
  
-  * The higher requirements more stringent are requirements of the individual components. High requirements for uptime results also show that the choices you are left with are old technology. It is namely empirical data over time which may say something about downtime. We have all noticed how long after Red Hat and SuSE is on its server products.
+  * The higher requirements more stringent are requirements of the individual components. High requirements for uptime results also show that the choices you are left with are old technology. It is namely empirical data over time which may say something about downtime. We have all noticed how long after Red Hat and !SuSE is on its server products.
  
  Getting few complaints, with a stable and reliable environment, requires solid release handling. Alternatively, a bunch of complaints and dissatisfied users emerge, when installing not good enough tested cutting edge software. People with "boy room skills" has a tendency to underestimate the consequences of software upgrade. If something goes fine on your home computer, it does not mean that this will work in a wide network with 500 client computers and 3200 users.
  
@@ -435, +435 @@

  
  In our eyes ad-hoc solutions are only a detour through changes, and only an emergency measure. An ad-hoc solution is comparable to a temporary repair with "wire and tape." One must in sight clean up such solutions when you want stable operation without constant surprises. By skipping a planning phase you will get many more ad hoc solutions, and several operational problems when changes or upgrades are done. Therefore it is essential that professionals and management understand the value of a good planned process for changes.
  
- Therefore, we recommend that you convene a meeting for planning, and makes a stepwise plan for changes in the system. A stepwise plan will naturally vary according to the change. The upgrade OpenOffice.org suite is something other than upgrading the whole system. When upgrading to a new office application, a 2-3 hour tour of the office suite may be enough for the teacher in each school. When upgrading the entire system one must both provide user training and that the technical works as intended.
+ Therefore, we recommend that you convene a meeting for planning, and makes a stepwise plan for changes in the system. A stepwise plan will naturally vary according to the change. The upgrade !OpenOffice.org suite is something other than upgrading the whole system. When upgrading to a new office application, a 2-3 hour tour of the office suite may be enough for the teacher in each school. When upgrading the entire system one must both provide user training and that the technical works as intended.
  
  You'll find few shortcuts is the main point when it comes to planning and implementation. Studies show that those who plan properly and ensure that people have the right skills, have lower operating costs for the operation.
  

