[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=3&rev2=4

  
  The purpose of the ICT service is to prevent disturbances like shutdowns or reduced quality using computer programs. Users will experience few problems with the ICT system if the ICT service has enough resources to operations, equipment and for inquiries to the Service Desk. Anyway small or big errors happens as disturbances for users. Then one needs good handling of incidents.
  
- In parachute environment they call near accidents for "events." It is perhaps not quite the same in computer operation when something is not working. The purpose of dealing with incidents and restore service as quickly as possible, so that everything works normally. If something goes wrong, it must have the least possible impact on users. What is a normal service is agreed through an operating agreement describing the service level.
+ In parachute environment they call near accidents for "incidents". It is perhaps not quite the same in computer operation when something is not working. The purpose of dealing with incidents and restore service as quickly as possible, so that everything works normally. If something goes wrong, it must have the least possible impact on users. What is a normal service is agreed through an operating agreement describing the service level.
  
- Statistics of events is important. Especially if several people job with the operation. When several jobs together, you loose track of all cases. Statistics will point out problem areas that must be addressed more thoroughly than a quick fix from service office. For exsample there may be many requests to exchange passwords to students who have forgotten this. Then it may be wise to let the teacher to class switch pupil password.
+ Statistics of incidents is important. Especially if several people job with the operation. When several jobs together, you loose track of all cases. Statistics will point out problem areas that must be addressed more thoroughly than a quick fix from service office. For example there may be many requests to exchange passwords to students who have forgotten this. Then it may be wise to let the teacher switch passwords for pupils in the class.
  
  An operational disturbance is defined as:
  
@@ -231, +231 @@

  
  === Check list ===
  
- Vi har laget en kort huskeliste for å sikre at man har på plass rutiner og systemer for god hendelseshåndtering
+ We have made a short check list to ensure it has in place procedures and systems for good event handling
  
-  * Driftsoperatør som gjør feilretting er den som melder status tilbake til IT-kontakt på skolen og/eller bruker
-  * Systemet for logging av hendelser må være på plass slik at det virker både teknisk og funksjonelt for de som jobber med hendelseshåndtering på skolene og på servicekontoret
-  * Systemet for hendelseslogging må brukes for så og si alle driftshendelser
-  * Ved jevne mellomrom lages statistikk av loggen over hendelser. Statistikken brukes for å sette inn tiltak som fjerner problemer som går igjen, og irriterer brukerne.
+  * The operator making debugging, is the one that reports the status back to the ICT contact at school and/or 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 event logging must be used for nearly all operating events
+  * Statistics of the log of events is made periodically. The statistics used to implement measures which eliminates recuring problems, which irritate users.
  
- === Planlegging og implementasjon ===
+ === Planning and implementation ===
  
- Å sette opp et brukbart system for logging av hendelser krever er noe mer enn å installere systemet. Alle i driftsavdelingen må bruke systemet. De som melder feil må også få tilbakemelding på e-post med saksnummer. Slike ting krever betydelig med konfigurering av systemet for hendelseslogging. I tillegg må man sørge for enkel brukeropplæring av de som tar imot henvendelsene.
+ 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.
  
  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.
  
- Selve brukergrensesnittet til loggsystemet er relativt selvforklarende. Så det tar ikke mange timene å ta i bruk. I løpet av den daglige bruken av systemet vil man bli mer og mer komfortabel med hva som bør stå i meldingene som logges. Det er avgjørende at alle i driftsavdelingen bruker systemet for logging av driftsmeldinger.
+ 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.
  
- === Aktiviteter ved driftsforstyrrelser ===
+ === Activities when operating interference occurs ===
  
- For å få en idé om hvilke aktiviteter som gjøres ved en melding av en hendelse, bruker vi et eksempel.
+ To get an idea of activities done in relation to a message of an event, we use an example.
  
- En bruker kontakter servicekontoret med et problem. Utskriften virker ikke, er meldingen fra brukeren på telefon. Driftsoperatør logger hendelsen rett etter samtalen er avsluttet. Problemet med utskriften blir en sak med et saksnummer (som gis automatisk).
+ 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).
  
- Driftsoperatør på servicekontoret gjør en rask analyse. Er det utskriftskøen som har stoppet igjen, eller er det noe annet? Det kan hende det mangler papir eller toner? Ved å undersøke utskriftskøen ser driftsoperatøren at den er fylt opp. Hun sletter køen, og ser om neste utskrift blir skrevet ut.
+ 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.
  
- Denne gangen fylte skriverkøen seg opp igjen. Driftsoperatør kontakter skolens IT-kontakt, og ber om å sjekk om papir er på plass. Dette noteres i hendelsesloggen. IT-kontakten melder tilbake at papir er fylt på, og at utskriften går som normalt. Saken er avsluttet noe som også noteres i systemet for hendelseslogging.
+ 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.
  
