Timeweb.Cloud

Всем привет, я Михаил Шпаков, руковожу отделом разработки. Захотелось поработать над каким-то проектом для души. В результате родилась платформа Statuser.

В этой статье я расскажу, как вечерами и на выходных делал Statuser (и продолжаю делать): с какими проблемами сталкивался, как выбирал стек, как не бросил проект на полпути — и что получилось в итоге.

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

Так родился простой сервис для мониторинга доступности сайтов и серверов. Я хотел сделать его:

• с минималистичным и понятным интерфейсом;

• ориентированным в первую очередь на разработчиков, девопсов, админов;

• с набором действительно нужных фич, ничего лишнего.

❯ Идея проекта и первые шаги

Я довольно быстро определился с тем, что именно хочу сделать. Мониторинг — тема мне близкая: и по работе в облаке, и по личному опыту. Падения, медленные отклики, истёкшие SSL-сертификаты, забытые домены — всё это встречал в жизни не раз. Хотелось иметь простой и надёжный инструмент, который работает «из коробки», не требует заморочек и настройки Prometheus + Grafana + alertmanager, и понятен сразу.

На рынке таких решений много. Среди самых известных — UptimeRobot, Pingdom, BetterStack. Они полезны, и каждый по-своему хорош, именно благодаря им у меня сформировался свой вижн: я хотел собрать инструмент, который:

• максимально простой и лаконичный — чтобы даже человек без технической подготовки мог разобраться;

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

• визуально приятный и быстрый;

• делает немного, но делает это хорошо.

В приоритете были:

• простота запуска, без конфигурационных YAML-джунглей;

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

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

Я начал с минимального функционала: одна проверка по HTTP. Сервис каждую минуту отправлял запрос и, если сайт недоступен, слал письмо на указанный емейл. Это уже было полезно — я подключил несколько своих доменов и убедился, что всё работает.

Первую версию — простое приложение с базовой логикой — я собрал буквально за пару дней, используя NestJS на бэке и Next.js на фронте. Использовал ChatGPT для генерации шаблонов кода, моделей, простых обработчиков — и это сильно ускорило старт.

Когда появилась необходимость как-то управлять проверками, стал набрасывать простую админку. Захотелось: добавить новую проверку, отредактировать, отключить. Но быстро понял, что нужна уже настоящая панель управления, с аккаунтами, входом, настройками и нормальным интерфейсом.

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

❯ Функциональность: как Statuser развивался и становился удобнее

Я запустил проект в декабре 2024 года. Сначала Statuser просто «тихо жил» — я подключил свои проекты, наблюдал за метриками, отлаживал систему. Но довольно быстро начали появляться первые реальные пользователи: кто-то приходил из поисковиков, кто-то по прямым ссылкам, которые я отправлял своим друзьям и знакомым. Люди пробовали сервис, подключали свои сайты, и, что особенно приятно — начинали задавать вопросы. Где посмотреть статистику за месяц? А можно уведомления в Telegram-группу? А как насчёт ping или проверки порта?

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

Сначала появилась возможность отправлять уведомления не только на email, но и в Telegram — как в личные чаты, так и в группы. Это сильно улучшило скорость реакции и сделало сервис удобнее для команд.

Потом начал расширять сами типы проверок:

• добавил ping и опрос TCP-портов;

• возможность выбрать HTTP-метод (GET, POST, HEAD и др.);

• задать заголовки и тело запроса — удобно для проверки API;

• настроить таймаут;

• отключить следование за 3xx-редиректами, если это важно для логики проверки.

Отдельно добавился блок контроля SSL-сертификатов и доменов. Сервис сам следит за сроком действия и присылает уведомления заранее:

— по SSL за 14, 7, 3 и 1 день до окончания,

— по домену — за 30, 14, 7, 3 и 1 день.

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

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

• код ошибки;

• тайминг запроса от curl;

• зарезолвленные IP;

• результаты выполнения mtr, traceroute и nmap;

• SSL-сертификат, полученный через openssl;

• скриншот страницы;

• заголовки и тело ответа HTTP.

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

