Ситуация типовая: сервис работает, команда, которая его писала, ушла или стала недоступна, а новому подрядчику надо как-то принять это хозяйство. Момент неприятный, но управляемый, если понимать, что именно проверять и в каком порядке.
Разберем состав приемки: что обязано быть передано, что почти никогда не передается и как оценить, во что обойдется дальнейшая жизнь.
Почему приемка платная
Вопрос возникает первым, поэтому ответим сразу. Приемка — это работа по изучению чужого решения, и она занимает от нескольких дней до двух недель в зависимости от размера.
Подрядчик, который берет сервис на поддержку без приемки, делает одно из двух. Либо закладывает риск неизвестности в ежемесячную цену, и вы платите за него постоянно. Либо начнет разбираться в момент первой аварии, за ваш счет и в условиях простоя.
Платная приемка честнее: вы получаете документ с описанием состояния, перечнем рисков и оценкой работ по приведению в порядок. С этим документом можно идти к любому подрядчику, включая прежнего, и сравнивать предложения по одинаковому объему работ.
Что должно быть передано
| Что | Зачем | Как часто отсутствует |
|---|---|---|
| Исходный код с историей изменений | Основа всего, история помогает понять решения | Код есть, история теряется часто |
| Инструкция по сборке и развертыванию | Без нее выкатить изменение невозможно | Отсутствует почти всегда |
| Описание окружений | Где живет продуктовая среда, где тестовая | Тестовой среды часто нет вовсе |
| Доступы к серверам и панелям | Управление инфраструктурой | Приходят частями, что-то забывают |
| Схема базы данных и миграции | Понимание структуры | Схема есть, документации нет |
| Внешние интеграции и ключи | Платежи, почта, аналитика, учетная система | Ключи оформлены на почту разработчика |
| Домены и сертификаты | Продление и управление | Домен зарегистрирован на подрядчика |
| Настройки почты и рассылок | Письма клиентам перестают уходить незаметно | Забывают регулярно |
Две строки заслуживают отдельного внимания. Домен, зарегистрированный на подрядчика, — это рычаг, о котором вспоминают в момент конфликта. Ключи внешних сервисов на личной почте разработчика перестают работать в момент, когда он меняет пароль или удаляет аккаунт.
Проверка кода: пять вопросов
Глубокий аудит кода стоит дорого и нужен редко. Для решения о поддержке достаточно ответить на пять вопросов.
Собирается ли проект по инструкции. Берем чистую машину, следуем документации, получаем работающее приложение. Если не получается, первым делом восстанавливается воспроизводимая сборка, потому что без нее невозможно ничего.
Есть ли автоматические проверки. Тесты хоть какие-то, линтеры, проверка при сборке. Их отсутствие не приговор, но означает, что каждое изменение придется проверять руками, и это влияет на стоимость сопровождения.
Как давно обновлялись зависимости. Библиотеки трехлетней давности означают известные уязвимости и невозможность обновиться без переработки. Это самая частая строка технического долга.
Есть ли журналирование. Когда что-то ломается, разбор начинается с логов. Сервис без них требует воспроизведения ошибки, а воспроизводится далеко не все.
Что с секретами. Пароли и ключи в коде репозитория — находка, которая случается регулярно. Если код когда-либо был доступен посторонним, все эти секреты подлежат замене.
Проверка инфраструктуры
Вторая половина приемки. Здесь проверяется не то, как написано, а то, как оно живет.
Смотрим: где размещен сервис и на чьих учетных записях, есть ли резервное копирование и когда его проверяли, настроен ли мониторинг доступности, кто получает уведомления, есть ли ограничение доступа к административным частям, до какого числа оплачен хостинг и продлены сертификаты.
Про копии подробно — в отдельной статье, здесь достаточно проверить факт: разворачивалась ли когда-нибудь копия и сколько это заняло.
Отдельный пункт — счета за инфраструктуру. Бывает, что хостинг оплачивается с карты разработчика и продлевается вручную. Такой сервис живет до первого пропущенного платежа, и восстановление после удаления данных провайдером обходится дороже любой приемки.
Разговор с прежней командой
Самый ценный ресурс приемки — время людей, которые это писали. Пара часов разговора экономит недели чтения кода, поэтому стоит попытаться их получить, даже если расставание было прохладным.
Вопросы, которые задают в первую очередь: что здесь устроено нестандартно и почему; какие места вы бы не трогали без крайней необходимости; что регулярно ломается и как это чинится; какие есть ручные процедуры, о которых нет документации; что вы собирались сделать, но не успели.
Последний вопрос особенно полезен: он показывает, что команда сама считала проблемным. Обычно это совпадает с тем, что вылезет в первые месяцы.
Если прежняя команда недоступна, эти же вопросы задают тем, кто пользуется сервисом ежедневно. Пользователи знают, что «по пятницам отчет надо запускать дважды» и «после обновления цен надо зайти и нажать вот сюда». Такие ритуалы — прямые указатели на места, где что-то работает неправильно.
Как оценить технический долг
Технический долг звучит абстрактно, поэтому переводим в понятное: сколько времени и денег потребуется, чтобы привести сервис в состояние, в котором с ним можно спокойно работать.
Разбивается на три уровня срочности. Критичное — то, что может привести к потере данных или простою: отсутствие копий, уязвимые зависимости с известными проблемами, секреты в открытом виде, отсутствие мониторинга. Это делается в первый месяц.
Важное — то, что мешает работать: невоспроизводимая сборка, отсутствие тестовой среды, ручное развертывание, отсутствие журналов. Это план на два-три месяца.
Желательное — то, что улучшает жизнь на горизонте года: обновление устаревших библиотек, рефакторинг самых проблемных мест, автоматические проверки. Делается фоном в рамках подписки.
Такая раскладка дает заказчику понятный выбор: что чиним сейчас, что позже, от чего отказываемся. Она же становится планом работ на первый квартал и основой для ежемесячного отчета.
Сопровождение работающего против спасения брошенного
Две разные задачи, которые заказчики нередко смешивают.
Сопровождение работающего сервиса — это поддержание жизни: мониторинг, обновления, мелкие доработки, реакция на инциденты. Предсказуемая работа с понятной ежемесячной ценой.
Спасение брошенного — это проект: восстановить сборку, поднять окружения, разобраться в логике, закрыть критичные риски. У него есть начало и конец, и считается он отдельно, потому что объем определяется состоянием наследства.
Пытаться закрыть второе ценой первого — типовая причина конфликтов. Подрядчик берет сервис за небольшую ежемесячную сумму, обнаруживает объем работ и либо начинает просить денег, либо перестает отвечать.
Кто в компании должен участвовать
Приемка со стороны заказчика тоже требует людей, и это стоит учесть при планировании.
Нужен человек, который знает, как сервис используется в бизнесе: какие функции критичны, что происходит ежедневно, какие процессы завязаны на него. Без этого подрядчик увидит код, но не поймет, что в нем важно.
Нужен доступ к тому, кто платит за инфраструктуру: часть доступов и договоров обнаруживается именно в бухгалтерии, по счетам за хостинг и сервисы.
И нужно решение по срочным находкам. Если приемка выявила, что домен истекает через неделю или что копий нет вовсе, кто-то должен санкционировать немедленные работы. Заранее договоритесь, у кого есть такие полномочия, иначе критичное зависнет на согласовании.
Общая нагрузка на заказчика при приемке — несколько часов в течение двух недель. Это немного, но эти часы должны быть выделены заранее. Найденные случайно, между двумя совещаниями, они растягивают приемку вдвое. Тот же принцип действует и при передаче инфраструктуры между подрядчиками, что разобрано в сравнении схем обслуживания.
Почему первый месяц дороже
В первый месяц исполнитель делает то, что дальше делать не придется: восстанавливает картину, закрывает критичные риски, настраивает мониторинг и копии, пишет недостающую документацию.
Это стоит времени, и честнее вынести его в отдельную строку, чем размазать по году в виде завышенной подписки. Наша приемка стоит от 80 000 ₽ и включает проверку по всем пунктам выше плюс письменное заключение с планом работ.
Дальше начинается сопровождение: 40 000 ₽ в месяц для простого сервиса, 80 000 ₽ для среднего с интеграциями, 200 000 ₽ для нагруженного с несколькими окружениями. Разовые работы по устранению критичного считаются отдельно по результатам приемки.
Что проверить в первый день
Даже без полноценной приемки есть несколько проверок, которые занимают час и дают быстрый ответ о состоянии дел.
Откройте сервис и посмотрите, действителен ли сертификат и до какой даты. Проверьте, кто указан владельцем домена и когда истекает регистрация. Попробуйте зайти в административную часть и посмотрите, сколько там активных учетных записей и нет ли среди них уволенных сотрудников или неизвестных вам людей.
Спросите, где лежат резервные копии, и попросите показать последнюю. Если ответ занимает больше пяти минут, копий, скорее всего, нет в том виде, в котором они нужны.
Эти четыре проверки не требуют разработчика и регулярно вскрывают вещи, которые надо чинить немедленно, независимо от того, кто будет поддерживать сервис дальше.
Что должно быть в договоре
Несколько пунктов, которые стоит проговорить до начала работ, чтобы не повторить историю с предыдущим подрядчиком.
Все учетные записи и домены оформляются на заказчика. Исходный код и права на него принадлежат заказчику после оплаты. Доступы к репозиторию есть у представителя заказчика с первого дня. Документация обновляется по мере изменений и хранится там, где заказчик до нее дотянется.
Отдельно фиксируется порядок расставания: срок передачи дел, полный состав передаваемого, обязанность отвечать на вопросы преемника в течение оговоренного периода. Как это увязывается с параметрами обслуживания, разобрано в статье про SLA.
Типовые находки приемки
Список того, что обнаруживается чаще всего. Он полезен как ожидание: если подрядчик находит эти вещи, он смотрит внимательно. Отчет по шаблону выглядит иначе и таких деталей не содержит.
Развертывание вручную по памяти. Изменения выкатываются копированием файлов на сервер, порядок действий знает один человек. Первое, что чинится: воспроизводимая процедура выкладки с возможностью отката.
Продуктовая среда как тестовая. Проверка идет прямо на работающем сервисе, потому что другой площадки нет. Отдельная среда для проверок окупается на первом же неудачном изменении.
Одна учетная запись на всех. Администраторский доступ общий, кто что менял — неизвестно. Разделение по людям с журналом действий делается за день.
Забытые фоновые процессы. Скрипты по расписанию, о которых никто не помнит: часть уже не нужна, часть тихо падает месяцами, а один из них неожиданно оказывается критичным для бизнеса.
Устаревшая версия платформы. Обновление откладывалось, и теперь оно требует переработки кода. Планируется отдельным этапом, потому что делать это одновременно с приемкой значит смешать две задачи.
Когда сервис проще переписать
Честный раздел, потому что иногда это правда.
Признаки, при которых переписывание оказывается дешевле поддержки: технологии, для которых сложно найти специалистов; отсутствие исходного кода целиком или частично; архитектура, не выдерживающая текущую нагрузку без переработки; бизнес изменился настолько, что от исходной логики осталась половина.
Но решение это принимается по цифрам, а не по ощущению разработчика, которому чужой код всегда кажется плохим. Считается стоимость поддержки на горизонте двух лет против стоимости переписывания плюс риски переходного периода.
Промежуточный вариант встречается чаще: сервис поддерживается как есть, а новая функциональность пишется рядом в современном виде и постепенно забирает части старого. Дольше по календарю, зато без остановки бизнеса и без ситуации, когда новая версия делается год, а старую все это время никто не поддерживает.
Как выглядит первый месяц работы
Порядок, который мы используем и который стоит требовать от любого подрядчика.
Первая неделя: сбор доступов, инвентаризация, попытка воспроизвести сборку, проверка копий и мониторинга. Итог — список того, что критично.
Вторая неделя: закрытие критичного. Настройка резервного копирования, если его нет. Замена скомпрометированных секретов. Подъем мониторинга. Восстановление воспроизводимой сборки.
Третья и четвертая недели: тестовая среда, документация, план работ на квартал, первый отчет. К концу месяца сервис становится управляемым: понятно, что там внутри, что может сломаться и что делать, когда сломается. Дальше работа переходит в обычный режим сопровождения с предсказуемой ежемесячной стоимостью.
Чек-лист приемки
- Исходный код получен целиком, с историей изменений.
- Проект собирается на чистой машине по письменной инструкции.
- Известно, где продуктовая среда, где тестовая, и есть ли вторая вообще.
- Все доступы к серверам, панелям и внешним сервисам у заказчика.
- Домены и сертификаты оформлены на заказчика, сроки продления известны.
- Ключи внешних интеграций перевыпущены на корпоративные учетные записи.
- Резервное копирование работает, восстановление проверено.
- Настроен мониторинг доступности, уведомления приходят живому человеку.
- Секретов в открытом виде в репозитории нет.
- Составлен список технического долга с разделением на критичное, важное и желательное.
Десять пунктов — это и есть содержание приемки, и по ним же принимается работа самого подрядчика на этом этапе. Пройти их можно и своими силами, если в компании есть технический специалист с временем на это, а если некому, с них начинается наша работа: что входит в сопровождение веб-сервиса, описано на странице услуги. Как в целом устроен выбор между своими силами и внешней командой — в разборе стоимости года.