Преминаване към по-големи работни пространства без чакане за никого

Всеки проект в Mythex получава собствено работно пространство: малък облачен компютър, на който агентът пише код и на който работи прегледът на приложението ти. Бяхме повишили новите работни пространства от 1 GB памет на 2 GB, но по-старите останаха на 1 GB — в деня, в който проверихме, около една четвърт от тях. Първата ни корекция местеше проекта към по-голямо работно пространство при следващото му отваряне. В първия му ден в продукцията това накара един човек да чака седем минути. Тогава сложихме строго времево ограничение, а после изобщо махнахме преместването от отварянето на проект.

Защо старите работни пространства останаха малки

Доставчикът ни на средата задава размера на работното пространство при създаването му и го запазва през всяко паузиране и възобновяване. Промяната на шаблона — рецептата, по която се създават новите работни пространства — засяга само работни пространства, създадени след промяната. Нищо не преоразмерява съществуващите.

Това имаше значение. Едно от малките работни пространства остана без памет по време на git push, докато прегледът му се стартираше, и не отговаряше 11 минути. Публикуване се провали заради това.

Първи опит: преместване на проекта при събуждане

Работните пространства се паузират, когато никой не ги използва, и се събуждат при отваряне на проекта. Събуждането изглеждаше правилният момент да се премести проект, защото никой още не работи в него.

Преместването работеше така:

Провери размера. Ако работното пространство е по-малко от 2 GB, премести го. Ако размерът е неизвестен, не прави нищо.
Не смущавай публикуване. Публикуването чете файловете на работното пространство, затова ако има такова в ход, пропусни преместването.
Опаковай проекта. Архивирай всичко в проекта — включително историята му в git, която е всяка контролна точка, която проектът има, и файла .env на приложението, който принадлежи на собственика — но пропусни инсталираните зависимости (node_modules), които могат да се инсталират отново.
Прехвърли го директно. Потокът на архива се предава от старото работно пространство в ново, 2 GB, така че никога не трябва да се побира в паметта на нашия собствен сървър.
Сравни преди превключване. Преброй файловете, прочети последната контролна точка и преброй контролните точки, и в двете работни пространства. Превключвай, само ако и трите съвпаднат.
При всяка грешка запази старото. Всяка грешка или несъвпадение изхвърля новото работно пространство и отваря проекта в старото, както преди.

Една подробност при сравнението беше по-важна, отколкото изглежда. Проверката работи като администраторския акаунт, а git отказва да чете хранилище, притежавано от друг потребител. Тя не отпечата нищо и от двете страни — и „нищо“ съвпадна с „нищо“, така че проверката мина, без изобщо да сравни историята. Казахме на git да се довери на директорията и добавихме тест, така че това да не се повтори.

Какво се обърка в първия ден

В първия ден в продукцията опаковането на един проект удари петминутен лимит на команда — вътре в събуждането. Собственикът чака седем минути, докато работното му пространство се отвори. А понеже преместването се беше провалило, проектът остана малък и следващото отваряне щеше да опита отново и да го накара да чака пак.

Миграция, която кара някого да чака, докато отваря собствения си проект, е лоша сделка. Целта на това да се прави при събуждане беше никой да не забележи.

Втори опит: твърд бюджет

Същия ден променихме четири неща:

Една минута за цялото преместване. Всяка стъпка — проверка на размера, опаковане, създаване на новото работно пространство, копиране, разопаковане, сравнение — дели един бюджет от 60 секунди. Когато той свърши, проектът се отваря в старото работно пространство.
Спри работата, не само чакането. Отказът от наша страна не е достатъчен, ако архивирането още работи вътре в работното пространство, което собственикът ще използва. Всяка команда за архивиране сега се прекратява вътре в работното пространство малко преди бюджетът да свърши. Ако новото работно пространство пристигне, след като сме се отказали, се изхвърля.
Не карай собственика да чака почистване. Изтриването на временния архив вече се случва на заден план.
Не опитвай отново при всяко отваряне. Проект, който не може да се премести, се оставя на мира 24 часа, така че една грешка струва най-много едно забавяне на ден, а не по едно при всяко отваряне.

Трети опит: махни го от събуждането

Това направи най-лошия случай една минута. Но минута си остава минута, и осъзнахме, че преместването изобщо не трябва да е на нечий път.

Вече не се създава работно пространство с 1 GB. Значи това не е продължащ процес; това е еднократна задача с фиксиран списък от работни пространства. Правенето ѝ при събуждане означаваше, че реален човек плаща за всяко бавно преместване, а единственият начин да разберем, че някое работно пространство няма да се премести, беше някой току-що да е чакал за него.

Затова премахнахме преместването от събуждането изцяло. Отварянето на проект работи, както преди. Останалите малки работни пространства се обработват като контролирана партида: никой не чака за това, а работно пространство, което не може да се премести, се появява в доклада на партидата, където можем да го разгледаме, вместо пред човека, който е негов собственик.

Какво взехме от това

Преоразмеряването не винаги е възможно. Когато платформа фиксира размера при създаването, повишаването на стойността по подразбиране помага само на новите неща. Планирай за старите.
„Никой още не го използва“ все пак означава, че някой чака. Работата, извършена по пътя към продукт, е работа, която човек наблюдава.
Сложи бюджет на всичко, което е на пътя на потребител, и спри работата, когато бюджетът свърши. Прекъсването от наша страна, докато команда продължава да работи другаде, само мести проблема.
Еднократната миграция принадлежи на еднократна задача. Скриването ѝ в ежедневни действия я прави по-евтина за писане и по-скъпа за пускане.
Тествай проверките си за безопасност. Сравнение, което не сравнява нищо, изглежда точно като такова, което е минало.

Ако изграждаш с Mythex, няма какво да правиш: целта е просто по-малко работни пространства да остават без памет, а отварянето на проект да е толкова бързо, колкото преди. Как работните пространства се паузират и събуждат е описано в документацията в частно работно пространство. За друга история за изчерпана памет вижте сривът от липса на памет, скрит в етикет на напредък.