- Om skriveren ikke hadde startet igjen kunne det vært toner som manglet, eller at skriveren hadde en feil. Var det en feil måtte driftsoperatør skalert problemet. Med skalering menes at andre enn driftsoperatør og IKT-kontakten løser problemet. I dette eksemplet måtte man fått hjelp av en servicetekniker som kan fikse skrivere.
+ 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.
  
- Dette eksemplet viser at det settes igang et helt apparat for å få igang en skriver som har stanset opp. Virker ikke skriveren selv om man har lagt inn mer papir i en i en tom skriver, så må man først undersøke om det er toner som mangler. Om alt ser ut til å være på plass, men ting fortsatt ikke virker, må man skalere problemet. Driftsavdelingen kaller inn en ekspert på et bestemt område for å fikse feilen. Denne gangen var det en servicetekniker for skrivere.
+ 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.
  
- Hva som var feilårsak og den reparasjonen som ble gjort noteres i systemet for hendelseslogging.
+ What was wrong and the fix done is noted in the system for event logging.
  
- === Roller ===
+ === Roles ===
  
- Det er en rekke roller involvert når IT-tjenesten behandler meldinger om at noe ikke virker. I eksemplet over samarbeider skolens IT-kontakt og driftsoperatøren om å løse problemet med utskrift. Hadde problemet vært større måtte man ha innkalt en servicetekniker. Får man ikke fikset skriveren å må kjøpe ny. Må skolen skaffe ny skriver kan det hende man må involvere IT-ansvarlige for å få penger. Mange steder er det rektor som har siste ordet.
+ 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.
  
- Kort sagt blir det fort mange som blir involvert når noe ikke virker. Man skal i utgangspunktet løse problemer der og da. Da unngår man å involvere mange som ikke kan bidra til å løse problemet. Skalerer man problemer som kan løses lokalt så blir det fort mer kostbart. Også fordi mange henvendelser bør være enkelt å håndtere der og da. Andre henvendelser dreier seg om mer sammensatte problemer. Da må man involvere flere personer. Er man avhengig av ekstra eller ekstern hjelp for å løse problemet så må dette som hovedregel avklares med driftsleder. Det viktige er å være bevisst ved håndtering av driftshendelser, og bruke ressursene på en god måte.
+ 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.
  
- === Nøkkelpunkter ===
+ === Key points ===
  
- Vi har satt opp en del nøkkelpunkter ved håndtering av hendelser. Punktene skal være til hjelp for å vurdere om man gjør en god jobb ut fra målbare og vel definerte krav. Slike målepunkter er:
+ 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:
  
-  * Totalt antall driftsforstyrrelser
-  * Gjennomsnittlig tid fra man har fått en henvendelse til at problemet er løst, brutt ned på koder (en godt organisert driftsavdeling har koder for hendelser og feiltyper).
-  * Prosentvis av hendelser håndtert innen avtalt svartid (avtalt i avtalen om tjenestenivå)
-  * Gjennomsnittlig kostnad for hver hendelse
-  * Prosentvis av hendelsene løst av hjelpetjenesten uten å gå videre til neste nivå med driftsstøtte
-  * Hendelser pr klientmaskin (arbeidsplass)
-  * Antall og prosenter av hendelser som løses fra driftsenteret uten behov for besøk på skolen
+  * Total number of operating disturbances.
+  * 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).
+  * 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
+  * Events per client machine (workplace)
+  * Number and percentage of incidents solved by the operations center without the need for visits to school
  
- === Verktøy ===
+ === Tools ===
  
- Det er en rekke verktøy som kan gjøre det enklere å håndtere driftsforstyrrelser.
+ A number of tools can make it easier to handle operational disturbances.
  
-  * Automatisk logging
+  * Automatic logging
-  * Automatisk dirigering av hendelser til riktige personer
-  * Automatisk uthenting av data fra databasen for konfigurasjonsstyring
-  * Telefonen og e-post virker enkelt sammen med verktøy for registrering av henvendelser og hendelser.
+  * 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.
  
- == Problemhåndtering (Problem Management) ==
+ == Problem Management ==
  
- Problemhåndtering er en «undersøkende» prosess. Kjente feil blir oftest håndtert direkte av servicekontoret. Dette er den mest vanlige formen for hendelseshåndtering. Ved ukjente feil må man undersøke nærmere hva som er galt. Denne form for feilsøking krever både sunn fornuft og teft. Gode driftsfolk bruker teften til å gå rett til problemet, finner løsningen, og gjenopprette tjenesten så raskt som mulig slik at alt virker på vanlig måte.
+ 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.
  
