Þjóðsögur forritara og verkfræðinga (1. hluti)

Þjóðsögur forritara og verkfræðinga (1. hluti)

Þetta er úrval sagna af netinu um hvernig pöddur hafa stundum alveg ótrúlegar birtingarmyndir. Kannski hefurðu eitthvað að segja líka.

Bílaofnæmi fyrir vanilluís

Saga fyrir verkfræðinga sem skilja að hið augljósa er ekki alltaf svarið og að sama hversu langsótt staðreyndirnar kunna að virðast, þá eru þær samt staðreyndir. Pontiac deild General Motors Corporation barst kvörtun:

Þetta er í annað skiptið sem ég skrifa til þín og ég ásaka þig ekki fyrir að svara ekki, því það hljómar klikkað. Fjölskyldan okkar hefur það fyrir sið að borða ís á hverju kvöldi eftir kvöldmat. Ístegundirnar breytast í hvert skipti og eftir matinn velur öll fjölskyldan hvaða ís hún kaupir og eftir það fer ég út í búð. Ég keypti nýlega nýjan Pontiac og síðan þá hafa ferðir mínar til að fá mér ís orðið vandamál. Þú sérð, í hvert skipti sem ég kaupi vanilluís og kem aftur úr búðinni, þá fer bíllinn ekki í gang. Ef ég kem með einhvern annan ís fer bíllinn í gang án vandræða. Mig langar að spyrja alvarlegrar spurningar, sama hversu heimskulega það hljómar: „Hvað er það við Pontiac sem gerir það að verkum að hann byrjar ekki þegar ég kem með vanilluís, en byrjar auðveldlega þegar ég kem með aðra bragð af ís?“

Eins og þú getur ímyndað þér var deildarforsetinn efins um bréfið. Hins vegar sendi ég verkfræðing til að athuga. Það kom honum á óvart að hann skyldi mæta vel menntaður maður sem bjó á fallegu svæði. Þau sömdu um að hittast strax eftir kvöldmat svo þau gætu farið í búðina í ís. Um kvöldið var þetta vanilla, og þegar þeir komu aftur að bílnum, fór hann ekki í gang.

Vélstjórinn kom þrjú kvöld í viðbót. Í fyrsta skiptið var ísinn súkkulaði. Bíllinn fór í gang. Í seinna skiptið var jarðarberjaís. Bíllinn fór í gang. Þriðja kvöldið bað hann um að fá vanillu. Bíllinn fór ekki í gang.

Af skynsemi neitaði vélstjórinn að trúa því að bíllinn væri með ofnæmi fyrir vanilluís. Því samdi ég við eiganda bílsins að hann myndi halda heimsóknum sínum áfram þar til hann fyndi lausn á vandanum. Og á leiðinni byrjaði hann að skrifa niður: hann skrifaði niður allar upplýsingar, tíma dags, bensíntegund, komu og heimkomu úr búð o.s.frv.

Vélstjórinn áttaði sig fljótlega á því að eigandi bílsins eyddi minni tíma í að kaupa vanilluís. Ástæðan var útsetning vörunnar í versluninni. Vanilluís var vinsælastur og var hann geymdur í sérstökum frysti fremst í búðinni til að auðvelda að finna hann. Og allar hinar tegundirnar voru aftarlega í versluninni og það tók miklu lengri tíma að finna rétta tegundina og borga.

Nú var spurningin fyrir vélstjórann: hvers vegna fór bíllinn ekki í gang ef styttri tími var liðinn frá því að vélin var slökkt? Þar sem vandamálið var tíminn, ekki vanilluís, fann verkfræðingurinn fljótt svarið: þetta var gaslás. Það kom á hverju kvöldi en þegar bíleigandinn eyddi meiri tíma í að leita að ís náði vélin að kólna nægilega vel og fór auðveldlega í gang. Og þegar maðurinn keypti vanilluís var vélin enn of heit og gaslásinn hafði ekki tíma til að leysast upp.

Siðferðileg: Jafnvel alveg brjáluð vandamál eru stundum raunveruleg.

Crash Bandicoot

Það er sárt að upplifa þetta. Sem forritari venst þú því að kenna kóðanum þínum um fyrst, annan, þriðja... og einhvers staðar í tíu þúsundasta sæti kennir þú þýðandanum um. Og neðar á listanum kennir þú nú þegar búnaðinum.

Hér er saga mín um vélbúnaðarvilluna.

Fyrir leikinn Crash Bandicoot skrifaði ég kóða til að hlaða og vista á minniskorti. Fyrir svona sjálfumglaðan leikjaframleiðanda var þetta eins og að ganga í garðinn: Ég hélt að vinnan myndi taka nokkra daga. Hins vegar endaði ég á að kemba kóðann í sex vikur. Á leiðinni leysti ég önnur vandamál, en á nokkurra daga fresti fór ég aftur í þennan kóða í nokkrar klukkustundir. Það var kvöl.

Einkennin leit svona út: þegar þú vistar núverandi spilun leiksins og fer inn á minniskortið, gengur allt næstum alltaf vel... En stundum tæmast lestur eða skrifa aðgerð án augljósrar ástæðu. Stutt upptaka skemmir oft minniskortið. Þegar leikmaður reynir að bjarga tekst honum ekki aðeins að bjarga heldur eyðileggur hann líka kortið. Djöfull.

Eftir smá stund fór framleiðandinn okkar hjá Sony, Connie Bus, að örvænta. Við gátum ekki sent leikinn með þessari villu og sex vikum síðar skildi ég ekki hvað olli vandamálinu. Í gegnum Connie höfðum við samband við aðra PS1 forritara: hefur einhver lent í einhverju svipuðu? Nei. Enginn átti í vandræðum með minniskortið.

Þegar þú hefur engar hugmyndir um kembiforrit er eina aðferðin sem er eftir að „deila og sigra“: fjarlægðu sífellt meiri kóða úr gallaða forritinu þar til það er tiltölulega lítið brot eftir sem veldur enn vandanum. Það er, þú klippir forritið af stykki fyrir stykki þar til sá hluti sem inniheldur gallann er eftir.

En málið er að það er mjög erfitt að skera bita úr tölvuleik. Hvernig á að keyra það ef þú fjarlægðir kóðann sem líkir eftir þyngdarafl? Eða að teikna persónur?

Þess vegna verðum við að skipta út heilum einingum fyrir stubba sem þykjast gera eitthvað gagnlegt, en í raun gera eitthvað mjög einfalt sem getur ekki innihaldið villur. Við verðum að skrifa svona hækjur til að leikurinn virki að minnsta kosti. Þetta er hægt og sársaukafullt ferli.

Í stuttu máli, ég gerði það. Ég fjarlægði fleiri og fleiri kóðastykki þar til ég var skilinn eftir með upphafskóðann sem stillir kerfið til að keyra leikinn, frumstillir flutningsbúnaðinn o.s.frv. Auðvitað gat ég ekki búið til vista og hlaða valmynd á þessu stigi, því ég þyrfti að búa til stubb fyrir allan grafíkkóðann. En ég gæti þykjast vera notandi með því að nota (ósýnilega) vista og hlaða skjáinn og beðið um að vista og síðan skrifað á minniskortið.

Þetta skildi eftir mig lítið stykki af kóða sem var enn með ofangreind vandamál - en það var samt að gerast af handahófi! Oftast virkaði allt vel en einstaka sinnum komu upp gallar. Ég fjarlægði næstum allan leikkóðann, en villan var enn á lífi. Þetta var ráðgáta: kóðinn sem eftir var gerði í rauninni ekki neitt.

Einhvern tíma, líklega um þrjú leytið um nóttina, datt mér í hug. Lestur og ritun (inntak/úttak) aðgerðir fela í sér nákvæma framkvæmdartíma. Þegar þú vinnur með harðan disk, minniskort eða Bluetooth-einingu gerir lágstigskóði sem ber ábyrgð á lestri og ritun það í samræmi við klukkupúlsa.

