Ako škálovať SaaS po spustení bez rozbitia produktu

Všetci oslavujú spustenie. Takmer nikto vás nevaruje pred časťou, ktorá príde potom — pred tým zvláštnym, napätým rokom, keď produkt, ktorý vám priviedol prvých sto zákazníkov, začne podliehať pod ťarchou ďalšej tisícky. Nedeje sa nič dramatické. Veci jednoducho začnú byť pomalšie, nestabilnejšie, ťažšie meniteľné. Jeden utorok si uvedomíte, že funkcia, ktorá kedysi trvala deň, teraz trvá týždeň, a nikto vám presne nepovie prečo. Práve tam, a nie pri spustení, sa väčšina SaaS produktov potichu vyhráva alebo prehráva.

Sedeli sme s mnohými zakladateľmi presne v tomto bode. Nezlyhávajú — to je na tom mätúce. Tržby rastú, tím sa rozširuje, demá idú dobre. Ale pod povrchom produkt stoná. Tikety podpory stúpajú rýchlejšie než používatelia. Nasadenia, ktoré boli kedysi nudné, teraz prichádzajú so zatajeným dychom. Codebase, ktorý pred rokom pôsobil dômyselne, teraz pôsobí ako mínové pole, kde každá zmena hrozí, že spustí niečo iné. Neurobili nič zlé. Jednoducho prerástli to, čo postavili, a nikto im nepovedal, že sa to má stať.

Toto je teda návod, ktorý by sme priali viacerým zakladateľom predtým, než sa objavili praskliny. Nie je o hyperškálovaní, Kubernetes ani o tom, čo nejaký jednorožec urobil pri päťdesiatich miliónoch používateľov. Je o tom nudnom, rozhodujúcom strede — prechode z funguje to pre pár ľudí na funguje to pre mnohých — bez prepisovania všetkého, bez odplašenia zákazníkov a bez vyhorenia tímu. Cieľom nie je dokonalá architektúra. Je to produkt, ktorý ďalej rastie, namiesto takého, ktorý sa potichu začína lámať.

Čo sa naozaj láme, keď SaaS rastie

Tu je tá časť, ktorá zakladateľov prekvapuje najviac: problémy škálovania takmer nikdy neprídu ako dramatický výpadok, na ktorý sa pripravujete. Server nezačne horieť. Namiesto toho si produkt vyvinie istý druh miernej horúčky. Stránky, ktoré sa načítavali okamžite, začnú trvať tri sekundy. Report, ktorý fungoval dobre pre prvých zákazníkov, vyprší pri tom veľkom, ktorý sa práve zaregistroval. Tá istá chyba sa stále vracia, pretože dve časti kódu na sebe potajme závisia spôsobom, ktorý nikto nezdokumentoval.

To, čo sa naozaj láme, sú zriedka vaše servery — sú to vaše predpoklady. Na začiatku ste stavali pre tvar svojich prvých používateľov: pár účtov, malé dáta, jednoduché pracovné postupy, všetci približne rovnakí. Rast nepridáva len viac toho istého. Pridáva rozmanitosť. Zákazníka s desaťnásobkom dát. Tím, ktorý používa funkciu spôsobom, aký ste si nikdy nepredstavovali. Špičku v pondelok o 9:00, keď sa všetci prihlásia naraz. Každý z nich potichu poruší predpoklad zabudovaný do vášho kódu pred rokom, keď bolo jeho porušenie nemysliteľné.

Štyri miesta, kde sa to zvyčajne ukáže ako prvé, sú predvídateľné. Databáza je takmer vždy ten kanárik — dopyty, ktoré boli okamžité nad malými tabuľkami, sa pri raste dát plazia. Pomalý endpoint: jedna či dve stránky, ktoré robia priveľa práce na požiadavku, v poriadku, kým sa premávka nenahromadí. Krehké nasadenie, kde sa vydanie čohokoľvek stalo desivým, lebo kód je príliš zamotaný na to, aby sa o ňom dalo uvažovať. A záťaž podpory, ktorá vôbec nie je infraštruktúrou, ale je najpravdivejším skorým signálom, že produkt už nezodpovedá tomu, ako ho ľudia skutočne používajú.

