Аудит архітектури — це не думка про ваш стек. Це карта того, де система ламається під планом, який ви справді маєте.
Огляди архітектури мають погану славу, бо багато з них — вправи на смак: консультант пояснює, що обрав би інакше. Корисний аудит відповідає на вужче і значно цінніше питання: з огляду на те, де цей бізнес хоче бути за вісімнадцять місяців, що зламається, коли і скільки коштує це виправити?
Сигнали, що він потрібен зараз
- Продуктивність помітно падає зі зростанням використання, і ніхто не може точно сказати чому
- Витрати на інфраструктуру зростають швидше за виручку
- Один компонент падає і тягне за собою непов'язані функції
- Випуск маленької фічі вимагає правок у багатьох частинах системи
- Ви от-от збільшите трафік у десять разів — запуск, партнерство, раунд
- Інвестор запитав, чи масштабується архітектура, і чесна відповідь — ніхто не знає
Що досліджує аудит
Шар даних — перший і найважчий
У більшості систем справжньою стелею є база даних, і це найдорожче для зміни згодом. Що важливо: розділення читання й запису, індексація під реальні патерни запитів, необмежені запити, що ростуть разом із таблицею, чи є єдиний master на запис межею, і чи може схема еволюціонувати без простою.
Ізоляція відмов
- Що стається, коли стороння залежність повільна, а не мертва — таймаути і circuit breaker чи каскадне вичерпання потоків
- Чи може один орендар або один важкий клієнт погіршити сервіс для всіх
- Чи можуть фонові задачі задушити шлях запитів
Швидкість змін
Архітектура — це не лише про навантаження. Система, яку не можна безпечно змінювати, не справляється зі своєю роботою, навіть якщо ніколи не падає. Ми шукаємо зв'язаність, що змушує правити кілька модулів, відсутність швів для тестування і спільний стан, який унеможливлює локальні міркування.
Відповідність розміру команди
Який вигляд має мати результат
| Поганий результат аудиту | Корисний результат |
|---|---|
| «Розгляньте мікросервіси» | «Таблиця Orders досягне насичення запису приблизно на 4× поточного обсягу; шардинг за орендарем — це ~3 інженеро-тижні» |
| «Покриття тестами низьке» | «Звірка платежів не має тестів; регресія тут беззвучна і фінансова» |
| «Технічний борг значний» | «Три пункти блокують роадмап Q4; решта може зачекати, і ось чому» |
| 60-сторінковий звіт | Односторінкове резюме, впорядкований перелік і послідовний план |
Сенс аудиту архітектури — перетворити розмиту тривогу щодо масштабування на невелику кількість датованих і оцінених у грошах рішень.
Перевірте конкретну гіпотезу зростання
Діаграма не показує фактичної межі системи. Пов'яжіть зміну використання із залежностями, місткістю та доказами відновлення.
- Простежте критичний запит через сервіси, черги й сховища.
- Визначте спільні точки відмови та неперевірені припущення навантаження.
- Порівняйте обмежені зміни за впливом і вартістю перевірки.
Часті запитання
Скільки триває аудит архітектури системи?
Від тижня до трьох для більшості систем. Робота полягає в читанні коду та інфраструктури, вивченні реальних продакшн-метрик і патернів запитів та розмовах з інженерами. Довші проєкти зазвичай означають, що обсяг зсунувся в бік реалізації.
Ви скажете нам усе перебудувати?
Дуже рідко, і ставтеся скептично до будь-кого, чия типова рекомендація — перебудова. Більшість стель масштабування піднімаються точковими змінами — індекс, черга, кеш, ключ шардингу — а не новою архітектурою.
Чи потрібен аудит архітектури перед раундом?
Варто, якщо інвестори проводитимуть технічний due diligence, що є стандартом починаючи з Series A. Знайти проблеми самому значно дешевше, ніж дозволити іншій стороні знайти їх під час переговорів.
Чи завжди потрібен навантажувальний тест?
Лише за суттєвого відкритого питання місткості й погоджених меж тесту. Наявна телеметрія може відповісти на частину питань; відсутні виміри зафіксуйте.
Хвилюєтеся, що зламається на 10×?
Ми складаємо карту стель, оцінюємо виправлення і вибудовуємо їх у послідовність — зазвичай менш ніж за три тижні.
Читати далі за темою
Технічний борг у стартапі: скільки — це забагато?
Технічний борг є в кожного стартапу, і здебільшого це було правильне рішення. Питання не в тому, як його позбутися, а в тому, які його частини нараховують відсотки, яких ви вже не тягнете.
Технічний аудит MVP: що ми перевіряємо в перші 48 годин
Більшість аудитів MVP закінчуються документом. Корисний закінчується рішеннями: що горить, що може почекати і скільки коштує виправлення.