Стартап після MVP: коли інфраструктура гальмує бізнес

У продукту вже є платні клієнти. Маркетинг готує нову кампанію, розробники планують функції на наступний квартал. А застосунок досі працює на сервері, який налаштували перед першим запуском. Релізи вручну проводить одна людина, і ніхто не пам'ятає, коли востаннє перевіряли відновлення даних.

На старті все це могло бути правильним вибором. Проблема починається пізніше: коли тимчасові рішення затримують оновлення, заважають клієнтам або змушують команду регулярно гасити пожежі. Момент для змін визначає не кількість серверів чи користувачів, а ціна технічних обмежень для бізнесу.

Чому одного сервера вистачає для MVP

Для перевірки продуктової гіпотези складна інфраструктура зазвичай не потрібна. Якщо невелика команда ще з'ясовує, чи потрібен ринку її продукт, раціональніше запустити робочу версію, отримати відгуки й перевірити попит, ніж заздалегідь будувати систему під мільйон користувачів.

Одна віртуальна машина, монолітний застосунок, одна база даних і просте розгортання можуть бути цілком достатніми. Ручні операції на старті теж не катастрофа, якщо вони зрозумілі, контрольовані та не загрожують даним. Kubernetes, кілька регіонів і десятки мікросервісів додають не лише можливості, а й витрати на налаштування, підтримку та пошук несправностей.

Один сервер не стає поганим рішенням автоматично після першої сотні клієнтів. Він може залишатися доречним роками, доки команда контролює ризики й виконує вимоги продукту.

Як помітити, що продукт переріс інфраструктуру

Поки сервер справляється з роботою, причин перебудовувати все може й не бути. Але якщо через навантаження затримуються платежі, реєстрації або випуск оновлень, інфраструктура вже впливає на бізнес. Важлива не кількість користувачів сама по собі, а те, скільки операцій вони виконують і яких ресурсів ті потребують.

Зростає не лише трафік

Умовний сервіс виростає з 50 до 5 000 користувачів. Додаються CRM, документи, фонові завдання, платежі. Застосунок і база на одній VM конкурують за CPU, пам'ять і диск. Проте 5 000 читачів сторінки та 5 000 одночасних транзакцій у SaaS — різні навантаження.

Сервер відповідає, головна сторінка відкривається. Здавалося б, усе гаразд. Але реєстрація нового користувача зависає, бо фонове завдання не завершилося вчасно. Перевірка лише доступності головної сторінки такої проблеми не покаже.

Що виміряти до будь-якої міграції

Почніть із трьох найважливіших операцій продукту. Для кожної перевірте час виконання, частку помилок і залежність від інших компонентів. Показник p95 означає час, у межах якого завершується 95% виміряних запитів. Його корисно порівнювати у звичайні години та під час піків, разом із HTTP 5xx, CPU, RAM і дисковим I/O.

Швидка діагностика:

• Повільна реєстрація: подивіться p95, повільні SQL-запити та тривалість фонових операцій.
• Затримки інтеграцій: перевірте черги, кількість повторних спроб і помилки зовнішнього API.
• Падіння під навантаженням: шукайте записи OOM, вичерпані ліміти з'єднань та затримки диска.
• Помилки після релізу: зіставте час інциденту зі змінами коду й налаштувань.

Показники мають допомогти відрізнити нестачу ресурсів від помилки застосунку.

Сім тимчасових рішень, які створюють ризики

Найнеприємніші проблеми часто ховаються в рішеннях, до яких команда давно звикла. Один сервер, один адміністратор, неперевірена резервна копія. Поки все працює, їх майже не помічають. Після збою з'ясовується, що відновлення залежить від людини, яка сьогодні не на зв'язку.

Cron і моноліт не є помилками самі по собі. Ризик виникає, коли невдале завдання ніхто не помічає або не може безпечно повторити, особливо під час платежів.

Почніть із наслідків відмови

Спочатку оцініть ризик втрати даних і зупинки ключових операцій, далі — релізи й ручну роботу. Якщо збій конкретної інтеграції паралізує бізнес, пріоритети змінюються.

«Копії є, але відновлюватися з них ще не пробували» — поганий результат перевірки. RPO визначає максимально допустимий період втрати даних, RTO — цільовий максимальний час, за який потрібно відновити роботу системи. Snapshot, реплікація та резервна копія вирішують різні завдання. Наявність будь-якого з цих механізмів сама по собі не означає, що відновлення перевірене.

Команда боїться оновлень: як технічний борг гальмує бізнес

«Цю бібліотеку краще поки не чіпати». «Сервер налаштовував попередній розробник». «Оновлення PHP відкладемо, бо незрозуміло, що зламається». Такі фрази не доводять, що команда працює погано. Вони підказують, де накопичилися незадокументовані залежності й бракує безпечного способу перевірити зміни.

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

Якщо для звичайного оновлення потрібно телефонувати людині, яка давно залишила проєкт, проблема вже не в конкретній бібліотеці. Перевірте, чи може інший розробник із належними доступами розгорнути застосунок у тестовому середовищі, виконати невелику зміну та відкотити її. Запишіть, скільки це зайняло часу, які дії довелося виконати вручну й чого бракувало в інструкції.

Git, документація конфігурації та порядок роботи із секретами допоможуть зробити реліз відтворюваним без участі одного фахівця.

Як інфраструктурні обмеження забирають гроші

У рахунку за сервер немає рядка «втрачені продажі». Там також не видно годин, які розробники витратили на виправлення чергового збою. Проте для бізнесу це реальні витрати: технічні обмеження стають фінансовою проблемою, коли зупиняють критичні операції або забирають час команди в розвитку продукту.

Сервер доступний, а завершити оплату неможливо

Під час маркетингової кампанії сервіс може відкриватися без проблем, проте повільно реєструвати нових клієнтів чи повертати помилку під час платежу. Моніторинг показує, що сервер доступний, хоча клієнт не може завершити оплату. Навіть HTTP 200 у відповіді головної сторінки ще не означає, що замовлення пройшло.

Зіставляйте HTTP 5xx і затримки API з успішними платежами та реєстраціями. Падіння конверсії ще не доводить провину сервера, але збіг із журналами помилок дає підставу для перевірки.

Скільки коштує ручне виправлення

Умовний приклад: після кожного релізу двоє розробників витрачають сумарно шість годин на ручні перевірки та виправлення. Якщо таких релізів чотири на місяць, це 24 людино-години. Помноживши їх на внутрішню вартість години, компанія отримає орієнтир для порівняння із затратами на автоматизацію. Це не реальний кейс і не гарантія, що автоматизація усуне всі витрати.

Фіксуйте дату, тривалість, постраждалу операцію й робочий час. Потенційно втрачені замовлення позначайте як оцінку, а не доведений збиток.

Чому після MVP не обов'язково потрібні мікросервіси

Проблему одного перевантаженого процесу не обов'язково вирішувати переходом на Kubernetes. Невеликій команді частіше потрібні передбачувані релізи, окреме тестове середовище й нагляд за критичними операціями. Складніша архітектура збільшує кількість компонентів, які теж доведеться обслуговувати.

Що можна змінити без перебудови продукту

Почати можна з конкретних речей: відокремити production від staging, описати розгортання та відкат, налаштувати сповіщення про збої платежів і фонових завдань. Далі автоматизувати повторювані кроки через простий сценарій CI/CD, наприклад у GitHub Actions або GitLab CI. Не потрібно впроваджувати великий набір інструментів лише тому, що так роблять інші.

Додавання вузлів може створити нові проблеми, якщо сесії прив'язані до одного сервера, файли локальні, а завдання не захищені від дублювання.

Коли розподілена архітектура має сенс

Вертикальне масштабування збільшує ресурси одного сервера; горизонтальне додає екземпляри застосунку та розподіляє між ними навантаження. Другий підхід доречний, коли одного вузла недостатньо або бізнес потребує стійкості до його відмови. Перед переходом треба перевірити спільне зберігання стану, сесії, файлові дані, повторні запити та залежності від бази.

