ProHoster > Blogs > Administrācija > Programmētāju un inženieru folklora (1. daļa)

Programmētāju un inženieru folklora (1. daļa)

Programmētāju un inženieru folklora (1. daļa)

Šī ir stāstu izlase no interneta par to, kā kļūdām dažkārt ir pilnīgi neticamas izpausmes. Varbūt arī tev ir ko pastāstīt.

AutomaŔīnu alerÄ£ija pret vaniļas saldējumu

Stāsts inženieriem, kuri saprot, ka acÄ«mredzamais ne vienmēr ir atbilde un ka neatkarÄ«gi no tā, cik tāli Ŕķiet fakti, tie joprojām ir fakti. General Motors Corporation Pontiac nodaļa saņēma sÅ«dzÄ«bu:

Å Ä« ir otrā reize, kad es jums rakstu, un es nepārmetu jums, ka neatbildējāt, jo tas izklausās traki. MÅ«su Ä£imenē ir tradÄ«cija katru vakaru pēc vakariņām ēst saldējumu. Saldējuma veidi mainās katru reizi, un pēc vakariņām visa Ä£imene izvēlas, kādu saldējumu pirkt, pēc kā dodos uz veikalu. Es nesen nopirku jaunu Pontiac, un kopÅ” tā laika mani ceļojumi pēc saldējuma ir kļuvuÅ”i par problēmu. Redziet, katru reizi, kad nopērku vaniļas saldējumu un atgriežos no veikala, maŔīna neieslēdzas. Ja atnesu kādu citu saldējumu, maŔīna ieslēdzas bez problēmām. Es gribu uzdot nopietnu jautājumu, lai cik muļķīgi tas izklausÄ«tos: "Kas ir tas Pontiac, kas liek tam nesākas, kad es atnesu vaniļas saldējumu, bet viegli sākas, kad atnesu citu saldējuma garÅ”u?"

Kā jÅ«s varat iedomāties, nodaļas prezidents bija skeptisks par vēstuli. Tomēr katram gadÄ«jumam es nosÅ«tÄ«ju inženieri pārbaudÄ«t. ViņŔ bija pārsteigts, ka viņu sagaidÄ«ja turÄ«gs, labi izglÄ«tots vÄ«rietis, kurÅ” dzÄ«vo skaistā rajonā. Viņi vienojās satikties uzreiz pēc vakariņām, lai abi varētu aiziet uz veikalu pēc saldējuma. Tajā vakarā tā bija vaniļa, un, kad viņi atgriezās pie maŔīnas, tā vairs neieslēdzās.

Inženieris ieradās vēl trÄ«s vakarus. Pirmo reizi saldējums bija Å”okolāde. Auto iedarbināja. Otrajā reizē bija zemeņu saldējums. Auto iedarbināja. TreÅ”ajā vakarā viņŔ palÅ«dza paņemt vaniļu. MaŔīna neieslēdzās.

Racionāli prātojot, inženieris atteicās ticēt, ka automaŔīnai ir alerÄ£ija pret vaniļas saldējumu. Tāpēc vienojos ar maŔīnas Ä«paÅ”nieku, ka viņŔ turpinās vizÄ«tes, lÄ«dz atradÄ«s problēmas risinājumu. Un pa ceļam viņŔ sāka veikt piezÄ«mes: pierakstÄ«ja visu informāciju, diennakts laiku, benzÄ«na veidu, ieraÅ”anās un atgrieÅ”anās laiku no veikala utt.

Inženieris drÄ«z saprata, ka automaŔīnas Ä«paÅ”nieks vaniļas saldējuma iegādei veltÄ«ja mazāk laika. Iemesls bija preču izkārtojums veikalā. Vaniļas saldējums bija vispopulārākais un tika glabāts atseviŔķā saldētavā veikala priekÅ”pusē, lai bÅ«tu vieglāk atrast. Un visas pārējās Ŕķirnes atradās veikala aizmugurē, un vajadzēja daudz vairāk laika, lai atrastu pareizo Ŕķirni un samaksu.

Tagad jautājums bija inženierim: kāpēc automaŔīna neieslēdzās, ja kopÅ” dzinēja izslēgÅ”anas bija pagājis mazāk laika? Tā kā problēma bija laikā, nevis vaniļas saldējumā, inženieris ātri atrada atbildi: tā bija gāzes slēdzene. Tas notika katru vakaru, bet, kad automaŔīnas Ä«paÅ”nieks vairāk laika pavadÄ«ja saldējuma meklējumos, motors paspēja pietiekami atdzist un viegli iedarbināja. Un, kad vÄ«rietis nopirka vaniļas saldējumu, motors vēl bija pārāk karsts un gāzes slēdzenei nebija laika izŔķīst.

Morāle: pat pilnīgi trakas problēmas dažreiz ir reālas.

crash somainā žurka

Ir sāpÄ«gi to piedzÄ«vot. Kā programmētājs pierod vainot savu kodu pirmo, otro, treÅ”o... un kaut kur desmittÅ«kstoÅ”ajā vietā vainojat kompilatoru. Un tālāk sarakstā jÅ«s jau vainojat aprÄ«kojumu.

Šeit ir mans stāsts par aparatūras kļūdu.

Spēlei Crash Bandicoot es uzrakstÄ«ju kodu, lai ielādētu un saglabātu atmiņas kartē. Tik paÅ”apmierinātajam spēļu izstrādātājam tā bija kā pastaiga parkā: domāju, ka darbs prasÄ«s vairākas dienas. Tomēr es beidzu atkļūdot kodu seÅ”as nedēļas. Pa ceļam es atrisināju citas problēmas, bet ik pēc dažām dienām uz dažām stundām atgriezos pie Ŕī koda. Tā bija agonija.

Simptoms izskatÄ«jās Ŕādi: saglabājot paÅ”reizējo spēles gaitu un piekļūstot atmiņas kartei, viss gandrÄ«z vienmēr notiek labi... Bet dažreiz lasÄ«Å”anas vai rakstÄ«Å”anas darbÄ«bas taimauts bez acÄ«mredzama iemesla. ÄŖss ieraksts bieži sabojā atmiņas karti. Kad spēlētājs mēģina glābt, viņam ne tikai neizdodas saglabāt, bet arÄ« iznÄ«cina karti. Smuki.

Pēc kāda laika mÅ«su Sony producente Konija Busa sāka krist panikā. Mēs nevarējām nosÅ«tÄ«t spēli ar Å”o kļūdu, un pēc seŔām nedēļām es nesapratu, kas izraisÄ«ja problēmu. Izmantojot Koniju, mēs sazinājāmies ar citiem PS1 izstrādātājiem: vai kāds ir saskāries ar kaut ko lÄ«dzÄ«gu? Nē. Nevienam nebija problēmu ar atmiņas karti.

Ja jums nav ideju par atkļūdoÅ”anu, vienÄ«gā pieeja ir ā€œsadalÄ«t un iekarotā€: no bojātās programmas izņemiet arvien vairāk koda, lÄ«dz paliek salÄ«dzinoÅ”i mazs fragments, kas joprojām rada problēmu. Tas ir, jÅ«s nogriežat programmu pa gabalu, lÄ«dz paliek daļa, kurā ir kļūda.

Bet lieta ir tāda, ka no videospēles ir ļoti grūti izgriezt gabalus. Kā to palaist, ja esat noņēmis kodu, kas atdarina gravitāciju? Vai zīmēt rakstzīmes?

Tāpēc mums ir jāaizstāj veseli moduļi ar stubiem, kas izliekas, ka dara kaut ko noderÄ«gu, bet patiesÄ«bā dara kaut ko ļoti vienkārÅ”u, kas nevar saturēt kļūdas. Jāraksta tādi kruÄ·i, lai spēle vismaz darbotos. Tas ir lēns un sāpÄ«gs process.

ÄŖsāk sakot, es to izdarÄ«ju. Es noņēmu arvien vairāk koda daļu, lÄ«dz man palika sākotnējais kods, kas konfigurē sistēmu spēles palaiÅ”anai, inicializē renderÄ“Å”anas aparatÅ«ru utt. Protams, Å”ajā posmā es nevarēju izveidot saglabāŔanas un ielādes izvēlni, jo man bÅ«tu jāizveido stubs visam grafikas kodam. Bet es varētu izlikties par lietotāju, izmantojot (neredzamo) saglabāŔanas un ielādes ekrānu, un lÅ«gt saglabāt un pēc tam ierakstÄ«t atmiņas kartē.

Tādējādi man palika neliels koda fragments, kuram joprojām bija iepriekÅ” minētā problēma, taču tā joprojām notika nejauÅ”i! Visbiežāk viss darbojās labi, bet reizēm bija kļūmes. Es noņēmu gandrÄ«z visu spēles kodu, bet kļūda joprojām bija dzÄ«va. Tas bija mulsinoÅ”i: atlikuÅ”ais kods faktiski neko nedarÄ«ja.

Kādā brÄ«dÄ«, laikam ap trijiem naktÄ«, man ienāca prātā doma. LasÄ«Å”anas un rakstÄ«Å”anas (ievades/izvades) operācijas ietver precÄ«zus izpildes laikus. Strādājot ar cieto disku, atmiņas karti vai Bluetooth moduli, zemā lÄ«meņa kods, kas atbild par lasÄ«Å”anu un rakstÄ«Å”anu, to dara saskaņā ar pulksteņa impulsiem.

Ar pulksteņa palÄ«dzÄ«bu ierÄ«ce, kas nav tieÅ”i savienota ar procesoru, tiek sinhronizēta ar procesorā izpildāmo kodu. Pulkstenis nosaka datu pārraides ātrumu ā€” datu pārsÅ«tÄ«Å”anas ātrumu. Ja ir neskaidrÄ«bas ar hronometrāžu, tiek sajaukta arÄ« aparatÅ«ra vai programmatÅ«ra, vai abi. Un tas ir ļoti slikti, jo dati var tikt sabojāti.

Ko darÄ«t, ja kaut kas mÅ«su kodā sajauc laiku? Es pārbaudÄ«ju visu, kas ar to saistÄ«ts, testa programmas kodā un pamanÄ«ju, ka mēs PS1 programmējamo taimeri iestatÄ«jām uz 1 kHz (1000 atzÄ«mēm sekundē). Tas ir diezgan daudz; pēc noklusējuma, kad konsole startē, tā darbojas ar 100 Hz. Un lielākā daļa spēļu izmanto Å”o frekvenci.

Endijs, spēles izstrādātājs, iestatīja taimeri uz 1 kHz, lai kustības tiktu aprēķinātas precīzāk. Endijam ir tendence pārspīlēt, un, ja mēs līdzināsim gravitāciju, mēs to darām pēc iespējas precīzāk!

Bet ko darÄ«t, ja taimera paātrināŔana kaut kādā veidā ietekmētu programmas kopējo laiku un lÄ«dz ar to arÄ« pulksteni, kas regulē atmiņas kartes datu pārraides ātrumu?

Es komentēju taimera kodu. Kļūda vairs neatkārtojās. Bet tas nenozÄ«mē, ka mēs to labojām, jo ā€‹ā€‹kļūme radās nejauÅ”i. Ja man vienkārÅ”i paveicās?

Pēc dažām dienām es vēlreiz eksperimentēju ar testa programmu. Kļūda neatkārtojās. Es atgriezos pie pilnas spēles kodu bāzes un mainÄ«ju saglabāŔanas un ielādes kodu, lai programmējamais taimeris pirms piekļuves atmiņas kartei tiktu atiestatÄ«ts uz sākotnējo vērtÄ«bu (100 Hz), un pēc tam atiestatÄ«tu atpakaļ uz 1 kHz. Vairāk avāriju nebija.

Bet kāpēc tas notika?

Atkal atgriezos pie testa programmas. Es mēģināju atrast kādu modeli kļūdas raÅ”anās gadÄ«jumā ar 1 kHz taimeri. Galu galā es pamanÄ«ju, ka kļūda rodas, kad kāds spēlē ar PS1 kontrolieri. Tā kā es pats to darÄ«tu reti, kāpēc man, pārbaudot saglabāŔanas un ielādes kodu, ir vajadzÄ«gs kontrolleris? - Es pat nepamanÄ«ju Å”o atkarÄ«bu. Bet kādu dienu viens no mÅ«su māksliniekiem gaidÄ«ja, kad pabeigÅ”u testÄ“Å”anu ā€“ es laikam tajā brÄ«dÄ« lamājos ā€“ un nervozi virpa savās rokās kontrolieri. Radās kļūda. "Pagaidi, ko?!" Nu, dariet to vēlreiz!"

Kad sapratu, ka Å”ie divi notikumi ir savstarpēji saistÄ«ti, es varēju viegli atveidot kļūdu: sāku ierakstÄ«t atmiņas kartē, pārvietoju kontrolleri un sabojāju atmiņas karti. Man tas izskatÄ«jās pēc aparatÅ«ras kļūdas.

Es atnācu pie Konijas un pastāstÄ«ju viņai par savu atklājumu. Viņa nodeva informāciju vienam no inženieriem, kas izstrādāja PS1. "Neiespējami," viņŔ atbildēja, "Tā nevar bÅ«t aparatÅ«ras problēma." Es palÅ«dzu Konijai sarunāt mums sarunu.

Man piezvanÄ«ja inženieris, un mēs strÄ«dējāmies viņa lauztajā angļu valodā un manā (ārkārtÄ«gi) lauztajā japāņu valodā. Beidzot es teicu: "Ä»aujiet man vienkārÅ”i nosÅ«tÄ«t savu 30 lÄ«niju testa programmu, kur kontroliera pārvietoÅ”ana izraisa kļūdu." ViņŔ piekrita. Teica, ka tā bija laika izŔķieÅ”ana un ka viņŔ ir Å”ausmÄ«gi aizņemts, strādājot pie jauna projekta, taču piekāpsies, jo mēs esam ļoti nozÄ«mÄ«gs Sony izstrādātājs. Es iztÄ«rÄ«ju savu testa programmu un nosÅ«tÄ«ju to viņam.

Nākamajā vakarā (mēs bijām Losandželosā, bet viņŔ Tokijā) viņŔ man piezvanÄ«ja un nekaunÄ«gi atvainojās. Tā bija aparatÅ«ras problēma.

Es nezinu, kas tieÅ”i bija par kļūdu, bet pēc tā, ko dzirdēju Sony galvenajā mÄ«tnē, ja iestatÄ«jāt taimeri uz pietiekami augstu vērtÄ«bu, tas traucēja komponentiem mātesplatē taimera kristāla tuvumā. Viens no tiem bija atmiņas kartes bodu ātruma kontrolleris, kas arÄ« iestatÄ«ja kontrolieriem bodu ātrumu. Es neesmu inženieris, tāpēc, iespējams, esmu kaut ko sajaucis.

Bet būtība ir tāda, ka starp mātesplates komponentiem bija traucējumi. Un, vienlaikus pārsūtot datus caur kontrollera portu un atmiņas kartes portu ar taimeri, kas darbojas ar 1 kHz, tika zaudēti biti, dati un karte tika bojāta.

Sliktas govis

Astoņdesmitajos gados mans mentors Sergejs rakstÄ«ja programmatÅ«ru SM-1980, padomju PDP-1800 klonam. Å is mikrodators nupat tika uzstādÄ«ts dzelzceļa stacijā netālu no Sverdlovskas, nozÄ«mÄ«ga PSRS transporta mezgla. Jaunā sistēma bija paredzēta vagonu un kravu satiksmes marÅ”rutÄ“Å”anai. Bet tajā bija kaitinoÅ”a kļūda, kas izraisÄ«ja nejauÅ”as avārijas un avārijas. Kritieni vienmēr notika, kad kāds vakarā devās mājās. Bet, neskatoties uz rÅ«pÄ«gu izmeklÄ“Å”anu nākamajā dienā, dators darbojās pareizi visos manuālajos un automātiskajos testos. Tas parasti norāda uz sacensÄ«bu stāvokli vai kādu citu konkurences kļūdu, kas notiek noteiktos apstākļos. Noguris no zvaniem vēlā vakarā, Sergejs nolēma Ä·erties pie lietas un vispirms saprast, kādi apstākļi ŔķiroÅ”anas parkā izraisÄ«ja datora bojājumu.

Pirmkārt, viņŔ apkopoja statistiku par visiem neizskaidrojamiem kritieniem un izveidoja grafiku pēc datuma un laika. Modelis bija acÄ«mredzams. Novērojot vēl dažas dienas, Sergejs saprata, ka var viegli paredzēt turpmāko sistēmas kļūmju laiku.

DrÄ«z viņŔ uzzināja, ka traucējumi raduÅ”ies tikai tad, kad stacija Ŕķiroja liellopu kravas no Ukrainas ziemeļiem un Krievijas rietumiem, kas devās uz tuvējo kautuvi. Tas pats par sevi bija dÄ«vaini, jo kautuvi apgādāja fermas, kas atrodas daudz tuvāk, Kazahstānā.

Černobiļas atomelektrostacija eksplodēja 1986. gadā, un radioaktÄ«vie nokriŔņi padarÄ«ja apkārtējās teritorijas neapdzÄ«vojamas. Piesārņotas bija plaÅ”as teritorijas Ukrainas ziemeļos, Baltkrievijā un Krievijas rietumos. Aizdomās par augstu radiācijas lÄ«meni atbraukuÅ”ajos vagonos Sergejs izstrādāja metodi Ŕīs teorijas pārbaudei. IedzÄ«votājiem bija aizliegts turēt dozimetri, tāpēc Sergejs piereÄ£istrējās pie vairākiem militārpersonām dzelzceļa stacijā. Pēc vairākiem Ŕņabja dzērieniem viņam izdevās pārliecināt karavÄ«ru izmērÄ«t radiācijas lÄ«meni vienā no aizdomÄ«gajiem vagoniem. IzrādÄ«jās, ka lÄ«menis bija vairākas reizes augstāks par normālām vērtÄ«bām.

Liellopi ne tikai izstaroja daudz starojuma, bet arÄ« tā lÄ«menis bija tik augsts, ka tas izraisÄ«ja nejauÅ”u bitu zudumu SM-1800 atmiņā, kas atradās ēkā blakus stacijai.

PSRS bija pārtikas trÅ«kums, un varas iestādes nolēma sajaukt Černobiļas gaļu ar gaļu no citiem valsts reÄ£ioniem. Tas ļāva samazināt kopējo radioaktivitātes lÄ«meni, nezaudējot vērtÄ«gus resursus. Uzzinājis par to, Sergejs nekavējoties aizpildÄ«ja dokumentus emigrācijai. Un datoru avārijas apstājās paÅ”as, kad radiācijas lÄ«menis laika gaitā samazinājās.

Caur caurulēm

Savulaik Movietech Solutions radÄ«ja programmatÅ«ru kinoteātriem, kas paredzēta grāmatvedÄ«bai, biļeÅ”u tirdzniecÄ«bai un vispārējai vadÄ«bai. Galvenās lietotnes DOS versija bija diezgan populāra mazo un vidēja lieluma kinoteātru ķēdēs Ziemeļamerikā. Tāpēc nav pārsteidzoÅ”i, ka tad, kad tika paziņota par Windows 95 versiju, kas ir integrēta ar jaunākajiem skārienekrāniem un paÅ”apkalpoÅ”anās kioskiem un bija aprÄ«kota ar visa veida ziņoÅ”anas rÄ«kiem, arÄ« tā ātri kļuva populāra. Visbiežāk atjauninājums noritēja bez problēmām. Vietējie IT darbinieki uzstādÄ«ja jaunu aprÄ«kojumu, migrēja datus, un bizness turpinājās. Izņemot gadÄ«jumus, kad tas nebija ilgs. Kad tas notika, uzņēmums izsÅ«tÄ«ja Džeimsu ar iesauku "Apkopējs".

Lai gan segvārds liecina par nelietÄ«gu veidu, tÄ«rÄ«tājs ir tikai instruktora, uzstādÄ«tāja un visnotaļ profesionāļa kombinācija. Džeimss dažas dienas pavadÄ«ja klienta vietnē, saliekot kopā visus komponentus, un pēc tam vēl pāris dienas mācÄ«ja personālam, kā lietot jauno sistēmu, atrisināja visas raduŔās aparatÅ«ras problēmas un palÄ«dzēja programmatÅ«rai tās sākuma stadijā.

Tāpēc nav pārsteidzoÅ”i, ka Å”ajos drudžainajos laikos Džeimss ieradās birojā no rÄ«ta, un, pirms viņŔ paguva sasniegt savu rakstāmgaldu, viņu sagaidÄ«ja menedžeris, kas bija piepildÄ«ts ar kofeÄ«nu neparasti.

"Es baidos, ka jums pēc iespējas ātrāk jādodas uz Anapolisu, Jaunskotijā." Visa viņu sistēma sabojājās, un pēc nakts darba ar viņu inženieriem mēs nevaram saprast, kas noticis. Šķiet, ka serverī ir radusies tīkla kļūme. Bet tikai pēc tam, kad sistēma bija darbojusies vairākas minūtes.

ā€” Vai viņi neatgriezās pie vecās sistēmas? - Džeimss atbildēja pilnÄ«gi nopietni, lai gan garÄ«gi izbrÄ«nā iepleta acis.

ā€” TieÅ”i tā: viņu IT speciālists ā€œmainÄ«ja prioritātesā€ un nolēma aiziet ar savu veco serveri. Džeims, viņi instalēja sistēmu seŔās vietās un tikko samaksāja par papildu atbalstu, un viņu bizness tagad darbojas tāpat kā 1950. gados.

Džeimss nedaudz iztaisnojās.

- Tas ir cits jautājums. Labi, sāksim.

Kad viņŔ ieradās Anapolisā, pirmais, ko viņŔ izdarÄ«ja, bija atrast klienta pirmo teātri, kurā bija problēma. Lidostā uzņemtajā kartē viss izskatÄ«jās pieklājÄ«gi, bet apkārtne ap vēlamo adresi izskatÄ«jās aizdomÄ«ga. Nevis geto, bet atgādina film noir. Kad Džeimss novietoja automaŔīnu pie pilsētas centra apmales, viņam tuvojās prostitÅ«ta. Ņemot vērā Anapolisas lielumu, tas, visticamāk, bija vienÄ«gais visā pilsētā. Viņas izskats uzreiz atgādināja slaveno varoni, kurÅ” uz lielā ekrāna piedāvāja seksu par naudu. Nē, ne par Džūliju Robertsu, bet gan par Džonu Voitu [mājiens uz filmu "Pusnakts kovbojs" - apm. josla].

AizsÅ«tÄ«jis prostitÅ«tu ceļā, Džeimss devās uz kino. Apkārtne bija kļuvusi labāka, taču tā joprojām radÄ«ja nobraukta iespaidu. Ne tas, ka Džeimss bÅ«tu pārāk noraizējies. ViņŔ jau agrāk ir bijis nožēlojamās vietās. Un Ŕī bija Kanāda, kur pat laupÄ«tāji ir pietiekami pieklājÄ«gi, lai pateiktu "paldies" pēc maku paņemÅ”anas.

Kinoteātra sānu ieeja atradās drūmā alejā. Džeimss piegāja pie durvīm un pieklauvēja. Drīz vien tas čīkstēja un nedaudz atvērās.

-Tu esi apkopēja? - no iekÅ”puses atskanēja aizsmakusi balss.

- Jā, tas esmu es... Es atnācu visu salabot.

Džeimss iegāja kinoteātra vestibilā. AcÄ«mredzot, kam nebija citas izvēles, darbinieki sāka apmeklētājiem dalÄ«t papÄ«ra biļetes. Tas apgrÅ«tināja finanÅ”u pārskatu sagatavoÅ”anu, nemaz nerunājot par interesantākām detaļām. Taču darbinieki atviegloti sagaidÄ«ja Džeimsu un nekavējoties aizveda uz servera telpu.

No pirmā acu uzmetiena viss bija kārtībā. Džeimss pieteicās serverī un pārbaudīja ierastās aizdomīgās vietas. Nekādu problēmu. Tomēr piesardzības dēļ Džeimss izslēdza serveri, nomainīja tīkla karti un atcēla sistēmu. Viņa nekavējoties sāka strādāt pilnā apjomā. Darbinieki atkal sāka tirgot biļetes.

Džeimss piezvanÄ«ja Markam un informēja viņu par situāciju. Nav grÅ«ti iedomāties, ka Džeimss varētu vēlēties palikt un redzēt, vai nenotiek kas negaidÄ«ts. ViņŔ nokāpa pa kāpnēm un sāka jautāt darbiniekiem, kas noticis. AcÄ«mredzot sistēma ir pārtraukusi darboties. Viņi to izslēdza un ieslēdza, viss strādāja. Bet pēc 10 minÅ«tēm sistēma atkrita.

TieÅ”i Å”ajā brÄ«dÄ« notika kaut kas lÄ«dzÄ«gs. PēkŔņi biļeÅ”u pārdoÅ”anas sistēma sāka mest kļūdas. Darbinieki nopÅ«tās un paķēra papÄ«ra biļetes, un Džeimss steidzās uz servera telpu. Ar serveri viss izskatÄ«jās labi.

Tad ienāca viens no darbiniekiem.

ā€” Sistēma atkal strādā.

Džeimss bija neizpratnē, jo nebija neko izdarÄ«jis. PrecÄ«zāk, nekas tāds, kas liktu sistēmai darboties. ViņŔ atteicās, paņēma tālruni un piezvanÄ«ja uz sava uzņēmuma atbalsta lÄ«niju. DrÄ«z vien tas pats darbinieks ienāca serveru telpā.

- Sistēma nedarbojas.

Džeimss paskatÄ«jās uz serveri. Uz ekrāna dejoja interesants un pazÄ«stams daudzkrāsainu formu raksts - haotiski savijas un pÄ«pes. Mēs visi esam redzējuÅ”i Å”o ekrānsaudzētāju kādā brÄ«dÄ«. Tas bija skaisti atveidots un burtiski hipnotizējoÅ”s.


Džeimss nospieda pogu, un raksts pazuda. ViņŔ steidzās uz biļeÅ”u kasi un pa ceļam sastapa darbinieku, kas atgriezās pie viņa.

ā€” Sistēma atkal strādā.

Ja jÅ«s varat veikt garÄ«go facepalm, tieÅ”i to izdarÄ«ja Džeimss. Ekrānsaudzētājs. Tas izmanto OpenGL. Un tāpēc darbÄ«bas laikā tas patērē visus servera procesora resursus. Rezultātā katrs zvans uz serveri beidzas ar taimautu.

Džeimss atgriezās servera telpā, pieteicās un nomainÄ«ja ekrānsaudzētāju pret skaistajām caurulēm ar tukÅ”u ekrānu. Tas ir, ekrānsaudzētāja vietā, kas patērē 100% procesora resursu, es instalēju citu, kas nepatērē resursus. Tad es gaidÄ«ju 10 minÅ«tes, lai pārbaudÄ«tu savu minējumu.

Kad Džeimss ieradās nākamajā kinoteātrÄ«, viņŔ domāja, kā paskaidrot savam menedžerim, ka viņŔ tikko nolidojis 800 km, lai izslēgtu ekrānsaudzētāju.

Avārija noteiktā mēness fāzē

Patiess stāsts. Kādu dienu radās programmatÅ«ras kļūda, kas bija atkarÄ«ga no mēness fāzes. Bija neliela rutÄ«na, ko parasti izmantoja dažādās MIT programmās, lai aprēķinātu tuvinājumu patiesajai Mēness fāzei. GLS izveidoja Å”o rutÄ«nu LISP programmā, kas, rakstot failu, izvadÄ«tu rindiņu ar gandrÄ«z 80 rakstzÄ«mēm garu laikspiedolu. Ä»oti reti ziņojuma pirmā rindiņa bija pārāk gara un noveda pie nākamās rindas. Un, kad programma vēlāk izlasÄ«ja Å”o failu, tā nolādējās. Pirmās rindas garums bija atkarÄ«gs no precÄ«za datuma un laika, kā arÄ« no fāzes specifikācijas garuma laika zÄ«moga drukāŔanas laikā. Tas ir, kļūda burtiski bija atkarÄ«ga no mēness fāzes!

Pirmais papÄ«ra izdevums Žargonu fails (Steele-1983) ietvēra Ŕādas rindas piemēru, kas noveda pie aprakstÄ«tās kļūdas, bet salikums to ā€œizlabojaā€. KopÅ” tā laika tas ir aprakstÄ«ts kā "mēness fāzes kļūda".

Tomēr esiet uzmanÄ«gi ar pieņēmumiem. Pirms dažiem gadiem CERN (Eiropas KodolpētÄ«jumu centra) inženieri saskārās ar kļūdām eksperimentos, kas tika veikti Lielajā elektronu-pozitronu paātrinātājā. Tā kā datori aktÄ«vi apstrādā milzÄ«go Ŕīs ierÄ«ces radÄ«to datu apjomu pirms rezultātu parādÄ«Å”anas zinātniekiem, daudzi sprieda, ka programmatÅ«ra ir kaut kādā veidā jutÄ«ga pret Mēness fāzi. Vairāki izmisuÅ”i inženieri nokļuva patiesÄ«bas bÅ«tÄ«bā. Kļūda radās sakarā ar nelielām 27 km garā gredzena Ä£eometrijas izmaiņām, ko izraisÄ«ja Zemes deformācija Mēness pārejas laikā! Å is stāsts ir ienācis fizikas folklorā kā "Ņūtona atriebÄ«ba daļiņu fizikā" un piemērs saiknei starp vienkārŔākajiem un senākajiem fizikas likumiem un progresÄ«vākajām zinātnes koncepcijām.

Noskalojot tualeti, vilciens apstājas

Labākā aparatÅ«ras kļūda, par kuru esmu dzirdējis, bija ātrvilcienā Francijā. Kļūda izraisÄ«ja vilciena avārijas bremzÄ“Å”anu, taču tikai tad, ja tajā atradās pasažieri. Katrā Ŕādā gadÄ«jumā vilciens tika izņemts no ekspluatācijas, pārbaudÄ«ts, bet nekas netika atrasts. Tad viņŔ tika nosÅ«tÄ«ts atpakaļ uz lÄ«niju, un viņŔ nekavējoties apstājās.

Vienā no pārbaudēm vilcienā braucoÅ”ais inženieris devās uz tualeti. ViņŔ drÄ«z nomazgājās, BOOM! Ārkārtas apstāŔanās.

Inženieris sazinājās ar vadītāju un jautāja:

ā€” Ko jÅ«s darÄ«jāt tieÅ”i pirms bremzÄ“Å”anas?

- Nu, es samazināju ātrumu nobraucienā...

Tas bija dÄ«vaini, jo normālas darbÄ«bas laikā vilciens nobraucienos palēnina ātrumu desmitiem reižu. Vilciens devās tālāk, un nākamajā nobraucienā maŔīnists brÄ«dināja:

ā€“ Es palēnināŔu.

Nekas nav noticis.

ā€” Ko jÅ«s darÄ«jāt pēdējā bremzÄ“Å”anas laikā? - jautāja Å”oferis.

- Nu... es biju tualetē...

- Nu tad ej uz tualeti un dari to, ko darīji, kad mēs atkal kāpjam lejā!

Inženieris devās uz tualeti un, kad vadÄ«tājs brÄ«dināja: ā€œEs palēninuā€, viņŔ noskaloja Å«deni. Protams, vilciens nekavējoties apstājās.

Tagad viņi varēja atkārtot problēmu, un viņiem bija jāatrod cēlonis.

Pēc divām minÅ«tēm pamanÄ«ja, ka dzinēja bremžu pults vads (vilcienam katrā galā bija pa vienam dzinējam) ir atvienots no elektrÄ«bas skapja sienas un guļ uz releja, kas kontrolēja tualetes spraudņa solenoÄ«du... Kad relejs tika ieslēgts, tas radÄ«ja traucējumus bremžu trosē, un sistēmas aizsardzÄ«ba pret kļūmēm vienkārÅ”i ietvēra avārijas bremzÄ“Å”anu.

Vārti, kas ienīda FORTRAN

Pirms dažiem mēneÅ”iem mēs pamanÄ«jām, ka tÄ«kla savienojumi kontinentālajā daļā [tas bija Havaju salās] kļūst ļoti, ļoti lēni. Tas var ilgt 10-15 minÅ«tes un pēc tam pēkŔņi atkārtoties. Pēc kāda laika mans kolēģis man sÅ«dzējās par tÄ«kla savienojumiem kontinentālajā daļā vispār nestrādā. Viņam bija kāds FORTRAN kods, kas bija jāpārkopē uz cietzemes maŔīnu, taču tas nevarēja, jo "tÄ«kls neizturēja pietiekami ilgi, lai pabeigtu FTP augÅ”upielādi".

Jā, izrādÄ«jās, ka tÄ«kla kļūmes radās, kad kolēģis mēģināja FTP failu ar avota kodu FORTRAN uz maŔīnu cietzemē. Mēs mēģinājām arhivēt failu: pēc tam tas tika nokopēts gludi (bet mērÄ·a maŔīnai nebija atsaiņotāja, tāpēc problēma netika atrisināta). Beidzot mēs "sadalām" FORTRAN kodu ļoti mazos gabaliņos un nosÅ«tÄ«jām tos pa vienam. Lielākā daļa fragmentu tika nokopēti bez problēmām, bet daži gabali neizturēja vai pārgāja pēc tam ļoti daudz mēģinājumi.

Pārbaudot problemātiskās vietas, mēs atklājām, ka tiem ir kaut kas kopÄ«gs: tajos visos bija komentāru bloki, kas sākās un beidzās ar rindām, kas sastāv no lielajiem burtiem C (kā kolēģis deva priekÅ”roku komentÄ“Å”anai FORTRAN). Mēs nosÅ«tÄ«jām e-pastu tÄ«kla ekspertiem kontinentālajā daļā un lÅ«dzām palÄ«dzÄ«bu. Protams, viņi gribēja redzēt mÅ«su failu paraugus, kurus nevarēja pārsÅ«tÄ«t caur FTP... bet mÅ«su vēstules lÄ«dz viņiem nesasniedza. Beidzot mēs izdomājām vienkārÅ”u aprakstÄ«tkā izskatās nepārsÅ«tāmi faili. Tas izdevās :) [Vai es Å”eit varu pievienot piemēru vienam no problemātiskajiem FORTRAN komentāriem? DroÅ”i vien nav tā vērts!]

Beigās mums izdevās to izdomāt. Nesen tika uzstādÄ«ta jauna vārteja starp mÅ«su pilsētiņas daļu un cietzemes tÄ«klu. Tam bija MILZÄŖGAS grÅ«tÄ«bas pārsÅ«tÄ«t paketes, kurās bija atkārtoti C lielo burtu biti! Tikai dažas no Ŕīm paketēm var aizņemt visus vārtejas resursus un novērst lielāko daļu citu pakeÅ”u nokļūŔanu. Mēs sÅ«dzējāmies vārtejas ražotājam... un viņi atbildēja: ā€œAk, jā, jÅ«s saskaraties ar atkārtotu C kļūdu! Mēs jau zinām par viņu. ā€ Galu galā mēs problēmu atrisinājām, iegādājoties jaunu vārteju no cita ražotāja (iepriekŔējo aizstāvÄ«bai, nespēja pārsÅ«tÄ«t FORTRAN programmas dažiem var bÅ«t priekÅ”rocÄ«ba!).

Grūti laiki

Pirms dažiem gadiem, strādājot pie ETL sistēmas izveides Perlā, lai samazinātu 40. fāzes klÄ«nisko pētÄ«jumu izmaksas, man vajadzēja apstrādāt aptuveni 000 1 datumu. Divi no viņiem pārbaudÄ«jumu neizturēja. Tas mani pārāk nesatrauca, jo Å”ie datumi tika ņemti no klienta sniegtajiem datiem, kas bieži, teiksim, bija pārsteidzoÅ”i. Bet, pārbaudot sākotnējos datus, izrādÄ«jās, ka Å”ie datumi ir 2011. gada 1. janvāris un 2007. gada 30. janvāris. Man likās, ka kļūda ir tajā programmā, kuru tikko uzrakstÄ«ju, bet izrādÄ«jās, ka ir jau XNUMX gadi. vecs. Tas var likties noslēpumaini tiem, kas nav pazÄ«stami ar programmatÅ«ras ekosistēmu. Tā kā cita uzņēmuma jau sen bija pieņemts lēmums pelnÄ«t naudu, mans klients man samaksāja, lai izlabotu kļūdu, ko viens uzņēmums bija ieviesis nejauÅ”i, bet otrs ar nolÅ«ku. Lai jÅ«s saprastu, par ko es runāju, man ir jārunā par uzņēmumu, kas pievienoja funkciju, kas kļuva par kļūdu, kā arÄ« par dažiem citiem interesantiem notikumiem, kas veicināja noslēpumaino kļūdu, kuru es izlaboju.

Vecajos labajos laikos Apple datori dažreiz spontāni atiestatÄ«ja datumu uz 1. gada 1904. janvāri. Iemesls bija vienkārÅ”s: tas izmantoja ar akumulatoru darbināmu ā€œsistēmas pulksteniā€, lai sekotu datumam un laikam. Kas notika, kad akumulators nomira? Datori sāka izsekot datumam pēc sekunžu skaita kopÅ” laikmeta sākuma. Ar laikmetu mēs domājām atsauces sākotnējo datumu, un Macintosh datoriem tas bija 1. gada 1904. janvāris. Pēc tam, kad akumulators izlādējās, paÅ”reizējais datums tika atiestatÄ«ts uz norādÄ«to datumu. Bet kāpēc tas notika?

IepriekÅ” Apple izmantoja 32 bitus, lai saglabātu sekunžu skaitu kopÅ” sākotnējā datuma. Viens bits var saglabāt vienu no divām vērtÄ«bām - 1 vai 0. Divi biti var saglabāt vienu no četrām vērtÄ«bām: 00, 01, 10, 11. TrÄ«s biti - viena vērtÄ«ba no astoņām: 000, 001, 010, 011, 100 , 101, 110, 111 utt. Un 32 varētu saglabāt vienu no 232 vērtÄ«bām, tas ir, 4 294 967 296 sekundes. Apple datumiem tas bija aptuveni 136 gadi, tāpēc vecāki Mac nevar apstrādāt datumus pēc 2040. gada. Un, ja sistēmas akumulators izlādējas, datums tiek atiestatÄ«ts uz 0 sekundēm kopÅ” laikmeta sākuma, un jums ir manuāli jāiestata datums katru reizi, kad ieslēdzat datoru (vai lÄ«dz brÄ«dim, kad iegādājaties jaunu akumulatoru).

Tomēr Apple lēmums saglabāt datumus kā sekundes kopÅ” laikmeta nozÄ«mēja, ka mēs nevarējām apstrādāt datumus pirms laikmeta, kam bija tālejoÅ”as sekas, kā mēs redzēsim. Apple ieviesa funkciju, nevis kļūdu. Cita starpā tas nozÄ«mēja, ka Macintosh operētājsistēma bija imÅ«na pret ā€œtÅ«kstoÅ”gades kļūduā€ (ko nevarētu teikt par daudzām Mac lietojumprogrammām, kurām bija savas datumu sistēmas, lai apietu ierobežojumus).

Uz priekÅ”u. Mēs izmantojām Lotus 1-2-3, IBM "slepkavas lietojumprogrammu", kas palÄ«dzēja uzsākt datoru revolÅ«ciju, lai gan Apple datoriem bija VisiCalc, kas padarÄ«ja personālo datoru veiksmÄ«gu. GodÄ«gi sakot, ja nebÅ«tu parādÄ«jies 1-2-3, datori diez vai bÅ«tu pacēluÅ”ies, un personālo datoru vēsture varētu attÄ«stÄ«ties ļoti atŔķirÄ«gi. Lotus 1-2-3 1900. gadu nepareizi uzskatÄ«ja par garo gadu. Kad Microsoft izlaida savu pirmo izklājlapu Multiplan, tā ieņēma nelielu tirgus daļu. Un, uzsākot Excel projektu, viņi nolēma ne tikai kopēt rindu un kolonnu nosaukÅ”anas shēmu no Lotus 1-2-3, bet arÄ« nodroÅ”ināt kļūdu saderÄ«bu, apzināti uzskatot 1900. gadu par garo gadu. Å Ä« problēma pastāv arÄ« Å”odien. Tas ir, 1-2-3 tā bija kļūda, bet programmā Excel tas bija apzināts lēmums, kas nodroÅ”ināja, ka visi 1-2-3 lietotāji varēja importēt savas tabulas programmā Excel, nemainot datus, pat ja tie bija nepareizi.

Taču bija cita problēma. Pirmkārt, Microsoft izlaida programmu Excel operētājsistēmai Macintosh, kas neatpazina datumus pirms 1. gada 1904. janvāra. Un programmā Excel 1. gada 1900. janvāris tika uzskatÄ«ts par laikmeta sākumu. Tāpēc izstrādātāji veica izmaiņas, lai viņu programma atpazÄ«tu laikmeta veidu un saglabātu datus sevÄ« atbilstoÅ”i vēlamajam laikmetam. Microsoft pat uzrakstÄ«ja paskaidrojoÅ”u rakstu par to. Un Å”is lēmums noveda pie manas kļūdas.

Mana ETL sistēma saņēma Excel izklājlapas no klientiem, kas tika izveidotas operētājsistēmā Windows, taču tās varēja izveidot arÄ« Mac datorā. Tāpēc laikmeta sākums tabulā varētu bÅ«t vai nu 1. gada 1900. janvāris, vai 1. gada 1904. janvāris. Kā to noskaidrot? Excel faila formāts parāda nepiecieÅ”amo informāciju, bet parsētājs, kuru es izmantoju, to neparādÄ«ja (tagad to parāda), un pieņēma, ka jÅ«s zināt konkrētas tabulas laikmetu. Es, iespējams, varēju pavadÄ«t vairāk laika, lai izprastu Excel bināro formātu un nosÅ«tÄ«tu ielāpu parsētāja autoram, taču man bija daudz vairāk darāmā klienta labā, tāpēc es ātri uzrakstÄ«ju heiristisku, lai noteiktu laikmetu. Viņa bija vienkārÅ”a.

Programmā Excel datumu 5. gada 1998. jÅ«lijs var attēlot formātā "07-05-98" (nederÄ«ga Amerikas sistēma), "Jul 5, 98", "JÅ«lijs 5, 1998", "5-Jul-98" vai kāds cits formāts. vēl viens bezjēdzÄ«gs formāts (ironiskā kārtā viens no formātiem, ko mana Excel versija nepiedāvāja, bija ISO 8601). Tomēr tabulā neformatētais datums tika saglabāts kā "35981" epochai-1900 vai "34519" epochai-1904 (skaitļi norāda dienu skaitu kopÅ” laikmeta). Es vienkārÅ”i izmantoju vienkārÅ”u parsētāju, lai izvilktu gadu no formatētā datuma, un pēc tam izmantoju Excel parsētāju, lai izvilktu gadu no neformatētā datuma. Ja abas vērtÄ«bas atŔķīrās par 4 gadiem, tad zināju, ka izmantoju sistēmu ar epoch-1904.

Kāpēc es neizmantoju tikai formatētus datumus? Tā kā 5. gada 1998. jÅ«liju var formatēt kā "98. jÅ«lijs" ar zaudētu mēneÅ”a dienu. Mēs saņēmām tabulas no tik daudziem uzņēmumiem, kas tās veidoja tik dažādos veidos, ka datumu noteikÅ”ana bija mÅ«su (Å”ajā gadÄ«jumā man) ziņā. Turklāt, ja Excel ir pareizi, tad arÄ« mums vajadzētu!

Tajā paŔā laikā es saskāros ar 39082. AtgādināŔu, ka Lotus 1-2-3 uzskatÄ«ja 1900. gadu par garo gadu, un tas tika uzticÄ«gi atkārtots programmā Excel. Un tā kā 1900. gadam tika pievienota viena diena, daudzas datuma aprēķināŔanas funkcijas varētu bÅ«t nepareizas Å”ai dienai. Tas nozÄ«mē, ka 39082 varēja bÅ«t 1. gada 2011. janvāris (operētājsistēmā Mac) vai 31. gada 2006. decembris (operētājsistēmā Windows). Ja mans ā€œgadu parsētājsā€ no formatētās vērtÄ«bas izvilka 2011. gadu, tad viss ir kārtÄ«bā. Bet, tā kā Excel parsētājs nezina, kurÅ” laikmets tiek izmantots, tas pēc noklusējuma tiek iestatÄ«ts uz epoch-1900, atgriežot 2006. gadu. Mana lietojumprogramma redzēja, ka starpÄ«ba ir 5 gadi, uzskatÄ«ja to par kļūdu, reÄ£istrēja to un atgrieza neformatētu vērtÄ«bu.

Lai to apietu, es uzrakstīju Ŕo (pseidokods):

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

Un tad visi 40 000 datumi tika pareizi parsēti.

Lielu drukas darbu vidū

Astoņdesmito gadu sākumā mans tēvs strādāja Storage Technology, tagad neeksistējoŔā nodaļā, kas radÄ«ja lentes piedziņas un pneimatiskās sistēmas ātrgaitas lentes padevei.

Viņi pārveidoja diskus, lai tiem varētu bÅ«t viens centrālais ā€œAā€ diskdzinis, kas savienots ar septiņiem ā€œBā€ diskdziņiem, un mazā OS RAM, kas kontrolēja ā€œAā€ disku, varēja deleģēt lasÄ«Å”anas un rakstÄ«Å”anas darbÄ«bas visiem ā€œBā€ diskdziņiem.

Katru reizi, kad tika palaists disks ā€œAā€, ar ā€œAā€ savienotajā perifērijas diskdzinÄ« bija jāievieto diskete, lai operētājsistēma ielādētu tā atmiņā. Tas bija ārkārtÄ«gi primitÄ«vs: skaitļoÅ”anas jaudu nodroÅ”ināja 8 bitu mikrokontrolleris.

Šāda aprÄ«kojuma mērÄ·auditorija bija uzņēmumi ar ļoti lielām datu noliktavām ā€“ bankas, mazumtirdzniecÄ«bas tÄ«kli u.c. ā€“, kam vajadzēja drukāt daudz adreÅ”u uzlÄ«mju vai bankas izrakstu.

Vienam klientam radās problēma. Drukas darba laikā viens konkrēts diskdzinis ā€œAā€ var pārstāt darboties, izraisot visa darba apstāŔanos. Lai atjaunotu diska darbÄ«bu, darbiniekiem bija viss jāpārstartē. Un, ja tas notika seÅ”u stundu uzdevuma vidÅ«, tika zaudēts milzÄ«gs dārgais datora laiks un tika izjaukts visas operācijas grafiks.

TehniÄ·i tika nosÅ«tÄ«ti no Storage Technologies. Taču, neraugoties uz viņu pÅ«lēm, viņi nespēja atveidot kļūdu testa apstākļos: Ŕķita, ka tā radās lielu drukas darbu vidÅ«. Problēma nebija aparatÅ«rā, viņi nomainÄ«ja visu, ko varēja: RAM, mikrokontrolleri, diskeÅ”u disku, visas iespējamās lentes diska daļas - problēma saglabājās.

Tad tehniķi piezvanīja uz Ŕtābu un izsauca Ekspertu.

Eksperts paķēra krēslu un kafijas tasi, sēdēja datoru telpā ā€” tajos laikos tur bija telpas, kas bija paredzētas datoriem ā€” un skatÄ«jās, kā darbinieki sastāda rindā lielu drukas darbu. Eksperts gaidÄ«ja neveiksmi ā€” un tā arÄ« notika. Visi skatÄ«jās uz Ekspertu, bet viņam nebija ne jausmas, kāpēc tas notika. Tāpēc viņŔ lika atkal ievietot darbu rindā, un viss personāls un tehniÄ·i atgriezās darbā.

Eksperts atkal apsēdās krēslā un sāka gaidÄ«t neveiksmi. Pagāja apmēram seÅ”as stundas, un kļūme notika. Ekspertam atkal nebija nekādu ideju, izņemot to, ka viss notika telpā, kas bija piepildÄ«ta ar cilvēkiem. ViņŔ pavēlēja atsākt misiju, apsēdās un gaidÄ«ja.

Ar treŔo neveiksmi Eksperts kaut ko pamanīja. Kļūme radās, kad darbinieki mainīja lentes sveŔā diskdzinī. Turklāt kļūme notika, tiklīdz kāds no darbiniekiem izgāja cauri noteiktai flīzei uz grīdas.

Paaugstinātā grÄ«da tika izgatavota no alumÄ«nija flÄ«zēm, kas ieklātas 6 lÄ«dz 8 collu augstumā. Neskaitāmi datoru vadi stiepās zem paaugstinātās grÄ«das, lai neviens nejauÅ”i neuzkāptu uz svarÄ«ga kabeļa. FlÄ«zes tika ieklātas ļoti cieÅ”i, lai zem paceltās grÄ«das nenokļūtu gruži.

Eksperts saprata, ka viena no flÄ«zēm ir deformēta. Kad darbinieks uzkāpa uz tā stÅ«ra, flÄ«zes malas berzējās pret blakus esoÅ”ajām flÄ«zēm. Ar tām berzējās arÄ« plastmasas detaļas, kas savienoja flÄ«zes, kas izraisÄ«ja statiskas mikroizlādes, kas radÄ«ja radiofrekvenču traucējumus.

MÅ«sdienās operatÄ«vā atmiņa ir daudz labāk aizsargāta pret radiofrekvenču traucējumiem. Bet tajos gados tas tā nebija. Eksperts saprata, ka Å”ie traucējumi traucē atmiņu un lÄ«dz ar to arÄ« operētājsistēmas darbÄ«bu. ViņŔ piezvanÄ«ja atbalsta dienestam, pasÅ«tÄ«ja jaunas flÄ«zes, uzstādÄ«ja pats, un problēma pazuda.

Ir paisums!

Stāsts notika serveru telpā, Portsmutas biroja ceturtajā vai piektajā stāvā (manuprāt), doku zonā.

Kādu dienu Unix serveris ar galveno datu bāzi avarēja. Viņi viņu pārstartēja, bet viņŔ laimÄ«gs turpināja krist atkal un atkal. Nolēmām piezvanÄ«t kādam no atbalsta dienesta.

Atbalsta puisis... Man Ŕķiet, ka viņu sauca Marks, bet tam nav nozÄ«mes... Man Ŕķiet, ka es viņu nepazÄ«stu. Tas tieŔām nav svarÄ«gi. Paliksim pie Marka, labi? Lieliski.

Tātad pēc dažām stundām ieradās Marks (proti, tas nav tāls ceļŔ no LÄ«dsas lÄ«dz Portsmutai), ieslēdza serveri un viss darbojās bez problēmām. Tipisks sasodÄ«ts atbalsts, klients par to ļoti sarÅ«gtina. Marks apskata žurnālfailus un neatrod neko nevēlamu. Tāpēc Marks atkal iekāpj vilcienā (vai ar kādu transporta veidu viņŔ ieradās, cik es zinu, tā varēja bÅ«t kliba govs... vienalga, tas nav svarÄ«gi, labi?) un izŔķērdējies dodas atpakaļ uz LÄ«dsu. diena.

Tajā paŔā vakarā serveris atkal avarē. Stāsts tāds pats... serveris neceļas. Mark mēģina palÄ«dzēt attālināti, bet klients nevar startēt serveri.

Vēl viens vilciens, autobuss, citronu bezē vai kāds cits stulbums, un Marks ir atpakaļ Portsmutā. Paskaties, serveris sāk darboties bez problēmām! BrÄ«nums. Marks vairākas stundas pārbauda, ā€‹ā€‹vai ar operētājsistēmu vai programmatÅ«ru viss ir kārtÄ«bā, un dodas uz LÄ«dsu.

Ap dienas vidu serveris avarē (noņemiet mieru!). Å oreiz Ŕķiet saprātÄ«gi piesaistÄ«t aparatÅ«ras atbalsta cilvēkus, lai aizstātu serveri. Bet nē, pēc kādām 10 stundām arÄ« nokrÄ«t.

Situācija atkārtojās vairākas dienas. Serveris strādā, avarē pēc aptuveni 10 stundām un nesākas nākamās 2 stundas. Viņi pārbaudÄ«ja dzesÄ“Å”anu, atmiņas noplÅ«des, viņi visu pārbaudÄ«ja, bet neko neatrada. Tad avārijas apstājās.

Nedēļa pagāja bezrūpīgi... visi bija priecīgi. Priecīgs, līdz viss sākas no jauna. Bilde tāda pati. 10 stundas darba, 2-3 stundas dīkstāves...

Un tad kāds (man Ŕķiet, ka viņi man teica, ka Å”im cilvēkam nav nekāda sakara ar IT) teica:

"Tas ir paisums!"

Izsauciens tika sagaidÄ«ts ar tukÅ”iem skatieniem, un kāda roka, iespējams, vilcinājās pie droŔības izsaukuma pogas.

"Tas pārstāj darboties ar plūdmaiņu."

Å Ä·iet, ka IT atbalsta darbiniekiem tas ir pilnÄ«gi sveÅ”s jēdziens, kuri, visticamāk, nelasÄ«s Paisuma gadagrāmatu, sēžot pie kafijas. Viņi paskaidroja, ka tas nekādā veidā nevar bÅ«t saistÄ«ts ar paisumu, jo serveris jau nedēļu strādājis bez kļūdām.

"PagājuÅ”ajā nedēļā paisums bija zems, bet Å”onedēļ tas ir augsts."

Nedaudz terminoloÄ£ijas tiem, kam nav jahtas licences. PlÅ«dmaiņas ir atkarÄ«gas no Mēness cikla. Un, Zemei griežoties, ik pēc 12,5 stundām Saules un Mēness gravitācijas spēks rada paisuma vilni. 12,5 stundu cikla sākumā ir paisums, cikla vidÅ« bēgums un beigās atkal paisums. Taču, mainoties Mēness orbÄ«tai, mainās arÄ« atŔķirÄ«ba starp bēgumu un bēgumu. Kad Mēness atrodas starp Sauli un Zemi vai Zemes pretējā pusē (pilnmēness vai bez mēness), mēs iegÅ«stam Syzygyn plÅ«dmaiņas ā€“ augstākos paisumus un viszemākos bēgumus. Pusmēness laikā mēs iegÅ«stam kvadrātveida plÅ«dmaiņas - zemākās plÅ«dmaiņas. AtŔķirÄ«ba starp abām galējÄ«bām ievērojami samazinās. Mēness cikls ilgst 28 dienas: syzygian - kvadratÅ«ra - syzygian - kvadratÅ«ra.

Kad tehniÄ·iem tika izskaidrota paisuma spēku bÅ«tÄ«ba, viņi uzreiz nodomāja, ka jāsauc policija. Un diezgan loÄ£iski. Bet izrādās, ka puisim bija taisnÄ«ba. Divas nedēļas iepriekÅ” netālu no biroja pietauvojās iznÄ«cinātājs. Katru reizi, kad paisums to pacēla lÄ«dz noteiktam augstumam, kuÄ£a radara stabs nonāca serveru telpas grÄ«das lÄ«menÄ«. Un radars (vai elektroniskā kara tehnika, vai kāda cita militāra rotaļlieta) radÄ«ja haosu datoros.

RaÄ·etes lidojuma misija

Man tika uzdots portēt lielu (apmēram 400 tÅ«kstoÅ”u rindu) raÄ·eÅ”u palaiÅ”anas kontroles un uzraudzÄ«bas sistēmu uz jaunām operētājsistēmas, kompilatora un valodas versijām. PrecÄ«zāk, no Solaris 2.5.1 uz Solaris 7 un no Verdix Ada attÄ«stÄ«bas sistēmas (VADS), kas rakstÄ«ts Ada 83, uz Rational Apex Ada sistēmu, kas rakstÄ«ta Ada 95. VADS iegādājās Rational, un tā produkts tika novecojis, lai gan Rational mēģināja ieviest saderÄ«gas VADS pakotņu versijas, lai atvieglotu pāreju uz Apex kompilatoru.

TrÄ«s cilvēki man palÄ«dzēja tÄ«ri apkopot kodu. Pagāja divas nedēļas. Un tad es pats strādāju, lai sistēma darbotos. ÄŖsāk sakot, tā bija vissliktākā programmatÅ«ras sistēmas arhitektÅ«ra un ievieÅ”ana, ar kādu es biju sastapies, tāpēc portÄ“Å”anas pabeigÅ”ana prasÄ«ja vēl divus mēneÅ”us. Pēc tam sistēma tika nodota testÄ“Å”anai, kas ilga vēl vairākus mēneÅ”us. TÅ«lÄ«t izlaboju testÄ“Å”anas laikā konstatētās kļūdas, taču to skaits strauji samazinājās (avota kods bija ražoÅ”anas sistēma, tāpēc tā funkcionalitāte darbojās diezgan droÅ”i, tikai nācās noņemt kļūdas, kas radās adaptācijas laikā jaunajam kompilatoram). Galu galā, kad viss darbojās kā nākas, mani pārcēla uz citu projektu.

Un piektdien pirms Pateicības dienas iezvanījās telefons.

RaÄ·etes palaiÅ”anu bija paredzēts pārbaudÄ«t aptuveni trÄ«s nedēļu laikā, un laika atskaites laboratorijas testu laikā komandu secÄ«ba tika bloķēta. Reālajā dzÄ«vē tas pārtrauktu pārbaudi, un, ja bloÄ·Ä“Å”ana notiktu dažu sekunžu laikā pēc dzinēja iedarbināŔanas, palÄ«gsistēmās notiktu vairākas neatgriezeniskas darbÄ«bas, kas prasÄ«tu ilgstoÅ”u un dārgu raÄ·etes gatavÄ«bu. Tas nebÅ«tu sācies, bet daudzi cilvēki bÅ«tu ļoti sarÅ«gtināti par zaudēto laiku un daudz, daudz naudas. Neļaujiet nevienam jums teikt, ka AizsardzÄ«bas departaments tērē naudu neapdomÄ«gi ā€” es nekad neesmu saticis lÄ«gumslēdzēju vadÄ«tāju, kurÅ” nebÅ«tu noteicis budžetu pirmajā vai otrajā vietā un tam sekotu grafiks.

IepriekŔējos mēneÅ”os Å”is atpakaļskaitÄ«Å”anas izaicinājums tika veikts simtiem reižu dažādās variācijās, tikai ar dažām nelielām žagas. Tātad iespējamÄ«ba, ka tas notiks, bija ļoti zema, bet tā sekas bija ļoti nozÄ«mÄ«gas. Reiziniet abus Å”os faktorus, un jÅ«s sapratÄ«sit, ka ziņas man un desmitiem inženieru un vadÄ«tāju paredzēja sabojātu brÄ«vdienu nedēļu.

Un uzmanība tika pievērsta man kā personai, kas pārnesa sistēmu.

Tāpat kā lielākajā daļā droŔības sistēmu, tika reÄ£istrēti daudzi parametri, tāpēc bija diezgan viegli identificēt dažas koda rindiņas, kas tika izpildÄ«tas pirms sistēmas avārijas. Un, protams, tajos nebija nekā neparasta; tie paÅ”i izteicieni tika veiksmÄ«gi izpildÄ«ti burtiski tÅ«kstoÅ”iem reižu viena un tā paÅ”a skrējiena laikā.

Mēs aicinājām cilvēkus no Apex par Rational, jo viņi bija tie, kas izstrādāja kompilatoru, un dažas no viņu izstrādātajām rutīnām tika izsauktas aizdomīgajā kodā. Viņus (un visus pārējos) iespaidoja tas, ka ir jāatrodas burtiski valstiski nozīmīgas problēmas saknē.

Tā kā žurnālos nebija nekā interesanta, mēs nolēmām mēģināt atveidot problēmu vietējā laboratorijā. Tas nebija viegls uzdevums, jo notikums notika aptuveni reizi 1000 skrējienos. Viens no iespējamiem iemesliem bija tas, ka izsaukums uz pārdevēja izstrādātu mutex funkciju (daļa no VADS migrācijas pakotnes) Unlock nenoveda pie atbloÄ·Ä“Å”anas. Apstrādes pavediens, kas izsauca funkciju, apstrādāja sirdsdarbÄ«bas ziņojumus, kas nomināli tika saņemti katru sekundi. Pacēlām frekvenci lÄ«dz 10 Hz, tas ir, 10 reizes sekundē, un sākām skriet. Apmēram stundu vēlāk sistēma bloķējās. Žurnālā mēs redzējām, ka ierakstÄ«to ziņojumu secÄ«ba bija tāda pati kā neveiksmÄ«gā testa laikā. Mēs veicām vēl vairākus braucienus, sistēma pastāvÄ«gi tika bloķēta 45-90 minÅ«tes pēc starta, un katru reizi žurnālā bija viens un tas pats marÅ”ruts. Lai gan mēs tehniski izmantojām atŔķirÄ«gu kodu ā€” ziņojumu biežums bija atŔķirÄ«gs ā€” sistēmas darbÄ«ba bija tāda pati, tāpēc bijām pārliecināti, ka Å”is ielādes scenārijs izraisa to paÅ”u problēmu.

Tagad mums vajadzēja noskaidrot, kur tieÅ”i izteiksmju secÄ«bā notika bloÄ·Ä“Å”ana.

Å ajā sistēmas ievieÅ”anā tika izmantota Ada uzdevumu sistēma, un tā tika izmantota neticami slikti. Uzdevumi ir augsta lÄ«meņa vienlaikus izpildāma konstrukcija programmā Ada, kaut kas lÄ«dzÄ«gs izpildes pavedieniem, kas ir iebÅ«vēti tikai paŔā valodā. Kad diviem uzdevumiem ir jāsazinās, tie "nosaka tikÅ”anos", apmainās ar nepiecieÅ”amajiem datiem un pēc tam pārtrauc tikÅ”anos un atgriežas pie neatkarÄ«gas izpildes. Tomēr sistēma tika ieviesta atŔķirÄ«gi. Pēc tam, kad mērÄ·a uzdevums tika satikts, Å”is mērÄ·a uzdevums tika satikts ar citu uzdevumu, kas pēc tam tika satikts ar treÅ”o uzdevumu un tā tālāk, lÄ«dz tika pabeigta apstrāde. Pēc tam visas Ŕīs tikÅ”anās tika pabeigtas, un katram uzdevumam bija jāatgriežas tā izpildē. Tas nozÄ«mē, ka mums bija darÄ«Å”ana ar pasaulē dārgāko funkciju izsaukÅ”anas sistēmu, kas apturēja visu ā€œdaudzuzdevumuā€ procesu, kamēr tā apstrādāja daļu no ievades datiem. Un iepriekÅ” tas neradÄ«ja problēmas tikai tāpēc, ka caurlaidspēja bija ļoti zema.

Es aprakstÄ«ju Å”o uzdevumu mehānismu, jo tad, kad tika pieprasÄ«ta tikÅ”anās vai tā tiks pabeigta, var notikt "uzdevuma maiņa". Tas nozÄ«mē, ka procesors varētu sākt apstrādāt citu uzdevumu, kas ir gatavs izpildei. Izrādās, ka tad, kad viens uzdevums ir gatavs satikties ar citu uzdevumu, var sākt izpildÄ«t pavisam citu uzdevumu, un galu galā vadÄ«ba atgriežas pirmajā tikÅ”anās reizē. Var rasties arÄ« citi notikumi, kuru dēļ uzdevums tiek pārslēgts; viens no Ŕādiem notikumiem ir sistēmas funkcijas izsaukums, piemēram, drukāŔana vai mutex izpilde.

Lai saprastu, kura koda rindiņa rada problēmu, man bija jāatrod veids, kā reÄ£istrēt progresu, izmantojot paziņojumu secÄ«bu, neaktivizējot uzdevuma slēdzi, kas novērstu avārijas raÅ”anos. Tāpēc es nevarēju izmantot priekÅ”rocÄ«bas Put_Line()lai izvairÄ«tos no I/O operāciju veikÅ”anas. Es varētu iestatÄ«t skaitÄ«tāja mainÄ«go vai kaut ko lÄ«dzÄ«gu, bet kā es varu redzēt tā vērtÄ«bu, ja es to nevaru parādÄ«t ekrānā?

Tāpat, pārbaudot žurnālu, atklājās, ka, neskatoties uz sirdsdarbības ziņojumu apstrādes sastingumu, kas bloķēja visas procesa I/O darbības un neļāva veikt citu apstrādi, citi neatkarīgi uzdevumi turpinājās. Tas ir, darbs netika bloķēts pilnībā, tikai (kritiska) uzdevumu ķēde.

Tas bija pavediens, kas vajadzÄ«gs, lai novērtētu bloķējoÅ”o izteiksmi.

Es izveidoju Ada pakotni, kurā bija uzdevums, uzskaitÄ«ts veids un Ŕāda veida globālais mainÄ«gais. Neskaitāmi literāļi bija saistÄ«ti ar konkrētām problemātiskās secÄ«bas izteiksmēm (piem. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), un pēc tam tajā ievietoja pieŔķirÅ”anas izteiksmes, kas globālajam mainÄ«gajam pieŔķīra atbilstoÅ”o uzskaitÄ«jumu. Tā kā visa Ŕī objekta kods vienkārÅ”i saglabāja konstanti atmiņā, uzdevumu pārslēgÅ”ana tās izpildes rezultātā bija ārkārtÄ«gi maz ticama. Mums galvenokārt bija aizdomas par izteiksmēm, kas varētu mainÄ«t uzdevumu, jo bloÄ·Ä“Å”ana notika izpildes laikā, nevis atgriezās, pārslēdzot uzdevumu atpakaļ (vairāku iemeslu dēļ).

IzsekoÅ”anas uzdevums vienkārÅ”i darbojās ciklā un periodiski pārbaudÄ«ja, vai globālā mainÄ«gā vērtÄ«ba ir mainÄ«jusies. Ar katru izmaiņu vērtÄ«ba tika saglabāta failā. Pēc tam Ä«sa gaidÄ«Å”ana un jauna pārbaude. MainÄ«go ierakstÄ«ju failā, jo uzdevums tika izpildÄ«ts tikai tad, kad sistēma to izvēlējās izpildei, pārslēdzot uzdevumu problēmzonā. NeatkarÄ«gi no tā, kas notika Å”ajā uzdevumā, tas neietekmēs citus nesaistÄ«tus bloķētos uzdevumus.

Bija paredzēts, ka, sistēmai sasniedzot problemātiskā koda izpildes punktu, globālais mainÄ«gais tiks atiestatÄ«ts, pārejot uz katru nākamo izteiksmi. Tad notiks kaut kas, kas liek uzdevumam pārslēgties, un, tā kā tā izpildes frekvence (10 Hz) ir zemāka nekā pārraudzÄ«bas uzdevumam, monitors varētu uztvert globālā mainÄ«gā vērtÄ«bu un to ierakstÄ«t. Parastā situācijā es varētu iegÅ«t atkārtotu uzskaitÄ«jumu apakÅ”kopas secÄ«bu: mainÄ«gā pēdējās vērtÄ«bas uzdevuma pārslēgÅ”anas brÄ«dÄ«. UzkarināŔanas laikā globālajam mainÄ«gajam vairs nevajadzētu mainÄ«ties, un pēdējā ierakstÄ«tā vērtÄ«ba norāda, kura izteiksme netika pabeigta.

Es palaidu kodu ar izsekoÅ”anu. ViņŔ sastinga. Un uzraudzÄ«ba darbojās kā pulkstenis.

Žurnālā bija sagaidāmā secÄ«ba, kuru pārtrauca vērtÄ«ba, kas norādÄ«ja, ka ir izsaukts mutex Unlock, un uzdevums nav izpildÄ«ts ā€“ kā tas ir tÅ«kstoÅ”iem iepriekŔējo zvanu gadÄ«jumā.

Apex inženieri Å”ajā laikā drudžaini analizēja savu kodu un atrada vietu mutex, kur teorētiski varētu rasties bloÄ·Ä“Å”ana. Bet tā varbÅ«tÄ«ba bija ļoti zema, jo tikai noteikta notikumu secÄ«ba, kas notiek noteiktā laikā, varēja izraisÄ«t bloÄ·Ä“Å”anu. Mērfija likums, puiÅ”i, tas ir Mērfija likums.

Lai aizsargātu vajadzÄ«go koda fragmentu, es aizstāju mutex funkciju izsaukumus (izveidots uz OS mutex funkcionalitātes) ar nelielu vietējo Ada mutex pakotni, lai kontrolētu mutex piekļuvi Å”im fragmentam.

Es ievietoju to kodā un veicu testu. Septiņas stundas vēlāk kods joprojām darbojās.

Mans kods tika iesniegts Rational, kur viņi to apkopoja, izjauca un pārbaudīja, vai tajā nav izmantota tā pati pieeja, kas tika izmantota problemātiskajās mutex funkcijās.

Å is bija manas karjeras vispilnÄ«gākais kodu apskats šŸ™‚ Telpā kopā ar mani bija apmēram desmit inženieri un vadÄ«tāji, vēl desmit cilvēki piedalÄ«jās konferences zvanā ā€” un viņi visi pārbaudÄ«ja apmēram 20 koda rindiņas.

Kods tika pārskatÄ«ts, jauni izpildāmie faili tika samontēti un iesniegti oficiālai regresijas pārbaudei. Pēc pāris nedēļām atpakaļskaitÄ«Å”anas tests bija veiksmÄ«gs, un raÄ·ete pacēlās gaisā.

Labi, tas viss ir labi, bet kāda ir stāsta jēga?

Tā bija absolÅ«ti pretÄ«ga problēma. Simtiem tÅ«kstoÅ”u koda rindu, paralēla izpilde, vairāk nekā ducis mijiedarbÄ«gu procesu, slikta arhitektÅ«ra un slikta ievieÅ”ana, iegulto sistēmu saskarnes un miljoniem iztērēti dolāru. Bez spiediena, pareizi.

Es nebiju vienÄ«gais, kurÅ” strādāja pie Ŕīs problēmas, lai gan es biju uzmanÄ«bas centrā, jo es veicu pārneÅ”anu. Bet, lai gan es to izdarÄ«ju, tas nenozÄ«mē, ka es sapratu visus simtiem tÅ«kstoÅ”u koda rindiņu vai pat tos pārlasÄ«ju. Kodu un žurnālus analizēja inženieri visā valstÄ«, bet, kad viņi man izstāstÄ«ja savas hipotēzes par kļūmes cēloņiem, man vajadzēja tikai pusminÅ«ti, lai tās atspēkotu. Un, kad man lÅ«dza analizēt teorijas, es to nodevu kādam citam, jo ā€‹ā€‹man bija skaidrs, ka Å”ie inženieri iet nepareizo ceļu. Izklausās pārgalvÄ«gi? Jā, tā ir taisnÄ«ba, bet es noraidÄ«ju hipotēzes un pieprasÄ«jumus cita iemesla dēļ.

Es sapratu problēmas būtību. Es precīzi nezināju, kur tas notiek un kāpēc, bet es zināju, kas notiek.

Gadu gaitā esmu uzkrājis daudz zināŔanu un pieredzes. Es biju viens no Ada lietoÅ”anas pionieriem un sapratu tās priekÅ”rocÄ«bas un trÅ«kumus. Es zinu, kā Ada izpildlaika bibliotēkas apstrādā uzdevumus un nodarbojas ar paralēlu izpildi. Un es saprotu zema lÄ«meņa programmÄ“Å”anu atmiņas, reÄ£istru un montētāja lÄ«menÄ«. Citiem vārdiem sakot, man ir dziļas zināŔanas savā jomā. Un es tos izmantoju, lai atrastu problēmas cēloni. Es ne tikai apstrādāju kļūdu, bet arÄ« sapratu, kā to atrast ļoti jutÄ«gā izpildlaika vidē.

Šādi stāsti par cīņu ar kodu nav Ä«paÅ”i interesanti tiem, kuri nav pazÄ«stami ar Ŕādas cīņas iezÄ«mēm un nosacÄ«jumiem. Taču Å”ie stāsti palÄ«dz mums saprast, kas nepiecieÅ”ams, lai atrisinātu patieŔām sarežģītas problēmas.

Lai atrisinātu patieŔām smagas problēmas, jums ir jābÅ«t vairāk nekā tikai programmētājam. Jums ir jāsaprot koda ā€œliktenisā€, kā tas mijiedarbojas ar vidi un kā darbojas pati vide.

Un tad jums būs sava sabojātā svētku nedēļa.

Turpināsim.

Avots: www.habr.com

Pievieno komentāru