Tietos datahaveri, vad händer

[Nitrometan]

Bilprovningen och Apoteket har varit utslagna i ett par dagar.

Tydligen är det deras leverantör Tieto som har problem. Det började i helgen och ryktas om ett hårdvarufel.

http://www.nyteknik.se/nyheter/it_telekom/allmant/article3355166.ece

Fler kan vara drabbade.

Govdata.se har en lista över de myndigheter som har Tieto som leverantör.
Tieto Sweden AB:
Arbetsmarknadsverket

Banverket

Ekonomistyrningsverket

Försvarsmakten

Göteborgs universitet

Karolinska institutet

Kriminalvården

Luleå tekniska universitet

Myndigheten för samhällsskydd och beredskap

Polisorganisationen

Post- och telestyrelsen

Tietoenator technology AB:

Kriminalvården

Linköpings universitet

Tietoenator Tech AB:

Försvarets materielverk

Försvarsmakten

Skatteverket

Totalförsvarets forskningsinstitut

Tietoenator Telecom & Media AB:

Arbetsmiljöverket

Centrala studiestödsnämnden

Kungliga tekniska högskolan

Lantmäteriverket

Linköpings universitet

Lunds universitet

Naturvårdsverket

Regeringskansliet

Riksförsäkringsverket

SMHI

Skatteverket

Tietoenator R&D Services AB:

Banverket

Försvarets materielverk

Försvarsmakten

Karlstads universitet

Luftfartsverket, affärsverk

Luleå tekniska universitet

Polisorganisationen

SMHI

Skatteverket

Statistiska centralbyrån

Totalförsvarets forskningsinstitut

Tietoenator Trigon AB:

Arbetsmarknadsverket

Luleå tekniska universitet

Länsstyrelsen i Skåne län

Tietoenator GM & R AB

Försvarsmakten

Högskolan i Kalmar

Karlstads universitet

Karolinska institutet

Lunds universitet

Malmö Högskola

Socialstyrelsen

Tietoenator Forest & Energy:

Arbetsmarknadsverket

Banverket

Ekonomistyrningsverket

Försvarsmakten

Försäkringskassan

Högskolan i Gävle

Kriminalvården

Linköpings universitet

Luftfartsverket, affärsverk

Lunds universitet

Lärarhögskolan i Stockholm

Svenska Kraftnät

SMHI

Tieto Sweden Healthcare & Welfare:

Centrala studiestödsnämnden

Försvarsmakten

Göteborgs universitet

Karlstads universitet

Karolinska institutet

Kriminalvården

Luftfartsverket, affärsverk

Luleå tekniska universitet

Lunds universitet

Malmö Högskola

Stockholms universitet

Tietoenator Media Systems AB:

Linköpings universitet

Lunds universitet

Regeringskansliet

Totalförsvarets forskningsinstitut

Sen finns det säkert ett antal företag också. Jag vet inte om nån av dem är drabbade av stoppet. Av naturliga skäl vill de inte skylta med det.

Hörde att Nacka kommun hade blivit av med mail och intranät.


Det skrivs inte så mycket om det, men när de har kommit igång så kanske det kommer nån artikel.

[Nitrometan]

Här är ett pressmeddelande från Tieto:
http://www.tieto.se/archive/news/2011/29227

TIETO ABP MEDDELANDE 29 november 2011 KL 8.15

Fredagen den 25 november inträffade ett allvarligt hårdvarufel i ett av Tietos svenska datacenter. Som följd har delar av produktionsverksamheten driftstörningar. Arbetet med att återställa tjänsterna hos berörda kunder fortgår tillsammans med bolagets underleverantörer. Vår bedömning är att det är svårt att förutse när samtliga tjänster är helt återställda. Återställningsarbetet är tidskrävande och tjänsterna kommer tillbaka successivt. Totalt påverkas cirka femtio kunder av dessa driftstörningar. Effekterna varierar beroende på kund.

- Vi ser mycket allvarligt på situationen och arbetar tillsammans med våra underleverantörer med högsta prioritet för att minimera effekterna av dessa driftstörningar hos våra kunder, säger Mikael Jupiter, driftansvarig, Tieto Sweden.

Så... De säger att 50 kunder är drabbade.

[kaer]

Verkar ju vara en gigantisk fuck up, minst sagt.
Känns lite som att det är en hund begraven här, tycker inte tietos förklaringar är särskilt uttömmande med tanke på hur lång tid det tar att fixa.

[shut teh face]

Verkar rätt kassa, ett företag i den storleken borde ha ordnat förutsättningar att sådant här inte kan hända genom redundans och recoverylösningar...

[hahavaffan]

Jag och tjejen upptäckte att apoteket.se gick ner i samband med att stormen drog in över landet. Först möttes vi av en SQL-felsida, och sen dog domänen helt. Trodde lätt det var nåt nödkraftverk som inte startat som det skulle, men om det är kopplat till Tietos ganska feta fail så är det nog allvarligare :D


Etta inte vara driftsansvarig där nu.

[martikainen]

Frågan är ju vad fasiken som rasat, är det ett SAN-skåp eller någon core-switch som ballat ur?

Finns ju inte mycket annat som kan rasa för att det skall drabba så många kunder samtidigt, och SAN/core switchar är ju oftast utrustning som delas mellan kunder.

Edit: verkar vara SAN'et japp, och även speglingen av SAN'et, NICE! .. http://www.idg.se/2.1085/1.418561/disk-problem-bakom-tieto-haveri

[Sparven från Minsk]

Skynet!

[hurril]

Gud har ett finger med i spelet!

[gatewarden]

Frågan är ju vad fasiken som rasat, är det ett SAN-skåp eller någon core-switch som ballat ur?

Finns ju inte mycket annat som kan rasa för att det skall drabba så många kunder samtidigt, och SAN/core switchar är ju oftast utrustning som delas mellan kunder.

Edit: verkar vara diskar .. http://www.idg.se/2.1085/1.418561/disk-problem-bakom-tieto-haveri

Om ett sanskåp eller en coreswitch rasar och man inte löser det på ett par timmar kanske man skall fundera över saker och ting.

Känns som det är något betydligt mer omfattande och att dom mörkar något.

Tieto har aldrig varit eller seriöst bolag med stor tillit och kommer aldrig bli det, med tanke på att dom är rätt billiga jämnfört med många andra större driftbolag så måste jag bara säga "Man får vad man betalar för"

[shut teh face]

Det luktar ju att någon klant har fuckat upp rejält, SAN-skåpen verkar ju ha varit speglade som förväntat och och det är inte troligt att de har problem på båda sidor samtidigt.

Oftast så är det ju dessutom speglat i SAN-skåpen i sig själva, och sedan speglat till olika skåp på operativnivå också.

[martikainen]

Om ett sanskåp eller en coreswitch rasar och man inte löser det på ett par timmar kanske man skall fundera över saker och ting.

Känns som det är något betydligt mer omfattande och att dom mörkar något.

Tieto har aldrig varit eller seriöst bolag med stor tillit och kommer aldrig bli det, med tanke på att dom är rätt billiga jämnfört med många andra större driftbolag så måste jag bara säga "Man får vad man betalar för"

Nu är det ju bekräftat att det är SANet som är problemet, men jag är ändå intresserad av vad du tror skulle vara orsaken om inte något så grundläggande i en plattform som nät eller disk, (eller elförsörjning)
Om 50kunder är drabbade samtidigt, eller ens 3-4 olika så sätter jag alltid mina pengar på nät/disk, och har ännu inte haft fel, det är ju väldigt sällan som tex 10 vmware hostar får för sig att balla ur, om de inte tappat nät/disk, alternativt ström, men då hade det nog kommit ut direkt att det är elfel.

[Ronn]

Nu är det ju så att just SAN t.ex. så är man rätt beroende av leverantören ifall det är allvarliga hårdvarufel, nu är det tieto som får bära hästhuvudet utåt men det är ju ändå EMC (eller eventuellt mellanleverantör) som egentligen bär ansvaret antagligen kopplat till penalties beroende på hur avtal ser ut.

Vad tieto skulle kunna göra för att förebygga är att ha redundanta SAN osv det går ju teorisera hur mycket som helst men ingen skulle betala för det.

[gatewarden]

