Мониторинг производительности систем в 2026: минимальный набор метрик и алертов

Минимальный набор метрик для мониторинга: что нужно собирать в первую очередь

Минимальный production-мониторинг должен охватывать пять уровней: хост, диск, сеть, процессы и приложение. Для каждого уровня нужны сигналы доступности, насыщения ресурса, задержки и ошибок. Базовый набор включает загрузку CPU и load average, доступную память и swap, место на файловых системах и inode, I/O latency, сетевой throughput, drops и retransmits, состояние процессов, request rate, latency, error rate и успешность ключевой операции.

Такой набор помогает ответить на четыре рабочих вопроса: доступен ли объект, хватает ли ему ресурса, растет ли задержка и появляются ли ошибки. Высокий utilization без деградации сервиса не всегда означает инцидент. Отсутствие ожидаемых метрик опаснее: сервис может выглядеть healthy, хотя exporter, pipeline сбора или канал уведомлений уже не работает.

Для быстрого старта соберите следующие алерты:

• Target недоступен: проверить узел, exporter, сеть и сам Prometheus.
• Метрики перестали поступать: найти stale series, ошибку scrape или изменение labels.
• Высокая задержка приложения: проверить p95 и p99, очередь запросов, базу данных и внешние зависимости.
• Рост ошибок: разделить 4xx и 5xx, определить сервис и операцию, которая ломается.
• Заполнение файловой системы или inode: найти mount point, темп роста и безопасное действие по освобождению места.
• Давление на память: проверить available memory, swap in/out, OOM и процессы-потребители.
• Деградация хранения: проверить latency, очередь I/O, ошибки диска, RAID или ZFS pool.
• Потери пакетов и retransmits: определить интерфейс, направление трафика и сетевой сегмент.

Каждый alert должен приводить к конкретному действию. Практический перечень сигналов для Linux, виртуальных машин, Docker, Kubernetes, NAS и ZFS собран в статье о рабочих метриках для DevOps-инженера и администратора.

Пять уровней наблюдения в production

Уровни связаны между собой. Высокая latency приложения может возникнуть из-за переполненного connection pool, зависшего процесса, очереди на диске или потерь пакетов. Поэтому CPU alone не объясняет состояние сервиса.

Минимальный стартовый комплект алертов

В первую очередь дежурный должен получать page по недоступности критичного сервиса, быстрому росту 5xx, OOM, crash loop, degraded storage и заполнению диска с риском остановки записи. Предупреждения о приближении к порогу ресурса можно отправлять в рабочий канал или ticket-систему.

Для каждого правила задайте метрику, условие, длительность, severity, владельца и действие. Alert без инструкции превращается в сообщение о факте и увеличивает время диагностики.

• up == 0 для критичного target в течение 1-2 scrape-интервалов: проверить endpoint, узел и exporter.
• Отсутствие ожидаемой series или устаревание данных: проверить scraping, labels и pipeline мониторинга.
• p95 или p99 выше baseline 10 минут вместе с ростом 5xx: искать узкое место в приложении или зависимости.
• Filesystem usage выше 85% и прогноз заполнения менее чем за 24 часа: удалить безопасные временные данные или расширить volume.
• Available memory ниже 10% вместе с активным swap или OOM: найти процесс-потребитель и проверить лимиты.
• Деградированный RAID или ZFS pool: остановить рискованные операции записи и проверить состояние накопителей.
• Устойчивый рост drops или TCP retransmits: проверить интерфейс, MTU, перегруженный канал и соседнее оборудование.

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

Порог, который подходит веб-серверу, может быть бесполезен для batch-воркера, базы данных или NAS. Веб-сервис чувствителен к хвостовой latency и 5xx, batch-процесс допускает высокий CPU во время окна обработки, а файловое хранилище требует контроля pool health, I/O latency и свободной емкости.

Сначала составьте карту объектов и зависимостей, затем соберите историю обычной нагрузки. Порог становится рабочим, когда он связан с влиянием на сервис, SLO или заметным отклонением от baseline.

Что считать объектом наблюдения

