Jak škálovat SaaS po spuštění, aniž byste rozbili produkt

Spuštění oslavují všichni. Skoro nikdo vás nevaruje před tím, co přijde potom — tím podivným, nervy drásajícím rokem, kdy produkt, který vám přivedl prvních sto zákazníků, začne praskat pod tíhou dalšího tisíce. Nic dramatického se neděje. Věci jsou jen pomalejší, vrtkavější, hůř se mění. Jedno úterý zjistíte, že funkce, která dřív zabrala den, teď zabere týden, a nikdo neumí přesně říct proč. Právě tam, ne při spuštění, se většina SaaS produktů tiše vyhrává nebo prohrává.

S mnoha zakladateli jsme seděli přesně v tomto bodě. Neselhávají — a to je na tom matoucí. Tržby rostou, tým se rozšiřuje, dema jdou dobře. Ale pod povrchem produkt sténá. Tikety podpory stoupají rychleji než uživatelé. Nasazení, která bývala nudná, teď přicházejí se zatajeným dechem. Kódová základna, která před rokem působila chytře, teď připomíná minové pole, kde každá změna riskuje, že odpálí něco jiného. Neudělali nic špatně. Jen přerostli to, co postavili, a nikdo jim neřekl, že se to tak má stát.

Tohle je tedy průvodce, který bychom přáli mít víc zakladatelů dřív, než se objevily praskliny. Není o hyperškálování, Kubernetes ani o tom, co udělal nějaký jednorožec při padesáti milionech uživatelů. Je o té nudné, rozhodující střední fázi — přechodu od funguje to pro pár lidí k funguje to pro mnoho — bez přepisování všeho, bez odrazení zákazníků a bez vyhoření týmu. Cílem není dokonalá architektura. Je to produkt, který dál roste, místo aby se tiše začal lámat.

Co se vlastně láme, když SaaS roste

Tady je část, která zakladatele překvapuje nejvíc: problémy se škálováním skoro nikdy nepřicházejí jako dramatický výpadek, na který se připravujete. Server nezačne hořet. Místo toho produkt dostane jakousi mírnou horečku. Stránky, které se načítaly okamžitě, začnou trvat tři sekundy. Report, který běžel v pořádku prvním zákazníkům, vyprší u toho velkého, který právě podepsal. Stejná chyba se pořád vrací, protože dvě části kódu na sobě tajně závisí způsobem, který nikdo nezdokumentoval.

Co se ve skutečnosti láme, zřídka jsou vaše servery — jsou to vaše předpoklady. Na začátku jste stavěli pro podobu prvních uživatelů: pár účtů, málo dat, jednoduché workflow, všichni zhruba stejní. Růst nepřidává jen víc téhož. Přidává rozmanitost. Zákazník s desetkrát víc daty. Tým, který používá funkci způsobem, jaký byste si nikdy nepředstavili. Špička v pondělí v devět ráno, kdy se všichni přihlásí naráz. Každý z nich tiše poruší předpoklad zabudovaný do kódu před rokem, kdy bylo jeho porušení nemyslitelné.

Čtyři místa, kde se to obvykle projeví nejdřív, jsou předvídatelná. Databáze je skoro vždy ten kanárek — dotazy, které byly na malých tabulkách okamžité, se s růstem dat plazí. Pomalý endpoint: jedna dvě stránky, které na požadavek dělají příliš mnoho práce, v pohodě, dokud se nenavrší provoz. Křehké nasazení, kde se cokoliv dodat stalo děsivým, protože kód je příliš zamotaný, aby se v něm dalo vyznat. A zátěž podpory, která vůbec není infrastrukturou, ale je nejpravdivějším raným signálem, že produkt už neodpovídá tomu, jak ho lidé doopravdy používají.

Past řešení problémů, které ještě nemáte

Než si povíme o opravách, varování, které zachránilo víc produktů než jakákoli optimalizace. Největší hrozbou pro rostoucí SaaS není ignorovat škálu — je honit ji příliš brzy. Ve chvíli, kdy zakladatel pocítí první zpomalení, instinkt sáhne po architektuře, o které četl na slavném inženýrském blogu. Mikroslužby. Frontu zpráv. Víceregionové nasazení. Šardování databáze dřív, než má milion řádků.

Takhle utratíte šest měsíců a jmění na budování infrastruktury pro škálu, které jste nedosáhli, zatímco se skutečný produkt zastaví. Hůř, právě jste si ztížili každou budoucí změnu, protože distribuovaný systém je dramaticky složitější na stavbu i ladění než ten jednoduchý, který jste měli. Vyměnili jste problém, který jste ještě neměli, za zaručený, který máte dnes: nic se nedodává.