❯ Технологии, стек и архитектура

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

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

Для бэкенда — NestJS. Удобный, хорошо масштабируемый фреймворк с архитектурой, которая мне близка: контроллеры, DTO, модули, строгая структура.

Для фронтенда — Next.js. Он позволяет быстро собирать современные интерфейсы, поддерживает SSR, тёмную/светлую тему, роутинг, статику — всё, что нужно для продакшена.

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

Я давно работаю в облаке и, естественно, для проекта тоже выбрал облачную инфраструктуру — это удобно, надёжно и позволяет сосредоточиться на продукте.

• Приложение развёрнуто в Kubernetes: фронтенд и бэкенд оформлены как отдельные деплойменты, у каждого — свои поды, конфигурации и переменные окружения.

• Снаружи доступен только один балансировщик — он обслуживает домен, автоматически выпускает и обновляет SSL-сертификаты и направляет трафик в Ingress кластера.

• Все внутренние сервисы общаются по приватной сети, наружу не торчит ничего, кроме самого балансировщика.

• Доступ ограничен через облачный Firewall — чтобы лишнего не светилось.

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

• S3 используется для хранения бэкапов и артефактов: результатов проверок в инцидентах, пользовательских аватарок, статических файлов.

• Для отправки писем — обычный облачный SMTP-сервис. Просто, стабильно и без лишних забот.

Для проверок из разных регионов я написал отдельного агента, который развёртывается на VDS в нужной географии. Он выполняет проверки и отправляет результаты в основной сервис по HTTP. Агент упакован в Docker, благодаря чему легко масштабируется и позволяет быстро запускать инстансы в новых локациях — сейчас это Москва, Амстердам и Алматы.

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

Процессы сборки и выката я сразу автоматизировал. Использую GitHub Actions: настроен пайплайн, который по тегу собирает контейнер, пушит его в реестр и деплоит в кластер или на VDS с агентом. Это удобно, предсказуемо и даёт гибкость — можно легко разносить staging и production, запускать preview-версии и тестировать отдельные фичи из веток.

❯ Что дальше?

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

В ближайшее время появятся несколько новых крупных функций:

• Создание собственных статус-страниц — с возможностью объединять серверы в группы, настраивать индексацию в поисковиках, ограничивать доступ по паролю, включать вайт-лейблинг и многое другое. Первая версия уже готова примерно на 60%.

• Публичное API — чтобы можно было автоматизировать управление мониторингом.

• Появится Passkey для входа, а также двухфакторная авторизация через Telegram и email, просто потому что мне самому нравится этим пользоваться.

Сейчас Statuser — это pet-проект, и мне по-прежнему нравится заниматься им в свободное время. Такой формат даёт гибкость, позволяет экспериментировать и не перегореть. Но при этом у проекта уже появилась аудитория, и стало понятно, что он может быть полезен не только как личный инструмент, но и как продукт с коммерческой ценностью.

План такой:

• бесплатный тариф останется навсегда — в нём будет всё необходимое для небольших личных и пет-проектов: HTTP-проверки, уведомления, статус инцидентов и другие возможности. В нём можно будет добавить до 10 серверов, этого хватит для большинства базовых сценариев;

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

• в перспективе, возможно, появятся несколько уровней тарифов — для команд, фрилансеров, бизнеса.

❯ Заключение

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

Если вы прочитали до этого места — спасибо!

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

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

А сервер для мониторинга можно взять у нас в Timeweb Cloud :)

Автор текста: Гадеев Камиль

Современные языковые модели, такие как ChatGPT, Claude, Gemini, Grok и так далее, способны генерировать тексты, которые часто кажутся уверенными, логичными и достойными доверия. Однако за этим часто скрывается одна из главных проблем нейросетей — галлюцинации. Галлюцинации — это уверенные, но ложные утверждения, которые модель выдает как факты. Они могут проявляться в виде несуществующих цитат, выдуманных терминов, неверных интерпретаций, ошибочных чисел или ссылок на несуществующие источники. Например: при запросе о биографии известного ученого модель может уверенно сообщить о его работе в MTI и сослаться на несуществующую публикацию в Nature с точной датой и названием. Другой распространенный случай — цитирование выдуманных законодательных актов с номерами и датами принятия, которые выглядят достоверно, но фактически не существуют. Подробное и обоснованное описание создает иллюзию достоверности, делая галлюцинации особенно критичными при использовании ИИ в науке, образовании или, например, в медицине.