Target - источник метрик, который Prometheus регулярно опрашивает. Им может быть физический сервер, виртуальная машина, контейнерный узел, pod, reverse proxy, база данных, NAS или пользовательский endpoint.

Для каждого target зафиксируйте имя владельца, назначение, критичность, endpoint, scrape interval, используемые exporters и канал уведомлений. Если объект есть в инвентаризации, но отсутствует в Prometheus, это пробел контроля.

Baseline вместо универсальных нормативов

Соберите минимум 7-14 дней истории, чтобы увидеть рабочие пики, ночные окна и регулярные batch-задачи. Для критичных сервисов добавьте данные после нагрузочного теста и после планового релиза. Сравнивайте текущее значение с абсолютным порогом и с нормальным диапазоном конкретного объекта.

Пример: CPU 90% в течение 10 минут для API вместе с ростом p99 требует реакции. Для batch-воркера тот же показатель в заранее известное окно может быть штатным. Алерт должен учитывать расписание, лимиты и SLO.

Разные exporters генерируют разный объем данных. Node exporter, container exporter, Kubernetes-метрики и application exporter дают разное число series, поэтому их набор нужно учитывать при построении Grafana и расчете retention. Подход к baseline и поиску узкого места разобран в руководстве по оценке производительности сервера и сервиса.

Метрики хоста для мониторинга: CPU, память и системная нагрузка

Метрики хоста показывают доступность и запас ресурсов. Они помогают локализовать проблему, но сами по себе не доказывают пользовательскую деградацию. Связывайте ресурсные показатели с latency, error rate и очередями приложения.

CPU: utilization, iowait и steal

Разделяйте CPU по режимам: user показывает работу приложений, system - работу ядра, iowait - время ожидания I/O, steal - время, забранное гипервизором у виртуальной машины.

Устойчивую загрузку выше 85-90% в течение 10-15 минут можно использовать как warning. Значение выше 95% переводите в critical, когда одновременно растут latency, длина очереди или число отказов. Краткий пик на несколько секунд обычно не требует page.

• Высокий user при нормальной latency указывает на активную обработку и требует наблюдения за запасом CPU.
• Высокий system может быть связан с большим числом сетевых операций, системных вызовов или проблемным драйвером.
• Высокий iowait направляет диагностику к диску, storage-сети или очереди I/O.
• Рост steal на VM требует проверки лимитов и соседней нагрузки на физическом хосте.

Память и swap

Основной показатель для Linux - available memory, а не свободная память без учета page cache. Cache может быть освобожден ядром при необходимости, поэтому процент free memory сам по себе дает слабый сигнал.

Available memory ниже 15% используйте как warning для первичной настройки. Значение ниже 5-10% вместе с активным swap in/out, ростом reclaim pressure или OOM переводите в critical. Порог корректируйте для баз данных, файловых серверов и систем с большим кэшем.

• Постоянный swap in/out указывает на давление на память и может увеличивать latency.
• Один факт занятого swap не всегда означает аварию: часть страниц могла попасть туда во время обычной работы.
• OOMKilled или сообщения ядра об OOM требуют отдельного alert с указанием процесса и узла.
• Рост RSS одного процесса при стабильном request rate может указывать на утечку памяти.

Load average и доступность узла

Load average отражает очередь runnable и uninterruptible tasks. Сравнивайте его с количеством логических CPU и с режимами CPU. Load 8 на узле с 8 vCPU может быть нормальным при коротком пике, но устойчивый рост выше числа CPU вместе с высокой latency указывает на перегрузку.

Проверяйте up для target, возраст последней метрики, ошибки scrape и доступность node exporter. Если метрики исчезли, причина может находиться в exporter или цепочке сбора, а не в штатной нагрузке узла. Для командной диагностики Linux полезен практический алгоритм с top, iostat и ss.

Метрики диска для мониторинга: место, задержка и ошибки I/O

Диск нужно контролировать по трем независимым направлениям: доступная емкость, скорость обработки запросов и здоровье устройства или массива. Свободные гигабайты не показывают latency, а низкая latency не гарантирует наличие места для новых файлов.

