Gå til innhold

Alt ut for Altinn


Anbefalte innlegg

Feilen var vel i The BIG-IP Fast Cache Module, big news flash, den cacher. Kanskje for å veie opp for ytelsesproblemer i andre deler av systemet. Verden må være bra vakker i svart-hvitt. Er du også på lønningslista til en av leverandørene?

Endret av Del
  • Liker 1
Lenke til kommentar
Videoannonse
Annonse
Gjest Slettet+6132

Jeg registrerer at Accenture har fått en underleverandør til å ta på seg all skyld, og jeg registrerer at du kan lite om driftskritiske systemer. Sensitive data skulle aldri ha blitt cachet i en tredjeparts programvare.

 

Jeg tviler på at f5 ville gått med på å få skylden hvis det ikke var big-ip som var problemet. De har et rykte å ta vare på de også. Og ja, sensitive data skulle aldri bli cachet, det var jo nettopp det som feilet.

 

Kunne ikke vært mer enig.

Det Accidenture er gode på er å lage kontrakter som gir oppdragsgiver all skyld ved feil de eller underleverandører gjør.

Det skal de ha.

Oppsannn,

Det er kanskje ikke det som er viktig ved å lage driftsikre/teknisk gode løsninger i IT-bransjen?

:)

Endret av Slettet+6132
Lenke til kommentar

Feilen var vel i The BIG-IP Fast Cache Module, big news flash, den cacher

Mulig vi snakker forbi hverandre...

Som vanlig i slike løsninger, så cacher lastbalansereren statiske objekter og ikke dynamiske. Men så hadde tydeligvis en dynamisk html blitt tolket som en statisk. Er dette virkelig så vanskelig å skjønne uten å dra inn Microsoft?

Lenke til kommentar

Feilen var vel i The BIG-IP Fast Cache Module, big news flash, den cacher. Kanskje for å veie opp for ytelsesproblemer i andre deler av systemet. Verden må være bra vakker i svart-hvitt. Er du også på lønningslista til en av leverandørene?

 

Kamerat, caching er fundamentalt i CS-verdenen. Den negative koblingen du prøver å opprette når ikke frem. Caching er så enormt grunnleggende i CS-verdenen at alt fra webservere til filsystem til grafiske brukergrensesnitt benytter seg av det.

 

Almost all programming can be viewed as an exercise in caching.

Endret av Paull
  • Liker 1
Lenke til kommentar

Jeg hater ikke Microsoft. Jeg registrerer at Accenture har fått en underleverandør til å ta på seg all skyld, og jeg registrerer at du kan lite om driftskritiske systemer. Sensitive data skulle aldri ha blitt cachet i en tredjeparts programvare. Det handler om sikkert design. Microsoft baserte løsninger har en tendens til å bli et lappeteppe med sloppy forhold til minnehåndtering.

 

Først og fremst: caching har ingenting med minnehåndtering å gjøre. Caching ofrer minne for å unngå langt tregere oppslag i f.eks. DB eller filststem. Således er caching elementært i nær sagt ethvert moderne driftskritisk system.

 

Og for det andre: sensitive data skal aldri caches i tredjeparts programvare? Det må være den merkeligste påstanden jeg har hørt. Du aner ikke hva BIG-IP er for noe, gjør du vel? Det er en rackmontert enhet dedikert til lastbalansering som monteres onsite, så hvis du mener sensitive data ikke kan caches der så kan vel heller ikke sensitive data rutes gjennom Cisco-ruteren som er montert rett under? Den inneholder jo også tredjeparts programvare. :roll:

 

Det er alltid morsomt når idealister stikker fingrene i ørene og kjemper med nebb og klør mot virkeligheten. Beklager, men denne gangen bomma du grovt.

 

Slapp dog bare av, Microsoft kommer nok snart til å gi deg en gyldig grunn til å gå i strupen på dem, kjenner jeg dem rett.

Endret av henrikwl
Lenke til kommentar

Hm, enorm iver etter å frikjenne Accenture (leverandør) og Basefarm (drifter) her. Si meg jobber dere alle tre der? La oss ta dette fra begynnelsen.

 

