Резюме : есть много статей в интернетах о том как это полезно и прекрасно логировать время и проделанную работу. Однако это для себя. Но зачем этого требует от вас руководство? Наверно из благих целей.

Есть одна менеджерская мечта - команда должна хорошо логировать свою работу и время, потраченное на нее. Ведь тогда будет понятно кто сачкует, а кто перегружен; кому медаль золотую вручить, а кому - позолоченную; какие задачи сложно даются, а какие - просто; сколько денег нужно потратить, а сколько - отобрать. Но на практике хренушки, к сожалению это не работает для большинства команд. Как правило по двум причинам:

Кто-то слишком ленивый, ведь логирование отвлекает от прямых обяазанностей ради “какой-то бюрократии”.

У кого-то просто нет для этого навыков. Есть люди, которые не умеют этого делать - когда забудут, а когда вовсе не придумают что написать… А чукча, оказывается, не писатель. Всему конечно можно обучиться при желании, но желания нет.

Чаще всего дело в обоих причинах, но если копнуть чуть глубже - обычные смертные не видят полезности в логировании работы, а понимать менеджеров никто не хочет - их принято нелюбить.

Полезность в логировании на самом деле огромная - человек упорядочивает свою работу; понимает насколько он завершил задачу, а сколько еще осталось; дает возможность другим понять и продолжить его труд если вдруг кирпич на голову. В общем-то это важная практика для time management’a.

Хоть и трудно переоценить необходимость логирования, стоит все же смириться, что делать это готов далеко не каждый, а всех жизни учить тоже плохо - раздражает. И нужно ли это на самом деле для руководства - спорный вопрос. Вот почему…

Как Agile начистил рожу логированию

По залогированному времени видно кто сачкует, а кто работу работает . На самом же деле в плане отчетности люди постоянно мухлюют. Если прошло 2 часа, а на реальную работу человек потратил лишь час, залогирует он все равно 2 часа. Даже если говорить про инструменты записывающие состояние рабочего стола и активность нажатий, народ заводит доп. компьютеры и/или пытается отдохнуть кликая без цели по окошкам.

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

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

По залогированному времени видно насколько правильно мы оцениваем задачи . Если вы до сих пор оцениваете задачи во временных единицах, пора задумываться, пора прислушиваться.. Оценка времени давно показала себя с плохой стороны - не умеет человек оценивать временные рамки. Поэтому задачи оценивают в более грубых единицах - по сложности (story points), либо, и это приобретает популярность, просто на глаз определяют сколько задач брать в итерацию. Ведь в итоге важно не то сколько времени потратил конкретный человек, а сколько задач он сделал.

Залогированное время помогает находить проблемы . Т.е. если человек потратил слишком много времени на какую-то задачу, то либо он плохо разбирается в этой области (и ему нужно помочь), либо задача поставлена неверно, либо та часть приложения с которой он работает - проблематична. Да, это правда может помочь, но только если эти все проблемы не обсуждаются на ежедневных статус-митингах. Т.е. логирование времени тут заменяет общение с людьми. На самом деле общение с людьми не заменить, это всегда более эффективно, поэтому в данном случае (логирование времени как инструмент для выявления проблем) - это один из симптомов того что команда мало общается. На daily standups проблемы и так бы выявились при правильном подходе.

Если логировать, то как?

Во-первых, главное - это логировать не время, а сделанную работу. Лучшее место для этого - commit message если вы работаете с кодом и/или issue tracker. Так мы прогресс держим близко к тому где все крутится, не нужно далеко ходить чтоб узнать что конкретно сделал тот или иной член команды.

У красноглазых есть отличные гайдлайны о том как должны выглядеть сообщения в коммитах и что там должно помещаться, вот еще статейка по-короче . Как правило если ваш коллега подошел к вам с вопросом, ему что-то не понятно о вашем изменении, значит коммит был описан плохо. Это важно во-первых для повседневной работы: не все можно обсудить на статус-митингах, а дергать по каждой мелочи коллег - значит мешать им делать свои задачи. Во-вторых, это история изменений - то что было сделано определить хоть как-то можно по содержимому, то зачем вы сделали это и почему не по-другому - об этом коллегам прийдется догадываться, а ведь не каждая фирма готова оплатить курсы молодого телепата.

По логированию времени (или в общем по time management’у) есть много всего, повторять чужое не хочу, но посоветую все-таки очередной раз попробовать Pomodoro ;) У меня получилось где-то с третьего, и все равно периодически забрасываю.

Подытожим

Логирование как работы, так и потраченного времени - безусловно полезные вещи. Особенно для себя любимого. Научить кого-то это делать - тоже полезно. Но строить по этому какие-то метрики - бесполезная затея.

Когда программа ведет запись действий в лог-файл (как правило, это файлы с расширением *.log), можно выяснить когда произошло то или иное событие, в какой момент времени произошел сбой приложения или возникла ошибка. Логирование позволяет отследить время старта сервера и его остановку, время подключения пользователя к базе данных, время попытки взлома веб-сервера и другие важные события, в зависимости от того, какая программа ведет запись истории в файл лога. Просмотр лога помогает отладить тот или другой программный процесс. LogViewer Pro - бесплатная для домашнего использования программа для просмотра логов. С её помощью Вы сможете читать лог-файлы в удобном виде, с выделением строчек лога цветом, в зависимости от того, какую информацию несет запись.

Просмотр логов

Просмотрщик логов LogViewer Pro можно адаптировать под любую структуру записи файла лога. Для выделения цветом отдельных строчек лога достаточно задать выражение - слово или символы, встречающиеся в строке. Утилита распознает большое количество кодировок, выполняет поиск по файлу лога, умеет переносить строчки при недостаточной ширине окна, выводит содержимое лога на печать, поддерживает открытие сразу нескольких файлов в одном окне. К файлу лога можно применить фильтр, при просмотре лога можно устанавливать закладки, для удобства просмотра LogViewer Pro пронумерует строчки. Для оперативности и постоянного мониторинга программа может читать лог в режиме реального времени. Интерфейс программы изменяется - можно изменить цвет фона, выбрать шрифт, добавить или убрать отдельные элементы приложения. LogViewer Pro поддерживает работу из командной строки, является portable-приложением. Программа бесплатна для частного, домашнего использования. При бесплатном использовании утилиты LogViewer Pro будет при запуске открывать окно на 25 секунд с предложением о покупке лицензии - это единственное ограничение функционала программы.

Скриншоты программы LogViewer Pro

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

Сбор логов https с помощью FiddlerCap

Установка FiddlerCap

Необходимо скачать и запустить приложение .

В открывшемся окне нажать на кнопку «Install». В строке Destination Folder будет указан путь до папки, в которую установится FiddlerCap. По умолчанию там указывается Рабочий стол.

Дождаться окончания установки и нажать кнопку «Close».

Сбор логов с помощью FiddlerCap

Найти папку FiddlerCap в той директории, которая была выбрана на этапе установки. По умолчанию FiddlerCap устанавливается на Рабочий стол. В папке FiddlerCap запустить файл «FiddlerCap.exe».

В пункте «Настройки захвата» установить три галки:

• сохранять двоичные данные,
• расшифровать HTTPS трафик,
• хранить куки и POST формы.

Если появится предупреждение об установке сертификата, то в нем следует нажать кнопку «Да». При необходимости, сертификат будет предложено удалить при сохранении логов.

Закрыть все браузеры, открытые на компьютере. Нажать на кнопку «Начать захват». Открыть программу, при работе с которой появляется ошибка (например, Контур.Экстерн), и воспроизвести ошибку.

После того, как ошибка будет воспроизведена, необходимо нажать на кнопку «Остановить захват» в окне программы FiddlerCap. Логирование завершится.

Выбрать папку для сохранения.

Файл с логами будет сохранен в выбранной папке.

При сохранении логов появится окно с вопросом об удалении сертификата из корневого хранилища. На усмотрение пользователя можно выбрать любой вариант.

Запись сетевого трафика в Internet Explorer

Для записи сетевого трафика в Internet Explorer необходимо открыть необходимую страницу в Internet Explorer. В Internet Explorer перейти в меню «Сервис» > «Средства разработчика F12» ("Tools" > «Developer Tools F12") F12 .

Если меню «Сервис» не отображается, то нажать клавишу «Alt» на клавиатуре .

Перейти на вкладку «Сеть (Network)» > «Ctrl+4». Включить сбор сетевого трафика: в Internet Explorer 9 нажать «Начать сбор». В Internet Explorer 11 нажать на кнопку с зеленым треугольником.

Воспроизвести ошибку (например, обновить страницу, либо перейти по нужной ссылке). Сохранить собранный лог, нажав на изображение дискеты.

В ыбрать папку для сохранения, ввести имя файла, нажа ть «Сохранить». Файл будет создан в xml формате. Создание лога завершено.

Запись сетевого трафика в Mozilla Firefox

Для записи сетевого трафика в Mozilla Firefox необходимо открыть необходимую страницу в Mozilla Firefox. В IMozilla Firefox перейти в меню «Сервис» > «Разработка» > «Средства разработчика (Ctrl + Shift + I) либо нажать на клавиатуре клавишу F12 .

Перейти на вкладку «Сеть» и обновите страницу, нажав на клавиатуре клавишу F5 . Воспроизведите ошибку.

Выделите любую запись из лога — нажмите по нему правой кнопкой мыши и нажмите на «Сохранить все как HAR».

Запись сетевого трафика в Google Chrome

Для записи сетевого трафика в Google Chrome необходимо открыть необходимую страницу в Google Chrome. В Google Chrome перейти в меню «Сервис» > «Дополнительные инструменты» >«Средства разработчика (Ctrl +Shift +I) либо нажать на клавиатуре клавишу F12 .

Передите в раздел Network и обновите страницу, нажав на клавиатуре клавишу F5 . Воспроизведите ошибку.

Если запись логов не началась автоматически, нажмите на кнопку «Record Network Log».

Выделите любую запись из лога, нажмите по нему правой кнопкой мыши и нажмите на «Save as HAR with content».

Выберите папку для сохранения, введите имя файла, нажмите на сохранить. Файл будет сохранен в формате har.

Установка

Необходимо скач ать и запустить приложение . На предложение начать установку следует ответить утвердительно, нажав на кнопку «Да».

В открывшемся окне нажать на кнопку «Next».

В следующем окне необходимо установить переключатель «I accept the terms in the Licence Agreement» и кликнуть по кнопке «Next».

Выбрать тип установки «Typical».

Отметить пункт «Create shortcut for Microsoft Network Monitor on the desktop» (Создать ярлык на рабочем столе) и нажать на кнопку «Install».

Нажать на кнопку «Finish» для завершения установки.

После окончания установки необходимо дождаться окончания автоматической настройки компонента Microsoft Network Monitior 3.3 Parsers.

Запуск логирования

Закрыть неиспользуемое программное обеспечение (это необходимо для исключения сохранения в лог активности сторонних продуктов). Запустить программу с помощью ярлыка на рабочем столе.

В главном окне программы выбрать меню «File» > «New» > «Capture».

Нажать на кнопку «Start», после чего свернуть программу и воспроизвести ошибку.

Воспроизвессти ошибку, нажать на кнопку «Stop», выбрать меню «File» > «Save As», указать каталог для сохранения и имя файла и нажать на кнопку «Сохранить». Создание лога завершено.

Process Monitor

Чтобы начать логирование при помощи программы Process Monitor, необходимо выполнить следующие шаги:

Закрыть неиспользуемое программное обеспечение (это необходимо для исключения сохранения в лог активности сторонних продуктов), скач ать и запустить приложение .

После запуска программы выбрать меню «File» > «Capture Events». Логирование будет остановлено. Выбрать меню «Edit» > «Clear Display». Автоматически записанный лог будет удален. Программа готова к работе.

Выбрать меню «File» > «Capture Events». Логирование будет запущено. Свернуть приложение и воспроизвести ошибку.

Восстановить приложение и выбрать меню «File» > «Capture Events». Логирование будет остановлено. Выбрать меню «File» > «Save». Установить переключатель «All Events».

Кликнуть по кнопке с тремя точками справа от поля «Path», указать папку для сохранения и имя файла (рекомендуется оставить по умолчанию) и нажать на кнопку «Сохранить».

В окне параметров сохранения файла нажать на кнопку «Сохранить». Создание лога завершено.

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

Лог – это текстовый файл, в котором каждому событию соответствует одна строка со временем и некоторыми дополнительными сведениями. Ведение лог-файлов позволяет восстановить картину неполадки либо последовательность действий, которая к ней привела. Для удобства пользователей лог-файлы размещаются в одной директории.

Icon

Для текущей смены лог-файлы сохраняются в директорию /linuxcash/logs/current .

Помимо лог-файлов сохраняются образы всех чеков, которые были закрыты в течении смены, а также журналы регистрации в ККМ сумм для данных документов.

• Файлы с образами чеков сохраняются в директорию /linuxcash/logs/current/documents и именуются по правилу <номер_смены>-<номер_чека>.img , здесь номер_смены - номер текущей смены, номер_чека - номер завершенного чека.
• Журналы регистрации сохраняются в директорию /linuxcash/logs/current/trs и именуются как <номер_чека>.<метка_времени> , здесь - номер_чека - номер завершенного чека, метка_времени - текущее время на момент начала регистрации в ККМ в формате unixtime .

Директория	Содержимое
documents	образы закрытых чеков
trs	журнал регистрации в ККМ текущего документа (файл присутствует, если произошло аварийное завершение работы программы во время печати чека)
trs/commited	журналы успешно зарегистрированных документов в ККМ
trs/canceled	журналы документов, которые не были зарегистрированы в ККМ
trs/critical	журналы регистрации в ККМ, содержащие критические ошибки, возникшие при регистрации

Для упрощения разбора информации "задним" числом при закрытии смены выполняется ротация директорий с лог-файлами. Таким образом, для каждой смены в каталоге /linuxcash/logs/cashlogs создается директория, название которой соответствует номеру смены.

Уровень детализации записей в лог-файлах

Правила ведения логов, события, которые подлежат записи, их подробность и полнота задаются в файле /linuxcash/cash/conf/Artix/artix.conf . Используемая подсистема ведения логов позволяет гибко настраивать виды журналов, объединять данные в один файл, распределять данные по нескольким файлам или выводить информацию в консоль. После установки кассового ПО логирование всех модулей осуществляется по умолчанию на уровне INFO. Запись логов ведется в несколько файлов. Наиболее важные из них:

Допускается использование одного из уровней:

• TRACE,
• DEBUG,
• INFO,
• WARN,
• ERROR.

Самый детальный уровень называется TRACE, самый строгий - ERROR. В зависимости от выбранного уровня в лог записывается информация, которая соответствует уровню, или строже.

Уровень	Описание
ERROR	ошибка в приложении, приложение может работать дальше без возникновения проблем, причина проблемы может состоять в неправильных входных данных или доступе к внешним сервисам
WARN	некритичная ошибка, приложение может работать дальше без возникновения проблем, вероятно одна из функций приложения дала сбой, который может быть исправлен
INFO	важная информация о работе приложения, например, запуск/остановка приложения, использование конфигурационных файлов или аутентификация пользователя в системе
DEBUG	отладочная информация работы приложения, например, технические данные, полученные при работе с внешними системами, или информация о вызове методов объектов, включая список параметров
TRACE	трассировка выполнения приложения, например, информация о вызываемых методах и времени их работы, информация о времени вызова внешних сервисов.

Для изменения уровня детализации достаточно установить требуемый уровень первым параметром требуемого логгера.

Пример настройки записи информации в файл terminal.log

Ротация данных после закрытия смены

Запуск процесса ротации файлов осуществляется после закрытия смены при помощи shell-скрипта /linuxcash/cash/bin/oncloseshift.sh, выполнение которого настраивается через макрос «Закрытие смены», как вызов внешнего скрипта.

Icon

За реорганизацию файлов отвечает модуль artix-maint-mysql . Журналы событий за текущую смену переименовываются в соответствии с правилами ротации , заданными в разделе shiftly .

Остановка работы кассы при ошибке логирования

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

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

При возникновении ошибки, связанной с прекращением логирования, программа остановит работу и выдаст сообщение:

Необходимо восстановить возможность логирования данных, после чего нажать ОК - программа перезапустится в нормальном режиме.

Почему так важно запретить самому себе отладку руками?

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

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

Я уже не говорю о том, что люди в командах меняются, команды меняются и так далее. Человеко-часы уходят на одно и то же. Перестаньте делать это. Я серьёзно. Возьмите ответственность за других людей на себя. Помогите им не переживать тот же самый участок вашей жизни.

Проблематика: Сложно отлаживать составной код

Возможный алгоритм решения проблемы:

1. Разбить на отдельные части
2. Выкидываем отладку, просто запрещаем пользоваться режимом Debug
3. Анализируем отдельные части (придумываем для них невалидные ситуации, граничные случаи)
4. Пишем тесты на каждую отдельную часть всего алгоритма
5. В тестах иногда приходится узнавать промежуточные данные, но…
   Отладка нам боле недоступна, поэтому втыкаем Trace в те части, где возникает подозрение на некорректное выполнение алгоритма
6. По трассировке нужно понять причину проблемы
7. Если не понятно, то чаще всего либо стоит написать ещё тест, либо выполнить трассировку на один этап раньше

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

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

Давайте посмотрим пример. Вы знаете, что по отдельности все реализации интерфейсов работают (т.к. написаны тесты, доказывающие это). Но при взаимодействии всего вместе возникает некорректное поведение. Что вам нужно? Нужно логировать ответы от «корректных» интерфейсов:

Void Register(User user) { // на этом участке не нужно ничего логировать, // т.к. всё будет понятно из исключения var isExists = _userRepository.IsUserExists(user); if (isExists) { throw new InvalidOperationException($"User already exists: {user}"); } // а вот это уже можно и залогировать, // т.к. от этого зависят дальнейшие детали алгоритма var roleInOtherService = _removeService.GetRole(user); _log.Trace($"Remote role: {roleInOtherService}") switch (roleInOtherService) { case "...": break; ... } // тут нам не критично, если пользователю не добавили // определённые привелегии в каком-то удалённом сервисе, // но мы бы хотели знать об этом foreach (var privilege in Privileges) { var isSuccess = _privilegeRemoteService.Grant(user, privilege); if (isSuccess) { _log.Trace($"Add privilege: {privilege} to User: {user}"); } else { _log.Trace($"Privilege: {privilege} not added to User: {user}"); } } ... }
В этом примере видно, как мы трассируем отдельные части алгоритма для того, чтобы можно было зафиксировать тот или иной этап его выполнения. Посмотрев на логи, станет ясно в чём причина. В реальной жизни весь этот алгоритм стоило бы разбить на отдельные методы, но суть от этого не меняется.

Всё это в разы ускоряет написание кода. Вам не нужно бежать по циклу с F10 для того, чтобы понять на какой итерации цикла возникла проблема. Просто залогируйте состояние нужных вам объектов при определённых условиях на определённой итерации цикла.

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

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

Плюсы	Минусы
Есть возможность проследить выполнение алгоритма без отладки	Приходится писать код трассировки
В production логи будут собирать иногда нужные данные	В production логи будут собирать иногда ненужные данные
Время на отладку сокращается, т.к. вы часто запускаете код и тут же видите результаты его выполнения (всё как на ладони)	Нужно подчищать за собой. Это иногда приводит к повторному написанию кода трассировки
Коллеги могут прослеживать выполнение алгоритма по логам	Коллегам приходится смотреть не только на сам алгоритм, но и на трассировку его выполнения
Логирование - единственный способ отладки недетерминированных сценариев (например, многопоточность или сеть)	В production уменьшается производительность из-за операций I/O и CPU

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