itforprof

В современном мире, где мониторинг веб-сайтов и проверка SSL-сертификатов становятся всё более сложными, простого «пинга» сервера уже недостаточно для определения состояния сайта. Балансировщики нагрузки, HTTPS, различные версии HTTP и нюансы сертификатов требуют более продвинутых инструментов мониторинга.

Компания Checkmk представила check_httpv2 новую, быструю и мощную реализацию мониторинга веб-сайтов и HTTPS-сервисов с открытым исходным кодом. Вместе с ним представлен инструмент check_cert для детальной проверки SSL-сертификатов.

Почему важен мониторинг веб-сайтов и SSL-сертификатов?

Ранее используемые решения, такие как check_http из мира Nagios, служили нам более 20 лет, но теперь они не справляются с современными задачами. Проверка сертификата и кода ответа требовала двух отдельных запросов, а о продвинутых сценариях, таких как контроль конкретных криптосетей и издателя сертификата, можно было только мечтать. Теперь все эти возможности доступны:

• Мониторинг сайта в один запрос.

• Контроль остаточного срока действия сертификата.

• Проверка используемых алгоритмов шифрования.

• Возможность использования в Checkmk, в любом совместимом с Nagios решении или как отдельный CLI-инструмент.

От check_http к check_httpv2

Старый плагин check_http, появившийся ещё в конце 90-х вместе с Nagios, пережил множество обновлений и до сих пор используется во многих системах.
Однако его возраст даёт о себе знать:

• Для проверки кода ответа HTTP и срока действия SSL-сертификата нужны были два отдельных запроса.

• Ряд полезных функций, которые сегодня стали стандартом, просто отсутствовал.

• Поддержка разных версий разошлась — плагин существует в вариантах Monitoring Plugins и Nagios Plugins, а объединить усилия не получилось.

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

Rust для мониторинга веб-сайтов

Для разработки нового инструмента разработчики Checkmk выбрали язык программирования Rust. Он быстрый, безопасный и удобный в поддержке. Python проигрывал по производительности, а C/C++ — по удобству поддержки.

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

Мониторинг сайтов с check_httpv2

Check_httpv2 можно использовать не только внутри Checkmk, но и как отдельный инструмент в терминале. Это позволяет тестировать новый плагин без перестройки всей инфраструктуры мониторинга.

Сборка своими руками

На свежей Ubuntu 24.04 выполняется следующим образом:

sudo apt install cargo libssl-dev pkg-config git

cd ~/git

git clone https://github.com/Checkmk/checkmk.git

cd checkmk/packages/site/check-http/

cargo check --release

cargo build --release

cd ../target/release/

Для проверки сертификатов путь будет почти таким же — просто вместо check-http используем check-cert.

Первая проверка сайта

В Checkmk всё настраивается через меню:

Настройка → Службы → HTTP, TCP, электронная почта… → Сеть → Проверить веб-службу HTTP.

Там указываем имя и URL сайта, который хотим отслеживать, и через пару кликов получаем в мониторинге статус веб-сервера.

Если хочется протестировать автономно, в терминале это выглядит так:

./check_httpv2 --url https://www.checkmk.com

В ответ получаем:

• Код состояния (200 OK, 301 Redirect и т. д.).

• Факт наличия или отсутствия HTTPS.

• Перенаправления, если они есть.

Проверка срока действия сертификата

Хотите, чтобы система предупредила за 40 дней до истечения сертификата и прислала CRIT за 20 дней? Легко:

./check_httpv2 --url https://www.checkmk.com --certificate-levels 40,20

Теперь у вас всегда будет запас времени на продление сертификата.

Check_cert: когда «валидный» сертификат — ещё не гарантия безопасности

Многие администраторы считают, что если SSL-сертификат валиден, то всё в порядке. Но это не всегда так. Представьте атаку типа man-in-the-middle: сертификат действителен, но выдан совершенно другим центром сертификации, чем ваш обычный. Или сайт вроде бы использует TLS 1.3, но с небезопасными алгоритмами шифрования.

Здесь в игру вступает check_cert — инструмент для детальной проверки сертификатов, созданный с нуля на Rust и интегрированный в Checkmk.

Программа check_cert обладает широким спектром функций для детального анализа сертификатов:

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

• Контроль за максимальным сроком действия сертификата.

• Анализ алгоритмов подписи и длины ключа.