Altinn har hatt en historie, og denne kulminerte i brukeren Kenneth som fikk sine sensitive data frigjort for all verden.

 

Dere tre har av en eller annen grunn hengt dere opp i denne siste hendelsen, hvor Accenture og Basefarm (for de er kildene her) bedyrer at de har ingen skyld, men at all skyld ligger på F5, som har innrømmet at dynamiske sider ble cachet ved en feil. I tillegg er dere besatt av å fokusere kun på Microsoft sin uskyld, noe som drar fokus bort fra de største syndebukkene i den lange fadesen som kulminerte i Kenneth.

 

Det er mulig Accenture spiller med rene kort i denne enkelthendelsen, men dere er litt for kjappe med å kjøpe det som kommer derfra som hele bildet.

 

Så tilbake til skyldnerne. Dette er ingen enkelthendelse. Det var store problemer i fjor også (hvorfor har dere ikke kommet med noen forsvarstale for Microsfoft i den sammenheng?). Det er en rapport fra Veritas som er rimelig krass som kom før årets fadese. Dernest, på selve dagen hadde systemet knelt ved overlast fra morgen til kveld før Kenneth ble offer. Det er altså rimelig bred systemsvikt som kulminerte i Kenneths uheldige berømmelse.

 

Hvis dere vil kan vi godt gå inn på en teknisk diskusjon rundt datasikkerhet, caching, lastbalansering og routing av nettverkstrafikk, så får vi se hvem av oss som har flest kniver i den skuffen.

Endret av Del
  • Liker 2
Lenke til kommentar

Del, har du noe annet enn synsinger på hvorfor Accenture / Basefarm's forklaring er feil eller misvisende? Og hvordan klarer du å blande inn Microsoft hele tiden?

Det virker like usaklig som å skylde på apache-bevegelsen hver gang et propellhue klarer å lage et php script med 35,6 sikkerhetshull per linje kode, siden de har levert komponenter til server-systemet...

 

Hvis dere vil kan vi godt gå inn på en teknisk diskusjon rundt datasikkerhet, caching, lastbalansering og routing av nettverkstrafikk, så får vi se hvem av oss som har flest kniver i den skuffen.

 

Passer ikke inn i denne tråden, men .. Du har allerede vist tendenser til å mikse seperate funksjoner (minne og cache, for eksempel), noe som ikke akkurat gir deg startposisjonen i det kappløpet, for å si det slik.

  • Liker 1
Lenke til kommentar

Problemet er at du klarer ikke skille snørr og barter. Samme hvor stor belastning en lastbalanserer utsettes for, så skal ikke slike ting skje. Enkelt og greit. Feilen var i BIG-IP, og skylden for det ligger ene og alene hos F5. Punktum, det er ikke noe å diskutere en gang.

 

Diskusjonen om hvorvidt andre teknologiske valg ville gjort det lettere å unngå generelle problemer knyttet til belastningstoppene (det er slettes ikke umulig st så ville vært tilfelle) de få gangene i året det er en problemstilling er for så vidt interessant, men nå var det altså ikke det som var hovedproblemet denne gang og du trenger ikke å gjøre enhver diskusjon om Altinn om til en korstog mot Microsoft og alle som bruker det. Verden er ikke svart-hvitt, og avgjørelsen om å bruke Microsoft-produkter foretas ofte av helt andre enn de som skal implementeremløsningen - noe du ville visst om du hadde erfaring med denne typen utvikling.

 

Og, siden du er i overkant opptatt av hvor folk jobber så kan jeg informere om at jeg ikke jobber i hverken Altinn, Accenture eller Basefarm, men hos en av konkurrentene til Accenture.

  • Liker 2
Lenke til kommentar

Del, har du noe annet enn synsinger på hvorfor Accenture / Basefarm's forklaring er feil eller misvisende?

Forklaring på hva? Hvis du skal gå inn i en betent diskusjon bør du heve presisjonsnivået ditt flere hakk. Les min forrige post en gang til hvis du har problemer med å sortere ut.
Og hvordan klarer du å blande inn Microsoft hele tiden?

