Двухчасовой технический аудит: что стартапы быстро узнают

Почему встречи не замечают то, что видит аудит

Обычно встречи держатся на памяти, статусах и на том, что кажется срочным именно сегодня. Это звучит разумно, но многое скрывает. Люди рассказывают о прогрессе общими словами, пропускают неудобные детали и часто предполагают, что за шероховатости отвечает кто-то другой.

Стартап может выйти с планерки, полностью согласовав цели, а к пятнице снова упереться в те же блокеры. Команда говорит: «мы уже близко», — хотя один нестабильный тест, один неописанный шаг деплоя или один сервис без владельца продолжает тормозить всех. Встречи сглаживают такие мелочи, потому что у людей нет ни времени, ни доказательств, чтобы сразу их зафиксировать.

Двухчасовой технический аудит меняет оптику. Вместо вопроса «что, по вашему мнению, происходит?» он проверяет, что команда реально делает каждый день. Смотрят на шаги релиза, последние pull request, цепочку ошибок, backlog и места, где работа буксует.

Это важно, потому что настоящая работа оставляет следы. Если релиз зависит от того, бодрствует ли один инженер, это видно. Если одна и та же ошибка возвращается каждый месяц, история это покажет. Если у сервиса нет четкого владельца, пробелы быстро становятся заметны, стоит только задать простой вопрос: «Кто чинит это, когда оно ломается?»

Поэтому короткие аудиты часто кажутся немного некомфортными. Они срезают вежливый слой, который создают встречи. На созвоне команда может звучать согласованно, но кодовая база, заметки о деплоях и привычки дежурств могут рассказывать совсем другую историю.

Олег Сотников работал инженером, CTO и основателем, и такой опыт здесь особенно полезен. Люди, которые сами выпускали продукт, управляли инфраструктурой и переживали давление релизов, обычно быстрее замечают мелкие сигналы. Они знают, что отсутствие владельца или ручной шаг деплоя выглядит мелочью ровно до недели релиза.

Встречи все еще нужны. Они помогают принимать решения. Аудит помогает увидеть, вокруг чего эти решения уже принимались.

Что именно проверяет короткий аудит

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

Первое, что нужно проверить, — это ответственность. Кто решает, безопасно ли сливать изменение? Кто выкатывает релиз? Кто чинит продакшен, если что-то ломается в 11 вечера? Если ответы меняются в зависимости от того, кого спросить, у команды есть реальный пробел.

Обычно он проявляется в мелочах. Pull request висят открытыми, потому что никто не чувствует себя ответственным. В прод падает баг, и исправление начинается со Slack-ветки с вопросом, кто знает этот кусок системы. Стартапы чувствуют это как задержки, стресс и переделки задолго до того, как называют это проблемой ответственности.

Аудит также смотрит, как команда выпускает изменения. Нужно увидеть реальный путь от кода до продакшена. Хороший процесс обычно скучный: понятные ревью, повторяемые шаги деплоя и план отката, которым уже пользовались раньше.

Слабый процесс оставляет такие следы:

• релизы зависят от того, онлайн ли один человек
• шаги деплоя живут у кого-то в голове
• срочные исправления проходят без ревью и без следа
• команда узнает о сбоях первой от клиентов
• откат означает «просто быстро поправим на живом сервере»

Логи, алерты и недавние инциденты показывают ту же историю под другим углом. Если алертов слишком много и они шумные, на них перестают реагировать. Если логов нет, никто не может отследить, что сломалось. Если последние три инцидента закончились быстрым патчем без разбора, тот же сбой вернется снова.

Стек тоже просматривают бегло. Смысл не в том, чтобы пристыдить команду за «не тот» инструмент. Смысл в том, чтобы увидеть дорогие привычки: слишком много сервисов для маленького продукта, избыточная инфраструктура, слабые настройки по умолчанию или самописные куски, которые каждую неделю добавляют работы. Один стартап может держать пять баз данных там, где хватило бы одной. Другой может платить за сложные инструменты деплоя, хотя более простая схема выкатывала бы продукт не менее безопасно.

Короткий аудит работает потому, что с доказательствами спорить трудно. История коммитов, таймлайн инцидентов, настройки алертов и ежемесячные счета обычно показывают картину прямо перед глазами.

Отсутствие владельцев видно быстро

Одно из первых, что выявляет двухчасовой технический аудит, — это простая вещь: у некоторых самых болезненных частей продукта нет понятного владельца. Сервис работает в продакшене, клиенты на него завязаны, и все же никто не может ответить на базовые вопросы без того, чтобы не втянуть в обсуждение трех человек из чата.

Поначалу это может не выглядеть хаотично. Общий ящик для писем кажется безопасным. Общий чат кажется живым. Люди отвечают, помогают друг другу и двигают дела вперед.

