Kako skalirati SaaS nakon lansiranja bez razbijanja proizvoda

Svi slave lansiranje. Gotovo nitko vas ne upozorava na dio koji dolazi nakon toga — onu čudnu, napetu godinu kada proizvod koji vam je donio prvih stotinu kupaca počinje popuštati pod teretom sljedećih tisuću. Ništa dramatično se ne događa. Stvari jednostavno postaju sporije, nestabilnije, teže za mijenjanje. Jednog utorka shvatite da značajka koja je nekad trajala dan sada traje tjedan, a nitko ne zna točno reći zašto. Tu se, a ne pri lansiranju, većina SaaS proizvoda tiho dobiva ili gubi.

Sjedili smo s mnogo osnivača upravo u ovoj točki. Oni ne propadaju — to je ono zbunjujuće. Prihod raste, tim se širi, demoi prolaze dobro. Ali ispod površine proizvod stenje. Tiketi za podršku rastu brže od korisnika. Implementacije koje su nekad bile dosadne sada dolaze sa zadržanim dahom. Baza koda koja je prije godinu dana djelovala pametno sada djeluje kao minsko polje gdje svaka promjena prijeti aktiviranjem nečeg drugog. Nisu učinili ništa pogrešno. Jednostavno su prerasli ono što su izgradili, a nitko im nije rekao da se to treba dogoditi.

Ovo je dakle vodič za koji bismo voljeli da ga je više osnivača imalo prije nego što su se pojavile pukotine. Ne radi se o hiperskaliranju, Kubernetesu ili o tome što je neki jednorog napravio s pedeset milijuna korisnika. Radi se o dosadnoj, odlučujućoj sredini — prelasku iz radi za nekolicinu u radi za mnoge — bez pisanja svega ispočetka, bez plašenja kupaca i bez sagorijevanja vašeg tima. Cilj nije savršena arhitektura. Cilj je proizvod koji nastavlja rasti umjesto onoga koji se tiho počinje lomiti.

Što se zapravo lomi kada SaaS raste

Evo dijela koji najviše iznenađuje osnivače: problemi skaliranja gotovo nikad ne stižu kao dramatičan ispad za koji se pripremate. Poslužitelj se ne zapali. Umjesto toga, proizvod razvija neku vrstu blage groznice. Stranice koje su se učitavale trenutno počinju trajati tri sekunde. Izvještaj koji je radio dobro za prve kupce dobiva timeout za velikog koji se upravo potpisao. Isti bug se stalno ponavlja jer dva dijela koda potajno ovise jedan o drugome na način koji nitko nije dokumentirao.

Ono što se zapravo lomi rijetko su vaši poslužitelji — to su vaše pretpostavke. Na početku ste gradili za oblik svojih prvih korisnika: nekoliko računa, malo podataka, jednostavni tijekovi rada, svi otprilike isti. Rast ne dodaje samo više istoga. Dodaje raznolikost. Kupca s deset puta više podataka. Tim koji koristi značajku na način kakav nikad niste zamišljali. Skok u ponedjeljak u 9 ujutro kada se svi prijave odjednom. Svaki od njih tiho krši pretpostavku ugrađenu u vaš kod prije godinu dana, kada je njezino kršenje bilo nezamislivo.

Četiri mjesta na kojima se to obično prvo pokaže su predvidljiva. Baza podataka gotovo je uvijek kanarinac — upiti koji su bili trenutni na malim tablicama puze kako podaci rastu. Spori endpoint: jedna ili dvije stranice koje obavljaju previše posla po zahtjevu, u redu dok se promet ne nagomila. Krhka implementacija, gdje je objava bilo čega postala zastrašujuća jer je kod previše zamršen da bi se o njemu moglo razumno razmišljati. I opterećenje podrške, koje uopće nije infrastruktura, ali je najistinitiji rani signal da proizvod više ne odgovara načinu na koji ga ljudi zapravo koriste.

Zamka rješavanja problema koje još nemate

Prije nego što razgovaramo o popravljanju stvari, upozorenje koje je spasilo više proizvoda od bilo koje optimizacije. Najveća prijetnja rastućem SaaS-u nije zanemarivanje skale — već jurnjava za njom prerano. U trenutku kad osnivač osjeti prvo usporavanje, instinkt je posegnuti za arhitekturom o kojoj je čitao na nekom poznatom inženjerskom blogu. Mikroservisi. Red poruka. Postavka s više regija. Particioniranje baze podataka prije nego što ona ima milijun redaka.

Tako provedete šest mjeseci i bogatstvo gradeći infrastrukturu za skalu koju niste dosegli, dok stvarni proizvod prestaje napredovati. Još gore, sada ste svaku buduću promjenu učinili težom, jer je distribuirani sustav dramatično složeniji za izgradnju i otklanjanje pogrešaka od jednostavnog koji ste imali. Zamijenili ste problem koji još niste imali za zajamčeni koji imate danas: ništa se ne objavljuje.

