и во что станет доработка

купить проще всего ?

конечно.

только дороже всего

я видел уже в 3 компаниях такие ситуации

покупаем за охулиард что-то, что самим писать делать охулиард лет

если повезло - то что купили даже используется

ок. не буду спорить

купить проще всего так проще всего.

если не повезло - лицухи лежат мертвым грузом

дел оваше кушать вам

Коллеги, а огласите предмет спора?

так вот время от и до мы определяем как от нет ничего дежурный отреагировал на индендет

это не спор, это приятная беседа о вечном )

это время внедрения

упрощенно так

как будет не упрощенно ?

финальная точка будет сформулирована дргой ?

сфорфмулируйте

Коллеги, а огласите предмет спора?

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

- начало - сейчас, нет ничего. - финальная точка минимум - через пол года мы должны уметь реагировать на следующие типы событий (список событий1). - финальная точка желаемая - через пол года мы должны уметь реагировать на следующие типы событий (список событий2). - финальная точка идеальная - через пол года мы должны уметь реагировать на следующие типы событий (список событий3).

ок.

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

список событий которые должны быть обработаны предмет тз

тоесть будут ясны до выбора системы

Ну, то есть, в дерьмо нырять мы не хотим

Ладно, Баду, да продлятся дни его вечно

тоесть схлапываюься как бесполезные в контексте обсуждения.

Там все на PHP

Но остальные-то куда?

прмеры списка событи (видна разница в требованиях) : список событий 1: уровень - сервер не доступен, объект не доступен, кол-в отгрузок такое то и такое то, получено стока то петрушки на склад... список событий 2: урвоень - + иметь корреляцию простых тех-процессов компании с инфраструтурными и бизнесметриками, автоматически определять отклонения и выявлять аномальное поведение метрик список событий 3: урвоень - _автоматическая_ корреляция бинес-процессов компании с любыми событиями в мониторинге (реализуемая к примеру через РСМ)

тоесть время внедрения сведется к рнд + бизнес обоснования +скриптингу выбронной системы.

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

верно ?

прмеры списка событи (видна разница в требованиях) : список событий 1: уровень - сервер не доступен, объект не доступен, кол-в отгрузок такое то и такое то, получено стока то петрушки на склад... список событий 2: урвоень - + иметь корреляцию простых тех-процессов компании с инфраструтурными и бизнесметриками, автоматически определять отклонения и выявлять аномальное поведение метрик список событий 3: урвоень - _автоматическая_ корреляция бинес-процессов компании с любыми событиями в мониторинге (реализуемая к примеру через РСМ)

не имеет значения. будет описано в бизнес требованиях. любая система прошедшая рнд это может делать.

+ к построению процессов в компании для эксплуатации этой системы.

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

не понял мысли

процессы построения бизнес процессов будут индетичны.

и не относятся к системе.

процессы построения бизнес процессов будут индетичны.

не факт, зависит от подхода и реализации системы

факт.

любая система с точки зрения бизнеса ведет себе идентично.

есть мелкие отличия.

где-то мы переложим часть задач на персонал наместах, где-то е мы все сможем деалать сами где-то все вообще автоматически будет

тычток мышкой дороже апи.

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

тычок мышкой через пол года дешевле чем готовое АПИ через 2 года

нет.

что нет?

мышка требует проверки.

и проверки проверки.

потому что люди ошибаются

так что эт оне критерий.

конечно. но через 2 года будет поздно. лдей можно выдрессировать и иметь достаочный SLA

они все равно бесплатные эти тычки мышкой.

это важный критерий.

они делаются дежурными за зарплату.

так что процессы не критерий.

они будут идентичны для любой системы

важно понимать что в жтом случае я делаю аццкую побалжку в сторону заббикса.

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

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

это разная реализация процессов в компании. цена отличатся и время а запуск отличается. по этому это тоже надо учитывать.

другие подразделения не принимают участия в ээксплутации системы. они воспринимают мониторинг как письмо пришедшее на почту

другие подразделения не принимают участия в ээксплутации системы. они воспринимают мониторинг как письмо пришедшее на почту

нет верно, в том варианте, про который мы говорим (Магнит) - подразделения на местах принимали участие. ИТ было не тока в HQ. на местах были тое люди по всей стране

у подразделений есть право создать триггер в заббиксе ?

ERROR: S client not available

они могут зайти через интерфейс и его сделать ?

очевидно нет.

у подразделений есть право создать триггер в заббиксе ?

нет

значит в эксплутатации системы они не принимают участия.

у них свой отдельный инструментарий для своих задач.

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

так и только так

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

значит время схлопывается на планерки и все такое вот

или можно не рассчитывать на них и делать все самим

значит время схлопывается на планерки и все такое вот

внедрение процессов да

давайте дальше ))

закопались в мелочках не столь важных

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

решаемые задачи.

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

время имеет значение - надо уожиться в отведенные пол года

процент охвата скоупа это очеивдно время которое тратится на * техническую добычу метрики. * техническое отдачу метрики * необходимые доработки мониторинга для приема метрики * создание триггера

что в свою очередь превращаетя в * изучение готовых инструментов * допилку инструментов * реализацию триггеров

процент охвата скоупа это очеивдно время которое тратится на * техническую добычу метрики. * техническое отдачу метрики * необходимые доработки мониторинга для приема метрики * создание триггера

очень обобщенно так.

есть другой подход ?

при использовании штатных инструментов и только их мы обречены считать условно cpu usage/ db rps / nginx active / memcache hitsmiss

необходимые доработки и создание триггера можно развернуть на детали - но думю это лишнее. если говорить о системе в целом

при использовании штатных инструментов и только их мы обречены считать условно cpu usage/ db rps / nginx active / memcache hitsmiss

разные системы могут сильно разное на основе этих штатных метрик

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

метрики такого уровня тоесть интерсные бизнесу нужно будет писать.

ибо на cpu usage бизнесу плевать.

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

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

тоесть кидает нас в пучину расчетов сколько стоит реализация бизнес метрики для бизнеса.

ибо на cpu usage бизнесу плевать.

до определнного предела

что очень завязано на протокол отдачи метрик.

на который тоже всем плевать.

тоесть кидает нас в пучину расчетов сколько стоит реализация бизнес метрики для бизнеса.

это в случае с манитом было более завязано на способ понимания что у нас вообще есть и как устроено