Jeg har blandet inn flere, det er andre som henger seg kun opp i Microsoft. Gå tilbake så ser du at jeg ga deg en lenke som bekreter at Altinn er bygget på Microsoft sitt CSP. Gå tilbake hit og les:

https://www.diskusjon.no/index.php?showtopic=1424347&view=findpost&p=19082321

Når da systemet ved gjentatte ganger har kollapset, blir det litt fjernt å frede Microsoft.

Du har allerede vist tendenser til å mikse seperate funksjoner (minne og cache, for eksempel),

Hm, hva fabler du om? Gå tilbake til posten hvor jeg beskyldte Microsfotløsninger for å ha sloppy forhold til minnehåndtering, hvor sa jeg der at cache og minne er samme sak? Når det er sagt er det velkjent at minnehåndtering og cache er nært beslektet. Fysisk cache regnes som en del av minnehierarkiet. Når det gjøres i software er det også lett å dra paralleller. Du får lese litt her hvis du synes det er uklart: http://en.wikipedia.org/wiki/Cache_%28computing%29
  • Liker 1
Lenke til kommentar

Og, siden du er i overkant opptatt av hvor folk jobber så kan jeg informere om at jeg ikke jobber i hverken Altinn, Accenture eller Basefarm, men hos en av konkurrentene til Accenture.

Takk, det er greit å vite. Da kan jeg godt forstå at du har forståelse for Accenture sin situasjon.
  • Liker 1
Lenke til kommentar

Del.... La meg nå ta tingene steg for steg...

 

Forklaring på hva? Hvis du skal gå inn i en betent diskusjon bør du heve presisjonsnivået ditt flere hakk. Les min forrige post en gang til hvis du har problemer med å sortere ut.

 

La meg sitere biter av den posten rett over min:

 

Hm, enorm iver etter å frikjenne Accenture (leverandør) og Basefarm (drifter) her. [...]

Altinn har hatt en historie, og denne kulminerte i brukeren Kenneth som fikk sine sensitive data frigjort for all verden. [...]

Det er altså rimelig bred systemsvikt som kulminerte i Kenneths uheldige berømmelse.

 

Vi snakker selvfølgelig om Kenneth, som du sier rett ut at er resultat av systemsvikt av Accenture og Basefarm. Mens dokumentasjon fra de leverandørene peker på en hittil ukjent bug i utstyr fra en 3djepart.

 

Og når det gjelder Microsoft biten..

 

Jeg påstår ikke at feilen skyldes Microsoft, men jeg er lei av at Microsoft elskere fanatisk avfeier at feilen har noe med valg av Microsoft løsning å gjøre.

 

Kanskje jeg leser litt for mye inn i det, men her er slik jeg leser det : "Jeg påstår ikke at det er Microsoft, men det er Microsoft. Og alle som sier noe annet, er fanatikere"

 

Sensitive data skulle aldri ha blitt cachet i en tredjeparts programvare. Det handler om sikkert design. Microsoft baserte løsninger har en tendens til å bli et lappeteppe med sloppy forhold til minnehåndtering.

 

Der drar du en DIREKTE sammenheng mellom caching og minnehåndtering.

 

 

Noe mer som var uklart? Jeg hadde forresten sett at vi holdt ting til kjente fakta, istedet for diverse synsing videre i tråden :)

Lenke til kommentar

Jeg hadde forresten sett at vi holdt ting til kjente fakta, istedet for diverse synsing videre i tråden :)

Som vi sier nord for Sinsenkrysset, det var rette rævva som feis. Det var vel jeg som brakte kjente fakta inn i tråden i det hele, og fikk skremt ut litt dokumentasjon fra andre. Ditt bidrag har vært kun synsing, og det blir veldig kjedelig øvelse for leserne om jeg plukker tullballet ditt fra hverandre.DIREKTE my ass, hvis du lurer på hva jeg mener er det bare å spørre. Hvis du er uenig så får du være konkret og si hva du er uenig i. :tease:
  • Liker 1
Lenke til kommentar

Fakta : Altinn's forklaring på siste tid's problemer

 

Fakta : Plattform har fint lite å si for skalerbarhet (Facebook er skrevet i PHP for Gud's skyld, og Hotmail kjører på Microsoft løsninger)

 

Fakta : Minne og caching er to seperate ting.

 

grumbles

 

Hvordan du kan få det sitatet om caching og minne til å mene noe annet enn det som faktisk står der, og som du så beskylder meg for å tolke feil... Da må jeg virkelig spørre, hva i alle dager var det du prøvde å si der da?

 

Lenke til kommentar
Josten har allerede postet lenken. Har du noe å bidra med?
Fakta : Plattform har fint lite å si for skalerbarhet (Facebook er skrevet i PHP for Gud's skyld, og Hotmail kjører på Microsoft løsninger)
Hm, naturligvis har plattform mye å si for skalerbarhet. Facebook har utviklet en egen kompilator for php på grunn av det. ref. http://en.wikipedia.org/wiki/HipHop_for_PHP Det du forsøker å si er at man kan få enhver plattform til å skalere til Altinn sitt behov? Og hva så?
Fakta : Minne og caching er to seperate ting.
Minnehåndtering og caching er beslektet.Linux eksempelvis bruker minnet til caching notorisk. Hvis du ikke rebooter vil cache fylle opp alt minnet på en linuxmaskin over tid. Det brukes for å forbedre ytelse, eller sagt på en annen måte, å maskere dårlig ytelse. Hva trodde du cache var? Trodde du det ikke hadde noe med minnehåndtering å gjøre du også?
  • Liker 1
Lenke til kommentar

Jeg har skrevet det før, jeg skriver det igjen: Det spiller ingen rolle HVOR buggen var, noen er ansvarlig for den. Rent teknisk kan vi si i dette tilfellet at det var de som skrev cache-greia som er ansvarlig, men spørsmålet er da hvem som valgte dette produktet. Gjorde de en god nok jobb? Var dette programvare de kunne gå inne for. Det har de tydeligvis gjort, så Accenture er til slutt ansvarlig. (Antageligvis. Det kan selvsagt hende at denne softwaren var en del av kravspeccen fra myndighetene, men jeg tviler.)

Lenke til kommentar
Josten har allerede postet lenken. Har du noe å bidra med?
Fakta : Plattform har fint lite å si for skalerbarhet (Facebook er skrevet i PHP for Gud's skyld, og Hotmail kjører på Microsoft løsninger)
Hm, naturligvis har plattform mye å si for skalerbarhet. Facebook har utviklet en egen kompilator for php på grunn av det. ref. http://en.wikipedia..../HipHop_for_PHP Det du forsøker å si er at man kan få enhver plattform til å skalere til Altinn sitt behov? Og hva så?
Fakta : Minne og caching er to seperate ting.
Minnehåndtering og caching er beslektet.Linux eksempelvis bruker minnet til caching notorisk. Hvis du ikke rebooter vil cache fylle opp alt minnet på en linuxmaskin over tid. Det brukes for å forbedre ytelse, eller sagt på en annen måte, å maskere dårlig ytelse. Hva trodde du cache var? Trodde du det ikke hadde noe med minnehåndtering å gjøre du også?

 

1. Det er fakta, og du sier noe annet. Du etterspurte fakta. Du sier det er linket allerede i tråden, og da burde du jammen meg ikke trenge å spørre om det...

 

2. Skalerbarhet er design, ikke plattform. Noen plattformer er naturlig lettere å skalere, men det har som sagt fint lite å si for faktisk skalerbarhet. Visste du forresten at YouTube kjører det meste på Python? De har til og med en

på det der de snakker om blant annet plattform og skalering. (
videoen er også ganske stilig, en av hovedfolka bak flickr som snakker)

 

3. Minne er en måte å lagre data på. Det er en harddisk også. Cache ER data. Det kan lagres på f.eks harddisk eller minne. Å tro at det ene er det andre fører til forvirring. Ja, Linux bruker minne til å cache data fra harddisk. Varnish bruker minne og harddisk til å cache ferdige sammensatte html-sider. CPU cacher data fra systemminne i L1/L2/L3 minne. Legg her merke til at cache og minne er to forskjellige ting.

 

I tillegg bør man se hvordan løsningen ble integrert i systemet, det er ikke opplagt at systemet skulle ha tilgang til de sensitive dataene overhodet.

 

Så load balancer og SSL handler skal ikke ha tilgang til data som sendes til klienter... Nå er jeg nyskjerrig.. Hvordan har du tenkt at det skal skje?

Endret av Terrasque
Lenke til kommentar

1. Det er fakta, og du sier noe annet. Du etterspurte fakta.

Nei, jeg sier ikke noe annet, jeg sier at det er et større bilde hvor dette er en bit Accenture og Basefarm har presentert. Jeg etterspurte nye fakta fra deg. Kutt ut stråmenn, det kler deg ikke.
2. Skalerbarhet er design, ikke plattform.
Meningsløs semantikk. Når plattformen dikterer store deler av designet (slik det typisk gjøres i all-inn løsninger fra Microsoft), så er mange aspekter ved systemet i større og mindre grad avhengig av plattform. Eksempelvis er HP Non-stop en plattform som på meget lavt nivå legger til rette for sikre løsninger som skalerer.
Visste du forresten at YouTube kjører det meste på Python?
Ja, faktisk. Du finner en interessant artikkel om ytelse og Python her:

http://www.infoworld...too-slow-188715

som du skjønner er plattform og ytelse ikke helt uavhengige størrelser. Diskusjon rundt ytelse og plattform dukker stadig opp i min hverdag. Ofte er det en trade-off mellom enkel og kjapp utvikling på den ene siden og ytelse på den andre. Blander vi sikkerhet inn i bildet blir det straks mye mer komplekst.

3. Minne er en måte å lagre data på. Det er en harddisk også. Cache ER data. Det kan lagres på f.eks harddisk eller minne. Å tro at det ene er det andre fører til forvirring. Ja, Linux bruker minne til å cache data fra harddisk. Varnish bruker minne og harddisk til å cache ferdige sammensatte html-sider. CPU cacher data fra systemminne i L1/L2/L3 minne. Legg her merke til at cache og minne er to forskjellige ting.
Jaså, så du vet en del om hva cache er. Nå har du fått vist det i tråden også til alles kjedsommelighet. Jeg har aldri sagt at minne og cache er det samme, her begynner det å bli mange stråmenn.

I tillegg bør man se hvordan løsningen ble integrert i systemet, det er ikke opplagt at systemet skulle ha tilgang til de sensitive dataene overhodet.

Så load balancer og SSL handler skal ikke ha tilgang til data som sendes til klienter... Nå er jeg nyskjerrig.. Hvordan har du tenkt at det skal skje?

Tja, man kan jo for eksempel skille ut de sensitive delene av systemene i noe som ikke går via en cache modul. Dette kan jo naturligvis gå utover ytelse, hvilket var mitt opprinnelige poeng når jeg første gang kommenterte big-ip saken i denne tråden. Kan du nå være så snill å komme deg videre. Jeg er sikker på at de fleste er dritlei vår dialog.
  • Liker 1
Lenke til kommentar
2. Skalerbarhet er design, ikke plattform.
Meningsløs semantikk. Når plattformen dikterer store deler av designet (slik det typisk gjøres i all-inn løsninger fra Microsoft), så er mange aspekter ved systemet i større og mindre grad avhengig av plattform.

 

Må bare kommentere på denne.. Hvis du ser

(14:50 og litt utover) av den youtube videoen jeg nevnte tidligere, ser du at han nevner et par skalerings-teknikker de går etter. Blant annet "divide and conquer" - han nevner blant annet database sharding, og å dele prosesser opp i deler og sub-deler som kan kjøres uavhengig av hverandre (Han nevner ganske ofte RPC som en av hoved-teknikkene dems).

 

Jeg ser ikke noen som helst grunn til at det ikke kan gjøres på hvilken som helst plattform, med hvilket som helst programmeringsspråk, så lenge det har sockets tilgjengelig. Noen språk og plattformer har en del verktøy som gjør det lettere, men det er fremdeles noe du må designe inn i systemet.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...