Интегратор исчез — что делать: план восстановления проекта
Представьте ситуацию. Звонит нам торговая компания из Бутово, у них 28 рабочих мест, и это просто катастрофа: три недели назад их подрядчик-интегратор пропал, совсем не отвечает. Единственный инженер уехал, телефон заблокирован, и — вишенка на торте — никто не помнит пароль от контроллера домена. А через восемь дней ещё и сертификат на онлайн-кассе истекает! Звучит как анекдот, правда? Но, к сожалению, это реальность, с которой мы в ITfresh сталкиваемся постоянно, где-то 4-5 раз в год. Ниже я расскажу вам, как мы справляемся с такими проектами, шаг за шагом: что делаем в первые 24 часа, как возвращаем контроль над доступом, чем замещаем утерянную документацию, и во сколько это всё обойдётся.
Откуда берутся истории «интегратор исчез»
За пятнадцать лет в этой сфере я насмотрелся всякого. Но чаще всего, когда речь заходит о потерянном IT-контроле, это сводится к четырём основным сценариям. Итог, увы, всегда один: компания остаётся без инженера, а что самое критичное — без жизненно важных доступов.
Сценарий 1. Подрядчик-одиночка ушёл
Пожалуй, это самый частый сценарий. Только представьте: три года в компании работал «один сильный сисадмин». Он, как говорится, держал всю IT-инфраструктуру на себе. А потом — бах! Человек просто исчезает. Заболел? Уехал за границу? Или, может, получил крутое предложение в банке? Неважно. Главное, что на связь он больше не выходит. И что самое неприятное? Документации, конечно, никакой нет! Ведь «всё было у него в голове», как любят говорить. Только в этом, 2025 году, я лично брался за шесть подобных проектов в Москве и Подмосковье.
Сценарий 2. Маленькая компания закрылась
А иногда бывает и такая история. Небольшая команда подрядчика, всего 3-4 человека, просто разваливается. Причины? Да какие угодно: бурные ссоры между партнёрами, внезапные налоговые проверки, или потеря крупного клиента. Конец один: заказчику никто не звонит, договор формально всё ещё действует, но доступы буквально «зависают в воздухе». Просто некому их передать. В 2025 году, между прочим, мы уже сталкивались с двумя такими случаями. И обе компании были не маленькие – по 30-40 рабочих мест.
Сценарий 3. Конфликт по деньгам
Вот ещё один вариант. Клиент, например, должен подрядчику 200-300 тысяч рублей. И подрядчик что делает? Правильно, уходит в полный «режим тишины». Перестаёт отвечать на звонки, игнорирует запросы, ни одна заявка не закрывается. Договор вроде как есть, подписан, но по факту никакой поддержки вы не получаете. В таких историях нам сначала приходится подключать юристов, а только потом, когда юридическая часть более-менее прояснится, мы берёмся за технические вопросы.
Сценарий 4. Целевой саботаж
Этот сценарий, пожалуй, самый редкий, но, поверьте, и самый мерзкий. Слава богу, случается такое не чаще, чем раз в 2-3 года. Что происходит? Уходящий подрядчик, словно назло, специально меняет все пароли. Стирает аккаунты из облачных сервисов. А бывает, ещё и переписывает регистратор домена на себя! Это уже не шутки. Тут, конечно, сразу в дело вступает статья 274 Уголовного кодекса. Начинается оперативная работа с полицией. Но в эти чисто юридические дебри я сейчас углубляться не стану, это отдельный разговор.
Что интересно, несмотря на все эти ужасные истории, алгоритм восстановления контроля всегда один и тот же. Разница лишь во времени реакции. Если мы сталкиваемся с очевидным саботажем, то действуем моментально, буквально за считанные часы. А когда это просто «режим тишины» от подрядчика, у нас есть запас в несколько дней.
Первые 24 часа: что я делаю в день звонка
Когда мне на телефон звонит руководитель какой-нибудь торговой компании и, едва сдерживая панику, почти кричит: «Е.С., наш сисадмин пропал! Что нам теперь делать?!», мой план на первые 24 часа всегда чёткий и отработанный. Выглядит он так:
Час 1-2. Заморозка периметра
- Сменить пароль учётки Domain Admin и любых других учёток с правами «уровня бога»;
- Срочно отключите все VPN-сертификаты и L2TP/IKEv2-учётки, которыми когда-либо пользовался ваш бывший подрядчик. Это первый шаг к безопасности.
- Или вот ещё: не забудьте заблокировать на роутере абсолютно все правила типа «remote access for IT», которые были настроены с доверенных IP-адресов бывшего подрядчика. Это критично!
- Если у вас MikroTik, обязательно отключите доступ к порту SSH и Winbox со стороны интернета. Оставьте его доступным только из вашей локальной сети — это стандарт безопасности.
- И, конечно, смените пароли административных панелей абсолютно всех публичных сервисов. Речь идёт об SSL VPN на вашем UTM, панели почтового сервера, личном кабинете хостера и, конечно, регистраторе домена. Не пропустите ни один!
Час 2-4. Инвентаризация по горячим следам
Первым делом я мчусь в офис клиента, а оттуда — прямиком в серверную. Моя главная задача? Описать абсолютно всё, что там вижу. Причём именно своими руками. Вот минимальный список того, что я скрупулёзно заношу в свой блокнот:
# Серверы
- HPE ProLiant DL360 Gen10, серийник CZ12345ABC, ILO 192.168.1.5
- hostname VHOST01, гипервизор VMware ESXi 7.0u3
- на нём: DC01, FS01, 1C-APP01, 1C-DB01
- Synology RS1221+, MAC 00:11:32:XX:XX:XX, IP 192.168.1.10
- бэкапы, файловые шары, время восстановления неизвестно
# Сеть
- MikroTik CCR2004-1G-12S+2XS, IP 192.168.1.1
- Коммутатор HPE Aruba 2530-24G, IP 192.168.1.2
- Wi-Fi: UniFi U6-LR (3 шт.), контроллер CloudKey 192.168.1.3
# Внешний контур
- Домен company.ru — у регистратора REG.RU, доступ ?
- SSL-сертификаты: на сайте Let's Encrypt, на сервере 1С от КриптоПро
- Почта: Яндекс 360 Бизнес, админ-учётка ?
Мой блокнот — это фундамент для всей последующей работы, без него никуда. Пока один инженер обходит всю инфраструктуру, я не теряю времени. Сразу же связываюсь с бухгалтерией. Зачем? Чтобы найти любые старые письма от хостеров и регистраторов доменов. Там, поверьте, зачастую скрываются самые актуальные контакты!
Час 4-8. Поиск точек владения
А вот что меня волнует больше всего: где у клиента остался реальный административный контроль, а где он по факту всё ещё у того самого исчезнувшего подрядчика? Чтобы это быстро прояснить, я всегда составляю простую табличку. В ней три колонки: 'что' (это может быть сервер, сервис, домен), 'у кого' (кто этим управляет) и 'что делать' (какие шаги предпринять).
Ресурс | Владелец | Действие
--------------------|---------------------|------------------
DNS-зона company.ru | reg.ru, аккаунт ? | Восстановить через паспорт директора
SSL-сертификат сайт | Let's Encrypt | OK, перевыпустим автоматически
Сертификат на кассу | КриптоПро, носитель | Найти токен в сейфе, перевыпустить
Microsoft 365 | tenant ушедшего ИП | Перенос tenant на ООО заказчика
Яндекс 360 | OK, на ООО | Сменить пароль admin
Битрикс24 | OK, на ООО | Сменить пароль и 2FA admin
1C 8.3 | KEY-USB у клиента | OK
Камеры Hikvision | Hik-Connect ? | Сбросить регистратор, привязать заново
ИБП APC | прошивка дефолт | Сменить пароль APC NMC
К концу первого дня у меня на руках уже есть полная карта владения IT-активами. И, конечно, чёткий список приоритетов: что нужно закрыть первым делом, а что подождёт до второго.
День 2-3: возврат контроля над доменом и AD
Ну вот мы и подошли к самому щекотливому вопросу: Active Directory. Помните ту торговую компанию из Бутово, о которой я говорил в самом начале? У них был всего один контроллер домена — DC01 на Windows Server 2019. А в качестве гипервизора — старенький Hyper-V на Windows Server 2016. И пароль Domain Admin, вы ведь догадываетесь, никто, естественно, не помнит! Так что же мы делаем в таких ситуациях?
Сброс пароля локального админа гипервизора
Часто бывает, что на физическом сервере есть встроенный Windows-логин или какой-нибудь дефолтный типа «admin/admin». Но если это не наш случай, то я не пасую. Запускаюсь с PE-носителя (например, SystemRescue), монтирую системный диск, а потом с помощью утилиты chntpw сбрасываю пароль локального администратора прямо на хосте. Вся процедура, учитывая все необходимые перезагрузки, занимает обычно минут 30-40. Не больше.
Сброс пароля Domain Admin через DSRM
На контроллере домена есть специальная офлайн-учётка DSRM (Directory Services Restore Mode). И вот её пароль, как правило, подрядчики почему-то не записывают нигде. Но если вдруг, совершенно случайно, нам повезёт и пароль всё-таки найдётся — тогда я просто вхожу в DSRM-режим.
# На DC, перезагружаемся в Safe Mode With Networking
bcdedit /set safeboot dsrepair
shutdown /r /t 0
# В DSRM логин — .\Administrator с DSRM-паролем
# Дальше сбрасываем пароль доменного admin через ntdsutil
ntdsutil
set instance to NTDS
ifm
create full c:\dump
quit
quit
А что, если DSRM-пароль тоже пропал? Такое, кстати, случается в 60% случаев! Тогда мы переходим к плану B: либо правим NTDS офлайн через esedbexport и chntpw, либо поднимаем новый контроллер домена прямо из бэкапа. Это добавит ещё 4-6 часов к общему времени восстановления.
В том кейсе нам просто фантастически повезло! Главный бухгалтер, как оказалось, бережно хранила в сейфе тот самый "заветный конверт" с пометкой «На случай Х». И что там было? Угадайте! Там лежал и DSRM-пароль, и, что уж совсем удача, админский пароль от гипервизора. Выяснилось, что наш предыдущий подрядчик отдал их год назад, ещё при подписании договора, но, разумеется, про конверт этот никто и не вспоминал, пока не прижало.
Подъём второго DC немедленно
В тот же день я, не теряя ни минуты, сразу разворачиваю второй контроллер домена. Важно, что уже на отдельной виртуалке. Команда для этого, кстати, совсем стандартная:
Install-WindowsFeature -Name AD-Domain-Services,DNS -IncludeManagementTools
$DSRM = ConvertTo-SecureString "ITfresh!DSRM2026" -AsPlainText -Force
$Cred = Get-Credential -Message "Domain Admin"
Install-ADDSDomainController `
-DomainName "corp.company.ru" `
-InstallDns:$true `
-Credential $Cred `
-SafeModeAdministratorPassword $DSRM `
-SiteName "Default-First-Site-Name" `
-Force:$true
# Проверка репликации
repadmin /replsummary
repadmin /showrepl
Представьте: до нашего прихода у этой компании с её 28 рабочими местами был всего один контроллер домена. Умри он — и всё, офис парализован на сутки, а то и дольше. С двумя DC такой кошмарный сценарий исключён.
День 4-5: смена паролей и инвентарь учёток
Моя задача номер один после этого? Вытащить вообще всё: полный-преполный список доменных учёток, локальных админов на каждом сервере, все сервисные аккаунты. Ну и, конечно же, общие почтовые ящики!
# Все доменные учётки
Get-ADUser -Filter * -Properties LastLogonDate, PasswordLastSet, Enabled |
Select-Object SamAccountName, Enabled, LastLogonDate, PasswordLastSet |
Export-Csv -Path "C:\audit\users.csv" -Encoding UTF8 -Delimiter ";"
# Сервисные аккаунты
Get-ADUser -Filter 'PasswordNeverExpires -eq $true' -Properties PasswordNeverExpires |
Select-Object SamAccountName, Description |
Export-Csv -Path "C:\audit\service.csv" -Encoding UTF8 -Delimiter ";"
# Учётки в группе Domain Admins
Get-ADGroupMember "Domain Admins" |
Get-ADUser -Properties LastLogonDate |
Select-Object SamAccountName, LastLogonDate |
Export-Csv -Path "C:\audit\admins.csv" -Encoding UTF8 -Delimiter ";"
# Локальные админы серверов через PSRemoting
Invoke-Command -ComputerName (Get-ADComputer -Filter 'OperatingSystem -like "*Server*"').Name `
-ScriptBlock { Get-LocalGroupMember "Administrators" } |
Select-Object PSComputerName, Name, ObjectClass
В кейсе торговой компании нашлось:
- Мы обнаружили 4 неактивные учётки бывших сотрудников, которые почему-то не отключались целый один-два года. Это же потенциальная угроза!
- Также мы нашли 3 сервисных аккаунта, у которых установлен флаг PasswordNeverExpires. Для нашей практики это крайне нестандартно и требует внимания!
- 1 учётка
ITSupportс правами Domain Admin и last logon вчера — это и был ушедший подрядчик; - 2 учётки
backup-svcиmonitoring-svcс неизвестным паролем — пришлось пересоздавать.
А что потом? Мы массово меняем пароли для каждой привилегированной учётки. И, конечно, безжалостно отключаем все "мёртвые души" — аккаунты сотрудников, которые давно уже не работают.
День 6-7: почта, облачные сервисы, сторонние API
После того, как разобрались с Active Directory, что дальше? Самое уязвимое место — это, как правило, публичные сервисы. Вот что мы увидели у одной торговой компании из Бутова:
- Microsoft 365 tenant — числился на ИП ушедшего инженера. Это типичная ловушка: подрядчик регистрирует tenant на себя, потом «не отдаёт» при расторжении. Я отправил запрос в Microsoft Support, через 4 рабочих дня tenant перевели на юрлицо заказчика по уставным документам и доверенности директора;
- Яндекс 360 Бизнес — здесь было проще, организация привязана к ИНН компании, я через директора восстановил пароль admin@yandex и сменил его на длинный из менеджера паролей;
- Битрикс24 — admin-учётка с почтой ушедшего сотрудника. Через техподдержку Битрикс24 восстановили доступ через паспорт директора-основателя за 2 рабочих дня;
- МойСклад — учётка владельца числилась на бухгалтера, она просто залогинилась и сменила пароли;
- Эквайринг и онлайн-касса — здесь была минимальная драма: сертификат КриптоПро для отправки чеков в ОФД истекал через 8 дней. Перевыпустили срочно через УЦ за 12 000 рублей;
- Telegram-боты для уведомлений склада — токен у подрядчика, мы его ротировали через @BotFather под учёткой генерального.
День 8-9: документация и регламенты
Обычно к этому моменту я уже полностью контролирую всю инфраструктуру: доступы перевыпущены, мониторинг настроен. Кажется, финиш? Но это ещё рано радоваться! Проект совсем не закрыт, потому что без чёткой документации через год мы опять столкнёмся с тем, что «всё в голове». Поэтому я разворачиваю либо BookStack, либо Notion — здесь уже заказчик сам выбирает, что ему удобнее — и за два дня предельно подробно описываю всё-всё-всё:
- Сетевая карта. Схема всех VLAN, IP-плана, серверов, точек Wi-Fi, камер, принтеров. Делаю в Draw.io, экспортирую в PNG и SVG;
- Реестр доступов. Все учётные записи с указанием, на кого зарегистрированы, где хранятся пароли, у кого 2FA;
- Регламенты на типовые операции. Заведение нового сотрудника (пошагово), увольнение, выдача нового ноутбука, восстановление файла из бэкапа;
- SLA. Время реакции по приоритетам инцидентов, контакты команды ITfresh, эскалация на руководителя;
- Plan of action на типичные аварии. Что делать, если упал интернет; что делать, если упал 1С; что делать, если истёк сертификат кассы; что делать, если зашифровал шифровальщик.
Все-все пароли я моментально выгружаю в Bitwarden Vaultwarden. Важный нюанс: он ОБЯЗАТЕЛЬНО разворачивается на собственном сервере клиента, а не где-то у нас. Мы принципиально не пользуемся общим хранилищем подрядчика. Знаете, почему? Потому что именно это, по нашему опыту, и становится главной головной болью и первопричиной большинства проблем.
Что мы внедряем сразу, чтобы история не повторилась
Мы? Мы не просто приходим, всё чиним и испаряемся! Ни в коем случае. После нас у клиента остаются целых три полезных "подарка", которых, скорее всего, раньше и в помине не было:
1. Vaultwarden у заказчика
Во-первых, это, конечно, наш self-hosted менеджер паролей. Мы поднимаем его в Docker, обычно прямо рядом с уже существующими сервисами. Хотите знать самое главное? Все-все пароли остаются только у ВАС, у клиента. Да, у ITfresh есть своя рабочая учётка, но она с очень ограниченным доступом и только к нужным нам секциям. Истинный владелец и полный хозяин этого хранилища — только сам заказчик. Если вдруг наши пути разойдутся, никаких проблем: вы останетесь со всеми своими ключами в руках.
# docker-compose.yml для Vaultwarden
services:
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
restart: always
environment:
DOMAIN: "https://passwords.company.ru"
SIGNUPS_ALLOWED: "false"
ADMIN_TOKEN: "ОченьДлинныйТокенДляAdminPanel2026"
WEBSOCKET_ENABLED: "true"
DATA_FOLDER: /data
volumes:
- ./data:/data
ports:
- "127.0.0.1:8088:80"
Перед самим Vaultwarden мы ставим nginx с Let's Encrypt — так безопаснее. А доступ к админ-панели? Его полностью закрываем, разрешая вход только с IP-адресов вашего офиса.
2. Уведомления в Telegram
Второй пункт — это наш мини-бот. Он круглосуточно шлёт алерты прямо в группу директора и сисадмина. Какие именно? Вот несколько примеров: упал контроллер домена (DC), истекает срок действия важного сертификата, диск на Synology забит уже на 85%, ночной бэкап не завершился, или fail2ban забанил какой-то подозрительный IP-адрес.
#!/bin/bash
# /opt/itfresh/check_certs.sh
DOMAINS="company.ru ofd.company.ru passwords.company.ru"
TOKEN="$(cat /opt/itfresh/.tg_token)"
CHAT="$(cat /opt/itfresh/.tg_chat)"
for D in $DOMAINS; do
EXP=$(echo | openssl s_client -servername $D -connect $D:443 2>/dev/null \
| openssl x509 -noout -enddate | cut -d= -f2)
EPOCH=$(date -d "$EXP" +%s)
NOW=$(date +%s)
DAYS=$(( (EPOCH - NOW) / 86400 ))
if [ $DAYS -lt 14 ]; then
curl -s "https://api.telegram.org/bot${TOKEN}/sendMessage" \
-d "chat_id=${CHAT}" \
-d "text=SSL ${D} истекает через ${DAYS} дн."
fi
done
Мы ставим этого бота в cron — он срабатывает каждый день ровно в 9:00 утра. Казалось бы, мелочь, да? Но только в 2026 году эта система спасла трёх наших клиентов от внезапно истёкших сертификатов!
3. Договор с пунктом «передача дел»
И последнее, но не менее важное. Загляните в любой наш договор с ITfresh. Вы там всегда найдёте очень чёткий пункт, где черным по белому прописано: «При расторжении договора подрядчик в течение 30 рабочих дней передаёт заказчику актуальную документацию, актуальные пароли в защищённом виде, а также полный перечень используемых сторонних сервисов с указанием владельца аккаунта». Что это значит для вас? Это юридически обязывает нас провести полноценную и прозрачную передачу всех дел. Клиент, благодаря этому, всегда чувствует себя на 100% защищённым.
Контр-нарратив: почему смена интегратора часто не решает проблему
Давайте будем честны: когда говорят, что «интегратор куда-то исчез», в половине случаев причина, увы, кроется на стороне самого заказчика. Это неприятная правда. Зачастую картина выглядит так: нерегулярные платежи, внедоговорные требования, затяжка с продлением подписки, а иногда и вовсе — инженеру просто не дают админ-доступ, когда он реально нужен для работы! Что происходит потом? Через год-два специалист выгорает и уходит. Вы меняете подрядчика, а через 18 месяцев история повторяется. Неужели это тупик?
Мы всегда предельно откровенны на первой встрече. Поверьте, половина успеха в IT-аутсорсинге — это адекватный заказчик. Ну, какой подрядчик сможет выдержать, если у вас в компании принято звонить инженеру в одиннадцать вечера в воскресенье с воплями: «У меня дома принтер не печатает!»? А если к этому ещё и оплату на три месяца задерживать? Тут уж, как ни крути, никто долго не протянет. Поэтому, прежде чем кидаться на поиски нового интегратора, любому клиенту полезно честно посмотреть: а как он сам выстраивает отношения?
FAQ: что чаще всего спрашивают клиенты
Что делать в первые 24 часа после ухода интегратора?
С чего начинать? Сразу же меняйте пароль администратора домена — это самое главное! Обязательно отключите весь VPN-доступ для всех учёток бывшего подрядчика. И не забудьте забрать ключи: от офиса, от серверной — вообще всё. А дальше что? Проверьте наличие резервного контроллера домена. Самое важное: убедитесь, что бэкапы хотя бы за прошлые сутки доступны и их можно прочитать. Только когда весь этот список выполнен, можно спокойно выдохнуть и уже начинать искать нового подрядчика.
Может ли уходящий подрядчик заблокировать вашу инфраструктуру?
Может ли бывший подрядчик нанести вред? Технически — да, вполне. Если у человека есть админ-доступ к таким критическим точкам, как домен, гипервизор, регистратор домена, BitLocker-ключи или почтовый сервер, он запросто может оставить после себя «мину» или перевести все лицензии на свой личный аккаунт. Это очень неприятно! Но вот юридически — нет, такие действия попадают напрямую под статью 274 УК РФ. На нашей практике, кстати, с реальным саботажем мы сталкиваемся редко, лишь в одном случае из десяти. Чаще всего подрядчик просто перестаёт брать трубку. Это не саботаж, это скорее… просто тишина.
Сколько стоит у ITfresh подбор после ушедшего интегратора?
Сколько стоит привести всё в порядок? За аудит и разработку чёткого плана восстановления вы заплатите 30-40 тысяч рублей. Это примерно один-два дня работы нашего инженера. Полное же восстановление контроля над вашей системой, а затем и переход на наш аутсорсинг, обойдётся от 80 до 150 тысяч рублей. Тут всё зависит от текущего состояния вашей инфраструктуры. Для примера: торговым компаниям с 25-50 рабочими местами (РМ) на это требуется, как правило, 9-12 полных рабочих дней. Но в реальности, с учётом всех нюансов, процесс может растянуться и на две-три календарные недели.
Что делать, если у подрядчика были все мейл-сертификаты и SSL-ключи?
Мой личный совет: перевыпускайте абсолютно всё! Не жалейте времени. SSL-сертификаты — их можно выпустить заново через Let's Encrypt или запросить у того же CA. S/MIME-сертификаты ваших сотрудников? Отозвать через УЦ и выдать новенькие. А как быть с API-токенами сторонних сервисов? CRM, телефония, эквайринг — неважно что, но их нужно перевыпускать только с нуля. Да, такая работа добавит ещё 2-3 дня к общему сроку. Но поверьте, это единственный по-настоящему честный, надёжный способ закрыть вообще все возможные лазейки в безопасности.
Как выбрать нового подрядчика, чтобы история не повторилась?
Какие пункты обязательно должны быть в вашем договоре? Первое: чёткое обязательство передавать клиенту абсолютно все пароли в его собственном Bitwarden/KeePass-хранилище. И не просто передавать, а проводить контрольную сверку раз в месяц! Второе: полноценное SLA, где детально прописана процедура передачи дел в случае расторжения. На это должно быть отведено 30 рабочих дней, и, конечно, с обязательной документацией. Третье: доступы к регистратору домена и вообще ко всем облачным сервисам всегда должны быть оформлены на учётке заказчика. Подрядчику же предоставляйте только делегированный доступ. И, ради бога, наш самый горячий совет: никогда не нанимайте подрядчика, если у него в команде всего один человек! Это не просто риск, это настоящая бомба замедленного действия под вашу инфраструктуру.
Итог
Что делать, если бывший подрядчик просто исчез? Перехват проекта — это не магия и не колдовство. Это чёткая, отработанная нами методика. Обычно она занимает 9 рабочих дней инженера, включает большой чек-лист из 40 пунктов и требует строгого соблюдения базовых правил безопасности. Но самое-самое главное — действовать нужно максимально быстро, буквально в первые 24 часа! Что именно? Срочно сменить все пароли, отключить VPN, провести полную инвентаризацию активов. А всё, что последует за этим, — это уже полноценный технический проект на две-три недели. Если вы сейчас столкнулись именно с такой бедой, просто напишите мне. Я приеду на первичный аудит прямо в течение этого же рабочего дня.
Похожая задача в вашей компании?
Расскажите мне, что у вас происходит прямо сейчас — я пришлю вам план работ и оценку стоимости в течение этого же рабочего дня.
Написать в Telegram или +7 903 729-62-41
Семёнов Е.С., руководитель ITfresh