Nu är det ju bekräftat att det är SANet som är problemet, men jag är ändå intresserad av vad du tror skulle vara orsaken om inte något så grundläggande i en plattform som nät eller disk, (eller elförsörjning)
Om 50kunder är drabbade samtidigt, eller ens 3-4 olika så sätter jag alltid mina pengar på nät/disk, och har ännu inte haft fel, det är ju väldigt sällan som tex 10 vmware hostar får för sig att balla ur, om de inte tappat nät/disk, alternativt ström, men då hade det nog kommit ut direkt att det är elfel.

Ok, om det är SANet som är problemet så kan man fråga sig hur dom har satt upp det, spegling till andra datahaller? Vad finns det för redudans bakom SANet? Om det skulle gå i två datorhallar på bolaget jag jobbar på blir ingen drabbad.

Handlar det om nät så skall det också finnas redundans så att om en coreswitch går sönder skall man fortfarande överleva.

Jag är ganska överraskad över denna problematiken, om en VMWarehost går ner så flyttar man dom virtuella hostarna till en annan server, svårare så är det sällan.

[Ronn]

Men om du köper coreswitchar eller SAN som en tjänst från externa leverantörer och dom garanterar att det inte finns några flaskhalsar vem bär skulden? Tänk utanför boxen dom flesta stora företag har någon form av leverantörsberoende för delar av sin kompetens. Sen kan det vara ett rent designfel i produkten som uppdagas det vet vi ju inte, jag tvivlar på att man sett detta som en accepterad risk hos tieto, både slutleverantör och underleverantör kommer ju potentiellt få dras med ett dåligt rykte beroende på vad felet bottnar i.

Dom enda som brukar klara sig från sånna här haverier är ju dom riktigt stora globala företagen som har råd att spegla data på flera geografiska lokationer och på så vis kan tappa en lokation med viss prestandaförlust men dom har ju också en verksamhet där det är gynnsamt att sprida ut sig geografiskt, t.ex. google, facebook mfl.

[martikainen]

Ok, om det är SANet som är problemet så kan man fråga sig hur dom har satt upp det, spegling till andra datahaller? Vad finns det för redudans bakom SANet? Om det skulle gå i två datorhallar på bolaget jag jobbar på blir ingen drabbad.

Handlar det om nät så skall det också finnas redundans så att om en coreswitch går sönder skall man fortfarande överleva.

Jag är ganska överraskad över denna problematiken, om en VMWarehost går ner så flyttar man dom virtuella hostarna till en annan server, svårare så är det sällan.

Men om du köper coreswitchar eller SAN som en tjänst från externa leverantörer och dom garanterar att det inte finns några flaskhalsar vem bär skulden? Tänk utanför boxen dom flesta stora företag har någon form av leverantörsberoende för delar av sin kompetens. Sen kan det vara ett rent designfel i produkten som uppdagas det vet vi ju inte, jag tvivlar på att man sett detta som en accepterad risk hos tieto, både slutleverantör och underleverantör kommer ju potentiellt få dras med ett dåligt rykte beroende på vad felet bottnar i.

Dom enda som brukar klara sig från sånna här haverier är ju dom riktigt stora globala företagen som har råd att spegla data på flera geografiska lokationer och på så vis kan tappa en lokation med viss prestandaförlust men dom har ju också en verksamhet där det är gynnsamt att sprida ut sig geografiskt, t.ex. google, facebook mfl.


Precis, detta felet ska egentligen inte kunna hända, men jag kan lova att majoriteten av driftleverantörer väldigt sällan kör tester om deras redundans/backups egentligen fungerar.
Vissa kunder kräver ju restoretester med jämna mellanrum, på X antal maskiner/data/funktioner, medans andra inte har något specifika krav.
Men hur ofta testar man redundansen på ett SAN eller switchar? Det görs förmodligen i implementationen men det finns aldrig något fönster att testa det när det väl är i produktion

Jag vill se koordinationen att få ett servicefönster på ett gemensamt SAN för 50 kunder, chansen att de kunderna inte har någon viktig körning just då är ju minimal.

[Trance]

Verkar rätt kassa, ett företag i den storleken borde ha ordnat förutsättningar att sådant här inte kan hända genom redundans och recoverylösningar...

Det kan hända alla med lite otur. Amazon har haft liknande stora avbrott och de är hyfsat duktiga på detta.

[gatewarden]

Precis, detta felet ska egentligen inte kunna hända, men jag kan lova att majoriteten av driftleverantörer väldigt sällan kör tester om deras redundans/backups egentligen fungerar.
Vissa kunder kräver ju restoretester med jämna mellanrum, på X antal maskiner/data/funktioner, medans andra inte har något specifika krav.
Men hur ofta testar man redundansen på ett SAN eller switchar? Det görs förmodligen i implementationen men det finns aldrig något fönster att testa det när det väl är i produktion

Jag vill se koordinationen att få ett servicefönster på ett gemensamt SAN för 50 kunder, chansen att de kunderna inte har någon viktig körning just då är ju minimal.

Disaster Recovery, något jag tror fler och fler inte göra i den omfattningen som börs. På ett av mina äldre jobb körde vi övningar relativt ofta, vad händer om byggnaden brinner ner, systemen dyker osv osv. Kunderna fick ofta vara med och filma osv.

Kör det för en del av mina kunder idag också, då baserat på att servrarna med systemen dyker, hur snabbt får vi upp det på andra servrar etc, hur lång tid tar det att återställa alla databaser osv osv.

SLAerna som är knutna till kunden avgör också på vilken nivå man får lägga allt. Dom kunderna som köper 9x5 behöver nödvändigtvis inte ha samma typ av disaster recovery.

Ett företag som tieto bör ju ha ganska många datorhallar där dom kan spegla sin miljö. Frågan är dock som sagt hur den ser ut och vet dom hur man gör en disaster recovery på ett bra sätt? Detta bör tom vara med i Governancepolicyn enligt dom riktlinjer som finns idag.

[Exdiaq]

Ryssen..

[Ronn]

Fast dom flesta DR tester är nog på rätt hög nivå, man testar scenarion som man har erfarenhet av sen tidigare i princip, kopplingen mellan två hallar går ner, strömmen i en hall går ner osv, sen hur ofta testar man t.ex. att korruption i datat uppstår hur testar man ens det? Kan ju vara många gånger värre än ett hårdarufel då ska man upptäcka korruptionen, spåra den till sitt ursprung för att veta när man kan återställa ifrån sen kan ju viktigt data från den tidpunkten vara helt förlorat hur skyddar man sig mot det?

Det är nog väldigt svårt att bygga bort alla tänkbara katastrofscenarion man kan bara förbereda sig så gott det går efter dom ekonomiska förutsättningar man har.

DÄREMOT så tycker jag detta visar lite på faran med trenden att så många blir mer och mer beroende av ett fåtal leverantörer, apoteket osv har ju valt att outsourca till en leverantör för att slippa ta driften själv, men smäller det hos leverantören så får det gigantisk påverkan i samhället/hos slutkunderna.

[gatewarden]

Fast dom flesta DR tester är nog på rätt hög nivå, man testar scenarion som man har erfarenhet av sen tidigare i princip, kopplingen mellan två hallar går ner, strömmen i en hall går ner osv, sen hur ofta testar man t.ex. att korruption i datat uppstår hur testar man ens det? Kan ju vara många gånger värre än ett hårdarufel då ska man upptäcka korruptionen, spåra den till sitt ursprung för att veta när man kan återställa ifrån sen kan ju viktigt data från den tidpunkten vara helt förlorat hur skyddar man sig mot det?

Det är nog väldigt svårt att bygga bort alla tänkbara katastrofscenarion man kan bara förbereda sig så gott det går efter dom ekonomiska förutsättningar man har.

DÄREMOT så tycker jag detta visar lite på faran med trenden att så många blir mer och mer beroende av ett fåtal leverantörer, apoteket osv har ju valt att outsourca till en leverantör för att slippa ta driften själv, men smäller det hos leverantören så får det gigantisk påverkan i samhället/hos slutkunderna.

Nej, man kan inte köra DR på allt. Men san är en av dom viktigaste knytpunkterna till allt. Att inte ha en redudans och en plan på om det smäller är förfärligt.