- '''Problemhåndtering er;'''
+ '''Problem management is;'''
  
-  * Problemkontroll
-  * Feilkontroll
-  * Proaktiv kontroll for å hindre problemer
-  * Identifisere feilmønstre ved å bruke informasjon fra f.eks. hendelseshåndteringen
+  * Problem management
+  * Checking errors
+  * Proactive control to prevent problems
+  * Identify error patterns, using information from for example event management
  
- '''Problem kontroll'''
+ '''Problem control'''
  
-  * Identifisere problemer
+  * Identify problemes
-  * Klassifisere problemer
+  * Classify problems
-  * Etterforske/Undersøke problemer
+  * Examine/research problems
  
- '''Feil kontroll'''
+ '''Wrong control'''
  
-  * Identifisere og registrere kjente feil
-  * Finne midlertidige løsninger om mulig
-  * Kontakte de med ansvar for endringsledelse for å få fjernet feilen permanent
+  * Identify and register known errors
+  * Find temporary solutions if possible
+  * Contacting those with responsibility for Change Management to remove the error permanently
  
- '''Proaktiv kontroll'''
+ '''Proactive control'''
  
-  * Identifisere og løse problemer og feil før hendelsen blir rapportert av brukere.
-  * Bruke logger, informasjon fra hendelseshåndteringen for å se hvor problemer kan oppstå
+  * 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
  
- === Prosedyrer for problemhåndtering ===
+ === 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.
  
- Wiki-teknologien har vist seg å være en stor suksess for å vedlikeholde katalogisert informasjon på Internett. Det er enkelt å bidra og alle endringer loggføres. Det er også mulig å importere OpenOffice.org dokumenter, og eksportere oppskrifter som pdf.
+ 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.
  
- == Konfigurasjonsstyring (Configuration Management) ==
+ == Configuration Management ==
  
- Ressursene som brukes på IT-systemene i skolen må håndteres på en økonomisk forsvarlig måte. Da må man ha styring på tjenestene som brukes og utstyret eller infrastrukturen som det ofte kalles. Utstyret, programvaren og tjenestene har en hel rekke med innstillinger. Dette er konfigurasjoner, eller en logisk modell av hvordan infrastruktur og tjenester er satt opp.
+ The resources spent on IT systems in schools must be handled in a financially prudent manner. Then you have to control of the services used and the equipment or infrastructure as it is often called. The equipment, software and services have a whole range of settings. This is configurations, or a logical model of how infrastructure and services are set up.
  
  To control the configurations they must be identified, saved and maintained. One must also be able to keep track of different versions of the configurations. We call each part of a setup for a Configuration Item (CI). A configuration file may, for example, ensure that certain users have access to a few printers in the network. Another can make sure you get a buffer on diskless clients.
  
@@ -386, +386 @@

  
  Many ICT services are not clever in handling changes in ICT systems. Leading to many disgruntled users. Surveys in the public sector in Denmark show that operating costs go down when you have good control on the changes. Therefore, it pays to involve users with training and participation related to the changes made.
  
- Det er helt avhengig av skikkelige prosesser ved endringsmeldinger. Dette gjelder uavhengig om endringene er små eller store. Derfor er det viktig å ha på plass riktige personer når man gjør endringer slik at det både er gitt opplæring og det er folk til å svare på spørsmål. Dette blir spesielt viktig når man tar i bruk nye utgivelser av programvare og tjenester. Det har ingen ting med om man bruker fri eller produsenteid programvare.
+ Changing messages is entirely dependent on proper processes. This applies regardless of whether the changes are small or big. Therefore it is important to have in place the right people when making changes, both to give training and to have people to answer questions. This becomes especially important when adopting new releases of software and services. This is independent of whether one uses free or proprietary software.
  
- Endringsledelsen skal sørge for at alle endringer gjøres på en standardisert og riktig måte. Det er viktig å få til beslutning om endring på riktig nivå i organisasjonen, Standard endringer kan ofte være forhåndsgodkjente når de er gjort et par ganger. Men større endringer vil ofte involvere et høyre beslutningsnivå mellom skoleledelsen og driftsoperatør.
+ Change Management should ensure that all changes are made in a standardized and right manner. It is important to ancor the decision about amending at the appropriate level in the organization, Standard changes can often be pre-approved when they are done a few times. But major changes will often involve a higher decision level between school management and operator.
  