Pasca riešenia problémov, ktoré ešte nemáte

Skôr než budeme hovoriť o opravách, varovanie, ktoré zachránilo viac produktov než akákoľvek optimalizácia. Najväčšou hrozbou pre rastúci SaaS nie je ignorovanie škály — je to jej naháňanie priskoro. Vo chvíli, keď zakladateľ pocíti prvé spomalenie, je inštinktom siahnuť po architektúre, o ktorej čítal na nejakom slávnom inžinierskom blogu. Mikroslužby. Front správ. Nastavenie vo viacerých regiónoch. Šardovanie databázy skôr, než má milión riadkov.

Takto strávite šesť mesiacov a celý majetok budovaním infraštruktúry pre škálu, ktorú ste nedosiahli, zatiaľ čo skutočný produkt sa prestane pohýnať. Čo je horšie, teraz ste každú budúcu zmenu sťažili, pretože distribuovaný systém je dramaticky zložitejší na vybudovanie a ladenie než jednoduchý, ktorý ste mali. Vymenili ste problém, ktorý ste ešte nemali, za zaručený, ktorý máte dnes: nič sa nevydáva.

Disciplína je tu tá istá, ktorá v prvom rade robí dobré produkty: riešte problém, ktorý máte pred sebou, nie ten, ktorý vám lichotí si predstavovať. Nudný, dobre pochopený monolit, ktorý viete rýchlo meniť, prekoná v škálovaní módny distribuovaný systém, ktorého sa bojíte dotknúť. Zložitosť je náklad, ktorý platíte každý jeden deň, nie jednorazový nákup.

Merajte skôr, než čokoľvek zmeníte

Takmer každý zakladateľ, ktorého v tejto fáze stretneme, je presvedčený, že vie, kde je problém. V polovici prípadov sa mýli — nie preto, že by bol nedbalý, ale preto, že intuícia je hrozný profiler. Časť kódu, ktorá pôsobí pomaly, je často v poriadku; skutočným vinníkom je nejaký tichý dopyt, ktorý beží štyridsaťkrát na stránke, na ktorú nikto nepomyslel. Nemôžete opraviť to, čo ste nezmerali, a hádanie je tu spôsobom, akým tímy trávia týždne optimalizovaním nesprávnej veci.

Na začiatok nepotrebujete vymakaný observability stack. Potrebujete tri nudné čísla pred očami, stále. Ktoré endpointy sú najpomalšie a ako pomalé pri skutočnej premávke. Ktoré databázové dopyty zaberú najviac celkového času — nie najpomalší jednotlivý dopyt, ale ten, ktorého čas sa nasčíta cez tisíce volaní. A kde sa chyby skutočne dejú, s dostatkom kontextu na ich reprodukovanie. S týmito tromi sa hmla zvyčajne rozplynie do jedného dňa.

1. 1
   Zapnite základné monitorovanie

   Časy odozvy podľa endpointu, miery chýb a logovanie pomalých dopytov na databáze. Hostované nástroje to zvládnu za jedno popoludnie. Nemôžete zlepšiť číslo, ktoré nevidíte.
2. 2
   Nájdite skutočnú trojku najhorších

   Zoraďte podľa celkového spotrebovaného času, nie podľa pocitu. Traja vinníci takmer vždy spôsobujú väčšinu bolesti. Zapíšte si ich — to je váš skutočný plán.
3. 3
   Opravte jeden, zmerajte znova

   Zmeňte jedinú vec, potom znova skontrolujte čísla. Potvrďte, že to pomohlo, skôr než budete pokračovať. Dve zmeny naraz a nikdy nebudete vedieť, ktorá bola dôležitá.
4. 4
   Zastavte, keď je to dosť dobré

   Definujte si 'dosť rýchlo' skôr, než začnete — povedzme každú stránku pod sekundu pri aktuálnej záťaži. Za tým je optimalizácia žrútom času, nie výhrou.