Är man dessutom leverantör till så många kunder så att om det blir problem med sanet så dör det för 50 kunder bör man verkligen ha koll på läget.

Som sagt skulle jag vilja sen slutrapport på exakt vad et är som har hänt och hur dom jobbat för att lösa problematiken.

[shut teh face]

Det kan hända alla med lite otur. Amazon har haft liknande stora avbrott och de är hyfsat duktiga på detta.
Amazon kör ju mongodb och cassandra där huvudsyftet är lokala billiga diskar och extremt flexibelt system där det inte gör något ifall ett par maskiner dyker eller liknande. Men det är klart, det kan hända alla, vad som helst.

Här har vi dubbelt av allting, det finns ingenting som kan dyka och det inte finns reserver, men det här med att speglat SAN också förstörs verkar konstigt och allvarligt, jag vill gärna veta mer om detta.

[Snobbe]

Ja jag undrar vad som hänt.... ett SAN med redundans dör bara inte....?

Har sett liknande fel när någon fuckat upp en patch på ett SAN men då gick det inte ner i flera dagar.

[shut teh face]

Jag är fortfarande inne på någon human error grej. Det är lätt att förstöra saker från diverse admin tool vilket brukar vara populärt att administrera i, speciellt HP.

:D

[Nitrometan]

Det skulle kunna vara ett admin-fel. Det skulle ju kunna vara så illa att hårdvara går sönder på två ställen samtidigt också.

Sen vet jag att Tieto var ute och sökte admin-personal för 300 kr/h och inte var intresserade av andra bud. För det priset kanske man inte får de bästa.

Eva Gidlöf, Sverigechef på Tieto, säger att det kanske inte blir nån ersättning till de drabbade.

http://www.idg.se/2.1085/1.419027/tieto-garanterar-inte-ersattning

Fast om de har köpt ett SLA med 24/7 garanterad upptid så borde det kunna bli lite ersättning, men enligt vissa rykten så har en del kunder tyckt att det var ett dyrt avtal och köpt 9/5 istället. Och slår man ut driftstimmarna över året så kanske de klarar sig utan att betala ersättning.

Kan du lova kunder kompensation?
– Våra avtal med kunderna reglerar noggrant vad som händer i sådana här situationer.

Är du orolig för Tietos rykte efter det här?
– Jag funderar inte på sådana saker just nu. Just nu vill jag vill lösa problemet. Om vi löser det på ett bra sätt tillsammans med kunderna kan det stärka relationerna, säger Eva Gidlöf.

– Avbrottet i sig är allvarligt men utifrån det här får vi en ännu starkare dialog med våra kunder.

Vad får de drabbade kunderna för kompensation?
– Vi får diskutera om det över huvud taget blir aktuellt. Vi har kommersiella avtal och dem kommenterar jag inte. Kunderna är olika stora och de tekniska lösningarna är olika.


Om vad som är problemet:
När vet ni vad som orsakade problemet?
– Vi fokuserar på att få igång kundernas applikationer. Parallellt med det utreder vi orsaken, men det är inte fokus just nu.

Hon vill inte kommentera hur Tieto arbetar internt med att lösa problemet.
– Eftersom det är en krisorganisation vill jag inte beskriva det.

[shut teh face]

Verkar riktigt konstigt med företag/myndigheter som inte "köpt" 24/7 SLA om deras verksamhet är beroende av dessa IT-funktioner för att tjäna pengar eller utföra sina core-verksamhet.

Oavsett vad så verkar ju alla ha blivit drabbade.

Också konstigt att inte betala ersättning till de med 24/7 SLA, men det kanske jag missuppfattar i artikeln.

Om vi frångår vårt 99,8% SLA så blir det hus i helvetet och då har vi ändå bara "interna" kunder.

[Nitrometan]

Fast det beror ju på hur avtalen är skrivna, det kanske finns undantag då ersättning inte betalas ut. T.ex. då hårdvara som Tieto köpt in med vissa garantier slutar fungera... Vad vet jag?

[krappen]

Jag tror att det är fel på SAN'et.







:naughty:

[shut teh face]

Fast det beror ju på hur avtalen är skrivna, det kanske finns undantag då ersättning inte betalas ut. T.ex. då hårdvara som Tieto köpt in med vissa garantier slutar fungera... Vad vet jag?
Kanske, men tieto har ju tagit ansvar för en funktionalitet, det är deras problem att se till att de köper rätt saker och från rätt leverantörer. Sedan har underleverantörerna också ett visst ansvar, kanske mer. Men oavsett vad så är det dåligt för tieto och de kan förlora kunder.

Vi har haft en del problem på grund av sådant som vi kanske inte råder över och är mer leverantörernas problem, och det enda man har skrivet med dem är ju att de ska hjälpa till eller har en viss tid på sig att lösa problemen. Om vi ponerar att problemet med SAN-skåpen är en bugg, då kanske leverantören ordnat detta relativt fort, men sen är det ju tietos "problem" att det är så stora mängder data eller att de har dåliga rutiner för att läsa tillbaka tvivelaktigt data, verifiering osv.

Det är mycket gråzoner. :)

Sen ser jag mycket problem där ute hos "kostnadseffektiva" företag/leverantörer där man konsoliderar ihop olika kunder på detta sätt. Inte ens vi som är ett företag konsoliderar våra egna saker på det sättet. Vi har egna SAN-skåp för egna system, visst det kostar ju och vi har förmodligen för mycket pengar men dessa pengar förlorar man ju ändå på en dags nertid.

[Nitrometan]

Om vi ponerar att problemet med SAN-skåpen är en bugg, då kanske leverantören ordnat detta relativt fort, men sen är det ju tietos "problem" att det är så stora mängder data eller att de har dåliga rutiner för att läsa tillbaka tvivelaktigt data, verifiering osv.
Japp. Visst kan det vara så.

Det är mycket gråzoner. :)
Japp. Gråa zoner...

Sen ser jag mycket problem där ute hos "kostnadseffektiva" företag/leverantörer där man konsoliderar ihop olika kunder på detta sätt. Inte ens vi som är ett företag konsoliderar våra egna saker på det sättet.
Japp. Tieto tyckte säkert att det var en bra idé att trycka in många kunder i samma skåp.

Lycka till säger jag. Förra året var det väl Logica som inte kunde drifta?

[Snobbe]

Vad tror ni kommer hända med tieto efter detta?:) Alla dessa kunder som legat nere sen i fredags lär ju inte stanna kvar iaf?

[martikainen]

Vad tror ni kommer hända med tieto efter detta?:) Alla dessa kunder som legat nere sen i fredags lär ju inte stanna kvar iaf?

Det är inte riktigt så enkelt som att bara byta leverantör, en upphandling och även transitionsprojekt kostar stålar.

[Snobbe]

Det är inte riktigt så enkelt som att bara byta leverantör, en upphandling och även transitionsprojekt kostar stålar.

Självklart vet jag det... Men vem vill va kvar med en leverantör som har gjort sitt system värdelöst i 5dar?

[martikainen]

Självklart vet jag det... Men vem vill va kvar med en leverantör som har gjort sitt system värdelöst i 5dar?

vem säger att kostaden av de 5 dagarna inte understiger kostnaden av att byta till den leverantör som kan garantera några få procentenheter mer i uptid av systemen?

[shut teh face]

Eftersom det är mycket myndigheter som det handlar om så följer de väl LOU och kan inte byta hur som helst. Troligtvis så blir det massa incidentmöten där man kräver ersättning och garantier på att det ej händer igen, kanske i form av separerade SAN-skåp eller liknande. ;)

[Snobbe]

vem säger att kostaden av de 5 dagarna inte understiger kostnaden av att byta till den leverantör som kan garantera några få procentenheter mer i uptid av systemen?

Fast vem vill va hos en leverantör där det faktiskt hänt att ett system varit nere i 5dagar? Även fast kostnaden blir lite mer att byta...

[hahavaffan]

Fast vem vill va hos en leverantör där det faktiskt hänt att ett system varit nere i 5dagar? Även fast kostnaden blir lite mer att byta...Blixten slår aldrig ner på samma ställe två gånger, osv. et al. Om kostnaden för att byta är högre, lär det inte finnas många ledningar i världen som väljer det.