- Grunnen til at ledelsen skal være med er at endringer i systemet er at en oppgradering ofte vil kreve opplæring av brukerne. Det kan være oppgradering til ny nettleser eller ny utgave av kontorprogrammet. Dette kan fort føre med seg en halv dags opplæring i hva som er nytt i et program. Slike endringer må derfor avklares med ledelsen. Endringene må også gjøres uten at det andre deler av systemet slutter å fungere.
+ The reason why the management should be included is that an upgrade will often require training of users. It may be upgrading to a new browser or a new version of office software. This can quickly lead to a half day training in what is new in a program. Such changes must be agreed with the management. The changes must also be done without the other parts of the system stops working.
  
- De med ansvar for å godkjenne endringer mottar en mottar en såkalt endringsmelding eller RFC (Request For Change) som er den engelske forkortelsen. Når man har en endringsmelding kan man vurdere om endringen skal utføres. Mange ganger må man avklare med ledelsen om eventuelle endringer skal gjøres, og eventuelt når det skal skje.
+ Those with responsibility for approving changes receives a so-called change message or RFC (Request For Change). When you have a RFC you can assess whether the change should be performed. Many times you have to clarify with management if optional changes should be made, and if so, when it will happen.
  
- Ved endringer må man også samarbeide med skolens IKT-ansvarlig. Man må sørge for at endringene skjer når det passer med skolenes planer. Å gjennomføre betydelige endringer uten endringsledelse kan føre til mye misnøye og ekstra henvendelser til servicekontoret. Da får man betydelig ekstraarbeid uten at dette er planlagt. I tillegg kan det føre til en endring som ville fort må rulles tilbake. Man får fort dobbelt så mye arbeide uten å havne noe annet sted enn tilbake til start. Hadde man sørget for de nødvendige godkjenninger ville endringen kunne gjøres på en planlagt og grei måte.
+ By changes one must also cooperate with the school's ICT responsible. One must ensure that changes occur when it fits with the schools plans. To implement significant changes without Change Management can lead to much dissatisfaction and additional inquiries to the Service Desk. This would provide significant extra work without this being planned. In addition, it may lead to a change that would soon be rolled back. You fast get twice as much work without ending anywhere else than back to start. Had one made the necessary approvals, may the change be done in a planned and straightforward manner.
  
- Endringsledelse gjøres for å unngå mer ekstra arbeide enn hva som er nødvendig. Å gjøre endringer krever selvsagt mer arbeide, men man vil få mindre ekstra arbeide om endringene planlegges. Man unngår også at man må rulle tilbake endringer fordi det oppstår problemer der brukerne ikke er forberedt på betydelig omlegging.
+ Change Management is done to avoid more extra work than what's necessary. Making changes obviously requires more work, but you will get less extra work on the changes planned. One also avoids the need to roll back changes, because problems arise where users are unprepared for substantial changes.
  
- Når man f.eks. oppdaterer hele systemet til ny versjon må man passe på at alle er orientert. Man må undersøke om de som berøres av endringen trenger opplæring. De rette fagpersonene må forberede det hele slik at det ikke oppstår overraskelser.
+ When you for esxample update the entire system to a new version, make sure that everyone is informed. One must look into whether those affected by the change need training. The right professionals must prepare it all, so there are no surprises.
  
- Men må unngå at alt ansvar havner hos den som står for styring av versjonene av programvaren. Det er den som har ansvaret for håndtering av utgivelser (release manager). Utgivelseshåndteringen er en prosess som fortrinnsvis skal arbeide med endringer som inneholder mange mindre endringer. Dette skjer som regel ved utrulling av nye systemer og tjenester, eller ved oppgradering av hele systemet til ny versjon.
+ All responsibility must not land on the person responsible for managing versions of software, the release manager. Release handling is a process which preferably should work with changes that contains many minor changes. This usually happens when rolling out new systems and services, or the upgrading of the entire system to a new version.
  
- === Aktiviteter ===
+ === Activities ===
  
-  * Se over endringsmeldingen (RFC) og sjekk at den også har fått et unikt nummer.
-  * Prioriter og kategoriser endringer
-  * Fjern endringer som ikke er mulige. Dette kan gjøres ved å merke disse som ikke mulig.
-  * Gi tilbakemelding til den som gav endringsmeldingen
-  * Sørg for at man har en rådgivingsgruppe (eng. Change Advisory Board) der endringen blir tatt opp, diskutert og vurdert. Rådgivningsgruppa kan være utvalgte IT-kontakter og driftspersonell med lang erfaring.
-  * Koordiner endringene med den som håndterer forskjellige versjoner av programmer og tjenester (eng. Release Management)
-  * Se over og avslutt endringsmeldingen (RFC)
-  * Husk å lagre endrede konfigurasjoner i lageret for oppsettfiler
-  * Rapporter
+  * See change message, or RFC (Request For Change) above, and check it also has got a unique number.
+  * Prioritize and categorize the changes
+  * Remove not possible changes. Thit can be done by marking them as not possible.
+  * Give feedback to the one giving the change message
+  * Make sure you have a Change Advisory Board, where the change is dealt with, discussed and evaluated. This consulting group can be selected ICT contacts and operations personnel with long experience.
+  * Coordinate changes with the Release Management which handle different versions of applications and services.
+  * Look over and finish the changing message (RFC)
+  * Remember to save modified configurations in the respository for configuration files.
+  * Reports
  
- Selv hva som kan se ut som en liten ubetydelig endringsmelding kan få omfattende konsekvenser om endringen gjøres. Vi har eksempler på skoler som har et stabilt Skolelinux-nett der alle programmene virker. Så installeres en testutgave av et populært program som kræsjer hele tiden. Skolelinux får skylda.
+ 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 Debaian Edu network where all the programs work. A test version of a popular program chrashing constantly, is installed, and Debian Edu get blamed.
  
- Et eksempel er skoler som har installert testversjonen av nyeste OpenOffice.org før programmet var endelig ferdig. Flere syntes at det kunne være gøy og prøve ut. Problemet er at testutgaver som regel er utgitt for å finne feil og ustabilitet i programmer. De er ikke ment for bruk i produksjon.
+ 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
  
- Hovedregel er at man ikke installerer testutgaver av programvare i produksjon. De fleste driftsoperatører anbefaler å bruke nest siste versjon av et program beregnet på produksjon. Etter 6-12 måneder er som regel de verste feilene plukket av en ny hovedutgave av et program.
+ 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.
  
  It means one often wait until summer before updating to a program that were reissued just before New Year. This fits well with the school year. The alternative may be instability and irritated users. Therefore the advisory group plays a key role when done small or large changes.
  
- == Utgivelsesledelse (Release Management) ==
+ == Release Management ==
  
- Utgivelseshåndteringen er administrasjon og planleggingsaktiviteter for å klargjøre for ønskede endringer. Endringene kan være små eller store der store endringer kan bestå av mange mindre delendringer. Utgivelseshåndringingen skjer før man setter igang selve jobben med å installere program- og maskinvare i produksjon.
+ Release handling is management and planning activities preparing for wanted changes. The changes can be small or large, where large changes can consist of many smaller changes. Release management goes on before initiating the actual job of installing software and hardware into production.
  
- Først gjennomføres planlegging og testing av nye utgivelser. Deretter så rulles det hele ut i produksjon. Utrulling er en del av infrastrukturledelse. Prosedyren er å gjennomføre det som er planlagt, testet, og ligger klar i systemene for konfigurasjonsstyring. Når alt er planlagt, testet og konfigurasjonene er lagret, så ruller man ut løsningen i drift.
+ First the planning and testing of new releases are carried out. Then it all is rolled out it into production. Deployment is part of the infrastructure management. The procedure is to implement what is planned, tested and is ready within the systems for Configuration Management. Once everything is planned, tested and configurations are stored, then roll out the solution in production.
  
- Som regel er mange tjenestetilbydere og leverandører involvert. Det gjelder både i forbindelse med anskaffelse av maskiner, den programvaren som brukes, og de konfigurasjonene som er anbefalt. God ressursplanlegging er grunnleggende for å kunne pakke og distribuere en ny utgivelse på en bra måte for brukerne. Slurver man på dette området kan man ende opp med at utstyret ikke virker, eller blir stående ubrukt fordi det er mangler ved installasjonen.
+ Usually, many service providers and suppliers are involved. This applies both to the procurement of machines, the software used, and the recommended configurations. Good resource planning is crucial to package and distribute a new release in a good way for users. Slipshod in this area can end up with equipment that doesn't work, or are left unused because of deficiencies in the installation.
  
- Utgivelsesledelsen tar et helhetlig grep ved endring i en tjeneste, og skal sikre at alle deler av en utgivelse ses i sammenheng. Det gjelder både for tekniske og ikke-tekniske forhold.
+ Release Management takes a comprehensive approach by the change in a service, and ensure that all parts of a publication is seen in context. This applies to both technical and non-technical factors.
  
- === Grunnleggende ===
+ === Basic ===
  
- Som man ser er utgivelseshåndtering helt grunnleggende for at datamaskiner, programvare og nettverket virker som planlagt. Skikkelig håndtering av utgivelser gjøres for å hindre driftsforstyrrelser. Ved nye utgivelser eller endringer er det forventet at driften skal gå som normalt uten avbrudd eller reduksjon i kvaliteten.
+ As you can see is the publication handling fundamental for computers, software and network to work as planned. Proper handling of releases is done to prevent disruptions. By new releases or changes it is expected that operations will continue as normal without interruption or reduction in quality.
  