Með hjálp klukku er tæki sem er ekki beintengt við örgjörvann samstillt við kóðann sem keyrir á örgjörvanum. Klukkan ákvarðar flutningshraðann — hraðann sem gögn eru flutt á. Ef það er rugl við tímasetningar, þá er annað hvort vélbúnaðurinn eða hugbúnaðurinn, eða hvort tveggja, líka ruglað saman. Og þetta er mjög slæmt, vegna þess að gögnin geta skemmst.

Hvað ef eitthvað í kóðanum okkar ruglar tímasetningarnar? Ég athugaði allt sem tengist þessu í prófunarforritskóðanum og tók eftir því að við stilltum forritanlega tímamælinum í PS1 á 1 kHz (1000 ticks á sekúndu). Þetta er frekar mikið; sjálfgefið, þegar stjórnborðið byrjar, keyrir það á 100 Hz. Og flestir leikir nota þessa tíðni.

Andy, leikjaframleiðandinn, stillti teljarann ​​á 1 kHz svo að hreyfingar yrðu reiknaðar út með nákvæmari hætti. Andy hefur tilhneigingu til að fara yfir borð og ef við líkjum eftir þyngdaraflinu gerum við það eins nákvæmlega og mögulegt er!

En hvað ef að flýta tímamælinum hefði einhvern veginn áhrif á heildartímasetningu forritsins og þar með klukkuna sem stjórnar baudratanum fyrir minniskortið?

Ég skrifaði ummæli út tímamæliskóðann. Villan gerðist ekki aftur. En þetta þýðir ekki að við laguðum það, því bilunin átti sér stað af handahófi. Hvað ef ég væri bara heppinn?

Nokkrum dögum síðar gerði ég tilraunir aftur með prófunarprógrammið. Gallinn kom ekki aftur. Ég fór aftur í allan leikjakóðagrunninn og breytti vistunar- og hleðslukóðann þannig að forritanlegur tímamælir myndi núllstilla sig á upprunalegt gildi (100Hz) áður en ég fékk aðgang að minniskortinu og endurstillti síðan aftur í 1kHz. Ekki urðu fleiri hrun.

En hvers vegna gerðist þetta?

Ég fór aftur í prófunarprógrammið. Ég reyndi að finna mynstur í því að villa kom upp með 1 kHz tímamæli. Að lokum tók ég eftir því að villa kemur upp þegar einhver spilar með PS1 stjórnanda. Þar sem ég myndi sjaldan gera þetta sjálfur - hvers vegna þyrfti ég stjórnandi þegar ég prófa vista og hlaða kóða? - Ég tók ekki einu sinni eftir þessari ósjálfstæði. En dag einn beið einn af listamönnunum okkar eftir því að ég kláraði prófunina - ég var líklega að bölva á því augnabliki - og snéri stjórnandanum taugaveiklaðan í höndunum. Villa hefur komið upp. "Bíddu ha?!" Jæja, gerðu það aftur!"

Þegar ég áttaði mig á því að þessir tveir atburðir voru samtengdir gat ég auðveldlega endurskapað villuna: Ég byrjaði að taka upp á minniskortið, færði stjórnandann og eyðilagði minniskortið. Fyrir mér leit þetta út eins og vélbúnaðarvilla.

Ég kom til Connie og sagði henni frá uppgötvun minni. Hún miðlaði upplýsingum til eins af verkfræðingunum sem hannaði PS1. „Ómögulegt,“ svaraði hann, „þetta getur ekki verið vélbúnaðarvandamál. Ég bað Connie að skipuleggja samtal fyrir okkur.

Verkfræðingurinn hringdi í mig og við rifumst á hans brotnu ensku og minni (mjög) brotnu japönsku. Að lokum sagði ég: "Leyfðu mér bara að senda 30 lína prófunarforritið mitt þar sem hreyfing stjórnandans veldur villu." Hann samþykkti það. Sagði að þetta væri tímasóun og að hann væri hræðilega upptekinn við að vinna að nýju verkefni, en myndi gefast upp vegna þess að við værum mjög mikilvægur þróunaraðili fyrir Sony. Ég hreinsaði upp prufuforritið mitt og sendi honum það.

Næsta kvöld (við vorum í Los Angeles og hann í Tókýó) hringdi hann í mig og baðst afsökunar. Þetta var vélbúnaðarvandamál.

Ég veit ekki nákvæmlega hvað villan var, en eftir því sem ég heyrði í höfuðstöðvum Sony, ef þú stillir tímamælirinn á nógu hátt gildi, þá truflaði hann íhluti á móðurborðinu í nágrenni við tímamæliskristallinn. Einn þeirra var flutningshraða stjórnandi fyrir minniskortið, sem einnig stillti flutningshraða fyrir stýringarnar. Ég er ekki verkfræðingur, svo ég gæti hafa klúðrað einhverju.

En niðurstaðan er sú að það var truflun á milli íhluta á móðurborðinu. Og þegar gögn eru send samtímis í gegnum stýringartengi og minniskortstengi með tímamæli sem keyrir á 1 kHz, töpuðust bitar, gögn töpuðust og kortið skemmdist.

Slæmar kýr

Á níunda áratugnum skrifaði leiðbeinandi minn Sergei hugbúnað fyrir SM-1980, sovéskan klón af PDP-1800. Þessi örtölva hefur nýlega verið sett upp á járnbrautarstöð nálægt Sverdlovsk, mikilvægri samgöngumiðstöð í Sovétríkjunum. Nýja kerfið var hannað til að leiða vagna og vöruflutninga. En það innihélt pirrandi villu sem leiddi til tilviljunarkenndra hruna og hruns. Fall kom alltaf þegar einhver fór heim á kvöldin. En þrátt fyrir ítarlega rannsókn daginn eftir virkaði tölvan rétt í öllum handvirkum og sjálfvirkum prófunum. Þetta gefur venjulega til kynna keppnisástand eða einhverja aðra keppnisgalla sem á sér stað við ákveðnar aðstæður. Þreyttur á símtölum seint á kvöldin ákvað Sergei að komast til botns í þessu og fyrst af öllu að skilja hvaða aðstæður í skipunargarðinum leiddu til tölvubilunar.

Í fyrsta lagi safnaði hann tölfræði um öll óútskýrð fall og bjó til línurit eftir dagsetningu og tíma. Mynstrið var augljóst. Eftir að hafa fylgst með í nokkra daga í viðbót áttaði Sergei að hann gæti auðveldlega spáð fyrir um tíma kerfisbilana í framtíðinni.

Hann komst fljótt að því að truflanir urðu aðeins þegar stöðin var að flokka lestarfarm af nautgripum frá norðurhluta Úkraínu og vesturhluta Rússlands á leið í sláturhús í nágrenninu. Þetta var í sjálfu sér undarlegt, vegna þess að sláturhúsinu var útvegað af bæjum sem staðsettir voru miklu nær, í Kasakstan.

Tsjernobyl kjarnorkuverið sprakk árið 1986 og geislavirkt niðurfall gerði nærliggjandi svæði óbyggilegt. Stór svæði í norðurhluta Úkraínu, Hvíta-Rússlands og vesturhluta Rússlands voru menguð. Þar sem Sergei grunaði mikið magn af geislun í vögnunum sem komu, þróaði Sergei aðferð til að prófa þessa kenningu. Íbúum var bannað að hafa skammtamæla, svo Sergei skráði sig með nokkrum hermönnum á járnbrautarstöðinni. Eftir nokkra drykki af vodka tókst honum að sannfæra hermann um að mæla geislunarstigið í einum af grunsamlegu vagnunum. Í ljós kom að magnið var margfalt hærra en eðlilegt gildi.

Ekki nóg með að nautgripirnir gáfu frá sér mikla geislun heldur var magn hans svo hátt að það leiddi til handahófs taps á bitum í minni SM-1800, sem var staðsett í byggingu við hlið stöðvarinnar.