Sen är kostnaden av att byta leverantör/system inte enbart ekonomisk. Det är inget man gör om man inte mååå-hååste.

[forslund]

Tieto har haft hårdvarufel i en kapacitetstjänst-plattform i en av våra centrala anläggningar i Sverige. I fredags kväll, den 25 november, drabbades vi ett dubbelt diskproblem i en så kallad FAST cache, vilket har slagit ut ett disksystem som många funktioner är beroende av.

http://www.idg.se/2.1085/1.418561/disk-problem-bakom-tieto-haveri

[hahavaffan]

Så långt avbrott, på grund av att en jävla prestandafunktion går ner?

[Nitrometan]

Nu är de uppe och springer igen. Alla är nöjda och glada. :)

SBAB -
http://www.idg.se/2.1085/1.419148/aven-sbab-pa-vag-upp

– Nu har Tieto lyckats starta om våra servrar och de har fått igång bolånesidan, Bo Andersson, cio på SBAB.
http://www.idg.se/polopoly_fs/1.419148.1322655801!imageUploader/3909444200.jpgBo på bild.

Apoteket -
http://www.idg.se/2.1085/1.419103/apotekets-e-recept-igang-igen

Onsdagen markerar den sjätte dagen av Tietos allvarliga driftstörningar. Under natten fick Apoteket AB och Tieto på plats en lösning som gör att alla kunder från och med i dag kan hämta ut sina e-recept.

– Det har fungerat över natten och enligt det senaste sms:et jag fick för tio minuter sedan fungerar det, säger Eva Fernvall, varumärkesdirektör på Apoteket AB.

Alla tekniska problem är dock inte lösta. Apoteket AB har fortfarande några bakomliggande system som ligger nere, men enligt Eva Fernvall ska det inte påverka kunderna.

Tieto är sedan 2007 Apotekets huvudleverantör av it-tjänster. Samarbetet har därefter utvidgats. Så sent som i september tog Tieto hem uppdraget att införa och drifta en butikslösning i 350 butiker. Eva Fernvall vill i nuläget inte kommentera avtalens längd eller eventuella förlängning.
Man får hoppas att den delen av Tieto lyckas bättre.

Men helt klart är det inte med "kraschen":
Tieto meddelar på onsdagsmorgonen att driftproblemen är långt från lösta. Enligt företaget är det fortfarande svårt att säga när kapacitetstjänsteplattformen är tillbaka i normal drift.

På Tietos egen sida har de inte uppdaterat meddelandet sen igår.

[Nitrometan]

Hmmm.

http://www.emc.com/about/glossary/fast-cache.htm

FAST cache accelerates performance to address unexpected workload spikes. FAST and FAST cache are a powerful combination, unmatched in the industry, that provides optimal performance at the lowest possible cost.

http://www.emc.com/about/glossary/fast.htm

FAST makes a storage system both faster and lower-cost at the same time, because it only uses high-performance tiers when needed, and uses low cost/high capacity tiers when possible. Policies provide control for how performance and cost are optimized, and the automation of FAST means the storage system has no added management burden compared to slower, more costly systems.

Nån sa att det var här problemet låg och att det var svårt att återställa den data som hade förlorats från "cache-disken".

[shut teh face]

Ska nedtiden ha handlat om att man inte velat tappa transaktioner kanske. Kan dock inte tänka mig att dessa myndigheter skulle låtit skiten ligga nere 1 vecka för att Tieto ska kunna garantera att alla transaktioner återställs.

Om det hade varit en bank hade man förstått det, eller spelbolag ;)

[Nitrometan]

Bilprovningen ännu inte uppe. Igår kom Nacka kommun tillbaka i drift.

http://www.nyteknik.se/nyheter/it_telekom/allmant/article3358355.ece

Benny Örnefors, Bilprovningens it-chef är väldigt fundersam över vad som hänt men anser att det är för tidigt att spekulerar i orsaken.

- Även om vi fått en ytlig och populär beskrivning av det hela, säger Benny Örnefors till idg.se.

Hans förtroende är inte på topp men Benny Örnefors vill inte göra sin bedömning innan alla fakta finns på bordet.

- Som jag säger, det är klart att vi är fundersamma på hur det kan hända som inte ska kunna hända. Sen vill jag vänta tills jag hör analysen av det hela innan jag dömer ut någon, säger Benny Örnefors till idg.se.

Tieto arbetar tillsammans med sina leverantörer för att ta reda på vad som orsakade hårdvarukraschen. Dessutom arbetar man med att säkerställa att någon liknande situation inte ska kunna ske igen, enligt Mikael Jupiter, driftchef, Tieto Sweden.

Från Tieto:
Tieto har sedan kvällen den 25 november en allvarlig driftstörning som berör omkring 50 kunder. Effekterna varierar från kund till kund. Flera tjänster är tillbaka i normal drift men fortfarande återstår arbete innan samtliga tjänster är återställda.

-Tjänsterna har successivt börjat återställas, men det är fortfarande svårt att bedöma när samtliga är tillbaka. Vi arbetar med högsta prioritet tillsammans med våra leverantörer och teknikpartners för att nå normal drift, säger Mikael Jupiter, driftchef, Tieto Sweden.

Tieto använder ledande säkerhetslösningar som följer branschstandard och mer än väl möter kundernas krav. Det hårdvarufel och de problem som felet orsakat har varit svårt att förutse, både för Tieto och teknikpartners. Det är en exceptionell händelsekedja som lett till en process där felkorrigering, återställning och validering av data är mycket komplext och tidsödande.

-Samtidigt med återställningen av driften arbetar vi tillsammans med våra leverantörer för att fastställa de underliggande orsakerna till det hårdvarufel som orsakat driftstörningen. Detta för att säkerställa att liknande fel inte kan uppstå igen, säger Mikael Jupiter.

Det ska bli intressant när vi kan få höra mer.

[Nitrometan]

Sollentuna kommun med bl.a. skoldatorer är fortfarande nere.

http://www.idg.se/2.1085/1.419367/tietokrisen-slar-mot-skolorna

Sedan i fredags kan Sollentuna kommun inte arbeta som vanligt. Tietos allvarliga driftproblem gjorde att kommunens it-system slogs ut. Men att det skulle dröja så här länge innan en lösning förvånar Sollentuna kommuns cio Britta Sandblom:

– I helgen tänkte man att Tieto ju har hela helgen på sig att lösa problemet, säger hon.

När problemet fortfarande inte var löst på söndagen ringde kommunens it-ansvariga runt till Sollentunas alla rektorer för att förvarna att skolorna kunde drabbas hårt av Tietos haveri. Det gällde speciellt grundskolan, med 9 000 elever i kommunen.

– Skolorna har varit helt utslagna. De har inte kommit åt e-post eller Google Apps, de har inte kunnat göra vare sig prov eller läxor och skolorna har fått improvisera.

På måndagen aktiverades kommunens krisledning och Sollentuna kommun pekade om skolornas webbaserade system till en alternativ server, för att ge Tieto tid att lösa problemet. Kommunen ringde så snabbt de kunde till de personer som får ekonomiskt försörjningsstöd så att de inte skulle bli utan pengar.

Att ett drifthaveri ska hålla i sig i mer än 100 timmar är enligt Sollentunas cio helt ofattbart.

– Det finns ingenting motsvarande i historien, söger Britta Sandblom.

För de mest kritiska systemen har Sollentuna kommun avtal med Tieto om en upptid på 99,8 procent.

– Den nivån är passerad för länge sedan.

Britta Sandblom räknar med att det ska bli lätt att få ersättning av Tieto.

– Det är självklart att om Tieto ska behålla sina kunder ska man inte behöva kämpa för en ersättning. På det området räknar vi med ett samarbete.

Intressant.

[shut teh face]

Som sagt, idioti och noobness på Tieto när det gäller design av SAN-skåpen.

[forslund]

Vad var det som var dåligt och hur skulle man designa det istället menar du?
Jag kan inte mycket om storage.

[Snobbe]

Vad var det som var dåligt och hur skulle man designa det istället menar du?
Jag kan inte mycket om storage.

Nu tror jag inte shut the face vet exakt hur deras SAN är designat. Men om det går ner i en vecka och problemet fortfarande inte är löst så är det antagligen dåligt designat:)

[dupper]

