Knight Kapital Trading System

Goldman Sachs Massive Trading Error Bears En skremmende likhet med den som førte ned Knight Capital Nå som vi vet mer om dagens handelsfeil for gjeld kan koste Goldman Sachs hundrevis av millioner, vet vi at det ser ut som en annen massiv handelsfejl - Knight Capitals 450 millioner trading glitch fra 2012. Begge Goldmans feil i går - en systemprogrammeringsfeil som angir ukorrekte prisgrenser i en rekke tickersymboler - og Knights feil - også en systemprogrammeringsfeil som sendte algoritmer som kjøper høyt og selger lavt - fremhever det faktum at Kompleks, høyhastighets dataprogramvare har muligheten til å sette markeder inn i en tizzy. Heres hvor langt Goldmans feilhandel, som ble sendt til opsjonsutveksling over hele landet, nådde i går (fra Bloomberg): Handelen kan ha påvirket ca. 400 000 kontrakter for selskaper som JPMorgan Chase Amp Co., Johnson Amp Johnson og Kellogg Co. basert på data for de 500 største handler. Nasdaq OMX PHLX vurderer en liste med ca. 1.225 unike kontrakter på 51 underliggende aksjer, i henhold til sin e-post til handelsvakt. Om lag 240 september 103 ble det inngått kontrakter for iShares Russell 2000 Exchange-Traded Fund, klokka 1, klokka 9:32. New York tid i dag, ned fra så mye som 3,32 to minutter tidligere, data samlet av Bloomberg-showet. Neste handel ble henrettet kl. 3.27 klokka 9:33. For Knight Capital kostet en programmeringsfeil firmaet sin egen eksistens. Goldman, derimot, sier feilen ikke ville være vesentlig for firmaets økonomiske tilstand. Banken er kjent for å ha noen av de mest sofistikerte og kraftfulle handelsteknologiene på gaten, men snakket om handel med høy fart i opsjonsmarkedet her. Som bedrifter prøver å bygge programmer for å bli den raskeste og dårligste, sier noen eksperter, kan feil gjøres. Tilbake rundt Knight-tiden snakket Business Insider til Lev Lesokhin. Han jobber for CAST, et selskap som visualiserer inneboende risiko i finansielle programvare systemer. Lesokhin forklarte at noen av disse finansselskapene ikke er oppmerksom nok til hva som ligger under dekselet til deres dataprogrammer - og det betyr at bisarre ting kan skje. På Knight var den bisarre tingen Frankenstein-koden. De fleste IT-applikasjoner har død kode, sa Leskhin. Dens der bare henger ut i kodebasen, men ingen av de levende modulene ringer det. Hvis du ikke har strukturelt tilsyn, vet du ikke om din nye live kode kan kalle den døde koden. I Knights-saken var det. Live-koden kalte den døde koden tilbake til livet, og programmet begynte å handle på det. Vel vent å se hva som skjedde med Goldman. Når det gjelder handler, kan de alle bli busted (avlyst), avhengig av reglene for hva som utgjør en offisiell feil ved de aktuelle børsene (NYSE, NASDAQ, CBOE). Mer om dette som kommer. Få den nyeste Goldman Sachs-aksjekursen her. Pressemelding SEC Charges Knight Capital med brudd på Market Access Rule for umiddelbar utgivelse 2013-222 Washington DC 16. oktober 2013 mdash Securities and Exchange Commission kunngjorde i dag at Knight Capital Americas LLC har avtalt å betale 12 millioner for å avgjøre gebyrer for at det brøt agencyrsquos markedsadgangsregel i forbindelse med firmrsquos 1. august 2012 handelshendelse som forstyrret markedene. En SEC-undersøkelse fant at Knight Capital ikke hadde tilstrekkelige garantier for å begrense risikoen som følge av tilgangen til markedene, og mislyktes som et resultat for å forhindre inntasting av millioner av feilaktige bestillinger. Knight Capital klarte heller ikke å gjennomføre tilstrekkelige vurderinger av effektiviteten av kontrollene. Dette er SECrsquos første håndhevelse under markedsadgangsregelen, som ble vedtatt i 2010 som regel 15c3-5. ldquo Markedsadgangsregelen er avgjørende for å beskytte markedene, og Knight Capitalrsquos-overtredelser bringer både firmaet og markedene i fare, sa Andrew Ceresney, meddirektør for SECrsquos Divisjon for Håndhevelse. ldquoGiven det raske tempoet i handel i todayrsquos-markeder og den potensielle massive effekten av kontrollbrudd, må meglerforhandlere holdes til de høye standarder for samsvar som er nødvendig for sikker og ordentlig drift av markedene. Danielquke Daniel Hawke, sjef for SEC Enforcement Divisionrsquos Market Abuse Unit, lagt til, ldquoBrokers og forhandlere må se på hver komponent i hvert av deres systemer og spørre seg selv hva som ville skje hvis komponenten fungerer feil og hvilke sikkerhetsnett er på plass for å begrense skade det kan forårsake. Knight Capitalrsquos unnlatelse av å stille disse spørsmålene hadde katastrofale konsekvenser. Ifølge Qursquos-ordren gjorde Knight Capital to kritiske teknologiske feilstrinn som førte til handelshendelsen 1. august 2012. Knight Capital flyttet en del av datakoden i 2005 til en tidligere punkt i kodesekvensen i en automatisert egenkapitalruter, noe som gjør en funksjon av ruteren defekt. Selv om denne funksjonen ikke var ment å bli brukt, forlot Knight den i ruteren. I slutten av juli 2012, da de forberedte seg på deltakelse i NYSErsquos nye Retail Liquidity Program, ble Knight Capital utført feil kode i samme ruter. Som et resultat, bestemte ordre som var kvalifisert for NYSErsquos-programmet, utløste den defekte funksjonen i Knight Capitalrsquos-ruteren, som da ikke kunne gjenkjenne når ordrene var fylt. I løpet av de første 45 minuttene etter at markedet ble åpnet 1. august sendte Knight Capitalrsquos-ruteren raskt over 4 millioner bestillinger inn i markedet da han forsøkte å fylle ut bare 212 kundeordrer. Knight Capital handlet mer enn 397 millioner aksjer, kjøpte flere milliarder dollar i uønskede stillinger, og til slutt tapte over 460 millioner. SECrsquos-bestillingen finner også at et internt Knight Capital-system genererte 97 automatiserte e-poster som gikk til en gruppe medarbeidere. E-postene refererte ruteren og identifiserte en feil før markedene åpnet 1. august. Disse meldingene var forårsaket av kodeutleggingsfeil, men Knight Capital handlet ikke på dem 1. august. Selv om Knight Capital ikke utformet disse meldingene som system varsler, de ga en mulighet til å identifisere og løse problemet før markedene åpnet. SECrsquos-bestillingen belastes Knight Capital med brudd på markedsadgangsregelen på følgende måter: Har ikke tilstrekkelig kontroll på et tidspunkt umiddelbart før innsending av ordrer til markedet, for eksempel en kontroll for å sammenligne bestillinger som forlater routeren med de som er inntatt. Stod på finansielle risikokontroller som ikke var i stand til å forhindre innføring av ordre som oversteg forhåndsdefinerte kapitalgrenser for firmaet som helhet. Koblede ikke kontoen som mottok henrettelsene 1. august til automatiserte kontroller angående firmaets samlede økonomiske eksponering. Fikk ikke tilstrekkelige kontroller og prosedyrer for kodeutplassering og testing for sin egenkapitalordningsrouter. Hadde ikke tilstrekkelige kontroller og skriftlige prosedyrer for å veilede employeesrsquo respons på betydelige teknologiske og compliance hendelser. Har ikke tilstrekkelig gjennomgått sin forretningsvirksomhet i forbindelse med markedsadgang for å sikre den samlede effektiviteten av risikostyringskontroll og tilsynsrutiner. Dens vurdering fokuserte i stor grad på å lage en oversikt over eksisterende kontroller og sikre at de fungerte som tiltenkt, i stedet for å fokusere på slike risikoer som mulig feil i sin automatiserte ordreruter. Firmaet reagerte også på tidligere hendelser for begrenset og ikke tilstrekkelig vurdert grunnårsakene til tidligere hendelser. Har ikke tilstrekkelig skriftlig beskrivelse av risikostyringskontrollene. Ikke sertifisert i sin årlige konsernsertifisering for 2012 at Knight Capitalrsquos risikostyringskontroller og tilsynsrutiner fulgte markedsadgangsregelen. SECrsquos-bestillingen belaster også Knight Capital med brudd på reglene 200 (g) og 203 (b) i forskrift SHO, som krever riktig merking av korte salgsordrer og lokalisering av aksjer for å låne for kortsalg. SECrsquos-ordren krever at Knight Capital betaler en 12 millioner straff og beholder en uavhengig konsulent for å gjennomføre en omfattende gjennomgang av firmrsquos kontroller og prosedyrer for å sikre overholdelse av markedsadgangsregelen. Uten å innrømme eller nekte funnene, samtykk Knight Capital til SECrsquos-ordren, som censurerer firmaet og krever at den opphører og avstår fra å begå eller forårsake disse bruddene. SECrsquos-undersøkelsen ble utført av ansatte i Market Abuse Unit, inkludert Jason Burt, Carolyn Welshhans, William Max Hathaway og Ainsley Kerr. Saken ble overvåket av Mr. Hawke og unitrsquos co-assisterende sjef Robert Cohen. SECrsquos nasjonale eksamensprogram og divisjonen for handel og markeder ga betydelig hjelp. Jeg snakket på en konferanse i fjor om temaene DevOps, Configuration as Code, og Continuous Delivery og brukte følgende historie for å demonstrere viktigheten av å gjøre distribusjonene fullt automatiserte og repeterbar som en del av et DevOpsContinuous Delivery-initiativ. Siden den konferansen har jeg blitt spurt av flere personer for å dele historien gjennom bloggen min. Denne historien er sant dette virkelig skjedde. Dette er min fortell av historien basert på hva jeg har lest (jeg var ikke involvert i dette). Dette er historien om hvordan et selskap med nesten 400 millioner i eiendeler gikk konkurs i 45 minutter på grunn av en mislykket distribusjon. Bakgrunn Knight Capital Group er et amerikansk globalt selskap for finansiell tjenesteyting som driver med markedsføring. elektronisk gjennomføring, og institusjonelt salg og handel. I 2012 var Knight den største handelsmann i amerikanske aksjer med en markedsandel på rundt 17 på hver NYSE og NASDAQ. Knights Electronic Trading Group (ETG) klarte en gjennomsnittlig daglig handelsvolum på mer enn 3,3 milliarder dagligvarer, som handlet over 21 milliarder dollar daglig. Det er ingen spøk 31. juli 2012 hadde Knight rundt 365 millioner i kontanter og ekvivalenter. NYSE planla å lansere et nytt Retail Liquidity Program (et program ment å gi bedre prising til retail investorer gjennom detaljhandel meglere, som Knight) 1. august 2012. Som forberedelse til denne hendelsen oppdaterte Knight sin automatiserte, høyhastighets algoritmiske ruteren som sender ordrer til markedet for utførelse kjent som SMARS. En av kjernefunksjonene til SMARS er å motta bestillinger fra andre komponenter i Knights trading platform (foreldreordre) og deretter sende en eller flere barnordre ut for utførelse. Med andre ord vil SMARS motta store bestillinger fra handelsplattformen og bryte dem opp i flere mindre bestillinger for å finne en buyer-match for volumet av aksjer. Jo større foreldreordre, desto flere barnbestillinger vil bli generert. Oppdateringen til SMARS var ment å erstatte gammel, ubrukt kode som kalles Power Peg-funksjonalitet som Knight ikke hadde brukt i 8 år (hvorfor kode som hadde vært død i 8 år fortsatt var tilstede i kodebase er et mysterium, men det er ikke poenget). Koden som ble oppdatert, repurposed et gammelt flagg som ble brukt til å aktivere Power Peg-funksjonaliteten. Koden ble grundig testet og vist seg å fungere riktig og pålitelig. Hva kan muligens gå galt Hva kan muligens gå galt Faktisk mellom 27. juli 2012 og 31. juli 2012 Knight manuelt distribuert den nye programvaren til et begrenset antall servere per dag åtte (8) servere i det hele tatt. Dette er hva SEC-arkiveringen sier om den manuelle distribusjonsprosessen (BTW hvis det er en SEC-filing om distribusjonen din, kan noe ha gått veldig galt). Under distribusjonen av den nye koden, har imidlertid en av Knights-teknikere ikke kopiert den nye koden til en av de åtte SMARS-dataserverne. Knight hadde ikke en andre tekniker gjennomgå denne distribusjonen, og ingen hos Knight skjønte at Power Peg-koden ikke var fjernet fra den åttende serveren, heller ikke den nye RLP-koden ble lagt til. Knight hadde ingen skriftlige prosedyrer som krevde en slik anmeldelse. SEC Filing Release nr. 70694 16. oktober 2013 Klokka 9:30 Eastern Time den 1. august 2012 åpnet markedene og Knight begynte å behandle bestillinger fra meglerforhandlere på vegne av sine kunder for det nye Retail Liquidity Programmet. De syv (7) serverne som hadde riktig SMARS-distribusjon, begynte å behandle disse ordrene riktig. Ordrer sendt til den åttende serveren utløste det supposable repurposed flagget og brakte tilbake den gamle Power Peg-koden fra de døde. Attack of the Killer Code Zombies Det er viktig å forstå hva den døde Power Peg-koden var ment å gjøre. Denne funksjonaliteten var ment å regne ut aksjene ved hjelp av en overordnet ordre ettersom barnordrer ble henrettet. Power Peg ville instruere systemet til å stoppe rutingen av barnordrer når foreldreordren ble oppfylt. I utgangspunktet ville Power Peg holde orden på barnordrene og stoppe dem når foreldreordren ble fullført. I 2005 flyttet Knight denne kumulative sporingsfunksjonaliteten til et tidligere stadium i kodeutførelsen (dermed fjerner sporing av spor fra Power Peg-funksjonaliteten). Når Power Peg-flagget på den åttende serveren ble aktivert, begynte Power Peg-funksjonaliteten å dirigere barneordrer for utførelse, men det var ikke sporing av antall aksjer mot foreldreordren noe som en endeløs sløyfe. 45 minutter i helvete Tenk deg hva som ville skje hvis du hadde et system som kunne sende automatiserte høyhastighetsordrer til markedet uten å spore for å se om nok bestillinger hadde blitt utført. Ja, det var så ille. Når markedet åpnet klokken 9:30, visste folk raskt at noe var galt. Klokka 9:31 var det åpenbart for mange mennesker på Wall Street at noe alvorlig skjedde. Markedet ble oversvømmet med ordre utenom ordinære for vanlige handelsvolumer på enkelte aksjer. Ved 9:32 mange mennesker på Wall Street lurte på hvorfor det ikke hadde stoppet. Dette var en evighet i høyhastighets handelsvilkår. Hvorfor hadde ikke noen slått drepebryteren på hva som helst system gjorde dette? Det viser seg at det ikke var noen drepebryter. I løpet av de første 45 minutters handel utgjorde Knights henrettelser mer enn 50 av handelsvolumet og kjørte visse aksjer opp over 10 av deres verdi. Som et resultat av dette reduserte andre aksjer i verdi som svar på feilaktige handler. For å gjøre ting verre, begynte Knights-systemet å sende automatiserte e-postmeldinger tidligere på dagen så tidlig som klokken 08:01 (da SMARS hadde behandlet ordrer kvalifisert for markedshandel). E-postmeldingene refererer til SMARS og identifiserte en feil som Power Peg deaktivert. Mellom 8:01 og 9:30 var det 97 av disse e-postene sendt til Knight personell. Selvfølgelig ble disse e-postene ikke utformet som systemvarsler, og derfor så ingen på dem med en gang. Oops. I løpet av 45 minutter av helvete opplevde ridderen at de forsøkte flere motforanstaltninger for å prøve å stoppe de fejlagte handler. Det var ingen drepebryter (og ingen dokumenterte prosedyrer for hvordan man reagerte), så de ble igjen forsøkt å diagnostisere problemet i et levende handelsmiljø der 8 millioner aksjer ble handlet hvert minutt. Siden de ikke var i stand til å bestemme hva som førte til feilaktige ordrer, reagerte de ved å avinstallere den nye koden fra serverne. Det ble distribuert til riktig. Med andre ord fjernet de arbeidskoden og forlot den ødelagte koden. Dette forsterket bare problemene som forårsaket flere foreldreordrer for å aktivere Power Peg-koden på alle servere, ikke bare den som ikke ble distribuert til riktig. Til slutt ble de i stand til å stoppe systemet etter 45 minutters handel. I de første 45 minuttene var markedet åpent, mottok Power Peg-koden og behandlet 212 foreldreordrer. Som et resultat av dette sendte SMARS millioner av barnordrer til markedet, noe som resulterte i 4 millioner transaksjoner mot 154 aksjer for mer enn 397 millioner aksjer. For deg aksjemarkedet junkies betydde dette Knight antatt ca 3,5 milliarder netto lange stillinger i 80 aksjer og 3,15 milliarder netto korte stillinger i 74 aksjer. I laymen8217s ord hadde Knight Capital Group et 460 millioner tap på 45 minutter. Husk, Knight har bare 365 millioner i kontanter og ekvivalenter. På 45 minutter gikk Knight fra å være den største handelsmannen i amerikanske aksjer og en stor markedsfører i NYSE og NASDAQ til konkurs. De hadde 48 timer for å hente kapitalen som var nødvendig for å dekke deres tap (som de klarte å gjøre med en 400 millioner investering fra rundt et halvt dusin investorer). Knight Capital Group ble til slutt kjøpt av Getco LLC (desember 2012) og det fusjonerte selskapet heter nå KCG Holdings. En leksjon å lære Hendelsene 1. august 2012 bør være en leksjon for alle utviklings - og operasjonsteam. Det er ikke nok å bygge bra programvare og teste det, og du må også sørge for at den leveres til markedet riktig slik at kundene får verdien du leverer (og så du ikke konkurs din bedrift). Ingeniøren (e) som distribuerte SMARS, er ikke bare skylden her, prosessen Knight hadde satt opp var ikke hensiktsmessig for risikoen de ble utsatt for. I tillegg var deres prosess (eller mangel derav) iboende utsatt for feil. Hver gang distribusjonsprosessen er avhengig av at mennesker leser og følger instruksjoner, utsetter du deg selv for risiko. Mennesker gjør feil. Feilene kan være i instruksjonene, i tolkningen av instruksjonene, eller i utførelsen av instruksjonene. Utplasseringer må automatiseres og repeteres og som fri for potensiell menneskelig feil som mulig. Had Knight implementert et automatisert distribusjonssystem komplett med konfigurasjon, distribusjon og testautomatisering ville feilen som forårsaket Knightmare vært unngått. Et par prinsipper for kontinuerlig levering gjelder her (selv om du ikke implementerer en full kontinuerlig leveringsprosess): Utgivelse av programvare skal være en repeterbar, pålitelig prosess. Automatiser så mye som er rimelig. Et scenario: Vi antar at de hadde veldig gode DevOps. Så alle servere ville være synkronisert. Men 8211 antar at den nye koden hadde en feil. Så alle servere er synkroniserte, men har samme buggy kode. Hva om to versjoner av koden, dvs. de siste 2 distribusjonene hadde denne feilen. Så snart de innser at noe er galt, ruller de tilbake koden, feilen forblir fortsatt8230 Precious minutter har gått. Kanskje 20 minutter i stedet for 45 minutter i artikkelen din. Så kort sagt 8211 er deres katastrofe-kill-switch en kodeopprullingsplassering i et levende miljø. Det vil fortsatt være en defekt design. Det de trenger trenger, ville være en stor rød bryter (nesten bokstavelig talt, et sted i dashbordet) for å stoppe umiddelbart. Hvor er forretningsregelen som sier at 8220 først gjør ingen skade8221. VJ hvis distribusjonen til alle servere hadde jobbet, ville de vært ok. Men i dette tilfellet ble 7 av 8 for ett delsystem distribuert til riktig. Fordi den dårlige oppførelsen rullet de tilbake de andre 7 tenkte den nye koden i det delsystemet var problemet. Det multipliserte problemet til den endelige dørbryteren. Katastrofer er nesten alltid komplekse. I dette tilfellet var det dårlige kodingspraksis, pluss tvilsom testingskode inspeksjonspraksis, pluss en feil i distribusjon, pluss tilbakekalling av delsystemet i granulariteten i stedet for hele systemet. Hvis du løser noen av disse problemene, får du ikke en katastrofe. En av de tingene jeg har sett i selskaper som ikke anerkjenner den virkelige betydningen og virkningen av deres IT-systemer, er at de don8217t gir budsjett for eldre kodeoppdateringer. For eksempel: I8217ve sett situasjoner der IT har ingen budsjett. Den må rettferdiggjøre alt det gjør mot en forretningsomkostning. Det betyr kontinuerlig å kryptere for å stille opp nye prosjekter. Virksomheten ser sjelden ut behovet for å oppdatere gammel programvare som for tiden fungerer, så de nekter å betale for det. Resultatet er konstant ny kode, laget av de billigste kodene som er mulig, mens de ikke investerer i teknologiene som til slutt vil forbedre ytelsen og redusere risikoen. Hvorfor Fordi disse blir sett på som 8220IT-problemer8221 og ikke hva som helst prosjekt av IT-folkene jobber med, så ingen betaler for det. En god lesning om denne øvelsen er The Phoenix Project av Gene Kim, Kevin Behr og George Spafford. Takk for at du bruker hjernen til sprøytenarkomanen. Sannsynligvis bør man spørre hvorfor de involverte teknikerne fikk ta skylden, men fikk ikke autoritet til å drepe bryteren på egenhånd. Åh, det er hvorfor du legger OpsSRE på plass uansett. 8220R8221 er for ansvarlig, aka flame agn. Jeg har skrevet litt om denne hendelsen, og jeg vil forsiktig at noen bruker SEC-rapporten som noe annet enn hva SEC trengte det for. kitchensoap20131029counterfactuals-ridder-kapital Fascinerende lese. Jeg jobbet på et stort auksjonshus for frukt og grønnsaker en gang der en ny programvareversjon ble installert og mislyktes, noe som førte til store tap for handelsmennene (selv om de ikke var så store som disse). Også dette var et tilfelle av feil utplassering og ingen tilbakelevering. Lærdommen som skal læres er at det er domener hvor datamaskinen ikke bør ta noen avgjørelse uten menneskelig validering. Hva med folkene som mistet jobbene sine fordi, oops, det var en feil Hva med de andre selskapene som kanskje kom seg i stygg på grunn av plutselig endring av aksjeverdien Automasjon av 8220 høyt nivåbeslutninger8221 skal håndteres carefully8230 Nice og pedagogisk post Btw. Bruke Cynefin-rammeverket gir en bedre karakterisering av denne 8216DevOps8217-feilen Dette innlegget synes å ha vært skrevet fra et DevOps-perspektiv. De foreslåtte løsningene er i tråd med et DevOps-perspektiv 8211 undersøke utgivelsesprosessen, automatisere mer og lage en drepekontakt med tilbakekoplingsfunksjoner. Noen kan lese innlegget og legge for mye vekt på Knight-tekniker som ikke kopierte den gamle koden til en av de åtte serverne. Noen kan oversimplisere et årsak og effekt forhold. Noen kan insistere på nye regler for å forhindre dette fra noen gang igjen.8217 En kraftigere tilnærming kan investere i: 8211 Øke mangfoldet for å analysere situasjonen og syntetisere bedre alternativer 8211 Forbedre kommunikasjonen mellom spesialiteter 8211 Forbedre implisitt samordning mellom spesialiteter 8211 Rekruttere personer med mer kompetanse til å skrive og vurdere kode En viktig faktor som begrenset forbedring av lagets evne fra ni år før den betydelige feilhendelsen, var feilaktig karakterisering av systemet. I et Cynefin-rammeverk er det å knytte denne feilen til et DevOps-problem ved å knytte systemet til 8220Obvious8221-domenet der det er enkle årsak og effektrelasjoner som er gjenkjennelige av 8216professionals.8217. Felet bør ikke knyttes til Cynefin 8220Complicated8221-domenet hvor en betydelig analyse av 8216specialists8217 ville ha forhindret feilen. Systemet skal være tilknyttet Cynefin 8220Complex8221 domene 8211 et komplekst adaptivt system. Systemet er disposisjonelt. De samme innledende forholdene vil ikke gi samme feil (unntatt ved et uhell). For mer informasjon om Cynefin, besøk en. wikipedia. orgwikiCynefin og CognitiveEdge. Jeg setter pris på at du fremhever stikkfaktorene i en slik katastrofe. Som forfatteren jobber jeg også i operasjoner, og it8217s er lett å falle inn i de samme gamle tankemønstrene på årsaker og løsninger. Jeg liker spesielt poenget ditt om mangfold (som kommer i alle former: erfaringsnivåer, kulturell og pedagogisk bakgrunn, ferdigheter, alder, etc.), da jeg tror dette er en sterk driver bak suksessen til DevOps selv. Å ha en rekke perspektiver, både innenfor og uten teamet ditt, ser på prosjektet ditt, har sterkt bevisbart potensial, og kan bidra til å bekjempe oversikter som den som er tatt opp i denne artikkelen. gt hvorfor kode som hadde vært død i 8 år, var fortsatt tilstede i kodebase er et mysterium, men det er ikke poenget. Tvert imot er det nøyaktig punktet. Kode med ubrukte, og derfor uprøvde, konfigurasjonsmuligheter er en katastrofe som venter på å skje. Dette er grunnen til at I8217m er veldig skeptisk til funksjon-flaggbaserte tilnærminger generelt. Konfigurasjon er like mye en del av programmet som kode er, og konfigurasjonsendringer skal gå gjennom samme livscyklus 8211 trekkforespørsel, kodeanmeldelse, utgivelse, distribuere til staging 8211 som enhver annen endring. Hvis utgivelsesprosessen din er for tung, og du må gjøre hurtige konfigurasjonsendringer til produksjon, fikser du utgivelsesprosessen. Det var for mange feil å tildele det episke tapet til bare DevOps (selv om jeg helt er enig i at automatisering og testing er den eneste måten): 8211 Ingen samarbeid og sjekklister mens du gjør en oppdatering på produksjonsservere. Enhver oppdatering på produksjonen krever at et lag ser på hverandre og går gjennom en sjekkliste. 8211 8 år ubrukt gammel kode i produksjon. Det forteller deg mye om mangelen på forståelse for risikoen for dangling 8220unused8221 kode. 8211 Utilstrekkelig logging fra koden, og utilstrekkelig sanntids loggovervåking, korrelasjon og analyse. Det ville ha utløst nok ledetråder tidlig til ingeniører og ops folk. 8211 Ingen hot-hot failover til en klynge med forrige versjon. Det ville ha stoppet alle problemer etter 1 eller 2 minutter. (At8217s den røde røde knappen som artikkelen nevner) Hvis du også har vært å bygge programvare, systemer og bedrifter i lang tid, vet du at katastrofe skjer, du vet at noen feil bare fanges i naturen og ikke under simuleringer, akkurat som deg vet maskiner vil gå ned. Du må forberede deg på det verste fallet i begge scenarier. Murphy8217s lov er så sant i vår verden I8217 har vært i det som nå kalles 8220DevOps8221-rommet i nesten 20 år, over halvparten av det i den finansielle verden. Knight var både en leverandør til og en konkurrent av selskapet jeg jobber for. Distribusjonsautomatisering kan ha hjulpet. Kan være. Men få selskaper har råd til nøyaktig dupliserte miljøer, og dette var hovedsakelig forårsaket av miljøforskjeller. Selv automatisert validering av distribusjon har kanskje ikke hjulpet i dette tilfellet hvis automasjonen didn8217t vet om miljøforskjellen. Automatisering er bare like bra som kunnskapen til menneskene som setter opp det. Hvis en manuell installasjon var ikke klar over det gamle systemet, så er det en god sjanse for at det automatiserte systemet wouldn8217t vært kjent for å sjekke det heller. Automatisering av tilbakelevering er også bare like bra som beslutningen om å gjøre tilbakelevering. Og hvis automatiseringen utilsiktet startet det gamle systemet, er det heller ingen garanti for at bytte det moderne systemet tilbake ville ha stoppet det gamle systemet 8211 du kunne ha endt med det samme problemet, selv etter en automatisk tilbakestilling av det moderne systemet. Som bringer meg til et siste punkt: Automatisering er et krav i store, moderne miljøer. Men over-reliance på det kan føre til at folk som kjører systemet er uvitende om hva det gjør. Automatisering er mest nyttig for valideringer, fordi validering av ting er gjort riktig er kjedelig og lett å skimp på når du er ferdig manuelt. Selv når automatisering, med menneskelige involverte bruddpunkter eller menneskedrevne trinn, bidrar det til at de som kjører systemet, kjenner systemet og hvordan det fungerer, forbedrer deres evne til å feilsøke problemer, diagnostisere problemer og gjøre hensiktsmessige forslag til hvilke tiltak du skal ta til stoppe eller avhjelpe et problem. Automatisering er et verktøy, men det er bare ett verktøy og det krever fortsatt en håndverker å bruke den på riktig måte. Ekspertise er det som gjør og holder flotte systemer flotte. Reblogged dette på Garrett S. Y. Hampton og kommenterte: Utrolig. DevOps ser alltid på, dokumenterer og evaluerer distribusjonene dine