Емкость файловой системы и inode

Filesystem usage выше 80-85% можно использовать как warning, выше 90-95% как critical. Учитывайте темп роста: volume с заполнением 86% и ростом 10% в час опаснее volume с заполнением 92%, которое стабильно использует место.

Контролируйте inode usage отдельным правилом. Миллионы мелких файлов могут исчерпать inode при наличии свободных гигабайт. В alert указывайте mount point, текущее значение, скорость роста и прогноз времени до заполнения.

• Для временных директорий проверяйте безопасное удаление старых файлов и наличие retention.
• Для баз данных учитывайте WAL, binlog, журналы и резервные копии, которые часто растут скачком.
• Для ZFS учитывайте snapshots, reservation и реальную доступную емкость pool.
• Для RAID проверяйте запас места и влияние rebuild на latency.

Latency, IOPS и очередь запросов

Сопоставляйте await или I/O latency с типом носителя и собственным baseline. Значение, нормальное для HDD, может быть неприемлемым для NVMe. Смотрите на queue depth, utilization, throughput и IOPS одновременно.

Устойчивый рост latency в 2 раза относительно обычного уровня в течение 10 минут заслуживает warning. Critical нужен при сильной деградации вместе с ростом p95 приложения, очереди запросов или timeout. Одна высокая цифра без влияния на сервис требует наблюдения и проверки.

Ошибки диска и состояние массива

Собирайте read errors, write errors, checksum errors, SMART-сигналы, degraded RAID, состояние resilver и scrub. Для ZFS проверяйте health pool, checksum errors и статус scrub.

Любая новая критичная ошибка накопителя или degraded state должна создавать отдельный operational alert. Производительность может оставаться нормальной в первые минуты после отказа диска, но запас отказоустойчивости уже снизился. В уведомлении указывайте устройство, pool или массив, узел и рекомендуемое действие.

Метрики сети для мониторинга: пропускная способность и потери

Сетевая диагностика требует разделять загрузку канала, ошибки интерфейса и качество TCP-соединений. Приложение может медленно работать при умеренном throughput, если растут retransmits или задержка между зависимостями.

Throughput и насыщение интерфейса

Сравнивайте RX/TX с реальной скоростью интерфейса, cloud bandwidth limit или quota. Для канала 1 Гбит/с устойчивые 700-800 Мбит/с можно взять как стартовый warning, а 900 Мбит/с и выше вместе с drops, очередями или latency - как critical.

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

Ошибки, drops и retransmits

Отслеживайте interface errors, drops, overruns, packet loss, TCP retransmits и failed connections. Единичный потерянный пакет не должен будить дежурного. Устойчивый рост относительно baseline требует проверки кабеля, duplex, MTU, очередей, firewall и соседнего оборудования.

В alert указывайте интерфейс, направление трафика, узел и связанный endpoint. Рост retransmits при нормальной загрузке канала направляет поиск к качеству пути и перегрузке приемника, а не к расширению полосы.

Latency и доступность endpoint

Добавьте blackbox-проверки для DNS, TCP, HTTP и TLS, если эти этапы влияют на путь пользователя. Разделяйте сетевую задержку, HTTP-ошибку и недоступность процесса.

• DNS check показывает проблемы разрешения имени и время ответа DNS.
• TCP check показывает доступность порта и сетевого маршрута.
• TLS check выявляет ошибки сертификата, handshake и срок действия.
• HTTP check проверяет код ответа, время ответа и ожидаемое содержимое.

Для сервиса за reverse proxy проверяйте участки client-proxy, proxy-application и application-database. Один общий ping не показывает, где именно образовалась задержка.

Метрики процессов для мониторинга: состояние, ресурсы и перезапуски

Доступный хост не гарантирует работающий сервис. Критичный worker может исчезнуть, зависнуть в ожидании диска или перезапускаться после OOM, пока node exporter продолжает отдавать нормальные значения.

Исчезновение процесса и crash loop