Matvælaskortur var í Sovétríkjunum og yfirvöld ákváðu að blanda Chernobyl kjöti saman við kjöt frá öðrum svæðum landsins. Þetta gerði það að verkum að hægt var að draga úr heildarmagni geislavirkni án þess að tapa verðmætum auðlindum. Eftir að hafa lært um þetta, fyllti Sergei strax út skjöl fyrir brottflutning. Og tölvuhrunið hætti af sjálfu sér þegar geislunarstigið minnkaði með tímanum.

Í gegnum rörin

Einu sinni bjó Movietech Solutions til hugbúnað fyrir kvikmyndahús, hannaðan fyrir bókhald, miðasölu og almenna stjórnun. DOS útgáfan af flaggskipaappinu var nokkuð vinsæl meðal lítilla og meðalstórra kvikmyndahúsakeðja í Norður-Ameríku. Það kemur því ekki á óvart að þegar tilkynnt var um Windows 95 útgáfa, samþætt nýjustu snertiskjáum og sjálfsafgreiðslusölum og búin alls kyns skýrslutólum, varð hún fljótt vinsæl líka. Oftast gekk uppfærslan án vandræða. Starfsfólk upplýsingatækninnar á staðnum setti upp nýjan búnað, flutti gögn og viðskipti héldu áfram. Nema þegar það entist ekki. Þegar þetta gerðist myndi fyrirtækið senda út James, kallaður "Hreinsunarmaðurinn."

Þrátt fyrir að gælunafnið bendi til glæpsamlegrar tegundar, þá er hreinsiefnið bara sambland af leiðbeinanda, uppsetningarforriti og allsherjarviðskiptum. James eyddi nokkrum dögum á síðu viðskiptavinarins til að setja alla íhlutina saman og eyddi síðan nokkrum dögum í viðbót við að kenna starfsfólkinu hvernig á að nota nýja kerfið, leysa öll vélbúnaðarvandamál sem upp komu og í raun hjálpa hugbúnaðinum í gegnum frumbernsku.

Því kemur það ekki á óvart að á þessum erilsömu tímum hafi James mætt á skrifstofuna á morgnana og áður en hann náði skrifborðinu sínu tók framkvæmdastjórinn á móti honum, fullur af koffíni umfram venjulega.

„Ég er hræddur um að þú þurfir að fara til Annapolis, Nova Scotia, eins fljótt og auðið er. Allt kerfið þeirra fór í rúst og eftir nótt af vinnu með verkfræðingum þeirra getum við ekki fundið út hvað gerðist. Það lítur út fyrir að netið hafi bilað á þjóninum. En aðeins eftir að kerfið hafði verið í gangi í nokkrar mínútur.

— Þeir fóru ekki aftur í gamla kerfið? - James svaraði fullkomlega alvarlega, þótt andlega hafi hann rekið upp augun af undrun.

— Nákvæmlega: upplýsingatæknisérfræðingurinn þeirra „breytti forgangsröðun“ og ákvað að fara með gamla netþjóninn sinn. James, þeir settu upp kerfið á sex stöðum og greiddu bara fyrir hágæða stuðning og fyrirtæki þeirra er nú rekið eins og það var á fimmta áratugnum.

James réttaði aðeins úr sér.

— Það er annað mál. Allt í lagi, við skulum byrja.

Þegar hann kom til Annapolis var það fyrsta sem hann gerði að finna fyrsta leikhús viðskiptavinarins sem átti í vandræðum. Á kortinu sem tekið var á flugvellinum leit allt þokkalega út en svæðið í kringum viðkomandi heimilisfang virtist grunsamlegt. Ekki gettó, en minnir á film noir. Þegar James lagði við kantsteininn í miðbænum kom vændiskona að honum. Miðað við stærð Annapolis var hún líklega sú eina í allri borginni. Framkoma hennar leiddi strax hugann að frægu persónunni sem bauð kynlíf fyrir peninga á hvíta tjaldinu. Nei, ekki um Juliu Roberts, heldur um Jon Voight [skírskotun til myndarinnar "Midnight Cowboy" - u.þ.b. braut].

Eftir að hafa sent vændiskonuna áleiðis fór James í bíó. Nærliggjandi svæði hafði batnað, en það gaf samt tilfinningu fyrir að vera niðurbrotið. Ekki það að James hafi haft miklar áhyggjur. Hann hefur áður komið á ömurlega staði. Og þetta var Kanada, þar sem jafnvel þjófar eru nógu kurteisir til að segja „takk“ eftir að hafa tekið veskið þitt.

Hliðarinngangur að kvikmyndahúsinu var í röku húsasundi. James gekk til dyra og bankaði. Fljótlega brakaði það og opnaðist aðeins.

-Ertu hreingerningur? - hás rödd kom innan frá.

- Já, það er ég... ég kom til að laga allt.

James gekk inn í anddyri kvikmyndahússins. Að því er virðist, að hafa ekki annað val, byrjaði starfsfólk að útdeila pappírsmiðum til gesta. Þetta gerði fjárhagsskýrslugerð erfiða, hvað þá áhugaverðari upplýsingar. En starfsfólkið heilsaði James með létti og fór strax með hann í netþjónaherbergið.

Við fyrstu sýn var allt í lagi. James skráði sig inn á netþjóninn og athugaði venjulega grunsamlega staði. Ekkert mál. Hins vegar, af mikilli varkárni, lokaði James netþjóninum, skipti um netkortið og afturkallaði kerfið. Hún hóf strax störf á fullu. Starfsfólkið byrjaði aftur að selja miða.

James hringdi í Mark og tilkynnti honum um ástandið. Það er ekki erfitt að ímynda sér að James gæti viljað halda sig við og sjá hvort eitthvað óvænt gerist. Hann fór niður stigann og fór að spyrja starfsmennina hvað hefði gerst. Augljóslega er kerfið hætt að virka. Þeir slökktu og kveiktu á honum, allt virkaði. En eftir 10 mínútur datt kerfið af.

Á þessari stundu gerðist eitthvað svipað. Allt í einu byrjaði miðakerfið að henda villum. Starfsfólkið andvarpaði og náði í pappírsmiðana og James flýtti sér inn í netþjónaherbergið. Allt leit vel út með netþjóninn.

Þá kom einn starfsmaðurinn inn.

— Kerfið virkar aftur.

James var undrandi vegna þess að hann hafði ekki gert neitt. Nánar tiltekið, ekkert sem myndi láta kerfið virka. Hann skráði sig út, tók upp símann sinn og hringdi í þjónustuver fyrirtækisins. Fljótlega kom sami starfsmaður inn í netþjónaherbergið.

- Kerfið liggur niðri.

James leit á þjóninn. Áhugavert og kunnuglegt mynstur af marglitum formum dansaði á skjánum - óskipulega hrollur og samtvinnuð pípur. Við höfum öll séð þennan skjávara einhvern tíma. Það var fallega gert og bókstaflega dáleiðandi.


James ýtti á takka og mynstrið hvarf. Hann flýtti sér að miðasölunni og hitti á leiðinni starfsmann sem sneri til hans.

— Kerfið virkar aftur.

Ef þú getur gert andlitslyf, þá er það nákvæmlega það sem James gerði. Skjáhvíla. Það notar OpenGL. Og þess vegna, meðan á notkun stendur, eyðir það öllum auðlindum miðlara örgjörvans. Þess vegna lýkur hverju símtali til netþjónsins með tímamörkum.

James sneri aftur í netþjónaherbergið, skráði sig inn og skipti um skjáhvíluna fyrir fallegu pípurnar með auðum skjá. Það er, í stað skjávarans sem eyðir 100% af örgjörvaauðlindum, setti ég upp annan sem eyðir ekki auðlindum. Svo beið ég í 10 mínútur til að athuga ágiskun mína.

Þegar James kom í næsta bíó var hann að velta fyrir sér hvernig hann ætti að útskýra fyrir yfirmanni sínum að hann væri nýbúinn að fljúga 800 km til að slökkva á skjávaranum.

