Если вы обратите внимание, то предлагаемые вами решения учтены в схеме — они являются обходным решение, пока отсутствуют ресурсы.
Если вы будете внимательны, то увидите, что в данном кейсе рассматривается ситуация, когда система внедряется без проектных виртуальных мощностей. В этом случае может быть так, что самый опытный DBA будет способен лишь снизить стоимость корневой причины, но не устранить её. И вендоры часто беспомощны.
Ваш юмор оправдан в случае маленького предприятия, когда количество информационных и инженерных систем с в районе тысячи, когда админы работают, как на конвейере, тогда становится не смешно.
Если погрузиться в тему, то можно увидеть множество серых зон и в ITIL. К примеру, вопрос распределения ответственности внутри процесса в соответствии с жизненным циклом ис. Вопросы разработки оптимальных сценариев процессов так же не проработаны. Механизмы взаимодействия процессов, базовые классификации, интеграции в цели бизнеса и многое другое осталось за рамками мышления британских учёных. Тут есть куда расти...
ITIL , как методология, остановился в развитии и всё меньше соответствует текущим потребностям.
Странно. Анализ по классике — это про отклонения. вызванные нарушением требований.
Анализ имеет свой жизненный цикл и методологию. У вас про это ничего.
Ваше грейдирование делает акцент на технических знаниях, но не на том, как выявить и устранить отклонение. Это отдельный вид искусства. Мне кажется, что вы довольно многое упустили, возможно, даже и суть аналитической деятельности.
Про симптомы —это да. Однако, работа с большей частью ошибок алгоритмизируема. Могут помочь общие принципы диагностики, логгирования, тестирования, организации моделирования решений проблем. Это очень занимательная задача обеспечения качества продукта.
Про практические примеры: нужно подумать, чтобы наглядно было. Вполне возможно, что это будет любопытно.
Про управление проблемами скорее всего будет. Эскалация инцидента в схеме не прорисована, потому, что под эскалацией я подразумевал перевод решения проблемы на организационный уровень. Учту разницу в пониманиях. Спасибо большое.
Всё. Понял: у нас разночтения определений. Ок. Эскалация инцидента или обращение к разработчику или мегаэксперту за помощью, прописывается в процессе управления инцидентами и контрактом с разработчиком/ поставщиком. Это алгоритмизируемая операция, которая на схеме не выделена и требует отдельного разговора. Может быть решена с помощью SLA/OLA, но здесь есть риск манипуляций. С моей точки зрения, лучше проактивно прорабатывать сценарии устранение инцидентов для особо критичных моментов эксплуатации. Хых. У меня в голове аналитик третьей линии поддержки — это эксперт, поэтому некоторая путаница. Аналитик же в моей парадигме — это мозг, оперирующий технологиями управления.
Обычно аналитик не является субъектом управления. Операционный директор отвечает за эксплуатацию. Он заказчик решения проблемы. Управление решением проблем — это скорее первый заместитель/исполнительный директор. Он обеспечивает взаимодействие с вендорами, разработчиками, поставщиками, от которых зависит организационная и ресурсная составляющие решения проблем.
Но, безусловно, очень много зависит от оргструктуры эксплуатации ИТ.
Это условная схема. Очень много зависит от организационной структуры эксплуатации ИТ и от зрелости процесса управления проблемами. При нормальной организации работы, администратор просто классифицирует проблему и дальше автоматически запускаются механизмы эскалации вверх и вбок. Так же автоматически запускается цепочка организационных изменений. Это, конечно, требует определенных навыков менеджмента. Обходные решения часто инициируются после анализа логов и первичной диагностики. У меня на практике организовано так, что админов курирует менеджер проблем по направлению, и, по сигналу админа решает организационные моменты.
По ходу придется пилить пост про проблемы. Если в минусы не загонят:)
Это понятно. Буду знать. Гибкие методы управления изменениями, в частности Agile , есть небольшая часть ITSM. Но всё равно спасибо за разъяснения.
Если вы обратите внимание, то предлагаемые вами решения учтены в схеме — они являются обходным решение, пока отсутствуют ресурсы.
Если вы будете внимательны, то увидите, что в данном кейсе рассматривается ситуация, когда система внедряется без проектных виртуальных мощностей. В этом случае может быть так, что самый опытный DBA будет способен лишь снизить стоимость корневой причины, но не устранить её. И вендоры часто беспомощны.
Ваш юмор оправдан в случае маленького предприятия, когда количество информационных и инженерных систем с в районе тысячи, когда админы работают, как на конвейере, тогда становится не смешно.
Если погрузиться в тему, то можно увидеть множество серых зон и в ITIL. К примеру, вопрос распределения ответственности внутри процесса в соответствии с жизненным циклом ис. Вопросы разработки оптимальных сценариев процессов так же не проработаны. Механизмы взаимодействия процессов, базовые классификации, интеграции в цели бизнеса и многое другое осталось за рамками мышления британских учёных. Тут есть куда расти...
ITIL , как методология, остановился в развитии и всё меньше соответствует текущим потребностям.
Странно. Анализ по классике — это про отклонения. вызванные нарушением требований.
Анализ имеет свой жизненный цикл и методологию. У вас про это ничего.
Ваше грейдирование делает акцент на технических знаниях, но не на том, как выявить и устранить отклонение. Это отдельный вид искусства. Мне кажется, что вы довольно многое упустили, возможно, даже и суть аналитической деятельности.
Про симптомы —это да. Однако, работа с большей частью ошибок алгоритмизируема. Могут помочь общие принципы диагностики, логгирования, тестирования, организации моделирования решений проблем. Это очень занимательная задача обеспечения качества продукта.
Про практические примеры: нужно подумать, чтобы наглядно было. Вполне возможно, что это будет любопытно.
В ваших рассуждениях есть попытка продать элементарную базу без понимания сути.
Почитайте Babok что-ли. Написано много но зря. Эх.
Про управление проблемами скорее всего будет. Эскалация инцидента в схеме не прорисована, потому, что под эскалацией я подразумевал перевод решения проблемы на организационный уровень. Учту разницу в пониманиях. Спасибо большое.
Всё. Понял: у нас разночтения определений. Ок. Эскалация инцидента или обращение к разработчику или мегаэксперту за помощью, прописывается в процессе управления инцидентами и контрактом с разработчиком/ поставщиком. Это алгоритмизируемая операция, которая на схеме не выделена и требует отдельного разговора. Может быть решена с помощью SLA/OLA, но здесь есть риск манипуляций. С моей точки зрения, лучше проактивно прорабатывать сценарии устранение инцидентов для особо критичных моментов эксплуатации. Хых. У меня в голове аналитик третьей линии поддержки — это эксперт, поэтому некоторая путаница. Аналитик же в моей парадигме — это мозг, оперирующий технологиями управления.
Обычно аналитик не является субъектом управления. Операционный директор отвечает за эксплуатацию. Он заказчик решения проблемы. Управление решением проблем — это скорее первый заместитель/исполнительный директор. Он обеспечивает взаимодействие с вендорами, разработчиками, поставщиками, от которых зависит организационная и ресурсная составляющие решения проблем.
Но, безусловно, очень много зависит от оргструктуры эксплуатации ИТ.
Это условная схема. Очень много зависит от организационной структуры эксплуатации ИТ и от зрелости процесса управления проблемами. При нормальной организации работы, администратор просто классифицирует проблему и дальше автоматически запускаются механизмы эскалации вверх и вбок. Так же автоматически запускается цепочка организационных изменений. Это, конечно, требует определенных навыков менеджмента. Обходные решения часто инициируются после анализа логов и первичной диагностики. У меня на практике организовано так, что админов курирует менеджер проблем по направлению, и, по сигналу админа решает организационные моменты.
По ходу придется пилить пост про проблемы. Если в минусы не загонят:)
Ну... Если вы увидели эту статью таким образом, то пусть так. :)