Ett bra sätt att minska driftstörningar och höja programsäkerheten

Det finns bra metoder för att väsentligt förbättra säkerhet och kontroll vid förändringar i företagens ADB-system. Per Fröjd redovisar i denna aritkel hur Posten använt en standardprogramvara för att nå de uppsatta målen.

Det finns många skäl för ett företag att ha säkra rutiner vid systemunderhåll eftersom brister får stora negativa konsekvenser. Vid min granskning 1989 av dessa rutiner vid Postens största ADB-verksamhet, GK-DATA, som årligen har ca 3.000 programändringar, formulerade jag ett antal frågeställningar. Sammanfattningsvis var syftet med dessa att få en uppfattning om följande:

* Kan endast behöriga ändringar genomföras?

* Genomförs de på ett sådant sätt att programfel och driftstörningar minimeras?

* Finns en lämplig arbets- och ansvarsfördelning i hela ändringsprocessen?

* Dokumenteras alla beslutade och genomförda ändringar så att de kan följas upp?

* Tillgodoses övriga krav på dokumentation och behandlingshistorik så att det går att rekonstruera körningar?

* Finns ändamålsenliga och säkra rutiner vid produktionssättning av ändring?

Detta kan låta som självklarheter men det är faktiskt så att en hel mängd förutsättningar måste tillgodoses för att målsättningarna skall kunna uppfyllas.

Efter vår granskning startade Posten ett projekt, för att se över dessa rutiner och ställa krav på ett informationssystem för hantering av ändringar. I detta projekt medverkade vi även från internrevisionens sida som kravställare och diskussionspartner. Under arbetets gång visade det sig att ett sådant system även verksamt skulle kunna bidra till ökad rationalitet och ändamålsenlighet. Arbetet resulterade i en kravspecifikation om inte mindre än 49 punkter som skulle realiseras genom köp av standardprogram eller genom egenutveckling. Det visade sig att det fanns några programvaror som i varierande grad svarade upp emot kraven och en av dessa valdes, som den för Posten bästa. Den testades under 1991 och har körts i pilotdrift under 1992. De två produkter som bäst uppfyllde kraven var Change Man och Endevor.

Vilka fördelar ger programvaran?

Testerna och pilotdriften har kunnat verifiera att den valda programvaran ger många fördelar.

Den kan på ett effektivt sätt samverka med IBMs behörighetskontrollsystem RACF, vilket gör att det går att skapa en strikt arbets- och ansvarsfördelning i hela systemunderhållsprocessen från ändringsbeslut till produktionssättning. Detta gäller även andra behörighetskontrollsystem för IBM stordator, Top Secret och ACF2. På en stor ADB-avdelning kan det innebära att följande användarkategorier tilldelas behörighet att utföra endast sin speciella uppgift i ”sitt” system:

* systemförvaltare (på användaravdelningen)

* systemansvarig (på ADB-avdelningen)

* programmerare

* driftansvarig

* behörighetsadministratör.

Det går inte att genomföra och införa en ändring utanför systemets ram så den beslutade ansvarsfördelningen kan inte kringgås. Användarkategoriernas arbetsuppgifter i processen kan knytas till kontrollpunkter för de olika arbetsstegen såsom:

* skapa ändringsbeställning i systemet

* definiera ändringens innehåll, dvs. vilka program- och andra moduler behöver ändras

* hämta berörd källkod (av programmerare skriven originalkod) från produktionsmiljön till utvecklingsmiljön

* utföra ändringen

* testa ändringen

* godkänna flyttning till nästa mer kompletta testmiljö

* godkänna flyttning till produktionsmiljön

* utföra flyttning till produktionsmiljön (sker med automatik).

Av detta kan man se att systemet egentligen utgår ifrån att driftstället har olika miljöer för utveckling, test och produktion, vilket ju också är en förutsättning för en god intern kontroll.

Systemet har en strikt versions- eller snarare generationshantering. Detta får den mycket väsentliga följdeffekten att garantier skapas för att den källkod man tar som utgångspunkt vid en ändring alltid motsvaras av en viss bestämd laddmodul (källkod översatt till körklar maskinkod) från produktionsprogrambiblioteket. Normalt är detta den senaste generation som varit i drift. Den aktuella generationen har nummer 0, föregående -1, osv. I miljöer utan stödsystem av den här typen är det ett vanligt problem att man av misstag tar fel källkodsversion som utgångspunkt vid programändringen, vilket naturligtvis ger fel slutresultat av ändringen.

Automatiserade handgrepp ökar säkerheten

Säkerheten ökar ytterligare genom att många handgrepp som tidigare varit manuella nu är automatiserade. Uppskattningsvis var femte störning i driften är en direkt följd av enkla misstag, närmast av ordningskaraktär, som görs vid ändringar och som med det nya systemet successivt kommer att starkt reduceras. Just färre driftstörningar bör kunna bli en stor intäktspost för de företag som skaffar system av denna typ.

Samtliga användarkategorier kommer att få bättre information om vilka förändringar som är aktuella och hur långt de har kommit i processen. Systemförvaltaren får t.ex. fullständig kontroll över alla program som ska ändras och sättas i produktion. Systemutvecklaren får ett verktyg för att kartlägga och beskriva omfattningen av en förändring. De program som ska nyskapas eller ändras till följd av en beställning anges i ett s.k. ändringspaket. Därefter håller systemet reda på att dessa verkligen ändras och överlämnas till produktion.

Alla förändringar väl dokumenterade

Alla förändringar blir dokumenterade med uppgift om förändringens innehåll, tidpunkt och av vem förändringen gjorts. Detta är särskilt viktigt beträffande de s.k. akuta ändringarna vid driftstörningar, som måste genomföras mycket snabbt utan den vanliga ansvarsfördelningen och som det normalt är svårt att ha en tillfredsställande kontroll över. Dessa ändringar måste sedan godkännas i efterhand enligt den fastställda ansvarsfördelningen. De akuta ändringarna kan således inte heller de göras utanför systemet.

I systemet finns en kalenderfunktion som gör att man kan ange tidpunkt för produktionssättningen varefter detta sker med automatik. På så sätt kan man på ett effektivt sätt anpassa sig till den allmänna driftsituationen, som dels kan kräva fullständigt förbud för produktionssättningar under en period, dels kan kräva tidsmässig samordning mellan tekniska förändringar i miljön och förändringar i tillämpningssystem.

Det finns också möjlighet att kunna koda program med interna beroendeförhållanden så att de automatiskt hanteras parallellt i processen och slutligen tas i produktion samtidigt. Det går också att styra hanteringen av program med interna beroendeförhållanden så att de hanteras i en viss tidsmässig ordning.

Enkelt gå tillbaka till tidigare programgeneration

Systemet är också utformat så att det är enkelt att gå tillbaka och köra föregående generation i produktionsprogrambiblioteket om den nya generationen skulle visa sig vara behäftad med felaktigheter.

Driftdokumentationen kan på samma sätt som programmoduler och andra moduler kopplas till ändringspaketet och flyttas då automatiskt med till produktionsbiblioteket samt ingår i generationshanteringen.

Systemet rapporterar automatiskt till andra informationsystem, bl.a. Info Management, som hos Posten bl.a. utnyttjas för rapportering och uppföljning av driftstörningar. Det innebär bl.a att det är möjligt att verifiera att akutändringar har ett giltigt skäl, dvs. svarar mot en inrapporterad driftstörning. Genomförda akutändringar rapporteras också med automatik till berörda intressenter via meddelande systemet för datoranvändare, MEMO.

I systemets bibliotek kan samtliga förändrade komponenter i ändringspaketet arkiveras, inklusive driftdokumentationen. Det innebär att det kommer att finnas en, med hjälp av generationsnummer, samlad och helt komplett dokumentation av alla de komponenter som tillsammans har styrt historiska körningar.

Sammanfattning av fördelar

Avslutningsvis vill jag betona att systemet inte helt automatiskt genomför alla förbättringar. Men om man före produktionsstart, installation och parametersättning har tänkt igenom vad som krävs för en säker och ändamålsenlig ändringshantering så kommer systemet att stödja detta på ett förträffligt sätt.

Möjligheten att kalendersätta produktionsättning av ändringar, bevaka att ett helt ändringspaket hanteras på rätt sätt, kunna sätta beroendeförhållanden, få historikuppgifter och dokumentation, information och rapportering om vad som utförts, en strikt ansvarsfördelning samt en säker versions-/generationshantering är faktorer som tillsammans ger mycket stora fördelar.

Om man jämför de fördelar jag redovisat med mina inledande frågeställningar vid granskningen visar det sig att uppfyllelsegraden är mycket god:

* Endast behöriga ändringar kan genomföras

* De genomförs på ett sådant sätt att programfel och driftstörningar minimeras

* Det finns en lämplig arbets- och ansvarsfördelning i hela ändringsprocessen

* Alla beslutade och genomförda ändringar dokumenteras så att de kan följas upp

* Övriga krav på dokumentation och behandlingshistorik tillgodoses så att det går att rekonstruera körningar

* Det finns ändamålsenliga och säkra rutiner vid produktionssättning av ändring.

Systemet kan starkt bidra till att styra förändringsarbetet så att de ovan angivna målsättningarna uppfylles. De flesta förbättringarna kommer att ske med automatik genom de i systemet inbyggda funktionerna medan andra kräver separata rutinförändringar. Exempelvis blir inte testrutinerna automatiskt bra, så att programfel minimeras, enbart för att det nya systemet införs. Däremot kommer det att ge strikta godkännanderutiner för test, vilket i sig är mycket viktigt.

Per Fröjd är ADB-revisor vid Posten.