Hrun á ákveðnum áfanga tunglsins

Sönn saga. Dag einn kom upp hugbúnaðarvilla sem var háð tunglfasa. Það var smá rútína sem var almennt notuð í ýmsum MIT forritum til að reikna út nálgun við raunverulegan fasa tunglsins. GLS byggði þessa venju inn í LISP forrit sem, þegar skrá er skrifað, myndi gefa út línu með næstum 80 stöfum að lengd. Það var mjög sjaldgæft að fyrsta línan í skilaboðum yrði of löng og leiddi til næstu línu. Og þegar forritið las þessa skrá síðar, bölvaði það. Lengd fyrstu línunnar var háð nákvæmri dagsetningu og tíma, sem og lengd fasaforskriftarinnar á þeim tíma sem tímastimpillinn var prentaður. Það er að villan var bókstaflega háð tunglfasa!

Fyrsta pappírsútgáfa Jargon skrá (Steele-1983) innihélt dæmi um slíka línu sem leiddi til villunnar sem lýst er, en vélritarinn „lagaði“ hana. Þessu hefur síðan verið lýst sem „tunglfasa“.

Farðu samt varlega með forsendur. Fyrir nokkrum árum fundu verkfræðingar frá CERN (European Center for Nuclear Research) villur í tilraunum sem gerðar voru á Large Electron-Positron Collider. Þar sem tölvur vinna virkan úr því gríðarlega magni af gögnum sem þetta tæki býr til áður en þær sýndu vísindamönnum niðurstöðuna, veltu margir fyrir sér að hugbúnaðurinn væri einhvern veginn viðkvæmur fyrir tunglfasa. Nokkrir örvæntingarfullir verkfræðingar komust til botns í sannleikanum. Skekkjan kom til vegna lítilsháttar breytinga á rúmfræði 27 km langa hringsins vegna aflögunar jarðar á ferð tunglsins! Þessi saga hefur farið inn í eðlisfræði þjóðsögur sem „Hefnd Newtons á eðlisfræði agna“ og dæmi um tengsl einföldustu og elstu eðlisfræðilögmálanna og fullkomnustu vísindalegra hugtaka.

Að skola klósettið stoppar lestina

Besta vélbúnaðarvilla sem ég hef heyrt um var í háhraðalest í Frakklandi. Gallinn leiddi til nauðhemlunar á lestinni, en aðeins ef farþegar voru um borð. Í hverju slíku tilviki var lestin tekin úr notkun, yfirfarin en ekkert fannst. Síðan var hann sendur aftur á línuna og hann stöðvaðist strax.

Í einni eftirlitinu fór verkfræðingur sem var í lestinni á klósettið. Hann skolaði fljótt burt, BÚMM! Neyðarstopp.

Vélstjórinn hafði samband við bílstjórann og spurði:

— Hvað varstu að gera rétt áður en þú bremsaðir?

- Jæja, ég hægði á mér á niðurleiðinni...

Þetta var undarlegt, vegna þess að við venjulega notkun hægir lestin á niðurleiðum tugum sinnum. Lestin hélt áfram og í næstu niðurleið varaði bílstjórinn við:

- Ég ætla að hægja á mér.

Ekkert gerðist.

— Hvað gerðirðu við síðustu hemlun? — spurði bílstjórinn.

- Jæja... ég var á klósettinu...

- Jæja, farðu þá á klósettið og gerðu það sem þú gerðir þegar við förum niður aftur!

Vélstjórinn fór á klósettið og þegar bílstjórinn varaði við: „Ég er að hægja á mér,“ skolaði hann vatnið. Auðvitað stoppaði lestin strax.

Nú gátu þeir endurskapað vandamálið og þurftu að finna orsökina.

Eftir tvær mínútur tóku þeir eftir því að vélbremsufjarstýringarsnúran (lestin var með einn hreyfli í hvorum enda) var aftengdur veggnum á rafmagnsskápnum og lá á genginu sem stýrði segullokanum á klósetttappanum... Þegar gengið var kveikt á, það skapaði truflanir í bremsustrengnum og kerfisvörn gegn bilunum fól í sér einfaldlega neyðarhemlun.

Gáttin sem hataði FORTRAN

Fyrir nokkrum mánuðum tókum við eftir því að nettengingar á meginlandinu [þetta var á Hawaii] voru að verða mjög, mjög hægar. Þetta gæti varað í 10-15 mínútur og svo skyndilega komið aftur. Eftir nokkurn tíma kvartaði kollegi minn við mig að nettengingar á meginlandinu almennt virkar ekki. Hann var með FORTRAN kóða sem þurfti að afrita í vél á meginlandinu, en það gat það ekki vegna þess að "netið hélt ekki nógu lengi til að FTP hleðslunni væri lokið."

Já, það kom í ljós að netbilun varð þegar samstarfsmaður reyndi að FTP skrá með frumkóða í FORTRAN á vél á meginlandinu. Við reyndum að geyma skrána: þá var hún afrituð vel (en markvélin var ekki með upptökubúnað, svo vandamálið var ekki leyst). Að lokum „skiptum“ við FORTRAN kóðanum í mjög litla bita og sendum þá einn í einu. Flest brotin voru afrituð án vandræða, en nokkur stykki fóru ekki framhjá, eða gengu eftir fjölmargir tilraunir.

Þegar við skoðuðum erfiðu kaflana komumst við að því að þeir áttu eitthvað sameiginlegt: þeir innihéldu allir athugasemdarkubba sem byrjuðu og enduðu á línum sem samanstanda af stóru C (eins og samstarfsmaður vildi frekar tjá sig í FORTRAN). Við sendum tölvupóst til netsérfræðinga á meginlandinu og báðum um aðstoð. Auðvitað vildu þeir sjá sýnishorn af skrám okkar sem ekki var hægt að flytja í gegnum FTP... en bréfin okkar bárust ekki til þeirra. Loksins komumst við upp með einfalt lýsahvernig óframseljanlegar skrár líta út. Það virkaði :) [Þorist ég að bæta við dæmi um eina af erfiðu FORTRAN athugasemdunum hér? Sennilega ekki þess virði!]

Á endanum tókst okkur að átta okkur á því. Ný gátt var nýlega sett upp á milli hluta háskólasvæðisins okkar og meginlandsnetsins. Það átti í MIKLU erfiðleikum með að senda pakka sem innihéldu endurtekna bita af hástöfum C! Aðeins nokkrir af þessum pökkum gætu tekið upp allar gáttarauðlindir og komið í veg fyrir að flestir aðrir pakkar komist í gegn. Við kvörtuðum við gáttaframleiðandann... og þeir svöruðu: „Ó, já, þú stendur frammi fyrir villu af endurteknum C! Við vitum nú þegar af honum." Við leystum vandann á endanum með því að kaupa nýja gátt frá öðrum framleiðanda (því fyrrnefnda til varnar gæti vanhæfni til að flytja FORTRAN forrit verið kostur fyrir suma!).

Erfiðir tímar

Fyrir nokkrum árum, þegar ég vann að því að búa til ETL kerfi í Perl til að draga úr kostnaði við 40. stigs klínískar rannsóknir, þurfti ég að vinna um 000 dagsetningar. Tveir þeirra stóðust ekki prófið. Þetta truflaði mig ekki mikið vegna þess að þessar dagsetningar voru teknar úr gögnum frá viðskiptavinum sem kom oft, eigum við að segja, á óvart. En þegar ég athugaði upprunalegu gögnin kom í ljós að þessar dagsetningar voru 1. janúar 2011 og 1. janúar 2007. Ég hélt að villan væri að finna í forritinu sem ég var nýbúinn að skrifa, en það kom í ljós að það voru þegar orðin 30 ár gamall. Þetta kann að hljóma dularfullt fyrir þá sem ekki þekkja til hugbúnaðarvistkerfisins. Vegna langvarandi ákvörðunar annars fyrirtækis um að græða peninga, greiddi viðskiptavinur minn mér fyrir að laga villu sem annað fyrirtæki hafði kynnt fyrir slysni og hitt viljandi. Til að þú skiljir hvað ég er að tala um, þarf ég að tala um fyrirtækið sem bætti við eiginleikanum sem endaði með því að verða að villu, sem og nokkra aðra áhugaverða atburði sem áttu þátt í dularfullu villunni sem ég lagaði.

Í gamla góða daga endurstilltu Apple tölvur stundum dagsetningu sína sjálfkrafa í 1. janúar 1904. Ástæðan var einföld: það notaði rafhlöðuknúna „kerfisklukku“ til að halda utan um dagsetningu og tíma. Hvað gerðist þegar rafhlaðan dó? Tölvur fóru að rekja dagsetninguna eftir fjölda sekúndna frá upphafi tímabils. Með tímaskeiði áttum við við upphaflega viðmiðunardagsetninguna og fyrir Macintoshes var það 1. janúar 1904. Og eftir að rafhlaðan dó var núverandi dagsetning endurstillt á tilgreinda. En hvers vegna gerðist þetta?

Áður notaði Apple 32 bita til að geyma fjölda sekúndna frá upphaflegri dagsetningu. Einn biti getur geymt eitt af tveimur gildum - 1 eða 0. Tveir bitar geta geymt eitt af fjórum gildum: 00, 01, 10, 11. Þrír bitar - eitt gildi af átta: 000, 001, 010, 011, 100 , 101, 110, 111 o.s.frv. Og 32 gæti geymt eitt af 232 gildum, það er 4 sekúndur. Fyrir Apple dagsetningar jafngilti þetta um 294 árum, þannig að eldri Mac-tölvur geta ekki séð um dagsetningar eftir 967. Og ef rafhlaðan kerfisins deyr, er dagsetningin endurstillt í 296 sekúndur frá upphafi tímabilsins og þú þarft að stilla dagsetninguna handvirkt í hvert skipti sem þú kveikir á tölvunni (eða þar til þú kaupir nýja rafhlöðu).

Hins vegar, ákvörðun Apple um að geyma dagsetningar sem sekúndur frá tímabilinu þýddi að við gátum ekki höndlað dagsetningar fyrir tímabilið, sem hafði víðtækar afleiðingar eins og við munum sjá. Apple kynnti eiginleika, ekki galla. Þetta þýddi meðal annars að Macintosh-stýrikerfið var ónæmt fyrir „árþúsundavillunni“ (sem ekki var hægt að segja um mörg Mac-forrit sem höfðu sín eigin dagsetningarkerfi til að sniðganga takmarkanir).

Gjörðu svo vel. Við notuðum Lotus 1-2-3, "drápsforrit" IBM sem hjálpaði til við að koma tölvubyltingunni af stað, þó að Apple tölvur væru með VisiCalc, sem gerði einkatölvuna farsælan. Í sanngirni, ef 1-2-3 hefði ekki birst, hefðu PC-tölvur varla farið í loftið og saga einkatölva hefði getað þróast allt öðruvísi. Lotus 1-2-3 fór rangt með 1900 sem hlaupár. Þegar Microsoft gaf út fyrsta töflureikni sinn, Multiplan, náði hann litlum hlutdeild á markaðnum. Og þegar þeir hófu Excel verkefnið ákváðu þeir ekki aðeins að afrita nafnakerfið fyrir röð og dálka frá Lotus 1-2-3, heldur einnig að tryggja samhæfni villu með því að meðhöndla 1900 vísvitandi sem hlaupár. Þetta vandamál er enn til í dag. Það er að segja að í 1-2-3 var þetta galli en í Excel var þetta meðvituð ákvörðun sem tryggði að allir 1-2-3 notendur gætu flutt inn töflurnar sínar inn í Excel án þess að breyta gögnunum, jafnvel þótt þau væru röng.

En það var annað vandamál. Í fyrsta lagi gaf Microsoft út Excel fyrir Macintosh, sem þekkti ekki dagsetningar fyrir 1. janúar 1904. Og í Excel var 1. janúar 1900 talinn upphaf tímabilsins. Þess vegna gerðu verktaki breytingar þannig að forritið þeirra þekkti tegund tímabilsins og geymdi gögn í sjálfu sér í samræmi við æskilegt tímabil. Microsoft skrifaði meira að segja skýringargrein um þetta. Og þessi ákvörðun leiddi til galla minnar.

ETL kerfið mitt fékk Excel töflureikna frá viðskiptavinum sem voru búnir til á Windows, en einnig var hægt að búa til á Mac. Þess vegna gæti upphaf tímabilsins í töflunni verið annað hvort 1. janúar 1900 eða 1. janúar 1904. Hvernig á að komast að því? Excel skráarsniðið sýnir nauðsynlegar upplýsingar, en flokkunartækið sem ég notaði sýndi það ekki (nú gerir það það) og gerði ráð fyrir að þú þekkir tímabil tiltekinnar töflu. Ég hefði sennilega getað eytt meiri tíma í að skilja Excel tvöfalda sniðið og senda plástur til þáttunarhöfundar, en ég hafði miklu meira að gera fyrir viðskiptavininn, svo ég skrifaði fljótt heuristic til að ákvarða tímabil. Hún var einföld.

Í Excel er hægt að tákna dagsetninguna 5. júlí 1998 á sniðinu "07-05-98" (ónýtt amerískt kerfi), "5. júlí 98", "5. júlí 1998", "5-júlí-98" eða annað snið, annað gagnslaust snið (kaldhæðnislegt nokk, eitt af sniðunum sem mín útgáfa af Excel bauð ekki upp á var ISO 8601). Hins vegar, innan töflunnar, var ósniðin dagsetning geymd sem annað hvort "35981" fyrir tímabil-1900 eða "34519" fyrir tímabil-1904 (tölurnar tákna fjölda daga frá tímabilinu). Ég notaði einfaldlega einfaldan þáttara til að draga árið úr sniðinni dagsetningu og notaði síðan Excel flokka til að draga árið úr ósniðinni dagsetningu. Ef bæði gildin voru mismunandi um 4 ár, þá vissi ég að ég var að nota kerfi með epoch-1904.

Af hverju notaði ég ekki bara sniðnar dagsetningar? Vegna þess að 5. júlí 1998 getur verið sniðið sem "júlí, 98" með mánaðardegi glataður. Við fengum töflur frá svo mörgum fyrirtækjum sem bjuggu þær til á svo marga mismunandi vegu að það var undir okkur komið (í þessu tilfelli, mér) að reikna út dagsetningarnar. Að auki, ef Excel fær það rétt, þá ættum við það líka!

Á sama tíma rakst ég á 39082. Mig minnir að Lotus 1-2-3 hafi talið 1900 hlaupár og þetta var endurtekið af trúmennsku í Excel. Og þar sem þetta bættist einum degi við árið 1900, gætu margar dagsetningarútreikningar verið rangar fyrir þann dag. Það er, 39082 gæti hafa verið 1. janúar 2011 (á Mac) eða 31. desember 2006 (á Windows). Ef „ársþáttarinn minn“ dró árið 2011 út úr sniðnu gildinu, þá er allt í lagi. En þar sem Excel flokkarinn veit ekki hvaða tímabil er verið að nota, þá er það sjálfgefið tímabil 1900, sem skilar árinu 2006. Umsóknin mín sá að munurinn var 5 ár, taldi það vera villu, skráði það og skilaði ósniðnu gildi.

Til að komast í kringum þetta skrifaði ég þetta (gervikóða):

diff = formatted_year - parsed_year
if 0 == diff
    assume 1900 date system
if 4 == diff
    assume 1904 date system
if 5 == diff and month is December and day is 31
    assume 1904 date system

Og svo voru allar 40 dagsetningar teknar á réttan hátt.

Í miðjum stórum prentverkum

Snemma á níunda áratugnum starfaði faðir minn hjá Storage Technology, deild sem nú er hætt, sem bjó til segulbandsdrif og loftkerfi fyrir háhraða segulbandsfóðrun.

