Hogyan skálázzon egy SaaS-t indítás után anélkül, hogy tönkretenné a terméket

Az indítást mindenki ünnepli. Szinte senki sem figyelmezteti Önt arra, ami utána jön — arra a furcsa, izzadó tenyerű évre, amikor a termék, amely megszerezte az első száz ügyfelét, kezd megroggyani a következő ezer súlya alatt. Semmi drámai nem történik. A dolgok csak lassabbak, megbízhatatlanabbak, nehezebben módosíthatók lesznek. Egy keddi napon rájön, hogy egy funkció, amely régen egy napig tartott, most egy hetet vesz igénybe, és senki sem tudja pontosan megmondani, miért. A legtöbb SaaS-termék ott — nem az indításnál — dől el csendben, hogy nyer vagy veszít.

Sok alapítóval ültünk együtt pontosan ezen a ponton. Nem buknak el — épp ez a zavarba ejtő. A bevétel nő, a csapat bővül, a demók jól mennek. De a felszín alatt a termék nyög. A támogatási jegyek gyorsabban emelkednek, mint a felhasználók. A korábban unalmas telepítések most visszafojtott lélegzettel érkeznek. A kódbázis, amely egy éve okosnak tűnt, most aknamezőnek érződik, ahol minden változtatás azzal a kockázattal jár, hogy mást is elindít. Nem csináltak semmi rosszat. Csak kinőtték azt, amit építettek, és senki sem mondta nekik, hogy ennek így kell történnie.

Tehát ez az az útmutató, amelyet azt kívánnánk, bárcsak több alapító kapott volna meg, mielőtt megjelentek a repedések. Nem a hiperskálázásról, a Kubernetesről vagy arról szól, mit csinált egy unikornis ötvenmillió felhasználónál. A unalmas, döntő középső szakaszról szól — arról, ahogy eljutunk a kevés embernek működik-től a soknak működik-ig — anélkül, hogy mindent újraírnánk, elijesztenénk az ügyfeleket, vagy kiégetnénk a csapatot. A cél nem a tökéletes architektúra. Hanem egy termék, amely tovább nő, ahelyett, hogy csendben kezdene megtörni.

Mi törik meg valójában, amikor egy SaaS nő

Itt van az a rész, ami a legjobban meglepi az alapítókat: a skálázási problémák szinte sosem úgy érkeznek, mint a drámai leállás, amire felkészül. A szerver nem gyullad ki. Ehelyett a termék egyfajta enyhe lázat kap. Az azonnal betöltődő oldalak hárommásodpercessé válnak. Egy jelentés, amely a korai ügyfeleknek jól futott, időtúllépéssel leáll annál a nagynál, aki épp aláírt. Ugyanaz a hiba újra és újra felbukkan, mert a kód két része titokban függ egymástól, oly módon, amit senki sem dokumentált.

Ami valójában megtörik, ritkán a szerverei — hanem a feltételezései. Eleinte az első felhasználói alakjára épített: néhány fiók, kevés adat, egyszerű munkafolyamatok, mindenki nagyjából egyforma. A növekedés nem csak ugyanabból ad többet. Változatosságot ad hozzá. Egy ügyfél tízszer annyi adattal. Egy csapat, amely egy funkciót olyan módon használ, ahogy Ön sosem képzelte. Egy csúcs hétfőn reggel kilenckor, amikor mindenki egyszerre lép be. Mindegyik csendben megsért egy feltételezést, amely egy éve épült a kódjába, amikor a megsértése elképzelhetetlen volt.

Az a négy hely, ahol először szokott jelentkezni, kiszámítható. Az adatbázis szinte mindig a kanári — a kis táblákon azonnali lekérdezések kúszni kezdenek, ahogy az adat nő. A lassú végpont: egy-két oldal, amely túl sok munkát végez kérésenként, rendben van, amíg fel nem torlódik a forgalom. A törékeny telepítés, ahol bármit kiadni ijesztővé vált, mert a kód túlságosan összegabalyodott ahhoz, hogy át lehessen látni. És a támogatási terhelés, amely egyáltalán nem infrastruktúra, de a legigazabb korai jelzés arra, hogy a termék már nem illeszkedik ahhoz, ahogy az emberek valójában használják.

