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

Mon Mar 30 15:26:40 UTC 2015

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Debian Wiki" for change notification.

The "DebianEdu/Documentation/en/ITIL/Delivery" page has been changed by AlexanderAlemayhu:
https://wiki.debian.org/DebianEdu/Documentation/en/ITIL/Delivery?action=diff&rev1=2&rev2=3

- = Tjenesteleveranse (Service Delivery) =
+ = Service Delivery =
  
- Hovedformålet med tjenesteleveranse er å sikre proaktiv drift og at IT-tjenesten leverer passende støtte for brukerne. Hensikten med tjenesteleveranse er å fokusere på virksomhetens behov. Det er aktiv læring med bruk av IT-verktøy i de forskjellige fagene som er behovet i skolen. Dette kapitlet beskriver i rekkefølge:
+ The main purpose of service delivery is to ensure proactive operation and ICT service delivers appropriate support for users. The purpose of service delivery is to focus on your organization's needs. It is active learning, with use of ICT tools in the different subjects, the school needs. This chapter describes in order:
  
-  * Tjenestenivåhåndtering
-  * Økonomistyring
-  * Kapasitetshåndtering
-  * Kapasitetsplanlegging
-  * Tilgjengelighetskontroll
-  * Driftskontinuitet
+  * Service level management
+  * Economy management
+  * Capacity handling
+  * Capacity planning
+  * Accessibility control
+  * Operational continuity
  
- == Tjenestenivåhåndtering ==
+ == Service level management ==
  
- Vi har oversatt det som ofte er kjent som forkortelsen SLA (Service Level Management) til tjenestenivåhåndtering. Håndtering av tjenestenivå handler om kvaliteten på driftstjenesten. Den måles i forhold til hva som er avtalt i en kontrakt. Det er helt konkrete tall for tilgjengelighet, svartider, brukerstøtte, feilretting osv.
+ Service Level Management is often shortened to the acronym SLA. Managing the the service level is about the quality of the operational services, measured in relation to what is agreed in a contract. There are definitely concrete figures for availability, response times, support, error correction etc.
  
- Målet er å ha styring over tjenestenivået for og forbedre kvaliteten på driftstjenestene. Ved gjentakende runder fastsettes, overvåkes og rapporteres kvalitetsnivået. Hensikten er å forbedre kontakten mellom IT-ansvarlige og brukerne slik at det leveres en IT-tjeneste til avtalt kvalitet.
+ The objective is to have control over service level and improve the quality of the operational services. By repeating rounds the quality level us determined, monitored and reported. The purpose is to improve the contact between ICT administrators and users, to get an ICT service to the agreed quality delivered.
  
- Det er viktig å ha et bevist forhold til forskjellig typer SLA-er. Man kan velge mellom mange typer avtaler. Det vanlige er tre typer:
+ It is important to have a proven relation to different types of SLAs. One can choose from many types of agreements. Typically three types :.
  
-  * Avtale pr tjeneste for alle kunder
-  * Avtale pr kunde for alle tjenester
-  * Avtale pr tjeneste pr kunde
+  * Agreement per service for all customers
+  * Agreement per customer for all services
+  * Agreement per service per customer
  
- Alle SLA-ene skal administreres, rapporteres på og vedlikeholdes. Det blir fort uoversiktlig og mye arbeide som ikke gir særlig nytte. Hensikten er at man får en avtale som bidrar til å bedre kvaliteten på tjenesten. Derfor er det nyttig å tenke seg godt om når avtalen lages. Her følger en oversikt over hva som er viktig å passe på når man lager en avtale om tjenestenivåhåndtering.
+ All SLAs is to be administered, reported on and maintained. It quickly becomes confusing and much work that does not provide particular benefit. The purpose is to get an agreement that helps to improve quality of service. Therefore it is useful to think carefully about this, when the agreement is made. Here is an overview of what is important to make sure when you create an agreement for the service level management.
  
- === Overordnet sjekkliste ===
+ === General checklist ===
  
-  * Enighet mellom bruker og driftssenter om hva som faktisk måles. Dette må ses fra brukernes perspektiv og ikke IT-tjenestens perspektiv.
-  * Målbarhet og utvetydighet på de måleverdiene som inngår i tjenestenivåavtalen
-  * Fastsettelse av realistiske mål for tjenestenivå (det er ingen vits i å love mer enn det man kan holde)
-  * Kontinuerlig fokus på kontroll av tjenestenivå - overvåking og periodisk rapportering av oppnådde resultater
+  * Agreement between the user and operations of what's actually measured. This must be seen from the users' perspective and not ICT service perspective.
+  * Measurement and unambiguously on the measurement values included in SLA
+  * Decide realistic targets for service level (there is no point in promising more than one can hold)javascript:;
+  * Continuous focus on the control of the service - monitoring and periodic reporting of results achieved
  
  === Planning ===
  
- Det er helt avgjørende at driftssenteret har tekniske muligheter til å måle de verdiene som inngår i tjenestenivåavtalen. Dette må tas hensyn til helt fra begynnelsen.
+ It is essential that the operations center has the technical capability to measure the values included in the SLA. This must be taken into account from the beginning.
  
