Comments 6
Не хочу быть занудой :) но это, по-сути описано в ITIL, он, конечно, не новое изобретение, и выглядит пыльно, но обидно наблюдать как в индустрии все наработки по-сути теряются.
По статье, молодцы, все сделали правильно.
По статье, молодцы, все сделали правильно.
❶ Про эксплуатацию и support, цитата: «Разбором инцидентов в нашей компании занимается отдел эксплуатации (или, проще, support).».
→Эксплуатация, это практическое использование (по назначению) производственных ресурсов для получения выгоды. В эксплуатацию, в том числе, входит и поддержка, но не входит разработка.
→Support – это только поддержание технического обеспечения в исправном состоянии, т.е. часть, но никак не эксплуатация в целом.
Чтобы утверждать, что занимаетесь эксплуатацией, нужно непосредственно реализовывать коммерческую выгоду. Вы ведь коммерческая организация? В целом? А сами, как работник, входите в состав ИТ подразделения, как часть организации? Смею утверждать, что речь, скорее всего, идёт об опорном процессе, поддерживающем основные (с западной т.з. основные = бизнес-процессы). Всего различают процессы: основные, опорные, качества. Кстати, поддержка (по Вашему Support) может быть бизнес процессом, а может и не быть им.
❷ Про инциденты, ЧП и т.д., цитата: «Инцидент (или сбой, ЧП) — это некая критическая (обычно массовая) проблема, которая существенно снижает доступность, корректность, эффективность или надежность бизнес-функционала или инфраструктурных систем.».
→ Инцидент, не является проблемой по определению. Упрощённо, в обывательской формулировке, инцидент это «что то не работает как нужно», но можно исправить собственными ресурсами, а проблема, это «невозможность восстановить собственными ресурсами» — нет знаний, нет оборудования и т.д… И уж тем более инцидент не является ЧП. Под ЧП Вы подразумевали чрезвычайное происшествие? Тогда потрудитесь изучить определение термина ЧП – непредвиденное событие повлекшее гибель людей, порчу имущества…
Шедеврально, цитата: «надежность бизнес-функционала или инфраструктурных систем». Попробуйте изучить понятия «надёжность» (собирательный термин), «бизнес», «функция» (как полезная работа), «инфраструктура» (есть ещё 2 структуры). Вас ждёт большой сюрприз, при осознании Вашего контекста…
Простите, но, в данном случае, как нельзя кстати, подходит выражение «Всё смешалось в доме Облонских…».
❸Про цели, цитата: «В рамках процесса управления инцидентами мы ставим перед собой следующие основные цели: 1.Как можно быстрее восстановить работоспособность наших систем …».
Основные? Значит есть дополнительные? Прелестно (сарказм).
→ Заявленный Вами нумерованный список, не является целями по определению, поскольку ни один из пунктов нельзя ни измерить ни достичь. Изучите, хотя бы, такие модные в последние 15 лет западные принципы S.M.A.R.T.
У процесса должна быть одна цель (goal, а не target (мишень)), которую следует декомпозировать на низ лежащие уровни. Или у Вас функция в составе процесса? Это не одно и тоже.
Пример цели: модернизировать техническое обеспечение корпоративной сети между точками A и B в узлах 1,2,3,4 имеющимися ресурсами.
Дополните цель рамками и допущениями.
Декомпозируйте на функции, задачи.
❹ Про мониторинг, цитата: «У нас была самописная система мониторинга, которая подразумевала самостоятельную подписку сотрудников на сообщения о проблемах…»
→ Мониторинг. Наблюдение и регистрация данных с неразрывно примыкающими интервалами с незначительно меняющимися данными. Различают мониторинг параметрический и состояния. Важна визуализация и оповещение… Важна интерпретация показателей.
Учитывая контекст, смею предположить, что у Вас не было и нет системы мониторинга. Скорее всего, речь идёт о недо-системе диагностики и журналировании событий, успешно выдаваемой руководству, как система мониторинга (см. определения «система», «диагностика», «журналирование», «мониторинг»).
Учитывая в целом контекст «статьи» и самостоятельную подписку, у Вас отсутствует формальная структура как часть организационного обеспечения.
Мониторинг по определению не может сообщать о проблемах (см.определение).
❺ Про фазы инцидентов, цитата «Разделили работу с инцидентами на две фазы — активную и ретроспективную».
Ативная-Пассивная. Ретроспективная-Перспективная. Вы хоть понимаете назначение применяемых терминов? (это риторический вопрос).
Начните, хотя бы, с русского языка – прошлое, настоящее, будущее.
Воздержитесь от применения таких терминов, как «превентивный» и т.д., если не понимаете их назначения.
█ Вы не только не осознаёте используемые термины, но ещё применяете жаргонизмы и псевдо-терминологию.
Создаёте автоматизированные системы по заведомо ложным ценностям.
В общем, судя по Вашей статье, как пишите, так организуете и реализовываете – беспорядок, ошибки, подмена понятий, дезорганизация и т.д…
Прочитав, скорее всего подумаете – но ведь у нас всё работает. Да, скажу, машина на 3-х колёсах тоже работает… т.е. с т.з. она неисправна, но работоспособна… какое-то время… в какой-то мере…
Как то так.
PS: Каждый работник компании не в состоянии поставить задачу, тем более, техническому работнику, поскольку нужно обладать не только техническими знаниями, но и умением ставить задачи как таковые (см. состав задачи), что подтверждается, как правило, наличием у них только потребности.
PSS: JIRA есть СОО (BTS) – Система Отслеживания Ошибок (bug tracking system), а не система отслеживания инцидентов. BTS нужна для ЖЦ объекта во время «Разработка» (Development), а не «Сопровождение» (Maintenance). Тем более, BTS не является системой управления документооборотом, что подтверждается анализом ЖЦ и составом объектов управления. Или, по другому, применяется не по назначению. Характеризуется эта ситуация неумением или невозможностью субъекта осознать естественных явлений или объектов, что есть по определению глупость. Это с академической т.з.
С обывательской, это как забивать гвозди микроскопом, потому что он тяжёлый и, таки, забивает. Однако есть плюс – продуцирование квази-деятельности в которой все заняты…
Удачи.
→Эксплуатация, это практическое использование (по назначению) производственных ресурсов для получения выгоды. В эксплуатацию, в том числе, входит и поддержка, но не входит разработка.
→Support – это только поддержание технического обеспечения в исправном состоянии, т.е. часть, но никак не эксплуатация в целом.
Чтобы утверждать, что занимаетесь эксплуатацией, нужно непосредственно реализовывать коммерческую выгоду. Вы ведь коммерческая организация? В целом? А сами, как работник, входите в состав ИТ подразделения, как часть организации? Смею утверждать, что речь, скорее всего, идёт об опорном процессе, поддерживающем основные (с западной т.з. основные = бизнес-процессы). Всего различают процессы: основные, опорные, качества. Кстати, поддержка (по Вашему Support) может быть бизнес процессом, а может и не быть им.
❷ Про инциденты, ЧП и т.д., цитата: «Инцидент (или сбой, ЧП) — это некая критическая (обычно массовая) проблема, которая существенно снижает доступность, корректность, эффективность или надежность бизнес-функционала или инфраструктурных систем.».
→ Инцидент, не является проблемой по определению. Упрощённо, в обывательской формулировке, инцидент это «что то не работает как нужно», но можно исправить собственными ресурсами, а проблема, это «невозможность восстановить собственными ресурсами» — нет знаний, нет оборудования и т.д… И уж тем более инцидент не является ЧП. Под ЧП Вы подразумевали чрезвычайное происшествие? Тогда потрудитесь изучить определение термина ЧП – непредвиденное событие повлекшее гибель людей, порчу имущества…
Шедеврально, цитата: «надежность бизнес-функционала или инфраструктурных систем». Попробуйте изучить понятия «надёжность» (собирательный термин), «бизнес», «функция» (как полезная работа), «инфраструктура» (есть ещё 2 структуры). Вас ждёт большой сюрприз, при осознании Вашего контекста…
Простите, но, в данном случае, как нельзя кстати, подходит выражение «Всё смешалось в доме Облонских…».
❸Про цели, цитата: «В рамках процесса управления инцидентами мы ставим перед собой следующие основные цели: 1.Как можно быстрее восстановить работоспособность наших систем …».
Основные? Значит есть дополнительные? Прелестно (сарказм).
→ Заявленный Вами нумерованный список, не является целями по определению, поскольку ни один из пунктов нельзя ни измерить ни достичь. Изучите, хотя бы, такие модные в последние 15 лет западные принципы S.M.A.R.T.
У процесса должна быть одна цель (goal, а не target (мишень)), которую следует декомпозировать на низ лежащие уровни. Или у Вас функция в составе процесса? Это не одно и тоже.
Пример цели: модернизировать техническое обеспечение корпоративной сети между точками A и B в узлах 1,2,3,4 имеющимися ресурсами.
Дополните цель рамками и допущениями.
Декомпозируйте на функции, задачи.
❹ Про мониторинг, цитата: «У нас была самописная система мониторинга, которая подразумевала самостоятельную подписку сотрудников на сообщения о проблемах…»
→ Мониторинг. Наблюдение и регистрация данных с неразрывно примыкающими интервалами с незначительно меняющимися данными. Различают мониторинг параметрический и состояния. Важна визуализация и оповещение… Важна интерпретация показателей.
Учитывая контекст, смею предположить, что у Вас не было и нет системы мониторинга. Скорее всего, речь идёт о недо-системе диагностики и журналировании событий, успешно выдаваемой руководству, как система мониторинга (см. определения «система», «диагностика», «журналирование», «мониторинг»).
Учитывая в целом контекст «статьи» и самостоятельную подписку, у Вас отсутствует формальная структура как часть организационного обеспечения.
Мониторинг по определению не может сообщать о проблемах (см.определение).
❺ Про фазы инцидентов, цитата «Разделили работу с инцидентами на две фазы — активную и ретроспективную».
Ативная-Пассивная. Ретроспективная-Перспективная. Вы хоть понимаете назначение применяемых терминов? (это риторический вопрос).
Начните, хотя бы, с русского языка – прошлое, настоящее, будущее.
Воздержитесь от применения таких терминов, как «превентивный» и т.д., если не понимаете их назначения.
█ Вы не только не осознаёте используемые термины, но ещё применяете жаргонизмы и псевдо-терминологию.
Создаёте автоматизированные системы по заведомо ложным ценностям.
В общем, судя по Вашей статье, как пишите, так организуете и реализовываете – беспорядок, ошибки, подмена понятий, дезорганизация и т.д…
Прочитав, скорее всего подумаете – но ведь у нас всё работает. Да, скажу, машина на 3-х колёсах тоже работает… т.е. с т.з. она неисправна, но работоспособна… какое-то время… в какой-то мере…
Как то так.
PS: Каждый работник компании не в состоянии поставить задачу, тем более, техническому работнику, поскольку нужно обладать не только техническими знаниями, но и умением ставить задачи как таковые (см. состав задачи), что подтверждается, как правило, наличием у них только потребности.
PSS: JIRA есть СОО (BTS) – Система Отслеживания Ошибок (bug tracking system), а не система отслеживания инцидентов. BTS нужна для ЖЦ объекта во время «Разработка» (Development), а не «Сопровождение» (Maintenance). Тем более, BTS не является системой управления документооборотом, что подтверждается анализом ЖЦ и составом объектов управления. Или, по другому, применяется не по назначению. Характеризуется эта ситуация неумением или невозможностью субъекта осознать естественных явлений или объектов, что есть по определению глупость. Это с академической т.з.
С обывательской, это как забивать гвозди микроскопом, потому что он тяжёлый и, таки, забивает. Однако есть плюс – продуцирование квази-деятельности в которой все заняты…
Удачи.
PSS: JIRA есть СОО (BTS) – Система Отслеживания Ошибок (bug tracking system), а не система отслеживания инцидентов. BTS нужна для ЖЦ объекта во время «Разработка» (Development), а не «Сопровождение» (Maintenance).…Мёсье потрудился посмотреть JIRA и выяснить, что в ней довольно-таки много различных доп.модулей, которые делают из JIRA почти всё, что угодно?
С обывательской, это как забивать гвозди микроскопом, потому что он тяжёлый и, таки, забивает
Ваше предложение состоит исключительно из сущностных квантификаторов и относительных ссылок, но без указания точки отсчёта, т.е. не представляет информационной ценности — не информативно.
Пример: те или иные, всякие разные, довольно много, различные.
Обращение «месье» неуместно.
Желаете дискуссии, извольте обосновать (см.определение) позицию в явной форме. Я готов. Риторика и демагогия меня не интересует.
Пример: те или иные, всякие разные, довольно много, различные.
Обращение «месье» неуместно.
Желаете дискуссии, извольте обосновать (см.определение) позицию в явной форме. Я готов. Риторика и демагогия меня не интересует.
Вижу, коллега, вашу позицию, как абсолютно противоположную, подходу описанному в статье.
Т.е. В статье описано как можно пару колес скрутить и превратить, с помощью пары палок, в велосипед и поехать. Вы же, судя по всему, сторонник академического подхода.
Мне тоже больно, что не хотят, понимаешь ли, купить отличный, готовый продукт из класса ITSM решений с нормальным консалтингом. И ведь знаю, что в Tutu работают товарищи, съевшие на теме ITSM собаку. ( или уже работали).
Глоссарий не используют из ITIL, да, велосипед переизобретают, да. Но свою потребность закрыли.
Сможете в статье описать так, чтоб все бросились выкидывать JIRA в окно? Боюсь сейчас время когда большинство решений — наколенная поделка JIT( без презрения, сам такой же)
Т.е. В статье описано как можно пару колес скрутить и превратить, с помощью пары палок, в велосипед и поехать. Вы же, судя по всему, сторонник академического подхода.
Мне тоже больно, что не хотят, понимаешь ли, купить отличный, готовый продукт из класса ITSM решений с нормальным консалтингом. И ведь знаю, что в Tutu работают товарищи, съевшие на теме ITSM собаку. ( или уже работали).
Глоссарий не используют из ITIL, да, велосипед переизобретают, да. Но свою потребность закрыли.
Сможете в статье описать так, чтоб все бросились выкидывать JIRA в окно? Боюсь сейчас время когда большинство решений — наколенная поделка JIT( без презрения, сам такой же)
По поводу колёс и палок. Контекст Вашего комментария соответствует принципу аналогии и ассоциативной связи, что снижает точность и достоверность оценки. Контекст моего комментария предельно ясен – ошибочность технических и организационных решений. Применение продуктов не в соответствие с их назначением. Если оценивать с позиции велосипеда, то последний предназначен для увеличения скорости перемещения человека. Используемая в ТУТУ.РУ АС управляет объектом типа электронный документ. Потребность состояла в увеличении скорости перемещения инцидентов? Это риторический вопрос. Переход от объективных оценок к субъективным приводит к искажению информации. Каждая последующая субъективная оценка вносит дополнительное искажение.
Про потребность. Предполагаю, что находясь на этапе неосознанного незнания, вполне себе можно мыслить, что потребность закрыта, но от мнения человека объективная реальность не зависит… Вспоминается рассказ про обезьян, банан и холодную воду…
Про покупку. Покупать? А обоснование есть? У работников есть аналитическая записка по выбору ПО для автоматизации? На основании моего опыта, сомневаюсь. Предполагаю, что выбор был по ощущениям «как уже те ребята сделали». Впрочем, проверить ведь не сложно. А нужно? Например, руководителю ИТ? И снова – каждое ошибочное решение вносить дополнительно искажение, усугубляя состояние…
Про статью. Что бы создать предметную статью, содержащую знания, нужна предметная постановка цели. Интересы (политические, экономические…). Далее, естественно, с декомпозицией на задачи и т.д. Входящие данные, типа «Сделать хорошо, чтобы все выбросили в окно» (утрирую), для анализа не подходят.
PS: Собаку есть не надо =), надо демонстрировать компетентность. Желательно на бумаге, поскольку на ней видна вся глупость человеческая. К тому же, человеку нельзя помочь, пока он этого сам не захочет, т.е. не перейдёт в состояние осознанного незнания и готовности к действиям.
Про потребность. Предполагаю, что находясь на этапе неосознанного незнания, вполне себе можно мыслить, что потребность закрыта, но от мнения человека объективная реальность не зависит… Вспоминается рассказ про обезьян, банан и холодную воду…
Про покупку. Покупать? А обоснование есть? У работников есть аналитическая записка по выбору ПО для автоматизации? На основании моего опыта, сомневаюсь. Предполагаю, что выбор был по ощущениям «как уже те ребята сделали». Впрочем, проверить ведь не сложно. А нужно? Например, руководителю ИТ? И снова – каждое ошибочное решение вносить дополнительно искажение, усугубляя состояние…
Про статью. Что бы создать предметную статью, содержащую знания, нужна предметная постановка цели. Интересы (политические, экономические…). Далее, естественно, с декомпозицией на задачи и т.д. Входящие данные, типа «Сделать хорошо, чтобы все выбросили в окно» (утрирую), для анализа не подходят.
PS: Собаку есть не надо =), надо демонстрировать компетентность. Желательно на бумаге, поскольку на ней видна вся глупость человеческая. К тому же, человеку нельзя помочь, пока он этого сам не захочет, т.е. не перейдёт в состояние осознанного незнания и готовности к действиям.
Sign up to leave a comment.
Процесс управления инцидентами в Туту.ру