Как да мащабирате SaaS след старта, без да счупите продукта

Всички празнуват старта. Почти никой не ви предупреждава за частта, която идва след това — странната, изнервяща година, когато продуктът, който ви е донесъл първите сто клиента, започва да поддава под тежестта на следващата хиляда. Нищо драматично не се случва. Нещата просто стават по-бавни, по-нестабилни, по-трудни за промяна. Един вторник осъзнавате, че функция, която преди отнемаше ден, сега отнема седмица, и никой не може съвсем да обясни защо. Точно там, а не при старта, повечето SaaS продукти тихо се печелят или губят.

Седели сме с много основатели точно в този момент. Те не се провалят — това е объркващото. Приходите растат, екипът се разширява, демонстрациите минават добре. Но отдолу продуктът стене. Заявките към поддръжката се качват по-бързо от потребителите. Внедрявания, които преди бяха скучни, сега идват със затаен дъх. Кодовата база, която преди година изглеждаше умна, сега прилича на минно поле, където всяка промяна рискува да задейства нещо друго. Те не са направили нищо погрешно. Просто са надраснали онова, което са изградили, и никой не им е казал, че така трябва да стане.

Затова това е ръководството, което ни се иска повече основатели да имаха, преди да се появят пукнатините. То не е за хипермащаб, Kubernetes или какво е направил някой еднорог при петдесет милиона потребители. То е за скучната, решаваща среда — преходът от работи за неколцина към работи за мнозина — без да пренаписвате всичко, да плашите клиентите си или да изтощавате екипа си. Целта не е перфектна архитектура. Целта е продукт, който продължава да расте, вместо такъв, който тихо започва да се чупи.

Какво всъщност се чупи, когато SaaS расте

Ето частта, която изненадва основателите най-много: проблемите с мащабирането почти никога не идват като драматичното спиране, за което се подготвяте. Сървърът не пламва. Вместо това продуктът развива нещо като лека треска. Страници, които се зареждаха мигновено, започват да отнемат три секунди. Справка, която работеше добре за ранните клиенти, изтича по време за големия, който току-що подписа. Един и същ бъг се появява отново, защото две части от кода тайно зависят една от друга по начин, който никой не е документирал.

Това, което наистина се чупи, рядко са сървърите ви — а вашите предположения. В началото сте изграждали за формата на първите си потребители: няколко акаунта, малко данни, прости работни процеси, всички горе-долу еднакви. Растежът не просто добавя повече от същото. Той добавя разнообразие. Клиент с десет пъти повече данни. Екип, който използва функция по начин, който никога не сте си представяли. Пик в 9 сутринта в понеделник, когато всички влизат наведнъж. Всеки от тях тихо нарушава предположение, заложено в кода ви преди година, когато нарушаването му беше немислимо.

Четирите места, където това обикновено се проявява първо, са предсказуеми. Базата данни почти винаги е канарчето — заявки, които бяха мигновени върху малки таблици, пълзят с нарастването на данните. Бавният ендпойнт: една-две страници вършат твърде много работа на заявка, добре е, докато трафикът не се натрупа. Крехкото внедряване, при което пускането на каквото и да е е станало плашещо, защото кодът е твърде заплетен, за да се осмисли. И натоварването на поддръжката, което изобщо не е инфраструктура, но е най-верният ранен сигнал, че продуктът вече не пасва на това как хората наистина го използват.

Капанът да решавате проблеми, които още нямате

Преди да говорим за поправяне на нещата, едно предупреждение, спасило повече продукти от която и да е оптимизация. Най-голямата заплаха за растящ SaaS не е пренебрегването на мащаба — а гоненето му твърде рано. В мига, в който основателят усети първото забавяне, инстинктът е да посегне към архитектурата, за която е чел в някой известен инженерен блог. Микроуслуги. Опашка за съобщения. Многорегионална настройка. Разделяне на базата данни, преди тя да има милион реда.

Така прекарвате шест месеца и цяло състояние в изграждане на инфраструктура за мащаб, който не сте достигнали, докато самият продукт спира да помръдва. По-лошо, вече сте направили всяка бъдеща промяна по-трудна, защото разпределената система е драматично по-сложна за изграждане и дебъгване от простата, която имахте. Заменили сте проблем, който още нямахте, с гарантиран, който имате днес: нищо не се пуска.

