SaaS-tuotteen skaalaus julkaisun jälkeen rikkomatta tuotetta

Kaikki juhlivat julkaisua. Lähes kukaan ei varoita siitä osasta, joka tulee sen jälkeen — siitä oudosta, hermoja raastavasta vuodesta, jolloin tuote, joka toi sinulle ensimmäiset sata asiakasta, alkaa notkua seuraavan tuhannen painon alla. Mitään dramaattista ei tapahdu. Asiat vain hidastuvat, muuttuvat epävakaammiksi ja vaikeammiksi muuttaa. Eräänä tiistaina tajuat, että ominaisuus, joka ennen vei päivän, vie nyt viikon, eikä kukaan osaa oikein sanoa miksi. Juuri siinä, ei julkaisussa, useimmat SaaS-tuotteet hiljaa voitetaan tai hävitään.

Olemme istuneet monen perustajan kanssa juuri tässä kohdassa. He eivät ole epäonnistumassa — se on hämmentävä juttu. Liikevaihto kasvaa, tiimi laajenee, demot sujuvat hyvin. Mutta pinnan alla tuote ähkii. Tukipyynnöt nousevat nopeammin kuin käyttäjät. Julkaisut, jotka ennen olivat tylsiä, tulevat nyt henki pidätettynä. Koodikanta, joka tuntui vuosi sitten nokkelalta, tuntuu nyt miinakentältä, jossa jokainen muutos uhkaa laukaista jotain muuta. He eivät tehneet mitään väärin. He vain kasvoivat ulos rakentamastaan, eikä kukaan kertonut, että näin kuuluikin käydä.

Tämä on siis opas, jonka toivoisimme useamman perustajan saaneen ennen halkeamien ilmestymistä. Kyse ei ole hyperskaalasta, Kubernetesista tai siitä, mitä jokin yksisarvinen teki viidelläkymmenellä miljoonalla käyttäjällä. Kyse on tylsästä, ratkaisevasta keskivaiheesta — siirtymästä siitä, että se toimii harvoille, siihen, että se toimii monille — ilman kaiken uudelleenkirjoittamista, asiakkaiden pelottelua tai tiimin uuvuttamista. Tavoite ei ole täydellinen arkkitehtuuri. Tavoite on tuote, joka jatkaa kasvuaan sen sijaan, että alkaisi hiljaa murtua.

Mikä oikeasti hajoaa, kun SaaS kasvaa

Tämä osa yllättää perustajat eniten: skaalausongelmat eivät juuri koskaan saavu sinä dramaattisena käyttökatkona, johon varaudut. Palvelin ei syty tuleen. Sen sijaan tuotteeseen kehittyy eräänlainen lievä kuume. Sivut, jotka latautuivat välittömästi, alkavat viedä kolme sekuntia. Raportti, joka pyöri hyvin varhaisille asiakkaille, aikakatkeaa sille suurelle, joka juuri allekirjoitti. Sama bugi ilmestyy yhä uudelleen, koska kaksi koodin osaa riippuvat salaa toisistaan tavalla, jota kukaan ei dokumentoinut.

Se, mikä todella murtuu, on harvoin palvelimesi — se on oletuksesi. Alussa rakensit ensimmäisten käyttäjiesi muotoon: muutama tili, vähän dataa, yksinkertaiset työnkulut, kaikki suunnilleen samanlaisia. Kasvu ei vain lisää lisää samaa. Se lisää vaihtelua. Asiakas, jolla on kymmenkertaisesti dataa. Tiimi, joka käyttää ominaisuutta tavalla, jota et koskaan kuvitellut. Piikki maanantaina kello yhdeksän, kun kaikki kirjautuvat sisään yhtä aikaa. Jokainen niistä rikkoo hiljaa oletuksen, joka leivottiin koodiisi vuosi sitten, kun sen rikkominen oli mahdoton ajatus.

Ne neljä paikkaa, joissa se yleensä näkyy ensin, ovat ennustettavissa. Tietokanta on lähes aina kanarialintu — kyselyt, jotka olivat välittömiä pienillä tauluilla, ryömivät datan kasvaessa. Hidas päätepiste: yksi tai kaksi sivua tekee liikaa työtä pyyntöä kohden, mikä on hyvä, kunnes liikenne kasaantuu. Hauras julkaisu, jossa minkä tahansa toimittamisesta on tullut pelottavaa, koska koodi on liian sotkuista hahmotettavaksi. Ja tukikuorma, joka ei ole lainkaan infrastruktuuria mutta on totuudenmukaisin varhainen merkki siitä, ettei tuote enää sovi siihen, miten ihmiset sitä oikeasti käyttävät.

