Как построить наблюдаемость, когда нет ни CMDB, ни oncall

Привет! Это Скутин Антон. Я работаю в «Петрович-Тех» руководителем отдела обеспечения доступности ИТ-сервисов. Моя предыдущая статья была про ITIL. В этот раз я решил рассказать о том, как построить наблюдаемость, когда нет ни CMDB, ни oncall. Эту тему я рассказывал на Observability Conf, коллеги завалили вопросами, поэтому решил поделиться здесь, подключайтесь в комментарии — обсудим!

Первородный хаос

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

На схеме хорошо видно, насколько разнородной была экосистема. Zabbix отвечал за инфраструктурный мониторинг, Prometheus собирал сервисные метрики, ELK использовался для хранения и анализа логов, PerfExpert следил за производительностью баз данных, а OpenTelemetry только начинала появляться в новых проектах. Каждый инструмент был по-своему полезен и успешно решал свою локальную задачу.

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

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

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

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

• Zabbix — используется для сбора большинства метрик и как единая база для событий, на основе которой строится вся аналитика и статистика.

• Большое количество метрик, частично сгруппированных по системам.

• Излишне большие темплейты, метрик много, но 60% не используется.

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

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

Проблема оказалась уже не в настройках. Незаметно для себя мы превратили хороший инструмент инфраструктурного мониторинга в универсальную платформу наблюдаемости. В результате чего начали проявляться его архитектурные ограничения.

Когда хороший инструмент используют не по назначению

К этому моменту стало ясно: дальнейшая оптимизация шаблонов, метрик и дашбордов не устранит системную проблему. Нужно было понять, какие ограничения возникают, когда инфраструктурный мониторинг становится основой для корреляции событий, аналитики и централизованного алертинга. 

Сначала это казалось вполне логичным. Если система уже собирает события, почему бы не сделать её единым центром мониторинга? Вскоре в Zabbix начали стекаться данные из других систем, вокруг него строились дашборды, появлялись интеграции, отчеты и собственные процессы. Чем больше информации он аккумулировал, тем сильнее возникало ощущение, что здесь и должна формироваться единая картина состояния сервисов.

Но на практике всё оказалось гораздо сложнее.

Почему Zabbix не справляется с ролью централизованной системы событий? 

Ответ — конкретные технические ограничения.

1. Неизменяемая событийная модель

2. Сложная архитектура дашбордов (SQL-запросы с большим количеством JOIN к БД Zabbix)

3. Alert storm при некоторых типах сбоев
(отсутствие дедупликации)

4. Низкая точность аналитических дашбордов

5. Фильтрация алертов на основе последнего комментария дежурного

6. Требуется инструмент для ведения карт сбоев, учёта причин, ответственных и т. д.

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

Особенно заметно это проявлялось во время крупных инцидентов. Один отказ инфраструктуры мог породить десятки, а иногда и сотни связанных между собой уведомлений. Вместо одного понятного сигнала команда получала настоящий поток алертов, среди которых было сложно определить первопричину. Инженеры тратили время не на устранение проблемы, а на сортировку уведомлений и поиск того самого события, с которого всё началось.

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

Когда каждый инструмент живёт своей жизнью

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

Prometheus использовался для мониторинга сервисов и приложений, однако со временем в компании появилось сразу несколько его экземпляров. Разные команды самостоятельно разворачивали собственные инстансы, настраивали правила сбора метрик и создавали свои дашборды. Такой подход давал разработчикам свободу, но одновременно приводил к новой проблеме: становилось всё сложнее понять, где находится источник истины и каким данным можно доверять в первую очередь.

С логами ситуация выглядела не лучше. ELK позволял удобно хранить и анализировать большие объемы информации, однако во время расследования инцидентов выяснилось, что часть логов поступает с заметной задержкой. Для последующего анализа это не критично, но в момент аварии каждая минута имеет значение. Если нужная информация появляется спустя час или два после события, она уже не помогает принять оперативное решение.