Мікросервіси й Kubernetes корисні, коли різним командам потрібно незалежно розвивати складний продукт. Для локальної проблеми така перебудова часто зайва.

Коли додавати ресурси, а коли змінювати архітектуру

Збільшення CPU або RAM допомагає, коли саме їх нестача підтверджена вимірюваннями. Якщо ж причина у повільному SQL-запиті, блокуванні або некоректній роботі черги, новий сервер лише відкладе проблему. «Перш ніж додавати ядра, подивімося, що саме навантажує сервер» — цілком практичне правило.

Спочатку визначити вузьке місце

Якщо база даних постійно вичерпує оперативну пам'ять, збільшення RAM може допомогти з кешуванням. Коли навантаження впирається в процесор і програма здатна використовувати додаткові ядра, має сенс розглянути більше CPU. У разі затримок диска слід перевірити характер операцій читання й запису, а не орієнтуватися лише на назву накопичувача.

Іноді достатньо середовища, ресурси якого можна змінювати за потреби. Один із варіантів — хмарний VDS для проєктів, що ростуть. Перед вибором слід перевірити доступні конфігурації, умови зміни ресурсів і можливий простій. Зміна розміру VM не усуває помилок коду й не створює автоматично відмовостійку систему.

Що перевірити перед зміною тарифу

Адміністратор може подивитися top, free, vmstat та iostat, а розробник — журнал повільних запитів і план виконання SQL через EXPLAIN. Мета не в тому, щоб зібрати якомога більше показників, а щоб знайти обмеження, яке справді впливає на операцію клієнта.

Умовний сценарій: реєстрація гальмує, вимірювання вказують на SQL-запит, а EXPLAIN виявляє зайве сканування таблиці. Команда оптимізує запит і повторює тест навантаження. Якщо затримка зменшилася, додаткові ресурси для цього симптому не потрібні.

Коли інвестиції в інфраструктуру окупаються

Питання не в кількості користувачів, а в тому, скільки бізнес витрачає на підтримку тимчасових рішень і чим ризикує, якщо нічого не змінить. Для одного сервісу короткий простій майже непомітний. Для іншого він зупиняє оплату, активацію послуг чи доступ до робочих даних.

Порівняти витрати на зміни й ціну бездіяльності

За один і той самий період оцініть підтверджені збитки від інцидентів, робочий час на ручні операції та обґрунтовані втрати через затримки релізів. Окремо врахуйте ймовірність повторення критичного збою. Порівняйте суму з витратами на впровадження й подальшу підтримку покращення. Не рахуйте одне й те саме двічі: наприклад, робочий час інженера не варто повторно включати до вже підрахованої повної вартості інциденту.

Оцінка не буде абсолютно точною, але дозволить порівняти витрати на виправлення з ризиком повторних збоїв. Якщо потенційна втрата даних неприйнятна, чекати, доки її вартість стане статистично очевидною, теж не потрібно.

Сім запитань для засновника

1. Відмова якого компонента зупинить продукт або критичну операцію?
2. Чи зможе інший розробник розгорнути систему за документацією без допомоги конкретної людини?
3. Коли команда востаннє успішно відновлювала дані з резервної копії?
4. Чи можна перевірити реліз у staging та відпрацювати повернення попередньої версії до запуску на production?
5. Чи зрозуміло, за які інфраструктурні ресурси компанія платить найбільше?
6. Чи можна збільшити ресурси без повної міграції та який простій для цього потрібен?
7. Чи є компоненти, які команда не наважується оновлювати через невідомі залежності?

Кілька невпевнених відповідей — привід для аудиту. Для кожного ризику визначте відповідального, мінімальне покращення та критерій успіху.

Тимчасові рішення не є помилкою стартапу. Помилка — не помітити, коли продукт уже виріс із них. Інфраструктура має змінюватися не за модою й не заради абстрактного майбутнього навантаження, а тоді, коли її обмеження впливають на клієнтів, роботу команди та фінансовий результат.