Knight kapital trading system

Goldman Sachs Massive Trading Error Bears En Skrämmande likhet med den som tog ner Knight Capital Nu när vi vet mer om dagens optionshandel fel kunde kosta Goldman Sachs hundratals miljoner, vi vet att det ser mycket ut som ett annat massivt handels misstag - Knight Capitals 450 miljoner trading glitch från 2012. Båda Goldmans misstag igår - ett systemprogrammeringsfel som ställer in felaktiga prisgränser i ett antal tickersymboler - och Knights misstag - också ett systemprogrammeringsfel som skickade algoritmer som köper högt och säljer lågt - markera det faktum att komplexa datorprogram med hög hastighet har befogenhet att sätta marknaderna i en tizzy. Heres hur långt Goldmans bristfälliga handel, som skickades till alternativutbyten runt om i landet, nåttes i går (från Bloomberg): Handel kan ha påverkat cirka 400 000 kontrakt för företag som JPMorgan Chase amp Co. Johnson Amp Johnson och Kellogg Co. baserat på data för de 500 största affärer. Nasdaq OMX PHLX granskar en lista med cirka 1.225 unika kontrakt på 51 underliggande aktier, enligt dess näringsidkare. Ungefär 240 september 103 sätter kontrakt för iShares Russell 2000 Exchange-Traded Fund handlas på 1 klockan 9:32 a. m. New York tid idag, ner från så mycket som 3,32 två minuter tidigare, data sammanställd av Bloomberg showen. Nästa handel genomfördes klockan 3.27 klockan 9:33. För Knight Capital kostade ett programmeringsfel företaget sin egen existens. Goldman säger däremot att felet inte skulle vara väsentligt för företagets finansiella ställning. Banken är känd för att ha några av de mest sofistikerade och kraftfulla handelstekniken på gatan, men talade om handel med hög fart på optionsmarknaden här. Som företag försöker bygga program för att bli den snabbaste och dåligaste, säger några experter, kan misstag göras. Bakom Knight-tiden talade Business Insider med Lev Lesokhin. Han arbetar för CAST, ett företag som visualiserar inneboende risker i finansiella mjukvarusystem. Lesokhin förklarade att några av dessa finansiella företag inte är tillräckligt noga med vad som ligger under huven i sina datorprogram - och det betyder att bisarra saker kan hända. På riddare var den bisarra saken Frankenstein-koden. De flesta IT-applikationer har död kod, sade Leskhin. Det finns bara hängande i kodbasen men ingen av levande moduler kallar det. Om du inte har strukturell övervakning vet du inte om din nya levande kod skulle kunna ringa den döda koden. I Knights fall var det. Den levande koden kallade den döda koden tillbaka till livet och programmet började handla på det. Tja, vänta och se vad som hände med Goldman. När det gäller affärerna kan de alla vara avbrutna (avbrutna) beroende på reglerna för vad som utgör ett officiellt fel vid de aktuella börserna (NYSE, NASDAQ, CBOE). Mer om detta för att komma. Få den senaste Goldman Sachs aktiekursen här. Pressmeddelande SEK-avgifter Knight Capital med överträdelser av Market Access Rule för omedelbar frisättning 2013-222 Washington DC 16 oktober 2013 mdash Securities and Exchange Commission meddelade idag att Knight Capital Americas LLC har gått med på att betala 12 miljoner för att avgöra avgifter som det kränkta reglerna för marknadsadgang för agencyrsquos i samband med handelshändelsen den 1 augusti 2012 som störde marknaderna. En SEC-undersökning fann att Knight Capital inte hade tillräckliga skyddsåtgärder för att begränsa riskerna med tillgången till marknaderna och misslyckades som ett resultat för att förhindra att miljontals felaktiga order infördes. Knight Capital misslyckades också med att genomföra adekvata granskningar av effektiviteten av sina kontroller. Detta är SECrsquos första verkställighetsåtgärd enligt marknadstillträdesregeln, som antogs 2010 som regel 15c3-5. ldquo Marknadsåtkomstregeln är nödvändig för att skydda marknaderna, och Knight Capitalrsquos-överträdelser sätter både företaget och marknaderna i fara, säger rdquo Andrew Ceresney, medordförande i SECrsquos-divisionen för verkställighet. ldquoGiven den snabba handelstakten på dagens marknader och den potentiella massiva inverkan av kontrollnedbrytningar måste mäklarehandlare hållas till de höga normerna för överensstämmelse som är nödvändiga för den säkra och ordnade driften av marknaderna. Daniel Daniel Hawke, chef för SEC Enforcement Divisionrsquos Market Abuse Unit, tillagt, ldquoBrokers och återförsäljare måste titta på varje komponent i vart och ett av sina system och fråga sig vad som skulle hända om komponenten störs och vilka säkerhetsnät finns på plats för att begränsa den skada den kan orsaka. Knight Capitalrsquos misslyckade med att fråga dessa frågor hade katastrofala konsekvenser. Enligt Qursquos-ordern gjorde Knight Capital två kritiska tekniska missteps som ledde till handelshändelsen den 1 augusti 2012. Knight Capital flyttade en del av datorkoden 2005 till en tidigare punkt i kodsekvensen i en automatiserad equity router, vilket ger en funktion av routern defekt. Även om denna funktion inte var avsedd att användas, lämnade Knight den i routern. I slutet av juli 2012 när man förberedde sig för deltagande i NYSErsquos nya Retail Liquidity Program, tillämpade Knight Capital felaktigt ny kod i samma router. Som ett resultat ledde vissa beställningar som berättigade till NYSErsquos-programmet ut den defekta funktionen i Knight Capitalrsquos-router, som då inte kunde känna igen när order hade fyllts. Under de första 45 minuterna efter att marknaden öppnades den 1 augusti skickade Knight Capitalrsquos-routern snabbt över 4 miljoner order till marknaden när man försökte fylla i endast 212 kundorder. Knight Capital handlade mer än 397 miljoner aktier, förvärvade flera miljarder dollar i oönskade positioner och så småningom en förlust på mer än 460 miljoner. SECrsquos-ordern finner också att ett internt Knight Capital-system genererade 97 automatiserade e-postmeddelanden som gick till en grupp personal. E-postmeddelandena refererade routern och identifierade ett fel innan marknaderna öppnades den 1 augusti. Dessa meddelanden orsakades av felet för kodinstallation, men Knight Capital handlade inte om dem den 1 augusti. Även om Knight Capital inte utformade dessa meddelanden som system varningar gav de möjlighet att identifiera och åtgärda problemet innan marknaderna öppnades. SECrsquos beställer kostnaderna Knight Capital med överträdelse av reglerna för marknadstillträde på följande sätt: Fick inte tillräckliga kontroller vid en punkt omedelbart före inlämnandet av order till marknaden, till exempel en kontroll för att jämföra beställningar som lämnar routern med de angivna. Förlitade sig på finansiell riskkontroll som inte kunde förhindra införandet av order som översteg förutbestämda kapitaltrösklar för företaget i sin helhet. Länkade inte kontot som mottog avrättningarna den 1 augusti till automatiserade kontroller avseende firmrsquos totala finansiella exponering. Fick inte tillräckliga kontroller och förfaranden för koddistribution och testning för sin egenordningsrouter. Fick inte tillräckliga kontroller och skriftliga förfaranden för att vägleda anställdas svar på väsentliga tekniska och överensstämmande incidenter. Granskade inte sin verksamhet på ett adekvat sätt i samband med dess marknadstillträde för att säkerställa den övergripande effektiviteten i sina riskhanteringsinsatser och tillsynsförfaranden. Dess bedömning fokuserade i stor utsträckning på att sammanställa en inventering av befintliga kontroller och säkerställa att de fungerade som avsedda, i stället för att fokusera på sådana risker som felfunktioner i sin automatiserade orderrouter. Företaget reagerade också på förhandshändelser för snävt och övervägde inte till rätta orsakerna till tidigare incidenter. Fick inte en adekvat skriftlig beskrivning av dess riskhanteringskontroller. Certifierade inte i sin årliga årsberättelse för 2012 att Knight Capitalrsquos riskhanteringskontroller och tillsynsförfaranden överensstämde med reglerna för marknadstillträde. SECrsquos-ordern tar också ut Knight Capital med överträdelser av reglerna 200 (g) och 203 (b) i förordningen SHO, som kräver en korrekt märkning av korta försäljningsorder och lokalisering av aktier för att låna för kort försäljning. SECrsquos-ordern kräver att Knight Capital betalar 12 miljoner straff och behåller en oberoende konsult för att göra en omfattande granskning av firmrsquos kontroller och förfaranden för att säkerställa att reglerna om marknadstillträde överensstämmer. Utan att erkänna eller förneka slutsatserna samtyckte Knight Capital till SECrsquos-ordern, som censurerar företaget och kräver att den upphör och avstår från att begå eller orsaka dessa kränkningar. SECrsquos-utredningen genomfördes av personal i Market Abuse Unit, inklusive Jason Burt, Carolyn Welshhans, William Max Hathaway och Ainsley Kerr. Fallet övervakades av Mr Hawke och unit co-vicechef Robert Cohen. SECrsquos National Exam Program och Division of Trading and Markets gav betydande assistans. Jag talade vid en konferens förra året om ämnena DevOps, Configuration as Code och Continuous Delivery och använde följande historia för att visa vikten av att implementeringarna automatiserades fullständigt och repeterbar som en del av ett DevOpsContinuous Delivery-initiativ. Sedan den konferensen har jag blivit uppmanad av flera personer att dela berättelsen genom min blogg. Denna berättelse är sant att detta verkligen hände. Detta är mitt berättande av historien baserat på vad jag har läst (jag var inte inblandad i detta). Det här är historien om hur ett företag med nästan 400 miljoner tillgångar gick i konkurs på 45 minuter på grund av en misslyckad implementering. Bakgrund Knight Capital Group är ett amerikanskt globalt finansiellt företag som bedriver marknadsföring. elektroniskt genomförande och institutionell försäljning och handel. År 2012 var Knight den största näringsidkaren i amerikanska aktier med en marknadsandel på cirka 17 på vardera NYSE och NASDAQ. Knights Electronic Trading Group (ETG) lyckades med en daglig daglig handel på mer än 3,3 miljarder trades dagligen och handlade över 21 miljarder dollar per dag. Det är inget skämt den 31 juli 2012 hade riddare cirka 365 miljoner kontanter och ekvivalenter. NYSE planerade att inleda ett nytt Retail Liquidity Program (ett program som syftar till att erbjuda förbättrade priser till detaljhandelsinvesterare genom detaljhandeln, som Knight) den 1 augusti 2012. För att förbereda denna händelse uppdaterade Knight sin automatiska, höghastighetsalgoritmiska router som skickar order till marknaden för utförande som kallas SMARS. En av kärnfunktionerna i SMARS är att ta emot order från andra delar av Knights trading platform (förälderorder) och sedan skicka en eller flera order till barn för körning. Med andra ord skulle SMARS få stora order från handelsplattformen och bryta upp dem i flera mindre order för att hitta en buyer-match för volymen av aktier. Ju större förälderordern är, desto fler barnorder kommer att genereras. Uppdateringen till SMARS var avsedd att ersätta gammal oanvänd kod som kallades Power Peg-funktionalitet som Knight inte hade använt i 8 år (varför kod som hade varit död i 8 år fortfarande var närvarande i kodbasen är ett mysterium, men det inte poängen). Koden som uppdaterades återställde en gammal flagga som användes för att aktivera Power Peg-funktionaliteten. Koden var noggrant testad och visat sig fungera korrekt och tillförlitligt. Vad kan eventuellt gå fel? Vad kan eventuellt gå fel Felaktigt mellan 27 juli 2012 och 31 juli 2012 Knight installerade manuellt den nya mjukvaran till ett begränsat antal servrar per dag åtta (8) servrar i alla. Det här är vad SEC-filningen säger om den manuella installationsprocessen (BTW om det finns en SEC-fil om din implementering kan det ha gått väldigt fel). Under utplaceringen av den nya koden kopierade en av Knights tekniker inte den nya koden till en av de åtta SMARS dataservrarna. Knight hade inte en andra tekniker granskar denna utplacering och ingen hos Knight insåg att Power Peg-koden inte hade tagits bort från den åttonde servern eller den nya RLP-koden tillade. Knight hade inga skriftliga förfaranden som krävde en sådan granskning. SEC Filing Release nr 70694 16 oktober 2013 klockan 9:30 Eastern Time den 1 augusti 2012 öppnade marknaderna och Knight började behandla order från mäklare för sina kunder för det nya Retail Liquidity Programmet. De sju (7) servrarna som hade rätt SMARS-implementering började behandla dessa order korrekt. Order som skickades till den åttonde servern utlöste den supposable repurposed flaggan och tog tillbaka den gamla Power Peg-koden från de döda. Attack of the Killer Code Zombies Det är viktigt att förstå vad den döda Power Peg-koden var tänkt att göra. Denna funktionalitet var tänkt att räkna aktierna mot en förälderorder som barnorder beställdes. Power Peg skulle instruera systemet att sluta dirigera barnbeställningar när förälderordern var uppfylld. I grund och botten skulle Power Peg hålla koll på barns order och stoppa dem när förälderns order slutfördes. År 2005 flyttade Knight denna kumulativa spårningsfunktionalitet till ett tidigare skede i kodkörningen (sålunda räknar spårningen från Power Peg-funktionaliteten). När Power Peg-flaggan på den åttonde servern aktiverades började Power Peg-funktionaliteten att dirigera barnorder för utförande, men spårade inte mängden aktier mot föräldraordningen något som en ändlös slinga. 45 minuter av helvetet Föreställ dig vad som skulle hända om du hade ett system som kunde skicka automatiska höghastighetsorder till marknaden utan att spåra för att se om tillräckligt många order hade utförts. Ja, det var så dåligt. När marknaden öppnade klockan 9:30 visste folk snabbt att något var fel. Vid 9:31 var det uppenbart för många människor på Wall Street att något seriöst hände. Marknaden översvämdes med ordinarie order för vanliga handelsvolymer på vissa lager. Vid 9:32 AM undrade många på Wall Street varför det inte hade slutat. Detta var en evighet i höghastighets handelsvillkor. Varför hade inte någon träffat kill-switchen på vilket system som helst som det visar sig att det inte fanns någon dödsbrytare. Under de första 45 minuterna av handel utgjorde Knights avrättningar mer än 50 av handelsvolymen och körde vissa aktier upp över 10 av deras värde. Som ett resultat av detta minskade andra lager i värde som svar på de felaktiga affärer. För att göra saken värre började Knights system skicka automatiserade e-postmeddelanden tidigare på dagen så tidigt som 08:01 (när SMARS hade behandlat order som var berättigade till marknadsföring före marknadsföring). E-postmeddelandena refererar till SMARS och identifierade ett fel som Power Peg inaktiverat. Mellan 8:01 och 9:30 var 97 av dessa e-postmeddelanden skickade till Knight personal. Naturligtvis var dessa e-postmeddelanden inte utformade som systemvarningar och därför tittade ingen på dem direkt. Hoppsan. Under 45 minuter av helvetet upplevde riddaren att de försökte flera motåtgärder för att försöka stoppa de felaktiga affärer. Det fanns ingen dödsbrytare (och inga dokumenterade rutiner för hur man reagerade) så att de kvarstod försöka diagnostisera problemet i en levande handelsmiljö där 8 miljoner aktier handlades varje minut. Eftersom de inte kunde bestämma vad som orsakade de felaktiga ordern reagerade de genom att avinstallera den nya koden från servrarna och användes på rätt sätt. Med andra ord tog de bort arbetskoden och lämnade den trasiga koden. Detta förstärkte bara problemen som orsakade ytterligare förordningar för att aktivera Power Peg-koden på alla servrar, inte bara den som inte distribuerades korrekt. Så småningom kunde de stoppa systemet efter 45 minuters handel. Under de första 45 minuterna öppnades marknaden Power Peg-koden mottagen och behandlade 212 föräldraordningar. Som ett resultat sände SMARS miljoner orderorder på marknaden vilket resulterade i 4 miljoner transaktioner mot 154 aktier för mer än 397 miljoner aktier. För dig börsklubbar innebar detta att riddaren antog cirka 3,5 miljarder netto långa positioner i 80 aktier och 3,15 miljarder netto korta positioner i 74 aktier. Under laymen8217s villkor realiserade Knight Capital Group en förlust på 460 miljoner på 45 minuter. Kom ihåg att Knight bara har 365 miljoner i kontanter och ekvivalenter. På 45 minuter gick Knight från att vara den största näringsidkaren i amerikanska aktier och en stor marknadsmäklare i NYSE och NASDAQ till konkurs. De hade 48 timmar för att höja kapitaltillskott för att täcka sina förluster (vilket de lyckats göra med 400 miljoner investeringar från cirka ett halvt dussin investerare). Knight Capital Group förvärvades så småningom av Getco LLC (december 2012) och det sammanslagna företaget heter nu KCG Holdings. En lektion att lära händelserna den 1 augusti 2012 bör vara en lektion för alla utvecklings - och operationsgrupper. Det räcker inte att bygga bra programvara och testa det. Du måste också se till att det levereras på marknaden korrekt så att dina kunder får det värde du levererar (och så du inte konkurs ditt företag). Den ingenjör som sätter in SMARS är inte enbart skyldig att den process som Knight hade satt upp inte var lämplig för den risk de utsattes för. Dessutom var deras process (eller brist därav) i sig föremål för fel. Varje gång din implementeringsprocess bygger på människor som läser och följer instruktioner utsätts du för risker. Människor gör misstag. Misstagen kan vara i instruktionerna, i tolkningen av instruktionerna eller i utförandet av instruktionerna. Utvecklingar måste automatiseras och repeteras och så befria från potentiellt mänskligt fel som möjligt. Had Knight implementerat ett automatiserat installationssystem komplett med konfiguration, implementering och testautomatisering skulle felet som orsakade riddare ha undvikits. Ett par principer för kontinuerlig leverans gäller här (även om du inte implementerar en fullständig leveransprocess): Frigörande av programvara bör vara en repeterbar, pålitlig process. Automatisera så mycket som är rimligt. Ett scenario: Vi antar att de hade mycket bra DevOps. Så alla servrar skulle synkroniseras. Men 8211 antar att den nya koden hade ett fel. Så alla servrar är synkroniserade men har samma buggy-kod. Vad händer om två versioner av koden, det vill säga de senaste 2 implementeringarna hade den här felet. Så snart de inser att något är fel, ringer de tillbaka koden, bugan stannar fortfarande8230 Precious minutes har gått. Kanske 20 minuter i stället för 45 minuter i din artikel. Så kort sagt 8211 är deras katastrofdrömbrytare en code rollback-implementering i en levande miljö. Det skulle fortfarande vara en defekt design. Vad de behöver behöver vara en stor röd strömbrytare (nästan bokstavligen, någonstans i instrumentbrädan) för att omedelbart sluta. Var är affärsregeln som säger att 8220 först gör ingen skada8221. VJ om utplaceringen till alla servrar hade fungerat, skulle de ha varit ok. Men i detta fall användes 7 av 8 för ett delsystem korrekt. På grund av det dåliga beteendet rullade de tillbaka de andra 7 tänker den nya koden i det delsystemet var problemet. Det multiplicerade problemet till den slutliga dödkontakten. Katastrofer är nästan alltid komplexa. I det här fallet var det dåligt kodande praxis, plus tvivelaktiga testkodskontrollmetoder, plus ett fel vid implementering, plus en återgång vid delsystemet dels granulat snarare än hela systemet. Om du löser några av dessa problem får du inte en katastrof. En av de saker jag har sett i företag som inte erkänner den faktiska betydelsen och inverkan av sina IT-system är att de don8217t ger budget för uppdateringar av äldre kod. Till exempel: I8217ve sedda situationer där IT har ingen budget. Det måste rättfärdiga allt det gör mot en affärsutgift. Det innebär att ständigt krypteras för att ställa upp nya projekt. Företag ser sällan behovet av att uppdatera gammal programvara som för närvarande arbetar, så de vägrar att betala för det. Resultatet är en konstant ny kod, gjord av de billigaste kodarna möjlig, men investerar inte i den teknik som i slutändan skulle förbättra prestanda och minska risken. Varför Eftersom dessa ses som 8220IT-problem8221 och inte utseendet på vilket projekt IT-medarbetarna arbetar på så kommer ingen att betala för det. En bra läsning om denna övning är The Phoenix Project av Gene Kim, Kevin Behr och George Spafford. Tack för att du tillämpade hjärnan på hype. Förmodligen bör man fråga varför de berörda teknikerna fick ta skulden, men fick inte myndighet att döda omkopplaren på egen hand. Åh, det är därför att du lägger OpsSRE på plats ändå. 8220R8221 är för ansvarig, aka flame bete. Jag har skrivit lite om den här händelsen, och jag skulle varna någon att använda SEC-rapporten som något annat än vad SEC behövde det för. kitchensoap20131029counterfactuals-ridder-capital Fascinerande läsning. Jag arbetade på ett stort auktionshus för frukt och grönsaker en gång där en ny mjukvaruversion installerades och misslyckades, vilket ledde till stora förluster för handlarna (men inte så stora som dessa). Även detta var ett felaktigt utplacering och ingen återgång. Läran att lära sig är att det finns domäner där datorn inte ska fatta något beslut utan mänsklig validering. Vad sägs om de människor som förlorade sina jobb, eftersom oj, det fanns en bugg Vad med de andra företagen som kanske kom i trubble på grund av plötslig förändring av lagervärdet Automation av 8220 högnivåbeslut8221 ska hanteras carefully8230 Trevligt och pedagogiskt postvärde. Användning av Cynefin-ramverket ger en bättre karakterisering av detta 8216DevOps8217-fel Det här inlägget verkar ha skrivits ur ett DevOps-perspektiv. De föreslagna lösningarna överensstämmer med ett DevOps-perspektiv 8211 granska frisläppsprocessen, automatisera mer och skapa en dödswitch med återskapningsfunktioner. Någon kan läsa inlägget och lägga för mycket tonvikt på Knight-tekniker som inte kopiera den gamla koden till en av de åtta servrarna. Någon kan överskatta en orsak och effekt relation. Någon kan insistera på nya regler för att 8216förhindra detta från att hända igen.8217 Ett kraftfullare tillvägagångssätt kan investera i: 8211 Öka mångfalden för att analysera situationen och syntetisera bättre alternativ 8211 Förbättra kommunikationen mellan specialiteter 8211 Förbättra implicit samordning mellan specialiteter 8211 Rekrytera personer med mer expertis för att skriva och granska kod En viktig faktor som begränsade att förbättra teamets förmåga från nio år före den signifikanta felhändelsen var felaktiga systemet. I en Cynefin-ram begränsar detta misslyckande till ett DevOps-problem systemet med 8220Obvious8221-domänen där det finns enkla orsak och effektrelationer som kan identifieras av 8216professionals.8217. Felet bör inte associeras med domänen Cynefin 8220Complicated8221 där en signifikant analys av 8216specialists8217 skulle ha förhindrat misslyckandet. Systemet bör associeras med Cynefin 8220Complex8221 domän 8211 ett komplext adaptivt system. Systemet är dispositionellt. Samma inledande förhållanden kommer inte att ge samma misslyckande (utom vid olycka). För mer information om Cynefin, besök en. wikipedia. orgwikiCynefin och CognitiveEdge. Jag uppskattar att du lyfter fram de tysta faktorerna i en sådan katastrof. Liksom författaren arbetar jag också med operationer, och det är lätt att falla i samma gamla tankemönster på orsaker och lösningar. Jag trivs särskilt med din mångfald (som kommer i alla former: erfarenhetsnivåer, kulturell och pedagogisk bakgrund, färdigheter, ålder etc.), eftersom jag tycker att detta är en stark drivkraft bakom framgången med DevOps själv. Att ha en mängd olika perspektiv, både inom och utan ditt team, har en stark och påvisbar potential för att titta på ditt projekt och kan hjälpa till att begränsa överblickar som den som uppstått i den här artikeln. Varför kod som hade varit död i 8 år fortfarande var närvarande i kodbasen är ett mysterium, men det är inte poängen Tvärtom är det faktiskt punkten. Kod med oanvända, och därför otestade, konfigurationsmöjligheter är en katastrof som väntar på att hända. Det är därför som I8217m är mycket skeptisk till funktionen-flaggbaserade tillvägagångssätt i allmänhet. Konfigurationen är lika mycket en del av ditt program som koden är och konfigurationsändringar ska gå igenom samma livscykel 8211-dragförfrågan, kodgranskning, släpp, distribuera till staging 8211 som någon annan ändring. Om din utsläppsprocess är för tung och du måste göra snabba konfigurationsändringar till produktionen, åtgärda din frigöringsprocess. Det var för många misstag att ange det episka misslyckandet med att bara DevOps (även om jag helt håller med om att automatisering och testning är det enda sättet): 8211 Inga lagarbete och checklistor medan du gör en uppdatering på produktionsservrar. Eventuell uppdatering av produktionen bör kräva att ett lag tittar över varandra och går igenom en checklista. 8211 8 år oanvänd gammal kod i produktion. Det berättar mycket om bristen på förståelse för riskerna med dangling 8220unused8221-kod. 8211 Otillräcklig loggning från koden och otillräcklig loggövervakning, korrelation och analys i realtid. Det skulle ha utlöst tillräckligt många ledtrådar till ingenjörer och opsfolk. 8211 Ingen hot-hot failover till ett kluster med tidigare version. Det skulle ha stoppat alla problem efter 1 eller 2 minuter. (That8217s den röda ruggknappen som artikeln nämner) Om du också har byggt arkitektur, system och företag under lång tid, vet du att katastrof händer, du vet att några buggar bara fångas i naturen och inte under simuleringar, precis som du vet maskiner kommer att gå ner. Du måste förbereda dig för det värsta fallet i båda scenarierna. Murphy8217s lag är så sant i vår värld I8217 har varit i det som nu kallas 8220DevOps8221-rymden i nästan 20 år, över hälften av det i den finansiella världen. Knight var både en leverantör till och en konkurrent till det företag jag jobbar för. Distributionsautomatisering kan ha hjälpt. Kanske. Men få företag har råd med exakt dubbla miljöer, och detta orsakades huvudsakligen av miljöskillnader. Även automatiserad validering av utplacering har inte hjälpt i det här fallet om automationen didn8217t vet om miljöskillnaden. Automatisering är bara lika bra som kunskapen om människorna som ställer upp det. Om en manuell installation inte var medveten om det gamla systemet, så hade det en bra chans att det automatiserade systemet wouldn8217t ha känt att kontrollera det heller. Automatisering av rollback är också bara lika bra som beslutsfattandet om huruvida man ska göra rollbacken. Och om automationen oavsiktligt startade det gamla systemet, var det inte heller någon garanti för att omkoppling av det moderna systemet skulle ha upphört med det gamla systemet 8211 kunde du ha haft samma problem även efter en automatiserad återuppringning av det moderna systemet. Vilket bringar mig till en sista punkt: Automation är ett krav i stora, moderna miljöer. Men alltförlitande på det kan leda till att de som kör systemet inte känner till vad det gör. Automatisering är mest användbar för valideringar, eftersom validering av saker görs på rätt sätt är tråkigt och lätt att skämma på när det görs manuellt. Även när man automatiserar, med mänskliga inblandade brytpunkter eller mänskliga driven steg bidrar man till att de som använder systemet känner till systemet och hur det fungerar, förbättrar sin förmåga att felsöka problem, diagnostisera problem och göra lämpliga förslag på vilka åtgärder som ska vidtas stoppa eller mildra ett problem. Automatisering är ett verktyg, men det är bara ett verktyg och det kräver fortfarande en hantverkare att använda den på lämpligt sätt. Expertis är vad som gör och håller bra system bra. Reblogged detta på Garrett S. Y. Hampton och kommenterade: Incredible. DevOps ser alltid på, dokumenterar och granskar dina implementeringar