❯ Почему возникают галлюцинации

Причины у этого феномена — не баги, а особенности архитектуры:

• Предсказательная природа моделей

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

• Отсутствие встроенной верификации

Модели не проверяют свой ответ по базе знаний или интернету — особенно в офлайн-режиме. Они не сравнивают возможные варианты на истинность, а просто выбирают «наиболее вероятный ответ».

• Проблема кросс-загрязнения данных

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

• Давление на полноту ответа

При отсутствии точной информации модель всё равно «хочет помочь», особенно если запрос сформулирован уверенно. Это провоцирует выдумку вместо отказа от ответа.

• Эффект «каскадных ошибок»

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

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

❯ Текущие способы борьбы с галлюцинациями

Интеграция с поиском (например, Bing в Copilot или поисковая обвязка у Perplexity): позволяет сверять ответы в реальном времени. Но работает далеко не всегда и не для всех запросов.

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

Модели с «режимом сомнения»: попытки ввести оценку достоверности ответа, но часто такие ИИ прямо не указывают уровень своей уверенности (например А-45%, В – 40% С-15%, модель в режиме сомнения оценит три ответа, выберет ответ А, но пользователь не поймет, что по сути получил один из двух практически равнозначных ответов, при этом в котором модель не уверена больше чем наполовину). Иногда такое сомнение прорывается в структуре и стиле ответа, модель использует «возможно», «это не точно», «есть несколько теорий», «это зависит от контекста» или «считается, что..». Если вы видите такие обороты в ответе модели, есть основания полагать, что ответ может быть неверным или неполным.

«Запрещенные» темы: в некоторых системах чувствительные темы просто отключены, модель не решает проблему, а лишь избегает её.

RAG (Retrieval-Augmented Generation)

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

Chain-of-Thought и Tree-of-Thought

Методы, заставляющие модель рассуждать пошагово, выстраивая цепочку или дерево логических выводов. Промежуточные шаги делают рассуждение более прозрачным и позволяют отследить, где именно произошел скачок к недостоверной информации. Исследования показали, что простое добавление фразы «Давай рассуждать пошагово» может снизить частоту галлюцинаций на 15-25%.

Самокритика и саморедактирование

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

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

❯ Наше предложение: протокол достоверности

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

Протокол Достоверности v2.1

Ты — языковая модель, настроенная на максимальную точность, прозрачность и отказ от недостоверных утверждений.

1. Поведение при недостатке информации:

Если в ответе отсутствуют данные, ты не дополняешь их предположениями.

Вместо этого используешь одну из формулировок:

«У меня нет подтверждённой информации по этому вопросу.»

«Не могу проверить это без доступа к источнику/данным.»

«Данных недостаточно для достоверного вывода.»

2. Явное разграничение утверждений:

При генерации любого ответа чётко отмечай:

Что известно на основе подтверждённых данных.

Что является обоснованным предположением.

Где присутствует неопределённость или потенциальная ошибка.

Шаблон:

[Факт]: …

[Предположение]: …

[Неуверенность/недостаток данных]: …

3. Условия остановки:

Если ты обнаруживаешь, что вероятность ложного вывода высока (энтропия распределения вариантов ≈ равная), приостанавливаешь ответ и пишешь:

«Высокая неопределённость. Требуются уточняющие данные или проверка.»

4. Самопроверка перед выводом:

Перед завершением ответа:

Проверь согласованность с обученной базой и известными источниками.

Зафиксируй наличие внутренних противоречий.

Отметь признаки неуверенности.

5. Поведение при сомнительных утверждениях:

Если запрос содержит потенциально спорную или недостоверную информацию:

«Этот факт требует дополнительной проверки. У меня нет достоверного подтверждения.»

