Isompiin työtiloihin siirtyminen ilman, että kukaan joutuu odottamaan

Jokaisella Mythex-projektilla on oma työtila: pieni pilvitietokone, jolla agentti kirjoittaa koodia ja sovelluksesi esikatselu pyörii. Olimme nostaneet uusien työtilojen muistin 1 Gt:stä 2 Gt:hen, mutta vanhemmat jäivät 1 Gt:n kokoon. Tarkistushetkellä niitä oli noin neljännes. Ensimmäinen korjauksemme siirsi projektin isompaan työtilaan, kun se seuraavan kerran avattiin. Ensimmäisenä tuotantopäivänään se pakotti yhden ihmisen odottamaan seitsemän minuuttia. Lisäsimme siihen kovan aikarajan ja lopulta poistimme siirron projektin avaamisesta kokonaan.

Miksi vanhat työtilat jäivät pieniksi

Hiekkalaatikkopalveluntarjoajamme asettaa työtilan koon luomisen yhteydessä, ja säilyttää sen jokaisen pysäytyksen ja jatkamisen läpi. Mallipohjan muuttaminen, eli resepti, josta uudet työtilat rakennetaan, vaikuttaa vain myöhemmin luotuihin työtiloihin. Mikään ei muuta olemassa olevien kokoa.

Tämä oli merkittävää. Yksi pienistä työtiloista loppui muistista git push -komennon aikana, kun sen esikatselu käynnistyi, ja se ei vastannut 11 minuuttiin. Julkaisu epäonnistui sen takia.

Ensimmäinen yritys: siirrä projekti herätessä

Työtilat pysähtyvät, kun kukaan ei käytä niitä, ja heräävät, kun projekti avataan. Herääminen vaikutti sopivalta hetkeltä siirtää projekti, koska kukaan ei vielä työskentele siinä.

Siirto toimi näin:

1. Tarkista koko. Jos työtila on pienempi kuin 2 Gt, siirrä se. Jos koko on tuntematon, älä tee mitään.
2. Älä häiritse julkaisua. Julkaisu lukee työtilan tiedostoja, joten jos julkaisu on kesken, ohita siirto.
3. Pakkaa projekti. Arkistoi kaikki projektissa, mukaan lukien sen git-historia, eli jokainen projektin tarkistuspiste, ja sovelluksen oma .env-tiedosto, joka kuuluu omistajalle. Jätä asennetut riippuvuudet (node_modules) pois, koska ne voi asentaa uudelleen.
4. Kopioi suoraan. Virtaa arkisto vanhasta työtilasta uuteen 2 Gt:n työtilaan, jotta se ei koskaan tarvitse mahtua omalle palvelimellemme.
5. Vertaa ennen vaihtoa. Laske tiedostot, lue viimeisin tarkistuspiste ja laske tarkistuspisteet molemmissa työtiloissa. Vaihda vain, jos kaikki kolme täsmäävät.
6. Säilytä vanha, jos jokin menee pieleen. Mikä tahansa virhe tai epäsuhta hylkää uuden työtilan ja avaa projektin vanhassa työtilassa kuten ennenkin.

Vertailun yksi yksityiskohta oli tärkeämpi kuin miltä näyttää. Tarkistus ajetaan ylläpitäjätilillä, ja git ei lue repositorion, joka kuuluu toiselle käyttäjälle. Se ei tulostanut mitään kummassakaan päässä, ja ”ei mitään” täsmäsi ”ei mitään” -tulokseen, joten tarkistus meni läpi vertaamatta yhtään historiaa. Kerroimme gitille luottavansa hakemistoon ja lisäsimme testin, ettei tämä pääse takaisin.

Mitä tapahtui ensimmäisenä päivänä

Tuotannossa ensimmäisenä päivänä yhden projektin pakkaus osui viiden minuutin komentoaikarajaan herätyksen sisällä. Omistaja odotti seitsemän minuuttia, ennen kuin hänen työtilansa aukesi. Koska siirto epäonnistui, projekti oli yhä pieni, joten seuraava avaus olisi yrittänyt uudelleen ja pakottanut hänet odottamaan taas.

