[debian-edu-commits] [Debian Wiki] Update of "DebianEdu/Documentation/en/ITIL/Delivery" 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/Delivery" page has been changed by AlexanderAlemayhu:
https://wiki.debian.org/DebianEdu/Documentation/en/ITIL/Delivery?action=diff&rev1=3&rev2=4

  
  For the structure of the SLA, see [[#Delivery--content-service-level-agreement|section in the service level agreement]].
  
- === Driftssituasjonen ===
+ === The operational situation ===
  
- Overvåkning av faktisk oppnådd tjenestenivå og rapportering tilbake til kunden er vesentlig for å bevare en god relasjon mellom driftssenteret og brukerne. Format og detaljeringsnivå for rapportering skal være håndtert i tjenestenivåavtalen.
+ Monitoring of actually achieved service levels, and reporting back to the customer, are essential to preserve a good relationship between the Service Desk and the users. Format and level of detail for reporting, should be dealt with in the SLA.
  
- Det skal avholdes periodiske (f.eks. kvartalsvise eller halvårlige) møter med kunden. Fra disse møtene bør det komme konkrete planer for neste periode og f.eks. avtalt implementering av nye tjenester.
+ It must be held periodic, for example quarterly or semiannually, meetings with the client. These meetings should result in concrete plans for the next period and, possibly, agreed implementation of new services.
  
- === Innhold i tjenestenivåavtalen ===
+ === Content of the Service Level Agreement (SLA) ===
  
  ==== Introduction ====
  
- Navn og kontaktinformasjon for avtalepartene, beskrivelse av tjenestene som inngår, varighet på avtalen, ansvarsforhold mellom kunde og leverandør.
+ Name and contact information for the Contracting Parties, description of the services included, duration of the agreement, responsibility between customer and supplier.
  
  ==== Service time ====
  
- Hvilket tidsrom avtalen gjelder (f.eks. mandag-fredag 08:00 - 16:00), eventuelle spesielle krav for bestemte tidspunkter (f.eks. eksamen), rutiner for å bestille utvidelse av tjenestetiden.
+ In which time the agreement applies, like Monday to Friday 8:00 a.m. to 4:00 p.m., any special requirements for certain times (for example exams), routines to order expanded time.
  
  ==== Availability ====
  
- Tilgang til tjenestene. Måles best som den tiden en eller flere tjenester har vært utilgjengelig i en periode (f.eks. en kalendermåned). Det kan avtales forskjellige nivåer for forskjellige tjenester (f.eks. avhengig av viktighet for brukerne).
+ Access to the services. Is best measured as the time, period, one or more services have been unavailable, for example a calendar month. Different levels for different services may be agreed, for example depending on the degree of importance for users.
  
- Viktig å presisere at dette er tilgjengelighet innenfor den avtalte tjenestetiden, ikke den total tilgjengelighet hele døgnet, hele uka og hele året (såkalt 24/7/365). F.eks. kan det være avtalt at systemet skal være tilgjengelig mellom kl. 08 til 18 på arbeidsdager, etter det og i helger er det mer usikkert om en kan bruke datasystemet om ikke annet er avtalt.
+ Important to emphasize that this is availability within the agreed period of service, not the overall availability all day, all week and all year round (called 24/7/365). For example, it may be agreed that the system should be available between the hours. 8 to 18 on workdays, after that and on weekends it is more uncertain whether one can use the computer system, unless otherwise agreed.
  
- Tilgjengelighet handler også om når man får brukerstøtte via telefon eller e-post. F.eks. kan servicekontoret nås mellom kl. 08 og 16 på dagen, eller hele døgnet. Skal man ha mulighet for brukerstøtte på ettermiddag og kvelden, eller i bestemte helger.
+ Availability is also if one gets support via phone or email. For example, can the Service Desk be reached between the hours 08 and 16 at day time, or all day. May one have the possibility of support in the afternoon and evening, or in specific weekends?
  
  ==== Stability ====
  
- Måles ofte som antall ganger med nedetid i en periode eller som gjennomsnittlig tid mellom episoder med nedetid. Man kan også måle tiden det tar før systemet kommer opp igjen.
+ Is often measured with the number of times of downtime for a period, or that the average time between episodes of downtime. One can also measure the time it takes to the system comes up again.
  
- ==== Brukerstøtte ====
+ ==== Support ====
  
- Måles ofte som svartid på telefon (f.eks. 1 minutt) eller e-post (f.eks. 30 minutter) ved henvendelser fra brukerne. Når driftsoperatør får en henvendelse om brukerstøtte vil meldingen bli kategorisert etter alvorlighetsgrad sammen med tidsgaranti for svar. Det kan også være avtale om hvor fort feilretting skal starte, noe som vil avhenge av hva slags kategori henvendelsen har fått.
+ Often measured as response times by phone (for example 1 minute) or email (for example 30 minutes) at requests from users. When the operator gets a request for support, the message will be categorized by severity with a time guarantee for answers. There may also be an agreement about how fast error correction will start, which will depend on what kind of received inquiry.
  
- Brukerstøtten handler også om når i døgnet man får tak i folk. Skal brukerstøtten være tilgjengelig i skolens åpningstid mellom kl. 08 og 16, eller skal man også ha brukerstøtte ut over kvelden eller på helgedager. Noen vil ha brukerstøtte også på bestemte helgedager.
+ The support is also about when during the day or night one reach people. Should support be available during school hours between 08 and 16 o'clock, or should one also have support throughout the evening or on weekends. Some will have support also on certain holidays.
  
- Perioden for når brukerstøtten er tilgjengelig står som regel i tjenestenivåavtalen. Det avtales også om hva brukerstøtten skal hjelpe til med innen for en fast pris, og hva som må løses på oppdragsbasis. Avtalen regulerer prosessen det er å behandle henvendelser, både med hva som vil fikses, og når dette vil skjer.
+ The period when support is available is usually in the SLA. It is also agreed what support will assist with to a fixed price, and what must be resolved additionally on an assignment basis. The agreement regulates the process of handling inquiries, both what to fix, and when this will happen.
  
  ==== Capacity ====
  
- Kan måles som gjennomsnittlig svartid ved bestemte operasjoner i bestemte applikasjoner. Skal måle brukeropplevelsen av systemet.
+ Can be measured as the average response time by certain operations in specific applications. Will measure the user experience of the system.
  
- ==== Endringshåndtering ====
+ ==== Change management ====
  
- Mål for tid til håndtering, godkjennelse og implementering av endringsforespørsler fra brukerne.
+ Measures for time management, approval and implementation of change requests from users.
  
  ==== Security ====
  
- Kan måles som antall fastslåtte sikkerhetshendelser i en periode. Det er svært viktig å være tydelig på hver enkelt brukers ansvar for at garantier skal gjelde.
+ Can be measured as the number of ascertained security incidents in a period. It is very important to be clear on each user's responsibility to ensure that warranties will apply.
  
  ==== Billing ====
  
- Priser, tidspunkt for fakturering og oppgjørsbestemmelser.
+ Prices, times for billing and settlement provisions.
  
- ==== Rapportering og oppfølging ====
+ ==== Reporting and follow-up ====
  
- Beskrivelse av regler og perioder for rapportering av målt tjenestenivå. Det anbefales regelmessige møter (f.eks. kvartalsvis) for å gå gjennom rapporten og planlegge fremover.
+ Description of rules and periods for reporting of measured service levels. It is recommended regular meetings, for example quarterly, to go through the report and plan ahead.
  
- ==== Straffereaksjoner og eventuelle incentiver ====
+ ==== Sanctions and possible incentives ====
  
- Regler for reduksjon i pris hvis avtalt tjenestenivå ikke er oppfylt. Eskaleringsrutiner og regler for heving av avtale ved kontinuerlig brudd på garantert tjenestenivå. Eventuelle incentiver ved oppnåelse eller bedre enn forventet tjenestenivå.
+ Rules for pricereduction if the agreed service is not met. Escalation procedures and rules for cancellation of agreement by continuous violations of guaranteed service level. Possible incentives for achievement or better than expected service.
  
- Se appendiks A for tjenestenivåavtale.
+ See Appendix A for SLA.
  
- == Økonomisk styring (Financial Management) ==
+ == Financial Management ==
  
  Organizations rarely have a full overview of their ICT spending. A 2001-survey of Norwegian municipalities showed that only 1 of 8 municipalities had an ICT budget. Probably it is not better for school. Putting in place an ICT budget is important. Often users think they pay too much for a service they are not happy with. This creates many times conflicts between users and the ICT department.
  
- Det er svært nyttig både for driftssenteret og brukerne å få dokumentert de reelle IT-kostnadene. Uten dette blir det vanskelig å budsjettere riktig. Ikke minst blir det vanskelig å gjøre en kost/nytte-vurdering av eksisterende IT-løsninger. Rektor bør kjenne IT-budsjettet like godt som hun kjenner lønnsbudsjettet, eller budsjettet over læremidler.
+ It is very useful for both the operations center and users to document the real ICT costs. Without it is difficult to budget appropriately. Not least, it is difficult to make a cost/benefit assessment of existing ICT solutions. Rector should know the ICT budget as well as she knows salary budget, or the budget of teaching aids.
  
- Det er tre viktige prosesser knyttet til økonomisk styring av IT-tjenestene:
+ There are three major key processes related to financial management of ICT services:
  
-  1. Budsjettering
+  1. Budgeting
-  1. Regnskapsføring
+  1. Accounting
   1. Billing
  
- === Budsjettering ===
+ === Budgeting ===
  
- Målet med budsjettet er å lage et realistisk anslag over forventede IT-kostnader. Budsjetteringen inneholder som regel forskjellige alternative løsninger. Det gjelder både i forhold til utstyr og programvare, og nivået man vil legge seg på. Budsjettet er utgangspunkt for senere budsjettforhandlinger med skolesjefen og/eller politikerne.
+ The objective of the budget is to make a realistic estimate of the expected ICT costs. Budgeting usually contains various alternative solutions. It applies both to equipment and software, and the level you want to lay on. The budget is the starting point for subsequent budget negotiations with the director of education and/or politicians.
  
- Budsjettet skal inneholde både personal- og utstyrskostnader. En del virksomheter regner bare på hva det koster å kjøpe utstyr. Da utelater man så mye som 60-70% er personalkostnader ved drift av en IT-løsning. Man må også få med alt av utstyr.
+ Budget must include both personnel and equipment costs. Some organisations count only on costs to buy equipment, omitting as much as 60 - 70 % personnel costs for the operation of an ICT-solution. One must also get all of the equipment.
  
- Det er eksempler på kommuner som har glemt å regne med kostnader til strømkontakter og datanettverk på skolene. Da har man glemt ca. 2000 kroner pr. klientmaskin. Skal man få på plass 70 nye datamaskiner snakker vi fort om 140.000 kroner til datanettverk og strøm.
+ There are examples of municipalities forgetting to count the cost of power connectors and computer networks in schools. Then you have forgotten about 2000 NOK(around 170£) per client machine. Should we put in place 70 new computers we talk soon about 140,000 NOK to computer networks and power.
  
  Alternative solutions are also important to include in the budget. This applies both for the operation and the equipment. Today there are several vendors who specialize in the operation of computer equipment in schools with varying prices and quality. Number of simultaneous users and type machines and software to be maintained, also means a lot.
  
- Skal man ha bærbar PC til alle lærere og elever vil man fort få 5-6 ganger høyere driftskostnader enn om man har stasjonære PC-er med tre elever for hver klientmaskiner.
+ If you want a laptop for all teachers and students one will easily get 5-6 times higher costs than if you have desktops with three students for each client machines.
  
  === Accounting ===
  
- Regnskapet vil i all hovedsak bestå av fakturaene for innkjøpt av utstyr, kabling, reparasjoner, drift og ekstra tjenester. Når regnskapsperioden er over er det viktig å gå gjennom tallene og sammenligne dette med budsjettet.
+ The accounts will mainly consist of invoices for purchased equipment, cabling, repair, operation and extra services. When the accounting period is over, it is important to go through the numbers and compare this with the budget.
  
- === Planlegging av regnskap og fakturering ===
+ === Planning accounting and billing ===
  
- Ikke alle kommuner har regnskapssystem som viser IT-kostnadene brutt ned på hver skole. Det kan være praktiske grunner til dette som for eksempel rabattordninger og lignende som kommunen får sentralt. Derfor er det viktig å gjøre litt planlegging slik at man får oversikt over hva kostnadene har vært med drift og anskaffelser når regnskapet skal vurderes opp mot budsjettet.
+ Not all municipalities have accounting that shows ICT costs broken down by each school. There may be practical reasons for this, such as discounts and the like that the municipality gets centrally. Therefore it is important to do some planning so that you get an overview of what costs have been for operating and procurement when the accounts should be assessed against the budget.
  
- En del organisasjoner kan ha tungvinte og kostbare regnskapsrutiner. Man får fort ekstra kostnader med å betale regninger ved forsinkelser, eller om man har mange som skal godkjenne en utbetaling. Så det er viktig å bli enig om gode faktureringsrutiner ved anskaffelse og drift slik at man både har kontroll, men også håndterer betaling i tide uten lange beslutningsveier.
+ Some organizations may have cumbersome and costly accounting procedures. You get fast extra charge to pay bills by delays, or if you have many who shall approve a payment. It is important to agree on good billing practices in the procurement and the operation. For both having control, as well as handling payments on time without long decision paths.
  
  === Implementation ===
  
- Betalingsmåte er regulert av tjenestenivåavtalen. Når det gjelder regnskapssystemet må man bli enig med økonomiavdelingen om en praktisk måte å få rapporter på, slik at man får den ønskede regnskapsoversikten over IT-kostnadene uten at det tar lang tid å få ut oversikten.
+ The payment method is regulated by the SLA. One must agree with the finance department for a convenient way to get reports from the accounting, to get the necessary accounting overview of ICT costs without it takes a long time to get out the overview.
  
- === Daglig drift ===
+ === Daily operation ===
  
- Når det gjelder driftsavtaler vil man vanligvis ha en fast månedlig fakturering som består av et fast beløp og eventuelle ekstra tjenester. Fakturering gjøres fra regnskapskontoret ut fra de driftsavtalene man har, og de ekstra tjenestene som er utført. Det er viktig med god og hyppig kontakt med regnskapstjenesten ut fra de oppdrag som er utført for kunden.
+ Regarding contracts one will usually have a fixed monthly billing consisting of a fixed amount and possible additional services. Billing is done from accounting office based on the current operating agreements, and the extra services performed. It is important to have good and frequent contact with the accounting service based on the tasks carried out for the customer.
  
- == Kapasitetsplanlegging (Capacity Management) ==
+ == Capacity Management ==
  
- Kapasitetsplanlegging brukes for å sikre at alle deler av IT-løsningen har tilstrekkelig kapasitet til å ivareta brukernes krav. Dette omfatter:
+ Capacity planning is used to ensure that all parts of the ICT solution has sufficient capacity to safeguard users' requirements. This includes:
  
-  * Overvåkning av ytelsen til IKT-tjenestene med tilhørende infrastruktur
-  * Konfigurasjon av systemene for å sikre at de utnyttes optimalt i forhold til det brukerne faktisk gjør
-  * Forståelse av brukernes behov og planlegging av eventuelle endringer på systemene for å ivareta fremtidige behov
-  * Ressursplanlegging i samarbeid med budsjettansvarlig
-  * Utarbeidelse av en kapasitetsplan for å sikre leveranse av driftstjenester i samsvar med avtalt tjenestenivå
+  * Monitoring the performance of IST 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
+  * Preparation of a capacity plan to ensure delivery of operations in accordance with the agreed service level
  
- Kapasitetsplanlegging handler om å balansere:
+ Capacity planning is all about balance:
  
-  * Kostnader mot kapasitet. Budsjettet setter grenser for hva slags løsninger som er mulig å implementere
-  * Tilbud og etterspørsel. Systemene må ha kapasitet til å kunne håndtere de krav som stilles av brukerne
+  * Costs against capacity. The budget limits what kind of possible solutions to implement
+  * Supply and demand. The systems must have capacity to handle the demands set of the users
  
- Målet med kapasitetsplanleggingen er å unngå overraskelser.
+ The objective of capacity planning is to avoid surprises.
  
  === Surveillance ===
  
- Det er avgjørende for god kapasitetsplanlegging at systemene overvåkes kontinuerlig for å fremskaffe det nødvendige datagrunnlaget.
+ It is essential for good capacity planning that the systems are continuously monitored to obtain the necessary data.
  
- Typiske data som overvåkes er:
+ Typical data which are monitored are:
  
-  * Prosessorutnyttelse
-  * Minneutnyttelse
-  * Prosessorbruk pr oppgave
-  * Svartider for brukerne pr oppgave
-  * Skriverstyring - antall utskrifter, kølengder, utskriftstid
+  * Prosessor utilization
+  * Memory utilization
+  * CPU usage per task
+  * Response times for users per task
+  * Printer management - the number of prints, queue length, time for print outs
   * Storage capacity
-  * Antall klienter
-  * Antall pålogginger
-  * Antall samtidige brukere
+  * Number of clients
+  * Number of logins
+  * Number of simultaneous users
  
- I Skolelinux er det Nagios som brukes som overvåkningsverktøy.
+ In Debian Edu, the Nagios used as a surveillance tool.
  
- === Analyse ===
+ === Analysis ===
  
- På bakgrunn av innsamlede data fra overvåkningsrutinene forsøker man å avdekke eventuelle flaskehalser i systemene. Eksempler:
+ On the basis of data collected from monitoring routines, one tries to identify any bottlenecks in the systems. Examples:
  
-  * Dårlig eller ujevn utnyttelse av maskinvaren
-  * Dårlig designet programvare
-  * Dårlig utnyttelse av minnekapasitet
-  * Flaskehalser på datalagring, minne eller prosessor
+  * Poor or varying utilization of hardware
+  * Poorly designed software
+  * Poor utilization of memory capacity
+  * Bottlenecks on data storage, memory or processor
   * Bottlenecks in the network
  
  === Configuration ===
@@ -203, +203 @@

  
  Here is a list of commonly encountered bottlenecks and what to do to get rid of them:
  
- ||'''Bottlenecks'''||'''Tiltak'''||
+ ||'''Bottlenecks'''||'''Actions'''||
  ||Missing sound, USB stick support and DVD on thin clients.||Install diskless workstations (> 800 Mhz processor, > 256 MB RAM)||
- ||Har 60 tynnklienter koblet til tjenermaskinen og ønsker flere PC-er.||Sats på halvtykke klienter, eller installer enda en tynnklient-tjener||
- ||Tynnklienter går tregt etter vi utvidet med 20 stykker uten å skaffe ny tjenermaskin||Installer 2 GB mer minne på tjenermaskin||
- ||Tynnklienter med 32 MB minne starter ikke etter oppgradering til Skolelinux 2.0||Skru på mellomlager (swap) på tynnklientene, eller nedgrader til LTSP 4.2 som er satt opp med swap.||
- ||Flash animasjoner gjør at tynnklientene går tregt når 50 elever er logget inn på samme tjenermaskin||Installer halvtykke klienter||
+ ||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.||
+ ||Flash animations make the thin clients slow when 50 students are logged into the same server machine||Install diskless clients||
  
  === Implementation ===
  
- Implementering av eventuelle endringer av systemkonfigurasjonen må gjøres i samsvar med de retningslinjer som er satt for endringer av systemet. En godt planlagt test av funksjon og ytelse må også gjøres før endringene kan gjøres i produksjonssystemet. Testingen gjøres for å unngå driftsforstyrrelser når endringene settes i produksjon.
+ Implementation of possible changes the system configuration must be done in accordance with the guidelines set for changes of the system. A well-planned test of function and performance must also be done before changes can be made in the production system. Testing is done to avoid operational disturbances when changes are set into production.
  
- === Utarbeidelse av kapasitetsplanen ===
+ === Making of the capacity plan ===
  
- En kapasitetsplan er i utgangspunktet en investeringsplan for IKT-systemet basert på kjennskap til brukernes nåværende behov og fremtidige planer.
+ A capacity plan is basically an investment plan for the ICT system based on knowledge of the users' current needs and future plans.
  
- Kapasitetsplanen bør oppdateres og behandles en gang i året, normalt i forbindelse med budsjettprosessen. Planen bør inneholde følgende områder:
+ The capacity plan should be updated and processed once a year, normally in conjunction with the budget process. The plan should include the following themes:
  
   * Introduction
-  * Forutsetninger
+  * Precondition
   * Summary
-  * Nåværende og fremtidige brukerbehov
-  * Tjenestesammendrag
-  * Ressurssammendrag
-  * Forbedringsområder
-  * Kostnadsmodell
+  * Current and future user needs
+  * Service summary
+  * Resource summary
+  * Areas for improvement
+  * Cost model
   * Recommondation
  
- == Tilgjengelighetsstyring ==
+ == Availability management ==
  
- God og stabil tilgjengelighet av IKT-tjenestene er selvsagt helt avgjørende for brukerne.
+ Good and stable availability of ICT services is obviously crucial for users.
  
- Tilgjengelighet sett fra brukerperspektiv avhenger av følgende forutsetninger:
+ Availability, seen from the user perspective, depends on the following assumptions:
  
-  * Tilgjengelighet av tekniske komponenter
+  * Availability of technical components
-  * Feiltoleranse
+  * Failure tolerance
-  * Kvalitet på vedlikehold og brukerstøtte
-  * Prosedyrer og rutiner for håndtering av driftstjenestene
-  * Sikkerhet, integritet og tilgjengelighet av data
+  * Quality of maintenance and support
+  * Procedures and routines for handling operational services
+  * Security, integrity and availability of data
  
- Tilgjengelighet kan måles på flere måter. Men før vi viser eksempler peker vi på hva som kan være vanskelig med måltall. Om det skal jobbes systematisk med tilgjengeligheten må man avklare hva de forskjellige tingene betyr. Hva betyr f.eks. et prosenttall for tilgjengelighet.
+ 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.
  
- La oss si at det er en «datamaskin med dataprogram» er en tjeneste. Om dataprogrammet ikke fungerer en dag, er da tjenesten utilgjengelig når alle de andre programmene fungerer helt greit. Hva om dataprogrammet er utilgjengelig for et klasserom, men tilgjengelig på resten av skolen (på grunn av en underliggende tjeneste). Dette er vanskelig materie å avklare, og jobbe med i praksis.
+ 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.
  
- === Måltall for tilgjengelighet ===
+ === Measures for availability ===
  
- Tilgjengelighet kan måles på flere måter. Her er noen eksempler:
+ Availability can be measured using several methods. Here are some examples:
  
- ||'''Måleverdi'''||'''Betydning'''||
+ ||'''Value'''||'''Meaning'''||
- ||% available||Verdien kan være tilgjengelighet mellom kl 08:00 til 18:00. Er systemet nede 1 time i løpet av en dag, er systemet tilgjengelig i 90% av den avtalte tiden. Måles tilgjengelighet over en måned med 20 arbeidsdager, så er systemet tilgjengelig i 95% av tiden.||
- ||% unavailable||Er systemet nede 1 time i løpet av en avtalt driftstid på f.eks. 10 timer om dagen, er systemet utilgjengelig i 10% av tiden. Måles dette over 20 arbeidsdager snakker vi om at systemet har vært utilgjengelig i 5% av tiden.||
- ||Antall timer utilgjengelig||Man kan avtale antall ganger man godtar at systemet er utilgjengelig i løpet av f.eks. en måned (20 arbeidsdager). Det kan være maksimalt 1 time utilgjengelighet i den perioden, og mellom 08:00 til 18:00.||
- ||Feilhyppighet||Også feilhyppighet kan måles pr dag eller hver måned. 3 feil i måneden for at systemet er nede mellom 08:00 til 18:00 er et eksempel.||
- ||Konsekvenser av feil||Måleverdiene er et vanlig utgangspunkt for å bedømme om en feil skal få konsekvenser ut over vanlig feilretting. Kunden eller skolen kan f.eks. be om å betale mindre for driftsavtalen for aktuell måned.||
+ ||% 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.||
+ ||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.||
  
  The most important is that your measure describes the user experience in the best possible way. Therefore, one should measure what is important for the user.
  
- Tilbakemeldingen fra skolene er at det er skrivere som gir mest problemer. Det gjelder alt fra at skriverkøen har stoppet opp, til at papir eller toner mangler. Enkelte har også opplevd noe ustabilitet med nettleseren, og at kontorprogrammet OpenOffice.org blir hengende. Det kan skje når bredbåndsforbindelsen er ustabil og man har linker i dokumenter som går ut på Internett.
+ The feedback from schools is that printers gives most problems. This includes everything from the print queue has stalled, to missing paper or toner. Some have also experienced some instability with the browser, and that OpenOffice.org suite is hanging. It may happen when your broadband connection is unstable and you have links in documents going to the Internet.
  
  === Infrastructure ===
  
- Skal man ha et stabilt datasystem er man avhengig av en god nok teknisk kvalitet på datanettet. Flere skoler har erfart ustabilitet fordi det fysiske datanettet er provisorisk og av dårlig kvalitet.
+ To have a stable computer system is dependent on a good enough technical quality of the network. Several schools have experienced instability because the physical computer network is provisional and of poor quality.
  
- Mange satser i dag på trådløse nett. Gjør man det må man også være klar over at trådløse nett har betydelige svakheter. Trådløse nett har begrenset kapasitet. Det gjør at det kan bli ganske hakkete om 30 elever skal se en filmsnutt fra Internett samtidig. Trådløse nett har også skygger. Det betyr at det er områder som ikke dekkes, noe som gjør at enkelte havner i blindsoner. Da får man dårlig eller ingen nettoppkobling i det hele tatt.
+ Today many invest in wireless networks. Doing so, one must also be aware of wireless networks having significant weaknesses. Wireless networks have limited capacity. It can be quite choppy when about 30 students are to see a film from the Internet simultaneously. Wireless networks also have shadows. Meaning areas may not get coverage, which allows some to end up in blind zones. This would provide poor or no net connection at all.
  
- Skal man stille krav til tilgjengelighet til vanligvis driftsselskap og IT-tjenester stille krav om god kvalitet på datanettet på skolen.
+ Should you set requirements to access, it is normally done by the operating company and ICT services to require good quality computer network at school.
  
  === «Single points of failure» ===
  
- Det er som regel deler i en dataløsning som bare må virke. Svikter f.eks. en brannmur og slutter å virke, så stopper det all trafikk til Internett. Man kan ha problemer med stabiliteten til system for tildeling av nett-adresser med DHCP (Dynamic Host Configuration Protocol).
+ Usually parts of a data solution must just work. Fails, for example, a firewall and stop working, stops all traffic to the Internet. One may also have problems with the stability of the system for allocating network addresses using DHCP (Dynamic Host Configuration Protocol).
  
- Driftsavdelingen har som ansvar og kjenne til de delene som kan stoppe hele dataløsningen. Det er viktig å finne disse punktene, og fjerne feilene en etter en, om dette er noe man har råd til. Hvis man ikke har råd til å fjerne feilkilder som kan stoppe f.eks. hele datanettet må man leve med risikoen om at noe plutselig ikke virker.
+ The operating department's responsibility is to know of the parts that may stop the entire data solution. It is important to find these points, and remove the errors one by one, if this is something you can afford. If one can't afford to remove sources of errors stopping for example. the entire computer network, one must live with the risk for something suddenly does not.
  
- Feilkilder som gjør at alt stopper kan også være logiske fremfor fysiske. Dette gjelder spesielt for datanett og databaser. Så det er viktig å ha et bredere perspektiv når det kommer til slike feilkilder.
+ Sources of error making everything stop, may also be logical rather than physical. This is especially true for computer networks and databases. So it is important to have a broader perspective when it comes to such errors.
  
  === Risk management ===
  
- Man må vurdere hva man aksepterer av risiko i datanettet. Er det akseptabelt at brukere mister personlige filer og data når en harddisk går i stykker? Hvor raskt skal man få på plass utstyr som har gått i stykker? Det er skoler som har erfart at det tar flere dager å få opp tjenermaskinen etter virusangrep. Kommunen har ikke ressurser å avsette til feilretting.
+ One must consider what one accepts of risks in the network. Is it acceptable that users lose personal files and data, when a hard drive fails? How quickly should one replace broken equipment? Some schools have experienced it takes several days to get the server up and go after a virus attack. The municipality has not resources to allocate to fix errors.
  
- Mye av arbeidet med drift går på å opprettholde tjenestenivået som er avtalt. Det handler om å unngå og miste tillit og brukertilfredshet. Risikostyring handler om å sette av passende ressurser til å holde hele datasystemet på lufta, og ha ressurser klar om noe skulle gå galt og må fikses.
+ Much of operation goes on to maintain the agreed service level. It's about avoiding and lose confidence and user satisfaction. Risk management is about having in place the appropriate resources to keep the entire computer system on the air, and have resources ready if something should go wrong, and needs to be fixed.
  
  === Testing ===
  
  It is a big difference to install equipment and software on a single PC and hundreds, even thousands of computers. With responsibility for hundreds of machines a small error, one can live with on a PC, mean much instability and discontent if the error affects hundreds of users.
  
- For å unngå at man gjør feil ved installasjon, og bidrar til stabilitet, er det helt avgjørende å teste utstyr og programvare som skal brukes. Det handler om å følge opp den forventede kvaliteten. Skal man ha stabil drift må man ofte velge nest siste utgave av utstyr og programvare.
+ To avoid making mistakes during installation and contributes to stability, it is essential to test equipment and software to be used. It's is to follow up the expected quality. If you want a stable operation one must often choose next to the last edition of equipment and software.
  
- Man bør unngå å ta i bruk programvare som som slutter med en null. F.eks. OpenOffice.org 2.0 bør man unngå. Man bør ta i bruk kontorprogrammet når versjon 2.0.2 har kommet eller nyere. Da har programpakken blitt fikset for flere feil. Det samme gjelder maskinvare.
+ One should avoid adopting software ending with a zero. For example you should avoid OpenOffice.org 4.0. One should adopt the office program when version 4.0.2 has arrived or later. Then the program has been fixed for several errors. The same applies to hardware.
  
  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.
  
- Når man gjør testing i mindre skala på utstyr som er i produksjon, er det helt avgjørende å avtale dette med de berørte. I tillegg må man velge tidspunkt for test. Man skal ikke test ut nye ting samtidig som det pågår f.eks. eksamensavvikling med bruk av IT-verktøy.
+ 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.
  
  === Design improvements ===
  
- En driftsavdeling vil være tjent med å utbedre systemer som gir mye driftsmeldinger. Det kan være at brukerne får mye søppelpost. Da kan det være greit å installere filer for søppelpost. Det kan være mye ekstra arbeide med elever som stadig glemmer passordet sitt, og lærere som sender henvendelsen til den sentrale drifsstaben. For å unngå ekstra e-posting og dobbeltarbeide så kan læreren selv gi eleven nytt passord.
+ An operations department will be served by correcting systems that provide much operational messages. It may be users getting much spam. Then it may be okay to install files for spam. There may be a lot of extra work with students who constantly forgets their password, and teachers who send the inquiry to the central drifsstaben. To avoid extra emailing and double work so the teacher can give the student a new password.
  
- Dette var et par eksempler på designforbedringer som letter arbeidet med drift, og gjør at brukerne blir mer fornøyd. En godt drevet driftsavdeling har en liste med prioriterte designforbedringer som gjør at driften blir enklere. Prioriteringene gjøres som regel ut fra en vurdering av henvendelsen til servicekontoret som man har lagret i meldingsloggen, og en vurdering av arbeidet som må gjøres for å behandle henvendelsene.
+ This was a some examples of design improvements to lighten the work of operation and allows users become more satisfied. A well-run operations department has a list of prioritized improvements in design making operation easier. The priorities is usually done based on an assessment of the inquiry to the service, stored in the message log, and an assessment of the work that must be done to treat the requests.
  
- === Planlegging for tilgjengelighet ===
+ === Planning for availability ===
  
- Det betyr at man har realistiske forventninger til IT-tjenesten ut fra hva driften koster. Planlegg hva som er forventet tilgjengelighet. F.eks. krever skolene at man skal være på lufta på under 1 time etter serverkræsj, så må man ha stående en ferdig installert maskin i reserve, hvor denne kan kobles inn som erstatning for den defekte maskinen. Det som gjøres i løpet av en time er å legge over sikkerhetskopierte filer til reservemaskinen.
+ It means having realistic expectations to the ICT service based on what operations costs. Plan for what's expected accessability. For example, when schools require one should be on air in less than one hour after the server crashes, one must have a standing pre-installed machine in reserve, to be inserted as replacement for the faulty machine. It's made during one hour to copy your backup files to the backup machine.
  
- Går en halvtykk eller tynn klient i stykker har man liggende et lite lager med maskiner og skjermer på skolen. Skolens IT-kontakt kan hente og installere en erstatningsmaskin. Dette kan gjøres enkelt og greit uten å vente i dagevis på utstyr som må bestilles.
+ Is a diskless or thin client broken a prepared small warehouse of machines and monitors is needed at the school. The school ICT contact can retrieve and install a replacement machine. This can be done easily without waiting days in ordering equipment.
  
- === Planlegging for gjenoppretting ===
+ === Planning for recovery ===
  
- Som eksemplet med utstyr som står klar til å erstatte defekt utstyr, så er det også forventet å kunne hente fram filer og data som har gått tapt. Derfor er det helt avgjørende å ha sikkerhetskopi av brukerdata og en kopi av oppsettfiler. Man må også ha arkitekturtegninger, og beskrivelser av systemet som gjør at IT-staben raskt kan få på plass systemene når noe går galt.
+ As the example of equipment standing ready to replace defective equipment, it is also expected to be able to retrieve lost files and data. Therefore it is crucial to have a backup of user data and a copy of the configuration files. One must also have computer architectural drawings, and descriptions of system, making ICT staff able to quickly install systems when something goes wrong.
  
- Det er helt avgjørende å planlegge sikkerhetskopiering av brukerdata og oppsett. Man må planlegge slik at man har riktig utstyr og passende tjenester. Det må også planlegges hvilke rutiner som skal følges når bestemte feilsituasjoner har skjedd, og systemene må gjenopprettes.
+ It is crucial to schedule backup of user data and settings. One must plan ahead in order to have proper equipment and appropriate services. Routines must be planned to be followed when certain error situations occurs and systems must be restored.
  
- == Driftskontinuitet (Service Continuity) ==
+ == Service Continuity ==
  
- Driftskontinuitet eller kontinuitetshåndtering er ofte det mest kostbare prosessen å jobbe med. Høye krav til driftskontinuitet vil kreve store investeringer, noe som avtales i arbeidet med SLA-en. F.eks. kan det avtales at det ikke er noen katastrofeplan for enkelte tjenester. Har man en katastrofeplan så er verdien svært lav om den ikke prøves en gang i blant. Som regle er dette dyrt. Det er eksempler der kunden og ledelsen har sperret maskinrommet og tatt strømmen for å teste beredskapen til IT-avdelingen.
+ Operating continuity or continuity management is often the most costly part of the work. High demands to operational continuity will require huge investments, which must be agreed in making the SLA. For example it can be agreed that there is no disaster plan for certain services. If you have a disaster plan the value is very low if not tested once in a while. Usually this is expensive. There are examples where customers and management have blocked the engine room and turned off power to test readiness of the IT department.
  
- Driftskontinuitet kan være aktuelt i bestemte perioder som ved eksamen. Da kan det stilles ekstra krav til å ha utstyr med backup klart i tilfelle en harddisk på tjenermaskinen skulle svikte. Men også dette vil kreve betydelig ekstraarbeide for driftsstaben.
+ Operating continuity may be appropriate in certain periods like under examinations. Then it may be extra requirements to have equipment with backup ready in case of a hard disk on the server fails. But even this will require considerable additional work for the operational staff.
  
- En IT-koordinator fortalte oss at det kan være like greit å utsette eksamen en dag om noe gikk galt med dataanlegget. Dette kostet mye mindre enn å ha et dobbelt antall med tjenermaskiner på hver skole. Det er eksempler på at skoler har hatt vannlekkasje. Da er det vanlige å utsette eksamen en dag eller to til skaden er utbedret. Man kan tenke på samme måte når det kommer til skolens dataløsning. Har man backup av hjemmekatalogene til elever og lærere har man tid til å områ seg uten å doble systemer på skolen. Da holder det med en eller to tjenermaskiner plassert på kommunehuset i reserve, som raskt kan kjøres ut og kobles opp på skolen om noe skulle gå galt.
+ An IT coordinator told us that it might be just as well to postpone the exam one day, if something went wrong with the computer system. This costs a lot less than having a double number of servers at each school. There are examples of schools having had water leakage. Then it is usual to defer examination a day or two to repair the damage . One might think the same way when it comes to school data solution. If you have a backup of home directories for pupils and teachers, you have time to consider without doubling systems at each school. Then it is sufficient with one or two servers in reserve located at the municipality building, which quickly can be moved and connected at the school if something goes wrong.