A csapda, hogy olyan problémákat old meg, amelyei még nincsenek

Mielőtt a javításról beszélnénk, egy figyelmeztetés, amely több terméket mentett meg, mint bármilyen optimalizálás. A növekvő SaaS legnagyobb veszélye nem a skála figyelmen kívül hagyása — hanem az, ha túl korán hajszolja. Abban a pillanatban, amikor egy alapító megérzi az első lassulást, az ösztöne ahhoz az architektúrához nyúl, amelyről egy híres mérnöki blogon olvasott. Mikroszolgáltatások. Üzenetsor. Több régiós felállás. Az adatbázis sardingolása, mielőtt egymillió sora lenne.

Így tölt el hat hónapot és egy vagyont olyan skálához épített infrastruktúrával, amelyet el sem ért, miközben a tényleges termék megáll. Sőt, most minden jövőbeli változtatást nehezebbé tett, mert egy elosztott rendszer drámaian összetettebb építeni és hibázni, mint az az egyszerű, ami volt. Egy olyan problémát, ami még nem volt, lecserélt egy garantáltra, ami ma van: semmi sem kerül kiadásra.

Az itteni fegyelem ugyanaz, amely eleve jó termékeket csinál: oldja meg az Ön előtt álló problémát, ne azt, amelyet hízelgő elképzelni. Egy unalmas, jól értett monolit, amelyet gyorsan tud módosítani, skálázásban felülmúl egy divatos elosztott rendszert, amelyhez fél hozzányúlni. A komplexitás olyan költség, amelyet minden nap megfizet, nem egyszeri vásárlás.

Mérjen, mielőtt bármit megváltoztat

Szinte minden alapító, akivel ebben a szakaszban találkozunk, meg van győződve róla, hogy tudja, hol a probléma. Az esetek nagyjából felében tévednek — nem mert hanyagok, hanem mert a megérzés szörnyű profilozó. A kódnak az a része, amely lassúnak érződik, gyakran rendben van; a valódi bűnös valami csendes lekérdezés, amely negyvenszer fut le egy oldalon, amelyre senki sem gondolt. Nem javíthatja meg azt, amit nem mért meg, és a találgatás itt az, ahogy a csapatok heteket töltenek a rossz dolog optimalizálásával.

Nincs szüksége puccos megfigyelhetőségi rendszerre a kezdéshez. Három unalmas számra van szüksége maga előtt, folyamatosan. Mely végpontok a leglassúbbak, és mennyire lassúak valós forgalom alatt. Mely adatbázis-lekérdezések veszik el a legtöbb összidőt — nem a leglassúbb egyetlen lekérdezés, hanem az, amelynek ideje több ezer híváson keresztül összeadódik. És hol történnek valójában a hibák, elegendő kontextussal a reprodukálásukhoz. E hárommal a köd általában egy napon belül felszáll.

1. 1
   Kapcsolja be az alapvető monitorozást

   Válaszidők végpontonként, hibaarányok és lassú lekérdezések naplózása az adatbázison. A hosztolt eszközök ezt egy délután alatt elintézik. Nem javíthat egy számot, amelyet nem lát.
2. 2
   Találja meg a valódi első hármat

   Az elfogyasztott összidő szerint rendezzen, ne megérzésre. Három bűnös szinte mindig a fájdalom nagy részéért felel. Írja le őket — ez a valódi ütemterve.
3. 3
   Javítson egyet, mérjen újra

   Változtasson egyetlen dolgon, majd ellenőrizze újra a számokat. Mielőtt továbblép, igazolja, hogy segített. Két változtatás egyszerre, és sosem fogja tudni, melyik számított.
4. 4
   Álljon le, amikor elég jó

   Mielőtt elkezdi, határozza meg az 'elég gyors'-at — mondjuk minden oldal egy másodperc alatt a jelenlegi terhelésnél. Azon túl az optimalizálás időpazarlás, nem győzelem.

Az az utolsó lépés fontosabb, mint amilyennek tűnik. A teljesítménymunka valóban függőséget okoz; mindig van még egy ezredmásodperc, amit le lehet faragni. De az ügyfelei nem érzik a különbséget 200 ms és 120 ms között, és az órák, amelyeket a hajszolásával tölt, olyan órák, amelyeket nem arra a funkcióra fordít, amely valóban növelné az üzletet. Mérjen, javítsa az első hármat, hirdessen győzelmet, lépjen tovább.

Az adatbázis szinte mindig az első fal

Ha pénzben kellene fogadnunk arra, hol éri el egy növekvő SaaS az első valódi plafonját, minden alkalommal az adatbázisra fogadnánk. Ez a rendszer azon egyetlen része, ahol a kis korai döntések a legkeményebben halmozódnak. Egy index nélküli lekérdezés ezer soron szempillantás alatt fut le, és egymilliónál megfeneklik. A kód nem változott. Az adat változott — és az adat csak nő.

A jó hír, hogy az adatbázis egyben az a hely is, ahol a legolcsóbb, legnagyobb hatású javítások élnek. A klasszikus a hiányzó index: egyetlen sor, amely egy többmásodperces lekérdezést azonnalivá tesz, mert az adatbázis abbahagyja minden sor átvizsgálását, hogy megtalálja azt a néhányat, amelyre szüksége van. Közvetlenül mögötte van az N+1 lekérdezés problémája — egy oldal, amely egyetlen kérdés helyett csendben ugyanazt a kis kérdést teszi fel az adatbázisnak százszor egy ciklusban. Mindkettő gyakori, mindkettő láthatatlan, amíg rá nem néz, és mindkettő általában egynapos javítás, ha egyszer megtalálta.

Van itt egy sorrend, amelyre támaszkodhat, és érdemes sorban követni, nem a végére ugrani. Először javítsa a lekérdezéseket — indexek, N+1-ek, a lassú jelentés. Aztán adjon hozzá gyorsítótárazást azokhoz az adatokhoz, amelyeket folyton olvasnak, de ritkán változnak. Csak ezután van értelme olvasási replikákról, nagyobb példányokról vagy az adatok szétválasztásáról beszélni. A legtöbb SaaS-terméknek sosincs szüksége a későbbi lépésekre. Csak az volt szükséges, hogy az elsőket rendesen elvégezzék.

A termék skálázása azt jelenti, hogy skálázza, ahogy módosítja

Itt az a váltás, amely meglepi az alapítókat: egy bizonyos ponton túl a skálázás nem arról szól, hogy a termék több felhasználót kezel, hanem arról, hogy a csapata több változást kezel. Amikor Ön és egy fejlesztő voltak, mindenki a fejében tartotta az egész rendszert. Bármit megváltoztathatott, mert tudta, mit érint. Öt vagy tíz embernél ez a mentális modell szétesik — és a kód, amely azt feltételezte, hogy mindenki mindent tud, teherré válik.

Ez a valódi oka annak, hogy a telepítések ijesztővé válnak. Nem az, hogy a kód egyik napról a másikra romlott el; az, hogy senki sem tudja már teljesen megjósolni egy változtatás robbanási sugarát. A megoldás nem hősködés vagy a kiadások befagyasztása. Hanem a befektetés abba a csillogásmentes állványzatba, amely lehetővé teszi egy nagyobb csapatnak, hogy mozogjon anélkül, hogy egymás lábára taposnának: egy automatizált tesztkészlet, amely elkapja a nyilvánvaló törést, telepítések, amelyek rutinszerűek a szertartás helyett, és egy mód arra, hogy egy rossz kiadást másodpercek alatt kapcsoljanak ki kapkodás helyett.

• Egy tesztkészlet, amely lefedi azt a maroknyi folyamatot, amely katasztrofális lenne, ha eltörne — bejelentkezés, fizetés, alapművelet. Nem mindent; a kritikus keveset.
• Telepítések, amelyek gombnyomásra futnak, nem szertartásra, hogy a kicsiben és gyakran kiadás biztonságossá váljon az idegtépő helyett.
• Egy gyors mód a visszaállításra, hogy egy rossz kiadás ötperces esemény legyen, ne egész éjszakás incidens.
• Funkciókapcsolók, hogy a kódot először néhány ügyfélnek adhassa ki, és azonnal kikapcsolhassa, ha rosszul viselkedik.
• Elegendő dokumentáció ahhoz, hogy egy ember szabadsága ne fagyassza be a termék egy egész területét.

