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