Mjukvarubugg hos Fastly slog ut Amazon, Reddit och stora nyhetssajter

Vad är skillnaden mellan Fastly och Cloudflare? Gör de samma sak?

Att ha separata QAs och testgrupperingar tyder på amatörer till utvecklare.

Huruvida dom har QA och test som separata grupper är väl svårt att säga utan att få tag på ett organogram.
Det går inte ens att veta huruvida dom har en QA avdelning. Gissningsvis har dom i alla fall inte en QA avdelning med något slags mandat att säkerställa kvaliteten.

Att dom skapat en fantastisk backend har noll relevans till om dom är amatörer på området kvalitetsäkring och test. Det är inte testarna som bygger backend. Det gör utvecklare. Och det har dom säkerligen en hel del som är kompetenta.

Jag skulle säga att den här incidenten är ett ganska tydligt exempel på ett företag som (liksom många andra) har alldeles för lite fokus på kvalitetssäkring och testning och framför allt en korkad syn på hur det borde hanteras.

Jag jobbar som testledare och test manager så jag är alltid intresserad av att utveckla mig inom området. Hur skulle man hitta en defekt som uppstår under väldigt specifika förhållanden och månen är i zenit? Testa allt?

Det stod väl i texten att det var på grund av något som deployats i maj och att problemet endast kunde "triggas" om någon kund gjorde en viss kombination av inställningar.

Hur som håller med om att det skulle vara lite jobbigt att vara den som commitade ändringarna.. Men samtidigt måste ändringarna ha granskats av flera och utöver det kan man också som andra redan varit inne på, tycka att testningen borde upptäckt felet.

Tycker ändå det löste felet snabbt med tanke på att det var från en commit som varit deployad över en månad utan att felet uppstått.

Svårt att svara generellt på det men det viktigaste med det hela är verkligen att på riktigt anamma testdriven utveckling. Många pratar om det men i praktiken är det relativt ovanligt att det verkligen görs ordentligt utanför dom mest kritiska operationerna (banker/medicin). Om man hela tiden jobbar med metoden att vi definierar input - output när vi ska skapa något och skriver testerna parallellt med utvecklingen (eller innan, smaksak det där) så kommer vi täcka in den absoluta majoriteten av alla buggar.

Dom talar om specifik konfiguration och om vi tar det till att mena det mer komplexa fallet med X parametrar som alla måste vara specifika värden för att orsaka buggen (och inte det mer vanliga, en specifik parameter med ett specifikt värde) så behöver vi ett lager till utöver det ovan (enhetstester). För nästa lager (integrationstestning) blir allt långt mer komplext som du såklart vet, här måste man jobba utifrån use-cases, vad tror vi att folk kommer göra? Och skriva tester för det.

I detta fallet där dom utvecklat en ny funktion så verkar det som att dom inte täckt in ett sätt att använda funktionen på i sina tester, men alla olika sätt går inte rimligt att skriva testfall för om man har många parametrar. Men det finns verktyg som kan automatgenerera sådana tester. Blir det tillräckligt många så tar testerna för lång tid för att man ska kunna vänta på dom i sin CI/CD pipe, då får man välja ut ett subset som core grejer som körs som del i pipe:en och sen nattliga tester på hela sviten.

Sen kan man ta en sida ur Netflix tankesätt också, de utvecklade internt ett "verktyg" som heter Chaos Monkey som live i produktion sänker godtyckliga servrar och applikationer/noder för att på så sätt tvinga fram bättre redundans och felhantering. Samma princip har ju länge använts inom testning, att försöka ha "sönder" koden, men kan man automatisera det? Låta den slumpa fram indata och tugga loss i sin egen instans och se vad som smäller.

Det du pratar om är väldigt standard o type det man lör sig på en tvådagars kurs om agil utveckling. Problemet, och som man får lära sig första minuten, är att man aldrig kan testa allt. Aldrig. Du kan vara scripta och automatisera scenarion som du vet om.

Ditt prat om agilt och ci/cd får mig att tro att du jobbat mycket inom produktbolag. Där är SUT extremt isolerat och där kanske det fungerar med det du säger. Har ingen erfarenhet tyvärr

Där jag jobbar, och på tidigare arbetsplatser, så utvecklar vi system som ska interagera med kanske 60 andra system och hundratals integrationer. Vissa nya, vissa webbaserade och vissa skrivna i språk där samtliga utvecklare dött. Här kan man omöjligt och aldrig förutse extremfall. Man kommer alltid bli tagen på sängen. Så man får jobba mer med mitigering, rollbackrutiner osv. Och Fastly var ganska snabbt på benen så de har nog testat sina rutiner ganska bra ändå.

Och då har jag inte ens nämnt arbete med känslig data där alla system och testare ska hållas separerade. Nä, jag önskar att vi körde devops o liknande men är nöjd så länge vi kan köra agilish

(Nu ska jag förbereda test enligt GDP, blir inte mer stelbent än så, lol)

Absolut, så är det, utgick helt ifrån hur Fastly skulle gjort med sin produkt, då det var den som felade och de som teoretiskt skulle ha kunnat hitta buggen via testning. Integrationstestning som du pratar om är en helt annan best och man kan mycket riktigt inte testa allt, varför jag nämnde testa utifrån use cases för att säkra alla viktiga/primära flöden. Utöver det, för att få ett säkert/stabilt system, handlar det om att skapa säkerhetsdörrar och vattenlås i systemet, se till så att om något börjar mumsa trådar eller läcka minne etc.

så hindras det från att sänka hela applikationen. I detta fallet skulle det ha yttrat sig som att för just den kunden som triggade buggen skulle systemet vara otillgängligt eftersom de sänkte varje instans de pratade med med sin konf. Men alla andra kunder skulle inte ha påverkats av det om dom tagit det konceptet fullt ut.

För så komplexa miljöer du jobbar i är det dock bara att inse som du säger att det inte går att förutspå allt så man måste istället jobba med att kunna rädda och gå tillbaka till ett tidigare stable state.

Sen, ja, alla lär sig det där i kurs 101-A men väldigt få tillämpar det faktiskt hela vägen i min erfarenhet. Många kör någon halvmesyr av sunkiga enhetstester och klagar om att "se jag gjorde det och det hjälpte inte, kan jag få sluta med det nu och bara koda?"

Så gick det med dina tankar om en riktad attack @crew seven