Ebből semmi sem jelenik meg egy demóban. Egyik sem ad közvetlenül egy funkciót. És pontosan ez az a munka, amely elválaszt egy gyorsuló terméket attól, amely minden új felvétellel lassul. A jól skálázó csapatok azok, amelyek a termék biztonságos módosításának képességét önmagában funkcióként kezelik — mert skálán pontosan az.

Egy rövid történet a repedés pontjáról

Hogy konkrét legyen, itt egy összeállítás a munkánkból — a részletek elmosva, a forma hű a valósághoz. Egy kis SaaS terepszerviz-csapatok kezelésére jól indult, és pár száz fizető céggé nőtt. Az alapítók egyformán voltak izgatottak és kimerültek. Aztán aláírt az addigi legnagyobb ügyfelük: egy cég, amelynek több felhasználója és több történeti adata volt, mint az előző tíz ügyfelüknek együttvéve.

Egy héten belül az irányítópult, amelyben mindenki élt, kúszásig lelassult annál az ügyfélnél — és furcsamód mindenki másnál is. A támogatási jegyek kilőttek. Az alapítók azt feltételezték, hogy sokkal nagyobb szerverre van szükségük, és egy fájdalmas, drága átépítésre készültek. Ez volt az a pillanat, amikor minket bevontak, és az ösztön érthető volt, de hibás.

Nem nyúltunk az architektúrához. Bekapcsoltuk a lassú lekérdezések naplózását, és egy délután át figyeltük. A bűnös szinte zavarba ejtően kicsi volt: a fő irányítópult minden felhasználó feladatlistáját egy klasszikus N+1 mintával töltötte be, feladatonként egy lekérdezést indítva. Egy kis ügyfélnél ez néhány tucat ártalmatlan lekérdezést jelentett. Az új óriásnál oldalbetöltésenként ezreket — ami megosztott infrastruktúrán az egész rendszert lehúzta mindenki számára.

A tanulság, amelyet az alapítók levontak, nem technikai volt. Hanem az, hogy az a rémisztő skálázási probléma, amelyet elképzeltek — az, amely átépítést és tőkebevonást igényelt — megmérve egy kétnapos javítás volt, amely egy ijesztő tünet mögé bújt. Hónapokat készültek a rossz probléma megoldásával tölteni. Ez a rés, az elképzelt és a megmért válság között, az, ahol a legtöbb skálázási pénz elvész.

Mikor van valóban itt az ideje egy darab újraépítésének

Ez a sok óvatosság a korai skálázással szemben úgy is olvasható, mint soha ne refaktorálj, soha ne építs újra. Nem erről van szó. Néha a termék egy része valóban elérte élete végét, és ismét foltozni a drágább választás. A trükk abban áll, hogy megkülönböztesse a valódi szerkezeti korlátot a hétköznapi növekedési fájdalmaktól, amelyeket egy megmért javítás kezelne.

Az őszinte jelzés ez: akkor építsen újra egy komponenst, amikor a módosításának költsége tartósan magasabbá vált, mint a cseréjéé. Nem akkor, amikor csúnya — a csúnya kód, amely stabil és ritkán nyúlnak hozzá, rendben van. A rendszer azon részét keresi, ahol minden változtatás lassú és kockázatos, ahol ugyanazok a hibák térnek vissza, ahol az új fejlesztők nem tudnak biztonságosan dolgozni, és ahol már kipróbálta az olcsóbb javításokat, és falba ütközött. Amikor ezek közül több egyszerre igaz, annak az egy darabnak a célzott újraírása a helyes döntés.

És amikor újraépít, egy darabot építsen újra — ne a terméket. A teljes, alapoktól való újraírás a skálázás szirénének éneke, az a dolog, amely tisztának érződik, és azzal végződik, hogy elsüllyeszt egy évet, miközben a versenytársak szállítanak. Cserélje ki azt az egy rohadt komponenst, egy tiszta határ mögött, miközben a termék többi része tovább fut és keres. Sebészi, nem hősies.

Gyakori kérdések