Для обязательных процессов и systemd units задайте короткий grace period, учитывающий штатный запуск. Отсутствие процесса после этого периода должно создавать alert с именем сервиса, узлом и последней причиной завершения.

Для restart count используйте окно времени. Например, более 3 перезапусков за 10 минут для стабильного worker обычно означает crash loop. Плановый deploy, rolling update и ручной restart должны иметь maintenance window или отдельную метку.

• Проверяйте exit code и сигнал завершения.
• Связывайте рестарт с OOMKilled, probe failure, dependency timeout или ошибкой конфигурации.
• Указывайте в уведомлении зависимые компоненты, которые могут объяснить каскад отказов.

CPU, память и file descriptors по процессам

Метрики всех процессов быстро увеличивают cardinality. Выберите ограниченный список критичных ролей: API, worker, proxy, database agent и системные демоны.

Отслеживайте CPU, RSS, количество потоков, open connections и file descriptors. Warning можно создавать при использовании 80% лимита descriptors, critical при 95% или появлении ошибок открытия файлов. Для памяти ищите устойчивый рост RSS при стабильной нагрузке, а для CPU сопоставляйте потребление с очередью и request rate.

Процессы в контейнерах и Kubernetes

В контейнерах контролируйте restart count, OOMKilled, CPU throttling, memory working set и достижение memory limit. В Kubernetes добавьте pod readiness, desired versus available replicas, evictions и состояние PVC.

Разделяйте ожидаемое обновление deployment и аварийный crash loop. Для pod, который перезапустился один раз во время rollout, нужен event или рабочее уведомление. Для нескольких рестартов за короткое окно нужен alert с именем workload и последним exit reason.

При проблемах в Kubernetes полезен пошаговый разбор pods и узлов через метрики мониторинга.

Метрики приложений для мониторинга: latency, ошибки и пользовательский результат

Application-level метрики связывают техническое событие с влиянием на пользователя. CPU может быть высоким без проблем для клиента, а HTTP-сервис может отвечать медленно при загрузке хоста 40% из-за блокировок, очереди или внешней базы данных.

Latency и error rate

Собирайте request rate, error rate и распределение времени ответа. Среднее значение скрывает хвост задержек, поэтому используйте p50, p95 и p99. Для API с большим числом быстрых запросов p99 часто показывает проблему раньше среднего.

Разделяйте 4xx и 5xx. 4xx могут отражать неверные запросы клиента, истекшую авторизацию или rate limiting. 5xx обычно требуют проверки приложения, proxy, базы данных или зависимости.

• Warning: p95 выше baseline в 1,5-2 раза в течение 10 минут.
• Critical: p95 или p99 растет одновременно с 5xx, timeout или failed dependency calls.
• Для availability используйте успешность запроса и успешность ключевого сценария, а не один код HTTP.

Saturation приложения

Найдите внутренние лимиты, которые заканчиваются раньше CPU и памяти. Контролируйте connection pool utilization, длину очереди, возраст самого старого сообщения, worker utilization, thread pool, rate limiting и cache hit ratio.

Alert должен называть конкретный ограничитель: занято 95% соединений к базе, очередь достигла 10 000 сообщений, oldest message старше 5 минут или worker pool заполнен. Такой сигнал сразу задает направление диагностики.

Для Nginx пригодятся status codes, upstream latency, active connections и число rejected connections. Для баз данных добавьте query latency, lock wait, connection pool и replication lag.

Synthetic checks и бизнес-критичные операции

Endpoint может возвращать HTTP 200, хотя пользователь не может войти, создать заказ или прочитать данные из базы. Добавьте безопасные synthetic checks для ключевых операций в отдельном тестовом контуре.

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

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

Пороги алертов: как настроить warning и critical без ложной точности

Рабочая модель alert состоит из шести частей: metric, condition, duration, severity, owner и action. Число без длительности реагирует на пик, длительность без severity смешивает срочные и плановые задачи, а alert без owner остается без действия.

Стартовые пороги для ресурсов

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

Для дисков и сети абсолютные значения зависят от оборудования и лимитов. Для памяти учитывайте page cache. Для CPU анализируйте режимы user, system, iowait и steal, а для load - число vCPU.

