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

Большинство владельцев бизнеса уверены, что главный цифровой риск начинается в тот день, когда увольняется разработчик, исчезает агентство или уходит ключевой сотрудник.

Это не так.

На самом деле сбой обычно начинается годами раньше. Он начинается тихо. Пароль сохраняется в личном браузере вместо корпоративного менеджера паролей. Сервер настраивают, но никто не документирует почему. Продакшн-фикс выкатывают прямо в пятницу вечером, потому что "срочно". Sitemap перестаёт обновляться после редизайна. Search Console начинает сообщать об ошибках индексации, но никто их не проверяет. Разработчик создаёт Git-репозиторий на личном аккаунте, потому что так быстрее. Другой сотрудник настраивает Cloudflare. Кто-то ещё покупает домен. Маркетинговое агентство создаёт Google Analytics. SEO-специалист настраивает Tag Manager. Никто не составляет карту того, как все эти части связаны.

Всё работает. Компания растёт. Приходят клиенты. Выручка увеличивается. И раз ничего не выглядит сломанным, все считают систему здоровой.

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

СБОЙ НАЧИНАЕТСЯ

I. Сбой начинается задолго до того, как кто-то его замечает

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

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

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

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

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

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

Полный проект можно посмотреть в нашем портфолио: Medpresso.

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

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

ЭКОСИСТЕМА

Ваш сайт: только видимая поверхность

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

В итоге сайт перестаёт быть просто сайтом. Он становится экосистемой. Типичный современный бизнес может зависеть от десятков взаимосвязанных систем:

• Регистратор домена

• DNS-провайдер

• Хостинг-инфраструктура

• CDN

• SSL-сертификаты

• Почтовые сервисы

• CRM

• ERP

• Платёжные шлюзы

• Google Analytics

• Google Search Console

• Tag Manager

• Маркетинговая автоматизация

• Git-репозитории

• Пайплайны деплоя

• Облачное хранилище

• API

• Сторонние интеграции

Большинство владельцев бизнеса думают, что владеют своим сайтом. На деле они владеют сложной сетью цифровых зависимостей. Сайт, лишь видимая поверхность. Настоящий бизнес живёт под ней. И именно там непрерывность либо продумывается, либо тихо забрасывается. Мы уже писали о том, что реально значит владеть всей этой сетью, а не только видимой её частью, в статье Most Companies Don't Own Their Website. They Own a Collection of Dependencies.

ПОТЕРЯЛИ СИСТЕМУ

II. Вы потеряли не разработчика. Вы потеряли систему.

Когда компании обращаются к нам после потери разработчика или смены агентства, первая фраза почти всегда одна и та же.

«Нам нужен кто-то, чтобы продолжить поддерживать сайт».

На деле им нужно совсем другое. Им нужен кто-то, кто восстановит годы незадокументированных решений. Это не одна и та же задача.

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

Почему была выбрана именно эта архитектура? Какие интеграции всё ещё активны? Какие API-ключи всё ещё действительны? Где хранятся бэкапы? Как работает деплой? Кто владеет продакшном? Какие плановые задачи критичны? Какие сервисы общаются между собой? Зачем существует эта функция? Какой клиент зависит от этой недокументированной фичи?

Когда документации нет, каждый ответ превращается в расследование. А расследования стоят дорого.

Онбординг нового разработчика в незнакомую, недокументированную кодовую базу обычно занимает месяц-два, прежде чем он реально становится продуктивным, и это ещё оптимистичный сценарий. На хорошо задокументированной системе этот же период сокращается драматически, потому что ответы уже существуют не только в памяти одного человека. Мы разбираем, что реально сохраняет кодовая база, а что нет, в статье The Code Remembers Every Version of the Business.

НЕ ОДИН ПРОДУКТ

Сайт, это не один продукт

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

Сам сайт может составлять лишь малую часть инфраструктуры. За ним стоят домены, хостинг-провайдеры, DNS-записи, конфигурации CDN, SSL-сертификаты, маршрутизация почты, платформы аналитики, CRM, платёжные системы, сторонние API, пайплайны деплоя, бэкапы, маркетинговая автоматизация, сервисы мониторинга, репозитории, облачное хранилище, политики безопасности, плановые задачи и бесчисленные мелкие интеграции, накопленные за годы.