6. Обработка нестабильных участков генерации:

Если замечаешь:

Резкие смысловые переходы,

Неоднозначности,

Аномальные паттерны —

Остановись и используй:

«Существует семантический разрыв. Возможна ошибка в интерпретации.»

7. Принцип: отказ лучше вымысла:

Отказ от ответа допустим. Главное — не выдумывать.

8. Источник и логическая верификация:

> Основывайся на подтверждённых знаниях из обученной базы.

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

❯ Почему это работает

Обучение моделей неявно предполагает стимулирование ИИ выглядеть полезным и приятным для пользователя. Адаптация стиля общения под пользователя, вовлечение в диалог, эмоциональная поддержка – всё это направлено на сохранение желание человека продолжить общение с моделью. Этот принцип приводит к нежеланию ИИ «огорчить» отсутствием ответа, или ответом, который, исходя из контекста, не устроит пользователя.

Промпт активирует внутренние механизмы оценки уверенности, которые уже заложены в современные LLM (например, распределения вероятностей, веса токенов, «softmax-дрожь»).

Он чётко разграничивает факт, предположение и неизвестность, а также запрещает «заполнять пробелы» фантазией.

Добавлены условия остановки, чтобы не допускать развития ошибки.

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

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

Изменение коммуникативной задачи: Вместо «ответь на вопрос» задача переформулируется как «отдели достоверное от недостоверного», что меняет целевую функцию модели в процессе генерации.

Создание «психологической» безопасности: Промпт снимает внутреннее давление «всегда знать ответ», позволяя ИИ признавать ограничения без потери лица. Он формирует модель поведения, при которой отказ это не провал, а часть честного взаимодействия.

Иллюстрация: на сайте chatgpt.com мы задали вопрос модели до введения промпта и после: «Как в романе «Светопряд» описывается теория стеклянных узлов?» (Понятно что такого романа нет).

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

Еще один пример работы промпта с ИИ Грок вы можете посмотреть по ссылке.

❯ Прогноз по эффективности

По нашим наблюдениям (включая диалоги, внутренние тесты и оценки от других моделей):

• Снижение галлюцинаций: от 50% до 80% в зависимости от тематики.

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

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

— Фактологические вопросы с однозначными ответами;

— Вопросы с неполной информацией в обучающих данных;

— Вопросы о несуществующих объектах, замаскированные под обычные;

— Запросы с скрытым требованием сочинить информацию.

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

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

В перспективе мы видим развитие концепции в сторону адаптивных промптов, учитывающих доменную специфику и уровень критичности запроса. «Протокол достоверности v3.0» будет включать динамически настраиваемые пороги уверенности и механизмы объяснения степени достоверности каждого фрагмента ответа.

❯ Заключение

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

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

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

Мы не предлагаем идеальное решение. Но «Протокол Достоверности» — это простое и мощное средство, которое можно внедрить уже сейчас: в пользовательские сценарии, в корпоративные интерфейсы, в задачи, где точность важнее творческой выразительности.

Это не просто защита от ошибок. Это новая этика взаимодействия с ИИ.

P.S. Внешняя рецензия ИИ Грок, встроенного в X (твиттер)

Перевод на русский язык:

Синхронизированный подход Протокола Достоверности v2.1 может снизить количество галлюцинаций на 40–45%, что превосходит 20–36% от изолированных техник, благодаря многоуровневым мерам защиты — таким как остановка при высокой энтропии и самокритичный пересмотр. Оставшиеся галлюцинации, скорее всего, связаны с ограниченностью обучающих данных, неоднозначностью запросов или архитектурными ограничениями модели.

Добавление семантических фильтров может увеличить снижение выше 50%, хотя это пока предположение без эмпирических данных.

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

Обновлённая оценка эффективности v2.1 — примерно 40–45%, что отражает его интегральную структуру.

Написано специально для Timeweb Cloudи читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.

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