- Håndtering av endringer eller nye utgivelser kan sammenlignes med å bygge ny vei. Bilene må fortsatt komme fram selv om man bygger ny vei oppå den gamle. God skilting må være på plass. Man må også ha de nødvendige ressurser til å legge om veien. Mangler man ressurser til å gjøre endringene så er det like greit å la vær.
+ Handling of changes or new releases can be compared to building a new road. Cars must still get past even if you build a new road atop the old. Good signage must be in place. One must also have the necessary resources to rebuild the road. If missing resources to make changes, it's just fine to let it be as it is.
  
- For noen kan det være kjedelig med skikkelig utgivelseshåndtering. Man får ikke brukt det nyeste nye hver gang det kommer noe nytt. Men som oftest er det ikke satt av ekstra tid i driftsavdelingen for å håndtere en flom av klager når helt ny programvare svikter. Linux-eksperten David Elboth slår fast at høye oppetider krever etablert teknologi. I LINUXmagasinet (1/2004) skriver han:
+ 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:
  
-  * Desto høyere krav desto strengere blir kravene til de enkelte komponentene. Høye krav til oppetid resulterer også at valgene du står igjen med er gammel teknologi. Det er nemlig erfaringsmateriale over tid som kan si noe om nedetid. Vi har alle lagt merke til hvor lenge etter Red Hat og SuSE ligger på sine serverprodukter.
+  * 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.
  
- === Sentralt programarkiv (DSL) ===
+ === Central program archives (DSL) ===
  
- Programarkivet i driftssammenheng er en samling av originalutgaven av den programversjonen av programvaren som er i produksjon. Bruker man Skolelinux 2.0 er det dette som er programarkivet. I dataverdenen brukes ordet programarkiv i flere sammenheng, spesielt når man programmerer. Når det gjelder drift snakker vi den originale sammensatte programvare av en bestemt versjon som er utgangspunktet for installasjonen.
+ The program archive in operational context is a collection of original edition of the program version of the software which are in production. If you use Skolelinux 2.0, this is the program archive. In the computer world, the word program archive in different contexts, especially when programming. When it comes to operation, we are talking about the original composed software of a particular version which is the base for the installation.
  
- Bruker man fri programvare kan programarkivet være Skolelinux 2.0 pluss de ekstra programmene man har lagt inn i tillegg fra forskjellige kilder. Det kan være bestemte versjoner av Macromedia Flash, Java og decodere som gjør det mulig å kjøre nasjonale prøver i nettleseren, eller se sendinger fra NRK.
+ Using free software the program archive may be Skolelinux 2.0 plus the extra programs you have added from various sources. There may be certain versions of Macromedia Flash, Java and decoders who make it possible to run national tests in the browser, or watching broadcasts from NRK.
  
- Har man planlagt og oppgradere til neste versjon av Skolelinux når den har kommet, vil det være den nye versjonen som blir hoved programarkiv. Også her vil alle ekstra programmer ut over ny Skolelinux være en del av arkivet.
+ If you plan to upgrade to the next version of Debian Edu when it comes, it will be the new version which is the main program arcive. Also here will all additional applications beyond new Debian Edu be part of the archive.
  
- Oppsettfiler som er justert eller laget lokalt av driftsavdelingen er følger ikke med som en del av hovedarkivet for programmer. Konfigurasjoner lagres i en egen versjonshåndtert katalog eller database.
+ Setup files adjusted or created locally by the operations department is not included as part of the main archive programs. Configurations are saved in a separate version handled directory or database.
  
- === Database for konfigurasjoner og maskinvare ===
+ === Database for configurations and hardware ===
  
- Som nevnt under kapitlet med konfigurasjonsstyring må man opprette en database eller en versjonshåndtert katalog for å ta vare på oppsettfiler. Man må også ha oversikt over alle datamaskiner, hva slags maskiner det er snakk om, ytelse, og unike standardadresser på nettverkskortene (MAC adresser).
+ As mentioned in chapter about configuration management, you must create a database or a version handled directory to take care of the setup files. One must also keep track of all computers, what kind of machines are involved, performance, and unique standard addresses on the network cards (MAC addresses)
  
- Det er mange grunner til å ha oversikt over utstyret. En av hovedgrunnene er å ha oversikt over hvor mange maskiner som er i drift, antall maskiner som ikke er i bruk, og antall maskiner på reparasjon. En annen grunn går på planlegging ved oppgraderinger. Det går både på hvor mye
+ There are many reasons to have an overview of the equipment. One of the main reasons is to keep track of how many machines are in operation, the number of machines that are not in use and the number of machines in repair. Another reason is planning on upgrades It is both the amount of.............?
  