Пороги для ошибок, latency и доступности

При наличии SLO стройте правила от error budget. Если сервис допускает 0,1% ошибок за месяц, alert на 5% ошибок в течение нескольких минут может быть слишком поздним. Для быстрого старта без SLO используйте baseline конкретного endpoint.

• Warning на 5xx выше 1% в течение 5-10 минут, если обычный уровень близок к нулю.
• Critical на 5xx выше 5% в течение 2-5 минут или при недоступности ключевой операции.
• Warning на p95 выше 1,5-2 baseline в течение 10 минут.
• Critical на p99 выше SLO вместе с ростом timeout, 5xx или очереди.
• Для synthetic check применяйте короткое подтверждение и несколько последовательных попыток.

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

Длительность, severity и окно оценки

Для CPU, memory, disk utilization и network saturation обычно подходят окна 5-15 минут. Для target down, критичных 5xx и synthetic check нужны короткие окна, рассчитанные с учетом scrape interval и времени восстановления.

Используйте severity:

• info: событие для истории или рабочей панели;
• warning: нужна плановая проверка, но page не требуется;
• critical: сервис уже деградирует или скоро потеряет доступность, назначен конкретный дежурный.

В каждое правило добавьте service, instance, severity, owner, ссылку на dashboard и runbook. URL runbook должен быть внутренней ссылкой проекта или рабочей системы, а в статье достаточно описать его назначение.

Как снизить шум алертов в Prometheus и Alertmanager

Alert fatigue возникает, когда команда получает много сообщений без понятного действия. Причины обычно связаны с коротким duration, слишком общим порогом, дублированием симптомов и неисправной маршрутизацией.

Какие алерты должны будить дежурного

Paging оставляйте для недоступности критичного сервиса, быстрого роста 5xx, нарушения SLO, OOM, crash loop, degraded storage и заполнения диска с близким риском остановки.

Высокий CPU без latency, переполнение неиспользуемого worker pool и единичный packet drop отправляйте в рабочий канал или ticket. Для каждого warning должен существовать срок проверки. Сигналы без владельца удаляйте или связывайте с ответственным сервисом.

Grouping, deduplication и inhibition

Группируйте события по cluster, service, instance или предполагаемой root cause. Падение узла может породить alerts от node exporter, нескольких контейнеров, proxy и приложения. Команде нужен один основной инцидент с перечнем зависимых симптомов.

Deduplication убирает повторяющиеся уведомления одного alert. Inhibition подавляет вторичные сигналы при подтвержденной недоступности родительского объекта. Например, alert на сервисный endpoint можно подавить при установленной недоступности узла.

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

Проверка ложных срабатываний

Проверьте правила на исторических данных, плановых рестартах, deploy, сетевых сбоях и пиковых нагрузках. Для каждого false alert запишите причину: короткий пик, неверный baseline, maintenance, ошибка labels или недоступный канал уведомлений.

После инцидента ответьте на четыре вопроса: был ли у alert понятный action, пришел ли он правильному владельцу, дублировал ли он первопричину, было ли достаточно времени на реакцию. Меняйте threshold, duration, route или исключение для maintenance только после такой проверки.

При разборе причин деградации полезен алгоритм интерпретации CPU, RAM, диска и сети, который связывает метрики с логами, трассировками и событиями.

Проверка цепочки Prometheus, exporters и Alertmanager

Мониторинг может показывать healthy-статус из-за отсутствующих данных. Проверяйте весь путь: exporter отвечает, target доступен, Prometheus выполняет scraping, правило вычисляется, Alertmanager получает firing alert, route выбирает receiver, а уведомление приходит в канал.

Что проверить в targets и exporters

1. Откройте endpoint exporter и убедитесь, что он возвращает метрики без ошибок аутентификации.
2. Проверьте сетевую доступность, network policy, firewall, DNS, scrape interval и timeout.
3. Убедитесь, что target присутствует в конфигурации Prometheus и имеет ожидаемое значение up.
4. Проверьте ошибки scrape, stale series, изменение labels и резкое падение числа series.
5. Сверьте панели Grafana с фактическим набором exporters. Разные exporters дают разный объем и состав данных.

