Комментарии 5
Можно ли пользоваться услугой?
Ухудшилось ли качество услуг?
Пострадали ли бизнес-процессы?
Пострадало ли качество предоставления услуги?
Если вы ответили «да» на один из этих вопросов, скорее всего, вы столкнулись с инцидентом.
Можно ли пользоваться услугой? Да.
Инцидент?
В оригинале так:
Is the service unusable?
Is there a degradation of the service?
Is the business process affected greatly?
Are service levels affected?
Я бы первый вопрос перевел: Услуга недоступна?
Вопрос: если решение инцедента приведёт к заметанию следов причин возникновения проблемы — насколько правильно решать его сразу? Вопрос не праздный. Сервис на сервере завис — сервер перезагрузили — инцидент решён. А проблема осталась: никто не знает почему завис сервис — логи при перезагрузке потерялись, объемы занимаемой памяти и активность дисковой подсистемы никто не снял и т.д… В идеале за технической стороной вопроса, конечно, должен смотреть мониторинг. В реальной жизни — неучтённые обстоятельства бывают всегда, как мне кажется.
>… насколько правильно решать его сразу?
Зависит от вашего SLA. Если уровень сервиса позволяет дождаться специалиста, который займётся поиском причины на месте — правильно его дождаться. А если у вас по SLA допустимое время простоя — 3 минуты, то перезагружаем сразу, потом делаем снэпшот и на препродуктовой среде пробуем воспроизвести баг для поиска проблемы.
Как-то так.
Зависит от вашего SLA. Если уровень сервиса позволяет дождаться специалиста, который займётся поиском причины на месте — правильно его дождаться. А если у вас по SLA допустимое время простоя — 3 минуты, то перезагружаем сразу, потом делаем снэпшот и на препродуктовой среде пробуем воспроизвести баг для поиска проблемы.
Как-то так.
Настолько сложно все описали, что даже сами запутались и ввели людей в заблуждение. Если коротко: инцидент — отклонение от нормального функционирование, проблема — причина повторяющихся инцидентов. Замена пробитого колеса на докатку — это обходное решение инцидента, проблема — это гвозди на дороге из-за которых колеса постоянно пробиваются.
Управление инцидентами — процесс, направленный на оперативное восстановление работы отказавших систем. Управление проектами — процесс, направленный на анализ причин повторяющихся сбоев и устранение этих причин (если это экономически обосновано).
Как по мне, разница между Helpdesk и ServiceDesk небольшая. В реальности и то и другое в компаниях используется практически одинаково. Ну и да, ни один ServiceDesk не умеет обнаруживать повторяющиеся инциденты в автоматическом режиме и создавать проблему — все же это делает руками человек. Остальные выводы относительно различия Helpdesk и ServiceDesk попахивают булшит.
Управление инцидентами — процесс, направленный на оперативное восстановление работы отказавших систем. Управление проектами — процесс, направленный на анализ причин повторяющихся сбоев и устранение этих причин (если это экономически обосновано).
Как по мне, разница между Helpdesk и ServiceDesk небольшая. В реальности и то и другое в компаниях используется практически одинаково. Ну и да, ни один ServiceDesk не умеет обнаруживать повторяющиеся инциденты в автоматическом режиме и создавать проблему — все же это делает руками человек. Остальные выводы относительно различия Helpdesk и ServiceDesk попахивают булшит.
Нашёл данную статью весьма интересной. Не могу не высказаться.
По порядку.
❶ Про мнение, цитата: «Второе отличие, по мнению Майкла, заключается в том, что инцидент можно разрешить только на определённое время. …».
→ Инцидент характеризуется временем, местом и сутью, т.е. другими словами когда, где и с чем произошло, о чём не пишет ITIL. На самом деле, изменение одной из 3-х составляющих приведёт к появлению нового инцидента, а не повторению предыдущего. Мера же воздействия инцидента на пользователей, является отдельным аспектом не оказывающим влияния на характеристики самого инцидента (метод обратной связи). Это надо уметь осознать.
→ Проблема. Характеризуется отсутствием алгоритма её устранения, основанной на недостатке имеющихся знаний и технического обеспечения. Это упрощённо.
Важно: Привлекая ресурсы извне, устраняя недостатки в ресурсах, т.е. нечто обладающее возможностью разрешить проблему, последняя преобразуется в задачу:
Учитывая вышеописанное, лишний раз убеждаешься в том, что мнение присутствует каждый раз, когда отсутствует знание…
❷ Про признак проблемы, цитата: ”профессор Росс Вайз (P. Ross S. Wise) считает, что первый признак проблемы — вопрос «почему»…”
→ Техника может быть:
Рассмотрим на примере единственного неисправного и неработоспособного принтера в отделе продаж:
Важно: проблема понятие относительное. Для пользователя, неисправность это проблема, а для техника — инцидент (см. определение п.1).
Первый признак проблемы это не «почему», а невозможность обеспечить работоспособность технического обеспечения собственными ресурсами (это есть критерий). И неважно, известно «почему», т.е. идентифицированное место и причина, или нет, поскольку причина выявляется только по результату диагностики (выявление места и причины неисправности). Данная ошибка основана на классическом обобщение, что приводит к снижению точности и достоверности информации. Чтобы возникло понимание, вольно приравняю «Почему» к декомпозированной формулировке «невозможность обеспечить работоспособность технического обеспечения собственными ресурсами».
Да, методическая формулировка сложнее для понимания, в отличие от обывательской формулировки выраженной в виде мнения, но зато позволяет идентифицировать наличие проблемы на основе критерия, а не ощущения. Выяснять же, к какой именно науке относиться звание профессора Росс Вайз, не имеет смысла, поскольку звание, само по себе, не является доказательством. Также может иметь место ошибка репортёра/редактора/ переводчика.
❸ Про примеры, цитата: «Вы едете на машине, и у неё лопнуло колесо…». Следствием выбранной автором ошибочной системы ценностей, является ложность приведённых им примеров.
Исправим заблуждения учитывая мои п.п.1-2.
Изначально у автора, цитата: «Вы едете на машине, и у неё лопнуло колесо. Это инцидент, потому что прокол нарушил ваши планы: вам приходится останавливаться, чтобы заменить колесо. В этом случае инцидент считается исчерпанным. Но теперь у вас есть проблема — вы едете на запасном колесе. Чтобы устранить проблему, вам нужно залатать покрышку.»
Рассматривать следует как систему, надсистему, так и подсистему, причём в совокупности прошлое, настоящее и будущее.
Утверждение автора ложно, поскольку запасное колесо не является частью системы автомобиля до момента установки в него (интеграция), а также перестает быть частью системы после снятия (см. определение терминов). Не являясь частью системы «автомобиль», колесо перестаёт выполнять полезную работу, в результате чего к нему не применимо понятие инцидент или проблема, зато применимы понятия неисправна и работоспособна, что методически верно с тех. т.з…
Итого, на примерах:
На основании вышеизложенного могу утверждать, что имеет место классический вариант подмены знания мнением, с последующим построением ложных умозаключений и приведением соответствующих примеров. Также следует учитывать, что ITIL описывает организационное обеспечение, причём частично, а применяется к техническому обеспечению, что заведомо ложно.
Если проще и по методу аналогии, то с таким же успехом можно утверждать, что бревно это карандаш, потому что оно деревянное, хотя это не так, поскольку назначение и функции карандаша и бревна отличаются, и это очевидно при первом же осмыслении.
█ Вместо заключения.
Проблема (см.определение) таких документов как ITIL состоит в их гуманитарном контексте и позиционировании как методологии по техническим вопросам, хотя таковыми они не являются по своему содержанию.
Проблема пользователей, использующих такие документы, заключается в невозможности осознания.
Количество не значит качество — массовый выброс подобных статей формирует ложную систему ценностей…
Из выше описанного следует делать вывод, что первичное значение имеет знание и осознание в совокупности с обоснованием (можно доказательством), а не вера в некое мнение. Следует не только выражаться в виде утверждений, но и трудится присовокуплять к ним подтверждения, что по своему составу уже будет уже обоснованием, хотя и не доказательством.
Что касается полезной работы Интеграторов, внедряющих автоматизацию по «таким» системам ценностей, в результате будем получать классический «даёшь внедрёж».
Желаю всем включать мозг и знания, а не «сердце» и мнение, поскольку этим широко пользуются маркетологи.
PS: Попугая можно научить говорить E=mc^2, однако для него это будет всего лишь совокупность звуков, а не знание как таковое.
PSS: Не всё заграничное хорошо. В России тоже достаточно накопленных знаний, надо лишь уметь их найти и осознать, а не гонятся за модными маркетинговыми выбросами типа DevOps и т.д…
По порядку.
❶ Про мнение, цитата: «Второе отличие, по мнению Майкла, заключается в том, что инцидент можно разрешить только на определённое время. …».
→ Инцидент характеризуется временем, местом и сутью, т.е. другими словами когда, где и с чем произошло, о чём не пишет ITIL. На самом деле, изменение одной из 3-х составляющих приведёт к появлению нового инцидента, а не повторению предыдущего. Мера же воздействия инцидента на пользователей, является отдельным аспектом не оказывающим влияния на характеристики самого инцидента (метод обратной связи). Это надо уметь осознать.
→ Проблема. Характеризуется отсутствием алгоритма её устранения, основанной на недостатке имеющихся знаний и технического обеспечения. Это упрощённо.
Важно: Привлекая ресурсы извне, устраняя недостатки в ресурсах, т.е. нечто обладающее возможностью разрешить проблему, последняя преобразуется в задачу:
- Известное начальное состояние (дано).
- Известное конечное состояние (найти)
- Алгоритм достижения от начального к конечному состоянию (решение).
Учитывая вышеописанное, лишний раз убеждаешься в том, что мнение присутствует каждый раз, когда отсутствует знание…
❷ Про признак проблемы, цитата: ”профессор Росс Вайз (P. Ross S. Wise) считает, что первый признак проблемы — вопрос «почему»…”
→ Техника может быть:
- Неисправна, но работоспособна (например, неисправность турбины в дизельном ДВС, что позволяет медленно, но ехать).
- Неисправна и не работоспособна (например, заклинивший ДВС).
- Исправна, но неработоспособна (например, нет топлива в автомобиле).
Рассмотрим на примере единственного неисправного и неработоспособного принтера в отделе продаж:
- У компании №1 нет тех.персонала имеющего компетентность по ремонту оргтехники – проблема.
- У компании №2 есть тех.персонал имеющий компетентность по ремонту оргтехники – инцидент.
Важно: проблема понятие относительное. Для пользователя, неисправность это проблема, а для техника — инцидент (см. определение п.1).
Первый признак проблемы это не «почему», а невозможность обеспечить работоспособность технического обеспечения собственными ресурсами (это есть критерий). И неважно, известно «почему», т.е. идентифицированное место и причина, или нет, поскольку причина выявляется только по результату диагностики (выявление места и причины неисправности). Данная ошибка основана на классическом обобщение, что приводит к снижению точности и достоверности информации. Чтобы возникло понимание, вольно приравняю «Почему» к декомпозированной формулировке «невозможность обеспечить работоспособность технического обеспечения собственными ресурсами».
Да, методическая формулировка сложнее для понимания, в отличие от обывательской формулировки выраженной в виде мнения, но зато позволяет идентифицировать наличие проблемы на основе критерия, а не ощущения. Выяснять же, к какой именно науке относиться звание профессора Росс Вайз, не имеет смысла, поскольку звание, само по себе, не является доказательством. Также может иметь место ошибка репортёра/редактора/ переводчика.
❸ Про примеры, цитата: «Вы едете на машине, и у неё лопнуло колесо…». Следствием выбранной автором ошибочной системы ценностей, является ложность приведённых им примеров.
Исправим заблуждения учитывая мои п.п.1-2.
Изначально у автора, цитата: «Вы едете на машине, и у неё лопнуло колесо. Это инцидент, потому что прокол нарушил ваши планы: вам приходится останавливаться, чтобы заменить колесо. В этом случае инцидент считается исчерпанным. Но теперь у вас есть проблема — вы едете на запасном колесе. Чтобы устранить проблему, вам нужно залатать покрышку.»
Рассматривать следует как систему, надсистему, так и подсистему, причём в совокупности прошлое, настоящее и будущее.
Утверждение автора ложно, поскольку запасное колесо не является частью системы автомобиля до момента установки в него (интеграция), а также перестает быть частью системы после снятия (см. определение терминов). Не являясь частью системы «автомобиль», колесо перестаёт выполнять полезную работу, в результате чего к нему не применимо понятие инцидент или проблема, зато применимы понятия неисправна и работоспособна, что методически верно с тех. т.з…
Итого, на примерах:
- В машине не оказалось запасного колеса – невозможно устранить собственными ресурсами => проблема, т.к. отсутствует тех.обеспечение.
- В машине нет запасного колеса, но неисправное колесо RunFlat => инцидент, т.к. тех.система неисправна, но работоспособна.
- 3. В машине есть запасное колесо, но водитель девушка и не в состоянии его заменить => проблема в части анатомии (сила), компетентности (частный случай навык) и т.д..
- В машине есть запасное колесо, домкрат и у водителя достаточно знаний и умений => инцидент, т.к. оперативно устраняется.
- И т.д.
На основании вышеизложенного могу утверждать, что имеет место классический вариант подмены знания мнением, с последующим построением ложных умозаключений и приведением соответствующих примеров. Также следует учитывать, что ITIL описывает организационное обеспечение, причём частично, а применяется к техническому обеспечению, что заведомо ложно.
Если проще и по методу аналогии, то с таким же успехом можно утверждать, что бревно это карандаш, потому что оно деревянное, хотя это не так, поскольку назначение и функции карандаша и бревна отличаются, и это очевидно при первом же осмыслении.
█ Вместо заключения.
Проблема (см.определение) таких документов как ITIL состоит в их гуманитарном контексте и позиционировании как методологии по техническим вопросам, хотя таковыми они не являются по своему содержанию.
Проблема пользователей, использующих такие документы, заключается в невозможности осознания.
Количество не значит качество — массовый выброс подобных статей формирует ложную систему ценностей…
Из выше описанного следует делать вывод, что первичное значение имеет знание и осознание в совокупности с обоснованием (можно доказательством), а не вера в некое мнение. Следует не только выражаться в виде утверждений, но и трудится присовокуплять к ним подтверждения, что по своему составу уже будет уже обоснованием, хотя и не доказательством.
Что касается полезной работы Интеграторов, внедряющих автоматизацию по «таким» системам ценностей, в результате будем получать классический «даёшь внедрёж».
Желаю всем включать мозг и знания, а не «сердце» и мнение, поскольку этим широко пользуются маркетологи.
PS: Попугая можно научить говорить E=mc^2, однако для него это будет всего лишь совокупность звуков, а не знание как таковое.
PSS: Не всё заграничное хорошо. В России тоже достаточно накопленных знаний, надо лишь уметь их найти и осознать, а не гонятся за модными маркетинговыми выбросами типа DevOps и т.д…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Как близнецы»: 3 пары похожих терминов ITIL