- === Bygg-håndtering ===
+ === Construction management ===
  
- I skolen installeres en rekke program i tillegg til nettleser og kontorprogram. Det trengs pedagogiske program for læring, tilleggsprogram i nettleseren, og det trengs program for multimedia. Systemene har også nettverksoppsett og endrede innstillinger i bestemte programmer. Har man mange tjenermaskiner og kanskje tusenvis av klienter ser man raskt at det er behov for effektive verktøy for utrulling. Slike verktøy er standard i Skolelinux.
+ A variety of applications in addition to browser and office suite are beeing installed in schools. Educational programs for learning, additional programs in the browser, and programs for multimedia are needed. The systems also have network setup and changed settings in specific programs. If you have many servers and perhaps thousands of clients quickly reveals quickly the need for effective tools for deployment. Such tools are standard in Debian Edu.
  
- Bygg-håndtering handler om å få installert de ønskede programpakkene, tjenestene og riktig innstillinger både av enkelte program og datanettverket. Mange har hørt om å bygge såkalte «images». Man installerer operativsystem og alle de programmene man trenger. Stiller inn nettverket. Deretter bruker man et image-program for å lage en kopi av det som er installert på harddisken. Dette kopieres så ut til de andre datamaskinene.
+ Construction management is about getting installed the required software packages, services and proper settings both of individual programs and data network. Many people have heard about so called "images". One installs operating system and all the programs needed. And adjust the network. Then use a image program to make a copy of the one installed at your hard drive. This is then copied at the other computers.
  
- Det er slett ikke nødvendig å bygge såkalte «images» eller diskbilder man kan kalle det på norsk. Skolelinux bygger på Debian som har et utmerket pakkesystem. Man trenger på ingen måte å kompilere programmer da dette er ferdig satt sammen, og kan installeres rett fra Internett. Det man må ha orden på er ønskede endringer i standardoppsettet til Skolelinux eller hoved programarkivet som er i bruk. Deretter lager man et eller flere skript som kan kjøre på de forskjellige maskinene for å få alt installert og satt opp.
+ It is not necessary to build so-called "images" or disk images you can call it in Norwegian. Debian Edu is based on Debian which has an excellent package management system. One does not in any way to compile applications as this is preassembled and can be installed directly from the Internet. one must have in order is wanted changes to the default setup of Debian Edu or the main program archive in use. Then you make one or more scripts running on different machines to get everything installed and set up.
  
- For de fleste situasjoner er skripting en enkel måte å «bygge» og rulle ut programmer og oppsett. Men det er situasjoner der bygging av diskbilder kan være løsningen. F.eks. ved installasjon på mange bærbare datamaskiner.
+ For most situations, scripting are an easy way to "build" and roll out programs and setups. But there are situations where the construction of disk images may be the solution. For ecample during installation on many laptops.
  
- Som vi ser handler håndtering av bygg-prosessen om å tilrettelegge for utrulling på mange datamaskiner. Helt unntaksvis handler det om å bygge en skreddersydd Debian-pakke. Men i de aller fleste situasjoner er alt pakket ferdig. Da må man få på plass et skript for som installerer ekstra programmer og bestemte innstillinger. Man kan også lage diskbilder om man har mange like maskiner, som f.eks. bærbar PC til alle elevene.
+ As we see, handling the construction process is about facilitating deployment on many computers. In exceptional cases, it's about building a tailor made Debian package But in most situations, all packaging is finished. Then you have to put in place a script which installs additional programs and certain settings. One can also create disk images if you have many similar machines, such as laptops to all students
  
  === Testing ===
  
- Det er helt avgjørende å teste nye programmer, konfigurasjoner, og nye tjenester før de settes i produksjon. Flere skoler har erfart ustabilitet fordi de har installerer programvare uten å gjøre de nødvendige justeringene. Derfor er det helt avgjørende å teste endringer i konfigurasjoner eller ny versjon av programvaren før endringen gjøres på alle maskinene.
+ It is essential to test new applications, configurations, and new services before they are put into production. Several schools have experienced instability because they have to install software without making the necessary adjustments. Therefore it is crucial to test changes in configurations or new version of the software before the change is made on all machines.
  
- Testing skjer gjerne i tre steg.
+ Testing generally takes place in three steps.
  
   * First, do an installation of the changes on a test network. This is technically testing guaranteing that everything connect and works in a system without users. Retain all changes in configuration files.
