Projekt:Utvecklingsstöd 2020/Förslag på riktlinje för underhållsansvar för utvecklade verktyg och tjänster

Från Wikimedia
Hoppa till navigering Hoppa till sök
Denna sida är för närvarande ett utkast.
Ändringar kan ske utan förvarning och innehållet reflekterar ej nödvändigtvis framtida beslut eller ståndpunkter. När innehållet har spikats bör denna mallen tas bort.
Beslutad: XXXX-XX-XX
Bör uppdateras senast: XXXX-XX-XX

Bakgrund och syfte

Det här dokumentet innehåller riktlinjer för hur och hur länge vi på WMSE underhåller våra digitala tjänster, verktyg, kodbibliotek och plattformar. Exempel på dessa är karttjänsten Offentlig konst i Sverige eller de verktyg som har tagits fram inom projektet Gemenskapens tekniska önskelista. Riktlinjerna omfattar såväl av oss utvecklade tjänster som tjänster som utvecklats externt och tagits över av oss. Under rubriken Tjänster har vi samlat dem alla.

Att kontinuerligt underhålla digitala tjänster är viktigt. Man tänker kanske att detta inte är ett problem förrän något faktiskt går sönder, men osäkerhet kring vad som gäller skapar en reell kostnad redan innan. Det är dessutom ett faktum att saker som inte underhålls sakta men säkert går sönder.[1] En tydlig riktlinje ger ett underlag för beslut om ny utveckling, men är även till stor hjälp för att avgöra om det är lämpligt att ta över driften av en externt utvecklad tjänst.

Det finns både interna och externa skäl för att vi har tagit fram dessa riktlinjer. De mest centrala samlar vi nedan.

Interna skäl

  • Riktlinjerna hjälper oss att se vilka resurser som finns inom ett visst projekt för att utveckla nya tjänster respektive hur mycket som måste öronmärkas för att underhålla gamla.
  • Om vi vill underhålla våra tjänster måste vi skapa budgetutrymme för det. Till exempel om projektet Utvecklingsstöd får samma budget varje år så blir det till slut inga resurser kvar för nyutveckling då underhållet kommer att kräva större andel av budgeten.
  • Vi måste kunna bedöma hur mycket resurser vi ska lägga på att bygga hållbara tjänster som går att underhålla, gentemot att snabbt och billigt sätta ihop en lösning.
  • Vi behöver en rutin för att förebygga, upptäcka och ågärda uppkomna säkerhetshål, eftersom de kan skada användarna.
  • Det finns risk att de som lagt sin tid på att utveckla en tjänst ser sin insats som bortkastad om den slutar fungera och kan inte återaktiveras till följd av resursbrist.
  • Det finns risk att anställda känner sig manade att ta över underhållet på volontärsbasis.
  • Om vi vet att vi har underhållsansvar för något kan vi agera när vi vet att externa faktorer kommer att ändras (t.ex. serverkonfiguration) istället för att behöva åtgärda det när det redan slutat fungera. På detta sätt förebygger vi störande avbrott i tjänsten.

Externa skäl

  • Bristen på tydliga riktlinjer kring hur vi underhåller det vi har byggt skapar förvirring för slutanvändarna som inte vet om det är värt att önska nya funktionaliteter eller om det är värt energin för dem att anpassa deras arbetsrutiner för att lära sig och inkludera ett nytt verktyg.
  • Slutanvändaren antar att tjänsten underhålls löpande om vi inte uttryckligen säger annat.
  • Gemenskapen blir mindre benägen att bidra till våra framtida projekt eller använda våra framtida verktyg om vi utan förvarning inte tar ansvar för dem, i synnerhet om vi överger dem till förmån för att bygga annat nytt. Detta ger intrycket av att vi inte respekterar gemenskapens tid och insats.
  • Vi vill gärna ge gemenskapen en chans att ta över verktyg vi inte längre underhåller, vilket är svårt om vi inte är tydliga om när detta kan ske.
  • Förbättringar och buggfixar som skapas av gemenskapen riskerar att bli ignorerade om vi inte aktivt bevakar, granskar och driftsätter dem.

