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