Лучшие практики: поиск неисправностей
При изучении, анализе и тестировании приложения перед специалистами стоят задачи обнаружить проблемы (самого различного рода - функциональные, связанные со стабильностью работы или производительностью и многое другое), локализовать их, понять причины и найти пути к устранению.
В решении подобных задач помогают различные инструменты, как узкоспециализированные, так и достаточно широкого круга применения. Но важно понимать, что следует полагаться не только на удобные инструменты, но и должным образом организовывать работу, применять зарекомендовавшие себя методики - т. н. best practices. Естественно, практик много, они разные, имеют различные цели и могут быть полезны в определённых ситуациях.
В этой статье - сейчас и в будущем при апдэйтах - я планирую собирать практики, которые могут быть удобны при troubleshooting.
Каждая практика будет описываться буквально несколькими предложениями.
Практики будут собираться/проверяться конкретно для java-мира, хотя - на то они и "лучшие практики", чтобы не быть зависимыми от применяемых технологий.
Code review. Всем известная практика ревью кода полезна во многих случаях, в частности, для профилактики возникновения неисправностей. Разработан новый блок кода, модуль или класс - и его следует показать ещё хотя бы одному человеку в команде. Если этот человек скажет, что в коде есть проблемы, то либо надо решить проблему, либо убедить оппонента в её отсутствии. Эта практика исходит из того, что несмотря на всю полезность инструментов статического анализа кода, только человек может заметить многие проблемы.
Аудит данных. Для диагностики причин неисправности очень часто надо как можно более точно представлять, в каком состоянии находилась система перед и в момент возникновения неисправности. Для этого нужны точные и объективные данные, причём желательно в виде истории изменений. Целью аудита является понимание, что, кем и когда было изменено в процессе работы - какие-то параметры, настройки приложения и пр. Если удобно - следует применять системные возможности аудита; а внутрь приложения полезно добавлять объекты-аудиторы. На уровне структур данных может быть достаточно, например, такого варианта:
Отладочное логирование. В некоторых случаях - едва ли не единственная возможность. Однозначно - не System.out.println (забивает стандартный вывод, поэтому придётся либо регулярно рестартовать приложение, либо перенаправлять в никуда - теряется смысл).
Самая сложная задача - выбор разумных уровней логирования и механизма ротация логов. Высокий уровень - мало информации для анализа; низкий уровень - большой объём данных и сложность анализа.
Универсального ответа не существует. Логи должны выживать достаточно долго, чтобы можно было вернуться на момент проблемы - в зависимости от приложения, три дня, неделя, месяц. Важно найти баланс, ориентируясь на имеющиеся предположения и опыт.
Какую именно информацию выводить - опять-таки зависит от приложения. Практики советуют как минимум писать в лог дату/время (важна синхронизация времени между серверами и компонентами!), имя потока/класс, дополнительную информацию для точной идентификации места и времени.
Рестарт... Как правило, при нестабильной работе, появлении каких-то ошибок в логах и т.д. многие первым делом выполняют рестарт. И теряют тем самым отличную возможность. Дело в том, что нестабильность и проблемы вызваны ошибками в приложении, возможно, неочевидными и трудно повторимыми. Поэтому, делая рестарт, мы теряем всяческую возможность попытаться получить как можно больше информации, понять и разобраться. Что же следует сделать? Как минимум, снять данные для диагностики (набор данных может различать для разных приложений - thread dump, mem dump, логи, другая специфическая информация). Если есть время и возможность - попытаться проанализировать и локализовать проблему. И только затем - рестартовать приложение.
При изучении, анализе и тестировании приложения перед специалистами стоят задачи обнаружить проблемы (самого различного рода - функциональные, связанные со стабильностью работы или производительностью и многое другое), локализовать их, понять причины и найти пути к устранению.
В решении подобных задач помогают различные инструменты, как узкоспециализированные, так и достаточно широкого круга применения. Но важно понимать, что следует полагаться не только на удобные инструменты, но и должным образом организовывать работу, применять зарекомендовавшие себя методики - т. н. best practices. Естественно, практик много, они разные, имеют различные цели и могут быть полезны в определённых ситуациях.
В этой статье - сейчас и в будущем при апдэйтах - я планирую собирать практики, которые могут быть удобны при troubleshooting.
Каждая практика будет описываться буквально несколькими предложениями.
Практики будут собираться/проверяться конкретно для java-мира, хотя - на то они и "лучшие практики", чтобы не быть зависимыми от применяемых технологий.
Code review. Всем известная практика ревью кода полезна во многих случаях, в частности, для профилактики возникновения неисправностей. Разработан новый блок кода, модуль или класс - и его следует показать ещё хотя бы одному человеку в команде. Если этот человек скажет, что в коде есть проблемы, то либо надо решить проблему, либо убедить оппонента в её отсутствии. Эта практика исходит из того, что несмотря на всю полезность инструментов статического анализа кода, только человек может заметить многие проблемы.
Аудит данных. Для диагностики причин неисправности очень часто надо как можно более точно представлять, в каком состоянии находилась система перед и в момент возникновения неисправности. Для этого нужны точные и объективные данные, причём желательно в виде истории изменений. Целью аудита является понимание, что, кем и когда было изменено в процессе работы - какие-то параметры, настройки приложения и пр. Если удобно - следует применять системные возможности аудита; а внутрь приложения полезно добавлять объекты-аудиторы. На уровне структур данных может быть достаточно, например, такого варианта:
property, creator, create_timestamp, modifier, modify_timestamp, old_value, new_valueСобранные данные могут сохраняться в БД, файл или передаваться по сети.
Отладочное логирование. В некоторых случаях - едва ли не единственная возможность. Однозначно - не System.out.println (забивает стандартный вывод, поэтому придётся либо регулярно рестартовать приложение, либо перенаправлять в никуда - теряется смысл).
Самая сложная задача - выбор разумных уровней логирования и механизма ротация логов. Высокий уровень - мало информации для анализа; низкий уровень - большой объём данных и сложность анализа.
Универсального ответа не существует. Логи должны выживать достаточно долго, чтобы можно было вернуться на момент проблемы - в зависимости от приложения, три дня, неделя, месяц. Важно найти баланс, ориентируясь на имеющиеся предположения и опыт.
Какую именно информацию выводить - опять-таки зависит от приложения. Практики советуют как минимум писать в лог дату/время (важна синхронизация времени между серверами и компонентами!), имя потока/класс, дополнительную информацию для точной идентификации места и времени.
Рестарт... Как правило, при нестабильной работе, появлении каких-то ошибок в логах и т.д. многие первым делом выполняют рестарт. И теряют тем самым отличную возможность. Дело в том, что нестабильность и проблемы вызваны ошибками в приложении, возможно, неочевидными и трудно повторимыми. Поэтому, делая рестарт, мы теряем всяческую возможность попытаться получить как можно больше информации, понять и разобраться. Что же следует сделать? Как минимум, снять данные для диагностики (набор данных может различать для разных приложений - thread dump, mem dump, логи, другая специфическая информация). Если есть время и возможность - попытаться проанализировать и локализовать проблему. И только затем - рестартовать приложение.
Комментариев нет:
Отправить комментарий