Migraatio, joka pakottaa ihmisen odottamaan oman projektinsa avaamista, on huono kauppa. Koko ajatus siirron tekemisestä herätyksen yhteydessä oli, ettei kukaan huomaisi sitä.

Toinen yritys: kova budjetti

Samana päivänä muutimme neljä asiaa:

• Yksi minuutti koko siirrolle. Jokainen vaihe, eli koon tarkistus, pakkaus, uuden työtilan luonti, kopiointi, purkaminen ja vertailu, jakaa yhden 60 sekunnin budjetin. Kun se loppuu, projekti avautuu vanhassa työtilassa.
• Pysäytä työ, ei vain odottamista. Meidän puolelta luovuttaminen ei riitä, jos arkistointi yhä käy työtilassa, jonka omistaja on aikeissa käyttää. Jokainen arkistokomento tapetaan nyt työtilan sisällä hetki ennen budjetin loppua. Jos uusi työtila saapuu sen jälkeen, kun olemme luovuttaneet, se hylätään.
• Älä pakota omistajaa odottamaan siivousta. Väliaikaisen arkiston poistaminen tapahtuu nyt taustalla.
• Älä yritä joka avauksella uudelleen. Projekti, jota ei voitu siirtää, jätetään rauhaan 24 tunnin ajaksi, joten epäonnistuminen maksaa korkeintaan yhden viiveen päivässä eikä yhtä jokaisesta avauksesta.

Kolmas yritys: vie se pois herätyksestä

Tämä teki pahimmasta tapauksesta yhden minuutin. Minuutti on silti minuutti, ja tajusimme, ettei siirron tarvinnut olla kenenkään polulla lainkaan.

Yhtään työtilaa ei enää luoda 1 Gt:n kokoisena. Kyse ei siis ole jatkuvasta prosessista. Se on kertaluonteinen työ kiinteällä listalla työtiloja. Sen tekeminen herätyksen sisällä tarkoitti, että oikea ihminen maksoi jokaisesta hitaasta siirrosta, ja ainoa tapa saada tietää, ettei työtilaa voida siirtää, oli se, että joku oli juuri odottanut sitä.

Poistimme siksi siirron herätyksestä kokonaan. Projektin avaaminen toimii kuten ennenkin. Jäljellä olevat pienet työtilat käsitellään nyt valvottuna eränä. Kukaan ei odota sitä, ja työtila, jota ei voi siirtää, näkyy erän raportissa, jossa voimme katsoa sitä, eikä omistajan edessä.

Mitä opimme

• Koon muuttaminen ei aina ole mahdollista. Kun alusta lukitsee koon luomisessa, oletuksen nostaminen auttaa vain uusia asioita. Varaudu vanhoihin.
• ”Kukaan ei käytä sitä vielä” tarkoittaa silti, että joku odottaa. Työ, joka tehdään tuotteeseen tultaessa, on työtä, jota ihminen katsoo.
• Aseta budjetti kaikelle, mikä on käyttäjän polulla, ja lopeta työ, kun budjetti loppuu. Aikarajan ylittäminen omalla puolellamme, kun komento jatkaa toisaalla, siirtää ongelman vain muualle.
• Yksittäinen migraatio kuuluu yksittäiseen työhön. Sen piilottaminen tavallisiin toimiin tekee siitä halvemman kirjoittaa ja kalliimman ajaa.
• Testaa turvatarkistuksesi. Vertailu, joka ei vertaa mitään, näyttää täsmälleen samalta kuin vertailu, joka meni läpi.

Jos rakennat Mythexillä, sinun ei tarvitse tehdä mitään. Tavoitteena on yksinkertaisesti vähemmän työtiloja, jotka loppuvat muistista, ja projektin avaaminen yhtä nopeaa kuin ennen. Siitä, miten työtilat pysähtyvät ja heräävät, kerrotaan dokumentaatiossa kohdassa yksityinen työtila. Toisen muistiongelman tarina löytyy artikkelista muistivuoto edistymisindikaattorissa.