Ansa: ratkoa ongelmia, joita ei vielä ole

Ennen kuin puhumme korjaamisesta, varoitus, joka on pelastanut enemmän tuotteita kuin mikään optimointi. Kasvavan SaaS:n suurin uhka ei ole skaalan sivuuttaminen — se on sen tavoittelu liian aikaisin. Sillä hetkellä, kun perustaja tuntee ensimmäisen hidastumisen, vaisto on tarttua siihen arkkitehtuuriin, josta hän luki jollain kuuluisalla insinööriblogilla. Mikropalvelut. Viestijono. Monialueinen ympäristö. Tietokannan pilkkominen, ennen kuin siinä on miljoonaa riviä.

Näin käytät kuusi kuukautta ja omaisuuden rakentaaksesi infrastruktuuria skaalalle, jota et ole saavuttanut, samalla kun itse tuote pysähtyy. Pahempaa, olet nyt tehnyt jokaisesta tulevasta muutoksesta vaikeamman, koska hajautettu järjestelmä on dramaattisesti monimutkaisempi rakentaa ja debugata kuin se yksinkertainen, joka sinulla oli. Vaihdoit ongelman, jota sinulla ei vielä ollut, taatusti sellaiseen, joka sinulla on tänään: mitään ei valmistu.

Kuri tässä on sama, joka tekee hyvistä tuotteista hyviä alun perinkin: ratkaise edessäsi oleva ongelma, älä se, jota sinua imartelee kuvitella. Tylsä, hyvin ymmärretty monoliitti, jota voit muuttaa nopeasti, päihittää skaalassa muodikkaan hajautetun järjestelmän, jota pelkäät koskea. Monimutkaisuus on kustannus, jonka maksat joka ikinen päivä, ei kertaostos.

Mittaa ennen kuin muutat mitään

Lähes jokainen perustaja, jonka tapaamme tässä vaiheessa, on vakuuttunut tietävänsä, missä ongelma on. Hän on väärässä noin puolet ajasta — ei huolimattomuuttaan, vaan koska intuitio on surkea profiloija. Se koodin osa, joka tuntuu hitaalta, on usein kunnossa; todellinen syyllinen on jokin hiljainen kysely, joka pyörii neljäkymmentä kertaa sivulla, jota kukaan ei ajatellut. Et voi korjata sitä, mitä et ole mitannut, ja arvailu tässä on tapa, jolla tiimit käyttävät viikkoja väärän asian optimointiin.

Et tarvitse hienoa havainnointipinoa aloittaaksesi. Tarvitset kolme tylsää lukua edessäsi koko ajan. Mitkä päätepisteet ovat hitaimpia ja kuinka hitaita oikealla liikenteellä. Mitkä tietokantakyselyt vievät eniten kokonaisaikaa — ei hitain yksittäinen kysely, vaan se, jonka aika kertyy tuhansien kutsujen yli. Ja missä virheet oikeasti tapahtuvat, riittävällä kontekstilla niiden toistamiseen. Näiden kolmen avulla sumu yleensä hälvenee päivässä.

1. 1
   Kytke perusvalvonta päälle

   Vasteajat päätepistettä kohden, virheprosentit ja hitaiden kyselyiden lokitus tietokannassa. Pilvipalvelutyökalut tekevät tämän iltapäivässä. Et voi parantaa lukua, jota et näe.
2. 2
   Löydä todellinen kärkikolmikko

   Lajittele kulutetun kokonaisajan, ei mututuntuman mukaan. Kolme pahantekijää selittää lähes aina suurimman osan tuskasta. Kirjoita ne ylös — se on todellinen tiekarttasi.
3. 3
   Korjaa yksi, mittaa uudelleen

   Muuta yksi ainoa asia, tarkista sitten luvut uudelleen. Vahvista, että se auttoi, ennen kuin jatkat. Kaksi muutosta kerralla, etkä koskaan tiedä kumpi merkitsi.
4. 4
   Lopeta, kun se on tarpeeksi hyvä

   Määritä 'tarpeeksi nopea' ennen kuin aloitat — vaikkapa jokainen sivu alle sekunnissa nykyisellä kuormalla. Sen jälkeen optimointi on ajan haaskausta, ei voitto.

Tuo viimeinen vaihe merkitsee enemmän kuin miltä näyttää. Suorituskykytyö on aidosti koukuttavaa; aina on yksi millisekunti lisää viilattavana. Mutta asiakkaasi eivät tunne eroa 200 ms:n ja 120 ms:n välillä, ja tunnit, jotka käytät sen tavoitteluun, ovat tunteja pois ominaisuudesta, joka oikeasti kasvattaisi liiketoimintaa. Mittaa, korjaa kärkikolmikko, julista voitto, jatka eteenpäin.