Дисциплината тук е същата, която прави добрите продукти на първо място: решавайте проблема пред себе си, а не онзи, който ви ласкае да си представите. Скучен, добре разбран монолит, който можете да променяте бързо, ще надмине по мащаб модна разпределена система, която се боите да докоснете. Сложността е цена, която плащате всеки божи ден, а не еднократна покупка.

Измервайте, преди да промените каквото и да било

Почти всеки основател, когото срещаме на този етап, е убеден, че знае къде е проблемът. В половината случаи греши — не защото е немарлив, а защото интуицията е ужасен профайлер. Частта от кода, която усещате като бавна, често е наред; истинският виновник е някоя тиха заявка, изпълняваща се четирийсет пъти на страница, за която никой не се е сетил. Не можете да поправите това, което не сте измерили, а гаденето тук е начинът, по който екипи прекарват седмици в оптимизиране на грешното нещо.

Не ви трябва изтънчен стек за наблюдаемост, за да започнете. Трябват ви три скучни числа пред очите, през цялото време. Кои ендпойнти са най-бавни и колко бавни при реален трафик. Кои заявки към базата отнемат най-много общо време — не най-бавната отделна заявка, а онази, чието време се натрупва през хиляди извиквания. И къде грешките наистина се случват, с достатъчно контекст, за да ги възпроизведете. С тези три мъглата обикновено се вдига за ден.

1. 1
   Включете базов мониторинг

   Времена за отговор по ендпойнт, нива на грешки и логване на бавни заявки в базата. Хостнатите инструменти правят това за един следобед. Не можете да подобрите число, което не виждате.
2. 2
   Намерете истинската тройка

   Сортирайте по общо изразходвано време, не по вътрешно усещане. Трима виновници почти винаги обясняват по-голямата част от болката. Запишете ги — това е истинската ви пътна карта.
3. 3
   Поправете едно, измерете отново

   Променете едно-единствено нещо, после проверете числата отново. Потвърдете, че е помогнало, преди да продължите. Две промени наведнъж и никога няма да разберете коя е имала значение.
4. 4
   Спрете, когато е достатъчно добре

   Дефинирайте „достатъчно бързо“, преди да започнете — да речем, всяка страница под секунда при текущото натоварване. Отвъд това оптимизацията е поглъщане на време, а не победа.

Тази последна стъпка има по-голямо значение, отколкото изглежда. Работата по производителността е истински пристрастяваща; винаги има още една милисекунда за орязване. Но клиентите ви не усещат разликата между 200 мс и 120 мс, а часовете, които прекарвате в гонене на това, са часове, които не сте отделили за функцията, която наистина би разраснала бизнеса. Измервайте, поправяйте първата тройка, обявявайте победа, продължавайте напред.

Базата данни почти винаги е първата стена

Ако трябваше да заложим пари къде растящ SaaS удря първия си истински таван, бихме заложили на базата данни всеки път. Тя е единствената част от системата, където малките ранни решения се натрупват най-силно. Заявка без индекс се изпълнява за миг върху хиляда реда и забива върху милион. Кодът не се е променил. Данните се промениха — а данните само растат.

Добрата новина е, че базата данни е и мястото, където живеят най-евтините поправки с най-голямо въздействие. Класическата е липсващият индекс: един-единствен ред, който превръща многосекундна заявка в мигновена, защото базата спира да сканира всеки ред, за да намери малцината, които ѝ трябват. Точно зад него е проблемът N+1 заявки — страница, която, вместо да зададе един въпрос, тихо задава на базата същия малък въпрос стотици пъти в цикъл. И двете са чести, и двете са невидими, докато не погледнете, и двете обикновено са поправка за един ден, щом веднъж сте ги намерили.

Тук има последователност, на която да се облегнете, и си струва да я следвате по ред, вместо да скачате към края. Поправете първо заявките — индекси, N+1, бавната справка. После добавете кеширане за данните, които се четат постоянно, но се променят рядко. Едва след това има смисъл да говорим за реплики за четене, по-големи инстанции или разделяне на данни. Повечето SaaS продукти никога не достигат по-късните стъпки. Те просто се нуждаеха първите да бъдат направени както трябва.

Да мащабираш продукта означава да мащабираш как го променяш

Ето промяната, която изненадва основателите: отвъд определена точка мащабирането спира да е за това продуктът да поема повече потребители и започва да е за това вашият екип да поема повече промяна. Когато бяхте вие и един разработчик, всеки държеше цялата система в главата си. Можехте да промените всичко, защото знаехте какво ще засегне. При пет или десет души този мисловен модел се разпада — и кодът, който предполагаше, че всеки знае всичко, се превръща в пасив.

Това е истинската причина внедряванията да стават плашещи. Не е, че кодът се е влошил за една нощ; а че никой вече не може напълно да предвиди радиуса на поражение от една промяна. Поправката не е героизъм или замразяване на пускането. Тя е инвестиция в неблестящото скеле, което позволява на по-голям екип да се движи, без да си стъпват един на друг: автоматизиран набор от тестове, който улавя очевидните счупвания, внедрявания, които са рутинни, а не церемониални, и начин да изключите лошо издание за секунди, вместо да тичате паникьосани.

• Набор от тестове, покриващ шепата потоци, които биха били катастрофални, ако се счупят — вход, плащане, основно действие. Не всичко; критичните малцина.
• Внедрявания, които вървят с бутон, а не с ритуал, така че пускането на малко и често да стане безопасно вместо изнервящо.
• Бърз начин за връщане назад, така че лошо издание да е петминутно събитие, а не цяла нощ инцидент.
• Флагове за функции, за да можете да пуснете код първо на неколцина клиенти и да го изключите мигновено, ако се държи зле.
• Достатъчно документация, за да не може отпуската на един човек да замрази цяла област от продукта.

Нищо от това не се вижда в демонстрация. Нищо от него не добавя пряко функция. И точно това е работата, която отличава продукт, който продължава да ускорява, от такъв, който се забавя с всяко ново назначаване. Екипите, които мащабират добре, са онези, които третират способността си да променят продукта безопасно като функция сама по себе си — защото при мащаб точно това е тя.

Кратка история от точката на пропукване

За да направим това конкретно, ето композиция, извлечена от работа, която сме вършили — детайлите размити, формата вярна на живота. Малък SaaS за управление на изнесени сервизни екипи беше стартирал добре и беше пораснал до няколкостотин платещи компании. Основателите бяха възхитени и изтощени в равна степен. После най-големият им клиент някога подписа: фирма с повече потребители и повече исторически данни от предишните им десет клиента, взети заедно.

За седмица таблото, в което всички живееха, се беше забавило до пълзене за този клиент — и, странно, за всички останали също. Заявките към поддръжката скочиха. Основателите предположиха, че им трябва далеч по-голям сървър, и се готвеха за болезнено, скъпо преархитектуриране. Точно в този момент ни повикаха, а инстинктът беше разбираем, но грешен.

Не докоснахме архитектурата. Включихме логване на бавни заявки и наблюдавахме един следобед. Виновникът беше почти смущаващо малък: основното табло зареждаше списъка със задачи на всеки потребител с класически модел N+1, изстрелвайки една заявка на задача. За малък клиент това означаваше няколко дузини безобидни заявки. За новия гигант това означаваше хиляди на зареждане на страница — което, върху споделена инфраструктура, влачеше цялата система надолу за всички.

Урокът, който основателите си извадиха, не беше технически. А че ужасяващият проблем с мащабирането, който си бяха представили — онзи, който изискваше преизграждане и набиране на средства — се оказа, измерен, двудневна поправка, скрита зад плашещ симптом. Бяха на път да прекарат месеци в решаване на грешния проблем. Тази пропаст, между въображаемата криза и измерената, е мястото, където се пилеят повечето пари за мащабиране.

Кога наистина е време да преизградите част

Цялата тази предпазливост относно преждевременното мащабиране може да се чете като никога не рефакторирай, никога не преизграждай. Не е това. Понякога част от продукта наистина е стигнала края на живота си и кърпенето ѝ отново е скъпият избор. Хитростта е да различите истинско структурно ограничение от обикновени болки на растежа, които измерена поправка би се справила с тях.

Честният сигнал е този: преизградете компонент, когато цената на промяната му постоянно е станала по-висока от цената на замяната му. Не когато е грозен — грозен код, който е стабилен и рядко докосван, е наред. Търсите част от системата, където всяка промяна е бавна и рискована, където същите бъгове продължават да се връщат, където новите разработчици не могат безопасно да работят и където вече сте опитали по-евтините поправки и сте ударили на стена. Когато няколко от тези са верни наведнъж, фокусирано пренаписване на точно тази една част е правилният ход.

И когато преизграждате, преизградете част — не продукта. Пълното пренаписване от нулата е сирената на мащабирането, нещото, което изглежда чисто и накрая потапя цяла година, докато конкурентите пускат. Заменете единствения изгнил компонент, зад ясна граница, докато останалата част от продукта продължава да работи и да печели. Хирургично, не героично.

Често задавани въпроси