Disciplína je tu stejná, jaká dělá dobré produkty už od začátku: vyřešte problém, který máte před sebou, ne ten, který vám lichotí si představovat. Nudný, dobře pochopený monolit, který umíte rychle měnit, ve škálování předčí módní distribuovaný systém, kterého se bojíte dotknout. Složitost je náklad, který platíte každý den, ne jednorázový nákup.

Než cokoliv změníte, změřte to

Skoro každý zakladatel, kterého v této fázi potkáme, je přesvědčen, že ví, kde je problém. Mýlí se zhruba v polovině případů — ne proto, že by byli nedbalí, ale protože intuice je hrozný profilovač. Část kódu, která se zdá pomalá, je často v pořádku; skutečný viník je nějaký tichý dotaz běžící čtyřicetkrát na stránce, na kterou nikdo nemyslel. Nemůžete opravit, co jste nezměřili, a hádání je tady to, jak týmy tráví týdny optimalizací špatné věci.

K začátku nepotřebujete nóbl observabilitní stack. Potřebujete pořád před očima tři nudná čísla. Které endpointy jsou nejpomalejší a jak pomalé pod skutečným provozem. Které databázové dotazy zaberou nejvíc celkového času — ne nejpomalejší jednotlivý dotaz, ale ten, jehož čas se sečte přes tisíce volání. A kde se chyby vlastně dějí, s dostatkem kontextu, aby šly reprodukovat. S těmito třemi se mlha obvykle rozplyne během dne.

1. 1
   Zapněte základní monitoring

   Doby odezvy na endpoint, míry chyb a logování pomalých dotazů v databázi. Hostované nástroje to zvládnou za odpoledne. Nemůžete zlepšit číslo, které nevidíte.
2. 2
   Najděte skutečnou trojku

   Seřaďte podle celkového spotřebovaného času, ne podle pocitu. Tři viníci skoro vždy stojí za většinou bolesti. Sepište si je — to je vaše skutečná roadmapa.
3. 3
   Opravte jeden, znovu změřte

   Změňte jedinou věc, pak znovu zkontrolujte čísla. Než půjdete dál, ověřte, že to pomohlo. Dvě změny naráz a nikdy se nedozvíte, která zabrala.
4. 4
   Skončete, když je to dost dobré

   Definujte si 'dost rychlé', než začnete — řekněme každá stránka pod sekundu při současné zátěži. Za tím je optimalizace žrout času, ne výhra.

Ten poslední krok je důležitější, než vypadá. Práce na výkonu je vážně návyková; vždycky je co osekat o další milisekundu. Ale vaši zákazníci necítí rozdíl mezi 200 ms a 120 ms a hodiny, které honěním strávíte, jsou hodiny nevěnované funkci, která by byznys skutečně rozrostla. Změřte, opravte trojku, vyhlaste vítězství, jděte dál.

Databáze je skoro vždy první zeď

Kdybychom měli vsadit peníze na to, kde rostoucí SaaS narazí na svůj první skutečný strop, vsadili bychom pokaždé na databázi. Je to jediná část systému, kde se malá raná rozhodnutí skládají nejtvrději. Dotaz bez indexu proběhne na tisíci řádků mrknutím oka a na milionu se zadrhne. Kód se nezměnil. Změnila se data — a data jen rostou.

Dobrá zpráva je, že databáze je zároveň místem, kde žijí nejlevnější opravy s největším dopadem. Klasikou je chybějící index: jediný řádek, který z mnohasekundového dotazu udělá okamžitý, protože databáze přestane prohledávat každý řádek, aby našla těch pár, které potřebuje. Hned za ním je problém dotazů N+1 — stránka, která se místo jedné otázky tiše ptá databáze stejnou malou otázkou stokrát v cyklu. Obojí je běžné, obojí je neviditelné, dokud se nepodíváte, a obojí je obvykle oprava na jeden den, jakmile to najdete.

Je tu posloupnost, o kterou se lze opřít, a vyplatí se ji dodržet v pořadí, ne skákat ke konci. Nejdřív opravte dotazy — indexy, N+1, pomalý report. Pak přidejte cachování pro data, která se čtou neustále, ale mění zřídka. Až pak má smysl mluvit o read replikách, větších instancích nebo oddělení dat. Většina SaaS produktů pozdější kroky nikdy nepotřebuje. Jen potřebovaly ty první pořádně udělat.

Škálovat produkt znamená škálovat, jak ho měníte

Tady je posun, který zakladatele zaskočí: za určitým bodem přestává být škálování o tom, že produkt zvládá víc uživatelů, a začíná být o tom, že váš tým zvládá víc změn. Když jste byli vy a jeden vývojář, každý držel celý systém v hlavě. Mohli jste změnit cokoliv, protože jste věděli, čeho se to dotkne. Při pěti nebo deseti lidech se ten mentální model rozpadá — a kód, který předpokládal, že všichni vědí všechno, se stává přítěží.

Tohle je skutečný důvod, proč se nasazení stávají děsivými. Není to tím, že by se kód přes noc zhoršil; je to tím, že nikdo už nedokáže plně předpovědět dosah změny. Řešením není hrdinství ani zmrazení dodávek. Je to investice do nevzhledného lešení, které většímu týmu umožní pohybovat se, aniž si lezou do zelí: automatizovaná sada testů, která zachytí zjevné rozbití, nasazení, která jsou rutinou místo obřadu, a způsob, jak špatné vydání vypnout během sekund místo zmatkování.

• Sada testů pokrývající tu hrstku toků, jejichž rozbití by bylo katastrofou — přihlášení, platba, klíčová akce. Ne všechno; jen ty kritické.
• Nasazení na tlačítko, ne rituál, aby se dodávání malé a často stalo bezpečným místo nervydrásajícím.
• Rychlý způsob, jak vrátit změnu, aby špatné vydání byla pětiminutová záležitost, ne celonoční incident.
• Feature flagy, abyste mohli nasadit kód nejdřív pár zákazníkům a okamžitě ho vypnout, když se chová špatně.
• Dost dokumentace, aby dovolená jednoho člověka nezmrazila celou oblast produktu.

Nic z toho se v demu neukáže. Nic z toho přímo nepřidá funkci. A přitom je to přesně ta práce, která odlišuje produkt, který dál zrychluje, od toho, který s každým novým náborem zpomaluje. Týmy, které škálují dobře, jsou ty, které berou svou schopnost bezpečně měnit produkt jako funkci samu o sobě — protože ve velkém přesně to je.

Krátký příběh z bodu praskání

Abychom to udělali konkrétní, tady je kompozit poskládaný z naší práce — detaily rozmazané, podstata věrná životu. Malý SaaS pro řízení týmů terénních služeb se dobře spustil a vyrostl na pár set platících firem. Zakladatelé byli stejně nadšení jako vyčerpaní. Pak podepsal jejich dosud největší zákazník: firma s víc uživateli a víc historickými daty než jejich předchozích deset klientů dohromady.

Během týdne se dashboard, ve kterém všichni žili, pro toho zákazníka zpomalil do plazení — a kupodivu i pro všechny ostatní. Tikety podpory vystřelily. Zakladatelé předpokládali, že potřebují mnohem větší server, a chystali se na bolestivou, drahou přestavbu architektury. To byla chvíle, kdy nás přizvali, a ten instinkt byl pochopitelný, ale špatný.

Architektury jsme se nedotkli. Zapnuli jsme logování pomalých dotazů a jedno odpoledne sledovali. Viník byl skoro trapně malý: hlavní dashboard načítal seznam úkolů každého uživatele klasickým vzorem N+1, vystřeloval jeden dotaz na úkol. U malého zákazníka to znamenalo pár desítek neškodných dotazů. U nového obra to znamenalo tisíce na načtení stránky — což na sdílené infrastruktuře stahovalo celý systém dolů pro všechny.

Ponaučení, které si zakladatelé odnesli, nebylo technické. Bylo to, že ten děsivý problém se škálováním, který si představovali — ten, který potřeboval přestavbu a kolo financování — byl po změření dvoudenní opravou schovanou za děsivým příznakem. Chystali se strávit měsíce řešením špatného problému. Právě ta mezera mezi představovanou a změřenou krizí je místem, kde se promrhá nejvíc peněz za škálování.

Kdy je opravdu čas přestavět nějaký kus

Všechna ta opatrnost vůči předčasnému škálování může znít jako nikdy nerefaktoruj, nikdy nepřestavuj. O to nejde. Někdy nějaká část produktu doopravdy dosáhla konce své životnosti a další záplatování je ta dražší volba. Trik je rozeznat skutečný strukturální limit od běžných růstových bolestí, které by zvládla měřená oprava.

Poctivý signál je tento: přestavte komponentu, když se náklad na její změnu stal trvale vyšším než náklad na její nahrazení. Ne když je ošklivá — ošklivý kód, který je stabilní a sahá se na něj zřídka, je v pořádku. Hledáte část systému, kde je každá změna pomalá a riziková, kde se stejné chyby pořád vrací, kde noví vývojáři nemohou bezpečně pracovat a kde jste už vyzkoušeli levnější opravy a narazili na zeď. Když je několik z těchto věcí pravda naráz, je cílené přepsání toho jednoho kusu ta správná volba.

A když přestavujete, přestavte kus — ne produkt. Kompletní přepsání od základů je sirénní píseň škálování, věc, která působí čistě a skončí potopením roku, zatímco konkurence dodává. Nahraďte tu jednu shnilou komponentu za jasnou hranicí, zatímco zbytek produktu dál běží a vydělává. Chirurgicky, ne hrdinsky.

Časté otázky