Tietokanta on lähes aina ensimmäinen seinä

Jos joutuisimme lyömään vetoa siitä, missä kasvava SaaS törmää ensimmäiseen todelliseen kattoonsa, löisimme tietokannan puolesta joka kerta. Se on järjestelmän se osa, jossa pienet varhaiset päätökset kumuloituvat kovimmin. Kysely ilman indeksiä pyörii silmänräpäyksessä tuhannella rivillä ja jumiutuu miljoonalla. Koodi ei muuttunut. Data muuttui — ja data vain aina kasvaa.

Hyvä uutinen on, että tietokanta on myös paikka, jossa halvimmat, vaikuttavimmat korjaukset asuvat. Klassikko on puuttuva indeksi: yksi ainoa rivi, joka muuttaa monisekuntisen kyselyn välittömäksi, koska tietokanta lakkaa skannaamasta joka riviä löytääkseen ne harvat, joita se tarvitsee. Heti sen perässä on N+1-kyselyongelma — sivu, joka yhden kysymyksen sijaan kysyy tietokannalta hiljaa saman pienen kysymyksen satoja kertoja silmukassa. Molemmat ovat yleisiä, molemmat näkymättömiä kunnes katsot, ja molemmat ovat yleensä päivän korjaus, kun olet ne löytänyt.

Tässä on järjestys, johon nojata, ja kannattaa seurata sitä järjestyksessä sen sijaan, että hyppäisi loppuun. Korjaa kyselyt ensin — indeksit, N+1:t, hidas raportti. Lisää sitten välimuistitus datalle, jota luetaan jatkuvasti mutta joka muuttuu harvoin. Vasta sen jälkeen on järkevää puhua lukureplikoista, suuremmista instansseista tai datan erottelusta. Useimmat SaaS-tuotteet eivät koskaan tarvitse myöhempiä vaiheita. Ne tarvitsivat vain ensimmäiset tehtyinä kunnolla.

Tuotteen skaalaus tarkoittaa sen skaalausta, miten sitä muutat

Tässä se muutos, joka yllättää perustajat: tietyn pisteen jälkeen skaalaus lakkaa olemasta siitä, että tuote käsittelee enemmän käyttäjiä, ja alkaa olla siitä, että tiimisi käsittelee enemmän muutosta. Kun olit sinä ja yksi kehittäjä, jokainen piti koko järjestelmän päässään. Saatoit muuttaa mitä tahansa, koska tiesit, mihin se vaikuttaisi. Viidellä tai kymmenellä ihmisellä tuo ajatusmalli murskaantuu — ja koodista, joka oletti kaikkien tietävän kaiken, tulee rasite.

Tämä on todellinen syy siihen, miksi julkaisut muuttuvat pelottaviksi. Ei ole niin, että koodi huononi yhdessä yössä; vaan että kukaan ei enää voi täysin ennustaa muutoksen vaikutusaluetta. Korjaus ei ole sankaritekoja tai toimitusten jäädytys. Se on sijoittamista siihen kimaltelemattomaan rakennustelineeseen, joka antaa suuremman tiimin liikkua astumatta toistensa varpaille: automatisoitu testijoukko, joka nappaa ilmeiset rikkoutumiset, julkaisut, jotka ovat rutiinia eivätkä seremoniallisia, ja keino sammuttaa huono julkaisu sekunneissa sen sijaan, että säntäilisi paniikissa.

• Testijoukko, joka kattaa sen kourallisen kulkuja, jotka olisivat katastrofaalisia jos ne rikkoutuisivat — kirjautuminen, maksu, ydintoiminto. Ei kaikkea; kriittiset harvat.
• Julkaisut, jotka pyörivät napista, eivät rituaalista, jotta pienen ja usein toimittamisesta tulee turvallista hermojaraastavan sijaan.
• Nopea keino palauttaa edellinen versio, jotta huono julkaisu on viiden minuutin tapahtuma, ei koko yön häiriötilanne.
• Ominaisuusliput, jotta voit toimittaa koodin ensin muutamalle asiakkaalle ja sammuttaa sen välittömästi, jos se käyttäytyy huonosti.
• Riittävästi dokumentaatiota, jottei yhden ihmisen loma jäädytä koko tuotteen aluetta.

Mikään tästä ei näy demossa. Mikään siitä ei suoraan lisää ominaisuutta. Ja se on juuri se työ, joka erottaa tuotteen, joka jatkaa kiihtymistään, sellaisesta, joka hidastuu jokaisen uuden palkkauksen myötä. Tiimit, jotka skaalaavat hyvin, ovat niitä, jotka kohtelevat kykyään muuttaa tuotetta turvallisesti ominaisuutena sinänsä — koska skaalassa juuri sitä se on.

Lyhyt tarina murtumispisteestä

Konkretisoidaksemme tämän, tässä on yhdistelmä työstä, jota olemme tehneet — yksityiskohdat hämärrettyinä, muoto todenmukaisena. Pieni SaaS kenttäpalvelutiimien hallintaan oli julkaissut hyvin ja kasvanut muutamaan sataan maksavaan yritykseen. Perustajat olivat yhtä lailla innoissaan ja uupuneita. Sitten heidän suurin asiakkaansa ikinä allekirjoitti: yritys, jolla oli enemmän käyttäjiä ja enemmän historiadataa kuin edellisillä kymmenellä asiakkaalla yhteensä.

Viikossa kojelauta, jossa kaikki elivät, oli hidastunut ryömimiseksi sille asiakkaalle — ja, oudosti, kaikille muillekin. Tukipyynnöt piikittyivät. Perustajat olettivat tarvitsevansa paljon suuremman palvelimen ja varautuivat tuskalliseen, kalliiseen uudelleenarkkitehtuuriin. Juuri sillä hetkellä meidät kutsuttiin mukaan, ja vaisto oli ymmärrettävä mutta väärä.

Emme koskeneet arkkitehtuuriin. Kytkimme hitaiden kyselyiden lokituksen päälle ja seurasimme iltapäivän. Syyllinen oli melkein noloittavan pieni: pääkojelauta latasi kunkin käyttäjän työlistan klassisella N+1-kuviolla, ampuen yhden kyselyn työtä kohden. Pienelle asiakkaalle se tarkoitti muutamaa kymmentä harmitonta kyselyä. Uudelle jätille se tarkoitti tuhansia sivulatausta kohden — mikä jaetulla infrastruktuurilla veti koko järjestelmän alas kaikilta.

Oppi, jonka perustajat ottivat mukaansa, ei ollut tekninen. Se oli, että pelottava skaalausongelma, jonka he olivat kuvitelleet — se, joka vaati uudelleenrakennuksen ja rahoituskierroksen — oli mitattuna kahden päivän korjaus piileskelemässä pelottavan oireen takana. He olivat aikeissa käyttää kuukausia väärän ongelman ratkaisuun. Tuo kuilu, kuvitellun kriisin ja mitatun välillä, on se, missä suurin osa skaalausrahasta tuhlataan.

Milloin on oikeasti aika rakentaa osa uudelleen

Kaikki tämä varovaisuus ennenaikaisesta skaalauksesta voi kuulostaa siltä, että älä koskaan refaktoroi, älä koskaan rakenna uudelleen. Ei se sitä ole. Joskus jokin tuotteen osa on aidosti saavuttanut elinkaarensa pään, ja sen paikkaaminen taas on kallis valinta. Niksi on erottaa todellinen rakenteellinen raja tavallisista kasvukivuista, jotka mitattu korjaus hoitaisi.

Rehellinen merkki on tämä: rakenna komponentti uudelleen, kun sen muuttamisen kustannus on tullut johdonmukaisesti korkeammaksi kuin sen korvaamisen kustannus. Ei silloin, kun se on ruma — ruma koodi, joka on vakaa ja harvoin kosketettu, on ihan kunnossa. Etsit järjestelmän osaa, jossa jokainen muutos on hidas ja riskialtis, jossa samat bugit palaavat yhä, jossa uudet kehittäjät eivät voi turvallisesti työskennellä ja jossa olet jo kokeillut halvemmat korjaukset ja törmännyt seinään. Kun useampi näistä on totta yhtä aikaa, juuri sen yhden osan kohdennettu uudelleenkirjoitus on oikea ratkaisu.

Ja kun rakennat uudelleen, rakenna osa — älä tuotetta. Täysi alusta-asti-uudelleenkirjoitus on skaalauksen seireenien laulu, se joka tuntuu puhtaalta ja päätyy upottamaan vuoden samalla kun kilpailijat toimittavat. Korvaa se yksi mädäntynyt komponentti selkeän rajan takana, samalla kun loput tuotteesta jatkaa pyörimistä ja ansaitsemista. Kirurgista, ei sankarillista.

Yleisiä kysymyksiä