Inseneeria

Inseneeria

Kuidas Mythexit ehitatakse ja käitatakse, sh mis katki läks ja kuidas me selle parandasime.

• Ebaõnnestunud uuesti avaldamine ei kustuta kunagi töötavat tagarakendust — Ebaõnnestunud uuesti avaldamine võis kustutada elava API või jätta katkise versiooni tööle. Kolm parandust, kuidas Mythex nurjunud avaldamise tagasi võtab.
• Hoiatused, mis käivituvad üks kord, mitte igas serveris — Hoiatus, mis peaks jõudma kord päevas, saabus ühe pärastlõuna jooksul viis korda. Miks mälusisene dubleerimine kahe serveri ja deploy-dega ei tööta.
• Suuremate töötubade juurde liikumine nii, et keegi ei pea ootama — Veerand töötubadest jäi pärast 2 GB-le üleminekut 1 GB peale. Esimene parandus pani ühe inimese seitsmeks minutiks ootama. Mida muutsime.
• Andmebaaside arveldamine selle järgi, mida need tegelikult kasutavad — Varem hindasime iga rakenduse andmebaasi kulu ja hinnang eksis mõlemas suunas. Nüüd arvestatakse iga andmebaasi mõõdetud kasutuse järgi, tunni kaupa.
• Kohe pärast avaldamist kokkukukkuvate rakenduste püüdmine — Kolm avaldamist läbisid tervisekontrolli, kuigi API kukkus iga käivituse paari sekundi järel kokku. Põhjus: krahhide lugemine viiekohalises nimekirjas.
• Pildirohkete agendikäikude hoidmine mälu piires — Agendikäik, mis vaatas kataloogi skaneeringuid, jooksis mälust välja 952 MB juures. Kolm põhjust, mis hoidsid pilte liiga kaua, ja nende parandused.
• Pikkade agendikäikude hoidmine kontekstiakna sees — Alamagendid kasvasid, kuni mudel need tagasi lükkas, peatusid varakult või eksisid vene keele žetoonidega. Kolm parandust, mis lasevad pikal tööl lõppeda.
• Vestluse elushoidmine, kui telefon magab — Telefonid magavad ja vahetavad vahelehti. Kaks viga tegid vestluse aeglaseks ja näitasid pärast pooleldi vastust. Kuidas need leidsime ja parandasime.
• Kuidas üks raske vestlus oleks võinud API maha võtta — 28. septembril jooksid mõlemad meie API serverid korraga mälust välja. Esimene parandus oli rohkem mälu; tegelik oli ajaloo laadimine suuruse, mitte arvu järgi.
• Publish'i kaks korda vajutamine avaldab nüüd ühe korra — Sama rakenduse kolm avaldamispäringut jõudsid API-sse 84 ms vahega ja käivitasid kolm juurutust. Kuidas andmebaas otsustab, kes avaldab.
• SEO õppetunnid oma saidi parandamisest — Dubleeritud KKK-märgistus, vale pisipilt Google'is, mallilehed ilma klõpsudeta ja tee, mille meie serv keeldus. Mida leidsime mythex.ai-l ja parandasime.
• Staatilised saidid jäävad üles ka uuesti avaldamise ajal — Staatilise saidi uuesti avaldamine tühjendas saidi enne uue ehituse üleslaadimist. Nüüd teenindab vana sait, kuni uus on paigas, ja muudatused ilmuvad sekunditega.
• Mälu täitumise viga, mis peitus edenemisindikaatoris — Meie agent jooksis mälust välja, kui kirjutas ühte suurt faili. Põhjus polnud mudel ega alamagendid, vaid olekusilt, mis saadeti uuesti 41 000 korda.
• Puuduv swap-fail, mis külmutas meie serverid — Tootmisserver lakkas vastamast ilma kokku kukkumata: swap-ruumita masinas lehtpuhvri pidev ümberlaadimine. Mis juhtus ja mida muutsime.
• Andmebaaside ärkamine ilma surnud ühendusteta — Avaldatud rakendus, mis ärkas unerežiimist, hoidis esimest päringut 10–12 sekundit andmebaasiühenduste najal, mis olid une ajal surnud. Kuidas saime selle 2,3 sekundini.
• Piirasime ise oma teenuseid — Meie API aadressipõhine piirang käsitles meie enda teenuseid nagu ühte inimest ja tootmises said need 429-vigu. Kuidas leidsime ja parandasime.
• Miks viisime Mythexi serverid ARM-ile — Kui raske töö kolis projektipõhistesse liivakastidesse, kasutasid meie serverid vaid kolmandiku mälust. Väiksemad ARM-instantsid vähendasid kulu umbes 30%.
• Kuidas saime deploy-d nullini 502-vigadeni — Valvur, mis võitles deploy-dega, ja koormusjaotaja, mis märkas liiga hilja: kuidas leidsime mõlemad, parandasime need ja langetasime deploy-d 10 502-st nullini.