Ten posledný krok je dôležitejší, než vyzerá. Práca na výkone je naozaj návyková; vždy je tu ďalšia milisekunda na orezanie. Ale vaši zákazníci necítia rozdiel medzi 200 ms a 120 ms a hodiny, ktoré strávite jeho naháňaním, sú hodiny, ktoré neminiete na funkciu, ktorá by biznis naozaj rozrástla. Zmerajte, opravte trojku najhorších, vyhláste víťazstvo, pokračujte ďalej.

Databáza je takmer vždy prvá stena

Keby sme mali staviť peniaze na to, kde rastúci SaaS narazí na svoj prvý skutočný strop, stavili by sme zakaždým na databázu. Je to jediná časť systému, kde sa malé skoré rozhodnutia hromadia najťažšie. Dopyt bez indexu beží nad tisíckou riadkov za okamih a nad miliónom sa zadrhne. Kód sa nezmenil. Zmenili sa dáta — a dáta len rastú.

Dobrou správou je, že databáza je zároveň miestom, kde sídlia najlacnejšie opravy s najväčším dopadom. Klasikou je chýbajúci index: jediný riadok, ktorý zmení niekoľkosekundový dopyt na okamžitý, lebo databáza prestane prehľadávať každý riadok, aby našla tých pár, ktoré potrebuje. Hneď za ním je problém N+1 dopytov — stránka, ktorá namiesto jednej otázky potichu kladie databáze tú istú malú otázku stokrát v cykle. Oba sú bežné, oba sú neviditeľné, kým sa nepozriete, a oba sú zvyčajne opravou na jeden deň, keď ich raz nájdete.

Existuje tu postupnosť, na ktorú sa oplatí spoľahnúť, a vyplatí sa ísť podľa poradia namiesto skoku na koniec. Najprv opravte dopyty — indexy, N+1, pomalý report. Potom pridajte cachovanie pre dáta, ktoré sa čítajú neustále, ale menia zriedka. Až potom má zmysel hovoriť o read replikách, väčších inštanciách či oddeľovaní dát. Väčšina SaaS produktov nikdy nepotrebuje neskoršie kroky. Len potrebovali, aby boli tie prvé urobené poriadne.

Škálovať produkt znamená škálovať to, ako ho meníte

Tu je posun, ktorý zaskočí zakladateľov nepripravených: za istým bodom prestáva byť škálovanie o tom, že produkt zvláda viac používateľov, a začína byť o tom, že váš tím zvláda viac zmien. Keď ste boli vy a jeden vývojár, každý mal celý systém v hlave. Mohli ste zmeniť čokoľvek, lebo ste vedeli, čoho sa to dotkne. Pri piatich či desiatich ľuďoch sa tento mentálny model rozpadne — a kód, ktorý predpokladal, že každý vie všetko, sa stáva záťažou.

Toto je skutočný dôvod, prečo sa nasadenia stávajú desivými. Nie je to tým, že by kód cez noc spľaskol; je to tým, že nikto už nedokáže úplne predvídať polomer výbuchu zmeny. Riešením nie je hrdinstvo ani zmrazenie vydávania. Je to investícia do nelichotivého lešenia, ktoré umožní väčšiemu tímu pohybovať sa bez toho, aby si navzájom liezli do cesty: automatizovaná sada testov, ktorá zachytí zjavné poruchy, nasadenia, ktoré sú rutinou namiesto obradu, a spôsob, ako zlé vydanie vypnúť za sekundy namiesto zúfalého zháňania.

• Sada testov pokrývajúca tých pár tokov, ktoré by boli katastrofálne, keby sa pokazili — prihlásenie, platba, hlavná akcia. Nie všetko; tie kritické nemnohé.
• Nasadenia, ktoré bežia na tlačidlo, nie ako rituál, takže vydávanie po malom a často sa stáva bezpečným namiesto nervydrásajúceho.
• Rýchly spôsob na vrátenie zmeny, takže zlé vydanie je päťminútovou udalosťou, nie celonočným incidentom.
• Feature flagy, takže môžete kód vydať najprv pár zákazníkom a okamžite ho vypnúť, ak sa správa zle.
• Dostatok dokumentácie, aby dovolenka jedného človeka nezamrazila celú oblasť produktu.