Но общая ответственность часто означает размытая ответственность. Когда нужен апрув на релиз, команда ждет. Когда алерт срабатывает в 2 часа ночи, все думают, что его уже увидел кто-то другой. Когда инцидент заканчивается, задачи по итогам висят под тегами вроде «backend» или «platform», пока тихо не умирают.

Пробел можно быстро заметить с помощью нескольких прямых вопросов:

• Кто принимает финальное решение по рискованному релизу?
• Кто решает, откатываться или чинить на живом проде?
• Кто читает алерты и закрывает их?
• Кто отвечает за исправления после сбоя?
• Кто следит за расходами на облако по этому сервису?

Если ответы звучат как «мы все», «в основном Сэм» или «зависит от ситуации», настоящего владельца нет. Если два человека вроде бы отвечают за систему, значит, по сути, не отвечает никто.

Простая карта владельцев обычно сразу делает проблему очевидной. В один столбец выпишите каждый сервис, процесс или вендора. В следующий — одно имя рядом с каждым пунктом. Не название команды. Не чат. Один человек.

Небольшой пример из стартапа хорошо это показывает. Приложение падает во время оформления заказа после пятничного деплоя. Инженеры говорят, что у платежного провайдера что-то изменилось. Продукт говорит, что релиз не должен был выходить. Операции говорят, что им никто не поручал следить за всплесками ошибок. К понедельнику у пяти человек есть мнения, но ни у кого нет четкой власти над платежным потоком или решением по релизу.

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

Исправить это несложно, но дискомфорт тут все же нужен. Дайте каждому сервису и каждому процессу одного владельца с финальным словом. Начните с релизов, инцидентов и всего, что связано с выручкой. Пустые места на этой карте и показывают, где живет настоящий риск.

Хрупкие релизы оставляют понятные следы

Проблемы с релизами редко остаются скрытыми. Они видны в логах деплоя, в ночных сообщениях в чате и в комментариях вроде «подождите Алекса, только он знает порядок релиза».

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

Ручные шаги наносят больше всего вреда. Каждая лишняя команда — это еще один шанс взять не ту ветку, пропустить миграцию или забыть изменить конфиг. Команды обычно называют такие ошибки «мелкими», но при релизе под давлением они очень быстро накапливаются.

История последних деплоев обычно рассказывает все сама:

• в заметках к релизу упоминаются ручные правки на сервере
• одни и те же hotfix приходят снова и снова
• перед срочным деплоем тесты пропускают
• нет письменного шага отката
• один инженер отвечает за каждый выкат в прод

Hotfix сам по себе не проблема. Стартапам иногда нужны срочные исправления. Проблема начинается тогда, когда команда может быстро выкатить изменение, но не может так же быстро его откатить. Если релиз идет плохо и у команды нет плана отката, стресс резко растет, и люди принимают еще худшие решения.

Дедлайны это усугубляют. Когда дата запуска уже близко, команды часто в первую очередь режут проверки. Они пропускают прогон тестов, ревью коллеги или деплой на staging, потому что «изменение совсем маленькое». Маленькие изменения тоже ломают продакшен.

Секретные знания о релизе — еще один явный сигнал тревоги. Если один человек знает порядок команд, место спрятанного конфига или тот самый сервер, который всегда надо перезапускать вручную, процесс релиза слабый. У стартапа нет процесса как такового. Им владеет один сотрудник.

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

Дорогие архитектурные привычки скрываются у всех на виду

Молодой продукт может нести расходы уровня enterprise задолго до того, как у него появится enterprise-трафик. Обычно это происходит по чуть-чуть: еще один управляемый сервис, еще одна очередь, еще одна база данных, еще один инструмент мониторинга. Каждое решение по отдельности кажется разумным. Вместе они превращают простой продукт в дорогой стек.

Двухчасовой технический аудит часто быстро замечает это, потому что задает прямой вопрос: какую проблему каждая часть решает именно сегодня? Если команда не может ответить в одном предложении, этот компонент, возможно, лишний.

Где расходы растут быстрее всего

Одна из типичных проблем — дублирование. Стартап может платить за один инструмент для логов ошибок, другой для uptime и третий для сбора метрик приложения, хотя два из них уже покрывают почти одну и ту же работу. Счет растет, а команда все равно пропускает инциденты, потому что никто не знает, какой дашборд считать надежным.

Другая проблема — размер. Команды иногда копируют схему, которую видели в крупной компании: несколько кластеров, отдельные брокеры сообщений, выделенные слои кеша и сложные правила failover. Для миллионов пользователей это может иметь смысл. Для продукта с несколькими тысячами сессий в месяц и маленькой инженерной командой это выглядит странно.

Самописные системы — еще одна тихая статья расходов. Основатели иногда утверждают домашний инструмент деплоя, внутреннюю админ-панель или особый слой авторизации, потому что это кажется контролем. Потом команда неделями поддерживает все это, чинит крайние случаи и обучает каждого нового сотрудника, как оно устроено. Бюджетный стандартный инструмент часто стоил бы меньше и ломался бы реже.

Быстрый обзор обычно находит лишнее в таких местах:

• два платных инструмента делают почти одну и ту же работу
• инфраструктура рассчитана на трафик, которого пока нет
• самописный код заменяет стабильные стандартные инструменты
• сервисы никто не хочет удалять, потому что у них нет владельца

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

Как провести аудит за два часа

Хороший двухчасовой технический аудит держится в узких рамках. Вы не оцениваете компанию целиком. Вы смотрите, как команда прямо сейчас выпускает софт, опираясь на свежие факты, а не на мнения из очередной встречи.

Начните с данных за последние несколько недель. Возьмите недавние инциденты, заметки о релизах и простой список инструментов, с которыми команда работает в разработке, тестировании, деплое и мониторинге. Старые документы помогают редко. Свежие примеры — да.

Удобный план работы выглядит так:

• 0–20 минут: собрать последние инциденты, заметки о деплоях и текущий стек инструментов
• 20–50 минут: спросить, кто отвечает за каждый сервис, репозиторий, алерт и шаг согласования
• 50–90 минут: проследить один реальный релиз от изменения в коде до продакшена
• 90–120 минут: разложить выводы по риску, стоимости и срочности

Пробелы в ответственности обычно всплывают быстро. Спрашивайте прямо: кто утверждает этот релиз, кто чинит этот сервис ночью, кто обновляет эту зависимость, кто может безопасно откатить изменение? Если ответ звучит как «все», на деле обычно не отвечает никто.

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

Именно этот шаг часто выявляет реальные проблемы процесса релиза. Команда может говорить, что деплой — дело обычное, но по следам видно три согласования в Slack, один ручной шаг в базе данных и senior-инженера, который должен оставаться онлайн на всякий случай. Это не обычный релиз. Это хрупкий.

Следите за медленными передачами задач. Ручное копирование секретов, написанные от руки заметки о релизе, ожидание, пока один человек нажмет кнопку, и «племенные знания» о продакшене — все это дорогие привычки. Часть из них стоит денег напрямую. Другие отнимают время каждую неделю.

Финальные заметки лучше оформить в маленькую таблицу или короткий список. В каждом пункте должно быть указано, что не так, почему это важно и как скоро команде нужно действовать. Пишите простыми словами. «Нет владельца у billing alerts» лучше, чем длинный абзац.

Люди вроде Олега Сотникова часто проводят такой разбор, быстро отсекая догадки. Полезный результат — не толстый отчет. Полезный результат — короткий список проблем, которые команда может исправить уже на следующей неделе.

Простой пример из стартапа

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

В команде пять человек. Трое пишут код, один занимается дизайном, и один основатель ведет продажи и поддержку. На бумаге все выглядит нормально. На практике один инженер отвечает за каждый релиз, лучше всех знает продакшен-сервер и держит шаги деплоя в голове.

Это не кажется опасным, пока не задаешь один простой вопрос: что будет, если он спит, болеет или не в сети, когда на запуске что-то пойдет не так? Четкого ответа нет. У стартапа проблема не в сломанном скрипте деплоя. У него проблема процесса релиза, потому что ответственность сосредоточена на одном человеке.

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

Потом проверка затрат показывает типичную для молодых команд вещь: они держат две базы данных, хотя хватило бы одной. Одну добавили во время раннего эксперимента. Вторая осталась, потому что у команды не дошли руки ее убрать. Теперь они платят за обе, резервируют обе и разбираются со странным потоком данных между ними.

С собой они уносят не огромный отчет, а короткий список правок на следующую неделю:

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

Вот почему двухчасовой технический аудит часто лучше, чем еще одна встреча. Он превращает расплывчатое беспокойство в небольшой набор конкретных исправлений, которые команда успеет сделать до запуска.

Ошибки, из-за которых аудит бесполезен

Короткий аудит проваливается, если люди используют его, чтобы защищать решения, а не показывать, как работа реально устроена. Атмосфера очень важна. Если проверка превращается в поиск виноватых, инженеры замолкают, основатели напрягаются, и самые полезные детали остаются скрытыми.

Люди должны говорить: «Эта часть ломается, когда Сэм в отпуске» или «Мы все еще выкатываем это вручную по пятницам». Такая честность быстро находит риск. Страх его убивает.

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

Именно там живет риск. Не в презентации.

Команды также портят аудит, превращая его в огромный список недостатков. Пятьдесят находок выглядят серьезно, но редко помогают. Большинству стартапов нужен короткий список, с которым можно работать уже в этом месяце. Три ясные правки лучше длинного backlog, который больше никто не открывает.