PerfExpert успешно решал задачи мониторинга баз данных, но существовал практически как отдельный остров. Из-за отсутствия полноценного API его было сложно встроить в общую систему событий, поэтому инженерам приходилось обращаться к нему отдельно. OpenTelemetry, наоборот, уже начинала использоваться в новых проектах, однако пока еще не была интегрирована в общую архитектуру мониторинга.

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

Этот вывод изменил наш подход. Вместо очередной попытки «починить мониторинг» мы начали говорить о культуре мониторинга.

Проблема оказалась не в инструментах

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

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

Основные проблемы выглядели так:

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

• Неопределённая ответственность за сервисы. Во время инцидента приходилось отдельно выяснять, кому принадлежит система и кто может принять решение или подключиться к устранению сбоя.

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

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

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

Сначала процессы — потом технологии

Осознание проблемы изменило и подход к ее решению.

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

Решение проблемы культуры мониторинга:

• Единый центр компетенций

• Runbook и листы эскалации

• Сбор и согласование метрик с заказчиком

• Система приоритетов

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

Мы начали определять владельцев сервисов, договорились о единых приоритетах инцидентов, подготовили runbook'и и листы эскалации, а также стали согласовывать ключевые метрики с заказчиками. Последний пункт оказался особенно важным. Вместо того чтобы самостоятельно решать, какие показатели считать критичными, мы начали обсуждать это с теми, кто ежедневно пользуется сервисами и лучше понимает влияние каждого отказа на бизнес.

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

Мы перестали воспринимать мониторинг как набор отдельных инструментов. Теперь это была единая система, в которой технологии лишь помогают реализовать заранее определённые процессы.

Мониторинг должен появляться ещё до запуска сервиса

После того как появились единые правила, возник следующий логичный вопрос: как сделать так, чтобы новые проекты не повторяли старых ошибок?

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

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

Решением стало внедрение процесса постановки сервисов на мониторинг через архитектурный комитет.

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

Для каждого нового сервиса появился минимальный набор требований. Мы заранее определяем, какие метрики необходимо собирать, какие события должны генерировать алерты, какие логи являются критичными и кто будет отвечать за сопровождение системы после запуска. При этом команды по-прежнему могут использовать собственные инструменты и дополнительные проверки, если это действительно необходимо. Важно другое: базовые требования становятся едиными для всех.

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

Когда стандарты экономят время

Следующим шагом стала стандартизация.

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

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

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

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

Важно отметить, что мы не стремились создать идеальный стандарт с первой попытки. Гораздо важнее было договориться о минимальном наборе правил, который действительно соблюдается всеми командами. Такой подход оказался значительно эффективнее, чем разработка объёмных регламентов, которые никто не открывает после публикации.

Хороший алерт не заканчивается уведомлением

Даже после стандартизации оставался ещё один вопрос. Что происходит после того, как мониторинг сообщает о проблеме?

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

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

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

Такое решение оказалось полезным не только для новых сотрудников. Даже опытные инженеры перестали тратить время на поиск информации в документации или обращение к коллегам. Вместо абстрактного уведомления они сразу получали понятный сценарий действий.

В этот момент мы окончательно изменили своё отношение к мониторингу. Хороший мониторинг — это не тот, который сообщает о проблеме первым. Хороший мониторинг помогает решить проблему как можно быстрее.

Когда процессы появились, стало ясно, какого инструмента не хватает

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

Мы научились правильно собирать данные, но всё ещё не умели эффективно работать с событиями.

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

Стало очевидно, что следующим шагом должен стать единый слой обработки событий.

Логичное желание — купить готовое решение

Когда стало понятно, что нужен единый слой обработки событий, мы начали изучать готовые решения. Среди них был MONQ — платформа, которая хорошо иллюстрировала целевую для нас архитектуру event management.

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

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

Однако покупать готовую платформу на этом этапе было бы преждевременно. Нам не требовался весь объём её функциональности сразу, а стоимость лицензии, внедрения, интеграций, обучения и сопровождения не соответствовала текущему объёму задач.

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

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

А может, написать своё?

Наверное, через этот этап проходит почти каждая инженерная команда.

