Flytning til større workspaces uden at få nogen til at vente

Hvert Mythex-projekt får sit eget workspace: en lille cloud-computer, hvor agenten skriver kode, og din apps forhåndsvisning kører. Vi havde hævet nye workspaces fra 1 GB hukommelse til 2 GB, men ældre workspaces var blevet på 1 GB — på den dag vi kontrollerede, cirka en fjerdedel af dem. Vores første rettelse flyttede et projekt til et større workspace, når det næste gang blev åbnet. På dets første dag i produktion fik det én person til at vente syv minutter. Vi satte en hård tidsgrænse på det og tog derefter flytningen ud af at åbne et projekt overhovedet.

Hvorfor de gamle workspaces forblev små

Vores sandkasse-udbyder fastlægger et workspaces størrelse, når det oprettes, og bevarer den gennem alle pauser og genoptagelser. Ændring af skabelonen — opskriften nye workspaces bygges efter — påvirker kun workspaces, der oprettes efter ændringen. Intet ændrer størrelsen på dem, der allerede findes.

Det betød noget. Et af de små workspaces løb tør for hukommelse under et git push, mens dets forhåndsvisning startede, og svarede ikke i 11 minutter. En udgivelse fejlede på grund af det.

Første forsøg: flyt projektet, når det vågner

Workspaces pauser, når ingen bruger dem, og vågner, når projektet åbnes. Vågningen virkede som det rigtige øjeblik at flytte et projekt på, fordi ingen arbejder i det endnu.

Flytningen fungerede sådan her:

1. Tjek størrelsen. Hvis workspacet er mindre end 2 GB, flyt det. Hvis størrelsen er ukendt, gør intet.
2. Forstyr ikke en udgivelse. En udgivelse læser workspacets filer, så hvis en kører, springes flytningen over.
3. Pak projektet. Arkivér alt i projektet — inklusive dets git-historik, som er hvert checkpoint projektet har, og appens egen .env-fil, som tilhører ejeren — men udelad installerede afhængigheder (node_modules), som kan geninstalleres.
4. Kopiér direkte over. Stream arkivet fra det gamle workspace ind i et nyt 2 GB-workspace, så det aldrig skal være i vores egen servers hukommelse.
5. Sammenlign, før du skifter. Tæl filerne, læs det seneste checkpoint og tæl checkpoints, i begge workspaces. Skift kun, hvis alle tre stemmer overens.
6. Behold det gamle ved enhver fejl. Enhver fejl eller uoverensstemmelse kaster det nye workspace væk og åbner projektet i det gamle, som før.

Ét detalje i sammenligningen betød mere, end det ser ud til. Tjekket kører som administratorkontoen, og git nægter at læse et repository, der ejes af en anden bruger. Det udskrev intet på begge sider — og »intet« svarede til »intet«, så tjekket bestod uden at sammenligne nogen historik overhovedet. Vi fortalte git at stole på mappen og tilføjede en test, så det ikke kan snige sig tilbage.

Hvad der gik galt på første dag

På sin første dag i produktion ramte pakningen af ét projekt en timeout på fem minutter for en kommando — inde i vågningen. Ejeren ventede syv minutter, før deres workspace åbnede. Og fordi flytningen var mislykkedes, var projektet stadig småt, så næste åbning ville have forsøgt igen og fået dem til at vente igen.

En migrering, der får nogen til at vente, mens de åbner deres eget projekt, er en dårlig handel. Hele pointen med at gøre det ved vågning var, at ingen ville bemærke det.

Andet forsøg: et hårdt budget

Samme dag ændrede vi fire ting:

• Ét minut til hele flytningen. Hvert trin — tjek af størrelsen, pakning, oprettelse af det nye workspace, kopiering, udpakning, sammenligning — deler ét budget på 60 sekunder. Når det løber ud, åbnes projektet i det gamle workspace.
• Stop arbejdet, ikke kun ventetiden. At give op på vores side er ikke nok, hvis arkiveringen stadig kører inde i det workspace, ejeren er ved at bruge. Hver arkiveringskommando dræbes nu inde i workspacet kort før budgettet udløber. Hvis det nye workspace kommer frem, efter vi har givet op, kastes det væk.
• Lad ikke ejeren vente på oprydning. Sletning af det midlertidige arkiv sker nu i baggrunden.
• Prøv ikke igen ved hver åbning. Et projekt, der ikke kunne flyttes, lades være i 24 timer, så en fejl højst koster en forsinkelse om dagen, ikke én per åbning.

Tredje forsøg: tag det ud af vågningen

Det gjorde værste tilfælde til ét minut. Men et minut er stadig et minut, og vi indså, at flytningen slet ikke behøvede at ligge på nogens vej.

Der oprettes ikke længere noget workspace på 1 GB. Så dette er ikke en løbende proces; det er et engangsjob med en fast liste af workspaces. At køre det inde i vågningen betød, at en rigtig person betalte for hver langsom flytning, og den eneste måde, vi ville lære, at et workspace ikke ville flyttes, var, at nogen netop havde ventet på det.

Så vi fjernede flytningen fra vågningen helt. Åbning af et projekt gør det samme, som det gjorde før. De resterende små workspaces håndteres i stedet som et overvåget batch: ingen venter på det, og et workspace, der ikke vil flyttes, dukker op i batchens rapport, hvor vi kan se på det, i stedet for foran den person, der ejer det.

Det vi lærte

• Ændring af størrelse er ikke altid muligt. Når en platform låser størrelsen ved oprettelsen, hjælper en hævet standard kun nye ting. Planlæg for de gamle.
• »Ingen bruger den endnu« betyder stadig, at nogen venter. Arbejde udført på vej ind i et produkt er arbejde, en person ser på.
• Sæt et budget på alt, der ligger på en brugers vej, og stop arbejdet, når budgettet løber ud. At time ud på vores side, mens en kommando fortsætter et andet sted, flytter kun problemet.
• En engangsmigrering hører hjemme i et engangsjob. At gemme den i hverdagens handlinger gør den billigere at skrive og dyrere at køre.
• Test dine sikkerhedstjek. En sammenligning, der ikke sammenligner noget, ser nøjagtig ud som en, der bestod.

Hvis du bygger på Mythex, er der intet at gøre: målet er simpelthen færre workspaces, der løber tør for hukommelse, og at åbning af et projekt er lige så hurtig som før. Hvordan workspaces pauser og vågner, er dækket i dokumentationen under privat workspace. For en anden historie om hukommelse der løb tør, se out-of-memory-crashet gemt i en fremskridtsetiket.