Disciplina je ovdje ista ona koja čini dobre proizvode na prvom mjestu: riješite problem koji je pred vama, a ne onaj koji vam laska zamišljati. Dosadan, dobro shvaćen monolit koji možete brzo mijenjati nadmašit će u skali pomodan distribuirani sustav kojeg se bojite dotaknuti. Složenost je trošak koji plaćate svaki dan, a ne jednokratna kupnja.

Mjerite prije nego što išta promijenite

Gotovo svaki osnivač kojeg susrećemo u ovoj fazi uvjeren je da zna gdje je problem. U pola slučajeva su u krivu — ne zato što su nemarni, već zato što je intuicija užasan profiler. Dio koda koji djeluje spor često je u redu; pravi krivac je neki tihi upit koji se pokreće četrdeset puta na stranici o kojoj nitko nije razmišljao. Ne možete popraviti ono što niste izmjerili, a nagađanje je ovdje način na koji timovi troše tjedne optimizirajući pogrešnu stvar.

Ne treba vam otmjen observability stog za početak. Trebaju vam tri dosadna broja pred očima, cijelo vrijeme. Koji su endpointi najsporiji i koliko spori pod stvarnim prometom. Koji upiti baze podataka troše najviše ukupnog vremena — ne najsporiji pojedinačni upit, već onaj čije se vrijeme zbraja kroz tisuće poziva. I gdje se pogreške zapravo događaju, s dovoljno konteksta da ih reproducirate. S ta tri, magla se obično razbistri unutar jednog dana.

1. 1
   Uključite osnovno praćenje

   Vremena odziva po endpointu, stope pogrešaka i bilježenje sporih upita na bazi podataka. Hostani alati to rade u jedno poslijepodne. Ne možete poboljšati broj koji ne vidite.
2. 2
   Pronađite prava tri prva

   Sortirajte prema ukupnom utrošenom vremenu, ne prema osjećaju. Tri prijestupnika gotovo uvijek čine većinu boli. Zapišite ih — to je vaš stvarni plan.
3. 3
   Popravite jedan, izmjerite ponovno

   Promijenite samo jednu stvar, zatim ponovno provjerite brojeve. Potvrdite da je pomoglo prije nego što nastavite. Dvije promjene odjednom i nikad nećete znati koja je bila važna.
4. 4
   Stanite kada je dovoljno dobro

   Definirajte 'dovoljno brzo' prije nego što počnete — recimo, svaka stranica ispod sekunde pri trenutnom opterećenju. Iza toga, optimizacija je gubljenje vremena, a ne pobjeda.

Taj zadnji korak važniji je nego što izgleda. Rad na performansama je istinski ovisan; uvijek postoji još jedna milisekunda za skinuti. Ali vaši kupci ne osjećaju razliku između 200 ms i 120 ms, a sati koje provodite jureći za time sati su koje ne provodite na značajci koja bi zapravo rasla posao. Izmjerite, popravite prva tri, proglasite pobjedu, idite dalje.

Baza podataka gotovo je uvijek prvi zid

Da moramo kladiti novac na to gdje rastući SaaS udari u svoj prvi pravi strop, kladili bismo se na bazu podataka svaki put. To je jedini dio sustava u kojem se male rane odluke najteže nagomilavaju. Upit bez indeksa izvodi se u trenu na tisuću redaka i zaglavi se na milijunu. Kod se nije promijenio. Podaci jesu — a podaci samo rastu.

Dobra vijest je da je baza podataka ujedno mjesto gdje žive najjeftiniji popravci s najvećim učinkom. Klasičan je nedostajući indeks: jedna linija koja pretvara višesekundni upit u trenutan, jer baza prestaje skenirati svaki redak da bi pronašla onih nekoliko koje treba. Odmah iza njega je problem N+1 upita — stranica koja, umjesto da postavi jedno pitanje, tiho postavlja bazi isto malo pitanje stotine puta u petlji. Oba su česta, oba su nevidljiva dok ne pogledate, i oba su obično popravak od jednog dana kada ih jednom pronađete.

Postoji redoslijed na koji se vrijedi osloniti, i isplati se slijediti ga redom umjesto preskakanja na kraj. Prvo popravite upite — indekse, N+1, spori izvještaj. Zatim dodajte predmemoriranje za podatke koji se stalno čitaju, a rijetko mijenjaju. Tek nakon toga ima smisla govoriti o replikama za čitanje, većim instancama ili razdvajanju podataka. Većina SaaS proizvoda nikad ne treba kasnije korake. Samo su trebali da prvi budu napravljeni kako treba.

Skaliranje proizvoda znači skaliranje načina na koji ga mijenjate

Evo zaokreta koji zatekne osnivače nespremne: nakon određene točke, skaliranje prestaje biti o tome da proizvod podnosi više korisnika i počinje biti o tome da vaš tim podnosi više promjena. Kad ste bili vi i jedan razvojni inženjer, svi su držali cijeli sustav u glavi. Mogli ste promijeniti bilo što jer ste znali što će dirnuti. Pri pet ili deset ljudi taj se mentalni model razbija — i kod koji je pretpostavljao da svi sve znaju postaje opasnost.