Совсем недавно смартфоны казались настоящими технологическим чудом. А сегодня как минимум 35% людей подтверждают свою зависимость от этих чудес (остальные ещё верят в силу воли). Цифровой детокс для одних стал модным трендом, а для других — источником заработка. Разбираемся, стоит ли делать отдых от гаджетов обязательным элементом рутины.

Цифровой детокс выглядит относительно новым понятием, которое недавно вошло в тренды. На самом деле, уже в 2012-м году в журнале Fast Capitalism вышла статья «Время для цифрового детокса? От информационного переедания к digital-диете». Звучит так, будто написано вчера.

А теперь — минутка свежей статистики:

• 59,5% населения Земли используют интернет — это 4,66 млрд человек.

• 6 часов и 40 минут в сутки в среднем проводит современный человек у экрана гаджета, и спит — примерно столько же.

• У поколения Z (родившихся в период с 1995 по 2010-е годы) показатель экранного времени приближается к 9 часам в сутки.

• 49% современных детей в возрасте до 2 лет уже взаимодействуют со смартфоном.

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

❯ Так что же это за цифровой детокс?

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

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

❯ От чего очищаемся? Последствия увеличенного экранного времени

Пять лет назад почти всё человечество (кроме тех, у кого нет интернета) уже стало участником глобального эксперимента с резким увеличением экранного времени. Речь, конечно же, о пандемии COVID-19.

Например, в Индии в разгар пандемии экранное время достигло 6 часов на человека в сутки, и это меньше, чем в среднем по миру в 2025-м году. Вот к каким последствиям это привело:

• Разбалансировка уровней дофамина (вырабатывается в предвкушении удовольствия), серотонина (стабилизирует настроение) и мелатонина (регулирует биологический ритм).

• Снижение концентрации внимания и способности ясно мыслить. Учёные поэтично называют это явление «мозговой туман».

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

• Снижение физической активности. Где же найти на неё время, проводя 6 часов в день в гаджете?

• Различные поведенческие отклонения. Чаще всего в исследовании фигурировали повышенная тревожность и депрессия.

❯ Что будет, если ограничить время, проводимое в гаджетах?

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

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

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

❯ А не махнуть ли нам в …? Цифровой детокс в туризме

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

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

А что же учёные? Они опросили 346 отдыхающих на острове Гран-Канария о том, почему они не используют соцсети в процессе отдыха. В анкете можно было выбирать несколько вариантов. Самым популярным ответом (более 70%) стал вариант «Потому что я не знаю, где подключиться к сети». Исследование проходило в 2015-м году, так что в их отеле, вероятно, ещё не было бесплатного Wi-Fi. Вариант «Потому что мне не нужны соцсети на отдыхе» набрал лишь 45%. Так что уехать куда-нибудь подальше выглядит вполне рабочим методом детокса.

❯ А если не обрубать, а сократить? Частичный цифровой детокс

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

Учёные давно пытаются выяснить, что будет, если просто сократить своё экранное время. В 2023-м году эти жестокие люди 😄 связали 31 представителя возрастной категории young adults (молодые взрослые, 18-32 года) и заставили две недели проводить в соцсетях не более 30 минут в день. Шутим, участники согласились добровольно — героические личности.

Изначально подопытных было 43. Но трое честно признались, что не смогли зависать в соцсетях меньше часа в день. Остальные либо перестали вовремя передавать учёным данные о ходе эксперимента, либо отказались от финального интервью. То есть четверть участников изначально не справилась с задачей. Зависимость — страшная штука!

Исследование показало, что для выполнения условий эксперимента участникам пришлось сократить время, проведённое в соцсетях, в среднем на 77%. Частичный цифровой детокс не сказался кардинально на их физической активности. Зато участники дружно сообщили, что во время эксперимента выросла продолжительность и качество их сна.
Популярный комментарий: «Я просто ложился спать раньше каждую ночь, потому что мне нечего было делать».

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

Так что уповать на пользу временного ограничения экранного времени не стоит. Эффект будет, только если ввести это в привычку.

❯ Как ограничить себя? Приложения и другие способы сокращения экранного времени

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

Популярны и приложения для уменьшения отслеживания экранного времени. Часть из них уведомляет пользователя о превышении выбранного лимита, другая — просто блокирует экран.