Когда понимаешь, какой функциональности не хватает, невольно появляется мысль: «Возможно, проще сделать это самостоятельно?»

Мы начали проектировать собственную систему. Архитектура выглядела вполне современной: backend на Python, REST API на Flask, PostgreSQL в качестве хранилища, веб-интерфейс на React. На бумаге всё выглядело достаточно реалистично.

Более того, первые оценки показывали, что реализовать базовый функционал вполне возможно.

Однако спустя некоторое время практика показала, что написать работающий прототип — далеко не самая сложная часть проекта.

Настоящие сложности начинаются позже.

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

Мы хотим создавать систему мониторинга или всё-таки заниматься развитием инфраструктуры компании?

Ответ оказался очевидным.

Компромисс, который оказался самым разумным

После этого мы начали внимательно смотреть в сторону open source.

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

Так мы пришли к Alerta, что она может дать?

1. Централизация алертов

2. Дедупликация и корреляция

3. Инцидент менеджмент

Она не обещала решить абсолютно все проблемы одним нажатием кнопки. Но и мы уже прекрасно понимали, что таких решений не существует.

Зато Alerta закрывала те задачи, которые действительно были для нас критичны: централизованный прием событий, дедупликацию алертов, корреляцию, управление инцидентами и удобный API для интеграции с существующей инфраструктурой.

Важно отметить, что переход на open source не означает «установил и забыл». Интеграции всё равно требуют времени, процессы — настройки, а архитектура — постоянного развития.

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

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

Новая архитектура: когда каждый инструмент занимается своим делом

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

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

Теперь мы решили вернуть каждому инструменту его первоначальную роль.

Главные изменения по сбору метрик:

▪ Zabbix — инфраструктура и серверные метрики
▪ Prometheus или VictoriaMetrics — будет собирать все бизнес-метрики сервисов
▪ ELK — для сбора общих логов
▪ Fluentbit / Vector — для сбора критичных логов для обеспечения быстрой записи
▪ PerfExpert либо его замена — для работы с метриками БД
▪ OpenTelemetry — постепенное начало использования инструмента

В новой архитектуре Zabbix продолжает отвечать за мониторинг инфраструктуры и оборудования. Prometheus и VictoriaMetrics используются для хранения и анализа прикладных и бизнес-метрик. ELK остается основной платформой для централизованного хранения логов, а для сценариев, где критична скорость доставки данных, используются Fluent Bit и Vector. Мониторинг баз данных по-прежнему выделен в отдельное направление, а OpenTelemetry становится стандартом для сбора телеметрии в новых сервисах.

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

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

Отдельное внимание мы уделили визуализации данных. Инженерам важно не только получать уведомления, но и видеть общую картину: состояние сервисов, динамику инцидентов, повторяющиеся проблемы и влияние изменений на стабильность платформы. Поэтому мы постепенно переносим визуализацию в Grafana, а для аналитики и управленческой отчетности рассматриваем использование Power BI. Это позволяет работать не только с отдельными событиями, но и анализировать тенденции, которые раньше оставались незаметными.

Что изменилось?

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

С чего начиналось и к чему пришли?

× Разрозненные системы мониторинга без единого центра событий
× Zabbix используется как база событий, хотя не предназначен для этого
× Алерты приходят из разных систем и плохо связаны между собой
× Отсутствует дедупликация и корреляция событий
× Сложная аналитика и дашборды через SQL к базе Zabbix
× Зависимость мониторинга от ручных процессов и комментариев дежурных

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

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

Сегодня эффект от принятых решений становится всё более очевидным.

Во-первых, у сервисов появились владельцы и понятные правила сопровождения. Во-вторых, новые системы сразу создаются с учетом требований к мониторингу, а не получают его «в довесок» после запуска. В-третьих, события из разных источников больше не рассматриваются по отдельности — они становятся частью единой картины.

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

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

Observability — это путь, а не конечная точка

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

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

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

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

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

Интересно сравнить этот подход с вашим опытом: как у вас определяются владельцы сервисов, обрабатываются события из разных источников и устраняются дубли алертов?

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