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

[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 PetterReinholdtsen:
https://wiki.debian.org/DebianEdu/Documentation/en/ITIL/Support?action=diff&rev1=23&rev2=24

Comment:
Updated from git.

  
  Your operations department can create a copy of the Debian Edu archive on a central server. From here, all the software can quickly and smoothly be installed on other machines. The advantage is that your ICT service has a constant overview of the versions of the software they have made available to schools. This also prevents the installation of software that has not been reviewed by the Change Management.
  
- There may be considerable problems if you do not maintain the software archive and configurations. It can also lead to mistakes with a configuration or software package. Then this gets rolled out to all machines. In addition, some schools may install insufficiently tested software or use beta releases in production. So one must have good processes and have someone to take responsibility for maintenance of the program archive and configurations.
+ There may be considerable problems if you do not maintain the software archive and configurations. It might happen as well that one does mistakes with a configuration or software package. Then this gets rolled out to all machines. In addition, some schools may install insufficiently tested software or use beta releases in production. So one must have good processes and have someone to take responsibility for maintenance of the program archive and configurations.
  
  It may seem like one needs a lot of extra things in place in order to install and maintain the services and programs that are in use. However, if you skip the tools that provide management of upgrades, you give yourself a lot of extra work. The ICT service must spend a lot of time on manual installation on each machine. The danger of making mistakes increases. When things do not work you get disgruntled users, and much time is spent fixing problems.
  
- Many operating major IT systems have inadequate plans for changes. Some have no plans at all, but just installing new versions of software. Changes made can be perceived as problematic for some users, because functions they are comfortable with changes place in the user interface. For operations it can go completely wrong. For example when they should upgrade to from older version of Windows to newer in Arendal municipality, most stopped working. ICT service said they had several computer program that was held together with "wire and tape." It took half a year to clean it up.
+ Many of those administrating big IT systems have inadequate plans for the upcoming changes. Some have no plans at all, but just upgrading the software to the latest releases. Changes made can be perceived as problematic for some users, because functions they are comfortable with could change location on the user interface. For operations it can go completely wrong. For example when they tried upgrading from older to newer version of Windows in the Arendal municipality, mostly everything stopped working. The IT department said they had several computer programs that were held together with "wire and tape." It took half a year to clean it up.
  
  === Planning and implementation ===
  
  The reason for planning before implementing changes is to avoid weeks or months of delay due to problems. The time used for planning is quickly regained because one avoids additional problems. There will always be people who say they have had no problems with ad hoc changes in the systems; but closer examination reveals that there are problems after such changes, they merely don't get communicated.
  
- In our eyes ad-hoc solutions are only a detour through changes, and only an emergency measure. An ad-hoc solution is like a temporary repair with "wire and tape." One must in due course clean up such solutions to ensure stable operation without constant surprises. Skipping a planning phase leads to 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.
+ In our eyes, ad-hoc solutions are only a detour through changes, and only an emergency measure. An ad-hoc solution is like a temporary repair with "wire and tape." One must in due course clean up such solutions to ensure stable operations without constant surprises. Skipping a planning phase leads to 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 make a stepwise plan for changes in the system. A stepwise plan will naturally vary according to the change. Upgrading the !OpenOffice.org suite is quite different from 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 test that the technical details work 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.
+ The main point is that it is straightforward 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 operations.
  
  === Activities ===
  
@@ -449, +449 @@

  ||Configuration database||Be sure to have in place all configuration files. This applies both to those who are in use, and the new ones supplied in systems to be changed or updated.||
  ||Build management||All scripts and systems used to deploy or create disk images must be in place.||
  ||Testing||First, run trials on test equipment. When this works without any problems, it can be tested at a school. The school must be fully informed about, and fully in on trying out new software. When one is sure that everything works, you can upgrade for all.||
- ||Fall-back solution||Even with extensive testing, new releases may go wrong. Therefore it is essential to have a fallback. The easiest solution is to spare have the old installation with data on a separate server machine. Such a machine can be plugged in if the change or upgrade does not work.||
+ ||Fall-back solution||Even with extensive testing, new releases may go wrong. Therefore it is essential to have a fallback. The easiest solution is to spare the old installation with its data on a separate server machine. Such a machine can be plugged in again if the change or upgrade does not work.||
  
  === Tools ===
  
- As seen from the activity list, one needs several tools to keep track of different releases of software, services and hardware in the system. Some of these tools mentioned previously. But we repeat this anyway:
+ As seen from the activity list, one needs several tools to keep track of different releases of software, services and hardware in the system. Some of these tools were mentioned previously. But we repeat this anyway:
  
   * Debian tools for the definitive software library
-  * Database for configurations and hardware (subversion setup files, spreadsheets detailing all hardware with physical location)
+  * Configuration and hardware asset database (subversion setup files and spreadsheets providing an overview over all hardware and their respective physical locations)
   * Build management (the system which builds Debian packages)
   * Hardware for testing and backup-solution
  
@@ -498, +498 @@

  In this chapter we have proposed a number of tools to improve operational support. Here follows a summary of the tools:
  
   * Debian tools for the definitive software library
-  * Database for configurations and hardware (subversion setup files, spreadsheets detailing all hardware with physical location)
+  * Configuration and hardware asset database (subversion setup files and spreadsheets providing an overview over all hardware and their respective physical locations)
   * Build management (the system which builds Debian packages)
   * Hardware for testing and backup-solution
   * Request Tracker
@@ -521, +521 @@

  
  There are often a wide range of programs and procedures to solve a specific task. But some problems solved completely different when maintaining 500 computers and 11 servers, than when fixing your home PC. An example might be tools that allow the teacher to see the desktop of each student on his or hers client machine. The teacher can stop and start programs for all pupils, and prevent individual pupils to use for example IMs when this interferes with school work.
  
- Regarding the choice of operating tools, it's about automation and simplification of operational tasks. It is about making and reduce manual work to a minimum. So the motivation is to just maintain automatic. Also here it is to make things easy, which can be a considerable job to get done.
+ Regarding the choice of operating tools, it's about automation and simplification of operational tasks. It is about making and reducing manual work to a minimum. So the motivation is to just to maintain the automatics. Also here it is possible to make things easy, which can be a considerable job to fulfill.
  
  As you can see, it is not easy to set up good criteria for selection of operating tool for large installations. Most of all, this is because software developers often lack experience in the operation of IT systems. They are known only to create new things, but to create good and relevant tools for operation requires many years of experience.