Perkėlimas į didesnes darbo erdves be ilgesnio laukimo kam nors

Kiekvienas Mythex projektas turi savo darbo erdvę: mažą debesų kompiuterį, kuriame agentas rašo kodą ir veikia jūsų programėlės peržiūra. Naujas darbo erdves buvome pakėlę nuo 1 GB iki 2 GB atminties, bet senosios liko su 1 GB — tą dieną, kai patikrinome, apie ketvirtadalį jų. Mūsų pirmasis sprendimas perkeldavo projektą į didesnę darbo erdvę, kai jis būdavo vėl atidaromas. Pirmąją gamybos dieną tai vienam žmogui lėmė septynių minučių laukimą. Nustatėme griežtą laiko ribą, o vėliau perkėlimą visai pašalinome iš projekto atidarymo.

Kodėl senos darbo erdvės liko mažos

Mūsų sandbox teikėjas nustato darbo erdvės dydį jai sukūrus ir jį išlaiko per visus sustabdymus ir atnaujinimus. Šablono keitimas — receptas, pagal kurį kuriamos naujos darbo erdvės — paveikia tik po pakeitimo sukurtas erdves. Egzistuojančių erdvių dydžio niekas nekeičia.

Tai turėjo reikšmės. Viena iš mažų erdvių git push metu, kol jos peržiūra dar startavo, baigėsi atmintis ir ji 11 minučių nereagavo. Dėl to nepavyko publikavimas.

Pirmas bandymas: perkelti projektą, kai jis pabunda

Darbo erdvės sustoja, kai niekas jų nenaudoja, ir pabunda, kai projektas atidaromas. Pabudimas atrodė tinkamas momentas perkelti projektą, nes tuo metu dar niekas juo nedirba.

Perkėlimas veikė taip:

Patikrinti dydį. Jei erdvė mažesnė nei 2 GB, ją perkelti. Jei dydis nežinomas, nieko nedaryti.
Nekliudyti publikavimo. Publikavimas nuskaito erdvės failus, todėl jei jis vyksta, perkėlimą praleisti.
Supakuoti projektą. Suarchyvuoti visą projektą — įskaitant git istoriją, t. y. visus projekto kontrolinius taškus, ir programėlės .env failą, kuris priklauso savininkui — bet palikti įdiegtas priklausomybes (node_modules), kurias galima įdiegti iš naujo.
Kopijuoti tiesiogiai. Archyvą perduoti iš senos erdvės į naują 2 GB erdvę srautu, kad jis niekada netilptų mūsų serverio atmintyje.
Palyginti prieš perjungiant. Abiejose erdvėse suskaičiuoti failus, perskaityti naujausią kontrolinį tašką ir suskaičiuoti kontrolinius taškus. Perjungti tik tada, kai visi trys sutampa.
Esant bet kokiai klaidai, palikti seną erdvę. Bet kokia klaida ar neatitikimas sunaikina naują erdvę, o projektas atidaromas senoje, kaip anksčiau.

Viena palyginimo detalė svarbesnė, nei atrodo. Tikrinimas vykdomas administratoriaus paskyra, o git nenori skaityti repozitorijos, kurią priklauso kitam vartotojui. Abiejose pusėse jis nieko neišspausdino — ir „nieko“ sutapo su „nieko“, todėl tikrinimas praėjo, nelyginant jokios istorijos nepalygindamas. Nurodėme git pasitikėti katalogu ir pridėjome testą, kad taip vėl neįvyktų.

Kas nutiko pirmąją dieną

Pirmąją gamybos dieną vieno projekto pakavimas užkliuvo už penkių minučių komandos laiko ribos — tai įvyko pabudimo metu. Savininkas laukė septynias minutes, kol jo erdvė atsidarė. Kadangi perkėlimas nepavyko, projektas liko mažas, todėl kitas atidarymas bandytų dar kartą ir privers žmogų laukti vėl.

Migracija, kuri verčia žmogų laukti atidarant savo projektą, yra blogas kompromisas. Visas tikslas buvo tas, kad niekas nepastebės.

Antras bandymas: griežtas biudžetas

Tą pačią dieną pakeitėme keturis dalykus:

Viena minutė visam perkėlimui. Visi žingsniai — dydžio tikrinimas, pakavimas, naujos erdvės kūrimas, kopijavimas, išpakavimas ir palyginimas — dalijasi viena 60 sekundžių biudžeto riba. Jai pasibaigus, projektas atidaromas senoje erdvėje.
Sustabdyti darbą, ne tik laukimą. Nepakanka atsisakyti laukti mūsų pusėje, jei archyvavimas vis dar vyksta erdvėje, kurią savininkas ketina naudoti. Kiekviena archyvavimo komanda dabar nutraukiama pačioje erdvėje, prieš pat biudžeto pabaigą. Jei nauja erdvė atkeliauja jau pasibaigus laikui, ji išmetama.
Nelaukti valymo savininko. Laikino archyvo šalinimas dabar vyksta fone.
Nebandyti iš naujo kiekvieną kartą. Projektas, kurio nepavyko perkelti, 24 valandas paliekamas ramybėje, todėl nesėkmė kainuoja ne daugiau kaip vieną delsą per dieną, o ne po vieną kiekvienam atidarymui.

Trečias bandymas: išimti iš pabudimo

Tai sumažino blogiausią atvejį iki vienos minutės. Bet minutė vis tiek yra minutė, ir supratome, kad perkėlimas iš viso neturėjo būti kieno nors kelyje.

Dabar joks darbo erdvė nebesukuriama 1 GB dydžio. Taigi tai nėra nuolatinis procesas; tai vienkartinis darbas su fiksuotu darbo erdvių sąrašu. Vykdant jį pabudimo metu, tikras žmogus mokėjo už kiekvieną lėtą perkėlimą, o vienintelis būdas sužinoti, kad erdvė neperkeliama, buvo tai, kad kažkas ką tik laukė.

Todėl perkėlimą visiškai pašalinome iš pabudimo. Projekto atidarymas veikia kaip anksčiau. Likusios mažos erdvės tvarkomos kaip prižiūrimas paketas: niekas jo nelaukia, o erdvė, kurios nepavyksta perkelti, pasirodo paketo ataskaitoje, kur galime į ją pažiūrėti, o ne prieš savininką.

Ką iš to išmokome

Dydžio keisti ne visada įmanoma. Kai platforma nustato dydį sukūrimo metu, numatytojo dydžio didinimas padeda tik naujiems dalykams. Planuokite senus.
„Dar niekas to nenaudoja“ vis tiek reiškia, kad kažkas laukia. Darbas, atliekamas kelyje į produktą, yra darbas, kurį žmogus stebi.
Dėkite biudžetą visam, kas yra vartotojo kelyje, ir sustabdykite darbą, kai biudžetas baigiasi. Laiko ribos nustatymas mūsų pusėje, kol komanda vis dar veikia kitur, tik perkelia problemą.
Vienkartinė migracija priklauso vienkartiniam darbui. Paslėpta kasdieniuose veiksmuose, ji lengviau parašoma, bet brangiau vykdoma.
Testuokite savo saugos patikras. Palyginimas, kuris nieko nepalygina, atrodo lygiai taip pat kaip tas, kuris praėjo.

Jei kuriate Mythex, nieko daryti nereikia: tikslas — mažiau darbo erdvių, kurioms išsenka atmintis, o projekto atidarymas toks pat greitas kaip anksčiau. Kaip darbo erdvės sustabdomos ir pabundamos, aprašyta dokumentacijoje: privati darbo erdvė. Kitą atminties išsekimo istoriją rasite atminties išsekimo gedimas, paslėptas progreso etiketėje.