Cum scalați un SaaS după lansare fără să stricați produsul

Toți sărbătoresc lansarea. Aproape nimeni nu vă avertizează despre ce vine după — anul acela ciudat, cu nervii încordați, în care produsul care v-a adus primii o sută de clienți începe să se îndoaie sub greutatea următoarei mii. Nu se întâmplă nimic dramatic. Lucrurile devin doar mai lente, mai fragile, mai greu de schimbat. Într-o marți oarecare vă dați seama că o funcție care dura o zi durează acum o săptămână și nimeni nu poate spune exact de ce. Acolo, nu la lansare, sunt câștigate sau pierdute în tăcere majoritatea produselor SaaS.

Am stat alături de mulți fondatori exact în acest punct. Nu eșuează — și ăsta e lucrul derutant. Veniturile cresc, echipa se mărește, demo-urile merg bine. Dar dedesubt, produsul geme. Tichetele de suport urcă mai repede decât utilizatorii. Lansările care erau plictisitoare vin acum cu respirația ținută. Codul care părea ingenios acum un an pare acum un câmp minat în care fiecare schimbare riscă să declanșeze altceva. Nu au greșit cu nimic. Pur și simplu au depășit ceea ce au construit, și nimeni nu le-a spus că așa trebuia să se întâmple.

Așa că acesta este ghidul pe care ne-am dori ca mai mulți fondatori să-l fi avut înainte să apară fisurile. Nu e despre hiperscalare, Kubernetes sau ce a făcut un unicorn la cincizeci de milioane de utilizatori. E despre mijlocul plictisitor și decisiv — trecerea de la funcționează pentru câțiva la funcționează pentru mulți — fără a rescrie totul, fără a vă speria clienții și fără a vă epuiza echipa. Scopul nu este o arhitectură perfectă. Este un produs care continuă să crească în loc de unul care începe în tăcere să se rupă.

Ce se rupe de fapt când un SaaS crește

Iată partea care îi surprinde cel mai mult pe fondatori: problemele de scalare nu sosesc aproape niciodată sub forma căderii dramatice pentru care vă pregătiți. Serverul nu ia foc. În schimb, produsul face un fel de febră ușoară. Pagini care se încărcau instant încep să dureze trei secunde. Un raport care mergea bine pentru clienții timpurii expiră pentru cel mare care tocmai a semnat. Aceeași eroare reapare mereu pentru că două părți ale codului depind în secret una de cealaltă, într-un mod pe care nimeni nu l-a documentat.

Ceea ce se rupe cu adevărat rareori sunt serverele — sunt presupunerile dumneavoastră. La început ați construit pentru forma primilor utilizatori: câteva conturi, date puține, fluxuri simple, toți cam la fel. Creșterea nu adaugă doar mai mult din același lucru. Adaugă varietate. Un client cu de zece ori mai multe date. O echipă care folosește o funcție într-un mod pe care nu l-ați imaginat niciodată. Un vârf luni la 9 dimineața, când toți se conectează deodată. Fiecare încalcă în tăcere o presupunere înrădăcinată în codul de acum un an, când a o încălca era de neconceput.

Cele patru locuri unde tinde să apară mai întâi sunt previzibile. Baza de date este aproape întotdeauna canarul — interogări instantanee pe tabele mici încep să se târască pe măsură ce datele cresc. Endpoint-ul lent: una sau două pagini care fac prea multă muncă pe cerere, în regulă până se adună traficul. Lansarea fragilă, unde a livra orice a devenit înfricoșător pentru că codul e prea încâlcit ca să fie înțeles. Și încărcarea de suport, care nu ține deloc de infrastructură, dar e cel mai sincer semnal timpuriu că produsul nu mai se potrivește cu felul în care îl folosesc oamenii de fapt.

Capcana rezolvării unor probleme pe care încă nu le aveți

Înainte să vorbim despre reparat, un avertisment care a salvat mai multe produse decât orice optimizare. Cea mai mare amenințare pentru un SaaS în creștere nu este ignorarea scării — este urmărirea ei prea devreme. În clipa în care un fondator simte prima încetinire, instinctul e să apeleze la arhitectura despre care a citit pe un blog de inginerie celebru. Microservicii. O coadă de mesaje. O configurație multi-regiune. Fragmentarea bazei de date înainte ca ea să aibă un milion de rânduri.

Așa cheltuiți șase luni și o avere construind infrastructură pentru o scară pe care nu ați atins-o, în timp ce produsul real se oprește din mișcare. Mai rău, ați făcut acum fiecare schimbare viitoare mai grea, pentru că un sistem distribuit e dramatic mai complex de construit și de depanat decât cel simplu pe care îl aveați. Ați schimbat o problemă pe care încă nu o aveați cu una garantată pe care o aveți azi: nimic nu se livrează.

