Нет

Спасибо

Я думаю никто не поделится, это же хлеб админов

Это внутренний документ

А можете поделиться драфтом или концепцией?

А что ты собрался оттуда утаскивать? У тебя нет требований, каким должен быть у тебя мониторинг?

Вам достаточно проштудировать ITIL и или MOF

Моф от MS вообще шикарен

Это внутренний документ

Само собой, даже если не внутренный, то уникальные знания делают контору/сотрудника ценным

не совсем понятно что такое концепция мониторинга. Типа как мониторится, что-за сборка, триггеры и вооще что может мой заббикс?

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

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

Вообще не так

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

Это больше SLA/OLA

Найдите MOF раздел по мониторингу

А что ты собрался оттуда утаскивать? У тебя нет требований, каким должен быть у тебя мониторинг?

Нет. Илья, на конфе ты сам говорил, что мониторинг это не только лампоски, но и реакция на них. 3 уровнч тригеров и дальнейшая ескалация.

Нет. Илья, на конфе ты сам говорил, что мониторинг это не только лампоски, но и реакция на них. 3 уровнч тригеров и дальнейшая ескалация.

И? У нас есть требования, которые при этом меняются. У тебя нет требований?

Это больше SLA/OLA

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

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

У вас каша

Найдите MOF раздел по мониторингу

Ок, попробую. Спасиьо

И? У нас есть требования, которые при этом меняются. У тебя нет требований?

Нет

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

Там будут и сервисы

И карта зависимостей

И роли

https://www.microsoft.com/ru-ru/download/details.aspx?id=23221

У вас каша

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

Не

Не так

https://www.microsoft.com/ru-ru/download/details.aspx?id=23221

Спасибо.

)

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

Неявные - это зависимости

Сервис зависит и от него могут зависеть

Итд

SLA - это с бизнесом соглашение

OLA - внутри по сути

Оперейшен левел

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

Я пару раз и разрабатывал стратегию, концепцию мониторинга. И строил процесс управления инцидентами (как реакция на срабатывание мониторинга)

Занимательное дело

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

Хелпдеск/Сервисдеск

По управлению инцидентами мне больше всего понравилось в Гугле - про SRE

OLA - внутри по сути

Согласен, есть даже примерное понимание, но не с ядром на конкретном заббиксе

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

Могу поделится великолепным источником знаний. Освоив который вы сможете «сделать» такую реакцию, которая нужна именно вам

По управлению инцидентами мне больше всего понравилось в Гугле - про SRE

https://landing.google.com/sre/

Занимательное дело

Согласен, но примеров мало можно найти.

Там есть примеры разбора полетов даже

Могу поделится великолепным источником знаний. Освоив который вы сможете «сделать» такую реакцию, которая нужна именно вам

Если можнл.

Это нормально, что на SSD mysqldump при дампе дает 350 iops чтения ? 20-30 МБ в сек. Даже если без зипа. source и dest на одном волюме. Фигня какая-то. Что там еще можно подстроить ему

Там есть примеры разбора полетов даже

Спасибо. Посмотрю, изучу.

Я б рекомендовал с каталога сервисов начать

Ок, спасибо

И параллельно все вести в терминологии ITIL/ITSM

Не знаю где взять в электронном виде. В бумажном продаётся Cleverics

А после у каждого сервиса будет SLA

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

Это нормально, что на SSD mysqldump при дампе дает 350 iops чтения ? 20-30 МБ в сек. Даже если без зипа. source и dest на одном волюме. Фигня какая-то. Что там еще можно подстроить ему

Размер базы?

ФС?

ext4 350 гиг

dd тест что покажет?

К примеру чтение из урандома и создание файла размером 50ГБ

Сам ссд не загибается?

Какой ссд?

dd if=/dev/urandom of=/mnt/ssd/dd_test_out bs=8k count=1M 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 57.2294 s, 150 MB/s dd if=/dev/zero of=/mnt/ssd/dd_test_out bs=8k count=1M 8589934592 bytes (8.6 GB, 8.0 GiB) copied, 13.3251 s, 645 MB/s

такое норм ?

может в винде гипервизоре дело ...

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

Загружали алярмы в 1с itil, оттуда распределение заявок первой линией по сотрудникам 2,3 ....

такое норм ?

пойдет

ERROR: S client not available

покажи как бекап делаешь

команду

с зипом mysqldump -q --single-transaction -u -p db | gzip > dump.sql.gz

без зипа несильно лучше чтение

в конфиге еще такое есть, но видимо не то что интересно max_allowed_packet = 1G

самое смешное в хранилке кэш еще должен дейстовать

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

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

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

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

И тут я с вами соглашусь .:) Именно это и систематизируется (а затем и автоматизируется и измеряется) в процессах управления инцидентами и проблемами

Извините, а можно эти схемы в не пожатом виде?

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

Ок, вопросов нет

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

Благодарю!

А кто какие тикет-системы использует?)

Jira/Redmine/Bitrix24

Не начинайте срач только

А то мы уже плююемся от нашей, перепиливали, допиливали, все равно что-то не то

Не начинайте срач только

Не)

Мне чисто советом помочь)))

А то мы уже плююемся от нашей, перепиливали, допиливали, все равно что-то не то

а что у вас?

osTicket

не слышал даже

в который сами ещё и полезли допиливать функционал

я б рекомендовал если есть $$$ брать Jira

если не хочется тратить $$$ - брать Redmine

ну и приструнить хотелки. сам при внедрении с такими хотелками сталкивался - в 80% удавалось уговорить не допиливать функционал а пользоваться стандартным

Посмотрите GLPI, опенсорс и не плох

Стандартный функционал не сможет выгрузить отчёты в том формате, в котором нам надо)