Knight Oppgradering Utløste Old Trading System

Jeg snakket på en konferanse i fjor om emnene DevOps, Configuration as Code, og Continuous Delivery, og brukte følgende historie for å demonstrere viktigheten av implementeringene fullt automatisert 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 vurderer implementeringen din. Knight Capital Group: Har en uheldig dårlig datamaskin slått ned et handelshus Knight Capital Group (Knight) er et handelshus som hjelper andre til å få tilgang til finansmarkeder ved å utføre sine handler. Det tjener som en bestemt markedsmarkør, noe som betyr at den gir buysell-ordrer slik at andre alltid kan utføre en handel mot det, for mer enn 600 verdipapirer på NYSE og NASDAQ børser. Det fungerer også som markedsfører for mange andre verdipapirer. Fordi markedsfremstilling og handel er nøkkelaktiviteter i finansmarkedene, som krever pålitelig og ærlig handel, er det ikke rart at nettstedet har slogan The Standard of Trust. Så hva er en å tenke på hendelsen som fant sted den 1. august, hvor en flurry av handler fra Knight førte til at den akkumulerte en handelsposisjon på 7 milliarder kroner, langt mer enn det kunne opprettholde, noe som førte til en felles innsats for å drive posisjonen ned til et mindre risikabelt nivå I sin rush for å redusere risikoeksponeringen solgte det uunngåelig noen av sine beholdninger billig (også kjent som brannsalg), og endte med å miste 440 millioner. Selv mot standardene for tap som vi har blitt vant til i denne finanskrisen, var det en veldig dårlig dag for Knight. Siden da har Knight vært i stand til å finne investorer med ny kapital på 400 millioner, i det vesentlige samme beløp som det tapte, noe som vil stabilisere firmaet dersom det ikke lider mer katastrofale tap. Det har også undersøkt årsaken til den plutselige økningen i innkjøpsordrer. Her er informasjonen litt uklart, men Wall Street Journal rapporterer en uventet grunn: En oppdatert oppdatering av datasystemer. Hva som synes å ha skjedd, er at de nye datasystemene ble installert og fungerte riktig, men de ble ikke installert på alle handelsplattformer (hvert system må kopieres på tvers av alle handelsplattformer). Dette førte til at gamle systemer handlet på noen plattformer mens nye systemer ble handlet på andre, og tilsynelatende var det de gamle systemene som gikk galt. Nøyaktig hvordan dette er mulig er uklart fordi de gamle systemene tydeligvis hadde fungert godt før, men en mulig årsak er at de gamle systemene ikke lenger postet sine handler til risikostyringssystemet, slik at bidraget fra sin virksomhet til den totale risikoen gikk uoppdaget. Denne forklaringen er spekulativ, men hvis rapportene som det nye systemet fungerte bra er korrekt, tyder den store oppkjøpet av kjøpsordrer på at det må ha vært noen opplysninger som blir tapt fra risikovurderingssystemet. Denne fortellingen om datafeil starter og slutter med menneskelig feil. Folk mislyktes i å installere det nye systemet på tvers av alle handelsplatformene, og folk klarte ikke å stoppe bransjer da NYSE handelsgulvtjenestemenn merket de uvanlige handler og advarte Knight om at det var kilden til uvanlige handelsbevegelser. Men nøkkelpunktet her er at datasystemene var så raske og effektive i arbeidet at det var lite tid å stoppe dem når de kom. Dette er et fenomen som er kjent fra forskning om organisatoriske ulykker. Det er også en stor årsak til forsømmelser, som jeg har notert i arbeid med kollegaene Don Palmer og Jo-Ellen Pozner. I tilfelle av Knight var handlingene utvilsomt så farlig at det er en dom om hvorvidt firmaet har opprettholdt sine plikter for riktig risikostyring (rettssaker, noen). Det vil imidlertid være vanskelig å tildele ansvar fordi disse handlingene var tilfeldig, og ulykken skjedde i grensesnittet mellom raske og defekte datamaskiner, og langsommere mennesker forsøkte å hente seg. Denne historien har tydeligvis viktige leksjoner for hvordan organisasjoner tenker på styring av risiko og kvalitetskontroll, særlig ettersom de gjør flere og flere av deres nøkkelsystemer automatisk. Det er også en påminnelse om at finansmarkeder inneholder menneskelige handelsmenn, som kan være ganske feil i sine vurderinger, og erstatter dem med datamaskiner gjør dommene enda dårligere. Og til slutt, hvis du noen gang har hatt en programvareoppgradering, gå galt, tenk på Knight Capital og hvor mye verre det kunne ha vært: Jeg tviler på at du noen gang har opplevd en datamaskinoppgradering som trakk penger fra bankkontoen din og distribuert den til fremmede. Greve, H. R. Palmer, D. og Pozner, J. 2010. Organisasjoner Gone Wild: Årsakene, prosessene og konsekvensene av organisatorisk mislighold. The Academy of Management Annals. 4: 1, 53 107. Patterson, S. J. Strasburg og J. Bunge. 2012. Knight Upgrade Triggered Old Trading System, store tap. Wall Street Journal. 15.8.2012. Legg til en kommentar Er du allerede medlem Logg inn Henrich R. Greve er professor i entreprenørskap på INSEAD. De fleste delte artikler Hvordan et par indiske sykehus har gjort kostnadsfri kirurgi et bærekraftig helseparadigram. Fremtidssjefen må håndtere tankesett, inkludert hans eller hennes egen. t. co6hUfF9Pbjt t. co7MMvy6RL0B knowledge. insead. edubloginsead-blogintelligent-boards-know-their-limits-5321 via INSEADKnowledge Suksess i ledelsen krever læring så fort som verden endrer seg. - Warren Bennis via INSEADKnowledge Mest populær på appen: Innovating på Intersections t. coNCd8aCXfmU t. coki40D6zX48 knowledge. insead. edumobile-apps via INSEADKnowledge Auke Hunneman. 27.02.2017 kl 01.40 Takk for svaret ditt Steven - Takk for svaret ditt Steven. Steven Sweldens. 27.02.2017 kl. 10.37 Takk Auke, for - Takk Auke, for referansen. Antifragilitet ideen er sikkert relatert, men. Tom Cummings. 27.02.2017 kl. 10.12 Styreleder, Tallberg Foundation - Ron Soonieus legger et viktig poeng på hvordan den foreslåtte fusjonen. jring281. 26.02.2017 klokken 07.17 Fellow INCOSE - Interessant hypotese. To feil kan oppstå når du forsøker å implementere det. 1. Strategi. Praveen Valliavalappil (Will). 24.02.2017 kl 07.48 Direktør - ingeniør - Hei Steve, elsket lese. Veldig godt artikulert. Jeg er enig i at når vi er i. I Spotlight INSEAD Global Leadership Centre tilbyr unik kompetanse som et ledende senter innen forskning og praksis i ledelse og. Et partnerskap mellom INSEAD Knowledge, KnowledgeWharton og World Economic Forum Global Agenda Council på Emerging Market. For å kapitalisere på muligheter som oppstår ved digitalisering, må organisasjoner og ledere omfavne de nye forretningsmessige realitetene. En mørk magi: Stigningen av robothandlerne Bildetekst Trafikksteder: De hektiske forhandlergulvene på 1980-tallet er blitt erstattet av store ranger av dataservere. kan ikke konkurrere om fart, det er så enkelt som det. For ti år siden var John Coates en handelsmann i Wall Street. I dag er han neuroscientist ved Cambridge University, og tilbringer sine dager overvåkingshandlere hormoner for å se hva som gjør dem kryss. Det er enkle tester du kan gjøre. Når du ser et grønt lys. du klikker en mus. Den raskeste du kan gjøre er 100 til 120 millisekunder. Enhver grunnleggende kognitiv prosessering, finne ut ting, kanskje 200 til 300 millisekunder. Problemet er, boksene - forrige gang jeg så - de behandlet en handel på 10 millisekunder, og i dag tror jeg. snakket om milliontedeler av et sekund. Disse boksene er robothandlerne - datamaskiner som tar sine egne beslutninger når de skal kjøpe og selge, men tusen ganger raskere enn noen menneskelig kan. De opererer algos som effektivt etterligner hva handelsmenn pleide å gjøre Remco Lenterman, direktør for handelsfirma IMC. Når du tenker på et handelsgulv i London eller New York, kan du kanskje forestille deg en giggle av svette menn som bøyer hverandre ut av veien som de bruk forseggjorte fingerbevegelser for å formidle sine frantiske ordrer. Dens et bilde populært av 1980-tallet komedie Trading Places. Men det er også 30 år utdatert. For det faktum er at finansiell handel har gjennomgått en datastyrt revolusjon som ligner Amazons overtakelse av High Street. All den virkelige handlingen har flyttet til cyberspace. Ta New York Stock Exchange. I disse dager finner de fleste handel ikke sin berømte neoklassiske fasade like utenfor Wall Street, men i langt mindre glamorøse New Jersey. Det er her NYSE har satt opp et stort elektronisk handelsanlegg som dekker 10 hektar (fire hektar), som ligger på rad av dataservere. Og mange flere hektar er okkupert av serverne til robothandelsfirmaene som er koblet til den. Nerdy brainboxes Datastyrt handel er en iboende hemmelig verden. Handelsfirmaene holder et tett hold på sine handelsstrategier, folk og datakode (eller algoritmer). Ellers kan en rival finne ut sine komplekse, men fullstendig automatiserte handelsmønstre, og deretter kopiere dem, eller enda verre, dumpe sine datamaskiner til å overlevere millioner. Billedtekst Loadersamoney-forhandlerne på 1980-tallet har blitt sendt til søppelbøssen i historien Remco Lenterman, en direktør i et slikt firma, IMC i Nederland, forsøker å demystifisere sin virksomhet. Han sier: I gamle dager, for 10 år siden, ville et skrivebord av aksjehandlere ha mellom 80 og 100 av menneskehandlere på en investeringsbank. I dag er det kanskje åtte av dem igjen. Det de gjør er å operere algos som effektivt etterligner det som handlerne pleide å gjøre, og de tilpasser disse algosene kontinuerlig og overvåker risikoen for hva som skjer i markedet. Med andre ord, de ikoniske høytestosteronene Loadsamoney-handelsmenn fra fortiden - Universitetsmesterne tømt av den amerikanske forfatteren Tom Wolfe i Vanity-bonfireet - har blitt utstødt av quants, de nerdy brainboxes som designer og driver dataprogrammene . I et nylig post-script til sin roman skrevet for Daily Beast. Tom Wolfe beklaget emasculation av sine anti-helter, omdøpe dem Eunuchs of the Universe. Tettere servere, retttere kabler Firmene som Lentermans lager penger ved å skrape en liten fortjenestemargin på et utrolige stort volum av kjøp og salg av raske brann. Ulike algohandlere bruker svært forskjellige strategier. Men de alle deler behovet for å identifisere handelsmuligheter - flyktige avvik mellom den tilgjengelige markedsprisen og hvor datamaskinen mener prisen burde være - og deretter reagere på dem raskere enn noen andre. Race til null Alternativene som er tilgjengelig i fjor for alle som ønsker å sende en elektronisk handelsordre mellom New York og Chicago: Kreves tid for en komplett rundtur Det kalles løp til null. Og det har ført til investering av milliarder dollar i raskere, smartere datamaskiner og i de raskeste mulige tilkoblingene. På børser over hele planeten betaler handelsmenn heftige gebyrer for å co-lokalisere sine servere rett ved siden av børsene. Og hundrevis av millioner har blitt brukt på å bygge rettere kabler for å barbere noen få brøkdeler av en annen tid enn det tar å sende ordrer mellom verdens store handelssentre: London, New York, Chicago og Tokyo. Alt dette kan virke litt irrasjonelt når Storbritannias og amerikanske regjeringer sliter med å skrape sammen nok penger til å oppgradere infrastrukturen som trengs for å ferge mennesker fra ett sted til et annet. Flash Crash Det er imidlertid en mørkere side til dette rushet til datastyring. For eksempel kan ulykker skje. I august i fjor ble det høyteknologiske finansfirmaet Knight Capital bragt i fare for konkurs ved en algoritme som gikk haywire og rakk opp mer enn 440m tap på bare 45 minutter før den ble slått av. Kanskje det mest berømte uhellet var den nå legendariske Flash Crash klokken 14.45 i New York den 6. mai 2010. Om noen få minutter falt New York Børs, og så like plutselig gjenopprettet igjen. Aksjekurser i enkelte firmaer, for eksempel konsulentkontoret Accenture, gikk ned til en brøkdel over null, mens Apple steg til 100 000. For måneder etterpå kunne ingen forklare hva som hadde gått galt. Den offisielle amerikanske forskningsmessige undersøkelsen sa at den hadde blitt utløst av en enkelt ordre, plassert av en stor institusjon, ved hjelp av en algoritmisk handelsstrategi. Men det som gjorde ting langt verre var en varm potetvirkning: I forvirring, en etter en, prøvde robothandlerne å kutte og løpe, og børsens datamaskiner ble oversvømt. Rett håndtering De nye algoritmiske handelsmennene har også blitt anklaget for en ganske gammel skolefarlig oppførsel. Eric Hunsader, av det amerikanske dataanalysfirmaet Nanex, sier at miniatyrversjoner av Flash Crash skjer i enkelte aksjer mange ganger om dagen, og han påstår at mye av det er direkte manipulasjon. Han har laget diagrammer som skildrer merkelig og fantastisk oppførsel av markedene. som datamaskiner forsøker å outfox hverandre ved å raskt generere og deretter kansellere tusenvis av ordrer et sekund. Bildetekst Et Nanex-diagram som illustrerer Google Mini-Flash-krasj 22. april i år Vi tillater at folk får raskere tilkoblinger for å plassere og fjerne tilbud eller bud raskere enn lysets hastighet, kan levere den informasjonen til de andre markedsdeltakere. Og han er ikke den eneste som er bekymret for at noen datastyrte forhandlere kan være så bra. Dessverre er markedernes natur at det alltid er potensial for fornærmende aktivitet, og med veldig rask handel kan disse tingene skje veldig, veldig fort, sier Martin Wheatley, leder av Storbritannias nyopprettede Financial Conduct Authority. Oppriktig, for regulatoren, skaper det et problem å prøve å plukke ut fra den store mengden datahandler som potensielt kan være fornærmende. En Dark Magic, presentert av BBC Business Editor Robert Peston, vil bli sendt på Radio 4 kl 0900 den 8. juli 2013, og vil bli tilgjengelig på BBC iPlayer etterpå. Del denne historien om deling