Disciplina de aici este aceeași care face produse bune de la bun început: rezolvați problema din fața dumneavoastră, nu pe cea pe care vă măgulește să o imaginați. Un monolit plictisitor, bine înțeles, pe care îl puteți schimba rapid, va depăși la scară un sistem distribuit la modă de care vă e teamă să vă atingeți. Complexitatea este un cost pe care îl plătiți în fiecare zi, nu o achiziție unică.

Măsurați înainte să schimbați ceva

Aproape fiecare fondator pe care îl întâlnim în această etapă este convins că știe unde e problema. Greșesc cam jumătate din timp — nu pentru că sunt neglijenți, ci pentru că intuiția e un profiler groaznic. Partea de cod care pare lentă e adesea în regulă; adevăratul vinovat e vreo interogare tăcută care rulează de patruzeci de ori pe o pagină la care nimeni nu s-a gândit. Nu puteți repara ce nu ați măsurat, iar ghicitul aici e felul în care echipele petrec săptămâni optimizând lucrul greșit.

Nu vă trebuie o stivă de observabilitate sofisticată ca să începeți. Vă trebuie trei numere plictisitoare în față, tot timpul. Care endpoint-uri sunt cele mai lente și cât de lente sub trafic real. Care interogări de bază de date consumă cel mai mult timp total — nu cea mai lentă interogare singulară, ci cea al cărei timp se adună de-a lungul a mii de apeluri. Și unde se întâmplă de fapt erorile, cu suficient context pentru a le reproduce. Cu acestea trei, ceața se ridică de obicei într-o zi.

1. 1
   Activați monitorizarea de bază

   Timpii de răspuns pe endpoint, ratele de eroare și logarea interogărilor lente pe baza de date. Uneltele găzduite fac asta într-o după-amiază. Nu puteți îmbunătăți un număr pe care nu-l vedeți.
2. 2
   Găsiți adevăratul top trei

   Sortați după timpul total consumat, nu după instinct. Trei vinovați explică aproape întotdeauna cea mai mare parte a durerii. Notați-i — aceasta e foaia dumneavoastră de parcurs reală.
3. 3
   Reparați unul, măsurați din nou

   Schimbați un singur lucru, apoi reverificați numerele. Confirmați că a ajutat înainte de a merge mai departe. Două schimbări deodată și nu veți ști niciodată care a contat.
4. 4
   Opriți-vă când e destul de bine

   Definiți 'destul de rapid' înainte să începeți — să zicem, fiecare pagină sub o secundă la sarcina actuală. Dincolo de asta, optimizarea e o pierdere de timp, nu o victorie.

Acel ultim pas contează mai mult decât pare. Munca de performanță creează cu adevărat dependență; există mereu încă o milisecundă de tăiat. Dar clienții nu simt diferența dintre 200 ms și 120 ms, iar orele petrecute urmărind-o sunt ore nepetrecute pe funcția care chiar ar crește afacerea. Măsurați, reparați top trei, declarați victoria, mergeți mai departe.

Baza de date este aproape întotdeauna primul zid

Dacă ar trebui să pariem bani pe unde un SaaS în creștere atinge primul plafon real, am paria pe baza de date de fiecare dată. E singura parte a sistemului unde deciziile mici și timpurii se compun cel mai dur. O interogare fără index rulează într-o clipire pe o mie de rânduri și se blochează la un milion. Codul nu s-a schimbat. Datele s-au schimbat — și datele doar cresc, mereu.

Vestea bună e că baza de date e și locul unde trăiesc cele mai ieftine reparații cu cel mai mare impact. Cea clasică e indexul lipsă: o singură linie care transformă o interogare de mai multe secunde într-una instantanee, pentru că baza de date încetează să scaneze fiecare rând ca să le găsească pe cele câteva de care are nevoie. Imediat în spate vine problema interogării N+1 — o pagină care, în loc să pună o întrebare, întreabă în tăcere baza de date aceeași mică întrebare de sute de ori într-o buclă. Ambele sunt comune, ambele sunt invizibile până te uiți și ambele sunt de obicei o reparație de o zi odată ce le-ai găsit.

Există o secvență pe care să vă bazați aici, și merită urmată în ordine, nu sărind la final. Reparați mai întâi interogările — indexuri, N+1-uri, raportul lent. Apoi adăugați caching pentru datele citite constant, dar schimbate rar. Abia după aceea are sens să vorbiți despre replici de citire, instanțe mai mari sau separarea datelor. Majoritatea produselor SaaS nu au niciodată nevoie de pașii ulteriori. Aveau nevoie doar ca primii să fie făcuți cum trebuie.

A scala produsul înseamnă a scala felul în care îl schimbați

Iată schimbarea care îi ia prin surprindere pe fondatori: dincolo de un anumit punct, scalarea încetează să fie despre produsul care suportă mai mulți utilizatori și începe să fie despre echipa care suportă mai multă schimbare. Când erați dumneavoastră și un dezvoltator, fiecare ținea tot sistemul în cap. Puteați schimba orice pentru că știați ce va atinge. La cinci sau zece oameni, acel model mental se sfărâmă — iar codul care presupunea că toți știu totul devine o povară.