Þeir endurhönnuðu drif þannig að þeir gætu haft eitt miðlægt "A" drif tengt við sjö "B" drif og litla stýrikerfið í vinnsluminni sem stjórnaði "A" drifinu gæti falið lestrar- og skrifaðgerðum til allra "B" drifanna.

Í hvert sinn sem drif “A” var ræst var nauðsynlegt að setja diskling í jaðardrifið sem er tengt við “A” til að hlaða stýrikerfinu inn í minni þess. Það var ákaflega frumstætt: tölvuafl var veitt af 8 bita örstýringu.

Markhópurinn fyrir slíkan búnað voru fyrirtæki með mjög stór gagnageymsluhús - banka, verslanakeðjur o.fl. - sem þurftu að prenta mikið af heimilisfangamerkjum eða bankayfirlitum.

Einn viðskiptavinur átti í vandræðum. Í miðju prentverki gæti eitt tiltekið drif „A“ hætt að virka, sem veldur því að allt verkið stöðvast. Til að koma aftur á rekstri drifsins þurfti starfsfólk að endurræsa allt. Og ef þetta gerðist í miðju sex tíma verkefni, þá tapaðist gífurlegur dýr tölvutími og áætlun um alla aðgerðina raskaðist.

Tæknimenn voru sendir frá Storage Technologies. En þrátt fyrir bestu viðleitni þeirra gátu þeir ekki endurskapað villuna við prófunaraðstæður: hún virtist eiga sér stað í miðjum stórum prentverkum. Vandamálið var ekki vélbúnaðurinn, þeir skiptu út öllu sem þeir gátu: vinnsluminni, örstýringu, disklingadrif, alla hugsanlega hluta segulbandsdrifsins - vandamálið var viðvarandi.

Þá hringdu tæknimennirnir í höfuðstöðvarnar og hringdu í sérfræðinginn.

Sérfræðingurinn greip stól og kaffibolla, settist í tölvuherbergið – í þá daga voru herbergi helguð tölvum – og fylgdist með því þegar starfsfólkið stóð í röð í stóru prentverki. Sérfræðingurinn beið eftir bilun - og það gerðist. Allir litu á sérfræðinginn, en hann hafði ekki hugmynd um hvers vegna þetta gerðist. Hann skipaði því að setja starfið aftur í biðröð og allt starfsfólkið og tæknimennirnir sneru aftur til vinnu.

Sérfræðingurinn settist aftur í stólinn og fór að bíða eftir bilun. Um sex klukkustundir liðu og bilunin kom upp. Sérfræðingurinn hafði aftur engar hugmyndir, nema að allt gerðist í herbergi fullt af fólki. Hann skipaði fyrir að hefja verkefnið að nýju, settist aftur og beið.

Við þriðju bilunina tók sérfræðingurinn eftir einhverju. Bilunin átti sér stað þegar starfsmenn skiptu um segulband í erlendum diski. Ennfremur kom bilunin fram um leið og einn starfsmanna gekk í gegnum ákveðna flísa á gólfinu.

Upphækkað gólf var úr álflísum lagðar í 6 til 8 tommu hæð. Fjölmargir vírar frá tölvum lágu undir hækkuðu gólfi til að koma í veg fyrir að einhver stígi óvart á mikilvægan snúru. Flísar voru lagðar mjög þétt til að koma í veg fyrir að rusl kæmist undir upphækkað gólf.

Sérfræðingurinn áttaði sig á því að ein flísanna var aflöguð. Þegar starfsmaður steig á horn þess nudduðust brúnir flísarinnar við aðliggjandi flísar. Plasthlutarnir sem tengdu flísarnar nudduðust líka með þeim sem olli truflanir á kyrrstöðu sem sköpuðu útvarpstruflanir.

Í dag er vinnsluminni mun betur varið fyrir truflunum á útvarpsbylgjum. En á þessum árum var þetta ekki raunin. Sérfræðingurinn áttaði sig á því að þessi truflun truflaði minnið og þar með rekstur stýrikerfisins. Hann hringdi í þjónustuverið, pantaði nýjar flísar, setti þær upp sjálfur og vandamálið hvarf.

Það er háflóð!

Sagan gerðist í miðlaraherbergi, á fjórðu eða fimmtu hæð á skrifstofu í Portsmouth (held ég), á hafnarsvæðinu.

Einn daginn hrundi Unix þjónninn með aðalgagnagrunninum. Þeir endurræstu hann, en hann hélt hamingjusamlega áfram að detta aftur og aftur. Við ákváðum að hringja í einhvern úr stuðningsþjónustunni.

Stuðningsgaurinn... ég held að hann hafi heitið Mark, en það skiptir ekki máli... ég held að ég þekki hann ekki. Það skiptir ekki máli, eiginlega. Við skulum halda okkur við Mark, allt í lagi? Frábært.

Svo nokkrum klukkustundum síðar kom Mark (það er ekki langt frá Leeds til Portsmouth, þú veist), kveikti á netþjóninum og allt virkaði án vandræða. Dæmigerður fjandinn stuðningur, viðskiptavinurinn verður mjög í uppnámi yfir þessu. Mark lítur í gegnum annálaskrárnar og finnur ekkert óviðeigandi. Þannig að Mark fer aftur í lestina (eða hvaða ferðamáta sem hann kom á, það gæti hafa verið halt kýr fyrir allt sem ég veit... alla vega, það skiptir ekki máli, allt í lagi?) og heldur aftur til Leeds, búinn að sóa dagurinn.

Sama kvöld hrynur þjónninn aftur. Sagan er sú sama... þjónninn hækkar ekki. Mark reynir að aðstoða fjarstýrt, en biðlarinn getur ekki ræst þjóninn.

Önnur lest, rúta, sítrónumarengs eða eitthvað annað drasl, og Mark er kominn aftur til Portsmouth. Sjáðu, þjónninn ræsir sig án vandræða! Kraftaverk. Mark eyðir nokkrum klukkustundum í að athuga hvort allt sé í lagi með stýrikerfið eða hugbúnaðinn og heldur af stað til Leeds.

Um miðjan dag hrynur þjónninn (farðu rólega!). Að þessu sinni virðist sanngjarnt að fá inn vélbúnaðarstuðningsfólk til að skipta um netþjóninn. En nei, eftir svona 10 tíma dettur það líka.

Ástandið endurtók sig í nokkra daga. Serverinn virkar, hrynur eftir um 10 tíma og fer ekki í gang næstu 2 tímana. Þeir athugaðu kælingu, minnisleka, þeir athugaðu allt, en fundu ekkert. Svo hættu hrunin.

Vikan leið áhyggjulaus... allir voru ánægðir. Sæl þangað til allt byrjar aftur. Myndin er sú sama. 10 tímar í vinnu, 2-3 tímar í niðri...

Og þá sagði einhver (ég held að þeir hafi sagt mér að þessi manneskja hefði ekkert með IT að gera) sagði:

"Það er sjávarfallið!"

Upphrópunin var mætt með tómum augnaráðum og líklega hikaði hönd einhvers við öryggishringingarhnappinn.

„Það hættir að vinna með straumnum.“

Þetta virðist vera algjörlega framandi hugtak fyrir starfsmenn upplýsingatækniþjónustu, sem eru ólíklegir til að lesa Tide Yearbook á meðan þeir setjast niður í kaffi. Þeir útskýrðu að þetta gæti ekki tengst fjörunni á nokkurn hátt, því þjónninn hefði starfað í viku án bilunar.

„Í síðustu viku var sjávarfallið lágt, en í þessari viku er það mikið.