Exempel

Exempel på situationer som har tydliggjort behovet av sådana riktlinjer:

Nivåer av underhållsstatus

Reaktiva åtgärder från lägre nivåer gäller även för projekt som befinner sig på en högre nivå.

  • 0 - Under utveckling
    • Ursprungsstatus, indikerar att projektet är påbörjat men ännu inte färdigställts för första gång.

  • 1 - Inaktivera tjänsten
    • Eventuell server stängs av.
    • Eventuellt domännamn, epost-tjänster etc sägs upp för att minimera löpande kostnader.

  • 2 - Inget underhåll
    • Låter saker och ting köra tills det går sönder.
    • Tar inget ansvar för feedback, felrapporter eller säkerhetshål.
    • Verktyget inaktiveras om allvarliga säkerhetshål dyker upp.

  • 3 - Säkerhetsuppdateringar
    • Aktiv bevakning av bulletiner om säkerhetshål.
    • Verktyget inaktiveras om säkerhetshål saknar kända lösningar, eller om dessa inte är applicerbara.

  • 4 - Reaktivt felavhjälpande underhåll
    • Mindre åtgärder av inrapporterade buggar i existerande funktionalitet som aldrig fungerat på det vis man ursprungligen tänkt.

  • 5 - Adaptivt underhåll
    • Mindre buggfixar när något externt har påverkat verktyget, exempelvis:
      • Authentifieringskontraktet i Oauth ändras på wmflabs och kräver uppdatering av koden.
      • Linux-distributionen på servern där tjänsten bor har nått slutet av sin livscykel och bör därför om möjligt installeras om för att bättre kunna säkerställa målen i de lägre underhållsnivåerna.

  • 6 - Perfektivt och förebyggande underhåll.
    • Håller tjänsten uppdaterad och aktuell för att förenkla underhåll, eller förhindra plötsliga avbrott.
    • Beroende av interna (utvecklade av WMSE) och externa bibliotek/tjänster:
      • Relaterade detaljer man noterar i arbete med andra projekt.
      • Hålla koll på loggar.
      • Beroendeuppdateringsförslag via GitHub-robotar.
      • Osv
    • Städa upp i enlighet med förändringar i interna kod- och konfigurationskonventioner.

  • 7 - Vidareutveckling
    • Fortsatt aktiv med ytterligare egen utveckling.
    • Funktionsbegäran utifrån externa önskemål.
      • Skall beaktas och besvaras, men måste inte alltid genomföras.
      • Innebär inte nödvändigtvis att man aktivt bjuder in till önskemål.

Hur länge underhåller vi tjänster

Hur länge vi underhåller en tjänst på de olika nivåerna påverkas av ett antal olika parametrar:

  • Användning av tjänsten. Används tjänsten mycket bör den prioriteras högre. Detta gäller särskilt om den används av större Wikimedia-gemenskapen.
  • Involvering och arbete från gemenskapen. Har vi aktivt involverat gemenskapen i utvecklingen av tjänsten bör den prioriteras högre.
  • Marknadsföring av tjänsten. Har tjänsten marknadsfört aktivt bör den prioriteras högre.
  • Hur mycket arbete det är att underhålla tjänsten. En tjänst som kommer kräva mer resurser bör prioriteras lägre.
  • Hur mycket det kostar att hålla igång en tjänst. Kostar det mer bör den prioriteras högre, då förlusten blir större om den slutar att fungera.
  • Om tjänsten ingår i ett fortfarande aktivt projekt. Kan ett projekt på ett relevant sätt bära underhållskostnaderna bör den prioriteras högre.

Det kan vara bra att säga vi underhåller en tjänst på en viss nivå under en viss period och sedan utvärdera. En tjänst ska alltid ha en utskriven minsta tid innan underhållsnivån sänks till nivå 2, så att inget någonsin stängs ner oväntat. Undantag kan göras om en tjänst slutar fungera p.g.a. externa, oförväntade omständigheter.

Även efter en tjänst har stängts ner ska källkod och dokumentation finnas publikt tillgängligt, både för den som vill köra tjänsten och för slutanvändare. Detta gör det möjligt för andra att använda eller vidareutveckla tjänsten.