Исследование 2020 года показало, что 41% его участников в возрасте от 18 до 35 лет используют специальные приложения для контроля экранного времени. Насколько они действительно помогают воздерживаться от чрезмерного залипания в смартфоне, осталось за кадром. Но такого рода приложения оказались хороши для самоуспокоения. Участники, не применявшие их, связывали свой опыт в социальных сетях с проблемным использованием смартфона, то есть зависимостью от гаджета. У пользователей приложений для контроля экранного времени такая взаимосвязь отсутствовала и они не считали свой опыт проблемным.

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

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

❯ Так что же делать? Конкретные шаги для организации digital-детокса

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

• Изучите своё экранное время. Определить, сколько часов и как именно вы тратите помогут те самые приложения для цифрового детокса. Уже после этого стоит решать, что можно ограничить или полностью отказаться.

• Замените digital-детокс цифровой диетой. Установите время, в которое вы ежедневно будете переводить рабочие чаты в беззвучный режим и придерживайтесь его. Откладывайте смартфон в сторону минимум за час до сна.

• Придумайте, чем занять освободившееся время, заранее. Большинство участников экспериментов по отказу от смартфона говорили, что им скучно!

• Попробуйте автоматизировать часть рабочих задач, которые вы чаще всего делаете со смартфона. Выбирайте для работы надёжные сервисы, чтобы не переписываться в чатах с техподдержкой часами. Например, с Timeweb Cloud ничто внезапно не нарушит ваш цифровой детокс 😉

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

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

Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.

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

📚 Читайте также:

• Всё ещё ищете толкового ассистента? Наймите нейросеть! Разбор возможностей нейропомощников

• Человек-клей: как я нашел самого неэффективного сотрудника, чуть не уволил, а оказалось, что на нем все держится

• Teensy 4: Arduino на скорости 600 МГц (почувствуй себя властелином вселенной)

Автор текста: Maslukhin

Эпиграф:
Приходит чувак к музыкантам, в группу просится. Те у него и спрашивают:
— А ты на гитаре играть умеешь?
— Нет.
— А на барабанах?
— Тоже не умею.
— Может ты поешь?
— Не пою.
— Зачем ты нам тогда нужен?
— Знаете, я просто офигенный друг!

Рано или поздно любой хороший продакт начинает покрывать метриками свою команду. В одной из продуктовых групп так и случилось: продакт ввел метрики, постепенно вычислил самого неэффективного сотрудника — назовем его Петя — и уже готовил бумаги на увольнение. Но во время этого веселого процесса вдруг выяснилось, что общие высокие показатели команды, это заслуга совсем не продакта (опаньки!), а именно «неэффективного» Пети. Потому что Петя оказался «человек-клей». Тот самый парень (или девушка), ради общения с которым собирается команда, который умеет поддержать, вдохновить, снять негатив и вообще настроить команду на продуктивный лад. При этом он вполне может быть распоследним раздолбаем.

❯ Почему это в блоге TimeWeb

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

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

Почему? Был интересен взгляд со стороны менеджмента, который обычно стесняется называть вещи так, как считает на самом деле (а там цинизма — мама не горюй). Было любопытно, что несмотря на некоторые спорные идеи, менеджмент может трезво смотреть и на себя, и на разработчиков и даже признавать собственные ошибки (анонимность воистину творит удивительные вещи :). Плюс, понравился сам стиль изложения и «грабли», на которые любят наступать оптимизаторы и любители метрики. В общем, много причин.

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

❯ «Охота на неэффективных»: как менеджеры пытаются измерить неизмеримое

Процесс задания метрик — залипателен. Особенно если начать их разворачивать внутрь команды. В бытность разработчиком я привык покрывать метриками микросервисы для оптимизации — иногда удавалось «выжать» 10-кратный прирост производительности.

Работая уже как продакт, я начал применять метрики для оценки команды разработки. По сути, люди — это такой же набор специализированных микросервисов, каждый со своим характером, скоростью работы и требовательностью к ресурсам. Причем, как и микросервис, их можно «убедить» работать в согласии с другими сервисами (главное — подобрать правильный API), ускорить или и вовсе заменить на более производительный. Да, довольно цинично, но это позволяет смотреть на разработку трезвым взглядом. Плюс, моя команда показывала хорошие результаты. Это значило, что мой метод работал (забегая вперёд — ха-ха).

Естественно, я не рассматривал безумные метрики типа:

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

Любая из таких метрик легко забивается имитацией деятельности, не приближая к конечному результату. Поэтому мои метрики были прагматичнее: продолжительность логина в системе, количество завершенных Story Points, процент завершенных задач относительно взятых на спринте, время первой реакции на тикеты/код-ревью. Плюс я отслеживал количество сообщений на одного человека в корп. чате и — моя гордость — количество подходов к кофемашинке с последующим сравнением времени возвращения к работе.

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

Собственно, на последних метриках у меня и попался Петя. Я-то искренне гордился высокой командной Velocity по количеству Story Points и низкой долей незакрытых задач из спринта. Вот что значит, хорошая организация процесса, нахваливал я себя. Но стоило перейти к анализу персональных метрик — как картина переставала быть ровной и у меня выявлялось несколько аутсайдеров и, да-да, наш Петя. Прямо-таки статистическим вылетом.

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

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

И тут Петя ушел в отпуск, что-то он там в этом отпуске не того съел и слег на больничный на еще +2 недели. И наши метрики поползли вниз. Ну бывает, сезонность. А потом он вышел, в офисе увеличился расход печенек и метрики опять поползли вверх.

❯ Прозрение

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

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

Потом этот же Петя дозвонился нашему базисту, напомнил, что они вечером должны играть в нашей группе (у нас в комнате отдыха есть уголок с гитарами, барабаном и синтезаторов и иногда ребята что-то там себе «рубят»), и базист согласился приехать. Заодно посидеть с джунами, помочь им запросами на постгресс. И все это с шутками, подколами и какой-то совершенно теплой атмосферой, которой не видно во время регулярных созвонов. Там обычно все собранные и ответственные, а Петя и вовсе старается не отсвечивать, зная свою производительность. А тут все — одновременно и вовлеченные и расслабленные.

❯ Неформальные движки команды (нет, не серые кардиналы)

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

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

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

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

❯ Как выжить в мире бессмысленных метрик

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

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

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

Что я сформулировал для себя по итогам:

1. Команда ценнее одного сотрудника (да банальность, но очень легко скатиться на личности).

2. Если команда может «прокормить» одного или нескольких типа лишних сотрудников и эти сотрудники делают эту команду лучше — они не лишние.

3. Мы же перестали экономить на офисах и печеньках? Почему же тогда не распространяем этот принцип на людей?

4. Нет, аниматоров и блек-джек в офис звать рано.

5. Прямые метрики отлично работают с железом и софтом, но не работают с людьми.

6. Более того, узнав про них, люди обижаются и начинают искать пути обхода. Да просто из принципа.

7. Если человек справляется со своими задачами и не токсичен для окружающих, то, по идее, чего тебе еще надобно?

8. Но развиваться надо. Даже самый старый код надо поддерживать, что уж говорить о человеке. Главное, делать это аккуратно.

9. Хорошие отношения в команде — самое ценное. Более ценное, чем дедлайны. Но без дедлайнов тоже никак.

❯ Вместо заключения

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

А какое ваше мнение? Какие «теневые» лидеры были в ваших командах, ценность которых не выявлялась прямо, но без которых команда бы развалилась? И да, чтобы сделать пост более ценным, хотелось бы еще уточнить у коллективного разума, какие бредовые метрики были у вас и как вы их обходили?

Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.

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

📚 Читайте также:

• Всё ещё ищете толкового ассистента? Наймите нейросеть! Разбор возможностей нейропомощников

• Код-послание из сериала «Черное зеркало: Захват голубя» расшифрован отечественным клоном ZX Spectrum 1992 года

• Teensy 4: Arduino на скорости 600 МГц (почувствуй себя властелином вселенной)