To je pravi razlog zašto implementacije postaju zastrašujuće. Nije da je kod preko noći postao lošiji; nego da nitko više ne može potpuno predvidjeti polumjer eksplozije promjene. Rješenje nije junaštvo ili zamrzavanje objava. To je ulaganje u neglamuroznu skelu koja većem timu omogućuje kretanje bez gaženja jedan po drugome: automatizirani skup testova koji hvata očite kvarove, implementacije koje su rutina umjesto svečanosti, i način da loše izdanje ugasite u sekundama umjesto u panici.

• Skup testova koji pokriva nekoliko tijekova koji bi bili katastrofalni da se pokvare — prijava, plaćanje, glavna radnja. Ne sve; one kritične malobrojne.
• Implementacije koje se izvode na gumb, ne kao ritual, tako da objavljivanje malo i često postaje sigurno umjesto napeto.
• Brz način za vraćanje promjene, tako da je loše izdanje događaj od pet minuta, a ne cjelonoćni incident.
• Feature flagovi, tako da možete poslati kod prvo nekolicini kupaca i odmah ga ugasiti ako se loše ponaša.
• Dovoljno dokumentacije da godišnji odmor jedne osobe ne zamrzne cijelo područje proizvoda.

Ništa od ovoga ne pojavljuje se u demou. Ništa od ovoga ne dodaje izravno značajku. A upravo je to posao koji razdvaja proizvod koji nastavlja ubrzavati od onoga koji usporava sa svakim novim zaposlenikom. Timovi koji dobro skaliraju oni su koji svoju sposobnost da sigurno mijenjaju proizvod tretiraju kao značajku samu po sebi — jer pri skali to je upravo to.

Kratka priča iz točke pucanja

Da to konkretiziramo, evo kompozita izvučenog iz posla koji smo radili — detalji zamućeni, oblik vjeran životu. Mali SaaS za upravljanje terenskim servisnim timovima dobro je lansiran i narastao na nekoliko stotina tvrtki koje plaćaju. Osnivači su bili podjednako oduševljeni i iscrpljeni. Tada je potpisao njihov najveći kupac ikad: tvrtka s više korisnika i više povijesnih podataka nego prethodnih deset klijenata zajedno.

Unutar tjedna, nadzorna ploča u kojoj su svi živjeli usporila je do puzanja za tog kupca — i, začudo, za sve ostale također. Tiketi za podršku naglo su porasli. Osnivači su pretpostavili da im treba daleko veći poslužitelj i pripremali se za bolnu, skupu ponovnu arhitekturu. To je bio trenutak kad smo dovedeni, a instinkt je bio razumljiv, ali pogrešan.

Nismo dirali arhitekturu. Uključili smo bilježenje sporih upita i promatrali jedno poslijepodne. Krivac je bio gotovo neugodno malen: glavna nadzorna ploča učitavala je popis poslova svakog korisnika klasičnim N+1 obrascem, ispaljujući jedan upit po poslu. Za malog kupca to je značilo nekoliko desetaka bezopasnih upita. Za novog diva, značilo je tisuće po učitavanju stranice — što je, na dijeljenoj infrastrukturi, povuklo cijeli sustav prema dolje za sve.

Pouka koju su osnivači izvukli nije bila tehnička. Bila je u tome da je zastrašujući problem skaliranja koji su zamišljali — onaj koji je tražio ponovnu izgradnju i prikupljanje sredstava — bio, kada se izmjerio, popravak od dva dana skriven iza zastrašujućeg simptoma. Bili su na rubu da provedu mjesece rješavajući pogrešan problem. Taj jaz, između zamišljene krize i izmjerene, mjesto je gdje se troši većina novca za skaliranje.

Kada je doista vrijeme za ponovnu izgradnju dijela

Sav ovaj oprez oko preranog skaliranja može se čitati kao nikad ne refaktoriraj, nikad ne gradi ispočetka. Nije tako. Ponekad je dio proizvoda doista dosegao kraj svog životnog vijeka, a ponovno krpanje skupa je opcija. Trik je u razlikovanju stvarnog strukturnog ograničenja od običnih bolova rasta koje bi izmjereni popravak riješio.

Iskreni signal je ovaj: ponovno izgradite komponentu kada je trošak njezine promjene postao dosljedno viši od troška njezine zamjene. Ne kad je ružna — ružan kod koji je stabilan i rijetko dotaknut je u redu. Tražite dio sustava gdje je svaka promjena spora i rizična, gdje se isti bugovi stalno vraćaju, gdje novi razvojni inženjeri ne mogu sigurno raditi, i gdje ste već isprobali jeftinije popravke i udarili u zid. Kad je nekoliko toga istinito istovremeno, usredotočeno prepisivanje tog jednog dijela ispravan je potez.

A kad ipak gradite ispočetka, gradite dio — ne proizvod. Potpuno prepisivanje od nule sirenski je zov skaliranja, ono što djeluje čisto a na kraju potopi godinu dok konkurenti objavljuju. Zamijenite jednu trulu komponentu, iza jasne granice, dok ostatak proizvoda nastavlja raditi i zarađivati. Kirurški, ne herojski.

Česta pitanja