• Проверка информации о центре сертификации (issuer) и имени субъекта (subject).

• Гибкость использования: может быть интегрирована как плагин в системы, совместимые с Nagios, или применяться как автономная утилита с командной строкой CLI.

Пример мощной проверки

./check_cert --url checkmk.de --port 443 \
--not-after 3456000 1728000 \
--max-validity 90 \
--serial 05:0e:50:04:eb:b0:35:ad:e9:d7:6d:c1:0b:36:d6:0e:33:f1 \
--signature-algorithm 1.2.840.10045.4.3.2 \
--issuer-o "Let's Encrypt" \
--pubkey-algorithm rsa \
--pubkey-size 256

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

Массовый мониторинг сайтов в Checkmk

Управление несколькими сайтами (3–5) не вызывает сложностей, однако при работе с более чем 200 сайтами ручная настройка каждого правила становится утомительной задачей.
Checkmk предлагает два эффективных метода для решения этой проблемы:

1. Группировка конечных точек (endpoints) в одном правиле

В конфигурации check_httpv2 можно задать список URL-адресов, для которых будет применяться общая базовая настройка. При этом для каждого сайта можно определить индивидуальные параметры, переопределяющие общие.
Например, можно создать одно правило для домена, поддоменов и страницы с политикой конфиденциальности, задав для каждого адреса уникальные пороги времени ответа.

2. Использование макросов ($HOSTNAME$)

Вместо конкретного URL в правиле используется переменная $HOSTNAME$. Если в папке хостов присутствует example.com, проверка автоматически выполняется по адресу https://example.com.

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

Анализ работы балансировщиков нагрузки с check_httpv2

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

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

URL to test: https://example.com/
Stopped on redirect to: https://www.example.com/ (changed IP) (!)
Status: 301 Moved Permanently

Для проверки конкретного сервера в обход балансировщика используется параметр –server:

./check_httpv2 --url example.com --server 192.0.2.73

Это позволяет выполнить тестирование напрямую по IP-адресу и быстро определить работоспособность бэкенда. В Checkmk эта настройка осуществляется через опцию «Подключение к физическому хосту». Не следует путать это с прокси, для которого предусмотрен отдельный параметр –proxy-url.

Таким образом, в одном правиле можно задать проверку основного домена и каждого IP-адреса за балансировщиком. Это особенно полезно для диагностики проблем с производительностью, когда необходимо определить, какой сервер вызывает неполадки.

Проверка содержимого сайта с check_httpv2

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

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

Например, можно проверить наличие ключевого слова на странице с авторизацией:

./check_httpv2 \

--auth-user peter \

--auth-pw-plain spiderman \

--body-regex '(?m)check(_)?mk'

В этом случае плагин проверит наличие строк checkmk или check_mk в HTML-коде, даже если страница защищена паролем.

Сценарии использования включают:

• Убедиться, что на главной странице присутствует важный элемент (например, кнопка «Купить»).

• Следить за появлением определённых слов во внутреннем портале компании (например, «реструктуризация» или «срочное уведомление»).

• Мониторить наличие баннеров или акций на e-commerce сайте.

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

Тесты производительности с hyperfine

Обычная проверка check_httpv2 предоставляет время отклика, но для серьёзного анализа этого недостаточно, особенно если за сайтом стоят балансировщики, прокси или CDN. В таких случаях на помощь приходит инструмент hyperfine — лёгкий, но мощный бенчмарк для команд CLI.

Hyperfine позволяет многократно запускать команду и вычислять среднее время её выполнения.
Эти инструменты позволяют:

• обнаружить резкие изменения в скорости ответа;

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

• оценить влияние изменений в конфигурации.

Пример использования инструмента hyperfine:

hyperfine --warmup 2 -r 20 './check_httpv2 --url https://checkmk.com'

• --warmup 2 — два предварительных запуска для «прогрева», чтобы исключить влияние кэша на результаты;

• -r 20 — проведение 20 измерений.

• По завершении hyperfine предоставляет среднее время отклика, стандартное отклонение и диапазон значений.

Пример результата:

Time (mean ± sigma): 124.6 ms ± 9.8 ms

Range (min ... max): 108.3 ms ... 139.9 ms (20 runs)

Такой подход позволяет отслеживать стабильность отклика и быстро реагировать на снижение производительности.

Итоги и перспективы развития check_httpv2 и check_cert

