– Г-голубчики, – сказал Федор Симеонович озадаченно, разобравшись в почерках. – Это же п-проблема Бен Б-бецалеля. К-калиостро же доказал, что она н-не имеет р-решения.
– Мы сами знаем, что она не имеет решения, – сказал Хунта, немедленно ощетиниваясь. – Мы хотим знать, как ее решать.
– К-как-то ты странно рассуждаешь, К-кристо… К-как же искать решение, к-когда его нет? Б-бессмыслица какая-то…
– Извини, Теодор, но это ты очень странно рассуждаешь. Бессмыслица – искать решение, если оно и так есть. Речь идет о том, как поступать с задачей, которая решения не имеет. Это глубоко принципиальный вопрос, который, как я вижу, тебе, прикладнику, к сожалению, не доступен. По-моему, я напрасно начал с тобой беседовать на эту тему.

Понедельник начинается в субботу. А. и Б. Стругацкие

Вступление


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


В этой статье хоть и слегка упоминается специфика местных условий, но сам процесс описан достаточно абстрактно, так что применять его можно хоть для решения ошибок в IT-системе, хоть для поиска неисправностей в бытовой электронике, хоть для решения межличностных конфликтов...


Идентификация проблемы


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


Первое что необходимо сделать — идентифицировать проблему. Понять что, где и как работает неправильно. Определить компоненту системы, которая выдаёт ошибку, получить такую диагностику, которая показывает наличие проблемы.


Результатом этого шага должна стать следующая собранная информация:


  • Где произошла ошибка — имя (файла) формы или отчёта, точная версия.
  • Сообщение об ошибке — дословное, символ в символ, написанное текстом (для возможности последующего поиска, снимков экрана для этого недостаточно); если ошибка находится в лог-файле, то имя и месторасположение такого файла.
  • Окружение, в котором произошла проблема — продуктивная система, проектная, тестовая, все перечисленные.
  • Воспроизводится ли данная проблема, характер воспроизведения — на всех данных, на определённых данных или при специфических условиях, единичный сбой, плавающая ошибка.
  • Шаги, которые привели к возникновению проблемы, а в том случае, если проблема воспроизводится, то они же будут тестовым сценарием.
  • Оценка влияния проблемы — серьёзность самой проблемы и ожидаемых последствий; какое количество транзакций или пользователей попадает под влияние; сроки для решения и влияние на закрытие периода; общая сумма транзакций, затронутые VIP-персоны и другие факторы, которые являются важными в контексте проблемы.

Собранная информация должна быть задокументирована.


Цель этого шага:


  • Зафиксировать факт наличия проблемы.
  • Найти и зафиксировать место проявления проблемы в системе.
  • Полученные в результате ключевые слова (имя и версия компоненты, сообщения об ошибке) могут быть использованы в поиске по доступным базам знаний – внутренним системам, Металинку, в интернете. Если подобная проблема встретится в дальнейшем то, после идентификации этой новой проблемы, уже существующее решение должно быть найдено с высокой вероятностью.

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


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


Анализ проблемы и поиск причин возникновения


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


Полезными приёмами в данном случае являются:


  • Трассировка — позволит найти код, который отработал неправильно или выдал ошибку; позволит увидеть, что последнее выполнялось, если внятная диагностика проблемы отсутствует.
  • Анализ исполняемого кода — вместе с сообщением об ошибке даст гипотезы, почему код работает не так, как ожидается.
  • Отладка (в том числе диагностический вывод) — позволит определить, выполняются ли предположения о логике работы, значениях переменных, и увидеть, выполняется ли вообще диагностируемый участок кода.
  • Анализ данных (чем отличаются проблемные данные от остальных) — позволит сконцентрировать внимание на коде, в котором происходит обработка именно таких отличающихся данных.

Анализ причин и поиск решения идут по всем известной схеме:


  • Формулируем гипотезу о причине ошибки.
  • Проверяем сформулированную гипотезу:
    • исправляем код или данные,
    • делаем тестовый прогон
  • Анализируем результат.
  • Если гипотеза не подтвердилась — начинаем с начала.

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


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


Подготовка решения


Когда причина возникновения проблемы найдена, ищется наиболее подходящий способ её исправить. Это могут быть исправления данных, исправления в коде, изменение настроек или может, в наиболее тяжёлых случаях, более кардинальные изменения функциональности системы и т.д. Какие-то шаги могут быть предприняты сразу, какие-то (например, перенастройка системы, доработка функциональности и т.п.) оставлены на потом. Не следует забывать, что наиболее подходящее решение может оказаться в неожиданной плоскости, например, административной. Решение проблемы оценивается по трудозатратам, скорости исполнения и эффективности.


Хорошим тоном является задокументировать, как будет производиться решение проблемы, а только потом приступать к его реализации, особенно если это не очевидно из контекста, а подготовка исправлений займёт существенное время.


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


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


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


Разбор полётов


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


Во время завершающего подведения итогов следует сделать следующие действия и ответить на такие вопросы:


  • Что-то было упущено или не задокументировано из-за недостатка времени, теперь можно спокойно всё дооформить.
  • В подготовленном решении для скорости были устранены последствия, но не причина, и решение нужно продолжить (возможно в рамках другой задачи).
  • Если проблема была с данными, то нет ли других данных с той же проблемой, которые просто пока ещё не были обнаружены? Поправить их сейчас, когда мы полностью понимаем проблему, — самое подходящее время.
  • Есть ли шансы, что проблема повторится и не приведёт ли данная проблема или её следствия к другим неприятностям в будущем? Что можно предпринять для избежания?
  • Не стоит ли оформить решение проблемы как универсальный сценарий, скрипт, написать в ЧаВо (FAQ) или базу знаний и т.п.?
  • Следует ли распространить данное решение на другие экземпляры системы?

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


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

Комментарии (0)