7 методов отладки для ускорения устранения неполадок в рабочей среде

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

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

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

Совет № 1. Удалите или автоматизируйте все настройки, необходимые для запуска приложения.

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

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

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

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

Совет № 2: не попадайтесь в ловушку супа из технологического стека.

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

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

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

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

Совет № 3. Ведение журнала должно направлять вас к поиску проблемы, а не утопать в бесполезных деталях.

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

Совет № 4: справляйтесь с непредвиденными ситуациями.

Четко обозначьте предположения кода. Если определенная переменная всегда должна содержать значения 2, 5 или 7, убедитесь, что она имеет тип enum, а не int. Источником номер один крупных производственных простоев является несостоятельность определенного предположения. Все ищут проблему не в том месте, потому что принимают некоторые вещи как должное.

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

Совет № 5. Воспроизвести проблему, возникающую у клиента, должно быть просто.

Одним из самых сложных шагов всегда является воспроизведение проблемы, с которой столкнулся клиент. Много раз вы будете тратить 95% времени, пытаясь воспроизвести проблему, а затем в тот момент, когда вы сможете воспроизвести ее, исправление, тестирование и развертывание будут делом нескольких минут. Таким образом, архитектор приложения должен убедиться, что проблема чрезвычайно проста и быстра. Во многом это происходит потому, что для достижения той же ситуации, в которой находится клиент, разработчик должен выполнить значительную настройку приложения. Существует множество хранимых записей, которые вместе составляют ситуацию, в которой находится клиент, — проблема в том, что вы, как разработчик, должны точно угадать, что сделал клиент. А иногда они выполнили последовательность шагов, из которых помнят только последний.

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

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

Совет № 6. Должно быть очевидно, где в приложении размещать точки останова.

Если у вас есть экран Customer, должен быть какой-то объект Customer, где вы можете разместить точки останова для отладки проблемы на этом экране. Иногда разработчики впадают в лихорадку абстракции и придумывают невероятно умные концепции того, как обрабатывать события пользовательского интерфейса. Вместо этого мы всегда должны полагаться на принцип KISS (будь проще, красивее, глупее) и иметь один легко обнаруживаемый метод для каждого события пользовательского интерфейса. Точно так же для заданий пакетной обработки и запланированных задач должен быть простой способ определить, где находятся точки останова, чтобы оценить, работает ли этот код или нет.

Совет № 7: Убедитесь, что все внешние зависимости явно задокументированы.

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

Помимо методов отладки

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