Vad var det som var dåligt och hur skulle man designa det istället menar du?
Jag kan inte mycket om storage.

Om man skriver avtal på att hålla 99,8% uptime, och sen inte klarar av att hålla det pga interna fel så har man ju ett stort problem.

[forslund]

Om man skriver avtal på att hålla 99,8% uptime, och sen inte klarar av att hålla det pga interna fel så har man ju ett stort problem.

Ja, men det var inte det jag frågade efter.

[Ronn]

Om man skriver avtal på att hålla 99,8% uptime, och sen inte klarar av att hålla det pga interna fel så har man ju ett stort problem.

Nja uptime är ju ett riktmärke man ska förhålla sig, är kunden smart har dom bakat in straffavgifter om man går under det och är leverantören riktigt dålig så kanske dom tappar avtalet i nästa omförhandling, vissa avtal ger kunden rätt att byta leverantör rätt omgående men det är kostsamt.

Dom flesta kund/leverantörs förhållanden försöker nog förbättra tjänsten en eller ett par gånger innan man tröttnar och bryter med varandra.

[Snobbe]

Nja uptime är ju ett riktmärke man ska förhålla sig, är kunden smart har dom bakat in straffavgifter om man går under det och är leverantören riktigt dålig så kanske dom tappar avtalet i nästa omförhandling, vissa avtal ger kunden rätt att byta leverantör rätt omgående men det är kostsamt.

Dom flesta kund/leverantörs förhållanden försöker nog förbättra tjänsten en eller ett par gånger innan man tröttnar och bryter med varandra.

Uptime är inte ett riktmärke.... 99.8% är SLA avtalet. Går du under det så i dom flesta företagen så får hosting företaget böta (oftast så dom får lägre fakturor nästa månad t.ex.)

[Ronn]

Var ju exakt det jag skrev?

[dupper]

Nja uptime är ju ett riktmärke man ska förhålla sig, är kunden smart har dom bakat in straffavgifter om man går under det och är leverantören riktigt dålig så kanske dom tappar avtalet i nästa omförhandling, vissa avtal ger kunden rätt att byta leverantör rätt omgående men det är kostsamt.

Dom flesta kund/leverantörs förhållanden försöker nog förbättra tjänsten en eller ett par gånger innan man tröttnar och bryter med varandra.

Jo precis, vi snackar ju inte byta skor liksom. Men det är rätt tungt att teckna avtal på att hålla 99.8% uptime; det borde Tieto ha vägt mot "worst case scenario" kan man tänka sig, och ändå känt sig säkra nog på att ha siffran så högt.

[Ronn]

Det är typ standard idag sen tecknar man avtal för 24/7, 8-18 osv beroende på vad man har för affärsverksamhet, procenten går direkt att översätta till timmar och ofta är det ännu mer detaljerat i avtalen t.ex. max så här många timmar på en period, max så här länge per avbrott, max så här många avbrott totalt på en period.

Vad SLA sen egentligen reglerar är kraven på bakomliggande infrastruktur, resurser i beredskap osv men det är ju ingen exakt vetenskap, mycket estimeringar förhoppningsvis baserat på erfarenhet. ;)

Det är rätt komplicerat speciellt när man har underleverantörer med i bilden men man gör det gärna enkelt för sig när man köper/säljer av förståliga skäl sen blir det alltid en diskussion av det när nått går fel.

[shut teh face]

Vad var det som var dåligt och hur skulle man designa det istället menar du?
Jag kan inte mycket om storage.
Som jag skrivit tidigare i tråden, att de designat dåligt är självklart. Kanske inte medvetet, men försökt vara kostnadseffektiva.

De har lagt alla ägg i samma korg, samma SAN-skåp för alla kunder. Vilket inte är särskilt smart.

Men det är knappast teknikernas fel, de har säkert påpekat detta och begärt mer saker för att upprätthålla de SLA'er som alla kunder köpt. Nån chef som vill spara pengar eller inte förstår. De brukar ofta resonera "det fungerar ju", "vad är oddsen att det händer", "ska vi verkligen betala 10 miljoner extra per år för att skydda oss mot så osannolika saker". Jo, så är det. Men dessa pengar förlorar man väldigt fort när det väl går åt skogen, vilket alltid är en risk och man kan inte skydda sig mot allting med kompetens eller underhåll av system, thing is what it is.

[Ronn]

Ja det är en rimlig chans att du har helt rätt där.

[shut teh face]

Det är typ standard idag sen tecknar man avtal för 24/7, 8-18 osv beroende på vad man har för affärsverksamhet, procenten går direkt att översätta till timmar och ofta är det ännu mer detaljerat i avtalen t.ex. max så här många timmar på en period, max så här länge per avbrott, max så här många avbrott totalt på en period.

Vad SLA sen egentligen reglerar är kraven på bakomliggande infrastruktur, resurser i beredskap osv men det är ju ingen exakt vetenskap, mycket estimeringar förhoppningsvis baserat på erfarenhet. ;)

Det är rätt komplicerat speciellt när man har underleverantörer med i bilden men man gör det gärna enkelt för sig när man köper/säljer av förståliga skäl sen blir det alltid en diskussion av det när nått går fel.
Jag använder personligen SLA som incitament för att få saker och ting. Jag kan förstå företag där SLA/OLA inte existerar, att man famlar i mörkret och sånt här händer, men jag tror ej Tieto är på den nivån.

Men om jag framför mig har ett SLA som säger 99,8%, då vet man som tekniker vad som krävs för detta, ofta är det väldigt dyrt, sen är det upp till högre stående varelser att ta beslut om man kan få köpa det eller ej, och ofta ofta ofta får man inte det. Problemet är främst att det kostar så sjukt mycket pengar för varje promille på de högre nivåerna av upptid.

Till slut kommer man till den nivån där det är bättre att det finns en risk att skiten får gå ned, och sen betalar man böter. :) Och 100% kan man ju aldrig få heller. Nu säger jag dock inte att det är fallet här med Tieto, att ha samma kunder i SAN-skåp är i nivå med kontorstider på systement samt testmiljöer, ej skarpt.

[Nitrometan]

Nu skyller de på EMC.

http://www.idg.se/2.1085/1.419514/tietohaveriet-pinsamt-for-emc

Nu håller IDG ungefär samma trovärdighets-/sannings-/faktanivå som AB men ändå...

Tietos stora datahaveri bottnar i en misslyckad uppgradering av lagringsutrustning från EMC. Bara två dagar före haveriet presenterade EMC en rapport om vikten av katastrofskydd.

EMC säger "vi sa ju att ni skulle skydda er!" :)

Under året har Tieto genomfört flera stora uppgraderingar i sina lagringsservrar. Under EMC Forum i november framkom att Tieto skulle uppgradera till en utrustning med namnet VNX NS480 för att kunna utnyttja en teknik kallad fast cache.

Enligt välunderrättade källor är det den uppgraderingen som fallerat.

– Fast cache innebär att man kan utnyttja stora pooler av resurser fördelade på många diskar där systemet automatiskt flyttar data i olika nivåer. Om systemet blir korrupt blir det oerhört svårt att få grepp om var de enskilda filerna tagit vägen, säger en av de lagringsexperter CS talat med.

Det låter nästan för komplext för att vara bra.

Företrädare för Tieto bekräftar att haveriet beror på ett hårdvarufel i lagringsenheterna men vägrar att tala om vilka produkter det handlar om. Mikael Jupiter, vice vd med ansvar för it-drift på Tieto, säger att han inte vill ge några kommentarer om Tietos tekniska partner.

Även EMCs vd Robert Ekström är mycket fåordig.

– Jag har kontinuerliga möten med Tieto kring det här och vi kan kanske gå ut med information under nästa vecka, säger han.

Slutklämmen...
För EMC är situtationen pinsam med tanke på att man bara två dagar före haveriet publicerade en omfattande undersökning om katastrofskydd. Här återfinns följande forumulering:

”Resultatet av undersökningen visar att företag och organisationer måste byta riktning och ta katastrofskydd och backupfrågorna på allvar. Inte minst för att säkerställa att de affärskritiska it-systemen fortsätter att fungera även vid naturkatastrofer eller vid mer vanliga it-haverier.”
Jomen...

[Snobbe]

