Вступление

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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