Уже сейчас check_httpv2 и check_cert способны решать большинство задач современного мониторинга:

• проверка доступности и скорости работы сайта;

• контроль сертификатов (срок действия, валидность, алгоритмы, издатель);

• работа с несколькими сайтами в рамках одного правила;

• проверка содержимого страниц;

• гибкая интеграция в Nagios-совместимые системы или использование в качестве самостоятельного инструмента командной строки.

Все эти возможности дополняются удобным веб-интерфейсом Checkmk:

• параметры, доступные в командной строке, также присутствуют в GUI;

• результаты можно визуализировать с помощью графиков (время отклика, загрузка заголовков, контента и т. д.);

• предусмотрены встроенные подсказки и контекстная справка.

Планы на будущее

Разработчики рассматривают возможность расширения функционала:

• мониторинг сертификатов за прокси-серверами;

• внедрение новых метрик производительности;

• добавление дополнительных сценариев тестирования контента.

check_httpv2 и check_cert — это не просто обновлённые версии старых инструментов, а полноценные решения для глубокого анализа веб-сервисов. С ростом сложности сайтов эти инструменты становятся всё более полезными и незаменимыми.

В эпоху микросервисов и облачных технологий виртуальные машины (ВМ) продолжают играть ключевую роль в инфраструктуре многих организаций. Особенно это касается крупномасштабных решений, таких как SAP HANA, Oracle Database, Microsoft SQL Server и другие критически важные корпоративные приложения.

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

1. Подготовка физического сервера

Перед развертыванием высоконагруженной виртуальной машины необходимо удостовериться в правильной настройке хост-сервера:

• Отключите энергосберегающие функции BIOS (например, C-States);

• Убедитесь в достаточной мощности CPU и объёме памяти с учётом NUMA;

• Используйте быстрые сетевые и дисковые интерфейсы;

• Проверьте совместимость оборудования с помощью VMware Compatibility Guide.

2. Настройка виртуальных процессоров (vCPU)

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

Также необходимо учитывать архитектуру NUMA: при наличии нескольких CPU-сокетов ресурсоёмкая ВМ должна размещаться в пределах одного NUMA-домена. Это снизит задержки доступа к памяти. Подробнее — в документации VMware.

3. Конфигурация памяти

• Устанавливайте достаточный объём оперативной памяти с учётом NUMA;

• Для критичных ВМ рекомендуется использовать memory reservation;

• Избегайте ballooning и swapping в гостевой ОС.

4. vMotion и перемещение ВМ

При использовании vMotion для миграции крупных ВМ учитывайте:

• Нагрузку на сеть и хранилище;

• Возможные кратковременные просадки производительности;

• Планируйте перемещения в периоды низкой активности;

• При необходимости используйте Storage vMotion отдельно от vMotion.

5. Стартовая конфигурация и масштабирование

На начальном этапе конфигурация должна быть минимально необходимой:

• vCPU: 4–8 ядер;

• RAM: 64–128 ГБ.

После развертывания важно проводить нагрузочное тестирование и масштабировать ресурсы по мере необходимости. Подходящие инструменты: VMware vRealize Operations, Prometheus, Grafana.

6. Мониторинг и управление

Для поддержания стабильности виртуальной среды следует регулярно отслеживать:

• Загрузку CPU и памяти;

• Показатели IOPS и задержки дисков;

• Сетевую активность;

• Эффективность использования NUMA.

Заключение

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

В современном мире IT-специалисты стремятся максимально автоматизировать процессы. Это не только удобно, но и позволяет сэкономить значительное количество времени. В этой статье мы рассмотрим, как с помощью OpenTofu и cloud-init можно автоматически разворачивать виртуальные машины (ВМ) в Proxmox VE и настраивать на них всё необходимое — от пользователей до веб-сервисов.

Почему стоит использовать автоматизацию?

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

Однако с ростом количества проектов ручная настройка становится всё более трудоёмкой и времязатратной. Именно поэтому появились инструменты автоматизации, такие как FAI, Kickstart, preseed и другие. Сегодня стандартом стала инфраструктура как код (IaC).

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

Какие инструменты мы будем использовать?

Proxmox VE — это гипервизор, который поддерживает виртуальные машины и контейнеры. Он имеет удобный веб-интерфейс, мощные возможности (кластеризация, создание снимков, резервное копирование) и может использоваться бесплатно (без коммерческой подписки, но с доступом к no-subscription репозиториям). Proxmox отлично подходит для частных облаков, разработки и даже продакшн-инфраструктур.