-  * Når man er sikker på at alt virker på den tekniske siden prøveinstalleres løsningen på en skole. Det er svært viktig å avtale testingen med skolens IT-kontakt. Brukerne må også få full orientering om at det vil bli endringer fordi man utfører testing. Ta vare på aktuelle justeringer i oppsettfiler som er gjort underveis ut fra de driftsmeldingene som har kommet.
-  * Når man er sikker på at alt virker kan man rulle ut løsningen til alle skolene. Det gjøres enklest med å lage et skript som forenkler oppgradering av programpakker, tjenester og konfigurasjoner.
+  * When one is sure that everything works on the technical side, try installing the solution to a school. It is very important to agree about the testing with the schools ICT contact. Users must also get full briefing on the changes because of testing is performed. Retain current adjustments in the setup files, which are made along the way from the operating messages that have arrived.
+  * When one is sure everything works, you can roll out the solution to all schools. It is easiest to create a script that simplifies upgrading of software packages, services and configurations.
  
- === Reserveløsning ===
+ === Back up solution ===
  
- Mye kan gå galt under en ny installasjon eller oppgradering. Derfor må man ha klar en reserveløsning. Det betyr at man på kort tid kan ta i bruk systemet slik det var før oppgraderingen. På fagspråket heter dette tilbakerulling.
+ Much can go wrong during a new installation or upgrade. Therefore, one must have ready a fallback solution. It means one quickly can use the system as it was before the upgrade. In technical terms, this is called rollback.
  
- Når man skal rulle tilbake er det helt avgjørende å ha klar forrige versjon av arkivet for programvare og oppsettfiler. Det betyr at man kan installere f.eks. Skolelinux 1.0 på under en time, og legge på plass aktuelle konfigurasjonsfiler.
+ When rolling back it is absolutely essential to have ready the previous version of the software archive and configuration files. It means that you can install for example Edu 1.0 in under an hour, and put it in place the appropriate configuration files.
  
  Men tilbakerulling tar tid. Derfor kan det være greit å ha en tjenermaskin klar med forrige utgave av programvaren, de riktige konfigurasjonene, og hjemmekatalogene til brukerne. Denne tjeneren kan raskt erstatte maskinene som ble oppgradert, men ikke virket etter planen. Ved å ha tjenermaskin(er) i reserve kan man sørge for høy tilgjengelighet selv om noe skulle gå galt.
  
@@ -502, +502 @@

  
  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.
  
- === Planlegging og implementasjon ===
+ === Planning and implementation ===
  
  Årsaken til at man planlegger før man gjennomfører endringer er for å hindre uker eller ekstra måneder med problemer. Selv om man skulle bruke noe ekstra tid på planlegging, så tjenes dette raskt inn fordi man unngår ekstra problemer. Det vil alltid være personer som forteller at de ikke har hatt problemer med ad-hoc-endringer i systemene. Men når man undersøker nærmere viser det seg at det er problemer etter endringer, og at henvendelser om dette ikke formidlet videre.
  
@@ -512, +512 @@

  
  Hovedpoenget er at det er få snarveier når det kommer til planlegging og implementasjon. Undersøkelser viser at de som planlegger skikkelig og sørger for at folk har riktig kompetanse har lavere driftskostnader knyttet til driften.
  
- === Aktiviteter ===
+ === Activities ===
  
  Det er helt avgjørende å planlegge nye utgivelser. De fleste endringer av systemet skal avklares med ledelsen. Følgende liste over aktiviteter er laget som støtte ved oppgraderinger i en plan- og gjennomføringsfase.
  
@@ -543, +543 @@

  </td>
  </tr>
  <tr class="odd">
- <td align="left">Bygg-håndtering
+ <td align="left">Construction management
  </td>
  <td align="left">Alle skript og systemer som brukes til utrulling eller å lage diskbiler (images) må på plass.
  </td>
@@ -555, +555 @@

  </td>
  </tr>
  <tr class="odd">
- <td align="left">Reserveløsning
+ <td align="left">Back up solution
  </td>
  <td align="left">Selv med omfattende testing kan nye utgivelser gå galt. Derfor er det avgjørende å ha en reserveløsning. Den enkleste reserveløsningen er å ha den gamle installasjonen med data på en egen tjenermaskin. En slik maskin kan plugges inn om endringen eller oppgraderingen ikke virker.
  </td>
@@ -563, +563 @@

  </tbody>
  </table>
  
- === Verktøy ===
+ === Tools ===
  
  Som man ser av aktivitetslisten trenger man flere verktøy for å holde orden på forskjellige utgivelser av programvaren, tjenester og maskinvare i systemet. Noen av disse verktøyene er nevnt tidligere. Men vi gjentar dette allikevel: