Зарисовка из жизни IT~BP: Маленькие проблемы и неожиданные выводы из них

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

Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний (АйТи Мегастар/АйТи МегаБокс/АйТи Мегагруп). Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Являюсь одним из идеологов концепции IT~BP (партнёрство между IT и бизнесом).

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

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

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

Поэтому про логирование на пальцах и про грустные выводы, когда его нет.

Простыми словами логи это «летопись» работы программы, которая заполняется по ходу её работы. Либо говоря более техническим языком — телеметрия, которая собирается для анализа и исправления ошибок в работе комплекса программ. Бытовой и печальный пример — это «чёрный ящик» у летательных аппаратов. Авиакатастрофа — это трагедия, но одних переживаний мало, надо понять почему она произошла, и как сделать так чтобы такое более не повторялось.

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

Наверное в этом месте нужно сделать интересную ремарку про нейросети в 2023 году. Решения типа Copilot и ему подобное вряд ли заменят программистов, потому что они могут написать какой-то код, но не могут его отладить. Это просто задача более широкого класса, чем генерация кода.

Если разделить работу программиста на на части, то львиная часть придётся на «Понять что от тебя хотят и как это вообще сделать», затем будет та самая отладка и где-то в самом конце, где-то 5% от рабочего времени — это набор/генерация кода.

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

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

В своё время конкуренцию отладке представлял примитивный метод логирования «отладка принтами». Это когда программа пишет в консоль либо текстовый файл отладочные сообщения и значение части своих переменных. И вот этим пользуются до сих пор.

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

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

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

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

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

Выходом из ситуации служит сбор той самой телеметрии при работе программы. Причем сбор в особом, более подробном режиме. Дело в том, что сейчас при работе программ могут генерироваться гигабайты логов, которые нужно где-то хранить и как-то обрабатывать. Это можно делать в рамках коротких итераций тестирования, но не стоит делать в рамках длительной эксплуатации. Есть даже особый вид ошибки/инцидента, когда сервер забывает все своё файловое пространство логами и умирает, на жаргоне это звучит как: «обожраться логов и упасть».

Когда есть логи выполнения программы и они приложены к описанию ошибки, процесс исправления этой самой ошибки становится много легче. А еще появляется шанс исправить ошибки без чёткого сценария воспроизведения.

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

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

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

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

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

Конечно, программист не будет смотреть на набор ноликов и единичек, он откроет файл в шестнадцатеричном виде. Вместо ноликов и единичек будут циферки от 0 до 9 и буковки от A до F. Вы не поверите, но так информация воспринимается проще и быстрее…

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

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

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

Как результат, мы исправили свою прикладную библиотеку, а вендор выпустил обновление к своему серверу, правда через полгода. Как мы локализовали причину, при условии того, что сервера внезапно умирали на продуктиве, лучше не вспоминать.

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

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

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

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

Теперь представим, что должно произойти, если у технической поддержки нет этих самых логов? Просто выражать сочувствие пользователям и говорить, что мы снова попросили программистов разобраться в чем дело? Затем выслушивать эмоциональные ответы пользователей, у которых встал важный бизнес-процесс, а всех этих «технических специалистов» они видели на интересном месте в необычных условиях?

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

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

Возможно, что человек отлаживается по старинке через «принты». Но это значит, что человек никогда не задумывался над тем, как его код будет использоваться в дальнейшем. Человек не создаёт программный продукт, он просто кодирует и выполняет задачи, программистом ему состояться не случилось.

Смотрим на тестировщиков, QA-специалиста и прочих, которые не понимают, что такое логи и зачем они ему нужны. Сразу же возникает вопрос, а как эти люди вообще тестируют-то? Просто раз за разом «протыкивают» программу, как «дрессированные обезьянки»? Почему для них отсутствие логов сразу не стает признаком, что что-то идет не так? Почему для них уже это не является ошибкой?

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

Это тоже люди, которые просто выполняют задачи, но не проверяют либо обеспечивают качество. Как QC либо QA им состояться не случилось. Пусть даже они освоили автоматизацию тестирования и могут часами рассказывать про тест-дизайн. Они просто не понимают что и зачем они делают.

Смотрим на системного аналитика. Это тот человек, который должен был себе представить всю систему целиком причём в динамике по времени. От момент её разработки до момента её успешной эксплуатации. Успешная эксплуатация подразумевает под собой несколько систем логирования.

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

Как о них можно было забыть и о чем на самом деле думает такой системный аналитик в процессе своей работы?

Честно говоря, если поглядеть на всю эту картину немного глубже, то выводы будут более печальными и жёсткими. Но все же это уже разговор технических специалистов с «техническими специалистами» о качестве технических специалистов. Старый разговор инженера с ремесленником.

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

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

Если вы дочитали до конца и написанное было для вас полезным, то спасибо вам. Вне зависимости от того, технический вы специалист либо нетехнический.

Полезные материалы по теме: