mboost-dp1
Digitaliseringsstyrelsen
Det er et tveægget sværd at lave centraliserede løsninger for digital infrastruktur så kritisk som dette. Hvis alt bare virker er det til alles fordel, men hvis der er problemer går det også udover alle med potentielt katastrofale følger. Det er en "alle æg i en kurv" situation.
arne_v (5) skrev:
en database log, der var løbet fuld
er en halvpinlig årsag.
Men vel netop så dilettantisk som man kunne forvente. Jeg har et arbejde i det offentlige hvor jeg i næsten 2 år har gjort de såkaldte IT-folk opmærksomme på de stavefejl der er lavet i nogle parametre til et program vi anvender 90% af arbejdstiden - og som går ned hvert 40. minut.
Jeg har selv rettet fejlen hos mig - eller startet programmet rigtigt op manuelt og ingen problemer oplevet - men alle andre i hele systemet bruger ualmindeligt meget tid på genopstart og der forsvinder også informationer, som kan være vigtige for patientsikkerheden.
Der var tale om en bindestreg der skulle væk - og så skulle et ord staves i overensstemmelse med den manual der følger med programmet og som alle brugere har adgang til.
Jeg har ikke arbejdet der i mere end de 2 år. Men har fået at vide at problemet har eksisteret i over 10 år.
Hvad er det egentlig de vil få ud af at have to forskellige systemer som skal vedligeholdes i modsætning til et system, som dog får indbygget noget mere redundans - og evt. en lidt større log kapacitet :D
Man ser for sig at medarbejderne hver sag inden de går hjem lige skal sætte en ny 32 MB USB nøgle i serveren - og så arkivere den forrige med dato.
Man ser for sig at medarbejderne hver sag inden de går hjem lige skal sætte en ny 32 MB USB nøgle i serveren - og så arkivere den forrige med dato.
#7
To systemer med N1 og N2 instanser er ikke bedre beskyttet mod HW fejl end et system med N1+N2 instanser.
To forskellige systemer beskytter bedre mod software fejl, da software fejl normalt vil ramme alle instanser i et enkelt system.
Konfigurationsfejl som denne vil også ramme alle instanser for et system. Alle instanser vil køre med samme størrelse transaktions log og have de samme data i transaktions log. To systemer vil have forskellige opsætning og måske vil et af dem slet ikke have en fast størrelse transaktions log.
Det er dog dyrt med to systemer. Udvikling og vedligehold er i sagens natur dobbelt så dyr (bortset fra udfærdigelse af kravspecifikation og UAT plan der kan genbruges). Og man åbner op for en helt ny type fejl. Nemlig at de to systemer opfører sig forskelligt.
Og måske bærer forslaget om to systemer præg af at komme fra den akademiske verden.
To systemer med N1 og N2 instanser er ikke bedre beskyttet mod HW fejl end et system med N1+N2 instanser.
To forskellige systemer beskytter bedre mod software fejl, da software fejl normalt vil ramme alle instanser i et enkelt system.
Konfigurationsfejl som denne vil også ramme alle instanser for et system. Alle instanser vil køre med samme størrelse transaktions log og have de samme data i transaktions log. To systemer vil have forskellige opsætning og måske vil et af dem slet ikke have en fast størrelse transaktions log.
Det er dog dyrt med to systemer. Udvikling og vedligehold er i sagens natur dobbelt så dyr (bortset fra udfærdigelse af kravspecifikation og UAT plan der kan genbruges). Og man åbner op for en helt ny type fejl. Nemlig at de to systemer opfører sig forskelligt.
Og måske bærer forslaget om to systemer præg af at komme fra den akademiske verden.
Men faktisk ret typisk lol.arne_v (5) skrev:
en database log, der var løbet fuld
er en halvpinlig årsag.
Jeg har set det alt alt for mange gange på arbejde.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund