mboost-dp1
SXC - nighthawk7
#3
Læs http://bizzen.blogs.business.dk/2008/07/08/danske-... som der er linket til.
Det synes jeg nu er ret alvorligt og kan godt forstå folk ikke er alt for glade.
Læs http://bizzen.blogs.business.dk/2008/07/08/danske-... som der er linket til.
Vi hører om andre forstyrrelser i driften, og senest kunne vi læse, at når en finsk kunde hævede i en pengeautomatik, stod beløbet både som trukket fra kundens lønkonto og kundens Visa-konto
Det synes jeg nu er ret alvorligt og kan godt forstå folk ikke er alt for glade.
#2 måske er det ikke ligefrem jordens undergang, (Det er forhåbentlig ikke IBM som står bag LHC. :) ) men det fortjener at få en ordenligt lussing i medierne.
Det giver et enormt spild af penge af kundernes penge at Danske Bank konstant har problemer. Jeg sidder selv i et job hvor jeg er afhængig af at DDBs netbank er konstant online. Det er den jo så bare ikke, så jeg har heldigvis tid til at sortere mine clips i farveorden efter jeg har brygget kaffe og lavet prioritering på alle de mails som jeg ikke kan besvare uden adgang banken..
Det er spild af min tid og spild af min arbejdsgiver penge at betale min løn for et arbejde som DDB/IBM er skyld i at jeg ikke kan udføre.
Behøver jeg at nævne at DDB stadigvæk ikke har fået styr på de fejl som opstod under nedbrudet i foråret?
Når jeg skal stifte mit eget selskab, så vælger jeg helt sikkert ikke DDB, og det vil netop være på grund af deres upålidelige lorte system.
Det giver et enormt spild af penge af kundernes penge at Danske Bank konstant har problemer. Jeg sidder selv i et job hvor jeg er afhængig af at DDBs netbank er konstant online. Det er den jo så bare ikke, så jeg har heldigvis tid til at sortere mine clips i farveorden efter jeg har brygget kaffe og lavet prioritering på alle de mails som jeg ikke kan besvare uden adgang banken..
Det er spild af min tid og spild af min arbejdsgiver penge at betale min løn for et arbejde som DDB/IBM er skyld i at jeg ikke kan udføre.
Behøver jeg at nævne at DDB stadigvæk ikke har fået styr på de fejl som opstod under nedbrudet i foråret?
Når jeg skal stifte mit eget selskab, så vælger jeg helt sikkert ikke DDB, og det vil netop være på grund af deres upålidelige lorte system.
#7 Det har jeg også anbefalet min arbejdsgiver, men eftersom vi har over 50 konti i Danske Bank, så vil det også være en kæmpe udfordring at få flyttet alle aktiviteter over til en anden bank. Især de udenlandske transaktioner er tunge at danse med.
Helt ærligt, nej det er ikke godt nok, det skal ikke kunne ske.
MEN, hvis der skulle være en nyhed HVER gang et større IT system er nede i en halv time, så ville vi da ikke have andet, det sker hver eneste dag for forskellige firmaer og hostingcentre. At IBM har så store kunder, og derfor stort ansvar gør selvfølgelig at de er i væsentligt større "fare" for at komme i nyhederne.
I min verden lyder 1½ times nedbrud ca. Som en MEGET hurtig genskabelse af systemet - Selvfølgelig alt efter hvad fejlen har været, men hvis det er et spørgsmål om at opdage fejlen, lokalere problemet præcist, finde på hvad løsningen skal være, få den udført og ud i produktionsmiljøet - Ja så synes jeg ikke at 1½ time er meget.
IMO lyder det noget blæst op.
MEN, hvis der skulle være en nyhed HVER gang et større IT system er nede i en halv time, så ville vi da ikke have andet, det sker hver eneste dag for forskellige firmaer og hostingcentre. At IBM har så store kunder, og derfor stort ansvar gør selvfølgelig at de er i væsentligt større "fare" for at komme i nyhederne.
I min verden lyder 1½ times nedbrud ca. Som en MEGET hurtig genskabelse af systemet - Selvfølgelig alt efter hvad fejlen har været, men hvis det er et spørgsmål om at opdage fejlen, lokalere problemet præcist, finde på hvad løsningen skal være, få den udført og ud i produktionsmiljøet - Ja så synes jeg ikke at 1½ time er meget.
IMO lyder det noget blæst op.
#6
Hvis du har det dårligt med at din chef skal betale dig løn for den tid hvor du ikke har kunne arbejde på grund af nedbrudet er jeg da sikker på at han gerne vil høre på dig når du siger det til ham.
#9
Enig. De har ikke fortjent andet end ros for det meget hurtige arbejde. 1½ time er ikke meget til fejlsøgning og fejlretning på en stor og kompleks løsning som det lyder til at den her Danske Bank løsning er.
Hvis du har det dårligt med at din chef skal betale dig løn for den tid hvor du ikke har kunne arbejde på grund af nedbrudet er jeg da sikker på at han gerne vil høre på dig når du siger det til ham.
#9
Enig. De har ikke fortjent andet end ros for det meget hurtige arbejde. 1½ time er ikke meget til fejlsøgning og fejlretning på en stor og kompleks løsning som det lyder til at den her Danske Bank løsning er.
JustMe (12) skrev:Måske på tide de får en elektriker til at sætte en separat stikkontakt op til rengøringsdamen...
Off topic: Det minder mig om dengang jeg havde en dialin-pulje, og lidt andet sjov, der konstant blev markeret som nede i min overvågning. Eller - dvs. UPS'en stod og meldte fejl flere gange i minuttet...
Det endte med at jeg måtte køre ud på adressen (colo) for at se hvad der var galt. Det kunne være et defekt batteri - men det var det ikke! En håndværker havde da lige smidt hans 5 KW drejebænk i min UPS, da der jo "var et strømstik tilovers", som han så fint fik formuleret, da jeg stod ildrød i knolden og forklarede ham hvad han stod og var skyld i! :P
On topic: Så er det altså pinligt at de kan vise så lange nedetider på så vitale systemer. Vi kan dog godt blive enige om at 90 minutter ikke er alverden - men mange bække små. Og lur mig, om der ikke er en del mennesker der rent faktisk er mere afhængige af at lortet kører, end andre er - som der allerede er blevet pointeret i denne tråd.
Det kan vist godt gøres bedre IBM? :\
#13
Tilgengaeld saa er det mig en komplet gaade at de ikke har 100% redundans i et system saa vigtigt som dette.
Det er dyrt at lave redundans, men staar en stoerre kunde ( skal vi sige NSS Financials ) som rykker 20-30 millioner igennem systemet om dagen, saa bliver de eddermame sure naar der er nedbrud.
1.5 timer er ikke meget, nej, men kommer de 1.5 timer kl 8.30 naar der skal overfoeres penge til boershandel, saa er det pludselig ret meget ;)
Derudover burde DDB have laert af tidligere fejl.
Tilgengaeld saa er det mig en komplet gaade at de ikke har 100% redundans i et system saa vigtigt som dette.
Det er dyrt at lave redundans, men staar en stoerre kunde ( skal vi sige NSS Financials ) som rykker 20-30 millioner igennem systemet om dagen, saa bliver de eddermame sure naar der er nedbrud.
1.5 timer er ikke meget, nej, men kommer de 1.5 timer kl 8.30 naar der skal overfoeres penge til boershandel, saa er det pludselig ret meget ;)
Derudover burde DDB have laert af tidligere fejl.
Jeg kan egentligt ikke se at det er sådan et vigtigt system. Jo, det er da forstyrrende at deres kunder ikke kan komme til det, men det lyder jo ikke som om det er de underliggende transaktionssystemer der har været nede.
Jeg vil kalde systemet vigtigt, men ikke kritisk.
Jeg vil kalde systemet vigtigt, men ikke kritisk.
Hold kæft hvor medierne piver.
1.5 times nedetid i løbet af hvor længe?
Hvis det er det eneste tidspunkt den har været nede i et år er det alligevel 99.99983% oppetid.
Så god drift finder man ikke mange steder.
1.5 times nedetid i løbet af hvor længe?
Hvis det er det eneste tidspunkt den har været nede i et år er det alligevel 99.99983% oppetid.
Så god drift finder man ikke mange steder.
#18 #19
Absolut, men transaktioner vil stadig kunne gennemføres vha. andre mekanismer, at den mekanisme så er nede er selvfølgelig træls, men det er jo ikke noget der gør at bankvirksomhed ikke kan gennemføres, det er bare den kanal der er nede.
Hvis Danske Banks transaktionssystemer var nede havde de helt andre problemer, det var det jeg prøvede at sige med de underliggende systemer.
Absolut, men transaktioner vil stadig kunne gennemføres vha. andre mekanismer, at den mekanisme så er nede er selvfølgelig træls, men det er jo ikke noget der gør at bankvirksomhed ikke kan gennemføres, det er bare den kanal der er nede.
Hvis Danske Banks transaktionssystemer var nede havde de helt andre problemer, det var det jeg prøvede at sige med de underliggende systemer.
#22
Meget muligt.
Saa er det heldigt at deres it-ansvarlige jo altid soerger for at gennemteste deres redundans :)
Nej, men det lyder sandsynligt i mine oerer, at det ikke er sat ordentligt op eller ordentligt testet.
Personligt hiver jeg tit en redundant server ud af produktion, haardt og brutalt, blot for at konstatere at vores redundante system virker :)
Hvis det ikke virker, saa hellere et kontrolleret nedbrud hvor jeg er klar til emergency repairs, fremfor "et uheld" :)
Jeg vil gætte på at systemet har redundans.
Men at det som ved tidligere incidents har været problemer med at switche over.
Meget muligt.
Saa er det heldigt at deres it-ansvarlige jo altid soerger for at gennemteste deres redundans :)
Det lyder ikke sandsynligt at de bevidst har valgt ikke at have redundans på et Unix baseret system.
Nej, men det lyder sandsynligt i mine oerer, at det ikke er sat ordentligt op eller ordentligt testet.
Personligt hiver jeg tit en redundant server ud af produktion, haardt og brutalt, blot for at konstatere at vores redundante system virker :)
Hvis det ikke virker, saa hellere et kontrolleret nedbrud hvor jeg er klar til emergency repairs, fremfor "et uheld" :)
fidomuh (25) skrev:#22Jeg vil gætte på at systemet har redundans.
Men at det som ved tidligere incidents har været problemer med at switche over.
Meget muligt.
Saa er det heldigt at deres it-ansvarlige jo altid soerger for at gennemteste deres redundans :)
Nej, men det lyder sandsynligt i mine oerer, at det ikke er sat ordentligt op eller ordentligt testet.
Personligt hiver jeg tit en redundant server ud af produktion, haardt og brutalt, blot for at konstatere at vores redundante system virker :)
Hvis det ikke virker, saa hellere et kontrolleret nedbrud hvor jeg er klar til emergency repairs, fremfor "et uheld" :)
Men det kræver edderrådme meget meget meget lange, veludvoksede, nedfaldne ekstremt behårede nosser for lige at trække livlinen til Danske Netbank!!!
Jeg arbejder selv med hosting, hvor jeg er hos leverandøren, og jeg skal da lige hilse og sige at uanset om vi kører en n+1 eller en 2n løsning, så trækker jeg ikke nogen kabler ud medmindre det er i et servicevindue!
Der er jo ingen grund til at bede om problemer og nedetid som bliver talt (servicevinduer bliver ikke talt som nedetid - men som vedligeholdelse hvorfor den tid ikke medregnes).
Derudover kan jeg afsløre at i hvert fald én af IBMs kunder har reduceret antallet af servere stående hos IBM.
Jeg synes at denne sag er synd for IBM, de har godt nok FOR mange problemer med oppetiden til at det kan være særlig sjov at være ansat hos dem. Hele 2008 må have føltes som værende ret meget op af bakke! Jeg håber at min konkurrent men stadig ligesindede, snart får styr på tingene igen.
Hvad jeg finder mest uhyggeligt ved historier som denne er hvor tydeligt de viser vores afhængighed af systemer som disse.
Hvis samfundet - eller dele vi tager for givet kan skabe så meget påstyr ved sit fravær i sølle 1½ time så er vi måske blevet lidt for sårbare i vores højteknologiske vidunderverden.
Jeg mindes strømafbrydelsen i 2003 hvor hele min arbejdsplads gik i stå - og store dele af Sjælland tillige. Jeg gyser ved tanken om hvordan København eller en anden storby vil se ud hvis problemet var af et sådan omfang at vi var uden strøm i blot en uge.
I min verden hører ting som kortvarige nedbrud blandt livets uundgåelige peditesser uanset hvor meget vi forsøger at forsikre os imod det.
Hvis samfundet - eller dele vi tager for givet kan skabe så meget påstyr ved sit fravær i sølle 1½ time så er vi måske blevet lidt for sårbare i vores højteknologiske vidunderverden.
Jeg mindes strømafbrydelsen i 2003 hvor hele min arbejdsplads gik i stå - og store dele af Sjælland tillige. Jeg gyser ved tanken om hvordan København eller en anden storby vil se ud hvis problemet var af et sådan omfang at vi var uden strøm i blot en uge.
I min verden hører ting som kortvarige nedbrud blandt livets uundgåelige peditesser uanset hvor meget vi forsøger at forsikre os imod det.
Bortset fra det - har IBM vist problemer med deres ledelsesstil.
De har ansat en masse smarte slipsedrenge der er interesserede i deres egen karriere men ikke i firmaet.
De gamle medarbejdere der vidste hvordan man gør tingene gik deres vej i væmmelse.
En del andre firmaer har det samme problem -
Grundlæggende gælder at man kan lave en masse hype, men hvis der ikke ligger solidt arbejde bag - kommer nedbruddet, hvadenten det er i økonomi eller EDB -
De har ansat en masse smarte slipsedrenge der er interesserede i deres egen karriere men ikke i firmaet.
De gamle medarbejdere der vidste hvordan man gør tingene gik deres vej i væmmelse.
En del andre firmaer har det samme problem -
Grundlæggende gælder at man kan lave en masse hype, men hvis der ikke ligger solidt arbejde bag - kommer nedbruddet, hvadenten det er i økonomi eller EDB -
#26
Nej, det kraever en it-ansvarlig der er sit ansvar voksen, nothing else.
Saa maa du jo varsle et service vindue og forsoege.
Saa du vil hellere have uforudsete og ukontrollerbare nedbrud, end kontrollerede nedbrud, hvor du staar ved siden af maskinen og er klar til at faa den op igen? ...
Jeg foretraekker at kontrollere at systemerne virker, saa jeg ikke behoever at vaere nervoes for at firmaet ligepludselig mister millioner grundet et utestet produktionssystem.
Men det kræver edderrådme meget meget meget lange, veludvoksede, nedfaldne ekstremt behårede nosser for lige at trække livlinen til Danske Netbank!!!
Nej, det kraever en it-ansvarlig der er sit ansvar voksen, nothing else.
Jeg arbejder selv med hosting, hvor jeg er hos leverandøren, og jeg skal da lige hilse og sige at uanset om vi kører en n+1 eller en 2n løsning, så trækker jeg ikke nogen kabler ud medmindre det er i et servicevindue!
Saa maa du jo varsle et service vindue og forsoege.
Der er jo ingen grund til at bede om problemer og nedetid som bliver talt (servicevinduer bliver ikke talt som nedetid - men som vedligeholdelse hvorfor den tid ikke medregnes).
Saa du vil hellere have uforudsete og ukontrollerbare nedbrud, end kontrollerede nedbrud, hvor du staar ved siden af maskinen og er klar til at faa den op igen? ...
Jeg foretraekker at kontrollere at systemerne virker, saa jeg ikke behoever at vaere nervoes for at firmaet ligepludselig mister millioner grundet et utestet produktionssystem.
fidomuh (15) skrev:#13
Tilgengaeld saa er det mig en komplet gaade at de ikke har 100% redundans i et system saa vigtigt som dette.
Ved du noget vi andre ikke ved? Jeg har ihvertfald ikke kunne finde noget der viser at de ikke har redundans. Det er måske ikke 100% men jeg vil da godt holde en kasse flødeboller på at de på de vigtigste dele har redundans.
Det er dyrt at lave redundans, men staar en stoerre kunde ( skal vi sige NSS Financials ) som rykker 20-30 millioner igennem systemet om dagen, saa bliver de eddermame sure naar der er nedbrud.
Det er jo så ikke nødvendigvis IBM's skyld at der ikke er redundans. Selvom man kan argumentere for et nok så smart setup er det ikke sikkert at kunden mener det er nødvendigt.
Der er iøvrigt heller ikke rigtigt noget der underbygger din påstand om at det ville have hjulpet...
1.5 timer er ikke meget, nej, men kommer de 1.5 timer kl 8.30 naar der skal overfoeres penge til boershandel, saa er det pludselig ret meget ;)
Derudover burde DDB have laert af tidligere fejl.
Hvad mener du de ikke har lært?
fidomuh (30) skrev:
Nej, det kraever en it-ansvarlig der er sit ansvar voksen, nothing else.
Du kan ikke helt sammenligne det med når du selv fjoller rundt i det lilleblad hus du er ansat i.. :p
Saa maa du jo varsle et service vindue og forsoege.
Sådan fungerer det så ikke den i virkelige verden af flere årsager. Den primære er at man ikke bare forsøger noget man planlægger tester og planlægger lidt mere og så hiver man stikket. Men det er altsammen gjort inden systemet bliver sat i drift.
Saa du vil hellere have uforudsete og ukontrollerbare nedbrud, end kontrollerede nedbrud, hvor du staar ved siden af maskinen og er klar til at faa den op igen? ...
Man står ikke altid klar til den slags nedbrud. Der er vagtordninger ja men det betyder ikke at folk aldrig forlader kontoret eller altid er i nærheden af et sted hvor de kan få hul igennem til internettet. Det er derfor man laver den her slags test i implementeringsfasen.
Jeg foretraekker at kontrollere at systemerne virker, saa jeg ikke behoever at vaere nervoes for at firmaet ligepludselig mister millioner grundet et utestet produktionssystem.
Har du været med til at sætte et større projekt igang? Det lyder ikke sådan må jeg indrømme. Hvis du havde ville du vide at alt er testet så meget som det er muligt inden det bliver sat i drift eller skifter navn til et prod system...
#31
Hvorfor ikke?
Proceduren er ikke den samme, selvfoelgelig, men basalt set er konceptet praecis det samme - uanset om vi snakker IBM, MS eller "Hr Jensens homofirma" .. :)
Ting skal testes, der skal tages backup, etc.
Niveauerne er selvfoelgelig helt forskellige, men generelt ser jeg ikke den store forskel i de basale principper.
Saa risikerer du blot nedbrud som dette.
Jeg ville foretraekke at teste systemet loebende, hvilket jeg umiddelbart ikke har faaet nogen klager over overhovedet.
Selvfoelgelig ikke, men alt efter prioritet, saa *boer* der vaere ret udspecificerede kommandoveje til en loesning.
Tests i implementeringsfasen er fint, det er bare ikke saa brugbart naar der sker et nedbrud i produktionsfasen ;)
Naeh, hvorfor er det et krav?
Jeg udtaler mig om de basale principper, thats it.
Derudover har jeg set mange *store* systemer ( som ioevrigt bliver testet loebende ) og kender et par stykker der sidder med systemer i milliard-klassen.
Det ved jeg skam godt, men som du kan se paa nyheden her, saa hjalp det ikke saa fandens meget igen i lige netop dette tilfaelde.
Hvilket igen underbygger at tests i produktionsfasen ogsaa er vigtigt. :)
Du kan ikke helt sammenligne det med når du selv fjoller rundt i det lilleblad hus du er ansat i.. :p
Hvorfor ikke?
Proceduren er ikke den samme, selvfoelgelig, men basalt set er konceptet praecis det samme - uanset om vi snakker IBM, MS eller "Hr Jensens homofirma" .. :)
Ting skal testes, der skal tages backup, etc.
Niveauerne er selvfoelgelig helt forskellige, men generelt ser jeg ikke den store forskel i de basale principper.
Sådan fungerer det så ikke den i virkelige verden af flere årsager. Den primære er at man ikke bare forsøger noget man planlægger tester og planlægger lidt mere og så hiver man stikket. Men det er altsammen gjort inden systemet bliver sat i drift.
Saa risikerer du blot nedbrud som dette.
Jeg ville foretraekke at teste systemet loebende, hvilket jeg umiddelbart ikke har faaet nogen klager over overhovedet.
Man står ikke altid klar til den slags nedbrud.
Selvfoelgelig ikke, men alt efter prioritet, saa *boer* der vaere ret udspecificerede kommandoveje til en loesning.
Det er derfor man laver den her slags test i implementeringsfasen.
Tests i implementeringsfasen er fint, det er bare ikke saa brugbart naar der sker et nedbrud i produktionsfasen ;)
Har du været med til at sætte et større projekt igang?
Naeh, hvorfor er det et krav?
Jeg udtaler mig om de basale principper, thats it.
Derudover har jeg set mange *store* systemer ( som ioevrigt bliver testet loebende ) og kender et par stykker der sidder med systemer i milliard-klassen.
Hvis du havde ville du vide at alt er testet så meget som det er muligt inden det bliver sat i drift eller skifter navn til et prod system...
Det ved jeg skam godt, men som du kan se paa nyheden her, saa hjalp det ikke saa fandens meget igen i lige netop dette tilfaelde.
Hvilket igen underbygger at tests i produktionsfasen ogsaa er vigtigt. :)
#32
Og hvordan skulle IBM formulere sig overfor kunden når de skal gribe knoglen og sige "Hej, øøøhhh jeres netbank er lige røget ned, fordi vi har en ansat som lige testede redundans - for det skal jo virke, så det var jo ikke et problem at han testede det i primetime. Men redundant, var det ikke lige tihihi"
Helt seriøst, hvis jeg var kunde hos et firma hvor en medarbejder tester redundans efter forgodt befindende, så ville jeg skifte leverandør, og jeg skal love dig det ville gå stærkt!
Fair nok at du vil teste redundansen, men du må være ansat hos JayNet eller sådan en lille udbyder, hvis du mener at det er fair nok at teste redundans når du synes det er sjov.
En ting er at det skal virke og der ikke skal være noget problem i at gøre det, det er vi meget enige om. Men risikoen for at kunden mister data/oppetid og dermed penge, om den så er 1%, så kunne jeg aldrig drømme om at udsætte dem for den risiko.
Når det så er sagt, så skal man ikke have været lang tid i hostingbranchen for at vide, at man kan beskrive sig ud af en masse problemer, fange en masse mulige nedbrud før de sker. Man kan dokumentere hvilke fejl man kan tænke sig til og rette setuppet til så de fejl ikke vil koste oppetid.
Men NÅR man så ryger ned, så er det DEN fejl man ikke fik tænkt sig til, som opstår...
Og hvordan skulle IBM formulere sig overfor kunden når de skal gribe knoglen og sige "Hej, øøøhhh jeres netbank er lige røget ned, fordi vi har en ansat som lige testede redundans - for det skal jo virke, så det var jo ikke et problem at han testede det i primetime. Men redundant, var det ikke lige tihihi"
Helt seriøst, hvis jeg var kunde hos et firma hvor en medarbejder tester redundans efter forgodt befindende, så ville jeg skifte leverandør, og jeg skal love dig det ville gå stærkt!
Fair nok at du vil teste redundansen, men du må være ansat hos JayNet eller sådan en lille udbyder, hvis du mener at det er fair nok at teste redundans når du synes det er sjov.
En ting er at det skal virke og der ikke skal være noget problem i at gøre det, det er vi meget enige om. Men risikoen for at kunden mister data/oppetid og dermed penge, om den så er 1%, så kunne jeg aldrig drømme om at udsætte dem for den risiko.
Når det så er sagt, så skal man ikke have været lang tid i hostingbranchen for at vide, at man kan beskrive sig ud af en masse problemer, fange en masse mulige nedbrud før de sker. Man kan dokumentere hvilke fejl man kan tænke sig til og rette setuppet til så de fejl ikke vil koste oppetid.
Men NÅR man så ryger ned, så er det DEN fejl man ikke fik tænkt sig til, som opstår...
#33
Hvorfor vil du teste det i primetime?
Det er da dumt?
Jeg tester redundans efter forgodtbefindende, fordi jeg ved at jeg kan have systemet oppe igen indenfor 5-10 minutter.
Jeg er slet ikke ansat hos en ISP.
Hvis du ikke tester systemet, saa udsaetter du dem for denne risiko *KONSTANT*, saa din udtalelse giver ingen mening.
Det er altsammen meget fint og flot, men som med alt andet, saa er teori ikke altid det samme som praksis.
Som muligvis kunne vaere forebygget ved en "live" test.
Eller rettere, live testen kunne have vist dig fejlen paa et tidspunkt hvor kunderne *er* advaret og du har kontrol over situationen.
Fremfor naar *du* ( som den eneste der kan fixe problemet ) ligger paa Barbados, midt i et blowjob, og uden stroem paa telefonen.
Og hvordan skulle IBM formulere sig overfor kunden når de skal gribe knoglen og sige "Hej, øøøhhh jeres netbank er lige røget ned, fordi vi har en ansat som lige testede redundans - for det skal jo virke, så det var jo ikke et problem at han testede det i primetime. Men redundant, var det ikke lige tihihi"
Hvorfor vil du teste det i primetime?
Det er da dumt?
Helt seriøst, hvis jeg var kunde hos et firma hvor en medarbejder tester redundans efter forgodt befindende, så ville jeg skifte leverandør, og jeg skal love dig det ville gå stærkt!
Jeg tester redundans efter forgodtbefindende, fordi jeg ved at jeg kan have systemet oppe igen indenfor 5-10 minutter.
Fair nok at du vil teste redundansen, men du må være ansat hos JayNet eller sådan en lille udbyder, hvis du mener at det er fair nok at teste redundans når du synes det er sjov.
Jeg er slet ikke ansat hos en ISP.
En ting er at det skal virke og der ikke skal være noget problem i at gøre det, det er vi meget enige om. Men risikoen for at kunden mister data/oppetid og dermed penge, om den så er 1%, så kunne jeg aldrig drømme om at udsætte dem for den risiko.
Hvis du ikke tester systemet, saa udsaetter du dem for denne risiko *KONSTANT*, saa din udtalelse giver ingen mening.
Når det så er sagt, så skal man ikke have været lang tid i hostingbranchen for at vide, at man kan beskrive sig ud af en masse problemer, fange en masse mulige nedbrud før de sker. Man kan dokumentere hvilke fejl man kan tænke sig til og rette setuppet til så de fejl ikke vil koste oppetid.
Det er altsammen meget fint og flot, men som med alt andet, saa er teori ikke altid det samme som praksis.
Men NÅR man så ryger ned, så er det DEN fejl man ikke fik tænkt sig til, som opstår...
Som muligvis kunne vaere forebygget ved en "live" test.
Eller rettere, live testen kunne have vist dig fejlen paa et tidspunkt hvor kunderne *er* advaret og du har kontrol over situationen.
Fremfor naar *du* ( som den eneste der kan fixe problemet ) ligger paa Barbados, midt i et blowjob, og uden stroem paa telefonen.
#30 & #32
Der er 2 meget gode grunde til ikke at teste redundans mens der kører production:
1) hvis failover ikke virker så er den gal
2) hvis faiover virker med den box der tager over får et problem mens den er ene (forudsat at man ikke kører 3 eller 4)
Det bør laves i et service vindue.
En drifts-mand der valgte at lave en redundans test midt i production sådant et sted ville skulle på arbejds-formidlingen næste dag.
Der er 2 meget gode grunde til ikke at teste redundans mens der kører production:
1) hvis failover ikke virker så er den gal
2) hvis faiover virker med den box der tager over får et problem mens den er ene (forudsat at man ikke kører 3 eller 4)
Det bør laves i et service vindue.
En drifts-mand der valgte at lave en redundans test midt i production sådant et sted ville skulle på arbejds-formidlingen næste dag.
#32
[qoute]
Hvorfor ikke?
Proceduren er ikke den samme, selvfoelgelig, men basalt set er konceptet praecis det samme - uanset om vi snakker IBM, MS eller "Hr Jensens homofirma" .. :)
Ting skal testes, der skal tages backup, etc.
Niveauerne er selvfoelgelig helt forskellige, men generelt ser jeg ikke den store forskel i de basale principper.
[/qoute]
Nu ved jeg ikke hvilke aftaler der er lavet mellem dig og dit firma. Altså hvilken SLA der er lavet men du kan være helt sikker på at Danske Bank har sørget for at tests af failover bliver lavet såfremt det mener det er nødvendigt. Og jeg nægter at tro på at IBM ikke har testet det her setup så grundigt som det er muligt.
[qoute]
Saa risikerer du blot nedbrud som dette.
Jeg ville foretraekke at teste systemet loebende, hvilket jeg umiddelbart ikke har faaet nogen klager over overhovedet.
[/qoute]
Hvordan vil du undgå den her slags nedbrud ved at teste fail over? Bare i det hosting firma jeg er i er vi 100+ ansatte der gerne vil vide hvordan vi undgår nedbrud ved at teste.
[qoute]
Selvfoelgelig ikke, men alt efter prioritet, saa *boer* der vaere ret udspecificerede kommandoveje til en loesning.
[/qoute]
Jeg er ikke i tvivl om at de har en række fastlagte procedurer for hvordan en sådan sag håndteres og disse er med stor sansynlighed lavet i samarbejde med kunden.
[qoute]
Tests i implementeringsfasen er fint, det er bare ikke saa brugbart naar der sker et nedbrud i produktionsfasen ;)
[/qoute]
Fordi?
[qoute]
Naeh, hvorfor er det et krav?
Jeg udtaler mig om de basale principper, thats it.
Derudover har jeg set mange *store* systemer ( som ioevrigt bliver testet loebende ) og kender et par stykker der sidder med systemer i milliard-klassen.
[/qoute]
Det er ikke et krav nej. Det var mere for at få klarlagt om du havde noget at have din bedre viden i. Det er jo så ikke tilfældet.
[qoute]
Det ved jeg skam godt, men som du kan se paa nyheden her, saa hjalp det ikke saa fandens meget igen i lige netop dette tilfaelde.
Hvilket igen underbygger at tests i produktionsfasen ogsaa er vigtigt. :)
[/qoute]
Du har stadig ikke på nogen måde vist at yderligere tests kunne have stoppet det her fra at ske..? Eller for den sags skyld at redudans er løsningen. Inden du kommer med flere vilde påstande burde du måske lige underbygge de andre først.
#43
[qoute]
Hvorfor vil du teste det i primetime?
Det er da dumt?
[/qoute]
Meget dumt. Og en holdningsforbedrende samtale ville formentlig være billigt sluppet i det tilfælde.
[qoute]
Jeg tester redundans efter forgodtbefindende, fordi jeg ved at jeg kan have systemet oppe igen indenfor 5-10 minutter.
[/qoute]
Og IBM teknikerne brugte 90 minutter fordi de lige tog sig et par kaffepauser og en frokost i fejlsøgningen ikke..? Eller er det måske fordi det er så meget mere komplekst? Hvis/når du giver mig ret i det sidste kan du måske se hvor fjollet din sammeligning er.
[qoute]
Hvis du ikke tester systemet, saa udsaetter du dem for denne risiko *KONSTANT*, saa din udtalelse giver ingen mening.
[/qoute]
Så længe du ikke kan underbygge din påstand om at konstante tests kan afhjælpe den her slags problemer give din egen udtalelse mindre mening... Test når du har lavet ændringer på systemet. Eller har du så lidt styr på hvad du laver at du mener du bør teste alt hele tiden?
[qoute]
Det er altsammen meget fint og flot, men som med alt andet, saa er teori ikke altid det samme som praksis.
[/qoute]
Og at være sys adm i et lille blad hus er ikke det samme som at være sys adm i en hosting virksomhed hvor vi laver det her til hverdag.
[qoute]
Som muligvis kunne vaere forebygget ved en "live" test.
Eller rettere, live testen kunne have vist dig fejlen paa et tidspunkt hvor kunderne *er* advaret og du har kontrol over situationen.
Fremfor naar *du* ( som den eneste der kan fixe problemet ) ligger paa Barbados, midt i et blowjob, og uden stroem paa telefonen.
[/qoute]
Kan du ikke lige forklare os andre en gang for alle hvordan man tester alle leder og kanter i et ret stort og komplekst setup?
#35
Med røde ører efter den skideballe man har fået inden man fik sparket.
[qoute]
Hvorfor ikke?
Proceduren er ikke den samme, selvfoelgelig, men basalt set er konceptet praecis det samme - uanset om vi snakker IBM, MS eller "Hr Jensens homofirma" .. :)
Ting skal testes, der skal tages backup, etc.
Niveauerne er selvfoelgelig helt forskellige, men generelt ser jeg ikke den store forskel i de basale principper.
[/qoute]
Nu ved jeg ikke hvilke aftaler der er lavet mellem dig og dit firma. Altså hvilken SLA der er lavet men du kan være helt sikker på at Danske Bank har sørget for at tests af failover bliver lavet såfremt det mener det er nødvendigt. Og jeg nægter at tro på at IBM ikke har testet det her setup så grundigt som det er muligt.
[qoute]
Saa risikerer du blot nedbrud som dette.
Jeg ville foretraekke at teste systemet loebende, hvilket jeg umiddelbart ikke har faaet nogen klager over overhovedet.
[/qoute]
Hvordan vil du undgå den her slags nedbrud ved at teste fail over? Bare i det hosting firma jeg er i er vi 100+ ansatte der gerne vil vide hvordan vi undgår nedbrud ved at teste.
[qoute]
Selvfoelgelig ikke, men alt efter prioritet, saa *boer* der vaere ret udspecificerede kommandoveje til en loesning.
[/qoute]
Jeg er ikke i tvivl om at de har en række fastlagte procedurer for hvordan en sådan sag håndteres og disse er med stor sansynlighed lavet i samarbejde med kunden.
[qoute]
Tests i implementeringsfasen er fint, det er bare ikke saa brugbart naar der sker et nedbrud i produktionsfasen ;)
[/qoute]
Fordi?
[qoute]
Naeh, hvorfor er det et krav?
Jeg udtaler mig om de basale principper, thats it.
Derudover har jeg set mange *store* systemer ( som ioevrigt bliver testet loebende ) og kender et par stykker der sidder med systemer i milliard-klassen.
[/qoute]
Det er ikke et krav nej. Det var mere for at få klarlagt om du havde noget at have din bedre viden i. Det er jo så ikke tilfældet.
[qoute]
Det ved jeg skam godt, men som du kan se paa nyheden her, saa hjalp det ikke saa fandens meget igen i lige netop dette tilfaelde.
Hvilket igen underbygger at tests i produktionsfasen ogsaa er vigtigt. :)
[/qoute]
Du har stadig ikke på nogen måde vist at yderligere tests kunne have stoppet det her fra at ske..? Eller for den sags skyld at redudans er løsningen. Inden du kommer med flere vilde påstande burde du måske lige underbygge de andre først.
#43
[qoute]
Hvorfor vil du teste det i primetime?
Det er da dumt?
[/qoute]
Meget dumt. Og en holdningsforbedrende samtale ville formentlig være billigt sluppet i det tilfælde.
[qoute]
Jeg tester redundans efter forgodtbefindende, fordi jeg ved at jeg kan have systemet oppe igen indenfor 5-10 minutter.
[/qoute]
Og IBM teknikerne brugte 90 minutter fordi de lige tog sig et par kaffepauser og en frokost i fejlsøgningen ikke..? Eller er det måske fordi det er så meget mere komplekst? Hvis/når du giver mig ret i det sidste kan du måske se hvor fjollet din sammeligning er.
[qoute]
Hvis du ikke tester systemet, saa udsaetter du dem for denne risiko *KONSTANT*, saa din udtalelse giver ingen mening.
[/qoute]
Så længe du ikke kan underbygge din påstand om at konstante tests kan afhjælpe den her slags problemer give din egen udtalelse mindre mening... Test når du har lavet ændringer på systemet. Eller har du så lidt styr på hvad du laver at du mener du bør teste alt hele tiden?
[qoute]
Det er altsammen meget fint og flot, men som med alt andet, saa er teori ikke altid det samme som praksis.
[/qoute]
Og at være sys adm i et lille blad hus er ikke det samme som at være sys adm i en hosting virksomhed hvor vi laver det her til hverdag.
[qoute]
Som muligvis kunne vaere forebygget ved en "live" test.
Eller rettere, live testen kunne have vist dig fejlen paa et tidspunkt hvor kunderne *er* advaret og du har kontrol over situationen.
Fremfor naar *du* ( som den eneste der kan fixe problemet ) ligger paa Barbados, midt i et blowjob, og uden stroem paa telefonen.
[/qoute]
Kan du ikke lige forklare os andre en gang for alle hvordan man tester alle leder og kanter i et ret stort og komplekst setup?
#35
Med røde ører efter den skideballe man har fået inden man fik sparket.
Hubert (31) skrev:Ved du noget vi andre ikke ved? Jeg har ihvertfald ikke kunne finde noget der viser at de ikke har redundans. Det er måske ikke 100% men jeg vil da godt holde en kasse flødeboller på at de på de vigtigste dele har redundans.
Der står i resumeet:
Nedbrudet skyldtes ifølge Danske Bank "en fejl i et Unix-subsystem på én instans af bankens mainframe-systemer".
Hvis det får nævneværdige konsekvenser, så er der enten ikke redundans, eller også er der noget failover der fejler.
Da netbanken gik ned på grund af dette, må vi konkludere at det var en vigtig del.
Enten fejlede failover-mekaniskmen, eller også skylder du en kasse flødeboller. ;-)
#39
Det er en lidt mystisk formulering.
Jeg gætter på at det er en Linux/390 instans som har haft et problem.
Og at formuleringen skyldes at den har været igennem et hav af ikke tekniske reviewere.
Og jeg er ret sikker på at et sådant system her redundans - det må være failover som har failet.
Det er en lidt mystisk formulering.
Jeg gætter på at det er en Linux/390 instans som har haft et problem.
Og at formuleringen skyldes at den har været igennem et hav af ikke tekniske reviewere.
Og jeg er ret sikker på at et sådant system her redundans - det må være failover som har failet.
#39
Tak.
#35
Ret daarlige grunde imo.
Til forskel fra at failover ikke virker midt i prime-time mens alle er paa ferie?..... ?
Hvis failover virker, saa er det naeppe et problem at re-implementere boks #1.
Og hvis det er, saa er du jo heldig at dette er sket mens du er on-site og har kontrol over tingene.
Ja, men for systemer hvor produktion er 24/7, saa vil det noedvendigvis vaere i et "live" system.
#38
Du missede saa "personligt", eller hvad?
Jeg er ikke ansat hos IBM, og udtalte mig netop om det system jeg administrerer.
At det skal goere anderledes hos IBM, aendrer ikke paa at det skal goeres.
#37
Jeg siger at det *MULIGVIS* kan undgaaes.
Jeg aner intet om hvad de reelt har lavet af tests.
Det er logisk at man aldrig kan teste alt, men loebende tests ser jeg som den "nemmeste" mulighed for at komme saa meget rundt som muligt.
Eller ogsaa var det flere ting der gjorde udslaget?
Fx at det var et uventet nedbrud som man ikke havde kontrol over?
Du indser maaske engang at de basale principper er det samme, jeg er i hvert fald traet af at sige det :)
Bedreviden om hvad? De basale principper?
Jeg kan ikke umiddelbart tro andet end at folkene hos IBM ved det samme ( eller mere ) end jeg goer, hvorfor jeg netop undrer mig over *HVAD* der er gaaet galt, da det er ret tydeligt at der er gaaet noget galt.
Jeg kan ikke umiddelbart se hvad der skal underbygges, medmindre jeres system er 100% statisk?
Det er vores ikke, derfor tester jeg det loebende.
Umiddelbart tester jeg alt med risiko for at fejle, loebende.
Du ved, en slags "better safe than sorry"-taktik.
Og naar systemet saa fejler midt i produktionstid, hvad saa?
Hvis du ved at introducere en fejl, opdager en anden, ( noget jeg ret tit hoerer om i forbindelse med fejl-soegning .... ) saa kunne det muligvis vaere opdaget inden du staar med lorten i munden.
Off-topic, eftersom jeg ikke er den eneste admin og MISA konstant stikker fingrene ind i alle systemer de kan komme i naerheden af, saa er der ikke umiddelbart meget kontrol over hvem der laver hvilke aendringer..
- Hvorfor *jeg* tester i tide og utide.
Tillykke.
Jeg siger paa ingen maade at det er det samme, blot at de basale principper *er* de samme.
Men omvendt kan du maaske forklare hvori forskellen ligger?
I tager ikke backup? I har ikke failover?
I har ikke procedurer for fejlsoegning eller "Recovery" ?
I har ikke prioriteringer?
Det kan ikke lade sig goere.
KAn du ikke forklare mig hvorfor loebende tests er ubrugelige?
Tak.
#35
Der er 2 meget gode grunde til ikke at teste redundans mens der kører production:
Ret daarlige grunde imo.
1) hvis failover ikke virker så er den gal
Til forskel fra at failover ikke virker midt i prime-time mens alle er paa ferie?..... ?
2) hvis faiover virker med den box der tager over får et problem mens den er ene (forudsat at man ikke kører 3 eller 4)
Hvis failover virker, saa er det naeppe et problem at re-implementere boks #1.
Og hvis det er, saa er du jo heldig at dette er sket mens du er on-site og har kontrol over tingene.
Det bør laves i et service vindue.
Ja, men for systemer hvor produktion er 24/7, saa vil det noedvendigvis vaere i et "live" system.
#38
I #25. Jeg kan ihvertfald ikke læse "ud af produktion" og "emergency repair" som værende i et service vindue.
Du missede saa "personligt", eller hvad?
Jeg er ikke ansat hos IBM, og udtalte mig netop om det system jeg administrerer.
At det skal goere anderledes hos IBM, aendrer ikke paa at det skal goeres.
#37
Hvordan vil du undgå den her slags nedbrud ved at teste fail over? Bare i det hosting firma jeg er i er vi 100+ ansatte der gerne vil vide hvordan vi undgår nedbrud ved at teste.
Jeg siger at det *MULIGVIS* kan undgaaes.
Jeg aner intet om hvad de reelt har lavet af tests.
Det er logisk at man aldrig kan teste alt, men loebende tests ser jeg som den "nemmeste" mulighed for at komme saa meget rundt som muligt.
Og IBM teknikerne brugte 90 minutter fordi de lige tog sig et par kaffepauser og en frokost i fejlsøgningen ikke..? Eller er det måske fordi det er så meget mere komplekst?
Eller ogsaa var det flere ting der gjorde udslaget?
Fx at det var et uventet nedbrud som man ikke havde kontrol over?
Hvis/når du giver mig ret i det sidste kan du måske se hvor fjollet din sammeligning er.
Du indser maaske engang at de basale principper er det samme, jeg er i hvert fald traet af at sige det :)
Det er ikke et krav nej. Det var mere for at få klarlagt om du havde noget at have din bedre viden i. Det er jo så ikke tilfældet.
Bedreviden om hvad? De basale principper?
Jeg kan ikke umiddelbart tro andet end at folkene hos IBM ved det samme ( eller mere ) end jeg goer, hvorfor jeg netop undrer mig over *HVAD* der er gaaet galt, da det er ret tydeligt at der er gaaet noget galt.
Så længe du ikke kan underbygge din påstand om at konstante tests kan afhjælpe den her slags problemer give din egen udtalelse mindre mening...
Jeg kan ikke umiddelbart se hvad der skal underbygges, medmindre jeres system er 100% statisk?
Det er vores ikke, derfor tester jeg det loebende.
Umiddelbart tester jeg alt med risiko for at fejle, loebende.
Du ved, en slags "better safe than sorry"-taktik.
Test når du har lavet ændringer på systemet.
Og naar systemet saa fejler midt i produktionstid, hvad saa?
Hvis du ved at introducere en fejl, opdager en anden, ( noget jeg ret tit hoerer om i forbindelse med fejl-soegning .... ) saa kunne det muligvis vaere opdaget inden du staar med lorten i munden.
Eller har du så lidt styr på hvad du laver at du mener du bør teste alt hele tiden?
Off-topic, eftersom jeg ikke er den eneste admin og MISA konstant stikker fingrene ind i alle systemer de kan komme i naerheden af, saa er der ikke umiddelbart meget kontrol over hvem der laver hvilke aendringer..
- Hvorfor *jeg* tester i tide og utide.
Og at være sys adm i et lille blad hus er ikke det samme som at være sys adm i en hosting virksomhed hvor vi laver det her til hverdag.
Tillykke.
Jeg siger paa ingen maade at det er det samme, blot at de basale principper *er* de samme.
Men omvendt kan du maaske forklare hvori forskellen ligger?
I tager ikke backup? I har ikke failover?
I har ikke procedurer for fejlsoegning eller "Recovery" ?
I har ikke prioriteringer?
Kan du ikke lige forklare os andre en gang for alle hvordan man tester alle leder og kanter i et ret stort og komplekst setup?
Det kan ikke lade sig goere.
KAn du ikke forklare mig hvorfor loebende tests er ubrugelige?
#41
Jeg kan ikke helt se din pointe.
Der er 3 strategier:
1) ikke teste
2) teste i produktions tiden
3) teste i service vindue
Der er 2 outcomes for failover:
A) virker
B) virker ikke
1B og 2B får drifts manden fyret på gråt papir fordi det giver en unødvendig produktions forstyrrelse.
Hvorfor smarte drifts folk naturligvis vælger 3.
Selvom det tager kort tid at retablere, så er det stadigvæk en driftsforstyrrelse.
Duer ikke.
Til forskel fra at failover ikke virker midt i prime-time mens alle er paa ferie?..... ?
Jeg kan ikke helt se din pointe.
Der er 3 strategier:
1) ikke teste
2) teste i produktions tiden
3) teste i service vindue
Der er 2 outcomes for failover:
A) virker
B) virker ikke
1B og 2B får drifts manden fyret på gråt papir fordi det giver en unødvendig produktions forstyrrelse.
Hvorfor smarte drifts folk naturligvis vælger 3.
Hvis failover virker, saa er det naeppe et problem at re-implementere boks #1.
Og hvis det er, saa er du jo heldig at dette er sket mens du er on-site og har kontrol over tingene.
Selvom det tager kort tid at retablere, så er det stadigvæk en driftsforstyrrelse.
Duer ikke.
#42
Saa maa du jo goere det i et service vindue.
Problemet med tests i et service vindue, vil typisk vaere at der er meget, meget, lidt aktivitet paa maskinerne.
Saa, som jeg sagde, du tester bare i et service vindue hvis det er det du vil, jeg siger blot at det skal vaere i et produktionsmiljoe.
.... Saa, 24*7 betyder ikke "ingen service vinduer" - bortset fra naar det betyder "ingen service vinduer" ? ....
Hvis du har et system der skal vaere aktivt 24/7, saa vil du blot undlade at teste det, eller hvad?
Saa maa du jo goere det i et service vindue.
Problemet med tests i et service vindue, vil typisk vaere at der er meget, meget, lidt aktivitet paa maskinerne.
Saa, som jeg sagde, du tester bare i et service vindue hvis det er det du vil, jeg siger blot at det skal vaere i et produktionsmiljoe.
24*7 betyder ikke ingen service vinduer.
Der er næsten ingen systemer som kører uden service vinduer.
.... Saa, 24*7 betyder ikke "ingen service vinduer" - bortset fra naar det betyder "ingen service vinduer" ? ....
Hvis du har et system der skal vaere aktivt 24/7, saa vil du blot undlade at teste det, eller hvad?
arne_v (38) skrev:#36
I #25. Jeg kan ihvertfald ikke læse "ud af produktion" og "emergency repair" som værende i et service vindue.
Nødservice vindue :) Hvad IBM og andre kalder dem ved jeg ikke.
fidomuh (41) skrev:
Jeg siger at det *MULIGVIS* kan undgaaes.
Jeg aner intet om hvad de reelt har lavet af tests.
Det er logisk at man aldrig kan teste alt, men loebende tests ser jeg som den "nemmeste" mulighed for at komme saa meget rundt som muligt.
Nu kan man så bare ikke prøve sig frem på et produktionsmiljø.
Eller ogsaa var det flere ting der gjorde udslaget?
Fx at det var et uventet nedbrud som man ikke havde kontrol over?
Velkommen til den virkelige verden hvor man ikke altid har kontrol over alt.
Du indser maaske engang at de basale principper er det samme, jeg er i hvert fald traet af at sige det :)
Hvordan er det, det samme på det basale niveau? Du taler om at teste noget så simpelt som fail over. Jeg tvivler stadig på at teknikerne hos IBM ikke har testet noget så simpelt.
Bedreviden om hvad? De basale principper?
Jeg kan ikke umiddelbart tro andet end at folkene hos IBM ved det samme ( eller mere ) end jeg goer, hvorfor jeg netop undrer mig over *HVAD* der er gaaet galt, da det er ret tydeligt at der er gaaet noget galt.
Om hvordan man driver en større kompleks løsning...
Jeg kan ikke umiddelbart se hvad der skal underbygges, medmindre jeres system er 100% statisk?
Det er vores ikke, derfor tester jeg det loebende.
Umiddelbart tester jeg alt med risiko for at fejle, loebende.
Du ved, en slags "better safe than sorry"-taktik.
Du kan jo starte med at undbygge din påstand om at man ikke havde fået problemet hvis man havde lavet løbende tests på systemet.
Og naar systemet saa fejler midt i produktionstid, hvad saa?
Hvis du ved at introducere en fejl, opdager en anden, ( noget jeg ret tit hoerer om i forbindelse med fejl-soegning .... ) saa kunne det muligvis vaere opdaget inden du staar med lorten i munden.
Endnu en påstand du bør underbygge... Jeg ved ikke hvordan de gør tingene hos IBM. Jeg ved bare at serverne gennemgår en test inden de bliver sat i drift hos os. Og jeg tvivler meget på at det er anderledes hos IBM.
Off-topic, eftersom jeg ikke er den eneste admin og MISA konstant stikker fingrene ind i alle systemer de kan komme i naerheden af, saa er der ikke umiddelbart meget kontrol over hvem der laver hvilke aendringer..
- Hvorfor *jeg* tester i tide og utide.
Man dokumenterer vel sit arbejde når man arbejder på et system?
Tillykke.
Jeg siger paa ingen maade at det er det samme, blot at de basale principper *er* de samme.
Men omvendt kan du maaske forklare hvori forskellen ligger?
I tager ikke backup? I har ikke failover?
I har ikke procedurer for fejlsoegning eller "Recovery" ?
I har ikke prioriteringer?
Vi har backup af så godt som alt. Vi har indtil flere systemer med failover og vi har såmænd også procedurer for mange ting. Typisk bliver en procedure født ved at man oplever en fejl og så dokumenterer man hvordan problemet løses.
Det kan ikke lade sig goere.
KAn du ikke forklare mig hvorfor loebende tests er ubrugelige?
Jeg har vist ikke sagt at det var ubruglige..? Jeg har vist nærmere sagt at det ikke er en silver bullet løsning som du gerne vil have det til at fremstå som... Når vi laver større ændringer på vores kundeløsninger laver vi en plan for både udførelse af ændringen og en rollback plan. Som iøvrigt skal godkendes af kunden samt en kollega så der er 2 teknikere plus kunden der har sagt go' for ændringen og en rollback plan førend det bliver sat i drift. Gør i det sådan hos jer..? Måske i burde overveje det for at undgå at skulle lave tests i tide og utide.
fidomuh (44) skrev:
Saa maa du jo goere det i et service vindue.
Problemet med tests i et service vindue, vil typisk vaere at der er meget, meget, lidt aktivitet paa maskinerne.
Saa, som jeg sagde, du tester bare i et service vindue hvis det er det du vil, jeg siger blot at det skal vaere i et produktionsmiljoe.
Kan du ikke lige forklare hvorfor det skal være et prod miljø..? Ved du hvad et staging miljø er?
.... Saa, 24*7 betyder ikke "ingen service vinduer" - bortset fra naar det betyder "ingen service vinduer" ? ....
Hvis du har et system der skal vaere aktivt 24/7, saa vil du blot undlade at teste det, eller hvad?
Hvis du har et system der skal køre 24/7 sørger man for at designe det sådan at man kan tage dele af systemet ned for at kunne tage service vindue på den del.
#45
Det kommer saa an paa hvor man arbejder, men der er nu heller ingen der siger de bare skal proeve sig frem.
Der har jeg skam vaeret hele tiden.
Err? Du glemte hvad du selv mente, eller hvad?
Du siger at det er noget helt andet, fordi deres firma er stoerre. Jeg siger at de basale principper i driften er de samme.
...?
Eh, hvorfor skulle jeg vaere bedrevidende om det?
Jeg udtaler mig netop om de basale principper, som jeg vist har sagt flere gange nu.
Du kan proeve igen naar du har laest hvad jeg skriver.
Ordet *muligvis* er maaske et godt ord at opdage.
Jeg skal underbygge at det muligvis kunne vaere opdaget?
Tillykke.
Det er bare tydeligvis ikke *nok* de har testet.
Hvorfor jeg netop naevner at loebende tests af systemet *KAN* give et langt mere kontrolleret nedbrud i tilfaelde af fejl.
MISA fortaeller mig ikke engang at de har kigget paa serveren.
Hvis jeg er heldig bliver jeg cc'et midt i en mail korrespondance. :)
Det er sgu sjovt, for det er ogsaa saadan det fungerer hos os..
*HELT ANDERLEDES* .. Det kan jeg godt se *host* ... :)
Nej, du vil blot have det til at fremstaa som ubrugeligt..?
Eller hvad?
Hvor siger jeg at det er en silver-bullet loesning?
Jeg siger blot at det *kan* opdage fejl der ikke er opdaget i test-fasen.
( Og i min erfaring med introduktion af nye systemer, er det i loebende tests de fleste fejl findes )
Hvad er en "stoerre" aendring?
Hvad hvis der kommer mange "smaa" aendringer, saa testes de ikke?
Eller "haaber" i bare at det ikke draeber maskineriet? :)
Nej, det ville vaere voldsomt overkill til vores setup.
For slet ikek at tale om at vi ikke har 2 teknikere ansat.
Selv hvis 100 teknikere havde godkendt hver enkelt miniman aendring, ville jeg anbefale loebende tests.
Aktivitet, brug, etc?
Jada, ved du hvad forskellen er paa et staging og et produktions miljoe?
Desvaerre er virkeligheden ikke saadan altid.
Nu kan man så bare ikke prøve sig frem på et produktionsmiljø.
Det kommer saa an paa hvor man arbejder, men der er nu heller ingen der siger de bare skal proeve sig frem.
Velkommen til den virkelige verden hvor man ikke altid har kontrol over alt.
Der har jeg skam vaeret hele tiden.
Hvordan er det, det samme på det basale niveau? Du taler om at teste noget så simpelt som fail over. Jeg tvivler stadig på at teknikerne hos IBM ikke har testet noget så simpelt.
Err? Du glemte hvad du selv mente, eller hvad?
Du siger at det er noget helt andet, fordi deres firma er stoerre. Jeg siger at de basale principper i driften er de samme.
...?
Om hvordan man driver en større kompleks løsning...
Eh, hvorfor skulle jeg vaere bedrevidende om det?
Jeg udtaler mig netop om de basale principper, som jeg vist har sagt flere gange nu.
Du kan jo starte med at undbygge din påstand om at man ikke havde fået problemet hvis man havde lavet løbende tests på systemet.
Du kan proeve igen naar du har laest hvad jeg skriver.
Ordet *muligvis* er maaske et godt ord at opdage.
Endnu en påstand du bør underbygge...
Jeg skal underbygge at det muligvis kunne vaere opdaget?
Jeg ved ikke hvordan de gør tingene hos IBM. Jeg ved bare at serverne gennemgår en test inden de bliver sat i drift hos os. Og jeg tvivler meget på at det er anderledes hos IBM.
Tillykke.
Det er bare tydeligvis ikke *nok* de har testet.
Hvorfor jeg netop naevner at loebende tests af systemet *KAN* give et langt mere kontrolleret nedbrud i tilfaelde af fejl.
Man dokumenterer vel sit arbejde når man arbejder på et system?
MISA fortaeller mig ikke engang at de har kigget paa serveren.
Hvis jeg er heldig bliver jeg cc'et midt i en mail korrespondance. :)
Vi har backup af så godt som alt. Vi har indtil flere systemer med failover og vi har såmænd også procedurer for mange ting. Typisk bliver en procedure født ved at man oplever en fejl og så dokumenterer man hvordan problemet løses.
Det er sgu sjovt, for det er ogsaa saadan det fungerer hos os..
*HELT ANDERLEDES* .. Det kan jeg godt se *host* ... :)
Jeg har vist ikke sagt at det var ubruglige..? Jeg har vist nærmere sagt at det ikke er en silver bullet løsning som du gerne vil have det til at fremstå som...
Nej, du vil blot have det til at fremstaa som ubrugeligt..?
Eller hvad?
Hvor siger jeg at det er en silver-bullet loesning?
Jeg siger blot at det *kan* opdage fejl der ikke er opdaget i test-fasen.
( Og i min erfaring med introduktion af nye systemer, er det i loebende tests de fleste fejl findes )
Når vi laver større ændringer på vores kundeløsninger laver vi en plan for både udførelse af ændringen og en rollback plan.
Hvad er en "stoerre" aendring?
Hvad hvis der kommer mange "smaa" aendringer, saa testes de ikke?
Eller "haaber" i bare at det ikke draeber maskineriet? :)
Som iøvrigt skal godkendes af kunden samt en kollega så der er 2 teknikere plus kunden der har sagt go' for ændringen og en rollback plan førend det bliver sat i drift. Gør i det sådan hos jer..?
Nej, det ville vaere voldsomt overkill til vores setup.
For slet ikek at tale om at vi ikke har 2 teknikere ansat.
Måske i burde overveje det for at undgå at skulle lave tests i tide og utide.
Selv hvis 100 teknikere havde godkendt hver enkelt miniman aendring, ville jeg anbefale loebende tests.
Kan du ikke lige forklare hvorfor det skal være et prod miljø..?
Aktivitet, brug, etc?
Ved du hvad et staging miljø er?
Jada, ved du hvad forskellen er paa et staging og et produktions miljoe?
Hvis du har et system der skal køre 24/7 sørger man for at designe det sådan at man kan tage dele af systemet ned for at kunne tage service vindue på den del.
Desvaerre er virkeligheden ikke saadan altid.
fidomuh (46) skrev:
Det kommer saa an paa hvor man arbejder, men der er nu heller ingen der siger de bare skal proeve sig frem.
Aha. Jeg vil da gerne vide hvilket hosting firma der vil lade deres folk stå frem og fortælle at de laver tests på kunde systemerne fordi de lige føler for det uden for service vinduer og hvad har vi.
Der har jeg skam vaeret hele tiden.
Beklager men det lyder ikke sådan.
Err? Du glemte hvad du selv mente, eller hvad?
Du siger at det er noget helt andet, fordi deres firma er stoerre. Jeg siger at de basale principper i driften er de samme.
...?
nej men jeg har jo efterhånden fundet ud af at det er nødvendigt at skære det ud i pap... :p Man tester IKKE fail over uden for et service vindue hvis man vil beholde sig job i et seriøst hosting firma.
Eh, hvorfor skulle jeg vaere bedrevidende om det?
Jeg udtaler mig netop om de basale principper, som jeg vist har sagt flere gange nu.
Ja det skal du da ikke spørge mig om. Det er dig der fører dig frem som om du ved bedre end os andre.
Du kan proeve igen naar du har laest hvad jeg skriver.
Ordet *muligvis* er maaske et godt ord at opdage.
Så i bund og grund bruger du tid på noget du faktisk ikke ved om der hjælper. Samtidig med at du risikerer at forstyrer den normale drift..? Og så har du svært ved at forstå hvorfor andre ikke mener det er en go' ide..?
Jeg skal underbygge at det muligvis kunne vaere opdaget?
Jeg beder dig blot underbygge dine påstande. Er det for meget for meget for dig?
Tillykke.
Det er bare tydeligvis ikke *nok* de har testet.
Hvorfor jeg netop naevner at loebende tests af systemet *KAN* give et langt mere kontrolleret nedbrud i tilfaelde af fejl.
Óg det kan forstyre den normale drift... uden at give nogen fordel i tilfælde af fejl. Uddyb lige hvordan det kan være en fordel?
MISA fortaeller mig ikke engang at de har kigget paa serveren.
Hvis jeg er heldig bliver jeg cc'et midt i en mail korrespondance. :)
Nitten.
Det er sgu sjovt, for det er ogsaa saadan det fungerer hos os..
*HELT ANDERLEDES* .. Det kan jeg godt se *host* ... :)
Det er ikke mig der påstår alt er anderledes hos os..? Det er vist snarre omvendt, hvor du mener at løbende tests åbenbart redder dig fra en masse arbejde.
Nej, du vil blot have det til at fremstaa som ubrugeligt..?
Eller hvad?
Hvor siger jeg at det er en silver-bullet loesning?
Jeg siger blot at det *kan* opdage fejl der ikke er opdaget i test-fasen.
( Og i min erfaring med introduktion af nye systemer, er det i loebende tests de fleste fejl findes )
Jeg prøver lige igen. Vi laver tests på vores kunde systemer når vi laver ændringer der kan have indflydelse på driften af disse. Skal det skæres yderligere ud i pap må du lige sige til.
Hvad er en "stoerre" aendring?
Hvad hvis der kommer mange "smaa" aendringer, saa testes de ikke?
Eller "haaber" i bare at det ikke draeber maskineriet? :)
Det er selvfølgelig et vurderings spørgsmål som man i starten tager med en ældre/mere erfarn kollega. Det er muligt at du mener at man kan nøjes med at håbe men den går ikke du.
Nej, det ville vaere voldsomt overkill til vores setup.
For slet ikek at tale om at vi ikke har 2 teknikere ansat.
Og alligevel mener du at have løsningen på problemerne for IBM og andre?
Selv hvis 100 teknikere havde godkendt hver enkelt miniman aendring, ville jeg anbefale loebende tests.
Basseret på?
Aktivitet, brug, etc?
Er det din undskyldning for at risikere at forstyre driften?
Jada, ved du hvad forskellen er paa et staging og et produktions miljoe?
Ja det gør jeg. Jeg ved også at det desværre er de færeste der mener et staging miljø er nødvendigt.
Desvaerre er virkeligheden ikke saadan altid.
Virkeligheden er desværre sjælent optimal
Hubert (48) skrev:Aha. Jeg vil da gerne vide hvilket hosting firma der vil lade deres folk stå frem og fortælle at de laver tests på kunde systemerne fordi de lige føler for det uden for service vinduer og hvad har vi.
Du kan da bare goere det i et service vindue?
Som jeg *har* skrevet flere gange?
Beklager men det lyder ikke sådan.
Nej, jeg kan godt se det er svaert at faa den opfattelse naar du ikke laeser hvad jeg skriver :)
nej men jeg har jo efterhånden fundet ud af at det er nødvendigt at skære det ud i pap... :p Man tester IKKE fail over uden for et service vindue hvis man vil beholde sig job i et seriøst hosting firma.
SAa maa du jo goere det i et service-vindue?
Derudover saa arbejder jeg *ikke* i et hosting selskab, hvorfor jeg netop udpenslede tidligere at det er saadan *JEG* goer det.
Og det er af samme aarsag at jeg tidligere har skrevet at du bare kan goere det i et service vindue.
Ja det skal du da ikke spørge mig om. Det er dig der fører dig frem som om du ved bedre end os andre.
Jeps, som naar jeg skriver at IBM nok ved bedre?
Så i bund og grund bruger du tid på noget du faktisk ikke ved om der hjælper.
Som du goer, naar du implementationstester?
Samtidig med at du risikerer at forstyrer den normale drift..?
Hvis jeg forstyrrer den normale drift, saa var der jo netop et problem ... Ikke?
Og hvornaar er det bedst at have nedbrud?
Naar du ikke forventer det?
Eller naar du er forberedt paa det?
Jeg beder dig blot underbygge dine påstande. Er det for meget for meget for dig?
Umiddelbart er der ikke noget at underbygge.
Det er ganske logisk at man ved at teste muligvis finder fejl.
Óg det kan forstyre den normale drift... uden at give nogen fordel i tilfælde af fejl. Uddyb lige hvordan det kan være en fordel?
Du kan ikke se fordelen i at vaere forberedt paa et nedbrud, og saa at nedbruddet kommer paa det vaerst taenkelige tidspunkt?
Jeg ved ikke hvor mange nedbrud du har oplevet, men jeg kan godt se forskellen og jeg ved godt hvad jeg foretraekker.
Det er ikke mig der påstår alt er anderledes hos os..? Det er vist snarre omvendt, hvor du mener at løbende tests åbenbart redder dig fra en masse arbejde.
Nej, jeg mener at loebenede tests kan vaere en ekstra sikkerhed ifbm. nedbrud.
Jeg prøver lige igen. Vi laver tests på vores kunde systemer når vi laver ændringer der kan have indflydelse på driften af disse.
Saa hvis i ikke laver aendringer i 10 aar, testes systemet ikke laengere?
Skal det skæres yderligere ud i pap må du lige sige til.
Skal du bruge briller?
Det er selvfølgelig et vurderings spørgsmål som man i starten tager med en ældre/mere erfarn kollega. Det er muligt at du mener at man kan nøjes med at håbe men den går ikke du.
OK?
Men alle de her 1000 smaa aendringer du nu har lavet, som jo ikke giver en "test-fase" ... Hvad med dem? Der kan ikke vaere fejl i ? ..
Og alligevel mener du at have løsningen på problemerne for IBM og andre?
Nej?
Jeg mener at have en ide som *maaske* kunne have forebygget det.
Basseret på?
"Better safe than sorry"
ogsaa kendt som "Dont trust humans" .. Eller "Stol ikke blindt paa din udvikler" ..
Er det din undskyldning for at risikere at forstyre driften?
Nej, min undskyldning er at jeg gerne vil finde fejl mens jeg staar klar til at rette dem, fremfor at de skal hive mig hjem fra barbados og risikere at miste en udgivelse.
Ja det gør jeg. Jeg ved også at det desværre er de færeste der mener et staging miljø er nødvendigt.
I realiteten vil et staging miljoe ogsaa vaere overkill i utroligt mange tilfaelde. Det afhaenger helt af systemet.
Virkeligheden er desværre sjælent optimal
Ain't that the truth.
Men alligevel saetter du din lid til at teste udelukkende *inden* produktion.
Vi har debatteret det paa IRC og jeg gider ikke fortsaette en quote-war her ;)
fidomuh (49) skrev:Du kan da bare goere det i et service vindue?
Som jeg *har* skrevet flere gange?
Det gør jeg også, men det giver jo ifølge dig selv ikke det optimale fordi der ikke er et normalt brug på systemet.
Nej, jeg kan godt se det er svaert at faa den opfattelse naar du ikke laeser hvad jeg skriver :)
Det er ikke fordi jeg ikke læser hvad du skriver. Det er måske fordi du ikke virker som om du har helt fat i den lange ende af virkeligheden her...
SAa maa du jo goere det i et service-vindue?
Derudover saa arbejder jeg *ikke* i et hosting selskab, hvorfor jeg netop udpenslede tidligere at det er saadan *JEG* goer det.
Og det er af samme aarsag at jeg tidligere har skrevet at du bare kan goere det i et service vindue.
Men tidligere var det jo et problem når der ikke er brugere på?
Jeps, som naar jeg skriver at IBM nok ved bedre?
Og alligevel mener du at du kan fortælle dem noget?
Som du goer, naar du implementationstester?
Nu fanger man så bare fejl når man tester et system inden man sætter det i drift.
Hvis jeg forstyrrer den normale drift, saa var der jo netop et problem ... Ikke?
Og hvornaar er det bedst at have nedbrud?
Naar du ikke forventer det?
Eller naar du er forberedt paa det?
Jeg vil ikke udsætte mine brugere/kunder for driftsforstyrelser fordi jeg vil teste noget.
Umiddelbart er der ikke noget at underbygge.
Det er ganske logisk at man ved at teste muligvis finder fejl.
Men kun når man tester prod miljøet ikke?
Du kan ikke se fordelen i at vaere forberedt paa et nedbrud, og saa at nedbruddet kommer paa det vaerst taenkelige tidspunkt?
Jeg ved ikke hvor mange nedbrud du har oplevet, men jeg kan godt se forskellen og jeg ved godt hvad jeg foretraekker.
Jo jeg kan sagtens se fordelen i at være forberedt ved nedbrud men det betyder ikke at jeg vil udsætte brugerne for bevist nedbrud midt i deres arbejde for at forberede mig. Det bør heller ikke være nødvendigt.
Nej, jeg mener at loebenede tests kan vaere en ekstra sikkerhed ifbm. nedbrud.
ja det siger du godt nok men du mangler stadig at underbygge den påstand.
Saa hvis i ikke laver aendringer i 10 aar, testes systemet ikke laengere?
Nu er det ikke synderligt sansynligt at et system ikke oplever ændringer i 10 år. Og skulle det ske at et system ikke oplever ændringer i bare et ½ år ville man formentlig skedulere et service vindue for at køre nogle tests.
Skal du bruge briller?
Ja jeg bruger briller.
OK?
Men alle de her 1000 smaa aendringer du nu har lavet, som jo ikke giver en "test-fase" ... Hvad med dem? Der kan ikke vaere fejl i ? ..
Hvis det er oprette en bruger eller tilsvarende kan vælte et system ville det være opdaget længe før systemet blev sat i drift.
Nej?
Jeg mener at have en ide som *maaske* kunne have forebygget det.
Uden at kunne underbygge den. Ingen af os kan udtale os om det ville hjælpe. Jeg tvivler. Jeg kan udtale mig ud fra at arbejde med hosting til dagligt hvad med dig?
"Better safe than sorry"
ogsaa kendt som "Dont trust humans" .. Eller "Stol ikke blindt paa din udvikler" ..
Der er jo en grund til at man laver pre drift tests
Nej, min undskyldning er at jeg gerne vil finde fejl mens jeg staar klar til at rette dem, fremfor at de skal hive mig hjem fra barbados og risikere at miste en udgivelse.
Og hvis du ikke kan løse problemet så hurtigt som forventet?
I realiteten vil et staging miljoe ogsaa vaere overkill i utroligt mange tilfaelde. Det afhaenger helt af systemet.
Og alligevel kunne det løse mange problemer.
Ain't that the truth.
Men alligevel saetter du din lid til at teste udelukkende *inden* produktion.
Vi har debatteret det paa IRC og jeg gider ikke fortsaette en quote-war her ;)
Det kniber åbenbart med forståelsen her også. Der er vist ingen grund til at gentage rettelsen af din misforståelse igen igen.
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