Стоимость игнорируют по той же причине. «Все работает» звучит хорошо, пока счет продолжает расти. Если стартап платит за инструменты, облачную мощность и сервисы, которыми почти не пользуется, аудит должен сказать об этом прямо. Еще один квартал ожидания может закрепить привычки, от которых потом трудно отказаться.

Небольшой пример: стартап с восемью инженерами работает нормально изо дня в день, но все еще держит отдельные инструменты для staging, дублирующий мониторинг и слишком большие серверы, оставшиеся с более загруженного периода. Ничего не горит. И все же компания может тратить тысячи долларов в месяц впустую.

Последняя ошибка самая простая. Люди заканчивают проверку, кивают на выводы и уходят без владельцев и сроков. Потом ничего не меняется.

У каждой проблемы должны быть имя и срок, подходящий команде. Если следующий шаг ни за кем не закреплен, аудит превращается в вежливую встречу с более хорошими заметками.

Короткий чеклист после проверки

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

• Назначьте владельца каждому важному сервису. Если никто не может сказать, кто отвечает за billing API, worker очереди или скрипт деплоя, этот пробел всплывет во время сбоя.
• Попросите одного инженера по памяти объяснить обычный релиз. Если он пропускает шаги, опирается на заметки в старых чатах или ему нужен один senior, чтобы подтвердить порядок, процесс слабее, чем кажется.
• Проверьте откат простыми словами. Кто может отменить плохой деплой, сколько это займет и что при этом происходит с пользователями? «Наверное, сможем откатить» — это не ответ.
• Откройте последний инцидент. Кто-то должен уметь показать, что сломалось, как команда это починила и что изменилось после. Если в записи только несколько сообщений и смутное воспоминание, проблема может вернуться.
• Посмотрите на текущий стек инструментов и спросите, что можно убрать. Многие стартапы продолжают платить за лишний мониторинг, CI-дополнения или старые хостинг-компоненты еще долго после того, как нужда в них исчезла.

Этот тест работает, потому что превращает расплывчатую уверенность в ответы «да» или «нет». Команды часто говорят, что с релизами все нормально, ответственность понятна, а расходы под контролем. Потом короткая проверка показывает, что один инженер знает деплой, никто не отвечает за два внутренних сервиса, откат занимает 40 минут, а три платных инструмента дублируют друг друга.

Если больше чем на два вопроса ответы звучат неуверенно, исправьте сначала их. Ясные владельцы, записанные шаги релиза, проверенный откат, простой журнал инцидента и один ненужный инструмент меньше обычно помогают сильнее, чем еще одна планерка.

Что делать дальше

Не пытайтесь исправить все сразу. Короткий аудит обычно находит больше проблем, чем маленькая команда может закрыть за один спринт, и это нормально. Начните с тех изменений, которые сразу снижают риск.

Чаще всего это значит исправить шаги релиза, которые могут сломать продакшен, назначить владельца коду, у которого по сути нет хозяина, и убрать очевидные лишние расходы еще до того, как трогать более глубокую архитектуру. Если один баг может заблокировать деплой, или один сервис сжигает деньги без понятной причины, займитесь этим первым.

Простой план продолжения работает лучше, чем большой проект по уборке:

• Выберите 3 главные проблемы, которые могут вызвать сбой, задержку или лишние расходы.
• Дайте каждой проблеме одного владельца, а не группу.
• Поставьте срок, который укладывается в обычную работу, обычно это дни или пара недель.
• До начала работы запишите, что значит «готово».

Один владелец важнее, чем многие команды ожидают. Когда за задачу отвечают трое, никто не чувствует ее полной тяжести. Когда пунктом владеет один инженер, продуктовый лидер или основатель, решения принимаются быстрее, а хвостов становится меньше.

Проводите такую же проверку снова после крупных изменений в продукте. Новый billing flow, спешно сделанная enterprise-фича, переезд на другую облачную схему или рост команды — все это может создать новые слабые места. Первый аудит дает базовую точку отсчета. Второй показывает, устранила ли команда причины или только подлатала симптомы.

Если одни и те же проблемы возвращаются, позовите кого-то со стороны. Команды часто ходят по кругу вокруг одних и тех же ошибок в релизах или архитектуре, потому что создавали их вместе и никто не хочет спорить с прежними решениями. Внешний CTO advisor может быстро увидеть закономерности и спокойно назвать их, не превращая работу в долгий проект.

Олег Сотников может помочь основателям разобрать релизы, архитектуру и ответственность именно в таком практичном формате. Его опыт Fractional CTO и startup advisor полезен командам, которым нужен ясный следующий шаг, а не еще месяц встреч. Цель двухчасового технического аудита простая: снизить риск, назначить владельцев и проверить все еще раз после изменений в продукте.