Решение ИТ-задач — 6 правил решения научных задач

Эта статья объяснит научный подход к решению проблем. Хотя он был написан для решения проблем информационных технологий, эти концепции также могут применяться к другим дисциплинам. В описанных здесь методах, концепциях и техниках нет ничего нового, но шокирует то, как много «решателей проблем» их не используют. А пока приведу несколько примеров из реальной жизни.

Почему решатели проблем предполагают, а не используют научный подход к решению проблем? Может потому что кажется быстрее? Может, отсутствие опыта эффективного решения проблем? Или, может быть, потому что это кажется тяжелой работой с научной точки зрения? Может быть, постоянно гадая, а не решая, вы получаете больше дохода и повышаете надежность работы? А может потому, что вы нарушаете первое правило решения проблемы: понять проблему.

Правило №1. Поймите * настоящую * проблему.

Разве не очевидно, что вы должны понять проблему, прежде чем сможете ее решить? Может быть. Однако в большинстве случаев респондент начинает решать, не зная реальной проблемы. То, что покупатель или пользователь описывает как «проблему», обычно является лишь симптомом! Симптом: «Мой компьютер не включается». Настоящая проблема может заключаться в отсутствии электричества во всем здании. Симптом: «Я получаю сообщение об ошибке каждый раз, когда пытаюсь добавить новый продукт». Настоящая проблема может заключаться в следующем: «Только последние 2 продукта, которые я пытался добавить, дали ошибку« Продукт уже существует ». Другой классический пример: «Ничего не работает» …

Вы начинаете свое расследование с определения «настоящей проблемы». Это будет включать в себя вопросы (а иногда и их проверку) и выполнение базовых тестов. Задайте пользователям такие вопросы, как «Когда в последний раз система успешно работала?», «Как долго вы используете систему?», «Работает ли она на другом компьютере или у другого пользователя?», «Какое точное сообщение об ошибке? "и т. д. Попросите распечатать экран ошибки, если это возможно. Первичная проверка будет заключаться в том, чтобы убедиться, что оборудование работает и функционирует непрерывно. Проверьте компьютер пользователя, сеть, веб-сервер, брандмауэры, файловый сервер, серверную часть базы данных и т. д. В лучшем случае определите проблему. В худшем случае можно устранить несколько проблемных областей.

Пример из жизни. Признак со слов пользователя: «Система зависает в случайное время, когда я размещаю заказ». Среда: пользователь вводит сведения о заказе в форму в приложении мэйнфрейма. После заполнения всех реквизитов пользователь покинет форму. Затем мэйнфрейм передает эти данные на клиент / сервер Oracle предприятия через коммуникационное программное обеспечение. Oracle запланирует емкость и либо вернет ошибку, либо ожидаемую дату заказа обратно на мэйнфрейм. Это очень серьезная проблема, потому что вы можете потерять клиентов, если они попытаются разместить заказ, а система их не примет! Чтобы попытаться решить эту проблему, люди начали с изучения: 1) аппаратной нагрузки и емкости мэйнфрейма 2) мониторинга сетевой нагрузки между мэйнфреймом и системой Oracle 3) нанять консультантов для отладки коммуникационного программного обеспечения 4) отладить систему планирования производительности Oracle Через несколько месяцев они потерпели неудачу решить проблему.

Был назван «Решатель научных проблем». Прошло меньше суток и проблема решена! Как? Респондент проводит день с пользователем, чтобы увидеть, в чем была «настоящая проблема». Оказалось, что проблема возникает только с экспортными заказами. После изучения экрана захвата и действий пользователя было обнаружено, что для заказов на экспорт последнее поле формы всегда пустое, и пользователь не отключил это поле с помощью вкладки. Система не зависала, она ждала, пока пользователь снова нажмет "вкладку". Проблема решена. Можно видеть, что Научный Решатель проблем имел очень ограниченные знания о мэйнфреймах, системе регистрации заказов, коммуникационном программном обеспечении и системе планирования мощности Oracle. И это подводит нас к Правилу №2.

Правило №2. Не бойтесь начинать процесс решения, даже если вы не понимаете систему.

Сколько раз вы слышали: «Я не могу трогать этот код, потому что он был разработан кем-то другим!» Или «Я не могу помочь, потому что я консультант по персоналу, а это финансовая проблема»? Если ваша стиральная машина не включается, вам не нужно быть инженером-электриком, специалистом по ремонту стиральных машин, техником или любым другим специалистом, чтобы найти основные неисправности. Убедитесь, что вилка исправна. Проверьте триггерный переключатель и т. Д. «Я никогда раньше не видел этой ошибки» не должно останавливать вас от попыток ее решения. Несколько отправных точек можно получить с помощью сообщения об ошибке и поисковой системы в Интернете.

В любой сложной системе существует несколько основных принципов работы. Система A, которая считывает данные из Системы B, может быть мучительно сложной (это может быть лабораторный спектрометр, считывающий данные с компьютера с программируемой логикой через порт RS-232). Но некоторые основы для проверки: есть ли у обеих систем питание? Есть ли сообщение об ошибке в журнале событий одной из этих систем? Можете ли вы «пинговать» или отследить сетевой пакет от одной системы к другой? Попробуйте другой кабель связи. Найдите в Интернете сообщение об ошибке.

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

Правило №3. Бей легко.

Начнем этот раздел с реального примера. При определенных условиях хранимая процедура зависает. Хранимая процедура обычно занимает около часа (если она не приостановлена). Так что разработчик попытался отладить. Внесите изменения и подождите около часа, чтобы увидеть, решена ли проблема. Через несколько дней разработчик ушел и взял на себя «Устранение неполадок». Решатель проблем имел в своем распоряжении знания об условиях, при которых хранимая процедура могла зависнуть. Таким образом, создание копии процедуры и последующее удаление всего избыточного кода было простым упражнением. Все параметры были изменены на жестко заданные значения. Все биты кода выполнялись одновременно, а затем наборы результатов жестко закодировались в копию процедуры. Проблема была решена за 3 часа. Обнаружен бесконечный цикл.

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

Если проблема возникает в приложении, создайте новое приложение и попытайтесь имитировать проблему в новом приложении как можно проще. Если проблема возникает при вызове определенного метода для определенного элемента управления, попробуйте включить этот элемент управления только в пустое приложение и вызовите этот метод с жестко заданными значениями. Если проблема связана со встроенным SQL в приложении C #, попробуйте смоделировать код SQL в средстве запросов к базе данных (например, SQL * Plus для Oracle, Query Analyzer для SQL Server или используйте код в MS Excel через ODBC для базы данных).

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

Если вы не знаете, где проблема в программе, используйте DEBUG.

Правило №4. Отладка.

Большинство инструментов разработки приложений стандартно поставляются с отладчиком. Будь то Macromedia Flash, Microsoft Dot Net, Delphi или любая другая среда разработки, там будет какой-то отладчик. Если инструмент не входит в стандартную комплектацию отладчика, вы можете смоделировать его.

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

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

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

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

Решение проблемы было призвано помочь в решении очень сложной проблемы. Проект предусматривал переход системы с мэйнфрейма на технологию клиент-сервер. Во время тестов все прошло хорошо, но при загрузке системы неожиданно обнаружилось довольно много случайных «общих ошибок защиты». (Ошибка GPF была общей ловушкой ошибок в Windows 95 и 98). Попытка упростить код, попытка отладки, но не удалось реплицировать. В среде ЛАБОРАТОРИИ проблемы не возникнет! Сообщения трассировки отладки в файлах журналов указывают на то, что проблема возникла случайно. Некоторые пользователи испытали это больше, чем другие, но в конечном итоге все пользователи получат это! Интересная проблема.

«Устранение неполадок» устранило эту проблему после того, как он начал анализировать серверную часть базы данных. Я не уверен, было ли это совпадением или потому, что он систематически шел в правильном направлении благодаря научному подходу. Отслеживая, что происходило на бэкэнд-уровне, все эти приложения устанавливали все больше и больше подключений к базе данных. Каждый раз, когда пользователь запускает новую транзакцию, к базе данных устанавливается новое соединение. Сумма всех подключений была разблокирована только после закрытия приложения. По мере того, как пользователь переходит в новые окна в том же приложении, открывается все больше и больше подключений, и после определенного количества подключений приложение устанет от них и затем выйдет из строя. Это был программный сбой в шаблоне, который использовали все разработчики. Решение заключалось в том, чтобы сначала проверить, был ли уже открыт курсор базы данных, прежде чем открывать его повторно.

Как отслеживать происходящее во внутренней базе данных? Основные поставщики баз данных имеют инструменты с графическим интерфейсом, которые помогут вам отслеживать или анализировать запросы к базе данных. Он также показывает, когда люди подключаются, отключаются или не могут подключиться из-за нарушения безопасности. Большинство баз данных также содержат таблицы системных словарей, из которых можно получить эту информацию. Эти следы иногда могут рассказать всю историю того, почему что-то идет не так. Код запроса, взятый из отслеживания, может помочь «упростить поиск». По трассировке можно проверить, успешно ли программа обращается к базе данных. Вы можете увидеть, сколько времени занимает выполнение запроса.

Чтобы добавить к правилу №2 (не бойтесь начинать …); вы можете анализировать эту информацию отслеживания, даже если вы ничего не знаете о деталях приложения.

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

Правило №6. Используйте свежий взгляд.

Это последнее правило. Не тратьте слишком много времени на решение проблемы, прежде чем попросить о помощи. Помощь не обязательно должна исходить от кого-то старше вас. Основное правило заключается в том, что вам нужна пара свежих глаз для свежего взгляда, а иногда и свежий воздух во время перерыва. Другой человек посмотрит, а затем задаст вопрос или два. Иногда не хватало чего-то очень очевидного. Иногда просто ответ на вопрос заставляет задуматься в новом направлении. Кроме того, если вы часами наблюдаете за одним и тем же фрагментом кода, очень легко начать искать глупую ошибку. Многие проблемы с балансировкой можно решить с помощью пива. Это может быть смена обстановки и / или непринужденная атмосфера, которая выскочит из решения. Может быть, это был свежий кислород, который попал в мозг по дороге в паб. Может быть, потому что проблема обсуждалась с кем-то другим.

Предложение

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *