Хроносфера спонсировала этот пост. Примечание редактора: эта статья представляет собой отрывок из лучших практик журнала: практическое руководство по облачным нативным журналам (часть 1, раздел 6), опубликованное Мэннингом. Эта книга содержит практическую структуру, необходимую для преобразования ведения журнала из инструмента реактивной отладки в упреждающее конкурентное преимущество, и ее можно загрузить, чтобы прочитать полностью.
Как разработчики, мы склонны писать подробности журнала с учетом самих себя. Это хорошо в организации DevOps, где команда разработчиков также обрабатывает OPS. Но многие более крупные организации могут выбрать управление подходом библиотеки инфраструктуры информационных технологий (ITIL) к управлению ошибками и проблемами, или у вас может быть продукт, который люди развертывают в местах, выходящих за рамки вашего досягаемости. Но нам нужно думать дальше вперед. Одним из важных аспектов ITIL является его определение известной ошибки:
Известная ошибка — это проблема, которая имеет документированную основную причину и обходной путь. Известные ошибки управляются на протяжении всего их жизненного цикла в процессе управления проблемами. Детали каждой известной ошибки записываются в известной записи ошибки, хранящейся в известной базе данных ошибок (KEDB). Как правило, известные ошибки определяются с помощью управления проблемами, но известные ошибки также могут быть предложены другими дисциплинами управления услугами, например, управлением инцидентами. (Источник: ИТ -обработка карт вики)
Проще говоря, организация будет вести учет ошибок с разрешениями. Вот почему мы назначаем ошибки кодами ошибок. Код ошибки позволяет нам предоставить простой поиск ошибки, которая может быть связана с соответствующей документацией. Документация должна описать ошибку и предоставить подробную информацию, включая корректирующий набор действий для выполнения (это важно, если это включает в себя возвращение системы в оптимальное состояние без повреждения или потери данных).
Если, конечно, событие журнала записывается и действует до того, как все пойдет не так, то действия могут быть профилактическими по своему характеру.
Причиной ошибки может быть либо из действия пользователя, либо из -за ошибки в приложении, которое было поймано; В любом случае, мы должны добавить коды ошибок в информацию о журнале. Лучше всего не вскрывать коды ошибок в пользовательском интерфейсе (пользовательский интерфейс), так как вы, вероятно, подорваете уверенность пользователя в своем продукте. Но это не должно помешать вам связывать коды ошибок с сообщениями, подходящими для пользователей, когда действие пользователя вызывает проблему.
Для чего используются коды ошибок?
Коды ошибок позволяют возможность клиентам искать ошибки, описания и рекомендуемые ответы для включения в известную базу данных ошибок (KEDB). Создание такого содержимого кода ошибки может показаться очень требовательным; Это может быть далеко от дела.
При разработке программного обеспечения простейшим решением является наличие совместной электронной таблицы, которая выделяет идентификаторы ошибок, гарантируя, что идентификаторы являются уникальными. Затем захватите ожидаемую причину с кратким описанием от разработчика. Создание документации по разрешению всегда можно сделать позже.
Преимущества использования кодов ошибок
Одним из преимуществ использования кодов ошибок является то, что он становится довольно простым в стандартизации и интернационализации документации об ошибках. Коды ошибок являются языковыми и локальными агрессиями; После того, как у вас есть код, вы можете найти документацию по коде на соответствующем языке.
Существуют всевозможные дополнительные трюки, которые вы можете включить в процессы разработки программного обеспечения, такие как включение документации в инструмент управления кодом. Следовательно, вы выпускаете документ с кодом, чтобы детали были связаны с процессом выпуска. Инструмент качества кода может искать ошибки или записи фатальных журналов и применить регулярное выражение, чтобы увидеть, связан ли код ошибки с ним, и так далее.
Чиновка кода ошибки
Вот несколько советов по созданию нумерации кода ошибки:
- Не используйте ведущие нули в номере, если только он не префиксируется альфа -символом — это рискует усекать, если он обрабатывается численным образом, или создает дополнительную работу для форматирования (например, номера строки с установленной длиной и символом префикса). Затем, если этот номер преобразуется обратно в строку, он больше не будет соответствовать ключу для поиска информации.
- Не начинай с 1; Лучше всего начать с самой низкой цифры для полного диапазона (например, 1000).
- Упрощайте код ошибки легко найти с помощью инструментов поиска (например, 1000 в качестве кода менее вероятно, чем что -то вроде Apperr1000). Например, Oracle префикет кодов ошибок в базе данных с кодами ошибок ORA и WebLogic начинается с BEA; Таким образом, они, скорее всего, будут проиндексированы и более уникальны в поисках.
- Заманчиво просто документировать все коды ошибок в части кода (например, класс, интерфейс, файл заголовка, в зависимости от вашего языка); В конце концов, есть одно место, и из кода может быть сгенерирована документация. Но это не рекомендуется. В итоге вы получите код, на котором все станет зависимым и постоянно меняющимся, пока система разрабатывается. Каждое дополнение к коду ошибки делает изменение кода с огромным воздействием зависимости. Изменения кода с таким большим воздействием приведут к опасениям (даже если они не оправданы) и сопротивления изменениям.
- Лучше собрать детали в общем хранилище знаний, таких как вики или база совместной работы, которую каждый может поддерживать без последствий. Обратите внимание, что определение локального подмножества ошибок в коде — это нормально — это применяет принцип сухого («не повторяйте себя»). Например, коды ошибок, относящиеся к конкретному модулю, могут быть определены вместе, так как добавление кода ошибки, вероятно, будет проходить рука об руку с разработкой модуля.
- Групповые коды ошибок вместе в семьи, как видно из HTTP RFC, но будьте прагматичны в этом; Код ошибки может логически принадлежать к двум группам (например, ошибка подключения DB является проблемой базы данных или проблемой сетевого подключения?).
- Это не обязательно означает резервирование диапазонов чисел. Тем не менее, коды могут быть предварительно профиксированы или постфикс с помощью шорткода, чтобы обеспечить область применения на уровне продукта или подсистемы; Например, BEA-00000 и ORA-00000 обозначают коды ошибок для двух разных продуктов Oracle (база данных WebLogic и Oracle).
- Если вы используете один и тот же код ошибки из разных исключений, попробуйте дифференцировать точку происхождения в вспомогательной информации.
- Рассмотрим потребитель кода ошибки; Ошибка может исходить из одного места, но иметь разные причины, поэтому используйте разные коды ошибок для причин. Это облегчит работу или исправление команды поддержки.
Используя стандартные ошибки
Некоторые технологии предоставляют коды, указывающие на успех и ошибки, которые были хорошо задокументированы, например, для HTTP (RFC); Другие включают SMTP (услуги по электронной почте) и Oracle Weblogic Server.
Использование таких кодов в журналах помогает обеспечить больше контекста посредством общего значения и понимания — если они используются правильно. Например, искушение просто сделать все с помощью стандартных кодов HTTP 200 или 400 не помогает. Использование кода HTTP 413, чтобы сообщить требованиям, что они отправили слишком много данных, гораздо более эффективно и значимо, не говоря уже о том, что это будет отображаться в журналах для любых сетевых устройств маршрутизации.
Использование предопределенных кодов ошибок необходимо судить по осторожности, так как классы исключений в программном обеспечении можно считать особой формой кода ошибок. Но эти обстоятельства также могут снизить ясность.
Коды могут быть не только ошибки
Коды ошибок — это наиболее важные сообщения, которые можно уникально идентифицируемые. Принцип ассоциации кодов с документацией для оперативных (а не пользователей) процессов означает, что вы можете поднять событие обратно к конкретным эксплуатационным рекомендациям, которые могут варьироваться от выполнения процессов оптимизации базы данных до архивирования файлов журналов.
Вы только что прочитали отрывок из книги Manning «Лучшие практики ведения журнала» — вы можете скачать бесплатную копию всей книги.
Хроносфера — это платформа наблюдения, созданная для контроля в современном, контейнерном мире. Признанная в качестве лидера крупными аналитическими фирмами, хроносфера дает клиентам сосредоточиться на данных и идеях, которые имеют значение для снижения сложности данных, оптимизировать затраты и быстрее решать проблемы. Узнайте больше новейших из хроносферных трендовых историй Youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Написав для хроносферы, Фил Уилкинс провел более 30 лет в индустрии программного обеспечения, общий опыт работы в бизнесе и средах от многонациональных корпораций до программных стартапов и потребительских организаций до консультаций. Он начинал как разработчик в режиме реального времени, критически важным … Подробнее от Фила Уилкинса