- Videre er det viktig å definere de tjenestene hvor man er avhengig av underleverandører og derfor ikke kan gi garantier for tjenestenivå, eller er avhengig av en tilsvarende avtale med underleverandøren. Definisjonen av avhengigheter gjør man for at det skal være klart hvem som retter opp i problemer, og for å unngå stadige forhandlinger før feil kan rettes.
+ Furthermore, it is important to define the services dependent on subcontractors and therefore can't provide guarantees of service, or relies on a similar agreement with the subcontractor. The definition of dependencies is made because it should be clear who rectify problems, and to avoid ongoing negotiations before the error can be corrected.
  
- Krav til tjenestenivå kan være forskjellig for forskjellige brukergrupper eller under forskjellig perioder av skoleåret. F.eks. kan det være forskjell på lærere og elever, eller at man har høyere tjenestekvalitet under gjennomføring av eksamen. Det er viktig å ha dialog med alle relevante brukergrupper for å sikre at det som måles er mest mulig relevant for hver enkelt brukergruppe.
+ Level of service may be different for different user groups, or during different periods of the school year. For example, there may be difference between teachers and students, or a higher service quality when carrying out exams. Dialogue with all relevant users is important to ensure measuring of what's most relevant for each user group.
  
- === Implementering ===
+ === Implementation ===
  
- Det må utarbeides en tjenestekatalog som inneholder alle tjenestene som inngår i tjenestenivåavtalen. En tjeneste vil ofte være en applikasjon (program) i denne katalogen. Det vil ofte være forskjellige krav til forskjellige tjenester, og det vil gjenspeiles i forskjellige måltall i avtalen.
+ A service catalog with all services included in the SLA It must prepared. A service will often be a application/program in this directory. It will often be different requirements for different services, and reflected in different objektives in the agreement. It will often be different requirements for different services, and it will be reflected in different targets in the agreement.
  
  To establish and continually adjust the users' expectations can't be overstated. Often users have exaggerated expectations to the system and the services included. ICT service responsibilitity is to adjust expectations down to realistic levels before the service-level agreement (SLA) is signed. The operating management must also ensure that all users actually are notified and know about the expected service level through the agreement.
  
- For strukturen på selve tjenestenivåavtalen, se [[#Delivery--content-service-level-agreement|delen on innhold i tjenestenivåavtalen]].
+ For the structure of the SLA, see [[#Delivery--content-service-level-agreement|section in the service level agreement]].
  
  === Driftssituasjonen ===
  
@@ -56, +56 @@

  
  === Innhold i tjenestenivåavtalen ===
  
- ==== Innledning ====
+ ==== Introduction ====
  
  Navn og kontaktinformasjon for avtalepartene, beskrivelse av tjenestene som inngår, varighet på avtalen, ansvarsforhold mellom kunde og leverandør.
  
- ==== Tjenestetid ====
+ ==== 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.
  
- ==== Tilgjengelighet ====
+ ==== 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).
  
@@ -72, +72 @@

  
  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.
  
- ==== Stabilitet ====
+ ==== 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.
  
@@ -84, +84 @@

  
  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.
  
- ==== Kapasitet ====
+ ==== Capacity ====
  
  Kan måles som gjennomsnittlig svartid ved bestemte operasjoner i bestemte applikasjoner. Skal måle brukeropplevelsen av systemet.
  
@@ -92, +92 @@

  
  Mål for tid til håndtering, godkjennelse og implementering av endringsforespørsler fra brukerne.
  
- ==== Sikkerhet ====
+ ==== 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.
  
- ==== Fakturering ====
+ ==== Billing ====
  
  Priser, tidspunkt for fakturering og oppgjørsbestemmelser.
  
@@ -120, +120 @@

  
   1. Budsjettering
   1. Regnskapsføring
-  1. Fakturering
+  1. Billing
  
  === Budsjettering ===
  
@@ -134, +134 @@

  
  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.
  
- === Regnskap ===
+ === 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.
  
@@ -144, +144 @@

  
  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.
  
- === Implementering ===
+ === 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.
  
@@ -169, +169 @@

  
  Målet med kapasitetsplanleggingen er å unngå overraskelser.
  
- === Overvåkning ===
+ === Surveillance ===
  
  Det er avgjørende for god kapasitetsplanlegging at systemene overvåkes kontinuerlig for å fremskaffe det nødvendige datagrunnlaget.
  
@@ -180, +180 @@

   * Prosessorbruk pr oppgave
   * Svartider for brukerne pr oppgave
   * Skriverstyring - antall utskrifter, kølengder, utskriftstid
-  * Lagringskapasitet
+  * Storage capacity
   * Antall klienter
   * Antall pålogginger
   * Antall samtidige brukere
@@ -210, +210 @@

  ||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||
  
- === Implementering ===
+ === 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.
  
@@ -220, +220 @@

  
  Kapasitetsplanen bør oppdateres og behandles en gang i året, normalt i forbindelse med budsjettprosessen. Planen bør inneholde følgende områder:
  
-  * Innledning
+  * Introduction
   * Forutsetninger
-  * Sammendrag
+  * Summary
   * Nåværende og fremtidige brukerbehov
   * Tjenestesammendrag
   * Ressurssammendrag
@@ -277, +277 @@

  
  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.
  
- === Risikostyring ===
+ === 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.
  
@@ -297, +297 @@

  
  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.
  
- === Designforbedringer ===
+ === 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.
  