Misstänkte att det var en patch eller liknande som fuckade upp allt. Det har hänt på ett företag jag jobbade för innan också. Dock inte med liknande nertid och då var det SAN det gällde. Eftersom jag är noob på SAN och på vad nu tieto använder så undrar jag, går det inte att köra någon återställningspunkt när man patchar? Det kan ju omöjligt vara så att man tar världens risk när man ska patcha skiten?:)

[shut teh face]

Misstänkte att det var en patch eller liknande som fuckade upp allt. Det har hänt på ett företag jag jobbade för innan också. Dock inte med liknande nertid och då var det SAN det gällde. Eftersom jag är noob på SAN och på vad nu tieto använder så undrar jag, går det inte att köra någon återställningspunkt när man patchar? Det kan ju omöjligt vara så att man tar världens risk när man ska patcha skiten?:)
Det är lite mer komplext än så. Vid en normal mjukvaruuppgradering av saker och ting fungerar det bra att återställa till tidigare tidpunkt, men så fort lagring eller databaser är inblandat så är det inte lika enkelt.

Nu vet jag inte exakt vad fast-cache innebär dock.

Sedan undrar jag hur sådana här "hosting" företag gör, de borde ha testmiljöer för sina kunder med identiskt setup där man kör igenom allt sånt här, då borde man ha sett felet på SAN-skåpet i test medan man funktionstestat det under en längre period. Men de kanske bara smällt på det i skarpt läge direkt...

[Snobbe]

Det är lite mer komplext än så. Vid en normal mjukvaruuppgradering av saker och ting fungerar det bra att återställa till tidigare tidpunkt, men så fort lagring eller databaser är inblandat så är det inte lika enkelt.

Nu vet jag inte exakt vad fast-cache innebär dock.

Sedan undrar jag hur sådana här "hosting" företag gör, de borde ha testmiljöer för sina kunder med identiskt setup där man kör igenom allt sånt här, då borde man ha sett felet på SAN-skåpet i test medan man funktionstestat det under en längre period. Men de kanske bara smällt på det i skarpt läge direkt...

Jag tror generellt så har man de servrarna som kunden betalar för, dvs en stage miljö om nu kunden betalar för detta. Dock så gäller ju inte det på t.ex. lagring osv där man har flera kunder och stora SAN system osv. Där ska ju hosting företagen självklart ha 2 system så dom kan testa saker innan det går live. Men jag tror inte alla företagen följer den standarden tyvärr.

[shut teh face]

Jag tror generellt så har man de servrarna som kunden betalar för, dvs en stage miljö om nu kunden betalar för detta. Dock så gäller ju inte det på t.ex. lagring osv där man har flera kunder och stora SAN system osv. Där ska ju hosting företagen självklart ha 2 system så dom kan testa saker innan det går live. Men jag tror inte alla företagen följer den standarden tyvärr.
Så är det troligtvis.

De kan skylla hur mycket de vill på leverantören (EMC), Tors hammare eller vad som helst. Problemet kunde undvikas genom att designa enligt best practice.

[Nitrometan]

Bra analyser ni gör. :thumbup:

Sen tillkommer kostnadsfrågan och Tieto vill lägga ett lågt bud så att de får uppdraget samtidigt som de tjänar mycket pengar.

Då kan det bli dumsnålt.

Problemet kunde undvikas genom att designa enligt best practice.
Jo. Vi brukar prata om nåt vi kallar "good practice", vilket liknar best pratice. Skillnaden är att best practice är hårt styrt för att tala om vad som är bäst för alla alltid och good practice handlar om att ta hänsyn till den situation man är i - "vad är bäst här och nu?" Ofta är de lika eller samma, men man har möjlighet att välja och anpassa sig. Fast nu jobbar jag inte med SAN eller lagringslösningar så jag kan bara prata generellt.

[Nitrometan]

Hmmm.

http://www.emc.com/about/glossary/fast-cache.htm

http://www.emc.com/about/glossary/fast.htm

Nån sa att det var här problemet låg och att det var svårt att återställa den data som hade förlorats från "cache-disken".

Nu vet jag inte exakt vad fast-cache innebär dock.

EMC:s eget påhitt tydligen.

FAST cache accelerates performance to address unexpected workload spikes. FAST and FAST cache are a powerful combination, unmatched in the industry, that provides optimal performance at the lowest possible cost.

Upp till 2TB i en cache.

FAST är tydligen också deras lagring.

FAST makes a storage system both faster and lower-cost at the same time, because it only uses high-performance tiers when needed, and uses low cost/high capacity tiers when possible. Policies provide control for how performance and cost are optimized, and the automation of FAST means the storage system has no added management burden compared to slower, more costly systems.

Sen var det tydligen svårt att uppdatera den mjukvaran.

[Ronn]

Testmiljöer där man testar saker innan är också väldigt sällan exakta produktionsreplikor i uppsättning, ibland finns det begränsningar som gör det praktiskt eller ekonomiskt svårt att göra det "lika" och är inte testmiljön en exakt replika så finns det alltid risker att det går fel trots att man testat i testmiljö innan.

Samma sak som avtal gäller där ju mer lik testmiljön är produktion ju mer kostar det och ju mindre chans är det att man lägger ner dom pengar som behövs.

[shut teh face]

Testmiljöer där man testar saker innan är också väldigt sällan exakta produktionsreplikor i uppsättning, ibland finns det begränsningar som gör det praktiskt eller ekonomiskt svårt att göra det "lika" och är inte testmiljön en exakt replika så finns det alltid risker att det går fel trots att man testat i testmiljö innan.

Samma sak som avtal gäller där ju mer lik testmiljön är produktion ju mer kostar det och ju mindre chans är det att man lägger ner dom pengar som behövs.
Jo det är många företag som har den attityden, men i stage-miljöerna så är det ju möjligt att faktiskt alla kunder sitter på samma SAN-skåp, för där spelar det inte så stor roll, men det blir ändå korrekt vid testande av patchar/firmware/etc.

Men man har väl presenterat alternativen för kunderna och sagt olika prislappar, och lyckats få kunder att tro att de har 99,8% SLA ändå, men det är bara fulspel.

[Snobbe]

http://www.idg.se/2.1085/1.419612/tieto--blaskarmar-och-kraschade-band

Känns bra:D

[shut teh face]

Förvånande att de kör Windows.

OK då har de alltså inte testat av sina disaster recovery-rutiner.

[Nitrometan]

Jag har varit med om ett ställe där det fanns bra backuprutiner. Men sen när det inträffade en krasch (en server brann upp) så visade det sig att de inte hade provat att läsa tillbaka från backupbanden. Tydligen funkade det inte. Det blev lite panik och en leverantör som fick betala böter.

Som tur var så hade vi en aktuell kopia av de tabeller som försvann i en testmiljö. :)

[martikainen]

Jag har varit med om ett ställe där det fanns bra backuprutiner. Men sen när det inträffade en krasch (en server brann upp) så visade det sig att de inte hade provat att läsa tillbaka från backupbanden. Tydligen funkade det inte. Det blev lite panik och en leverantör som fick betala böter.

Som tur var så hade vi en aktuell kopia av de tabeller som försvann i en testmiljö. :)

Det där är ju tyvärr vanligare än man tror, avtalen behandlar ju väldigt ofta backuper och rutiner kring hur det skall tas och lagras, men väldigt många missar återläsningskraven.
restore på de viktigaste systemen samt 10-20% utvalda servrar bör ske 1-2ggr/år och vi samtliga större förändringar tex.

Jag lägger ingen skuld på Tieto i detta fallet, missförstå mig rätt, men det har säkerligen gjort precis som alla andra företag gör, man har dragit en gräns där man anser att pengarna väger tyngre än riskerna.
Man har köpt in redundanta system och tester har gjorts i implementation, nu sket det sig i både den primära och redundanta miljön, vad förväntas man göra då? Ha en till redundans?

Tieto är ju leverantör åt åtskilliga kunder, alla kostnader som tieto har, faktureras kunden på ett eller annat sätt, om tieto har ett avtal på att ha en redundant miljö så kan dom ju inte slänga upp en tredje lösning och fakturera hur som helst.

Skillnaden är om man jobbar med drift åt sitt egna företag, där har man helt andra möjligheter både vad gäller pengar men framförallt att forma och testa systemen.