Nič z toho sa neukáže v deme. Nič z toho priamo nepridáva funkciu. A je to presne tá práca, ktorá oddeľuje produkt, ktorý ďalej zrýchľuje, od takého, ktorý sa s každým novým prijatím spomaľuje. Tímy, ktoré škálujú dobre, sú tie, ktoré svoju schopnosť bezpečne meniť produkt považujú za funkciu samu o sebe — pretože pri škále to presne ňou je.

Krátky príbeh z bodu praskania

Aby sme to konkretizovali, tu je kompozit načrtnutý z práce, ktorú sme robili — detaily rozmazané, tvar verný realite. Malý SaaS na riadenie terénnych servisných tímov sa dobre spustil a narástol na niekoľko stoviek platiacich firiem. Zakladatelia boli nadšení a vyčerpaní rovnakou mierou. Potom podpísal ich vôbec najväčší zákazník: firma s viac používateľmi a viac historickými dátami než predchádzajúcich desať klientov dokopy.

Do týždňa sa dashboard, v ktorom všetci žili, spomalil na plazenie pre toho zákazníka — a, kupodivu, aj pre všetkých ostatných. Tikety podpory prudko stúpli. Zakladatelia predpokladali, že potrebujú oveľa väčší server, a pripravovali sa na bolestivú, drahú prearchitektúru. To bola chvíľa, keď nás privolali, a inštinkt bol pochopiteľný, no nesprávny.

Architektúry sme sa nedotkli. Zapli sme logovanie pomalých dopytov a jedno popoludnie sledovali. Vinník bol takmer trápne malý: hlavný dashboard načítaval zoznam úloh každého používateľa klasickým vzorom N+1, vystrelujúc jeden dopyt na úlohu. Pre malého zákazníka to znamenalo pár desiatok neškodných dopytov. Pre nového obra to znamenalo tisíce na načítanie stránky — čo na zdieľanej infraštruktúre stiahlo celý systém dole pre všetkých.

Ponaučenie, ktoré si zakladatelia odniesli, nebolo technické. Bolo to, že ten desivý problém škálovania, ktorý si predstavovali — ten, čo vyžadoval prestavbu a získanie kapitálu — bol po zmeraní dvojdňovou opravou skrytou za desivým príznakom. Boli na pokraji toho, že strávia mesiace riešením nesprávneho problému. Tá medzera medzi vymyslenou krízou a tou zmeranou je miestom, kde sa premrhá väčšina peňazí na škálovanie.

Kedy je naozaj čas prestavať jeden kus

Všetka táto opatrnosť ohľadom predčasného škálovania sa môže čítať ako nikdy nerefaktoruj, nikdy neprestavuj. Tak to nie je. Niekedy časť produktu naozaj dosiahla koniec svojej životnosti a jej ďalšie záplatovanie je tým drahým riešením. Trik je v rozlíšení skutočného štrukturálneho limitu od bežných bolestí rastu, ktoré by zmeraná oprava zvládla.

Úprimný signál je tento: prestavte komponent, keď sa náklady na jeho zmenu stali sústavne vyššími než náklady na jeho nahradenie. Nie keď je škaredý — škaredý kód, ktorý je stabilný a zriedka sa ho niekto dotýka, je v poriadku. Hľadáte časť systému, kde je každá zmena pomalá a riskantná, kde sa stále vracajú tie isté chyby, kde noví vývojári nemôžu bezpečne pracovať a kde ste už vyskúšali lacnejšie opravy a narazili na stenu. Keď je niekoľko z týchto vecí pravdivých naraz, cielené prepísanie toho jedného kusa je správnym ťahom.

A keď už prestavujete, prestavte kus — nie produkt. Úplné prepísanie od základu je sirénskym spevom škálovania, tým, čo pôsobí čisto a nakoniec potopí rok, zatiaľ čo konkurenti vydávajú. Vymeňte ten jeden zhnitý komponent za jasnou hranicou, zatiaľ čo zvyšok produktu ďalej beží a zarába. Chirurgicky, nie hrdinsky.

Časté otázky