Smá hugtök fyrir þá sem eru ekki með snekkjuleyfi. Sjávarföll eru háð hringrás tunglsins. Og þegar jörðin snýst, á 12,5 klukkustunda fresti skapar þyngdarkraftur sólar og tungls flóðbylgju. Í upphafi 12,5 stunda hrings er háflóð, í miðri lotunni er él og í lokin kemur aftur háflóð. En þegar braut tunglsins breytist breytist munurinn á flóði og fjöru. Þegar tunglið er á milli sólar og jarðar eða á gagnstæða hlið jarðar (fullt tungl eða ekkert tungl), fáum við Syzygyn fjöru - hæsta fjöru og lægsta fjöru. Við hálft tungl fáum við ferningsfjöru - lægstu sjávarföll. Munurinn á þessum tveimur öfgum minnkar mjög. Tunglhringurinn varir í 28 daga: syzygian - quadrature - syzygian - quadrature.

Þegar tæknimönnunum var útskýrt kjarna sjávarfalla töldu þeir strax að kalla þyrfti á lögregluna. Og alveg rökrétt. En það kemur í ljós að náunginn hafði rétt fyrir sér. Tveimur vikum áður lagðist skemmdarvarg við festar skammt frá skrifstofunni. Í hvert sinn sem sjávarfallið lyfti því upp í ákveðna hæð, endaði ratsjárpóstur skipsins á hæð netþjónsherbergisgólfs. Og ratsjáin (eða rafræn hernaðarbúnaður, eða annað herleikfang) skapaði glundroða í tölvunum.

Flugleiðangur fyrir eldflaugina

Mér var falið að flytja stórt (um 400 þúsund línur) eldflaugaskotstýringu og eftirlitskerfi yfir í nýjar útgáfur af stýrikerfi, þýðanda og tungumáli. Nánar tiltekið, frá Solaris 2.5.1 til Solaris 7, og frá Verdix Ada þróunarkerfinu (VADS), skrifað í Ada 83, til Rational Apex Ada kerfisins, skrifað í Ada 95. VADS var keypt af Rational og varan þess var úreltur, þó að Rational hafi reynt að innleiða samhæfðar útgáfur af VADS-sértækum pökkum til að auðvelda umskipti yfir í Apex þýðanda.

Þrír aðilar hjálpuðu mér að koma kóðanum saman á hreinan hátt. Það tók tvær vikur. Og svo vann ég sjálfur að því að láta kerfið virka. Í stuttu máli var þetta versta arkitektúr og innleiðing hugbúnaðarkerfis sem ég hafði kynnst, svo það tók tvo mánuði í viðbót að klára höfnina. Kerfið var síðan sent til prófunar sem tók nokkra mánuði í viðbót. Ég leiðrétti strax villurnar sem fundust við prófun, en þeim fækkaði fljótt (kóðinn var framleiðslukerfi, svo virkni þess virkaði nokkuð áreiðanlega, ég þurfti bara að fjarlægja villurnar sem komu upp við aðlögun að nýja þýðandanum). Að lokum, þegar allt virkaði eins og það átti að gera, var ég færður yfir í annað verkefni.

Og föstudaginn fyrir þakkargjörð hringdi síminn.

Til stóð að prófa eldflaugarskotið eftir um það bil þrjár vikur og við tilraunir á niðurtalningunni var röð skipana læst. Í raunveruleikanum myndi þetta stöðva prófunina og ef stíflan ætti sér stað innan nokkurra sekúndna frá því að vélin var ræst myndu nokkrar óafturkræfar aðgerðir eiga sér stað í hjálparkerfunum, sem myndi krefjast langrar - og dýrrar - viðbúnaðar eldflaugarinnar. Það hefði ekki byrjað, en margir hefðu verið mjög óhress með tímatapið og mikið, mikið af peningum. Ekki láta neinn segja þér að varnarmálaráðuneytið eyði peningum kæruleysislega - ég hef aldrei hitt verktakastjóra sem setti hvorki fjárhagsáætlunina í fyrsta eða annað, síðan áætlun.

Á undanförnum mánuðum hafði þessi niðurtalningaráskorun verið keyrð hundruð sinnum í mörgum afbrigðum, með aðeins nokkrum minniháttar hiksti. Þannig að líkurnar á því að þetta gerðist voru mjög litlar, en afleiðingar þess voru mjög verulegar. Margfaldaðu báða þessa þætti og þú munt skilja að fréttirnar spáðu eyðilagðri fríviku fyrir mig og tugi verkfræðinga og stjórnenda.

Og athygli var beint að mér sem þeim sem flutti kerfið.

Eins og með flest kerfi sem eru mikilvæg fyrir öryggi, voru margar breytur skráðar, svo það var frekar auðvelt að bera kennsl á þær fáu línur af kóða sem voru keyrðar áður en kerfið hrundi. Og auðvitað var nákvæmlega ekkert óvenjulegt við þá; sömu tjáningar höfðu verið framkvæmdar með góðum árangri bókstaflega þúsundir sinnum á sama hlaupinu.

Við kölluðum fólkið frá Apex inn í Rational vegna þess að það voru þeir sem þróuðu þýðandann og sumar rútínurnar sem þeir þróuðu voru kallaðar inn í grunsamlega kóðann. Þeir (og allir aðrir) voru hrifnir af því að það væri þörf á að ráðast að rótum vandamáls sem bókstaflega mikilvægi þjóðarinnar.

Þar sem ekkert áhugavert var í blöðunum ákváðum við að reyna að endurskapa vandamálið á rannsóknarstofu á staðnum. Þetta var ekki auðvelt verkefni þar sem atburðurinn átti sér stað um það bil einu sinni á 1000 hlaupum. Ein grunuð ástæða var sú að símtal í mutex-aðgerð sem er þróað af seljanda (hluti af VADS-flutningspakkanum) Unlock leiddi ekki til opnunar. Vinnsluþráðurinn sem kallaði aðgerðina afgreiddi hjartsláttarboð, sem að nafninu til bárust á hverri sekúndu. Við hækkuðum tíðnina í 10 Hz, það er 10 sinnum á sekúndu, og byrjuðum að keyra. Um klukkustund síðar læsti kerfið sig. Í skránni sáum við að röð skráðra skilaboða var sú sama og á prófinu sem mistókst. Við tókum fleiri hlaup, kerfið var stöðugt læst 45-90 mínútum eftir ræsingu og í hvert skipti sem loggurinn innihélt sömu leið. Jafnvel þó að við værum tæknilega að keyra annan kóða - tíðni skilaboða var önnur - var hegðun kerfisins sú sama, svo við vorum fullviss um að þessi álagsatburðarás væri að valda sama vandamáli.

Nú þurftum við að finna út hvar nákvæmlega blokkunin átti sér stað í röð tjáninga.

Þessi útfærsla á kerfinu notaði Ada verkefnakerfið og notaði það ótrúlega illa. Verkefni eru á háu stigi samtímis keyrandi smíði í Ada, eitthvað eins og þræðir um framkvæmd, aðeins innbyggt í tungumálið sjálft. Þegar tvö verkefni þurfa að hafa samskipti, "setja þau stefnumót", skiptast á nauðsynlegum gögnum og stöðva síðan stefnumótið og fara aftur í sjálfstæðar aftökur. Hins vegar var kerfið útfært öðruvísi. Eftir að markmiðsverkefni var stefnumót, hittist það markverkefni við annað verkefni, sem síðan hittist við þriðja verkefni, og svo framvegis þar til einhverri vinnslu var lokið. Eftir þetta var öllum þessum stefnumótum lokið og hvert verkefni varð að fara aftur í framkvæmd sína. Það er að segja, við vorum að fást við dýrasta aðgerðasímtalskerfi í heimi, sem stöðvaði allt „fjölverkavinnslan“ á meðan það vann úr hluta inntaksgagnanna. Og áður en þetta leiddi ekki til vandamála aðeins vegna þess að afköst var mjög lágt.