Edit: självklart ligger ansvaret på Tieto, men jag ser inte att dom har gjort något oerhört idiotiskt eller misskött sin leverans. (utan att veta mer vad som händer internt, tex om det ena skåpet aldrig fungerar över huvudtaget)

[TIMPA]

Inga dåliga företag etcetc som blir drabbade av den där skiten.

[Nitrometan]

Man har köpt in redundanta system och tester har gjorts i implementation, nu sket det sig i både den primära och redundanta miljön, vad förväntas man göra då? Ha en till redundans?

Från artikeln som länkas ovan:
Backupen togs på ett större antal virtuella maskiner, men det fungerade alltså inte. Då försökte Tieto läsa upp de senaste kopian från bandlagringssystemet. Problemet är att klientversionen av backupprogrammet Legato Networker som Tieto använder inte är kompatibel med Windows 2008 R2.

Legato Networker ägs sedan 2003 av EMC och kallas numera EMC Networker. Det finns dokumentation om vilka versioner av programmet som fungerar ihop med Windows 2008 R2, men här har uppenbarligen Tieto slarvat.

Det som enligt den utomstående experten nu har hänt är att det inte går att läsa upp backuperna från bandlagringssystemet på de virtuella Windowsservrarna.

Jag gissar att de som jobbar med systemen/backupen har påpekat problemen. Men jag gissar att nån chef har sagt nej för att det var för krångligt och dyrt att byta till "rätt version".

[shut teh face]

Man kan sammanfatta det som så att det inte finns rutiner värda namnet, för backup, disaster, recoery, om man inte testat dem, och ofta, och vid förändringar.

De kan vara skrivna på guldpapper av Bill Gates men systemen är ofta unika för varje organisation och teknikerna måste få tid att testa av saker och ting själva.

I slutändan så är det kanske kundernas ovilja att vilja betala mer som fått det såhär, det är väl därför Tieto är billiga (som jag förstått).

[Snobbe]

Förvånande att de kör Windows.

OK då har de alltså inte testat av sina disaster recovery-rutiner.

Fast du kan inte skylla på windows för det där, både windows och linux funkar bra om man sköter det på rätt sätt:) (jag chansar på att lagringsystemet inte är byggt på windows:p)

[Tenzu]

Det där är ju tyvärr vanligare än man tror, avtalen behandlar ju väldigt ofta backuper och rutiner kring hur det skall tas och lagras, men väldigt många missar återläsningskraven.
restore på de viktigaste systemen samt 10-20% utvalda servrar bör ske 1-2ggr/år och vi samtliga större förändringar tex.

Ja faktiska tester av reservrutiner och karastrofplaner är verkligen skrämmande dåliga på vissa ställen. Trist att sitta med en oandvändbar backup om det väl smäller menar jag.

Från det man fått veta så skulle jag säga att i alla fall en miss är att man valt att peta i FAST-cache lådor i SANet från början, det ger en kraftigt ökad komplexitet medan I/O vinsterna är högst tveksamma i praktiken enligt min erfarenhet. Bättre då att lägga ex.vis tempDB på egna SSD LUN om man känner att det behövs, men det är väl lite vilken filosofi man har.
Nu är ju FAST också (väldigt) dyrt så IT-arkitekten på Tieto har kanske prioriterat lite märkligt kan man tycka. Lider hur som med teknikerna på tieto, jäkla soppa att reda ut.

[Snobbe]

Är det bara jag som undrar varför apoteken och sollentuna kommun faktiskt behöver detta galet snabba lagringssystemet?:) Om det nu är så mycket snabbare än vanligt SAN osv.

[Tenzu]

Är det bara jag som undrar varför apoteken och sollentuna kommun faktiskt behöver detta galet snabba lagringssystemet?:) Om det nu är så mycket snabbare än vanligt SAN osv.

Enkla svaret är, they don't :)
Ett hyffsat SAN ligger <8ms vilket lär vara fullt tillräckligt för de allra flesta av tietos kunder.

Ex.vis ett e-recept behöver vara framme i tid till att patienten har masat sig ner till apoteket, där borde man kanske prioritera säkerhet istället för millisekunder kan man tycka.

[Snobbe]

Enkla svaret är, they don't :)
Ett hyffsat SAN ligger <8ms vilket lär vara fullt tillräckligt för de allra flesta av tietos kunder.

Ex.vis ett e-recept behöver vara framme i tid till att patienten har masat sig ner till apoteket, där borde man kanske prioritera säkerhet istället för millisekunder kan man tycka.

Mjo exakt. Det är nog väldigt få kunder som kan vilja kräva snabbare lagring än så och om de gör det så gör man ju den kundspecifik.

[hahavaffan]

Tieto - "Vi kan erbjuda er Det Snabbaste Systemet Ni Fattar Inte Hur Snabbt Det är, Vi Snackar SAN ULTRA FAST CACHE MUMBOJUMBO ©".
Hjärndöd kund - *Hårdnad* "Kommer vi vara snabbare än Apoteket Hjärtat?"
Tieto - "Utan tvekan! Vi snackar SAN ULTRA FAST CACHE MEGAMUMBOJUMBO ©"
Hjärndöd kund - "Vi tar det!!1111 *sprut sprut*"

Exakt så gick det till.

[shut teh face]

Kunderna har nog inte haft någon insyn i vilken lagring det är direkt. Dessutom kan man ju inte säga att SAN-skåp har en generell hastighet, beror ju helt och hållet på hur många kunder de slängt in där, alla får ju dela på samma kapacitet ändå, och de har ju lagt allt skit på samma diskar.

Cachen har de nog fixat för de märkt att det börjar gå slött för deras egna bruk, exempelvis att deras backuper och underhåll blivit lite långsamt kanske, där är ju första varningstecknet på att blanda ihop skit. De kunde lagt pengarna på mindre SAN-skåp så kunderna fått ett eget istället.

[Nitrometan]

Cachen har de nog fixat för de märkt att det börjar gå slött för deras egna bruk, exempelvis att deras backuper och underhåll blivit lite långsamt kanske, där är ju första varningstecknet på att blanda ihop skit. De kunde lagt pengarna på mindre SAN-skåp så kunderna fått ett eget istället.
Nu tycker jag att du verkar vrång. ;)

Hårdvara är dyrt.

Och säljarna på EMC kanske bjöd chefen på en trevlig golfrunda när de berättade om hur bra FAST cache var...

[Jarod]

https://www.msb.se/Upload/Forebyggande/Informationssakerhet/Rapporter/Tieto_rapport_2012.pdf

http://computersweden.idg.se/2.2683/1.434018/tietohaveriet---dag-for-dag

Haverirapporten om Tietohaveriet ger en ny inblick i vad som egentligen hände under de intensiva dagarna i höstas.
När Myndigheten för samhällsskydd och beredskap, MSB, släppte sin rapport på onsdagen gick det för första gången att få ihop alla pusselbitarna om vad som egentligen hände dagarna efter Tietos haveri den 25 november förra året. Här är alla händelserna – dag för dag.

[Nitrometan]

Tackar. Kan vara intressant att läsa.

[Nitrometan]

Här är beskrivningen av hur det började...

Fredag eftermiddag.
Under eftermiddagen upptäcker Tieto en driftstörning och inser snart att något allvarligt har inträffat. Företaget börjar jobba internt för att hitta och åtgärda felet.

Åtskilliga kunder får problem direkt, som till exempel Apoteket. 350 Apoteket över hela landet har ingen kontakt med sina it-system och kan inte lämna ut receptbelagda mediciner. Om någon patient skadats av detta är ännu okänt. ”Vissa apotek börjar i detta ansträngda läge hantera sina recept manuellt, medan andra ganska snabbt kan återinstallera ett äldre it-system vilket resulterar i att hanteringen hjälpligt kan upprätthållas”, står det i rapporten.

En annan, en namngiven, finansiell aktör drabbas också. Kundtjänsten påverkas, produktionen av kreditkort stoppas tillfälligt och inbetalningar till kundkonton går inte att se. Företaget räddas av sina reservkopior och kan ganska snabbt komma tillbaka till normal verksamhet.