OpenTofu — это свободная альтернатива Terraform. С его помощью можно описать в коде все необходимые параметры ВМ, такие как количество, объём оперативной памяти, размер дисков, количество CPU, шаблон и настройки. После этого всё создаётся автоматически.

cloud-init — это инструмент, который запускается внутри ВМ при первом старте. Он выполняет все команды, указанные в user-data файле, такие как настройка пользователей, установка пакетов и запуск скриптов. cloud-init работает с большинством популярных дистрибутивов.

Как это работает на практике?

- Создаём шаблон ВМ в Proxmox с предустановленной ОС и поддержкой cloud-init.

- Пишем OpenTofu-скрипт, описывая нужное количество машин и их параметры.

- Запускаем tofu apply и получаем готовую инфраструктуру без необходимости вручную кликать мышью.

Пример использования:

- Несколько веб-серверов (например, с Nginx).

- Один обратный прокси (Nginx или HAProxy).

Всё развёрнуто и настроено автоматически, начиная с нуля.

Преимущества автоматизации:

- Быстро: один конфиг — и готовый кластер через пару минут.

- Масштабируемо: хотите 3 ВМ, хотите 30 — просто меняете переменную.

- Предсказуемо: никаких «а у меня не работает» — всё конфигурируется одинаково.

- Гибко: хотите Ubuntu, хотите Debian, хотите PostgreSQL + Redis — всё настраивается заранее.

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

Насколько это сложно?

Для тех, кто уже знаком с Proxmox и имеет базовые навыки работы с YAML и HCL (языком конфигурации OpenTofu), настройка не вызовет трудностей — весь процесс можно освоить за один вечер.

Даже если вы только начинаете, подход остаётся доступным: достаточно один раз настроить шаблон виртуальной машины с поддержкой cloud-init и подключить провайдер Proxmox для OpenTofu.

После этого развёртывание новых ВМ становится полностью автоматизированным и воспроизводимым процессом.

Заключение

Современная автоматизация — это не просто «поиграться», а про устойчивость, скорость и контроль.

Комбинация Proxmox + OpenTofu + cloud-init — отличный выбор для разработчиков, системных администраторов и DevOps-специалистов, которым важно быстро и стабильно поднимать окружения.

Если вам нужно развернуть высоконагруженную инфраструктуру или внедрить автоматизацию в проекты на ELMA365, Bitrix24, Nginx, PostgreSQL или других решениях — мы поможем спроектировать и реализовать стабильную, масштабируемую систему на базе Proxmox.

💥 С чего всё началось?

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

📉 Что происходило:

Сайт выпадал из поисковой выдачи — ни трафика, ни заявок.

Хостинг регулярно блокировал сайт: он «падал», уходил в карантин и снова выпадал из поиска.

Антивирус, предложенный хостингом, не работал — вирусы возвращались снова и снова.

🔍 Провели аудит и вот что мы нашли:

В корне сайта лежали подозрительные каталоги и файлы

По директориям были раскиданы вредоносные PHP-файлы с рандомными названиями.

Вирус залез через дыры в популярном шаблоне Аспро.

Заражены были файлы:

• template.php

• header.php

• footer.php

А также уязвимые ajax-скрипты:

• /ajax/show_basket_popup.php

• /ajax/show_basket_fly.php

• /ajax/reload_basket_fly.php

И, конечно, типичные вредоносные скрипты, которые маскировались под системные. Например:

<script>if(!localStorage.getItem(...</script>

🤔 Почему вирусы возвращались?

• Заражённые “закладки” остались в шаблоне и модулях

• После восстановления из бэкапа оставались повреждённые файлы

• Уязвимости не устранялись, шаблон и модули не обновлялись

• И самое главное — не было защиты для входящих запросов

Как мы реально вылечили сайт на Битриксе от вирусов — без магии, только техно-колдовство 🛠️💻

После трёх волн атак и постоянных повторных заражений, мы пошли по хардкорному пути — и это сработало. Вот что мы сделали:

🔍 Глубокий аудит и ручная чистка

🧹 Полное удаление вредоносного кода

🧩 Удаление уязвимых модулей

🎨 Восстановление шаблона и компонентов

🛡️ Фильтрация POST-запросов

⬆️ Обновление всей системы

🔒 Дополнительная защита:

• Настроили WAF

• Перераспределили права доступа

• Сменили все пароли

• Включили резервное копирование на внешний источник

• Запустили постоянный мониторинг изменений

✅ Сайт Заказчика полностью очищен

• Ни вирусов, ни “закладок”, ни вредоносных скриптов

• Работает мониторинг, который мгновенно реагирует на любые подозрительные изменения

• С тех пор — ни одной повторной атаки

• Восстановлены все страницы, товары и позиции в поиске

• Бизнес снова принимает заказы, а владельцы наконец спят спокойно

💡 Что реально сработало в этом кейсе

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

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

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

🔹Профилактика.
Настроили резервные копии, доступы, защиту от повторных атак. Это не “установили антивирус и забыли”, а работа на несколько дней вперёд, чтобы исключить повторения.

Если у вас были похожие случаи — когда вирусы возвращаются даже после "восстановления" — проверьте старые шаблоны, кастомные модули и php.ini в неожиданных местах.
Иногда всё, что нужно — это не новая система, а глубокая чистка и пара часов внимательного аудита.

2. Импорт шаблона

1. Скачайте файл шаблона Wazzup24.yaml

2. В Zabbix: Configuration → Templates → Import

3. Выберите файл и подтвердите импорт

3. Настройка макросов

Необходимые параметры:

4. Архитектура шаблона

4.1 Основной элемент данных

• Название: Get Wazzup Channels Data

• Тип: HTTP Agent

• Ключ: wazzup.raw_data

Параметры:yamlCopyURL: https://api.wazzup24.com/v3/channels

Метод: GET

Заголовки: Authorization: Bearer {$API_KEY}

• Интервал: 10 минут

4.2 Правило автоматического обнаружения (LLD)

• Название: Wazzup Channels Data

• Ключ: wazzup.channels.discovery

• Макросы JSONPath:

5. Элементы данных каналов

5.1 Прототип элемента данных

• Название: Название: {#NAME} | Тип: {#TRANSPORT} | Номер: {#PLAINID}

• Ключ: wazzup.channel.state[{#CHANNELID}]

• Препроцессинг:JSONPath: $[?(@.channelId == '{#CHANNELID}')].state.first()

Объяснение JSONPath:

1. $ - корень JSON-документа

2. [?(@.channelId == '...')] - фильтр по уникальному ID канала

3. .state.first() - извлечение строкового значения состояния

6. Триггеры и состояния каналов

Полный список состояний:

1. active - канал активен

2. blocked - заблокирован

3. foreignphone - QR-код отсканирован чужим аккаунтом

4. openelsewhere - авторизация в другом аккаунте

5. init - процесс запуска

6. onModeration - на модерации

7. unauthorized - не авторизован

8. notEnoughMoney - недостаточно средств

9. phoneUnavailable - нет связи с телефоном

10. waitForPassword - требуется пароль 2FA

11. qridle - ожидание сканирования QR-кода

12. rejected - отклонен

13. disabled - отключен

14. Другое - неизвестный статус

expression: 'last(/Wazzup24/wazzup.channel.state[{#CHANNELID}],#1)="foreignphone"'

name: 'Название: {#NAME} | Тип: {#TRANSPORT} | Номер: {#PLAINID} QR отсканирован некорректным аккаунтом'

priority: WARNING

Это элемент типа code его надо вставить как на странице Nginx + OsTicket

7. Подключение шаблона к хосту

1. Откройте Configuration → Hosts

2. Выберите целевой хост

3. В разделе Templates добавьте "Wazzup24"

4. На старнице Macros вставьте {$API_KEY} с вашим API ключом

5. Сохраните изменения

8. Верификация работы

1. Перейдите в Monitoring → Latest Data

2. Выберите ваш хост

3. Проверьте наличие элементов:

4. wazzup.raw_dataАвтообнаруженные каналы

9. Расширенные настройки

9.1 Настройка интервалов

• Измените Update interval в элементе данных wazzup.raw_data для регулировки частоты опросов

• Рекомендуемые значения: 5-15 минут

9.2 Обработка ошибок

• Триггер "Данных нет": Срабатывает при отсутствии данных дольше {$NODATA_DURATION}

• Неизвестный статус: Триггер "статус не определен" срабатывает, если пришли неизвестные данные.

Заключение

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