Den store it-skandale om Polsag-systemet, som skulle danne basis for en omfattende it-modernisering hos Politiet, er nu officielt et overstået kapitel, efter at statsrevisorerne meget usædvanligt valgte at gentage kritikken af hele forløbet i denne uge.
Dermed er myndighedernes selvransagelse slut, og Rigsrevisionens beretning fra foråret 2013 får lov at stå for eftertiden. En rapport, der giver et overblik over de mange svigt og fejl, som skete undervejs, både hos Rigspolitiet og hos leverandøren CSC, som brugte Scanjour som underleverandør.
I rapporten bliver de tekniske problemer også hevet frem, og et af de store kritikpunkter fra de 80 bornholmske betjente, der som de eneste fik brugt Polsag i praksis, var lange svartider. Den lille politikreds på Bornholm kørte nemlig Polsag i pilotdrift i over et år, og de meget dårlige erfaringer herfra var en af grundene til, at projektet blev lukket helt ned i februar 2012.
Det eksterne tekniske gennemsyn af Polsag fra konsulentfirmaet Globeteam viser, hvorfor der var performanceproblemer. Et skøn viste, at webserverne i systemet en mandag formiddag rutinemæssigt ville blive udsat for 7,8 millioner http-request. Det ville kræve 44 servere, men testen gik kun på 13 udvalgte handlinger i Polsag-systemet og tog ikke højde for andre operationer eller spidsbelastninger. Tallet kunne derfor være meget højere i praksis.
Men selv med det lave, skønnede tal, ville det sætte Oracle-databasen, der var kernen i Polsag-systemet, under massivt pres. Databasen ville få 100.000 SQL-kald i sekundet, og det ville kræve en Oracle-server med mellem 60 og 128 processorer at drive. Oven i ville så komme logning, der omtrent ville fordoble antallet af kald til databasen - igen blot med de 13 udvalgte handlinger - så hardwarekravene ville i praksis være helt overvældende.
»Dette er et virkeligt stort tal, nærmest uanset hvor stor en Oracle-installation, der er tale om,« lyder vurderingen i den eksterne rapport.
Også den it-ekspert, som Rigsrevisionen har brugt, er lamslået.
»Set med teknikerens øjne er det stort set umuligt at håndtere så stort et antal,« skriver Rigsrevisionen.
I forhold til den server-kapacitet, som var planlagt til Polsag-systemet, var der brug for en massiv opgradering, hvis ikke svartiderne skulle være urimeligt lange. Det ville både koste i mere hardware, flere licensomkostninger til Oracle og højere driftsomkostninger hos CSC.
Undersøgelserne blev i øvrigt foretaget på Polsags uddannelsesmiljø, og ikke test- eller produktionsmiljøet, som konsulenterne ikke havde adgang til. Det gør det svært at vurdere helt præcist, hvor galt det stod til, og ifølge Rigsrevisionen blev der senere hen gennemført nogle test i produktionsmiljøet, som viste forbedringer.
Men forbedringerne var altså ikke overbevisende nok til, at man valgte at prøve at redde Polsag-systemet. I stedet blev det lukket helt ned i februar 2012, og 567 millioner kroner var med ét slag spildt. Leverandøren CSC havde systemet i pilotdrift på Bornholm fra december 2010 og frem til lukningen, men her blev altså heller ikke vist gode nok fremskridt undervejs.
Konsulenterne fra Globeteam havde en del forslag til, hvordan ydelsen kunne blive forbedret. Det omfattende blandt andet at få caching til at virke i browseren, og udvide den fra 24 timer til flere dage. Dermed ville mængden af data, der skulle overføres, når en betjent åbnede forsiden i Polsag-systemet, gå fra 5,5 megabyte til 2 megabyte.
Læs rapporten fra Globeteam med de tekniske detaljer (antallet af databasekald bliver beskrevet på side 10 og frem):
[scribd id=121767705 key=key-1gmcys1njyhwz4zchshr]