Tjänster som är under aktiv utveckling eller som aldrig färdigställdes tilldelas inte en underhållsnivå.

Förslag på standardtider

Följande är ett underlag för att ta fram en tidsplan för underhåll av en given tjänst, beroende på vilken typ av tjänst det är.

  • Tjänsten kommer från Gemenskapens tekniska önskelista
  • Tjänster som kan användas av tredje part, men inte främst byggdes för det syftet
  • Tjänster byggd för tidsbegränsad användning
    • Nivå 5 under den avsedda perioden sedan utvärdering
    • Därefter nivå 2
  • Övriga tjänster som inte kommer från Gemenskapens tekniska önskelista och är utvecklade för gemenskapen/allmänheten

Hur vi hanterar end-of-life

Inför att en tjänst fasas ut, det vill säga går ner på nivå 2 (eller lägre), så kallat end of lite, är det viktigt att vi dels informerar kvarvarande brukare dels att vi undersöker om det finns någon annan part som skulle vara intresserad av att adoptera tjänsten, det vill säga ta över drift och ansvar för den. Detta är främst relevant för tjänster som kan nyttjas av gemenskapen eller allmänheten.

De mekanismer vi har att tillgå är:

  • Informera på till exempel Bybrunnen samt tillämpliga WikiProjekt.
  • Lägga en banner direkt i tjänsten (både för informera brukare och leta efter adoptanter).
  • Kontakta eventuell extern part som var med under utvecklingen (troligen mer av artighet än att vi tror att de adopterar).
  • Kontakta eventuella medutvecklare till koden eller utvecklingsarbetet.
  • Fundera på om tjänsten kan föras över på en annan Wikimediaorganisation (till exempel Wikimedia Foundation eller Wikimedia Deutschland).

Arbetsinsatsen för ovanstående bör dock hållas låg. Insatsen ska helst ha tänkts igenom redan när man sätter underhållstidplanen, speciellt om själva överföringen av tjänsten kräver en mer aktiv insats från oss.

Vem står för underhållskostnaden

Om det finns en naturlig arvtagare till projektet där tjänsten uppstod bör denna ansvara för den uppkomna underhållskostnaden. Extra utrymme måste ges i budgeten, alternativt måste planerade leverabler skalas ner för att skapa det utrymmet.

Där det inte finns en naturlig arvtagare bör ett projekt under programmet Användning bära ansvaret. Antingen kan projektet Buggrapportering och översättning utökas med detta ansvar eller så måste ett nytt projekt skapas.

Den faktiska kostnaden för underhåll behöver utvärderas när organisationen väl har arbetat enligt detta sätt ett tag. Tills dess använder vi oss av följande grovt uppskattade schabloner:

  • Nivå 3: 0,5 dagar per år.
    • Om det inte fungerar att uppdatera komponenten/applicera säkerhetspatchen faller åtgärden utanför underhållsnivån.
  • Nivå 5: 0,5-2 dagar per år för att upprätthålla nuvarande skick, om inga externa faktorer påverkar. Det planerade arbetet innefattar att:
    • Regelbundet titta på loggar.
    • Läsa igenom prenumererade bulletiner
  • Nivå 6: 2-7 dagar per år.
    • Kan innebära ny utförligare dokumentation när någon slutar.
    • Kostnaden ligger i att man har tjänsten i åtanke och bibehåller tillräcklig kunskap om den för att känna igen när förändringar behövs.

Utöver ovanstående räknar vi med 1 dags arbete i samband med förberedelser för end-of-life.

Se även

  • Lista över existerande tjänster/verktyg (Google Doc) [dokument ännu ej redo]
  • Lista över domäner

Fotnoter

  1. ↑ Software maintenance: Maintenance debt. Wikipedia.
Hämtad från ”https://se.wikimedia.org/w/index.php?title=Projekt:Utvecklingsstöd_2020/Förslag_på_riktlinje_för_underhållsansvar_för_utvecklade_verktyg_och_tjänster&oldid=93739”