Отказаться скорее всего не получится, система действительно использует большой набор системных компонент. Еще и преимущественно кластерные версии. Компоненты специфические и лучшие для их конкретного применения у нас в продукте. Логи летят в клик, метрики в викторию, и сделано это было чтобы соответствовать требованиям клиентов по выдерживанию высоких нагрузок. Тысячи событий в секунду по требованиям безопасников или во время агрегации syslog, десятки миллионов метрик c инфраструктуры с миллионом устройств, как это бывает в крупных телекомах. И все это на одном инстансе.
Для продуктивной установки есть специальный установщик, выдаваемый поддержкой, также есть простая установка через виртуальную машину, которую можно скачать с сайта. Поддерживать самим все это тоже можно, также регулярно проходят обучающие курсы по администрированию и траблшутингу продукта.
Много раз внутри обсуждали необходимость запуска облака. А нужно ли оно?
Проблемой омонимии мы пока не озадачивались - в обработке первичных событий ИТ-мониторинга этот вопрос не стоит остро, контекст довольно жесткий.
Во-первых, мы нигде не используем представления отдельных слов (embeddings), где имеет место проблема омонимов - и lda- и doc2vec-модели строятся на контексте, совокупностях слов. Во-вторых, в наших текстах (логи, события, ошибки) вообще врядли будут омонимы в одном собщении (документе) - нет нужды пытаться как-то их отлавливать и различать. Т.е. идёт речь о "ключе шифрования" или "замочном ключе", становится ясно по контексту и обе модели (lda и doc2vec) эту разницу увидят и выдадут разные векторные представления.
И у Microsoft, и у VMware, и у Adobe, мне кажется, такая маркетинговая политика. Кто пользуется пиратскими версиями, тот бы и так не купил, а значит не надо бороться и можно дать бесплатно, для большего распространения, привязывания и обучения. Это некий протофримиум.
Могут быть и там, и там. Круто, когда в заказчике. Это снимает риски того, что ожидания разойдутся с реальностью. Но есть и профессиональные команды, это партнеры например, которые размещены тут. Данный проект делал Хоппер ИТ.
2.5 человека — если грубо по ролям, это 0,5 системный администратор, 1 инженер, 0,5 автотестер и 0.5 руководитель проекта.
Что касается компетенций. Системный администратор — нужно знать Linux, Docker, Kubernetes. Его задача поднять все компоненты, настроить окружение, сеть и т.д. Инженер внедрения — заводит пользователей, помогает им, учит пользоваться системой, настраивает карты здоровья и т.д. Автотестер — пишет синтетические тесты. Ну и руководитель проекта — тут все административные вопросы, общение с заказчиком и т.д.
Оценка влияния сбоев на бизнес это всегда нетривиальная задача. Сначала надо понять сколько стоит минута простоя каждого бизнес-сервиса и какой эффект в деньгах от длительных сбоев (тут приходит на помощь показатель RTO — максимальное время простоя при аварии, которая может состоять даже из нескольких сбоев). Во время длительных сбоев может начаться отток клиентов.
Например, в банке важны длительные сбои и частота сбоев, они влияют на отток клиентов. А в ретейле важно общее время недоступности сервиса, если например это интернет-магазин или служба доставки. Делаем выгрузку в эксель и согласно моделе считаем. Можно оценить и эффект каждого сбоя, можно расчитать некий интегральный KPI подразделения или подрядчика. В системе monq есть как раз мощный конструктор отчетов SLA.
в принципе, в фоновом режиме микросервис способен все ряды обсчитывать — коэффициенты корреляции мало меняются и для каждой пары КЕ достаточно его пересчитывать раз в день, а то и реже, чтобы обновлять матрицу корреляций. мы сортируем ряды по частоте изменения значений и берется верхняя сотня (как наиболее интересные) для отработки алгоритмов. кстати, из 3200 КЕ на одной из инсталяций за полгода только 25% изменили значения более 2 раз — поэтому полная корреляционная матрица почти вся «зелёная».
Абсолютно точно, голову никто не отменял. И я бы не рекомендовал сейчас на подобном анализе строить автоматизацию. Коренных проблем может быть несколько, а может и не быть вообще, так как система не обладает достаточными данными.
Например, у нас попадали алерты с фронта, проверка работы услуги не выполнена. Если мы добавим данные о том, что только что прошёл релиз, то это событие будет показано как корень, а если у нас только данные инфраструктурных метрик, то мы увидим, что фронт не отработал корректно возможно из-за перезагрузки сервера, что бред.
В этом случае надо один ряд сдвинуть на величину предполагаемой задержки и заново посчитать. Или сначала можно попробовать увеличить интервал регуляризации ряда до нескольких часов — возможно там корреляция проявится. В общем, для отслеживания таких связей понадобится несколько корреляционных матриц с разными лагами и интервалами регуляризации.
Можно подключить ИБ инструменты как дополнительные источники событий. Например, WAF и antiDDos сервисы. И когда пойдёт атака, можно будет быстро увидеть причину, понять глубину влияния и оповестить ответственных, не рассылая миллион оповещений всем подряд. Да и для ИБ это окно в мир информации ИТшников.
Да, ок. Чувствую надо будет в 21ом делать свой блог тут, чтоб конкретно можно было про продукт рассказывать, и писать коллективом интересные и для технарей статьи.
Спасибо, поправил. Да, решил одновременно разместить там и тут и сравнить реакцию.
По поводу кейсов, есть кейс внедрения элементов AIOps в Тинькофф тут и в крупном регионе тут. В начале года смогу еще парочку крупных внедрений описать. А что интересно было бы почитать? Там же каждое внедрение это целая своя длинная история: выбор решения, почему выбрали это, потом эпопея с инфобезом, который не любит дырки в сети ковырять и давать доступы в открытый мир, бывает, что систему стандартым установщиком не развернуть и начинаются танцы с бубном (например, развернуть контейнеры на линуксе с виртуализацией поверх Win-машин), потом интеграции с системами мониторинга (стандартными и не очень), потом ML и правила корелляции, потом автоматизация (например, описать как пишутся скриипты на Lua со вставками cURL или SNMP) и т.д. Еще есть куча нетехнических моментов, начиная с того, что все считают положительный эффект по-своему и у всех разные KPI. Следовательно и оценка результатов у всех своя.
Так любые вендоры работают, это рынок же такой. Цен открытых нет ни на один Eterprise продукт. Ни на Veaam, ни на IBM, ни на варю, ни на рэдхат и т.д.
вопрос больше риторический)
Отказаться скорее всего не получится, система действительно использует большой набор системных компонент. Еще и преимущественно кластерные версии. Компоненты специфические и лучшие для их конкретного применения у нас в продукте. Логи летят в клик, метрики в викторию, и сделано это было чтобы соответствовать требованиям клиентов по выдерживанию высоких нагрузок. Тысячи событий в секунду по требованиям безопасников или во время агрегации syslog, десятки миллионов метрик c инфраструктуры с миллионом устройств, как это бывает в крупных телекомах. И все это на одном инстансе.
Для продуктивной установки есть специальный установщик, выдаваемый поддержкой, также есть простая установка через виртуальную машину, которую можно скачать с сайта. Поддерживать самим все это тоже можно, также регулярно проходят обучающие курсы по администрированию и траблшутингу продукта.
Много раз внутри обсуждали необходимость запуска облака. А нужно ли оно?
Простите за птичий язык, бизнес - это менеджеры не из ИТ.
https://habr.com/ru/post/645395/
Проблемой омонимии мы пока не озадачивались - в обработке первичных событий ИТ-мониторинга этот вопрос не стоит остро, контекст довольно жесткий.
Во-первых, мы нигде не используем представления отдельных слов (embeddings), где имеет место проблема омонимов - и lda- и doc2vec-модели строятся на контексте, совокупностях слов. Во-вторых, в наших текстах (логи, события, ошибки) вообще врядли будут омонимы в одном собщении (документе) - нет нужды пытаться как-то их отлавливать и различать. Т.е. идёт речь о "ключе шифрования" или "замочном ключе", становится ясно по контексту и обе модели (lda и doc2vec) эту разницу увидят и выдадут разные векторные представления.
во второй части, опубликую на этой неделе
И у Microsoft, и у VMware, и у Adobe, мне кажется, такая маркетинговая политика. Кто пользуется пиратскими версиями, тот бы и так не купил, а значит не надо бороться и можно дать бесплатно, для большего распространения, привязывания и обучения. Это некий протофримиум.
То, что вы видите в будущем очень похоже на AIOps и зонтичный мониторинг с сильной автоматизацией. Уже смотрите в сторону каких-нибудь вендоров?
Все внутренности написаны на C# под линуксовым .NET, открыт не полностью, частично есть на гитхабе тут.
У меня скачался за 15 минут где-то. Залил сюда, чтоб уж наверняка.
Что касается компетенций. Системный администратор — нужно знать Linux, Docker, Kubernetes. Его задача поднять все компоненты, настроить окружение, сеть и т.д. Инженер внедрения — заводит пользователей, помогает им, учит пользоваться системой, настраивает карты здоровья и т.д. Автотестер — пишет синтетические тесты. Ну и руководитель проекта — тут все административные вопросы, общение с заказчиком и т.д.
Например, в банке важны длительные сбои и частота сбоев, они влияют на отток клиентов. А в ретейле важно общее время недоступности сервиса, если например это интернет-магазин или служба доставки. Делаем выгрузку в эксель и согласно моделе считаем. Можно оценить и эффект каждого сбоя, можно расчитать некий интегральный KPI подразделения или подрядчика. В системе monq есть как раз мощный конструктор отчетов SLA.
Абсолютно точно, голову никто не отменял. И я бы не рекомендовал сейчас на подобном анализе строить автоматизацию. Коренных проблем может быть несколько, а может и не быть вообще, так как система не обладает достаточными данными.
Например, у нас попадали алерты с фронта, проверка работы услуги не выполнена. Если мы добавим данные о том, что только что прошёл релиз, то это событие будет показано как корень, а если у нас только данные инфраструктурных метрик, то мы увидим, что фронт не отработал корректно возможно из-за перезагрузки сервера, что бред.
В этом случае надо один ряд сдвинуть на величину предполагаемой задержки и заново посчитать. Или сначала можно попробовать увеличить интервал регуляризации ряда до нескольких часов — возможно там корреляция проявится. В общем, для отслеживания таких связей понадобится несколько корреляционных матриц с разными лагами и интервалами регуляризации.
Можно подключить ИБ инструменты как дополнительные источники событий. Например, WAF и antiDDos сервисы. И когда пойдёт атака, можно будет быстро увидеть причину, понять глубину влияния и оповестить ответственных, не рассылая миллион оповещений всем подряд. Да и для ИБ это окно в мир информации ИТшников.
По поводу кейсов, есть кейс внедрения элементов AIOps в Тинькофф тут и в крупном регионе тут. В начале года смогу еще парочку крупных внедрений описать. А что интересно было бы почитать? Там же каждое внедрение это целая своя длинная история: выбор решения, почему выбрали это, потом эпопея с инфобезом, который не любит дырки в сети ковырять и давать доступы в открытый мир, бывает, что систему стандартым установщиком не развернуть и начинаются танцы с бубном (например, развернуть контейнеры на линуксе с виртуализацией поверх Win-машин), потом интеграции с системами мониторинга (стандартными и не очень), потом ML и правила корелляции, потом автоматизация (например, описать как пишутся скриипты на Lua со вставками cURL или SNMP) и т.д. Еще есть куча нетехнических моментов, начиная с того, что все считают положительный эффект по-своему и у всех разные KPI. Следовательно и оценка результатов у всех своя.