Agile vs. Логирование Работы. Логирование
Все события, происходящие при работе кассового ПО, записываются программой в файлы журналов или лог-файлы, которые впоследствии можно использовать для анализа сбоев, получения статистики, расследования инцидентов.
Лог – это текстовый файл, в котором каждому событию соответствует одна строка со временем и некоторыми дополнительными сведениями. Ведение лог-файлов позволяет восстановить картину неполадки либо последовательность действий, которая к ней привела. Для удобства пользователей лог-файлы размещаются в одной директории.
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 кассовая программа приостанавливает функционирование в случае прекращения записи в любой из логов, которые пишет сама касса, до устранения неполадок.
Остановка логирования при работе кассы - серьезная проблема, она может быть следствием прекращения правильной работы кассы. Такие ситуации возможны при непредвиденном отключении электроэнергии в процессе функционирования кассы, а также при проблемах с комплектующими.
При возникновении ошибки, связанной с прекращением логирования, программа остановит работу и выдаст сообщение:
Необходимо восстановить возможность логирования данных, после чего нажать ОК - программа перезапустится в нормальном режиме.
Резюме : есть много статей в интернетах о том как это полезно и прекрасно логировать время и проделанную работу. Однако это для себя. Но зачем этого требует от вас руководство? Наверно из благих целей.
Есть одна менеджерская мечта - команда должна хорошо логировать свою работу и время, потраченное на нее. Ведь тогда будет понятно кто сачкует, а кто перегружен; кому медаль золотую вручить, а кому - позолоченную; какие задачи сложно даются, а какие - просто; сколько денег нужно потратить, а сколько - отобрать. Но на практике хренушки, к сожалению это не работает для большинства команд. Как правило по двум причинам:
Кто-то слишком ленивый, ведь логирование отвлекает от прямых обяазанностей ради “какой-то бюрократии”.
У кого-то просто нет для этого навыков. Есть люди, которые не умеют этого делать - когда забудут, а когда вовсе не придумают что написать… А чукча, оказывается, не писатель. Всему конечно можно обучиться при желании, но желания нет.
Чаще всего дело в обоих причинах, но если копнуть чуть глубже - обычные смертные не видят полезности в логировании работы, а понимать менеджеров никто не хочет - их принято нелюбить.
Полезность в логировании на самом деле огромная - человек упорядочивает свою работу; понимает насколько он завершил задачу, а сколько еще осталось; дает возможность другим понять и продолжить его труд если вдруг кирпич на голову. В общем-то это важная практика для time management’a.
Хоть и трудно переоценить необходимость логирования, стоит все же смириться, что делать это готов далеко не каждый, а всех жизни учить тоже плохо - раздражает. И нужно ли это на самом деле для руководства - спорный вопрос. Вот почему…
Как Agile начистил рожу логированию
По залогированному времени видно кто сачкует, а кто работу работает . На самом же деле в плане отчетности люди постоянно мухлюют. Если прошло 2 часа, а на реальную работу человек потратил лишь час, залогирует он все равно 2 часа. Даже если говорить про инструменты записывающие состояние рабочего стола и активность нажатий, народ заводит доп. компьютеры и/или пытается отдохнуть кликая без цели по окошкам.
Отдых тоже важен, без него продуктивность упадет, это нормально. Но человек чувствует себя неловко если начальство видит что он просиживает время, поэтому и не отдохнуть, и не поработать.
Если же говорить про выявление совсем ленивых, так их продуктивность будет и так видна по количеству и качеству сделанной работы, для этого не нужно ничего логировать. Вы, как ни крути, заметите разницу между продуктивными людьми и лежебоками (жопосидами).
По залогированному времени видно насколько правильно мы оцениваем задачи . Если вы до сих пор оцениваете задачи во временных единицах, пора задумываться, пора прислушиваться.. Оценка времени давно показала себя с плохой стороны - не умеет человек оценивать временные рамки. Поэтому задачи оценивают в более грубых единицах - по сложности (story points), либо, и это приобретает популярность, просто на глаз определяют сколько задач брать в итерацию. Ведь в итоге важно не то сколько времени потратил конкретный человек, а сколько задач он сделал.
Залогированное время помогает находить проблемы . Т.е. если человек потратил слишком много времени на какую-то задачу, то либо он плохо разбирается в этой области (и ему нужно помочь), либо задача поставлена неверно, либо та часть приложения с которой он работает - проблематична. Да, это правда может помочь, но только если эти все проблемы не обсуждаются на ежедневных статус-митингах. Т.е. логирование времени тут заменяет общение с людьми. На самом деле общение с людьми не заменить, это всегда более эффективно, поэтому в данном случае (логирование времени как инструмент для выявления проблем) - это один из симптомов того что команда мало общается. На daily standups проблемы и так бы выявились при правильном подходе.
Если логировать, то как?
Во-первых, главное - это логировать не время, а сделанную работу. Лучшее место для этого - commit message если вы работаете с кодом и/или issue tracker. Так мы прогресс держим близко к тому где все крутится, не нужно далеко ходить чтоб узнать что конкретно сделал тот или иной член команды.
У красноглазых есть отличные гайдлайны о том как должны выглядеть сообщения в коммитах и что там должно помещаться, вот еще статейка по-короче . Как правило если ваш коллега подошел к вам с вопросом, ему что-то не понятно о вашем изменении, значит коммит был описан плохо. Это важно во-первых для повседневной работы: не все можно обсудить на статус-митингах, а дергать по каждой мелочи коллег - значит мешать им делать свои задачи. Во-вторых, это история изменений - то что было сделано определить хоть как-то можно по содержимому, то зачем вы сделали это и почему не по-другому - об этом коллегам прийдется догадываться, а ведь не каждая фирма готова оплатить курсы молодого телепата.
По логированию времени (или в общем по time management’у) есть много всего, повторять чужое не хочу, но посоветую все-таки очередной раз попробовать Pomodoro ;) У меня получилось где-то с третьего, и все равно периодически забрасываю.
Подытожим
Логирование как работы, так и потраченного времени - безусловно полезные вещи. Особенно для себя любимого. Научить кого-то это делать - тоже полезно. Но строить по этому какие-то метрики - бесполезная затея.
Состав сервисного лог-журнала
Сервисный лог включает в себя все этапы работы сервера логики. Данным параметром регулируется его состав: какие режимы и модули производят логирование, а какие нет. Параметр представляет собой строку, каждая из позиций которой содержит 0 или 1 и отвечает за включение логирования конкретного режима.
Сервисный лог нужен при обращении в тех.поддержку по проблемам, касающимся работы сервера. В обычном режиме его можно держать отключенным (или включенным неполностью), так как плотная работа сервера в непрерывном режиме может создавать файлы журнала в объеме до нескольких гигабайтов в сутки. Для отладки в реальном времени необходимо включить исследуемые режимы, произвести определенные действия, после чего вновь отключить. Сформированный файл в совокупности с другими журналами отправить в тех.поддержку. См. также модуль Сборка лог-журналов .
Значение позиций параметра в порядке следования
- 1. ProcedureShow
- 2.PBXSS
- 3.DB - логирование обращений в базу данных
- 4.HAL - логирование ядра
- 5.CallTaskManager - управление задачами
- 6.SmsTaskManager - логирование смс-сервиса.
- 7.SvcTaskManager - логирование служебных задач
- 8.AutoCallManager - логирование сервиса автодозвона
- 9.CallCenter - общее логирование Call-центра, имена операторов пропадут из задач.
- 10.CallPoolProgressive - логирование задач с прогрессивным обзвоном
- 11.CallPoolDistributed - логирование задач с ручным распределением
- 12.CallPoolReserved - логирование задач с закреплением абонента за оператором
- 13.CallPoolIncoming - логирование входящих задач
- 14.Searcher - логирование поиска оператора и абонента
- 15.CallHelper
- 16.TaskLogic
- 17.TALK - логирование диалоговых сценариев
- 18.SVC - логирование служебных сценариев
- 19.IVR - логирование IVR сценариев
- 20.IvrObjectReport - логирование объектов IVR
- 21.LineLogic
- 22.LineThreads
- 23.LLHWactions
- 24.Queue
- 25.QueueDebug пропадут подробности переключений
- 26.Timer - логирование таймеров
- 27.FlashTimer - логирование таймеров при переключении
- 28.ExtLines - логирование внешних линий
- 29.GetSetState
- 30.ShowHWActions
- 31.Threading
- 32.UserState - логирование состояний пользователя
- 33.DTMF - логирование полученных DTMF сигналов
- 34.Signals
- 35.MessageLoopReport
- 36.Conference - логирование конференц-связи
- 37.IMMessaging - логирование сообщений
- 38.UserRequest
Логирование счетчиков производительности
При активации в лог-журнал watcher сервера наравне с информацией о собственных процессах службы начинают фиксироваться стандартные счетчики производительности.
В зависимости от выбранного режима логируются значения базовых счетчиков, пользовательских счетчиков или и тех, и других вместе. Базовыми считаются счетчики: общая загрузка процессора (0-100, %), объем доступной физической памяти (МБ), текущая очередь диска (0-10), процент использования файла подкачки.
В качестве пользовательских могут быть указаны любые другие счетчики, существующие и доступные в системе. Для их указания используются специальные ключи файлов конфигурации:
где {0} - числовой порядковый индекс счетчика производительности. В качестве значения для счетчика производительности, отслеживающего общую загрузку процессора, например, подставляется "Processor|% Processor Time|_Total ". Для других счетчиков соответственно.
Логирование использования ресурсов
С помощью параметра можно настроить вывод в лог журнал WATCHER информации по использованию процессом (процессами, в случае разделения) ресурсов системы. Объем используемой памяти, количество открытых дескрипторов, количество потоков, пользовательские системные ресурсы, ориентировочное среднее процессорное время по всему процессу и отдельно по всем его потокам.
Логирование сбоев тактирования таймера
С помощью параметра можно настроить вывод в лог журнал WATCHER информации по выделению процессорного времени потокам системы. Вместе с основной деятельностью сервер постоянно проводит проверочные замеры тестовым таймером и засекает задержки в выдаче управления. В случае если операционная система отказывает в выделении службе сервера процессорного времени, это происходит и с тестовым таймером. Существует возможность выставить границу для его логирования. Среди вариантов границы задержки в 20 мс, 100 мс, 500 мс, 1 с и 5 с. По умолчанию логируются все задержки более 100 мс. Увеличение и уменьшение значения может потребоваться проводить в случае запроса из технической поддержки в ходе работ над поиском причин заметного некорректного поведения сервера.
Параметры аппаратуры. Конфигурация
В данном модуле можно включить и отключить логирование событий аппаратуры (папка \oktell\Server\Log\Hardware). По умолчанию, некоторые трассировки выключены.
- Во время работы системы логируются события, которые включены в модуле "параметры аппаратуры ".
- В момент запуска системы логируются события, которые обозначены в серверном конфигурационном файле в ключе TRACE_HARDWARE
Ниже приводится описание параметров аппаратуры, соответствующих им ключей и описание.
Параметры аппаратуры. Конфигурация. | Файл конфигурации TRACE_HARDWARE | Описание |
Общая трассировка | CALL | Общее состояние системы |
Трассировка событий аппаратуры | EVENTS | События генерируемые аппаратурой или сетью |
Трассировка медиа трафика | MEDIA-FLOW | Аудио/видео данные проходящие через сервер |
Трассировка сетевых подключений | NET | Включение/отключение сетевых соединений |
Трассировка пакетов протокола SIP | PROTO | Печать пакетов по протоколу SIP. Лог trn. |
Трассировка таймеров | TIMER | Включение/отключение и события таймеров |
Трассировка SIP транзакций | TRANS | Прием передача пакетов по протоколу SIP. Лог ua. |
Трассировка SIP сессий | SESSION | Обработка запросов по протоколу SIP. Лог ua. |
Трассировка транков | TRUNK | Не используется |
Трассировка медийных потоков | STREAM | Включение/отключение и события медийных каналов |
Трассировка предупреждений системы | WARNING | Предупреждения системы об отказе системы с возможностью продолжения работы |
Трассировка ошибок системы | ERRORS | Критические ошибки системы |
Трассировка RTP трафика | RTP-FLOW | Прием передача пакетов по протоколу RTP |
Трассировка сетевых атак | BANNED | Обнаружение и отслеживание сетевых атак на порты SIP. Лог trn. |
Трассировка RTP потоков | RTP | Включение/отключение и события RTP каналов |
Трассировка асинхронных вызовов | ASYNC | Обработка команд в отдельных потоках исполнения |
Трассировка факсов | FAX | Включение/отключение, события и пакеты факс-сеансов. Канальный лог. |
Трассировка 1,2,3,4,5 | FLAGxx (1-15) | Используются разработчиками для отладки системы. Рекомендуется всегда держать отключенными. |
Логирование сценариев
С помощью пункта Логирование указывается будет ли записывать в лог журнал выполнение компонентов данного сценария. Если сценарий отлажен, логирование можно выключить.
Когда работаешь удалённо сложно оценивать время своей работы. У ребят в офисе с этим проблем никаких нет. Они пришли в девять, ушли в пять. Значит восемь часов поработали. А когда ты сидишь дома или ходишь по кафе и коворкингам, относишься к этому по-другому, и потому легко попасть в огромную яму переработок из-за неправильного логирования.
Раньше я рассуждал просто. Моя работа заключается в том, чтобы писать код. Значит, когда я пишу код, я работаю. Получается, что мне нужно логировать время написания кода. После месяца таких логирований возникал вопрос: почему по цифрам получается, что вместо 40 часов в неделю я работал 25-30?
Первый же вывод, к которому легче всего прийти, - я весь месяц работал меньше положенного. Значит следующий месяц надо работать более активно! Но после месяца такой «активной» работы получалось, что работа-то сделана, а с самочувствием что-то явно не так. А ещё все лампочки горят красным , и работа как-то всё медленнее и медленнее работается.
Читателю со стороны, конечно, очевидно, что дело в неправильном логировании. Но если подходить к работе ответственно, самостоятельно в это сложно поверить. Ведь ты по-честному логируешь время, которое потратил на задачу, и по ощущениям ты не можешь потратить на неё больше. «Но у других ведь получается?»
За ответом можно сходить в храм под названием «Наука». Вот что рассказывает Барбара Окли в первом же видео курса Learning How to Learn (в недавней годноте была ссылка на конспект курса):
Что вы делаете, когда не получается до чего-то «додуматься»? Для зомби всё просто: они просто продолжают биться головой о стену. Но живой мозг куда сложнее. Однако, если вы поймёте хотя бы основы того, как он работает, то сможете учиться с большей лёгкостью и с меньшим разочарованием.
Исследователи выяснили, что у нас есть два абсолютно разных «режима мышления». Назовём их сфокусированный и расслабленный.
Все знакомы со сфокусированным режимом. Это когда мы концентрируемся на чём-то, что пытаемся выучить или понять. Но мало кто знает, в чём суть расслабленного режима.
Используем аналогию с пинболом, чтобы разобраться.
Если вы помните, пинбол работает так: вы оттягиваете поршень, затем отпускаете его, он бьёт по шарику, и тот движется внутри автомата, сталкиваясь с резиновыми препятствиями и тем самым накапливая вам очки. Это похоже на то, как работает мозг. В сфокусированном режиме резиновые препятствия стоят очень близко друг к другу, и шарик может двигаться по одной и той же «тропинке», безрезультатно пытаясь вырваться за пределы. А за пределами этих препятствий (может даже совсем в другом углу «автомата») вполне может быть «правильная тропинка», которая приведёт вас к решению текущей задачи. И что же делать в таком случае?
Чтобы добраться до этой «правильной тропинки» вам нужен иной способ мышления - расслабленный. В нём препятствия стоят на большем расстоянии друг от друга, и потому шарик может спокойно двигаться от одного к другому, затрагивая максимально возможное количество оных, и таким образом создавая новые нейронные связи, которых так не хватало в сфокусированном режиме.
Важно понимать, что вы не можете находиться в обоих режимах сразу. Это как монета, которая может быть повёрнута к вам только одной стороной: или сфокусированной, или расслабленной.
Это был мой вольный перевод-пересказ первой лекции , которая доступна без подписки на курс. Лучше посмотрите оригинал, если понимаете английский.
Вернёмся к проблеме. Скорее всего вы тоже часто замечали за собой, что решения творческих задач часто приходят в тот момент, когда вы максимально расслаблены: лежите в ванной, стоите у окна с кружкой чая, сидите в кресле с котом, гуляете вечером на улице. Я обожаю эти моменты, и всегда удивляюсь тому, насколько мозг круто работает. Но это какие-то особенно пиковые состояния, во время которых приходят самые светлые и гениальные идеи. На деле же есть ещё сотни микро-состояний расслабленности, когда вы просто отвлекаетесь от текущей проблемы и идёте заваривать чай, нарезать бутерброды, открывать окно, заказывать очередной кофе у бариста. Или когда просто пару минут залипаете куда-то в стену, потому что внезапно отвели глаза от экрана и «потерялись».
Получается, что учитывая время работы, стоит не забывать и о времени отдыха, потому что это и есть то самое расслабленное состояние, в котором рождаются новые идеи. Если вернуться назад и вспомнить о ребятах из офиса, то они редко сидят на месте по паре часов (как это часто бывает, когда вокруг никого), а постоянно куда-то ходят, с кем-то общаются, обсуждают не относящиеся к работе темы и так далее.
Если вы не забываете о том, что работа - это не только активная часть, но и пассивная (отдых), то скорее всего вам не понадобится часто перезагружаться , и в следующий раз при оценке задач вы не будете думать, что если у вас есть 8 рабочих часов, то это время для непрерывной работы, в которой нет места отдыху.
Нужно логировать всё, что помогает решить задачу. В том числе и отдых.