Большинство этих систем работают тихо. Пока однажды не перестают.

Одна ситуация повторяется удивительно часто. Мы задаём новому клиенту простой вопрос. «У вас есть документация?» Почти каждый бизнес уверенно отвечает: «Да». Затем присылают руководство по админ-панели, старое техническое задание, возможно, PDF о том, как добавлять посты в блог.

Ничто из этого не является технической документацией.

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

Разница кажется небольшой. На практике она часто определяет, возобновится ли проект за часы или замрёт на недели. Если не уверен, к какой категории относится твоя собственная документация, именно на этот вопрос отвечает Usability Audit.

АРХЕОЛОГИЯ

Каждый новый разработчик начинает с нуля

Отсутствие документации создаёт ещё одну скрытую проблему. Каждый новый разработчик начинает с нуля. Вместо того чтобы улучшать продукт, сначала он становится археологом. Читает незнакомый код. Отслеживает забытые интеграции. Сравнивает продакшн со стейджингом. Угадывает архитектурные замыслы. Изучает историю коммитов. Реверс-инжинирит структуру базы данных. Опрашивает сотрудников.

Иногда единственная оставшаяся документация, это сам код. Иногда даже он рассказывает лишь половину истории.

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

В эпоху AI это становится ещё дороже. Многие руководители считают, что современные инструменты разработки могут мгновенно разобраться в любом проекте. Это редко так. AI-ассистенты работают заметно эффективнее, когда у проекта чёткая архитектура, единообразные названия, задокументированные бизнес-правила и предсказуемая структура. Они спотыкаются там, где система годами эволюционировала без дисциплины. Без документации. Смешанные технологии. Непоследовательные названия. Устаревшие библиотеки. Временные фиксы, что стали постоянными. Бизнес-логика, спрятанная внутри контроллеров. Функции, реализованные пятью разными командами за шесть лет.

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

Мы разбираем близкую по духу проблему, когда AI даёт уверенный ответ, который никто так и не проверил, в статье The Cost of AI Isn't Generation. It's Verification.

ВЛАДЕНИЕ БЕЗ ДОСТУПА

«Сайт принадлежит нам». Правда?

Возможно, самое опасное заблуждение из всех: «Сайт принадлежит нам». Юридически это может быть правдой. Операционно, часто нет.

Мы видели бизнесы, что не могли получить доступ к собственному домену. Не могли войти в Google Search Console. Не знали, кто управляет DNS. Потеряли доступ к аналитике. Не имели Git-репозитория. Не знали, где размещён продакшн. Не имели инструкций по деплою. Не имели процедур восстановления. Не имели карты инфраструктуры.

Сайт продолжал существовать. Владение нет.

Бизнес может обладать каждым инвойсом, каждым дизайн-файлом и каждой строкой кода, и всё равно не иметь операционного контроля над собственной цифровой платформой. Это две совершенно разные вещи.

Именно поэтому организации редко теряют проекты из-за ухода разработчиков. Они теряют проекты, потому что критичное знание уходит вместе с ними. Разработчиков можно заменить. Знания нельзя. По крайней мере, не без того, чтобы заплатить за них дважды. Если твой текущий сайт достался тебе по наследству, а не был построен с тобой с первого дня, Corporate Website Development, отправная точка, с которой мы начали бы возвращать это владение.

ФРЕЙМВОРК

III. The Website Continuity Framework™

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

Сложность сама по себе не проблема. Проблема, невидимая сложность.

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

Разработчик увольняется. Агентство закрывается. Хостинг-провайдер меняет политику. Платёжный шлюз обновляет API. Сервер падает. Ключевой сотрудник уходит на пенсию. Начинается война. Пропадает ноутбук.

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

За годы мы заметили, что устойчивые цифровые бизнесы разделяют одну общую черту. Они не зависят от людей. Они зависят от систем.

Это важное различие. Люди остаются незаменимыми. Но знание принадлежит организации. Не отдельным людям.

Каждое критичное решение можно отследить. Каждая важная интеграция задокументирована. Каждое продакшн-окружение можно восстановить. У каждого пароля есть владелец. У каждого сервиса есть назначение. У каждого деплоя есть процесс.

