Подготовка копии рабочей базы для разработчика
Коллеги, подскажите пожалуйста, кому-то приходилось заниматься задачей подготовки "урезанной" копии информационной базы "для разработчика".
Дано:
- очень большая информационная база 1С на SQL Server (~5Тб).
Требуется:
- подготовить "урезанную" копию для разработчика с сохранением ссылочной целостности;
- в зависимости от подсистемы может потребоваться разный состав данных, например для разработчиков складской подсистемы справочник договоров контрагентов не нужен, соответственно должна быть возможность настройки - указать какие объекты следует оставить и (или) какие удалить с указанием отборов.
Ключевые требования:
- контроль ссылочной целостности;
- скорость подготовки копии, сейчас копия готовится несколько суток, требуется большая оперативность - хотя бы несколько часов.
Приходилось кому-то решать подобную задачу? Можете посоветовать материалы для изучения? Может быть в eng сегменте есть какие-то статьи или обсуждения (к сожалению ничего внятного найти не смог).
Дано:
- очень большая информационная база 1С на SQL Server (~5Тб).
Требуется:
- подготовить "урезанную" копию для разработчика с сохранением ссылочной целостности;
- в зависимости от подсистемы может потребоваться разный состав данных, например для разработчиков складской подсистемы справочник договоров контрагентов не нужен, соответственно должна быть возможность настройки - указать какие объекты следует оставить и (или) какие удалить с указанием отборов.
Ключевые требования:
- контроль ссылочной целостности;
- скорость подготовки копии, сейчас копия готовится несколько суток, требуется большая оперативность - хотя бы несколько часов.
Приходилось кому-то решать подобную задачу? Можете посоветовать материалы для изучения? Может быть в eng сегменте есть какие-то статьи или обсуждения (к сожалению ничего внятного найти не смог).
По теме из базы знаний
- Многопоточный CI-контур для 1С c Packer, Vagrant и Jenkins. Часть 1. Описание системы и обзор инструментария
- Технология доработки типовой конфигурации с использованием конфигуратора
- Мгновенные тонкие клоны баз 1С для разработки и тестов
- Database Compression Tool (DCT) Универсальный инструмент сжатия, свертки и конвертации баз данных 1С
- Быстрый фронт в базе размером 8.8 терабайт – наши стандарты при разработке компонентов системы
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
В моём понимании основной объём базы от регистров. 5 Тб в SQL это скорее всего с какими то логами?! Я как то наблюдал, что база выгруженная средствами 1С и загруженная в новое место теряла в весе больше 90%.
Мне кажется можно существенно сократить базу если выгрузить базу без регистров накопления, без бухгалтерских регистров.
А что за конфигурация?
Мне кажется можно существенно сократить базу если выгрузить базу без регистров накопления, без бухгалтерских регистров.
А что за конфигурация?
(2) 1С:Управление холдингом.
Логи предварительно очищаются и некоторые другие вспомогательные данные тоже, но все равно, оставшихся данных очень много и подход delete from where занимает очень много времени и, самое главное, не реализует сейчас условие по ссылочной целостности.
Логи предварительно очищаются и некоторые другие вспомогательные данные тоже, но все равно, оставшихся данных очень много и подход delete from where занимает очень много времени и, самое главное, не реализует сейчас условие по ссылочной целостности.
(4)В УХ нет лишнего. Там вся инфа в нескольких регистрах сведений. Она по сути своей и тому, как она сделана, проблема. Большая проблема. Архитектура УХ не следует вообще никаким правилам и стандартам. Это разгул фантазии и бескомпетентности. Оторвать и выбросить.
Смиритесь.
Серьезно. Ужасная поделка с нарушениями всех норм.
Смиритесь.
Серьезно. Ужасная поделка с нарушениями всех норм.
Я бы, пожалуй, сделал кучку правил обмена для разных наборов данных и выгружал бы за какой-то ограниченный промежуток времени документы.
Идея вырезать из базы кусок без части объектов метаданных и ничего не порушить выглядит утопично.
Идея вырезать из базы кусок без части объектов метаданных и ничего не порушить выглядит утопично.
(3) Спасибо за ответ!
Да, этот вариант тоже рассматривается. Проблема: придется постоянно поддерживать актуальность правил обмена - структура метаданных меняется достаточно часто. Также - в том случае, если допустим требуется подготовить "почти полную копию" - для целей НТ (нагрузочного тестирование) то потребуется перегонять слишком большой объем данных, в этом случае представляется что оптимальнее будет удалить ту часть данных которая не нужна.
Да, этот вариант тоже рассматривается. Проблема: придется постоянно поддерживать актуальность правил обмена - структура метаданных меняется достаточно часто. Также - в том случае, если допустим требуется подготовить "почти полную копию" - для целей НТ (нагрузочного тестирование) то потребуется перегонять слишком большой объем данных, в этом случае представляется что оптимальнее будет удалить ту часть данных которая не нужна.
(0) Там файлов небось много сохранено.
В копии разработчика должно быть максимум 10 документов каждого типа.
Я бы сделал так: По конфигурации создал бы пустою базу. Перенёс бы константы, "настроечные" регистры сведений и пользователей с правами.
Выгрузил бы в dt для возможности разворачивания новой копии.
Всё.
Если нужно какой-то особенный документ в копии: через КД2 генерим автоматические правила, Переносим из рабочей с сохранением зависимостей.
В копии разработчика должно быть максимум 10 документов каждого типа.
Я бы сделал так: По конфигурации создал бы пустою базу. Перенёс бы константы, "настроечные" регистры сведений и пользователей с правами.
Выгрузил бы в dt для возможности разворачивания новой копии.
Всё.
Если нужно какой-то особенный документ в копии: через КД2 генерим автоматические правила, Переносим из рабочей с сохранением зависимостей.
(5) Файлы хранятся на внешних томах.
>> В копии разработчика должно быть максимум 10 документов каждого типа.
Требования бывают разные, спасибо за замечание - не анализировали пока "профиль базы" в зависимости от подсистемы.
>> Если нужно какой-то особенный документ в копии: через КД2 генерим автоматические правила,
>> Переносим из рабочей с сохранением зависимостей.
Желательно чтобы процесс был автоматизирован: условно говоря - разработчик создает "задание" (описывает данные которые ему потребуются в базе, система выполняет подготовку базы с данными нужного состава).
>> В копии разработчика должно быть максимум 10 документов каждого типа.
Требования бывают разные, спасибо за замечание - не анализировали пока "профиль базы" в зависимости от подсистемы.
>> Если нужно какой-то особенный документ в копии: через КД2 генерим автоматические правила,
>> Переносим из рабочей с сохранением зависимостей.
Желательно чтобы процесс был автоматизирован: условно говоря - разработчик создает "задание" (описывает данные которые ему потребуются в базе, система выполняет подготовку базы с данными нужного состава).
(7)
Для этого нужно создавать специальную программу (например, конфигурацию 1С), а потом долго ее допиливать и перепиливать, по мере конкретизации исходных общих пожеланий и появления новых хотелок.
У вас есть разработчики, которые могут/будут этим заниматься? Или конфигурация должна внезапно появиться сама по себе, как джин из бутылки?
Желательно чтобы процесс был автоматизирован: условно говоря - разработчик создает "задание" (описывает данные которые ему потребуются в базе, система выполняет подготовку базы с данными нужного состава).
Каким образом представляете себе описание задания? Не в Word'е же?
Для этого нужно создавать специальную программу (например, конфигурацию 1С), а потом долго ее допиливать и перепиливать, по мере конкретизации исходных общих пожеланий и появления новых хотелок.
У вас есть разработчики, которые могут/будут этим заниматься? Или конфигурация должна внезапно появиться сама по себе, как джин из бутылки?
(10) Спасибо за ответ!
>> Для этого нужно создавать специальную программу (например, конфигурацию 1С), а потом долго ее допиливать и перепиливать, по мере конкретизации исходных общих пожеланий и появления новых хотелок.
Да, все верно - планируется разработка инструмента вида "сервис подготовки базы для разработчика".
>> Для этого нужно создавать специальную программу (например, конфигурацию 1С), а потом долго ее допиливать и перепиливать, по мере конкретизации исходных общих пожеланий и появления новых хотелок.
Да, все верно - планируется разработка инструмента вида "сервис подготовки базы для разработчика".
(11)
Аналогично: чтобы наковырять немного земли из огромной кучи, достаточно лопаты, а чтобы переместить "почти всю" кучу - нужны экскаватор и грузовик... разумеется, если надо сделать это быстро, а не за время, сравнимое со строительством пирамид. :-)
планируется разработка инструмента
Ну, так очевидно, что алгоритм работы этого сервиса не может быть универсальным (да еще и быстрым!) для разных вариантов ТЗ: или быстро делаем сильно урезанную базку, или - "почти полную копию".
Аналогично: чтобы наковырять немного земли из огромной кучи, достаточно лопаты, а чтобы переместить "почти всю" кучу - нужны экскаватор и грузовик... разумеется, если надо сделать это быстро, а не за время, сравнимое со строительством пирамид. :-)
Я в подобной ситуации генерировал запрос на truncate таблиц всех документов, справочников и регистров накопления.
Пример:
Результат скопировать и выполнить как новый запрос.
Если нужно почистить таблицы точечно, например удалить только контрагентов, то можно воспользовался инструментами разработчика. Там есть функционал выполнения прямых запросов truncate с отбором по таблицам.
Пример:
USE [Database]
SEL ECT 'TRUNCATE TABLE ' + name FR OM sys.objects WHERE type in (N'U') and name LIKE '%Document%'
Результат скопировать и выполнить как новый запрос.
Если нужно почистить таблицы точечно, например удалить только контрагентов, то можно воспользовался инструментами разработчика. Там есть функционал выполнения прямых запросов truncate с отбором по таблицам.
очень большая информационная база 1С на SQL Server (~5Тб).
А что много места занимает?
Посмотрите информацию о размерах таблиц базы данных на SQL.
А далее, на sql создавайте скрипты
1) сделать копию базы
2) обрезать таблицы
2 а) из существующей таблицы скопировать данные в Новую таблицу, за период (фильтр по Дате или Период)
2 б) удалить старую таблицу (TRUNCATE TABLE)
2 в) переименовать новую таблицу в старую (для этого предварительно нужно запоминать как называлась старая таблица)
и так для каждого регистра (посмотрите какие вам нужны, начинайте с самых больших по размеру)
Основу всех скриптов пишем в ms sql
А из кода 1с получаем названия названия таблиц и генерим скрипт.
(24) Да, тоже так считаю.
Был опыт с попыткой создания себе маленькой базы. Мучительно долго чистим таблицы. Потом добавляем нужные данные
Также видел очень интересный подход, на мой взгляд очень интересный и перспективный.
Под каждую задачу - своя маленькая ИБ (или набор баз, если задача интеграционная).
Постараюсь описать понятно и ничего не напутать.
Есть эталонная база, где минимум информации, чтобы можно было работать в режиме 1с предприятия.
Аналитик через спец. интерфейс быстро делает себе базу под каждую задачу (Пару кнопок):
(Делается копия эталонной базы и обновляется конфа с Git.)
Под конкретную задачу аналитик делает примеры документов, справочников и т.д. Задачу переводит на программиста. В задаче прямо конкретные ссылки на конкретные элементы (УФ это позволяют).
Пример: (для нового РН), при проведении документа (внешняя ссылка) должны появится такие-то движения. А при проведении документа (ссылка) этих движений быть не должно, т.к. такие-то условия не выполняются.
Программист делает копию этой подготовленной под задачу базы (пару кнопок в спец интерфейсе). Обновляет конфу своей базы из Gita и с ней работает.
После того, как закончил работу, выкладывает в GIT и переводит задачу на аналитика.
ИЗ ветки GIT-а по задаче (совпадает с номером задачи) делается cf-ник в Jenkins. Аналитик свою конфу обновляет этим cf-ником и проверяет. Пока не устранятся все ошибки, программист работает со своей базой и с веткой GIt. Как задача готова, она попадает в релиз. Релиз собирается опытным разрабом (или архитектором) из GIT. Тут м.б. конфликт веток и архитектор, иногда, может попросить опытного разраба устранить конфликты по своей задачке. Это бывает очень редко. Обычно архитектор сливает ветки GIT-а самостоятельно.
Через некоторое время ИБ аналитика и программиста удаляются. Обычно в имени используются номера задач. Так удобнее. (Можно и заменять, или продолжать в этой же, но всё это ведёт к непоняткам и ошибкам)
Оказалось важным, чтобы программист не делал разработку в базе аналитика. Часто были ошибки, т.е. в ИБ аналитика всё работает, а потом на проде ошибки (не всё попало в GIT).
И подготовка cf-ника аналитиком с помощью Jenkins из GIT-а также очень важна. Если программист cf-ник сделает со своей базы и аналитик обновиться с него, также м.б. ошибка в проде (опять не всё попало в GIT).
Ну и аналитик не должен работать с базой программиста.
Проблемы тоже были. Все базы программистов и аналитиков на одном сервере. И многие норовят делать копию с большой рабочей базы (а такая возможность у многих есть), чтобы не вбивать новые документы или элементы справочников. Также не используемые базы редко кто удаляет.
Так что сервер перегружен.
И постоянно приходиться следить, чтобы сотрудники подчищали за собой. Раз в неделю- две грозные письма со списком баз, и надо подтвердить, что база нужна. Если не подтвердил, то базу удалят.
Несмотря на наличие проблем, считаю такой подход самым правильным. Под каждую задачу - свой набор баз и окружения (например: БУХ+ЗУП + rabbit для задачки обмена бухии и зупа). Считай, что контейнер.
Был опыт с попыткой создания себе маленькой базы. Мучительно долго чистим таблицы. Потом добавляем нужные данные
Также видел очень интересный подход, на мой взгляд очень интересный и перспективный.
Под каждую задачу - своя маленькая ИБ (или набор баз, если задача интеграционная).
Постараюсь описать понятно и ничего не напутать.
Есть эталонная база, где минимум информации, чтобы можно было работать в режиме 1с предприятия.
Аналитик через спец. интерфейс быстро делает себе базу под каждую задачу (Пару кнопок):
(Делается копия эталонной базы и обновляется конфа с Git.)
Под конкретную задачу аналитик делает примеры документов, справочников и т.д. Задачу переводит на программиста. В задаче прямо конкретные ссылки на конкретные элементы (УФ это позволяют).
Пример: (для нового РН), при проведении документа (внешняя ссылка) должны появится такие-то движения. А при проведении документа (ссылка) этих движений быть не должно, т.к. такие-то условия не выполняются.
Программист делает копию этой подготовленной под задачу базы (пару кнопок в спец интерфейсе). Обновляет конфу своей базы из Gita и с ней работает.
После того, как закончил работу, выкладывает в GIT и переводит задачу на аналитика.
ИЗ ветки GIT-а по задаче (совпадает с номером задачи) делается cf-ник в Jenkins. Аналитик свою конфу обновляет этим cf-ником и проверяет. Пока не устранятся все ошибки, программист работает со своей базой и с веткой GIt. Как задача готова, она попадает в релиз. Релиз собирается опытным разрабом (или архитектором) из GIT. Тут м.б. конфликт веток и архитектор, иногда, может попросить опытного разраба устранить конфликты по своей задачке. Это бывает очень редко. Обычно архитектор сливает ветки GIT-а самостоятельно.
Через некоторое время ИБ аналитика и программиста удаляются. Обычно в имени используются номера задач. Так удобнее. (Можно и заменять, или продолжать в этой же, но всё это ведёт к непоняткам и ошибкам)
Оказалось важным, чтобы программист не делал разработку в базе аналитика. Часто были ошибки, т.е. в ИБ аналитика всё работает, а потом на проде ошибки (не всё попало в GIT).
И подготовка cf-ника аналитиком с помощью Jenkins из GIT-а также очень важна. Если программист cf-ник сделает со своей базы и аналитик обновиться с него, также м.б. ошибка в проде (опять не всё попало в GIT).
Ну и аналитик не должен работать с базой программиста.
Проблемы тоже были. Все базы программистов и аналитиков на одном сервере. И многие норовят делать копию с большой рабочей базы (а такая возможность у многих есть), чтобы не вбивать новые документы или элементы справочников. Также не используемые базы редко кто удаляет.
Так что сервер перегружен.
И постоянно приходиться следить, чтобы сотрудники подчищали за собой. Раз в неделю- две грозные письма со списком баз, и надо подтвердить, что база нужна. Если не подтвердил, то базу удалят.
Несмотря на наличие проблем, считаю такой подход самым правильным. Под каждую задачу - свой набор баз и окружения (например: БУХ+ЗУП + rabbit для задачки обмена бухии и зупа). Считай, что контейнер.
(27)
Непонятно, про что поподробнее рассказать.
Кстати был пост, критикующий подход удаления данных из полной копии, на который я и ответил, что согласен с критикой метода.
Т.е. взять огромную базу и постараться удалить не обязательные данные.
Минусы:
Если делать средствами 1С - то очень долго.
Если же средствами СУБД, то делается быстрее, но будут ошибки почти 100%.
И оно устаревает стремительно, если скриптом (обработкой) сделано.
И всё равно останется куча ненужной информации.
На мой взгляд, лучший подход:
К НИЧЕМУ добавить только очень НУЖНОЕ.
Даже обработка ЗагрузкаВыгрузкаДанныхXML позволяет это сделать и сохранить настройки для последующего использования.
Как пример: Выбрать документы за неделю, а все связанные данные ссылочного типа подтянутся. У Вас останутся только независимые РС.
Но есть нюанс для обработки. Метаданные должны быть одинаковы в обоих базах.
Там вроде бы можно грузить из конфигурации-предка, так сказать, (АрхивРабочейБазы) в конфигурацию-потомка: (ИБ_Разраб) . Но почти никогда без кучи ошибок не бывает.
Почти 100% алгоритм:
1) Из ИБ Архив выгружаем cf
2) Из ИБ_Разраб выгружаем cf (только при необходимости, если хранилище, то надо отключиться)
3) В ИБ_Разраб делаем "Загрузить конфигурацию из файла" и выбираем файл Архив.cf
4) Из ИБ Архив выгружаем обработкой нужные данные в xml. (Настройки сохраняем)
5) В ИБ_Разраб грузим обработкой данные из файла xml
6) Проверяем ИБ_Разраб, если что-то не так, то надо вернуться к п.4
7) В конфигурации ИБ_Разраб делаем "Загрузить конфигурацию из файла..." и выбираем файл ИБ_Разраб.cf. Или подключаемся к хранилищу и обновляемся с него.
9) Приятно удивляемся, как быстро всё работает и гордимся собой :)
Непонятно, про что поподробнее рассказать.
Кстати был пост, критикующий подход удаления данных из полной копии, на который я и ответил, что согласен с критикой метода.
Т.е. взять огромную базу и постараться удалить не обязательные данные.
Минусы:
Если делать средствами 1С - то очень долго.
Если же средствами СУБД, то делается быстрее, но будут ошибки почти 100%.
И оно устаревает стремительно, если скриптом (обработкой) сделано.
И всё равно останется куча ненужной информации.
На мой взгляд, лучший подход:
К НИЧЕМУ добавить только очень НУЖНОЕ.
Даже обработка ЗагрузкаВыгрузкаДанныхXML позволяет это сделать и сохранить настройки для последующего использования.
Как пример: Выбрать документы за неделю, а все связанные данные ссылочного типа подтянутся. У Вас останутся только независимые РС.
Но есть нюанс для обработки. Метаданные должны быть одинаковы в обоих базах.
Там вроде бы можно грузить из конфигурации-предка, так сказать, (АрхивРабочейБазы) в конфигурацию-потомка: (ИБ_Разраб) . Но почти никогда без кучи ошибок не бывает.
Почти 100% алгоритм:
1) Из ИБ Архив выгружаем cf
2) Из ИБ_Разраб выгружаем cf (только при необходимости, если хранилище, то надо отключиться)
3) В ИБ_Разраб делаем "Загрузить конфигурацию из файла" и выбираем файл Архив.cf
4) Из ИБ Архив выгружаем обработкой нужные данные в xml. (Настройки сохраняем)
5) В ИБ_Разраб грузим обработкой данные из файла xml
6) Проверяем ИБ_Разраб, если что-то не так, то надо вернуться к п.4
7) В конфигурации ИБ_Разраб делаем "Загрузить конфигурацию из файла..." и выбираем файл ИБ_Разраб.cf. Или подключаемся к хранилищу и обновляемся с него.
9) Приятно удивляемся, как быстро всё работает и гордимся собой :)
(27) Даже не знаю что подробнее. По метаданным создаете дерево взаимосвязей метаданных. Добавляете служебные (истории). На основе проекции метаданных на реальные таблицы бд создаете схему данных с поддержкой согласованного удаления. В этом случае при удалении записи документа SQL запросом будут удаляться согласованные данные.
Но это такой системный подход к разработке. Требующий много сил.
Если же для пары человек, то на мой взгляд, необходимо
1. добиться запуска 1с в режиме Предприятия с голого cf-ника.
С помощью обработок обновления все минимально необходимые элементы должны появляться при запуске.
Т.е. сделали новую пустую ИБ, загрузили в конфигурацию cf-ник рабочей базы. Стартанули -> режим 1с предприятия загрузился.
2. Далее из большой рабочей базы делаете выгрузку необходимых данных в файл. Например, все документы за последнюю неделю и весь справочник организаций + весь справочник пользователей. Можно даже обработкой ЗагрузкаВыгрузкаДанныхXML.
3. И той же обработкой грузите данные из файла себе в базу.
Про 1-й пункт идея у меня возникла потом.
Я же делал так: нашёл старую маленькую базу из архива (за несколько лет назад), обновил cf-ник до рабочей версии, потом, неожиданно для меня, долго и упорно добивался чтобы оно в 1сПредприятии запускалось без ошибок.
Далее в цикле:
В ИБ последней копии рабочей в обработке ЗагрузкаВыгрузкаДанныхXML делал файл выгрузки с документами за последнюю неделю со связанными объектами. Настройку сохранял.
В подготовленную базу подгружал этот файл той же обработкой. Потом проверял и смотрел. Недостающие битые ссылки, РС и т.д. опять добавлял в настройки выгрузки и выгружал заново.
И оно всё-таки заработало. Маленькая быстрая база с актуальными данными. Но больше я не решился чистить. Так в эту базу свежие данные и добавлял периодически.
Если же для пары человек, то на мой взгляд, необходимо
1. добиться запуска 1с в режиме Предприятия с голого cf-ника.
С помощью обработок обновления все минимально необходимые элементы должны появляться при запуске.
Т.е. сделали новую пустую ИБ, загрузили в конфигурацию cf-ник рабочей базы. Стартанули -> режим 1с предприятия загрузился.
2. Далее из большой рабочей базы делаете выгрузку необходимых данных в файл. Например, все документы за последнюю неделю и весь справочник организаций + весь справочник пользователей. Можно даже обработкой ЗагрузкаВыгрузкаДанныхXML.
3. И той же обработкой грузите данные из файла себе в базу.
Про 1-й пункт идея у меня возникла потом.
Я же делал так: нашёл старую маленькую базу из архива (за несколько лет назад), обновил cf-ник до рабочей версии, потом, неожиданно для меня, долго и упорно добивался чтобы оно в 1сПредприятии запускалось без ошибок.
Далее в цикле:
В ИБ последней копии рабочей в обработке ЗагрузкаВыгрузкаДанныхXML делал файл выгрузки с документами за последнюю неделю со связанными объектами. Настройку сохранял.
В подготовленную базу подгружал этот файл той же обработкой. Потом проверял и смотрел. Недостающие битые ссылки, РС и т.д. опять добавлял в настройки выгрузки и выгружал заново.
И оно всё-таки заработало. Маленькая быстрая база с актуальными данными. Но больше я не решился чистить. Так в эту базу свежие данные и добавлял периодически.
Размер достаточно внушительный. В любом случае нужно проанализировать какие таблицы больше всего занимают места, чтобы в будущем этим управлять.
1й вариант: РИБ. Создать начальный образ с минимальным набором НСИ (без документов и регистров) и далее дозаполнить обменом что нужно.
2й вариант. Уже упоминали ранее чистая база с актуальным cf. Риск конечно вообще не запустить есть)
3й вариант. Копия базы и последующая очистка всех больших таблиц. Документы можно оставить только свежие. Неактуальными данными можно и пренебречь вплоть до битых ссылок.
1й вариант: РИБ. Создать начальный образ с минимальным набором НСИ (без документов и регистров) и далее дозаполнить обменом что нужно.
2й вариант. Уже упоминали ранее чистая база с актуальным cf. Риск конечно вообще не запустить есть)
3й вариант. Копия базы и последующая очистка всех больших таблиц. Документы можно оставить только свежие. Неактуальными данными можно и пренебречь вплоть до битых ссылок.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот