Аналитик шлёт заказчику скриншоты графиков: живой дашборд на своём сервере

MAATRIX

Вы посчитали цифры, собрали графики в Power BI или Tableau на своём ноутбуке, сделали скриншот и отправили заказчику в Telegram. Через три дня данные обновились, а у заказчика на экране всё та же картинка — он либо принимает решение по устаревшим цифрам, либо пишет вам «скинь свежий скрин». Вы открываете тот же файл, пересобираете тот же график руками и отправляете заново. Это можно решить один раз: поднять дашборд на своём сервере, который заказчик открывает по постоянной ссылке и всегда видит текущие данные — без вашего участия в каждом обновлении.

Скриншот — это фотография прошлого

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

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

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

Что меняется, когда у дашборда есть постоянная ссылка

Живой дашборд на вашем сервере решает всё это одним движением: вместо файла заказчик получает URL. Один раз даёте ссылку — дальше он открывает её когда угодно и видит те данные, которые есть в базе прямо сейчас, а не те, что были на момент вашего последнего экспорта. Никаких «скинь свежий скрин» — свежий скрин всегда открыт по адресу.

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

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

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

Из чего собирается связка: база, BI-слой и доступ снаружи

Технически всё стоит на трёх слоях, и для фрилансера с одним VPS они прекрасно умещаются на одной машине.

Хранилище данных. Ваши цифры должны лежать в базе, а не только в Excel на диске. Для большинства фриланс-задач хватает PostgreSQL — он справляется с десятками и сотнями миллионов строк без специальной настройки. Если у вас действительно тяжёлая аналитика по логам или событиям с миллиардами записей, посмотрите в сторону колоночных СУБД вроде ClickHouse — но для типового отчёта заказчику это, как правило, избыточно.

BI-слой. Поверх базы нужен инструмент, который строит графики и умеет отдавать их по ссылке в браузере — это класс инструментов вроде Metabase, Redash или Superset, все с открытым кодом и разворачиваются одной командой через Docker Compose. Выбор между ними — вопрос вкуса и объёма данных: Metabase проще для быстрого старта и SQL-запросов, Redash и Superset дают больше гибкости в сложных визуализациях. Как поставить и настроить один из таких инструментов на VPS, подробно описано в гайде по установке Metabase, а разница между Metabase и Redash — в отдельном сравнении.

Доступ снаружи. BI-инструмент по умолчанию слушает какой-нибудь внутренний порт вроде 3000 — заказчику неудобно и небезопасно открывать его напрямую по IP и порту. Перед ним ставится реверс-прокси (обычно Nginx) с нормальным доменом и SSL-сертификатом, чтобы ссылка выглядела как https://reports.вашдомен.ru, а не http://185.x.x.x:3000. Как поднять Nginx в роли реверс-прокси на VPS — в отдельном гайде, а бесплатный сертификат для домена выпускается через Let's Encrypt и продлевается автоматически.

Вся связка на типовом небольшом VPS — база, BI-инструмент, прокси — работает без напряжения для одного-двух заказчиков с умеренным объёмом данных. Если заказчиков и дашбордов становится больше, просто берёте план с запасом по памяти: BI-слой и база при активной работе с большими выгрузками едят RAM заметнее, чем статичный сайт.

Данные должны обновляться сами

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

Правильная схема — обновление по расписанию, без вашего участия. Если данные приходят из внешнего источника (API рекламной площадки, CRM, платёжного сервиса), пишете небольшой скрипт, который забирает свежие данные и кладёт их в базу, и вешаете его на cron:

# обновление данных каждый час, лог — в отдельный файл
0 * * * * /usr/bin/python3 /home/analyst/etl/fetch_and_load.py >> /var/log/etl.log 2>&1

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

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

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

Доступ заказчика: ссылка вместо пароля от вашей инфраструктуры

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

Есть два практичных варианта, и выбор между ними зависит от чувствительности данных.

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

Доступ с паролем. Если в отчёте фигурируют суммы контрактов, персональные данные или что-то ещё, что не должно утечь при случайной пересылке ссылки, нужен слой аутентификации. Самый простой способ — базовая HTTP-авторизация на уровне Nginx перед конкретным дашбордом:

location /reports/client-a/ {
    auth_basic "Client dashboard";
    auth_basic_user_file /etc/nginx/.htpasswd_client_a;
    proxy_pass http://127.0.0.1:3000/;
}

Пароль для каждого заказчика — свой файл .htpasswd, генерируется командой htpasswd -c /etc/nginx/.htpasswd_client_a client_a. Для более серьёзной защиты, когда клиентов много и хочется единой точки управления доступом с логами входов, имеет смысл поставить перед сервисами отдельный слой вроде Authelia — но для одного-двух заказчиков это, как правило, избыточная сложность.

Что точно не стоит делать — присылать заказчику логин и пароль от общей админки BI-инструмента, где виден список всех дашбордов и всех клиентов. Разграничивайте доступ на уровне конкретного дашборда или коллекции, а не на уровне всего сервиса.

Несколько заказчиков на одном сервере

Когда клиентов становится больше одного, встаёт вопрос изоляции — заказчик A не должен даже случайно увидеть данные заказчика B. Два рабочих подхода.

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

Второй — по-настоящему растущим объёмам данных или числу клиентов имеет смысл развести хранилище: не одна общая база на всех, а отдельная схема или даже отдельный контейнер БД под крупного заказчика, чтобы тяжёлый запрос одного клиента не подтормаживал дашборд другого.

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

Частые вопросы