Почему алерт может не дойти до команды

Если правило видно в Prometheus как firing, это еще не подтверждает доставку. Проверьте состояние Alertmanager, receiver, route, labels, group wait, repeat interval, inhibition, silence и внешний канал.

Выполните контролируемый тестовый alert с известным service и severity. Зафиксируйте результат на каждом этапе: правило перешло в firing, Alertmanager получил событие, route выбрал receiver, receiver принял отправку, сообщение появилось в рабочем канале.

Контроль отсутствующих метрик

Создайте отдельные проверки на target down, отсутствие ожидаемого ряда, устаревание данных и резкое падение числа series. Для обязательной метрики задайте ожидаемый набор labels и период, за который она должна появиться.

Проблемы observability часто возникают на стыке компонентов. Exporter может отвечать, но отдавать неполный набор данных. Prometheus может собирать метрики, но не загрузить правило. Alertmanager может получить событие, но отправить его в подавленный или неверный receiver. Каждое звено проверяйте отдельно.

Хранение метрик и контроль объема данных Prometheus

Требования к storage зависят от числа targets, scrape interval, количества time series, labels, exporters и retention. Универсальная формула в формате X GB на Y месяцев дает неточную оценку и может привести к нехватке диска.

Как оценить фактический темп генерации данных

1. Подключите scraping части targets или всего набора, который планируете контролировать.
2. Дождитесь репрезентативного периода с обычной нагрузкой, пиком и плановыми задачами.
3. Зафиксируйте фактический объем данных и темп записи в Prometheus или Grafana.
4. Отдельно сравните node exporter, контейнерные, Kubernetes- и application exporters.
5. Экстраполируйте результат на полный набор targets и выбранный retention.
6. Добавьте примерно 20% запаса на straddling blocks.

Самая точная оценка получается при scraping всех targets. Если сначала собрана часть объектов, пересчитайте результат по их числу и профилю exporters, затем проверьте расчет на реальной нагрузке.

Cardinality и scrape interval

Высокая cardinality быстро увеличивает число series и нагрузку на Prometheus. Проверьте labels с request ID, UUID, полным URL, timestamp и другими уникальными значениями. Такие labels часто создают новую series для каждого события.

Увеличивайте scrape interval только после оценки потери оперативности. Для медленных ресурсных метрик может подойти более длинный интервал. Для availability, ошибок и latency критичного сервиса сохраните частоту, которая позволяет обнаружить проблему до нарушения SLO.

Recording rules помогают заранее вычислять тяжелые запросы для dashboards и alerts. Они не заменяют контроль cardinality. Сначала уберите лишние labels и метрики, затем пересмотрите retention и интервал сбора.

Итоговый чек-лист минимального мониторинга

Минимальная проверка перед production

1. Инвентаризируйте хосты, VM, контейнеры, Kubernetes-узлы, reverse proxy, базы данных, NAS и пользовательские endpoints.
2. Назначьте owner, критичность, endpoint, exporters, scrape interval и канал уведомлений для каждого target.
3. Подключите метрики host, disk, network, process и application уровня.
4. Соберите baseline обычной нагрузки, рабочих пиков и плановых операций.
5. Создайте небольшой набор actionable alerts с condition, duration, severity и action.
6. Настройте grouping, deduplication, inhibition и silence в Alertmanager.
7. Проверьте тестовый firing alert на пути от Prometheus до notification channel.
8. Добавьте dashboard и runbook для каждого critical alert.
9. Проверьте missing metrics, stale series, ошибки scrape и падение exporters.
10. Пересмотрите правила после первых инцидентов и сравните их с реальным влиянием на пользователей.

Для отдельного monitoring-стенда с изменяемыми ресурсами можно использовать облачную инфраструктуру, например серверы и Kubernetes в Timeweb Cloud. Объем диска и retention рассчитывайте после замера реального темпа данных, а не по числу targets.

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