Acesta e adevăratul motiv pentru care lansările devin înfricoșătoare. Nu că s-a înrăutățit codul peste noapte; e că nimeni nu mai poate prezice complet raza de explozie a unei schimbări. Soluția nu e eroismul sau o înghețare a livrărilor. E investiția în schela nespectaculoasă care permite unei echipe mai mari să se miște fără să se calce pe picioare: o suită de teste automate care prinde stricăciunea evidentă, lansări care sunt rutină în loc de ceremonie și o cale de a opri o versiune proastă în câteva secunde în loc de panică.

• O suită de teste care acoperă mâna de fluxuri care ar fi catastrofale dacă s-ar rupe — autentificare, plată, acțiunea de bază. Nu totul; puținele critice.
• Lansări care rulează la un buton, nu un ritual, ca să livrezi mic și des să devină sigur în loc de înnebunitor.
• O cale rapidă de revenire, ca o versiune proastă să fie un eveniment de cinci minute, nu un incident de o noapte.
• Feature flags, ca să poți livra cod câtorva clienți mai întâi și să-l oprești instant dacă se comportă greșit.
• Suficientă documentație încât concediul unei singure persoane să nu înghețe o întreagă zonă a produsului.

Nimic din asta nu apare într-un demo. Nimic nu adaugă direct o funcție. Și e exact munca ce desparte un produs care continuă să accelereze de unul care încetinește cu fiecare nouă angajare. Echipele care scalează bine sunt cele care tratează capacitatea de a schimba produsul în siguranță ca pe o funcție în sine — pentru că la scară exact asta este.

O scurtă poveste de la punctul de fisurare

Ca să fie concret, iată un compozit extras din munca pe care am făcut-o — detaliile estompate, forma fidelă realității. Un mic SaaS pentru gestionarea echipelor de servicii în teren se lansase bine și crescuse la câteva sute de companii plătitoare. Fondatorii erau în egală măsură încântați și epuizați. Apoi a semnat cel mai mare client de până atunci: o firmă cu mai mulți utilizatori și mai multe date istorice decât precedenții lor zece clienți la un loc.

În decurs de o săptămână, tabloul de bord în care trăiau toți se târa pentru acel client — și, în mod ciudat, și pentru toți ceilalți. Tichetele de suport au explodat. Fondatorii au presupus că aveau nevoie de un server mult mai mare și se pregăteau pentru o re-arhitectură dureroasă și costisitoare. Acela a fost momentul în care am fost aduși, iar instinctul era de înțeles, dar greșit.

Nu am atins arhitectura. Am activat logarea interogărilor lente și am urmărit o după-amiază. Vinovatul era aproape jenant de mic: tabloul de bord principal încărca lista de sarcini a fiecărui utilizator cu un tipar N+1 clasic, lansând o interogare per sarcină. Pentru un client mic asta însemna câteva zeci de interogări inofensive. Pentru noul gigant însemna mii pe încărcare de pagină — ceea ce, pe infrastructură partajată, trăgea tot sistemul în jos pentru toți.

Lecția pe care au reținut-o fondatorii nu a fost tehnică. A fost că înfricoșătoarea problemă de scalare pe care și-o imaginaseră — cea care avea nevoie de o reconstrucție și o rundă de finanțare — era, când a fost măsurată, o reparație de două zile ascunsă în spatele unui simptom înspăimântător. Erau pe punctul de a petrece luni rezolvând problema greșită. Acel decalaj, dintre criza imaginată și cea măsurată, e unde se irosesc cei mai mulți bani de scalare.

Când chiar e momentul să reconstruiți o bucată

Toată această prudență față de scalarea prematură poate fi citită ca nu refactoriza niciodată, nu reconstrui niciodată. Nu despre asta e vorba. Uneori o parte a produsului chiar a ajuns la capătul vieții, iar a o peticii din nou e alegerea costisitoare. Trucul e să distingeți între o limită structurală reală și durerile obișnuite de creștere pe care le-ar rezolva o reparație măsurată.

Semnalul onest este acesta: reconstruiți o componentă când costul schimbării ei a devenit constant mai mare decât costul înlocuirii. Nu când e urâtă — codul urât care e stabil și rar atins e în regulă. Căutați o parte a sistemului unde fiecare schimbare e lentă și riscantă, unde aceleași erori revin mereu, unde dezvoltatorii noi nu pot lucra în siguranță și unde ați încercat deja reparațiile mai ieftine și ați dat de un zid. Când mai multe dintre acestea sunt adevărate deodată, o rescriere focalizată a acelei singure bucăți e decizia corectă.

Și când reconstruiți, reconstruiți o bucată — nu produsul. Rescrierea completă de la zero e cântecul de sirenă al scalării, lucrul care pare curat și ajunge să scufunde un an în timp ce concurenții livrează. Înlocuiți singura componentă putredă, în spatele unei granițe clare, în timp ce restul produsului continuă să ruleze și să câștige. Chirurgical, nu eroic.

Întrebări frecvente