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

Debian Wiki debian-www at lists.debian.org
Tue Apr 14 15:59:05 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/Delivery" page has been changed by AlexanderAlemayhu:
https://wiki.debian.org/DebianEdu/Documentation/en/ITIL/Delivery?action=diff&rev1=5&rev2=6

  
  Capacity planning is used to ensure that all parts of the ICT solution has sufficient capacity to safeguard users' requirements. This includes:
  
-  * Monitoring the performance of IST services including infrastructure
+  * Monitoring the performance of ICT services including infrastructure
   * Configuration of systems to ensure they are optimally utilized to what the users actually do
   * Understanding user needs and planning for possible changes in the systems to take care of future needs
   * Resource planning in cooperation with the budget officer
@@ -175, +175 @@

  
  Typical data which are monitored are:
  
-  * Prosessor utilization
+  * Processor utilization
   * Memory utilization
   * CPU usage per task
   * Response times for users per task
@@ -204, +204 @@

  Here is a list of commonly encountered bottlenecks and what to do to get rid of them:
  
  ||'''Bottlenecks'''||'''Actions'''||
- ||Missing sound, USB stick support and DVD on thin clients.||Install diskless workstations (> 800 Mhz processor, > 256 MB RAM)||
+ ||Missing sound, USB stick support and DVD on thin clients.||Install diskless workstations (> 800 MHz processor, > 256 MB RAM)||
  ||Has 60 thin clients connected to the server and want more PCs.||Go for diskless clients, or install another a thin client server||
  ||Thin clients runs slowly after we expanded with 20 pieces without acquiring a new server machine||Install 2GB more memory on the server machine||
  ||Thin clients with 32MB memory does not start after upgrading to Skolelinux 2.0||Turn on cache (swap) of the thin clients, or downgrade to LTSP 4.2 which is set up with swap.||
@@ -228, +228 @@

   * Resource summary
   * Areas for improvement
   * Cost model
-  * Recommondation
+  * Recommendation
  
  == Availability management ==
  
@@ -242, +242 @@

   * Procedures and routines for handling operational services
   * Security, integrity and availability of data
  
- Availability can be measured in several ways. But before we show examples we'll point out what may be difficult targetting figures. If we should make systematic efforts to availability, we have to clarify what the different things mean. What means for example a percentage of availability.
+ Availability can be measured in several ways. But before we show examples we'll point out what may be difficult targetving figures. If we should make systematic efforts to availability, we have to clarify what the different things mean. What means for example a percentage of availability.
  
  Let's say a "computer with computer program" is a service. If the computer program does not work one day, then the service unavailable if all the other programs work fine. What if the computer program is unavailable for a classroom, but available on the rest of the school (because of an underlying service). This is difficult matter to clarify and work on in practice.
  
@@ -252, +252 @@

  
  ||'''Value'''||'''Meaning'''||
  ||% available||The value can be availability between hours 08:00 and 18:00. If the system is down 1 hours during one day, than the system is available in 90% of the agreed upon time. If availability is measured over a month with 20 work days, then the system is available 95% of the time.||
- ||% unavailable||Is the system down one hour during an agreed uptime, for example 10 hours a day, the system is unavailable in 10% of the time. Measured over 20 days, we may asssume the system has been unavailable for 5% of the time.||
+ ||% unavailable||Is the system down one hour during an agreed uptime, for example 10 hours a day, the system is unavailable in 10% of the time. Measured over 20 days, we may assume the system has been unavailable for 5% of the time.||
  ||Hours unavailable||One can agree to the number of times one accepts the system is unavailable during, for example within one month (20 days). It can be a maximum of one hour halt in the period, and between 08:00 until 18:00.||
  ||Error frequency||Even error rate can be measured per day or every month. 3 errors in the month and that the system is down between 08:00 until 18:00, is an example.||
  ||Consequences of errors||Measured values are a common starting point for judging whether an error to have consequences beyond ordinary error correction. The customer or the school for example, may ask to pay less for the operating agreement for the current month.||
@@ -293, +293 @@

  
  Server machines have usually a slightly older version of processors, and more robust memory, and hard drives. This is because many people use this hardware simultaneously. A small error that would not mean anything for one user, can provide downtime if 30 users logged into the machine.
  
- So testing is about to use proven equipment and editions of software running well a half or a year. Testing is also about trying out the different parts in a smaller but realistic context, to ensure that everything works. Adopting the latest version, or even beta versions of software or completely latest hardware usually lead to much trouble and extra work with maintenance. Settng systems in production without a small test in realistic environments usually lead to significant firefighting and dissatisfied users.
+ So testing is about to use proven equipment and editions of software running well a half or a year. Testing is also about trying out the different parts in a smaller but realistic context, to ensure that everything works. Adopting the latest version, or even beta versions of software or completely latest hardware usually lead to much trouble and extra work with maintenance. Setting systems in production without a small test in realistic environments usually lead to significant firefighting and dissatisfied users.
  
  When testing in a smaller scale on equipment in production, it is essential to arrange this with those affected. In addition, one must choose when to test. One should not test new things, for example, under examinations with use of ICT tools.
  



More information about the debian-edu-commits mailing list