Большинство утверждений из окружающих статей и заметок на этом сайте ведут к простому утверждению:

>
В работе нужно стремиться к минимизации всех раздражителей.

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

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

Рассуждения ниже построены на опыте эксплуатации веб приложений. Для других способов распространения, например IoT или десктопные приложения, методы и подходы могут отличатся.

Мотивационная часть

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

маффин или чихуахуа

Лог с ошибкой приложения все равно придется прочитать полностью и внимательно. Придется прочитать ВСЕ логи приложения, что бы понять ПРИЧИНУ возникшей проблемы или поведения.

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

Контекст

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

Стоит потратить немного времени, пока вы в контексте, и проверить результат работы на “раздражительность”:

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

Проверьте код наличие мусорных комментариев (TODO ссылку), и на отсутствие полезных. Достаточно ли контекста в тексте ошибки, понятно ли с какой сущностью случилась проблема.

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

Дублирование

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

Но в контексте эксплуатации - все наоборот.

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

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

Я уже много раз видел этот бесконечный цикл в рабочих мессенджерах:

  • создается общий канал по вопросам обсуждения штуки X, пусть будет CI/CD
  • все заинтересованные подписываются на него
  • пока там мало людей и тема интересная - все там присутствуют и помогают друг другу
  • но по ходу времени новых проблем на самом деле не появляется, читать сообщения уже не интересно, канал мьютится
  • владельцы канала иногда делают объявления, но раньше они спокойно доходили до всех, а теперь - нет. И выясняется это как обычно во время инцидента
  • как полечить? правильно - сделать новый канал. Где, точно, сто процентов, пару челюстей с зубами отдам, будут только важные сообщения.
  • через месяц в этот новый канал начинают спамить минорные ченджи и от них опять отписываются или мьютят дофига людей

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

Это все было к тому, что не нужно дублировать информацию касающуюся эксплуатации. Если алерты идут, то только в одно место. Если случилась ошибка АПИ - не нужно в каждом try catch(e) throw e или if err != nil { return err } логгировать дополнительно, что она случилась. Это нужно делать только в месте перехвата ошибки. В том месте, где ошибка или обрабатывается, и флоу выполнения продолжается (graceful degradation). Или где ошибка, как сущность языка программирования, перестает существовать и превращается в данные и улетает в ответ на запрос.

Совместимость

Хочется оставить микро-пометку про обратную и будущую совместимость (TODO ссылку) в контексте раздражителей. Разрабатывая по этим принципам, хоть мы и не уменьшаем раздражителей для себя, но мы все равно делаем полезное дело. Мы уменьшаем раздражаемость у наших потребителей. Статистически могу наблюдать, что изменения в публичном АПИ, или в базе данных, или во внутренностях библиотеки хеширования приводят к колоссальному раздражению потребителей. А если вы не сможете качественно обосновать причину таких изменений, то, скорее всего, потребителя вы потеряете.

Чеклист

Что стоит удалить:

  • лишние комментарии в коде
    • комментарии не должны быть переводом английских слов
  • дублирование логов
    • проблема одна, но в логах приложения выглядит как несколько; хорошо если две, бывает и по пять шесть сообщений на одну ошибку
  • логирование ошибок, на которые никто не реагирует, и не исправляет их
    • если всем пофигу, по почему должно стать не пофигу? заведите баг, запишите в него нужные данные и отфильтруйте ошибку. Или не фильтруйте ошибку, но исправьте баг. Второе, конечно же, приоритетнее.
    • если у вас есть нормальные системы сбора ошибок, например Sentry, то там даже есть встроенная для таких манипуляций функциональность. Они умеют и задачи завести, и статистику ошибки привести, и все детали случившегося лога сообщить.
    • исключение это аудит логи. Во первых, если у вас правда есть специальные аудит логи, то они уже отдельно размечаются. Поэтому их достаточно просто вырезать из общих логов приложения. Во вторых, аудит логи обычно относятся к какому-то бизнес процессу: аналитике, антифроду, отделу ИБ. И вам, скорее всего, в них смотреть не придется.