Ett stort logistikföretag med stora kontrakt med offentlig sektor drabbas. De kan inte kommunicera med sina kunder via e-post eller via sin interna eller externa hemsida. Företaget har varit med om en större kris tidigare och sammankallar snabbt sin krisgrupp. Företaget har en kontinuitetsplan som underlättar arbetet.

Söndag eftermiddag.
Tieto går ut med information om att driftstörningen beror på ett maskinvarufel. Det direkta felet hos Tieto åtgärds under kvällen. Nacka Värmdö Posten rapporterar att Nacka kommun har fått problem med sin hemsida, en liten föraning om vad som ska komma.

Måndag förmiddag.
Människor återvänder till sina arbetsplatser och upptäcker att deras it-tjänster inte längre fungerar. Tieto är fortfarande fåordiga om haveriet.
Logistikföretaget kan inte sköta sin verksamhet och kan inte ens nå sina anställda. Tillfälligt löser de problemet genom ett sms-utskick. Företaget väljer att prioritera sina kunder inom offentlig sektor.

Bilprovningen har totalstopp i it-systemet under måndagen. Varje dag rullar det in 20 000 fordon på företagets kontrollstationer. Bara telefonerna fungerar. Bilprovarna får övergå till manuell registering av provresultaten med papper och penna. Detta leder till omfattande merarbete och kostnader när all data ska efterregistreras. En annan följd av driftstörningen är att många fordon får körförbud eftersom Transportstyrelsen inte längre får in rapporter om godkända kontrollbesiktningar.

Nästan samtliga kommunala aktiviteter och verksamheter i Nacka kommun drabbas. Kommunen tar till Facebook och Twitter för att kommunicera på något sätt med sina medborgare och samarbetspartners.

Måndag eftermiddag.
Nacka kommuns socialtjänst tvingas meddela att det uppstått förseningar i utbetalningen av försörjningsstöd till följd av driftsstoppet. Kommunen får temporärt övergå till manuella utbetalningar.

Också i Sollentuna kommun får socialkontoret liknande problem. Skolorna i kommunen drabbas, e-posten fungerar inte längre och det går inte att logga in och se pågående arbeten. Runt 6000 elever och lärare får plocka fram papper och penna. Den kommunala administrationen drabbas också, handläggare kommer inte åt sina ärenden.

Stockholm stads skolwebb, en tjänst som används för frånvarorapportering, ligger nere under avbrottet.

Om efterverkningarna och återställningen:
Men också utanför Stockholm med kranskommuner påverkas verksamheter av driftsstoppet. Flera kommuner drabbas av problem med självservicessystem som till exempel tidsrapportering.
– De flesta drabbade kunder tycks ha problem under hela helgen och måndagen, trots att det direkta felet åtgärdades redan under söndagen. Återställningen av kunddata tar uppenbarligen tid, står det i rapporten.


Apoteket är en av de första kunderna som får tillbaka sitt it-stöd. Tieto själva väljer att prioritera att få igång deras system då de anser verksamheten vara samhällskritisk. Onsdag vid lunch är alla Apotek igång igen.

Hos det stora logistikföretaget dröjer det 11 dagar innan it-driften kommer tillbaka. Företaget säger att verksamheten inte är upp i normal drift ens två månader efter haveriet.

I mitten av december meddelar Nacka kommun att verksamheten till 95 procent kunnat återgå till det normala. Merkostnaden för haveriet uppskattas till minst 7,5 miljoner kronor.


Fast de pratar bara om symtomen. Inte om orsaken.

I MSB:s rapport står:
"Driftstörningen hos Tieto berodde på ett tekniskt problem, som inte beskrivs i detalj denna rapport."

Den beskrivning som finns i rapporten låter som rappakalja och är antagligen nåt som Tieto har "hittat på" och som MSB har godtagit.

3.2 Det tekniska felet

Det tekniska felet hos Tieto drabbade en central komponent av datalagrings-
utrustningen. Det innebar att i stort sett all datalagring hos de berörda
kunderna på kort tid upphörde att fungera. Tieto har inte offentliggjort några
mer detaljerade uppgifter om det maskinvarufel som var den direkta
felorsaken, utöver att det handlade om en central del av ett lagringssystem.
Felet inträffade under fredagen den 25 november. Det direkta felet tog två dygn
att åtgärda, vilket innebär att utrustningen hos leverantören fungerade igen
redan under söndagen den 27 november.

Kundernas information, alltså de data som lagrats i lagringssystemet, kunde
emellertid inte återställas enbart genom att byta ut en komponent i den
tekniska utrustningen. Maskinvarufelet utlöste nämligen en kedja av incidenter
som resulterade i en komplex och tidsödande återställningsprocess. Därför
dröjde det betydligt längre innan kunderna kunde återställa sina lagrade data i
samma skick som under fredagen, innan maskinvarufelet inträffade.

Fortfarande inget om orsaken eller om det var FAST cache som kanske visade sig vara en icke-optimal lösning i detta fall.

[Nitrometan]

Även här: http://computersweden.idg.se/2.2683/1.434024/haverirapport-tieto-vagrade-beratta

Som CS tidigare berättat är Kammarkollegiet skarpt kritiskt mot Tietos ovilja att dela med sig av information om de tekniska orsakssambanden bakom jättekraschen. Tieto har försvarat sig med att detta är frågor som fortfarande är under utredning.
Men nu visar det sig också att Tieto inte heller ville berätta för MSB vilka myndigheter som var drabbade av kraschen.

Bara timmar efter att Tieto-haveriet kallade MSB samman sin speciella samverkansgrupp för informationssäkerhet. Redan från start stod det klart att Apotekens receptsystem slagits ut. Men bit för bit stod det klart för MSBs specialgrupp att även en lång rad andra samhällsfunktioner drabbats.

Att läget inledningsvis bedömdes som potentiellt allvarligt framgår av att samverkansgruppen flera gånger övervägde att aktivera en nationell plan för allvarliga it-inicidenter. Tidigt i processen skickades också en preliminär lägesbedömning om Tieto-kraschen över till försvarsdepartementet.

Samverkansgruppens första steg var att försöka skaffa sig en överblick av haveriets konsekvenser för att få underlag till ett senare ställningstagande om haveriet skulle bedömas samhällsfarligt eller inte.

Men när MSB tog kontakt med Tieto för att ta reda på vilka myndigheter som drabbats av kraschen, blev det kalla handen. Tieto ville inte berätta det med hänvisning till affärssekretessregler i outsourcingavtalen.

Fast de olika myndigheterna har fortfarande ett ansvar. Bara för att de har ousourcat så slipper de inte ansvaret för sin verksamhet.

MSBs och Kammarkollegiets rapport ger fler interiörer om svårigheterna att få information av Tieto om haveriet.

Båda myndigheterna inbjöds att vara med i en referensgrupp till Tietos egen haveriutredning. Men efter att Tieto misslyckats med att få dem att skriva på ett non disclosure-avtal i strid med den offentlighetslagstiftning som myndigheter är skyldiga att följa, ströps informationen från Tietos sida.

Efter ett möte i i mitten av januari där Tieto i princip bara berättade att man inte hade något att säga, ansåg Kammarkollegiet samarbetet var meningslöst och hoppade av från referensgruppen.

MSB valde att sitta kvar i gruppen, men konstaterar i rapporten att informationen man fått från Tieto är i det närmaste obefintlig.

– Tieto har varit tillmötesgående utifrån sin affärslogik. Samtidigt kan vi bara konstatera att den information vi fått från dem har varit begränsad, säger Richard Oehme, chef för MSB enhet för samhällets informationssäkerhet.

Jaha. Så kan man också göra.

Om MSB hade sagt att stoppet var samhällsfarligt så hade Tieto kunnat berätta mer säger de, men eftersom Tieto inte berättade vilka som var drabbade så kunde MSB inte göra en bedömning av hur samhällsfarligt det var. Låter väl rimligt.

[shut teh face]

Jag är intresserad av att se "orsaken" senare, eller egentligen inte orsaken, de spelar ingen roll vad orsaken är, men jag håller fast på att felet kunde begränsas med annorlunda design, de vill de säkert inte avslöja dock.

[Nitrometan]

Ett annorlunda designat SAN med en annan backuplösning hade troligen gett ett annat resultat.

Men det säger nog inte Tieto.