Поговорим о багах?

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

По большому счету существуют три типа ошибок:

Разберемся с каждой ошибкой по порядку.

Что с ними делать? Во-первых, причиной возникновения таких ошибок может являться допущенная неточность или разночтение на стадии аналитики (сбор и описание требований). Во-вторых, ошибка может возникнуть из-за недопонимания разработчиком описания задачи и, как следствие, некорректная реализация или ошибка, допущенная непосредственно разработчиком при написании кода.

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

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

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

Ошибки среды окружения – стык разработки администрирования ОС и серверного оборудования. Тут все намного сложнее, так как программный стек, платформы, ОС и компоненты от проекта к проекту могут крайне сильно разниться, а также конфигурации решений могут очень сильно отличаться, накладывая свои ограничения. В целом, необходимо подходить системно и отрабатывать каждый компонент отдельно под проектные требования. Например, вы применяете брокер сообщений RabbitMQ, соответственно, вам необходимо учесть кластеризацию, параметры конфигурации хранилища сообщений на разных дисках, которые в свою очередь должны быть поданы на сервера с разных лун и т.д. Также важно оптимизировать настройки ОС на примере Linux, количество процессов для пользователя, размер кластера на диске под данные в БД и конкретного производителя СУБД. То есть, необходимо учитывать всё при конфигурировании среди базовых компонентов ОС.

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