— Б-любимые, — озадаченно сказал Федор Симеонович, разобравшись в почерке.
– Это п-задача Бена Б-бетцалеля.
К-калиостро доказал, что она п-не имеет р-решения.
«Мы сами знаем, что у нее нет решения», — тут же ощетинилась Хунта.
«Мы хотим знать, как решить эту проблему».
– Н-ты странно рассуждаешь, К-Христо.
Н-как ты ищешь решение, когда его нет? Б-чушь какая-то.
- Извините, Теодор, но ваши рассуждения очень странные.
Глупо искать решение, если оно уже существует. Речь идет о том, как справиться с проблемой, которая не имеет решения.
Это глубоко принципиальный вопрос, который, как я вижу, вам, учёному-прикладнику, к сожалению, недоступен.
По-моему, я зря заговорил с вами на эту тему.
Понедельник начинается в субботу.
А.
и Б.
Стругацкие
Введение
Любой поиск решения проблемы состоит из ряда шагов, независимо от характера проблемы.Такой технологический подход позволяет вполне успешно работать над проблемой, даже если совершенно не ясно, с какой стороны подойти к решению.
Хотя в этой статье слегка упоминается специфика местных условий, сам процесс описан достаточно абстрактно, так что его можно использовать даже для устранения ошибок в ИТ-системе, или для устранения неполадок в бытовой электронике, или для разрешения межличностных конфликтов.
Выявление проблемы
Нет смысла приступать к решению проблемы, пока она не сформулирована – либо будет найдено неправильное решение, либо оно никому не нужно.Но в любом случае результат будет бесполезен и усилия окажутся напрасными.
Первое, что нужно сделать, это выявить проблему.
Разберитесь, что, где и как работает неправильно.
Определите компонент системы, генерирующий ошибку, получите диагностику, показывающую наличие проблемы.
Результатом этого шага должна стать следующая собранная информация: Где произошла ошибка - имя (файл) формы или отчета, точная версия.
Сообщение об ошибке дословно, посимвольно, записано в виде текста (для возможности последующего поиска скриншотов для этого недостаточно); если ошибка в файле журнала, то имя и расположение такого файла.
Среда, в которой возникла проблема — производственная система, система проектов, тестовая система, все вышеперечисленное.
Воспроизводится ли эта проблема, характер воспроизведения - на всех данных, на определенных данных или при определенных условиях, единичный сбой, плавающая ошибка.
Шаги, которые привели к проблеме, и если проблема воспроизводима, то они также будут тестовым сценарием.
Оценка влияния проблемы – серьезность самой проблемы и ожидаемых последствий; сколько транзакций или пользователей затронуто; сроки решения проблемы и влияние на закрытие периода; общая сумма транзакций, затронутые VIP-персоны и другие факторы, важные в контексте проблемы.
Собранная информация должна быть документирована.
Цель этого шага: Зафиксируйте факт наличия проблемы.
Найдите и запишите место проблемы в системе.
Полученные ключевые слова (название и версия компонента, сообщения об ошибках) можно использовать при поиске в доступных базах знаний – внутренних системах, Металинк, в Интернете.
Если подобная проблема встретится в будущем, то после выявления этой новой проблемы с высокой вероятностью должно быть найдено существующее решение.
Такое описание проблемы является завершенным этапом работы; последующие шаги (анализ, поиск решений и т. д.) могут быть продолжены другим исполнителем или такая работа может выполняться параллельно.
Качество этого этапа легко оценить.
Ознакомившись с этой информацией, вы сможете сразу приступить к решению проблемы, не задавая дополнительных уточняющих вопросов.
Анализ проблемы и поиск причин
Как только место проблемы будет определено, можно приступать к поиску причин.Полезными приемами в этом случае являются: Трассировка — позволяет найти код, который работал некорректно или выдавал ошибку; позволит увидеть, что последнее было выполнено, если нет четкой диагностики проблемы.
Анализ исполняемого кода — вместе с сообщением об ошибке даст гипотезы, почему код не работает должным образом.
Отладка (в том числе вывод диагностики) – позволит определить, выполняются ли предположения о логике работы, значениях переменных, а также увидеть, выполняется ли вообще диагностируемый участок кода.
Анализ данных (чем проблемные данные отличаются от остальных) позволит вам сосредоточиться на коде, в котором происходит обработка именно таких разных данных.
Анализ причин и поиск решения происходят по известной схеме: Сформулируем гипотезу о причине ошибки.
Проверим сформулированную гипотезу: исправляем код или данные, сделать пробный запуск Давайте проанализируем результат. Если гипотеза не подтверждается, начинаем с начала.
Результатом данного этапа должна стать найденная причина проблемы.
Результат должен быть документирован.
Также полезно задокументировать шаги по поиску и анализу проблемы.
В случае, если в будущем возникнет подобная, но не совсем такая же проблема, информация о таких шагах облегчит проведение анализа – можно будет взять готовые шаблоны запросов и пропустить ряд анализов.
шаги, если в результате предыдущей работы было установлено, что этот путь неэффективен и так далее.
Подготовка решения
Когда причина проблемы найдена, осуществляется поиск наиболее подходящего способа ее устранения.Это могут быть исправления данных, исправления кода, изменение настроек, а может быть, в наиболее тяжелых случаях, более кардинальные изменения функциональности системы и т. д. Некоторые шаги можно предпринять сразу, а другие (например, перенастройка системы, улучшение функциональности) и т. д.) оставляются на потом.
Не следует забывать, что наиболее подходящее решение может оказаться в неожиданной сфере, например, административной.
Решение задачи оценивается по трудозатратам, скорости выполнения и эффективности.
Хорошей практикой является документирование того, как проблема будет решена, прежде чем ее реализовывать, особенно если это неочевидно из контекста и подготовка исправлений займет значительное количество времени.
Естественно, раствор должен быть тщательно протестирован в процессе приготовления.
Результатом этого этапа должна стать подготовленная и документированная последовательность действий, в результате которых проблема будет устранена.
К таким действиям относятся установка патчей, запуск подготовленных скриптов, ручные действия в системе и т.д. Если характер проблемы предполагает, что ситуация может повториться, то предпочтительнее более универсальное решение, которое можно будет применить в будущем с минимальными изменениями.
разбор полетов
После успешного решения проблемы следует провести завершающий этап работы.В частности, не так уж редко оказывается, что на этом этапе действительно ничего делать не нужно.
Но резюме должно быть.
Этот этап нацелен на будущее – улучшение качества и предотвращение потенциальных проблем.
В ходе заключительного подведения итогов вам следует сделать следующее и ответить на следующие вопросы: Что-то было упущено или не задокументировано из-за нехватки времени, теперь вы можете спокойно все завершить.
В подготовленном на скорость решении устранены последствия, но не причина, и решение нужно продолжить (возможно, в рамках другой задачи).
Если проблема была в данных, есть ли другие данные с той же проблемой, которые еще не обнаружены? Исправить их сейчас, когда мы полностью понимаем проблему, — лучшее время.
Есть ли вероятность, что проблема повторится и приведет ли эта проблема или ее последствия к другим неприятностям в будущем? Что вы можете сделать, чтобы избежать этого? Не стоит ли задокументировать решение проблемы в виде универсального скрипта, написать его в FAQ или базе знаний и т.п.
? Следует ли распространить это решение на другие экземпляры системы? Последний шаг должен привести к документированному заключению о том, какие действия следует предпринять, или к решению о том, что никаких специальных действий не требуется.
Хочу подчеркнуть, что если не требуется никаких дополнительных действий, то это тоже решение, и оно должно быть документально оформлено.
Просто отсутствие окончательных выводов указывает на то, что анализ воздействия не проводился.
Теги: #поддержка #техническая поддержка #методология #Service Desk
-
Лучшие Шрифты Для Программирования
19 Oct, 24 -
Как Правильно Продать/Купить Домен
19 Oct, 24 -
Skype Outside Отметил 8 Марта
19 Oct, 24 -
Секреты Метасплоита
19 Oct, 24