Ég lýsti þessu verkefnakerfi vegna þess að þegar beðið var um stefnumót eða búist við því að ljúka gæti „verkefnaskipti“ átt sér stað. Það er, örgjörvinn gæti byrjað að vinna úr öðru verkefni sem er tilbúið til að framkvæma. Það kemur í ljós að þegar eitt verkefni er tilbúið til að hitta annað verkefni getur allt annað verkefni byrjað að framkvæma og að lokum snýr stjórnin aftur á fyrsta stefnumótið. Og aðrir atburðir geta átt sér stað sem valda því að verkefnið breytist; einn slíkur atburður er kall á kerfisaðgerð, eins og prentun eða framkvæmd mutex.

Til að skilja hvaða kóðalína olli vandamálinu þurfti ég að finna leið til að skrá framfarir í gegnum röð fullyrðinga án þess að kveikja á verkefnarofi, sem myndi koma í veg fyrir að hrun yrði. Svo ég gat ekki nýtt mér það Put_Line()til að forðast að framkvæma I/O aðgerðir. Ég gæti stillt teljarabreytu eða eitthvað álíka, en hvernig get ég séð gildi hennar ef ég get ekki birt hana á skjánum?

Einnig kom í ljós við skoðun á annálnum að þrátt fyrir frystingu í vinnslu hjartsláttarskilaboða, sem hindraði allar I/O aðgerðir ferlisins og kom í veg fyrir að önnur úrvinnsla væri framkvæmd, var haldið áfram að framkvæma önnur sjálfstæð verkefni. Það er, verkið var ekki lokað að öllu leyti, aðeins (mikilvæg) keðja verkefna.

Þetta var vísbendingin sem þurfti til að meta hindrandi tjáningu.

Ég bjó til Ada pakka sem innihélt verkefni, upptalda gerð og alþjóðlega breytu af þeirri gerð. Ótal bókstafir voru bundnir við sérstakar tjáningar á vandræðaröðinni (t.d. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), og setti síðan úthlutunartjáningar inn í það sem úthlutaði samsvarandi upptalningu á alþjóðlega breytu. Þar sem hlutkóði alls þessa geymdi einfaldlega fasta í minni, var afar ólíklegt að skipta um verk vegna framkvæmdar hans. Okkur grunaði fyrst og fremst tjáning sem gæti skipt um verkefni, þar sem lokunin átti sér stað við framkvæmd frekar en að snúa aftur þegar skipt var um verkefni til baka (af ýmsum ástæðum).

Rakningarverkefnið keyrði einfaldlega í lykkju og athugaði reglulega til að sjá hvort gildi alþjóðlegu breytunnar hefði breyst. Við hverja breytingu var gildið vistað í skrá. Svo stutt bið og ný ávísun. Ég skrifaði breytuna í skrána vegna þess að verkefnið var aðeins keyrt þegar kerfið valdi hana til framkvæmdar þegar skipt var um verkefni á vandamálasvæðinu. Hvað sem gerðist í þessu verkefni hefði ekki áhrif á önnur, ótengd lokuð verkefni.

Búist var við að þegar kerfið kæmist á þann stað að keyra vandamálakóðann yrði alþjóðlega breytan endurstillt þegar farið var í hverja næstu tjáningu. Þá gerist eitthvað sem veldur því að verkefnið breytist og þar sem framkvæmdartíðni þess (10 Hz) er lægri en vöktunarverkefnisins gæti skjárinn fanga gildi alþjóðlegu breytunnar og skrifað hana. Í venjulegum aðstæðum gæti ég fengið endurtekna röð af undirmengi talninga: síðustu gildi breytunnar þegar skipt var um verkefni. Þegar hún hangir ætti alþjóðlega breytan ekki lengur að breytast og síðasta gildi sem skrifað er mun gefa til kynna hvaða tjáningu var ekki lokið.

Ég keyrði kóðann með rakningu. Hann fraus. Og eftirlitið gekk eins og í sögu.

Skráin innihélt væntanlega röð, sem var rofin af gildi sem gaf til kynna að mutex hefði verið kallað Unlock, og verkefninu er ekki lokið - eins og raunin er með þúsundir fyrri útkalla.

Apex verkfræðingar voru að greina kóðann sinn með hita á þessum tíma og fundu stað í mutex þar sem fræðilega séð gæti læsing átt sér stað. En líkurnar á því voru mjög litlar, þar sem aðeins ákveðin atburðarrás sem átti sér stað á ákveðnum tíma gæti leitt til lokunar. Lög Murphys, krakkar, það er lögmál Murphys.

Til að vernda kóðann sem ég þurfti, skipti ég út mutex aðgerðaköllunum (byggð ofan á mutex virkni stýrikerfisins) fyrir lítinn innfæddan Ada mutex pakka til að stjórna mutex aðgangi að því stykki.

Ég setti það inn í kóðann og keyrði prófið. Sjö klukkustundum síðar var kóðinn enn að virka.

Kóðinn minn var sendur til Rational, þar sem þeir tóku hann saman, tóku hann í sundur og athugaðu að hann notaði ekki sömu nálgun og notuð var í erfiðu mutex aðgerðunum.

Þetta var fjölmennasta kóðaúttekt á ferlinum mínum 🙂 Það voru um tíu verkfræðingar og stjórnendur í herberginu með mér, aðrir tíu manns voru á símafundi - og þeir skoðuðu allir um 20 línur af kóða.

Kóðinn var skoðaður, nýjar keyranlegar skrár voru settar saman og sendar til formlegrar aðhvarfsprófunar. Nokkrum vikum síðar tókst niðurtalningarprófið og flugflaugin fór í loftið.

Allt í lagi, það er gott og vel, en hver er tilgangurinn með sögunni?

Þetta var algjörlega ógeðslegt vandamál. Hundruð þúsunda lína af kóða, samhliða framkvæmd, yfir tugi víxlverkandi ferla, léleg arkitektúr og léleg útfærsla, viðmót fyrir innbyggð kerfi og milljónir dollara eytt. Engin pressa, ekki satt.

Ég var ekki sá eini sem vann við þetta vandamál, þó ég hafi verið í sviðsljósinu þegar ég var að flytja. En þó að ég hafi gert það, þýðir það ekki að ég hafi skilið allar hundruð þúsunda kóðalínanna, eða jafnvel skimað þær. Kóðinn og annálarnir voru greindir af verkfræðingum um allt land, en þegar þeir sögðu mér tilgátur sínar um orsakir bilunarinnar tók það mig ekki nema hálfa mínútu að hrekja þær. Og þegar ég var beðinn um að greina kenningar, þá sendi ég það áfram til einhvers annars, því mér var augljóst að þessir verkfræðingar voru að fara ranga leið. Hljómar fordómafullt? Já, þetta er satt, en ég hafnaði tilgátunum og beiðnum af annarri ástæðu.

Ég skildi eðli vandans. Ég vissi ekki nákvæmlega hvar það var að gerast eða hvers vegna, en ég vissi hvað var að gerast.

Í gegnum árin hef ég aflað mér mikillar þekkingar og reynslu. Ég var einn af frumkvöðlum þess að nota Ada og skildi kosti þess og galla. Ég veit hvernig Ada runtime bókasöfnin takast á við verkefni og takast á við samhliða framkvæmd. Og ég skil lágt stig forritun á stigi minnis, skráa og assembler. Með öðrum orðum, ég hef djúpa þekkingu á mínu sviði. Og ég notaði þá til að finna orsök vandans. Ég vann ekki bara í kringum villuna, ég skildi hvernig á að finna hana í mjög viðkvæmu keyrsluumhverfi.

Slíkar sögur af baráttu við kóða eru ekki mjög áhugaverðar fyrir þá sem ekki þekkja eiginleika og aðstæður slíkrar baráttu. En þessar sögur hjálpa okkur að skilja hvað þarf til að leysa mjög erfið vandamál.

Til að leysa mjög erfið vandamál þarftu að vera meira en bara forritari. Þú þarft að skilja „örlög“ kóðans, hvernig hann hefur samskipti við umhverfi sitt og hvernig umhverfið sjálft virkar.

Og þá muntu eiga þína eyðilögðu fríviku.

Til að halda áfram.

Heimild: www.habr.com

Bæta við athugasemd