Если завтра вся команда исчезнет, другая квалифицированная команда сможет продолжить работу. Не потому что знает проект. Потому что проект знает сам себя.

Эта идея легла в основу того, что мы теперь называем Website Continuity Framework™. Он состоит из пяти областей, что каждый растущий бизнес должен постоянно поддерживать.

1. ВЛАДЕНИЕ

1. Владение

Может ли твоя компания доказать операционное владение каждым критичным цифровым активом? Не только юридически. Практически. Кто контролирует домен? DNS? Хостинг? Git-репозитории? Cloudflare? Google Analytics? Search Console? Платёжных провайдеров? Почтовую инфраструктуру?

Владение, это не контракт. Владение, это непрерывный доступ.

Когда этот доступ проходит через внешнюю команду, стоит почитать про IT Outsourcing & Outstaffing, конкретно о том, как владение должно быть оформлено контрактно, а не только технически.

2. ДОКУМЕНТАЦИЯ

2. Документация

Если все текущие разработчики завтра исчезнут, сможет ли другая команда понять, как работает твой бизнес? Не как редактировать страницу. Как работает система. Архитектура. Инфраструктура. Деплой. Бизнес-логика. Интеграции. Процедуры восстановления.

Без документации каждое будущее улучшение начинается с восстановления вчерашнего знания.

3. ОПЕРАЦИОННАЯ УСТОЙЧИВОСТЬ

3. Операционная устойчивость

Может ли текущая работа продолжаться без конкретного человека? Возможны ли релизы? Можно ли чинить баги? Можно ли восстановить бэкапы? Можно ли справиться с инцидентом безопасности? Можно ли мигрировать инфраструктуру?

Если ответ зависит от одного человека, у бизнеса есть риск непрерывности. Мы разбираем, как привлекать внешнюю помощь, не создавая ту же самую зависимость заново, в статье How to Hire a Remote Dev Team Without Getting Burned.

4. ТЕХНИЧЕСКАЯ УСТОЙЧИВОСТЬ

4. Техническая устойчивость

Технологии никогда не стоят на месте. Версии PHP устаревают. Фреймворки перестают получать обновления безопасности. Библиотеки теряют поддержку. Браузеры эволюционируют. Поисковики меняются. AI-процессы разработки продолжают переформатировать саму инженерию.

Каждый год, что проект остаётся нетронутым, поддерживать его становится дороже, чем годом ранее.

Игнорирование поддержки не замораживает технологию. Оно просто откладывает счёт.

Выбор фреймворка обычно и есть главный фактор, определяющий размер этого счёта годы спустя, мы разбираем это в статье Laravel vs Symfony: The Most Expensive Technology Decision Is Often the One You Never Make.

5. ЗНАНИЯ ОРГАНИЗАЦИИ

5. Знания организации

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

Эти ответы редко существуют внутри исходного кода. Они существуют в памяти людей. Пока не задокументированы.

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

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

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

ЭРА AI

Непрерывность важна ещё больше в эпоху AI

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

Компании, что получают от AI больше всего пользы, не обязательно те, у кого самые новые технологии. Это те, у кого самые понятные системы. Структурированная документация. Последовательная архитектура. Чистые репозитории. Задокументированные бизнес-правила. Предсказуемые процессы.

AI не устраняет потребность в организационном знании. Он вознаграждает организации, что его сохраняют.

Мы столкнулись именно с этим разрывом сами, куда более напрямую, чем ожидали, в статье Four AIs Agreed. We Still Hadn't Verified Anything.

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

Реальный вопрос гораздо проще.

Сможет ли этот бизнес продолжать расти, если люди, что построили сегодняшнюю систему, завтра здесь не окажутся?

Всё остальное вторично.

ФИНАЛЬНАЯ МЫСЛЬ

Финальная мысль

Сайт, это не набор страниц. Это не CMS. Это не фреймворк. Это не хостинг-аккаунт. Это даже не исходный код.

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

Компании, что это понимают, не просто поддерживают сайты. Они защищают один из своих самых ценных бизнес-активов.

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

Автор: Евгений Боровой, основатель Peretz Agency.