Hau interneteko istorioen aukeraketa bat da akatsek batzuetan agerpen guztiz sinestezinak izan ohi dituztenei buruz. Agian zuk ere baduzu zerbait kontatzeko.
Autoen alergia bainila izozkiari
Begien bistakoa ez dela beti erantzuna ulertzen duten ingeniarientzako istorio bat, eta gertakariak zeinen urrunak badirudi ere, gertakariak dira oraindik. General Motors Corporation-eko Pontiac Division-ek kexa bat jaso zuen:
Bigarren aldia da zuri idazten dizudana, eta ez dizut leporatzen ez erantzun izanagatik, zoroa dirudielako. Gure familiak afalostean gauero izozkia jateko ohitura du. Aldi bakoitzean izozki motak aldatzen dira, eta afalostean familia osoak aukeratzen du zein izozki erosi, eta ondoren dendara joaten naiz. Duela gutxi Pontiac berri bat erosi nuen eta ordutik izozkiak hartzeko bidaiak arazo bihurtu dira. Ikusten duzu, bainila izozkia erosi eta dendatik itzultzen naizen bakoitzean, autoa ez da martxan jartzen. Beste izozkirik ekartzen badut, autoa arazorik gabe abiarazten da. Galdera serio bat egin nahi dut, ez du axola zein ergela: "Zer da Pontiac ez da abiatzen bainila izozkia ekartzen dudanean, baina erraz hasten da beste izozki-zapore bat ekartzen dudanean?"".
Imajina dezakezuenez, dibisioko presidentea eszeptikoa zen gutunarekin. Hala ere, badaezpada, ingeniari bat bidali nuen egiaztatzeko. Harrituta geratu zen inguru eder batean bizi zen gizon aberats eta ikasia ezagutu zuelako. Afalostean berehala elkartzea adostu zuten, biak izozki dendara joan ahal izateko. Arratsalde hartan bainila zen, eta kotxera itzuli zirenean, ez zen martxan jartzen.
Ingeniaria beste hiru arratsaldetan etorri zen. Lehenengo aldian izozkia txokolatea izan zen. Kotxea abiatu zen. Bigarren aldiz marrubi izozkia zegoen. Kotxea abiatu zen. Hirugarren arratsaldean bainila hartzeko eskatu zuen. Kotxea ez zen martxan jarri.
Arrazionalki arrazoituz, ingeniariak uko egin zion autoa bainila izozkiari alergia zuela sinestea. Horregatik, kotxearen jabearekin adostu nuen bere bisitetan jarraituko zuela arazoari irtenbidea aurkitu arte. Eta bidean, oharrak hartzen hasi zen: informazio guztia idatzi zuen, eguneko ordua, gasolina mota, dendatik heldu eta itzultzeko ordua, etab.
Ingeniaria laster konturatu zen autoaren jabeak denbora gutxiago ematen zuela bainilazko izozkia erosten. Arrazoia dendako salgaien diseinua zen. Banila izozkia zen ezagunena eta izozkailu bereizi batean gordetzen zen dendaren aurrealdean, errazago aurkitu ahal izateko. Eta beste barietate guztiak dendaren atzealdean zeuden, eta askoz denbora gehiago behar izan zen barietate egokia aurkitzeko eta ordaintzeko.
Orain galdera ingeniariarentzat zen: zergatik ez zen autoa martxan jartzen motorra itzali zenetik denbora gutxiago igaro bazen? Arazoa denbora zenez, ez bainila izozkia, ingeniariak azkar aurkitu zuen erantzuna: gas-giltzarrapoa zen. Arratsaldero gertatzen zen, baina autoaren jabeak izozki bila denbora gehiago ematen zuenean, motorra nahikoa hoztea lortu zuen eta erraz martxan jarri zen. Eta gizonak bainila izozkia erosi zuenean, motorra oraindik beroegia zegoen eta gasaren blokeoak ez zuen desegiteko astirik izan.
Morala: Arazo guztiz zoroak ere batzuetan benetakoak dira.
Crash Bandicoot
Mingarria da hau bizitzea. Programatzaile gisa, lehen, bigarren, hirugarren... zure kodea leporatzen ohitzen zara eta hamar milagarren tokian konpilatzaileari leporatzen diozu. Eta zerrendan beherago dagoeneko ekipoari leporatzen diozu.
Hona hemen hardware akatsari buruzko nire istorioa.
Crash Bandicoot jokorako, kodea idatzi nuen memoria-txartel batean kargatzeko eta gordetzeko. Hain joko garatzaile sutsu batentzat, parkean paseo bat bezala zen: lanak hainbat egun beharko zituela uste nuen. Hala ere, sei astez kodea arakatzen amaitu nuen. Bidean, beste arazo batzuk konpondu nituen, baina egun batzuetan kode honetara bueltatzen nintzen ordu batzuetan. Agonia izan zen.
Sintomak honela zeukan: jokoaren uneko playthrough gorde eta memoria-txartelera sartzen zarenean, ia beti dena ondo doa... Baina batzuetan irakurtzeko edo idazteko eragiketak denbora-muga agortzen du arrazoi argirik gabe. Grabaketa labur batek memoria txartela kaltetzen du askotan. Jokalari bat gordetzen saiatzen denean, ez du gordetzeaz gain, mapa suntsitzen du. Zorroa.
Pixka bat igaro ondoren, Sonyko gure ekoizlea, Connie Bus, izutzen hasi zen. Ezin izan dugu jokoa bidali akats honekin, eta sei aste geroago ez nuen ulertzen zerk eragiten zuen arazoa. Connieren bitartez, PS1eko beste garatzaile batzuekin harremanetan jarri ginen: inork aurkitu al du antzekorik? Ez. Inork ez zuen arazorik izan memoria txartelarekin.
Arazketarako ideiarik ez duzunean, geratzen den planteamendu bakarra "zatitu eta konkistatzen" da: kendu programa akastunetik gero eta kode gehiago arazoa eragiten duen zati txiki samarra geratzen den arte. Hau da, programa zatiz zati mozten duzu akatsa duen zatia geratu arte.
Baina kontua da, oso zaila dela bideo-joko bati zatiak moztea. Nola exekutatu grabitatea emulatzen duen kodea kendu baduzu? Edo pertsonaiak marrazten?
Hori dela eta, modulu osoak ordezkatu behar ditugu zerbait baliagarria egiten dutela itxuratzen duten zirriborroekin, baina egia esan akatsik eduki ezin duen zerbait oso sinplea egin behar dugu. Halako makuluak idatzi behar ditugu jolasak gutxienez funtziona dezan. Hau prozesu motela eta mingarria da.
Laburbilduz, egin nuen. Gero eta kode gehiago kendu nituen, sistema jokoa exekutatzeko konfiguratzen duen hasierako kodearekin geratu arte, errendatze-hardwarea hasieratzen duen, etab. Noski, fase honetan ezin izan dut gorde eta kargatu menu bat sortu, kode grafiko guztien zirriborro bat sortu beharko nukeelako. Baina erabiltzaile bat naizela itxuratu nezake gordetzeko eta kargatzeko pantaila (ikusezina) erabiliz eta gordetzeko eskatu eta gero memoria txartelean idazteko.
Horrek goiko arazoa oraindik zeukan kode txiki bat utzi zidan, baina hala ere ausaz gertatzen ari zen! Gehienetan dena ondo funtzionatzen zuen, baina noizean behin akatsak zeuden. Joko-kode ia guztia kendu nuen, baina akatsa bizirik zegoen. Hau harrigarria zen: gainerako kodeak ez zuen ezer egin.
Noizbait, ziurrenik goizeko hirurak aldera, pentsamendu bat bururatu zitzaidan. Irakurtzeko eta idazteko (sarrera/irteera) eragiketek exekuzio-denbora zehatzak dituzte. Disko gogor, memoria-txartel edo Bluetooth modulu batekin lan egiten duzunean, irakurketaz eta idazteaz arduratzen den maila baxuko kodeak erloju-pultsuen arabera egiten du.
Erloju baten laguntzaz, prozesadorera zuzenean konektatuta ez dagoen gailu bat prozesadorean exekutatzen den kodearekin sinkronizatzen da. Erlojuak baud-tasa zehazten du, datuak transferitzen diren abiadura. Denborarekin nahasmena badago, hardwarea edo softwarea, edo biak ere nahasten dira. Eta hori oso txarra da, datuak kaltetu daitezkeelako.
Zer gertatzen da gure kodean zerbaitek denborak nahasten baditu? Probako programaren kodean honekin lotutako guztia egiaztatu nuen eta konturatu nintzen PS1-en tenporizadore programagarria 1 kHz-en (1000 tick segundoko) ezarri genuela. Hau dezente da; lehenespenez, kontsola abiarazten denean, 100 Hz-en exekutatzen da. Eta joko gehienek maiztasun hori erabiltzen dute.
Andyk, jokoen garatzaileak, tenporizadorea ezarri zuen 1 kHz-ra, mugimenduak zehatzago kalkulatzeko. Andyk itsasontzian ibili ohi da, eta grabitatea imitatzen badugu, ahalik eta zehatzen egiten dugu!
Baina zer gertatzen da tenporizadorea bizkortzeak programaren denbora orokorrari nolabait eragingo balu, eta, beraz, memoria txartelaren baud-tasa erregulatzen duen erlojuari?
Tenporizadorearen kodea komentatu nuen. Akatsa ez da berriro gertatu. Baina horrek ez du esan nahi konpondu dugunik, hutsegite ausaz gertatu delako. Zer gertatzen da zortea besterik ez banintz?
Egun batzuk geroago proba-programarekin berriro esperimentatu nuen. Akatsa ez zen errepikatu. Jokoaren kode-base osora itzuli eta gorde eta kargatzeko kodea aldatu nuen, programagarria den tenporizadorea bere jatorrizko baliora (100Hz) berrezarri zedin, memoria-txartelera sartu aurretik, eta gero 1kHz-ra berrezarri. Ez zen istripu gehiago izan.
Baina zergatik gertatu zen hau?
Berriro proba-programara itzuli nintzen. 1 kHz-ko tenporizadore batekin akats bat gertatzean ereduren bat aurkitzen saiatu nintzen. Azkenean ohartu nintzen akatsa norbait PS1 kontrolagailu batekin jokatzen duenean gertatzen dela. Hori gutxitan egingo nukeenez, zergatik beharko nuke kontrolagailu bat gorde eta kargatzeko kodea probatzerakoan? - Ez nuen mendekotasun hori nabaritu ere egin. Baina egun batean gure artistetako bat probak bukatzeko zain zegoen -seguruenik une horretan madarikatzen ari nintzen- eta urduri jarri zuen kontrolagailua eskuetan. Akats bat gertatu da. "Itxaron, zer?!" Tira, egin ezazu berriro!».
Bi gertaera hauek elkarri lotuta zeudela konturatu nintzenean, errorea erraz erreproduzitu nuen: memoria txartelean grabatzen hasi nintzen, kontrolagailua mugitu eta memoria txartela hondatu nuen. Niri hardware akats bat iruditu zitzaidan.
Connierengana etorri eta nire aurkikuntzaren berri eman nion. PS1 diseinatu zuen ingeniarietako bati helarazi zion informazioa. "Ezinezkoa", erantzun zuen, "Ezin da hardware arazo bat izan". Connieri elkarrizketa bat antolatzeko eskatu nion.
Ingeniariak deitu zidan eta eztabaidatu genuen bere ingeles apurtuan eta nire (oso) hautsitako japonieraz. Azkenik, esan nion: "Utzi nire 30 lerroko proba-programa bidaltzeko, non kontrolagailua mugitzeak akats bat eragiten duen". Onartu zuen. Esan zuen denbora galtzea zela eta izugarri lanpetuta zegoela proiektu berri batean lanean, baina amore emango zuela Sonyrentzat oso garatzaile garrantzitsua ginelako. Nire proba-programa garbitu eta hari bidali nion.
Hurrengo arratsaldean (Los Angelesen geunden eta bera Tokion) deitu zidan eta barkamena eskatu zidan. Hardware arazo bat izan zen.
Ez dakit zehazki zein zen akatsa, baina Sonyren egoitzan entzun nuenaren arabera, tenporizadorea nahikoa balio handian ezartzen baduzu, tenporizadorearen kristalaren inguruko plakako osagaiak oztopatu zituen. Horietako bat memoria-txartelerako baud-tasa kontroladore bat zen, kontrolagailuentzako baud-tasa ere ezartzen zuena. Ez naiz ingeniaria, beraz, baliteke zerbait nahasi izana.
Baina ondorioa da plakako osagaien artean interferentziak egon zirela. Eta datuak aldi berean kontroladorearen atakatik eta memoria-txarteleko atakatik 1 kHz-ko tenporizadorearekin martxan jarrita, bitak galdu ziren, datuak galdu ziren eta txartela hondatu zen.
Behi txarrak
1980ko hamarkadan, nire tutoreak Sergei SM-1800rako softwarea idatzi zuen, PDP-11ren klona sobietarra. Mikroordenagailu hau Sverdlovsketik gertu dagoen tren geltoki batean instalatu berri da, SESBko garraio gune garrantzitsu batean. Sistema berria bagoiak eta merkantzien trafikoa bideratzeko diseinatu zen. Baina akats gogaikarri bat zeukan, ausazko hutsegite eta kraskadurak eragin zituena. Erorketak beti gertatzen ziren norbait arratsaldean etxera joaten zenean. Baina hurrengo egunean ikerketa sakona egin arren, ordenagailuak behar bezala funtzionatu zuen eskuzko eta automatikoko proba guztietan. Honek normalean lasterketa-baldintza bat edo baldintza jakin batzuetan gertatzen den beste akats lehiakorren bat adierazten du. Gauean berandu deiez nekatuta, Sergei-k amaierara heltzea erabaki zuen, eta, lehenik eta behin, ulertzea zer nolako egoerak ekarri zuen ordenagailuaren matxura.
Lehenik eta behin, azaldu gabeko erorketa guztien estatistikak bildu zituen eta grafiko bat sortu zuen dataren eta orduaren arabera. Eredua agerikoa zen. Egun batzuk gehiago behatu ondoren, Sergei konturatu zen erraz aurreikus zezakeela sistemaren etorkizuneko akatsen denbora.
Laster jakin zuen etenaldiak geltokiak Ukraina iparraldetik eta Errusia mendebaldetik gertuko hiltegi batera zihoazen tren-kargak sailkatzen zituenean bakarrik gertatu zirela. Hori berez bitxia zen, hiltegia askoz gertuago kokatutako baserriek hornitzen zutelako, Kazakhstanen.
Txernobilgo zentral nuklearrak 1986an eztanda egin zuen, eta erorketa erradioaktiboak inguruko eremuak bizigabe bihurtu zituen. Ukrainako iparraldeko, Bielorrusiako eta Errusiako mendebaldeko eremu zabalak kutsatu ziren. Heltzen ziren bagoietan erradiazio-maila handia susmatuz, Sergeik teoria hori probatzeko metodo bat garatu zuen. Biztanleri debekatuta zegoen dosimetroak izatea, beraz, Sergeik hainbat militarrekin erregistratu zen tren geltokian. Hainbat vodka edan ondoren, soldadu bat konbentzitzea lortu zuen bagoi susmagarrietako batean erradiazio maila neurtzeko. Maila balio normalak baino hainbat aldiz handiagoa zela ikusi zen.
Ganaduak erradiazio asko igortzen ez ezik, bere maila hain altua zenez, geltoki ondoko eraikin batean kokatutako SM-1800-ren memorian bit-galera ausaz galtzea ekarri zuen.
SESBn janari eskasia zegoen, eta agintariek erabaki zuten Txernobylgo haragia herrialdeko beste eskualdeetako haragiarekin nahastea. Horrek erradioaktibitate maila orokorra murriztea ahalbidetu zuen baliabide baliotsuak galdu gabe. Honen berri izan ondoren, Sergeik berehala bete zituen emigraziorako dokumentuak. Eta ordenagailuen hutsegiteek beren kabuz gelditu ziren erradiazio-maila denboran zehar jaitsi zenean.
Hodietatik barrena
Bazen behin, Movietech Solutionsek zinema aretoetarako softwarea sortu zuen, kontabilitate, sarreren salmenta eta kudeaketa orokorrerako diseinatua. Aplikazio enblematikoaren DOS bertsioa oso ezaguna zen Ipar Amerikako zinema-areto txiki eta ertainen artean. Beraz, ez da harritzekoa Windows 95 bertsioa iragarri zenean, azken ukipen-pantailekin eta autozerbitzuko kioskoekin integratuta eta era guztietako txostenak egiteko tresnaz hornituta, azkar ere ezaguna izatea. Gehienetan eguneratzea arazorik gabe joan zen. Bertako IT langileek ekipamendu berriak instalatu, datuak migratu eta negozioak jarraitu zuten. Irauten ez zuenean izan ezik. Hori gertatu zenean, konpainiak James bidaliko zuen, "Garbitzailea" ezizena.
Ezizenak mota gaiztoa iradokitzen badu ere, garbitzailea irakaslea, instalatzailea eta jack-of-all-trades konbinazio bat besterik ez da. Jamesek egun batzuk ematen zituen bezeroaren gunean osagai guztiak bateratzen, eta gero beste egun pare bat ematen zituen langileei sistema berria nola erabiltzen irakasten, sortzen ziren hardware-arazoak konpontzen eta, funtsean, softwareari bere haurtzaroan laguntzen.
Hori dela eta, ez da harritzekoa garai gogor hauetan James bulegora goizean heltzea, eta bere mahaira heldu baino lehen, zuzendariak harrera egitea, ohikoa baino kafeinaz beteta.
"Beldur naiz Annapolisera (Eskozia Berria) joan behar duzula ahalik eta azkarren". Sistema osoa erori zitzaien, eta gau batez ingeniariekin lan egin ondoren, ezin dugu asmatu zer gertatu zen. Badirudi sareak huts egin duela zerbitzarian. Baina sistemak hainbat minutuz martxan egon ondoren.
— Ez al ziren sistema zaharrera itzuli? - Erantzun zuen Jamesek guztiz serio, nahiz eta mentalki harrituta begiak zabaldu zituen.
— Zehazki: bere IT espezialistak "lehentasunak aldatu" zituen eta zerbitzari zaharrekin uztea erabaki zuen. James, sistema sei gunetan instalatu zuten eta premium laguntza ordaindu zuten, eta euren negozioa 1950eko hamarkadan bezala funtzionatzen dute orain.
James apur bat altxatu zen.
- Hori beste kontu bat da. Ados, has gaitezen.
Annapolisera iritsi zenean, egin zuen lehenengo gauza arazoren bat zuen bezeroaren lehen antzokia aurkitzea izan zen. Aireportuan hartutako mapan, denak itxura ona zuen, baina nahi den helbidearen inguruak susmagarria zirudien. Ez ghettoa, baina zinema beltza gogorarazten duena. James hiriguneko ertzean aparkatu zuenean, prostituta bat hurbildu zitzaion. Annapolisen tamaina ikusita, ziurrenik hiri osoko bakarra izango zen. Bere agerpenak berehala ekarri zuen gogora pantaila handian sexua diruaren truke eskaintzen zuen pertsonaia ospetsua. Ez, ez Julia Roberts-i buruz, Jon Voight-i buruz baizik ["Midnight Cowboy" filmari buruzko aipamena - gutxi gorabehera. erreia].
Emagaldua bidera bidalita, James zinemara joan zen. Inguruak hobera egin zuen, baina oraindik hondatuta zegoela ematen zuen. Ez zen James gehiegi kezkatuta zegoenik. Leku tamalgarrietan egon da lehenago. Eta hau izan zen Kanada, non lapurtzaileak ere adeitsuak diren "eskerrik asko" esateko diru-zorroa hartu ondoren.
Zinemako alboko sarrera kalezulo umil batean zegoen. James aterantz joan zen eta jo zuen. Handik gutxira kirrinka egin zuen eta apur bat ireki zen.
-Garbitzailea al zara? - Ahots erdal bat atera zen barrutik.
- Bai, ni naiz... dena konpontzera etorri naiz.
James zinema-aretoan sartu zen. Dirudienez, beste aukerarik ez zutenez, langileak bisitariei paperezko txartelak banatzen hasi ziren. Horrek finantza-txostenak zaildu zituen, are gutxiago xehetasun interesgarriagoak. Baina langileek lasaitasunez agurtu zuten James eta berehala zerbitzari gelara eraman zuten.
Lehen begiratuan, dena ondo zegoen. James zerbitzarian sartu zen eta ohiko leku susmagarriak egiaztatu zituen. Arazorik ez. Hala ere, kontu handiz, Jamesek zerbitzaria itxi zuen, sare-txartela ordezkatu zuen eta sistema atzera bota zuen. Berehala hasi zen oso-osorik lanean. Langileak sarrerak saltzen hasi ziren berriro.
Jamesek Marki deitu zion eta egoeraren berri eman zion. Ez da zaila imajinatzea Jamesek inguruan geratu eta ustekabeko zerbait gertatzen den ikustea. Eskailerak jaitsi eta langileei zer gertatu zen galdetzen hasi zen. Argi dago sistemak funtzionatzeari utzi diola. Piztu eta itzali zuten, dena funtzionatu zuen. Baina 10 minuturen buruan sistema erori egin zen.
Momentu honetan antzeko zerbait gertatu zen. Bat-batean, txartelen sistema akatsak botatzen hasi zen. Langileek hasperen egin zuten eta paperezko txartelak hartu zituzten, eta James zerbitzari gelara joan zen ziztu bizian. Zerbitzariarekin dena ondo ikusten zen.
Orduan, langileetako bat sartu zen.
— Sistema berriro funtzionatzen ari da.
James harrituta zegoen ez zuelako ezer egin. Zehatzago esanda, sistemak funtzionatuko lukeen ezer. Saioa amaitu, telefonoa hartu eta bere konpainiaren laguntza lineara deitu zuen. Handik gutxira langile bera zerbitzari gelara sartu zen.
- Sistema behera dago.
Jamesek zerbitzariari begiratu zion. Kolore anitzeko formen eredu interesgarri eta ezagun bat dantzatu zen pantailan: kaotikoki bihurritu eta tutuak nahastuz. Denok ikusi dugu pantaila-babesle hau noizbait. Ederki errendatu zen eta literalki hipnotizagarria zen.
Jamesek botoi bat sakatu zuen eta eredua desagertu egin zen. Presaka txarteldegira joan zen eta bidean berarengana itzultzen zen langile batekin egin zuen topo.
— Sistema berriro funtzionatzen ari da.
Facepalm mental bat egin dezakezun, horixe da Jamesek egin duena. Pantaila babeslea. OpenGL erabiltzen du. Eta, beraz, funtzionamenduan zehar, zerbitzariaren prozesadorearen baliabide guztiak kontsumitzen ditu. Ondorioz, zerbitzariari egindako dei bakoitza denbora-muga batekin amaitzen da.
James zerbitzari gelara itzuli zen, saioa hasi zuen eta pantaila-babeslea tutu ederrekin ordezkatu zuen pantaila huts batekin. Hau da, prozesadorearen baliabideen %100 kontsumitzen duen pantaila-babesle baten ordez, baliabiderik kontsumitzen ez duen beste bat instalatu dut. Orduan 10 minutu itxaron nituen nire asmakizuna egiaztatzeko.
James hurrengo zinemara iritsi zenean, bere arduradunari nola azaldu 800 km egin berri zituela pantaila-babeslea itzaltzeko galdetzen ari zen.
Istripua ilargiaren fase jakin batean
Benetako istorioa. Egun batean ilargiaren fasearen araberako software-akats bat sortu zen. Ilargiaren benetako fasearekiko hurbilketa kalkulatzeko MITeko hainbat programatan erabili ohi zen errutina txiki bat zegoen. GLS-k errutina hau LISP programa batean eraiki zuen, fitxategi bat idaztean, ia 80 karaktereko denbora-zigilua duen lerroa aterako zuen. Oso arraroa zen mezu baten lehen lerroa luzeegia izatea eta hurrengo lerrora ekartzea. Eta programak fitxategi hau irakurri zuenean, madarikatu egin zuen. Lehen lerroaren luzera data eta ordu zehatzaren araberakoa zen, baita denbora-zigilua inprimatu zen momentuko fasearen zehaztapenaren luzera ere. Hau da, akatsa literalki ilargiaren fasearen araberakoa zen!
Paperezko lehen edizioa (Steele-1983) deskribatutako akatsa ekarri zuen halako lerro baten adibide bat zegoen, baina tipografiagileak "konpondu" zuen. Harrezkero hori "ilargi faseko akatsa" gisa deskribatu da.
Hala ere, kontuz ibili hipotesiekin. Duela urte batzuk, CERNeko (Ikerkuntza Nuklearreko Europako Zentroa) ingeniariek akatsak aurkitu zituzten Elektroi-Positroi Talkatzaile Handian egindako esperimentuetan. Ordenagailuek gailu honek sortzen duen datu kopuru izugarria aktiboki prozesatzen dutenez zientzialariei emaitza erakutsi aurretik, askok espekulatu zuten softwarea nolabait sentikorra zela ilargiaren fasearekiko. Hainbat ingeniari etsituak egiaren hondora iritsi ziren. Akatsa 27 km-ko luzera duen eraztunaren geometrian aldaketa txiki baten ondorioz sortu zen, Ilargia igarotzean Lurraren deformazioaren ondorioz! Istorio hau fisikako folklorean sartu da "Newton's Revenge on Particle Physics" gisa eta fisikaren lege sinpleen eta zaharrenen eta kontzeptu zientifiko aurreratuenen arteko loturaren adibide bat.
Komuna botatzeak trena geldiarazten du
Inoiz entzun dudan hardware akatsik onena Frantziako abiadura handiko tren batean zegoen. Akatsak trenaren larrialdiko balaztatzea ekarri zuen, baina bidaiariak bazeuden bakarrik. Kasu bakoitzean, trena zerbitzutik kanpo atera zuten, egiaztatu zuten, baina ez zen ezer aurkitu. Ondoren, berriro lerrora bidali zuten, eta berehala gelditu zen.
Egiaztapenetako batean, trenean zihoan ingeniari bat komunera joan zen. Laster garbitu zuen, BOOM! Larrialdi geldialdia.
Ingeniaria gidariarekin harremanetan jarri eta galdetu zion:
— Zer egiten ari zinen balaztatu aurretik?
- Beno, jaitsiera moteldu dut...
Arraroa izan zen, funtzionamendu arruntean trena jeitsieran dozenaka aldiz moteltzen delako. Trenak aurrera egin zuen, eta hurrengo jaitsieran gidariak ohartarazi zuen:
- moteldu egingo dut.
Ez zen ezer gertatu.
— Zer egin zenuten azken balaztatzean? - galdetu zuen gidariak.
- Bueno... komunean nengoen...
- Beno, gero komunera joan eta egin duzuna berriro jaisten garenean!
Ingeniaria komunera joan zen, eta gidariak ohartarazi zuenean: «Moteltzen ari naiz», ura bota zuen. Noski, trena berehala gelditu zen.
Orain arazoa erreproduzitu zuten eta kausa aurkitu behar zuten.
Bi minuturen buruan, motorraren balazta urrutiko agintearen kablea (trenak motor bat zeukan mutur bakoitzean) armairu elektrikoaren hormatik deskonektatuta zegoela eta komuneko entxufearen solenoidea kontrolatzen zuen errelean etzanda zegoela... Erreleak noiz aktibatuta zegoen, balazta-kablean interferentziak sortu zituen, eta sistemaren hutsegiteen aurkako babesak larrialdiko balaztatzea besterik ez zuen sartzen.
FORTRAN gorroto zuen atea
Duela hilabete batzuk konturatu ginen penintsulako [hau Hawaiin] sareko konexioak oso-oso moteltzen ari zirela. Horrek 10-15 minutu iraun dezake eta bat-batean berriro gertatuko da. Denbora pixka bat igaro ondoren, nire lankideak kexatu egin zidan penintsulako sare konexioak direla oro har ez dabil. Penintsulako makina batean kopiatu beharreko FORTRAN kode batzuk zituen, baina ezin izan zuen, "sareak ez zuelako nahikoa iraun FTP karga osatzeko".
Bai, sareko hutsegiteak gertatu ziren lankide bat FORTRANen iturburu-kodea duen fitxategi bat kontinenteko makina batera FTP egiten saiatu zenean. Fitxategia artxibatzen saiatu ginen: gero ondo kopiatu zen (baina xede-makinak ez zuen deskonpaktatzailerik, beraz, arazoa ez zen konpondu). Azkenik FORTRAN kodea oso zati txikitan "zatitu" dugu eta banan-banan bidali ditugu. Zati gehienak arazorik gabe kopiatu ziren, baina pieza batzuk ez ziren pasatu, edo ondoren pasatu ziren ugari saiakerak.
Pasarte problematikoak aztertu genituenean, zerbait komunean zutela aurkitu genuen: denek C maiuskulaz osatutako lerroekin hasi eta amaitzen ziren iruzkin-blokeak zituzten (lankide batek FORTRANen komentatu nahiago zuen bezala). Penintsulako sareko adituei posta elektronikoz bidali genien eta laguntza eskatu genuen. Jakina, FTP bidez transferitu ezin ziren gure fitxategien laginak ikusi nahi zituzten... baina gure gutunak ez zitzaizkien iristen. Azkenik sinple bat asmatu dugu deskribatzeatransferiezinak diren fitxategiak nolakoak diren. Funtzionatu zuen :) [Ausartzen al naiz hemen FORTRAN iruzkin arazotsuetako baten adibide bat gehitzen? Seguruenik ez du merezi!]
Azkenean asmatu genuen. Duela gutxi atebide berri bat instalatu da gure campusaren eta penintsulako sarearen artean. Zailtasun HANDIAK izan zituen C maiuskularen zati errepikatuak zituzten paketeak transmititzeko! Pakete horietako gutxi batzuek atebide-baliabide guztiak har ditzakete eta beste pakete gehienak sartzea eragotzi. Atebidearen fabrikatzaileari kexatu genion... eta erantzun ziguten: “A, bai, errepikatutako C akats baten aurrean zaude! Dagoeneko badakigu haren berri». Azkenean arazoa konpondu genuen beste fabrikatzaile bati pasabide berri bat erosiz (lehenengoaren defentsan, FORTRAN programak transferitzeko ezintasuna abantaila izan daiteke batzuentzat!).
Garai gogorrak
Duela urte batzuk, 40. faseko entsegu klinikoen kostuak murrizteko Perlen ETL sistema bat sortzeko lanean ari nintzenean, 000 data inguru prozesatu behar izan nituen. Horietako bik ez zuten proba gainditu. Horrek ez ninduen gehiegi kezkatzen, data hauek bezeroek emandako datuetatik hartuak baitziren, askotan, esango dugu, harrigarriak izan zirenak. Baina jatorrizko datuak egiaztatu ditudanean, data hauek 1ko urtarrilaren 2011a eta 1ko urtarrilaren 2007a zirela konturatu nintzen. Idatzi berri nuen programan akatsa zegoela uste nuen, baina jada 30 urte zirela. zaharra. Software ekosistema ezagutzen ez dutenentzat misteriotsua izan daiteke honek. Beste konpainia batek dirua irabazteko aspaldiko erabakia dela eta, nire bezeroak konpainia batek ustekabean eta besteak nahita sartutako akats bat konpontzeko ordaindu zidan. Zertaz ari naizen ulertzeko, akats bat bihurtu zen funtzioa gehitu zuen enpresari buruz hitz egin behar dut, baita konpondu nuen akats misteriotsuan lagundu zuten beste gertaera interesgarri batzuez ere.
Garai onetan, Appleko ordenagailuek 1ko urtarrilaren 1904era berez berrezartzen zuten batzuetan. Arrazoia sinplea zen: bateriaz elikatzen den "sistemako erlojua" erabiltzen zuen data eta orduaren jarraipena egiteko. Zer gertatu zen bateria hiltzean? Ordenagailuak dataren jarraipena egiten hasi ziren aro bat hasi zenetik segundo kopuruaren arabera. Garaiz erreferentziazko jatorrizko data esan nahi genuen, eta Macintoshentzat 1ko urtarrilaren 1904a zen. Eta bateria hil ondoren, uneko data zehaztutakora berrezarri zen. Baina zergatik gertatu zen hau?
Aurretik, Applek 32 bit erabiltzen zituen jatorrizko datatik zenbat segundo ziren gordetzeko. Bit batek bi balioetako bat gorde dezake - 1 edo 0. Bi bitek lau balioetako bat gorde dezakete: 00, 01, 10, 11. Hiru bit - zortzitik balio bat: 000, 001, 010, 011, 100 , 101, 110, 111, etab. Eta 32k 232 balioetako bat gorde lezake, hau da, 4 segundo. Apple datetarako, 294 urte ingurukoa da, beraz, Mac zaharrek ezin dituzte kudeatu 967tik aurrerako datak. Eta sistemaren bateria hiltzen bada, data 296 segundora berrezartzen da garaia hasi zenetik, eta eskuz ezarri behar duzu data ordenagailua pizten duzun bakoitzean (edo bateria berria erosi arte).
Hala ere, Apple-k datak arotik segundotan gordetzeko erabakiak esan zuen ezin genituzkeela aroaren aurreko datak prozesatu, eta horrek ondorio handiak izan zituen, ikusiko dugunez. Apple-k funtzio bat aurkeztu zuen, ez akats bat. Besteak beste, horrek esan nahi zuen Macintosh sistema eragilea "milurteko akats"aren aurrean immunea zela (ezin zen esan murrizketak saihesteko data-sistema propioak zituzten Mac aplikazio askori buruz).
Segi aurrera. Lotus 1-2-3 erabili genuen, IBMren "hiltzaileen aplikazioa" PCaren iraultza abiarazten lagundu zuena, nahiz eta Apple ordenagailuek VisiCalc zuten, eta horrek ordenagailu pertsonala arrakasta izan zuen. Zintzotasunez, 1-2-3 agertu ez balitz, ordenagailuak nekez aterako ziren, eta ordenagailu pertsonalen historia oso ezberdin garatu zitekeen. Lotus 1-2-3-k gaizki tratatu zuen 1900. urte bisurte gisa. Microsoft-ek bere lehen kalkulu-orria kaleratu zuenean, Multiplan, merkatuaren zati txiki bat hartu zuen. Eta Excel proiektua abiarazi zutenean, Lotus 1-2-3-tik errenkada eta zutabeen izen-eskema kopiatzeaz gain, akatsen bateragarritasuna bermatzea erabaki zuten 1900 urte bisurte gisa nahita tratatuz. Arazo hau gaur egun ere existitzen da. Beraz, 1-2-3-n akats bat izan zen, baina Excel-en erabaki kontzientea izan zen 1-2-3 erabiltzaile guztiek beren taulak Excel-era inporta zezaketen datuak aldatu gabe, nahiz eta oker egon.
Baina beste arazo bat zegoen. Lehenik eta behin, Microsoft-ek Macintosherako Excel kaleratu zuen, 1ko urtarrilaren 1904a baino lehenagoko datak ezagutzen ez zituena. Eta Excel-en, 1eko urtarrilaren 1900a garaiaren hasieratzat hartu zen. Hori dela eta, garatzaileek aldaketa bat egin zuten beren programak aro mota ezagutu eta nahi den garaiaren arabera bere baitan gordetzeko datuak. Microsoft-ek horri buruzko azalpen artikulu bat ere idatzi zuen. Eta erabaki honek nire akatsa ekarri zuen.
Nire ETL sistemak Windows-en sortu ziren bezeroen Excel kalkulu-orriak jaso zituen, baina Mac-en ere sor litezke. Beraz, taulako aroaren hasiera 1eko urtarrilaren 1900a edo 1ko urtarrilaren 1904a izan liteke. Nola jakin? Excel fitxategi-formatuak beharrezko informazioa erakusten du, baina nik erabili nuen analizatzaileak ez zuen erakutsi (orain bai), eta taula zehatz baten garaia ezagutzen duzula suposatu zuen. Seguruenik denbora gehiago eman nezakeen Excel formatu bitarra ulertzen eta adabaki bat bidaltzen analizatzaile-egileari, baina askoz gehiago egin behar nuen bezeroarentzat, beraz, azkar idatzi nuen heuristiko bat garaia zehazteko. Sinplea zen.
Excel-en, 5ko uztailaren 1998eko data "07-05-98" (alferrikako sistema amerikarra), "Uztailaren 5, 98", "Uztailaren 5, 1998", "5-Uztaila" edo "98-8601-35981" formatuan irudika daiteke. beste formatu bat, alferrikako beste formatu bat (ironiaz, nire Excel-en bertsioak eskaintzen ez zuen formatuetako bat ISO 1900 zen). Hala ere, taularen barruan, formatu gabeko data "34519" gisa gorde zen 1904 arorako edo "4" 1904 arorako (zenbakiek arotik igarotako egun kopurua adierazten dute). Analizatzaile soil bat erabili dut urtea formateatutako datatik ateratzeko, eta, ondoren, Excel analizatzailea erabili dut formateatu gabeko datatik urtea ateratzeko. Bi balioak XNUMX urtetan desberdinak baziren, orduan banekien sistema bat erabiltzen ari nintzela epoch-XNUMX.
Zergatik ez ditut formateatutako datak erabili? 5ko uztailaren 1998a "98ko uztaila" gisa formatu daitekeelako hilabeteko eguna galduta. Hainbeste era ezberdinetan sortu zituzten hainbat enpresen taulak jaso genituen, non gure esku zegoen (kasu honetan, ni) datak zehaztea. Gainera, Excel-ek ondo egiten badu, guk ere bai!
Aldi berean, 39082rekin topo egin nuen. Gogora dezadan Lotus 1-2-3-k 1900 urte bisurtetzat hartzen zuela, eta Excel-en zintzo errepikatu zela. Eta horrek 1900. urteari egun bat gehitu dionez, datak kalkulatzeko funtzio asko oker egon litezke egun horretarako. Hau da, 39082 1ko urtarrilaren 2011ekoa (Mac-etan) edo 31ko abenduaren 2006koa (Windows-en) izan zitekeen. Nire "urteko analizatzailea" 2011 urtea formateatutako baliotik atera badu, dena ondo dago. Baina Excel analizatzaileak ez dakienez zein garai erabiltzen ari den, lehenetsita epoch-1900 da, 2006 urtea itzuliz. Nire aplikazioak aldea 5 urtekoa zela ikusi zuen, erroretzat jo zuen, erregistratu zuen eta formateatu gabeko balio bat itzuli zuen.
Honi aurre egiteko, hau idatzi nuen (pseudokode):
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
Eta gero 40 data guztiak behar bezala analizatu ziren.
Inprimatze-lan handien erdian
1980ko hamarkadaren hasieran, nire aitak Storage Technologyn lan egin zuen, orain desagertuta dagoen dibisioan, zinta unitateak eta abiadura handiko zintak elikatzeko sistema pneumatikoak sortu zituen.
Unitateak birdiseinatu zituzten, "A" unitate zentral bat zazpi "B" unitatetara konektatuta izan zezaten, eta "A" diskoa kontrolatzen zuen RAM OS txikiak irakurtzeko eta idazteko eragiketak "B" unitate guztiei delega zitzakeen.
"A" unitatea abiarazten zen bakoitzean, "A"-ra konektatutako unitate periferikoan diskete bat sartzea beharrezkoa zen sistema eragilea bere memorian kargatzeko. Oso primitiboa zen: konputazio-potentzia 8 biteko mikrokontrolagailu batek ematen zuen.
Ekipamendu horien xede-hartzailea datu biltegi oso handiak zituzten enpresak ziren -bankuak, txikizkako kateak, etab.- helbide-etiketa edo banku-laburpen asko inprimatu behar zituztenak.
Bezero batek arazo bat izan zuen. Inprimatze-lan baten erdian, "A" unitate jakin batek funtzionatzeari utziko dio, lan osoa gelditzea eraginez. Diskoaren funtzionamendua berrezartzeko, langileek dena berrabiarazi behar izan zuten. Eta hori sei orduko zeregin baten erdian gertatu bazen, orduan ordenagailuko denbora garestia galtzen zen eta eragiketa osoaren ordutegia eten egin zen.
Biltegiratze Teknologietatik bidali zituzten teknikariak. Baina ahaleginak egin arren, ezin izan zuten akatsa proba-baldintzetan erreproduzitu: inprimatze-lan handien erdian gertatzen zela zirudien. Arazoa ez zen hardwarea izan, ahal zuten guztia ordezkatu zuten: RAM, mikrokontroladorea, diskete-unitatea, zinta-unitatearen zati imajinagarri guztiak - arazoak iraun zuen.
Orduan, teknikariek egoitzara deitu eta Adituari deitu zioten.
Adituak aulki bat eta kafe bat hartu, informatika gelan eseri zen —garai haietan ordenagailuei eskainitako gelak zeuden— eta langileek inprimaketa lan handi bat ilaran jartzen zutela ikusi zuen. Aditua hutsegite bat gertatuko zenaren zain zegoen, eta hala egin zuen. Denek adituari begiratu zioten, baina ez zekien zergatik gertatu zen hori. Beraz, lana berriro ilaran jartzeko agindu zuen, eta langile eta teknikari guztiak lanera itzuli ziren.
Aditua berriro aulkian eseri zen eta hutsegite baten zain hasi zen. Sei ordu inguru pasa ziren eta hutsegitea gertatu zen. Adituak berriro ez zuen ideiarik, dena jendez betetako gela batean gertatu zela izan ezik. Misioa berrabiarazteko agindu zuen, berriro eseri eta itxaron zuen.
Hirugarren hutsegiterako, adituak zerbait nabaritu zuen. Hutsegitea langileek disko atzerriko zintak aldatu zituztenean gertatu zen. Gainera, hutsegitea langileetako bat lurreko baldosa jakin batetik igaro bezain laster gertatu zen.
Altxatutako zorua 6 eta 8 zentimetro arteko altueran jarritako aluminiozko baldosekin egina zegoen. Ordenagailuen hari ugari zoru altxatuaren azpian pasatzen ziren inork ustekabean kable garrantzitsu bat zapal ez zezan. Baldosak oso estu jarri ziren hondakinak zoru altxatuaren azpian ez sartzeko.
Fitxetako bat deformatuta zegoela konturatu zen aditua. Langile batek bere izkina zapaltzen zuenean, fitxaren ertzak ondoko fitxak igurzten zituen. Fitxak lotzen zituzten plastikozko piezak ere haiekin igurtzi zituzten, eta horrek irrati-maiztasun interferentziak sortzen zituzten mikrodeskarga estatikoak eragiten zituzten.
Gaur egun, RAM askoz hobeto babestuta dago irrati-maiztasunaren interferentziatik. Baina urte haietan ez zen horrela. Aditua konturatu zen interferentzia horrek memoria eten zuela, eta horrekin batera sistema eragilearen funtzionamendua. Laguntza zerbitzura deitu zuen, fitxa berriak eskatu, berak jarri zituen eta arazoa desagertu zen.
Itsasgora da!
Istorioa zerbitzari gela batean gertatu zen, Portsmouth-eko bulego baten laugarren edo bosgarren solairuan (uste dut), kai eremuan.
Egun batean datu-base nagusia zuen Unix zerbitzaria huts egin zuen. Berrabiarazi zioten, baina pozik jarraitu zuen behin eta berriro erortzen. Laguntza zerbitzutik norbait deitzea erabaki genuen.
Laguntzako mutila... Uste dut Mark izena zuela, baina horrek ez du axola... Ez dut uste ezagutzen dudanik. Berdin du, benetan. Jarrai gaitezen Markekin, ados? Bikaina.
Beraz, ordu batzuk geroago Mark iritsi zen (Leedsetik Portsmouthera ez dago oso urrun, badakizu), zerbitzaria piztu eta dena arazorik gabe funtzionatu zuen. Laguntza madarikatu tipikoa, bezeroa oso haserretzen da honekin. Markek erregistro-fitxategietan begiratu eta ez du ezer txarrik aurkitzen. Beraz, Mark trenera itzuliko da (edo iritsi zen edozein garraiobidetan, behi herren bat izan zitekeen nik dakidala... dena den, berdin du, ados?) eta Leedsera itzuliko da, alferrik galduta. eguna.
Arratsalde horretan bertan zerbitzariak huts egiten du berriro. Istorioa berdina da... zerbitzaria ez da altxatzen. Mark urrunetik laguntzen saiatzen da, baina bezeroak ezin du zerbitzaria abiarazi.
Beste tren bat, autobusa, limoi meringa edo beste txorakeriaren bat, eta Mark Portsmouth-era itzuli da. Begira, zerbitzariak arazorik gabe abiarazten du! Miraria. Markek hainbat ordu ematen ditu sistema eragilearekin edo softwarearekin dena ondo dagoela egiaztatzen eta Leedsera abiatzen da.
Egunaren erdialdean zerbitzariak huts egiten du (lasai ibili!). Oraingoan arrazoizkoa dirudi hardware-laguntzako jendea ekartzea zerbitzaria ordezkatzeko. Baina ez, 10 bat ordu igaro ondoren ere erortzen da.
Egoera errepikatu zen hainbat egunez. Zerbitzariak funtzionatzen du, 10 ordu inguru igaro ondoren huts egiten du eta ez da abiarazten hurrengo 2 orduetan. Hoztea, memoria ihesak egiaztatu zituzten, dena egiaztatu zuten, baina ez zuten ezer aurkitu. Orduan istripuak gelditu ziren.
Astea arduragabe pasa zen... denak pozik. Zoriontsu dena berriro hasi arte. Irudia berdina da. 10 ordu lan, 2-3 ordu geldialdiak...
Eta orduan norbaitek (uste dut esan zidala pertsona horrek ez zuela zerikusirik ITekin) esan zuen:
— Marea da!
Harridura begirada hutsekin jaso zen, eta norbaiten eskuak ziurrenik zalantzarik izan zuen segurtasun-deiaren botoian.
«Marearekin lan egiteari uzten dio».
Kontzeptu guztiz arrotza dela irudituko litzaieke IT laguntzako langileentzat, nekez irakurriko baitute Marea Urtekaria kafea hartzen eserita. Honek inolaz ere marearekin zerikusirik ezin duela azaldu dute, zerbitzariak astebete zeramatzan lanean hutsegiterik gabe.
"Aurreko astean marea behea izan zen, baina aste honetan altua da".
Terminologia apur bat belaontzi lizentziarik ez dutenentzat. Mareak ilargiaren zikloaren araberakoak dira. Eta Lurrak biratzen duen heinean, 12,5 orduz behin Eguzkiaren eta Ilargiaren grabitate-erakarpenak marea-uhin bat sortzen du. 12,5 orduko zikloaren hasieran itsasgora egiten da, zikloaren erdian beherakada, eta amaieran, berriz, itsasgora. Baina ilargiaren orbita aldatzen den heinean, itsasbeheraren eta itsasgoraren arteko aldea ere aldatzen da. Ilargia Eguzkiaren eta Lurraren artean edo Lurraren kontrako aldean dagoenean (ilbetea edo ilargirik gabea), Syzygyn mareak lortzen ditugu: itsasgora altuenak eta itsasbehera baxuenak. Ilargi erdian koadraturako mareak lortzen ditugu - marea baxuenak. Bi muturren arteko aldea asko murrizten da. Ilargi-zikloak 28 egun irauten ditu: sizigiarra - koadratura - sizigiarra - koadratura.
Teknikariei mareen indarren funtsa azaldu zitzaienean, berehala pentsatu zuten poliziari deitu behar zutela. Eta nahiko logikoa. Baina ikusten da mutilak arrazoia zuela. Bi aste lehenago, suntsitzaile bat amarratu zen bulegotik ez urrun. Mareak altuera jakin batera igotzen zuen bakoitzean, ontziko radar postua zerbitzari gelako solairuaren mailan amaitzen zen. Eta radarrak (edo gerra elektronikoko ekipoak, edo beste jostailu militarren batek) kaosa sortu zuen ordenagailuetan.
Hegaldi misioa txupinazorako
Koheteen jaurtiketa kontrolatzeko eta monitorizatzeko sistema handi bat (400 mila lerro inguru) sistema eragilearen, konpiladorearen eta hizkuntzaren bertsio berrietara eramatea arduratu nintzen. Zehatzago esanda, Solaris 2.5.1etik Solaris 7ra, eta Verdix Ada Development System (VADS), Ada 83-n idatzia, Rational Apex Ada sistemara, Ada 95-n idatzia. VADS Rational-ek erosi zuen eta bere produktua izan zen. zaharkitua, nahiz eta Rational VADS-en berariazko paketeen bertsio bateragarriak ezartzen saiatu zen Apex konpiladorerako trantsizioa errazteko.
Hiru pertsonak lagundu zidaten kodea garbi konpilatzen. Bi aste behar izan zituen. Eta gero nire kabuz lan egin nuen sistemak funtzionatzeko. Laburbilduz, aurkitu nuen software-sistema baten arkitektura eta ezarpen txarrena izan zen, beraz, beste bi hilabete behar izan zituen portua osatzeko. Ondoren, sistema probak egiteko aurkeztu zen, eta hainbat hilabete gehiago behar izan zituen. Probetan aurkitutako akatsak berehala zuzendu nituen, baina haien kopurua azkar gutxitu zen (iturburu-kodea produkzio-sistema bat zen, beraz, bere funtzionaltasunak nahiko fidagarri funtzionatzen zuen, konpiladore berrira egokitzean sortutako akatsak kendu behar izan ditut). Azkenean, dena behar bezala funtzionatzen ari zenean, beste proiektu batera eraman ninduten.
Eta Eskerrak emateko aurreko ostiralean, telefonoak jo zuen.
Suziria jaurtiketa hiru astetan probatu behar zen, eta atzerako kontaketa laborategiko probetan, komandoen sekuentzia blokeatu egin zen. Bizitza errealean, horrek proba bertan behera utziko luke, eta motorra martxan jarri eta segundo gutxiren buruan blokeoa gertatuko balitz, sistema laguntzaileetan hainbat ekintza itzulezin gertatuko lirateke, eta horrek kohetearen prestutasun luzea -eta garestia- eskatuko luke. Ez zen hasiko, baina jende asko asko haserretuko zen denbora eta diru asko eta asko galtzeagatik. Ez dezala inork esan Defentsa Sailak dirua arduragabekeriaz gastatzen duela —ez dut inoiz topatu aurrekontua lehen edo bigarrenik jarri ez zuen kontratazio kudeatzailerik, eta ondoren egutegia—.
Aurreko hilabeteetan, atzerako kontu-erronka hau ehunka aldiz exekutatu zen aldaera askotan, hikaste txiki batzuekin. Beraz, hori gertatzeko probabilitatea oso txikia zen, baina bere ondorioak oso nabarmenak ziren. Biderkatu bi faktore horiek, eta ulertuko duzu albisteak oporretako aste hondatua iragarri zidala niri eta dozenaka ingeniari eta zuzendariri.
Eta arreta jarri zidaten sistema porturatu zuen pertsona bezala.
Segurtasun-sistema kritiko gehienetan bezala, parametro asko erregistratu ziren, beraz, nahiko erraza izan zen sistema huts egin aurretik exekutatzen ziren kode lerro gutxi batzuk identifikatzea. Eta, noski, ez zegoen ezer arrarorik; esamolde berdinak arrakastaz exekutatu ziren literalki milaka aldiz korrika berean.
Apex-eko jendea Rational-era deitu genuen, konpilatzailea garatu zutenak zirelako eta haiek garatutako errutina batzuk kode susmagarrian deitzen zirelako. Beraiek (eta gainontzeko guztiak) harrituta geratu ziren literalki nazio-garrantzia duen arazo baten errora iritsi beharra zegoela.
Aldizkarietan ezer interesgarririk ez zegoenez, arazoa bertako laborategi batean erreproduzitzen saiatzea erabaki genuen. Ez zen lan erraza izan, gertaera 1000 lasterketako behin gutxi gorabehera. Ustezko arrazoi bat saltzaileak garatutako mutex funtzio baterako deia izan zen (VADS migrazio paketearen parte) Unlock ez zuen desblokeatzea ekarri. Funtzioa deitzen zuen prozesatzeko hariak bihotz-taupadak prozesatzen zituen, nominalki segundoro iristen zirenak. Frekuentzia 10 Hz-ra igo genuen, hau da, 10 aldiz segundoko, eta korrika hasi ginen. Ordubete inguru geroago sistema blokeatu egin zen. Erregistroan, ikusi genuen grabatutako mezuen sekuentzia huts egindako proban bezalaxe zela. Hainbat lasterketa gehiago egin genituen, sistema etengabe blokeatu zen hasi eta 45-90 minutura, eta aldi bakoitzean erregistroak ibilbide bera zuen. Teknikoki kode ezberdina exekutatzen ari ginen arren -mezuen maiztasuna ezberdina zen- sistemaren portaera bera zen, beraz, ziur geunden karga-eszenatoki honek arazo bera eragiten zuela.
Orain asmatu behar genuen blokeoa non gertatu zen zehazki adierazpenen sekuentzian.
Sistemaren inplementazio honek Ada ataza sistema erabiltzen zuen, eta oso gaizki erabili zuen. Zereginak Ada-n aldi berean exekutagarriak diren goi-mailako eraikuntza bat dira, exekuzio-hariak bezalako zerbait, hizkuntzan bertan bakarrik eraikia. Bi zeregin komunikatu behar direnean, "hitzaldi bat ezartzen dute", beharrezko datuak trukatzen dituzte, eta, ondoren, hitzordua gelditzen dute eta euren burutzapen independenteetara itzultzen dira. Hala ere, sistema ezberdina ezarri zen. Xede-zeregin bat hitzordua izan ondoren, xede-zeregin hori beste zeregin batekin hitzordu zen, gero hirugarren zeregin batekin, eta abar prozesamenduren bat amaitu arte. Honen ostean, hitzordu hauek guztiak amaitu ziren eta zeregin bakoitzak bere exekuziora itzuli behar izan zuen. Hau da, munduko funtzio-dei sistemarik garestienarekin ari ginen, eta horrek "multitasking" prozesu osoa geldiarazi zuen sarrerako datuen zati bat prozesatzen zuen bitartean. Eta honek baino lehen ez zuen arazorik ekarri errendimendua oso baxua zelako.
Zeregin-mekanismo hau deskribatu nuen, hitzordu bat eskatzen zenean edo osatzea espero zenean "zereginen aldaketa" gerta zitekeelako. Hau da, prozesadorea exekutatzeko prest dagoen beste zeregin bat prozesatzen has liteke. Ematen du zeregin bat beste zeregin batekin elkartzeko prest dagoenean, guztiz bestelako zeregin bat exekutatzen has daitekeela, eta, azkenean, kontrola lehen hitzordura itzultzen da. Eta zeregina aldatzea eragiten duten beste gertakari batzuk gerta daitezke; gertaera horietako bat sistemaren funtzio baterako deia da, adibidez mutex bat inprimatzea edo exekutatzea.
Kode-lerroak arazoa eragiten zuen ulertzeko, adierazpen-sekuentzia baten bidez aurrerapena grabatzeko modu bat aurkitu behar nuen ataza-aldaketarik eragin gabe, eta horrek hutsegite bat saihestuko zuen. Beraz, ezin izan nuen aprobetxatu Put_Line()I/O eragiketak egitea saihesteko. Kontagailuaren aldagai bat edo antzeko zerbait ezarri nezake, baina nola ikus dezaket haren balioa ezin badut pantailan bistaratu?
Era berean, erregistroa aztertzean, ondorioztatu zen, bihotz-taupaden mezuen prozesamendua izoztu arren, prozesuko I/O eragiketa guztiak blokeatu eta beste prozesamendu batzuk egitea eragozten zuen arren, beste zeregin independente batzuk exekutatzen jarraitzen zutela. Hau da, lana ez zen erabat blokeatu, zereginen kate (kritikoa) baizik.
Hau izan zen blokeo-adierazpena ebaluatzeko behar zen arrastoa.
Ada pakete bat egin nuen, zeregin bat, zerrendatutako mota bat eta mota horretako aldagai global bat zituena. Zenbakizko literalak sekuentzia problematikoko esamolde zehatzetara lotzen ziren (adibidez. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), eta, ondoren, aldagai global bati dagokion zenbaketa esleitzen zioten esleipen-adierazpenak txertatu zituen bertan. Horren guztiaren objektu-kodeak memorian konstante bat gordetzen zuenez, bere exekuzioaren ondorioz zereginen aldaketa oso zaila zen. Batez ere, zeregina alda zezaketen esamoldeez susmatzen genuen, blokeoa exekuzioan gertatu baitzen zeregina atzera aldatzean itzuli beharrean (hainbat arrazoirengatik).
Jarraipen-zeregina begizta batean exekutatu eta aldian-aldian aldagai globalaren balioa aldatu ote zen egiaztatzen zuen. Aldaketa bakoitzarekin, balioa fitxategi batean gordetzen zen. Ondoren, itxaronaldi labur bat eta egiaztapen berri bat. Aldagaia fitxategian idatzi nuen ataza arazo-eremuan zeregina aldatzean sistemak exekutatzeko aukeratzen zuenean bakarrik exekutatu zelako. Zeregin honetan gertatutakoak ez die eragingo blokeatutako beste zereginei.
Espero zen sistema kode problematikoa exekutatzeko puntura iristean, aldagai globala berrezarri egingo zela hurrengo adierazpen bakoitzerako mugitzean. Orduan, zeregina aldatzea eragiten duen zerbait gertatuko da, eta bere exekuzio-maiztasuna (10 Hz) monitorizazio-zereginarena baino txikiagoa denez, monitoreak aldagai globalaren balioa har dezake eta idatzi. Egoera normal batean, enumerazioen azpimultzo baten sekuentzia errepikakorra lor nezake: ataza aldatzeko unean aldagaiaren azken balioak. Zintzilik dagoenean, aldagai globalak ez luke aldatu behar, eta idatzitako azken balioak adieraziko du zein adierazpen ez den osatu.
Jarraipenarekin kodea exekutatu dut. Izoztu egin zen. Eta monitorizazioak erlojupeko moduan funtzionatu zuen.
Erregistroak esperotako sekuentzia zuen, mutex bat deitu zela adierazten zuen balio batek eten zuena Unlock, eta zeregina ez da amaitu - aurreko milaka deietan gertatzen den bezala.
Apexeko ingeniariak sukarrez ari ziren beren kodea aztertzen une honetan eta teorikoki blokeoa gerta zitekeen leku bat aurkitu zuten mutexean. Baina bere probabilitatea oso txikia zen, une jakin batean gertakari sekuentzia jakin batek soilik ekar zezakeelako blokeoa. Murphyren legea, mutilak, Murphyren legea da.
Behar nuen kode zatia babesteko, mutex funtzio deiak (OS mutex funtzionalitatearen gainean eraikiak) jatorrizko Ada mutex pakete txiki batekin ordezkatu ditut pieza horretarako mutex sarbidea kontrolatzeko.
Kodean sartu eta proba egin nuen. Zazpi ordu geroago kodea funtzionatzen zuen.
Nire kodea Rational-i bidali zen, non konpilatu, desmuntatu eta mutex funtzio problematikoetan erabiltzen zen ikuspegi bera ez zuela erabiltzen egiaztatu zuten.
Hau izan zen nire ibilbideko kodeen berrikuspen jendetsuena 🙂 Hamar ingeniari eta zuzendari inguru zeuden nirekin gelan, beste hamar pertsona konferentzia-dei batean zeuden, eta denek 20 kode lerro inguru aztertu zituzten.
Kodea berrikusi, fitxategi exekutagarri berriak muntatu eta erregresio-proba formaletarako bidali ziren. Pare bat aste geroago, atzerako kontaketa proba arrakastatsua izan zen eta suziria aireratu zen.
Ados, dena ondo dago, baina zertarako balio du istorioak?
Arazo guztiz nazkagarria izan zen. Ehunka milaka kode-lerro, exekuzio paraleloa, elkarreraginean dauden dozena bat prozesu baino gehiago, arkitektura eskasa eta inplementazio txarra, sistema txertatuetarako interfazeak eta milioika dolar gastatu. Presiorik ez, ezta.
Ez nintzen ni izan arazo honetan lanean ari zen bakarra, portatzea egiten ari nintzela fokuan egon nintzen arren. Baina egin nuen arren, horrek ez du esan nahi ehunka mila kode lerro guztiak ulertu ditudanik, ezta gainbegiratu ere egin ditudanik. Kodea eta erregistroak herrialde osoko ingeniariek aztertu zituzten, baina hutsegitearen arrazoiei buruzko hipotesiak kontatu zizkidatenean, minutu erdi bat besterik ez nuen behar ezeztatzeko. Eta teoriak aztertzea eskatzen zidatenean, beste bati helaraziko nion, begi-bistakoa baitzen niretzat ingeniari horiek bide okerra zihoazela. Sutsukeriazko soinua? Bai, egia da, baina hipotesiak eta eskaerak baztertu nituen beste arrazoi bategatik.
Arazoaren izaera ulertu nuen. Ez nekien zehazki non gertatzen zen edo zergatik gertatzen zen, baina banekien zer gertatzen zen.
Urteetan zehar, ezagutza eta esperientzia asko pilatu ditut. Ada erabiltzearen aitzindarietako bat izan nintzen eta bere abantailak eta desabantailak ulertzen nituen. Badakit Ada exekuzio-liburutegiek zereginak nola kudeatzen dituzten eta exekuzio paraleloari nola aurre egiten dioten. Eta maila baxuko programazioa memoria, erregistro eta muntatzaile mailan ulertzen dut. Beste era batera esanda, ezagutza sakona daukat nire alorrean. Eta arazoaren zergatia aurkitzeko erabili ditut. Ez nuen akatsa bakarrik landu, exekuzio-ingurune oso sentikor batean nola aurkitu ulertu nuen.
Kodearen aurkako borrokaren istorioak ez dira oso interesgarriak borroka horren ezaugarriak eta baldintzak ezagutzen ez dituztenentzat. Baina istorio hauek arazo benetan zailak konpontzeko zer behar den ulertzen laguntzen digute.
Arazo benetan gogorrak konpontzeko, programatzaile bat baino gehiago izan behar duzu. Kodearen "patua" ulertu behar duzu, bere ingurunearekin nola elkarreragiten duen eta inguruneak berak nola funtzionatzen duen.
Eta gero zure opor aste hondatua izango duzu.
Jarraitu behar da.
Iturria: www.habr.com