Всем привет! Меня зовут Дмитрий Чепель, я эксперт Acronis. Так уж получилось, что ко мне приходят люди с проблемами, которые не смогли решить мои коллеги.
Некоторые думают, что у меня есть какой-то «инстинкт разработчика», интуиция.
Не знаю, как вы, а я считаю, что интуиция — такой же инструмент развития, как и остальные, и ее можно и нужно совершенствовать и тренировать.
Интуиция как инструмент
Если рассматривать интуицию как инструмент развития (да и вообще как инструмент), то сразу станет понятно, что на самом деле, помимо наличия самого инструмента, было бы неплохо еще иметь и навыки использования этого инструмента.Навыками в данном случае будет личный опыт разработки/отладки/интеграции системы.
Чем больше опыта, тем сильнее развито «чувство» возможных проблем.
Чем шире ваш кругозор, чем глубже вы знаете систему, с которой работаете, ее среду и способы взаимодействия среды с оборудованием, на котором она работает, тем легче понять и осмыслить всю вертикально-интегрированную схему с аппаратной части.
к вашему продукту.
Для наглядности приведу пару примеров.
Пример 1: Самоповреждающийся архив
Представьте, что вы очень редко получаете сообщение о том, что ваши данные повреждены.Клиентов много, условия у всех разные, но время от времени вас уведомляют, что архивные копии отказываются восстанавливаться.
Винят, конечно, ваш «кривой» софт, ваши «кривые» руки и все в целом.
Начинаем тестировать код, проверять создание архива — всё в порядке.
Десять человек смотрят листинг и не видят никаких проблем.
Формат данных и способ создания архива предполагают проверку и защиту от сбоев, то есть проблема по идее не в нашем продукте.
(Примечание: при создании архива использованы коды Рида-Соломона, что позволило использовать только 40% избыточность с той же надежностью, что и Amazon S3 (имеющий 200% избыточность); об этом мы обязательно поговорим в одном из следующие статьи V наш блог , подписывайтесь и точно ничего не пропустите!) На самом деле, есть проблема, которую нужно решить.
Знание продукта помогло найти ошибку.
Дело в том, что особенностью нашего архива является создание двух копий метаданных: я предложил сравнить и посмотреть, совпадают они или нет. Они не согласились.
Начали копать — в одной из копий при открытии шестнадцатеричным редактором обнаружилась очевидная закономерность — каждые 64 байта данных были разделены 16 байтами «цифрового мусора».
Этот «шаблон» явно коррелировал с файловой системой и способом хранения данных на сервере.
Знание окружающей среды и знание продукта позволили нам использовать интуитивный подход к поиску, выявлению и устранению проблемы.
Широкий кругозор -> широкий опыт -> быстрое устранение неполадок.
Как видно из предыдущего примера, не зная, как хранятся данные, поиск ошибки займет очень много времени.
Обычно хороший разработчик сначала ищет проблемы в своем коде, но одна из проблем отладки заключается в том, что разработчику может быть сложно выйти из «цикла» отладки: перепроверка данных, алгоритма и уточнения условий не позволяет не давать «неправильных» ответов, разработчик снова запускает тест или ныряет в исходный код, ничего не находит и так до конца рабочего дня.
Очень важно уметь переключаться и выходить за пределы своей зоны ответственности: ошибка не обязательно в коде, виновата может и сама среда исполнения, и аппаратная среда, на которой все работает, и их нельзя исключить.
И для этой проблемы у меня есть еще один хороший пример.
Пример 2: Клиент не может дождаться результата операции и вылетает с ошибкой
Ситуация такая: программа работает уже некоторое время и все в порядке.Запросы, ответы, расчеты, результаты - никаких проблем, нигде ничего не вылетает, исходящие данные выглядят как положено, входящие обрабатываются корректно.
Через некоторое время стала появляться следующая ошибка: клиент зависал около минуты, не дождался ответа от сервера, а затем вернул ошибку.
Разработчик усиленно возится с, казалось бы, вполне рабочим кодом, который раньше без проблем работал и день, и два, и десять.
Проверка, чтение и просмотр логов не приносит никаких результатов.
Выхода из порочного круга отладки нет. В определенный момент мы решили шире взглянуть на проблему, отследить все события и посмотреть, как развивалась история ответов сервера до того, как он начал выдавать ошибки.
Мы заметили, что с определенного момента время отклика начало увеличиваться почти линейно, пока не дошло до злосчастной минуты.
Зашли по SSH, сделали принудительную индексацию — всё заработало.
Оглядываясь назад, решение выглядит очевидным и простым, однако разработчику было сложно выйти из цикла отладки и посмотреть на проблему со стороны системы, а не изнутри.
Пример 3. Невосстанавливаемые машины после резервного копирования
Вот еще одна интересная история буквально из недавнего прошлого: Acronis, как обычно, постоянно что-то переделывает и улучшает, а то и разрабатывает с нуля, учитывая предыдущий опыт. В данном конкретном примере разработчики работали над новым типом архива для выполнения резервного копирования дисков, который станет (вернее, уже стал) частью Acronis Cloud Storage. Код был написан, протестирован, и пришло время боевых испытаний.Они загрузили туда данные, сделали резервную копию, отправили в облако, а затем попытались восстановить компьютеры.
Проверяем результаты: что-то работает, что-то нет, компьютеры просто не загружаются.
Начинается утомительная череда отладки, логирования, проверки ошибок в автоматическом и ручном режиме, непосредственное сканирование файловой системы на предмет полного восстановления - все в порядке, том смонтирован, все файлы прочитаны.
Мы нашли пару мелочей и исправили их, но на то, что компьютеры не загружаются, они никак не повлияли.
В общей сложности мы провели несколько бессонных ночей, пытаясь найти причину сбоя загрузки (и, опять же, хочу повторить, не загружались только некоторые компьютеры).
В общем, разработчики попали в петлю отладки, из которой нет выхода.
Совершенно случайно мы заметили тот факт, что mft фрагментирован (имеет около полутора тысяч частей).
Сразу возникла мысль, что загрузчику просто не хватает чего-то для обработки такого массива информации.
Мы залезли в код, оптимизировали парсер файловой системы, исправили кое-что, и проблема моментально исчезла.
В данном конкретном случае debug-loop вывел меня из банального внимания на всевозможные мелочи.
И опять же, ретроспективно, решение кажется простым и очевидным, но на момент разработки сама идея проверки фрагментации и парсера была сродни озарению и внезапно нисходящей Благодати Разработчика.
Вместо заключения
Знайте свой продукт, знайте свой код и знайте свою среду.Не зацикливайтесь на одном и том же методе поиска ошибок.
Проверяйте не только программу и алгоритм, но и все, что связано с ее выполнением: сопутствующие продукты, ответы ОС, ответы оборудования и/или сервера.
Смотрите шире, смотрите глубже, и интуиция начнет помогать в поиске проблем, а ваш несомненно хороший продукт станет ближе вашим клиентам и пользователям.
Спасибо за внимание.
Теги: #Acronis #отладка #отладка #поиск ошибок #acronis #отладка #ошибка #программирование #отладка
-
Toshiba Выпускает Самую Быструю Sd-Память
19 Oct, 24 -
Боже Мой!
19 Oct, 24 -
Полный Текст Vim: Развертывание
19 Oct, 24 -
Дайджест It-Событий За Декабрь
19 Oct, 24 -
Саммит Parallels 2009
19 Oct, 24
