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