Недавно у меня случилась авария — я переработал до отказа: буквально руки не поднимались делать дела, сил хватало закрыть 1–2 задачи в день, а всё остальное время сливал в пустоту. После почти двухнедельного отдыха (это для меня много), я сел и начал анализировать — из-за чего это случилось, и что сделать, чтобы больше так не выдыхаться.

Из-за чего случилось — довольно понятно: мой предыдущий отпуск был запланирован на 26 февраля 2022 года, и конечно же я его отменил — и курс доллара непонятный (я летел в ОАЭ), и от команды далеко уходить не хотелось. Потом я как-то пытался компенсировать отдых — брать дейоффы, побольше спать и поменьше работать, но не получилось — видимо сказался общий нервяк от повестки.

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

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

В поисках KPI я посравнивал своё отдохнувшее состояние с тем, что было в начале мая и нашёл вот такие отличия усталого Феди от нормального. Усталый Федя:

• Избегает общения с новыми людьми (да и со старыми тоже).
• Не хочет слушать новую музыку (даже daily mix в Spotify), смотреть новые фильмы.
• Не хочет медитировать и писать в дневник.
• Много ест (странно, но потребление алкоголя при этом в норме).
• Не хочет в новый город\новую кофейню\новый ресторан.

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

Это и будет KPI — теперь если я обнаружу, что за две недели ни разу не притрагивался к дневнику, то я сразу же брошу все дела и устрою себе минимум 5-дневный отпуск.

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

Когда программисты называют сроки в виде вилки, типа «2–4 дня», многие менеджеры слышат только первую часть вилки — «2 дня». Если сказать «во второй половине мая», менеджер услышит «15 мая» вместо «между 15 и 30 мая». Если сказать «не меньше трёх дней», менеджер услышит «три дня».

Что с этим делать? Если вы программист — называйте абсолютные, а не относительные сроки. Не «2–4 дня», а «будет в следующий понедельник». Не «во второй половине мая», а «1 июня». Не «не меньше трёх дней», а «через три дня назову срок».

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

Гениальный совет, который когда-то подсмотрел у Николая Товеровского — чтобы не опаздывать на офлайновые встречи (люди, бывает, разговаривают лично), можно приезжать сильно заранее — не на 15 минут, а на час или даже два. Время ожидания не пропадает — всегда найдутся дела, которые можно поделать из любого места: пописать код, поотвечать на письма, навести порядок в проекте.

Для меня этот совет — про спокойствие. В ежедневной рутине запаренному мозгу сложно переходить от одного дела без дедлайна (пишу код, пока не напишу) к делу с дедлайном (в 15:00 встреча). Боишься не успеть: оставить репозиторий с падающими тестами, а список дел — с непоставленной галочкой. Чем ближе ко времени выхода, тем важнее незавершённость: кажется, что я если прямо сейчас не допишу этот код или не удалю эти два письма из инбокса, то небо упадёт на землю. У вас, уверен, получше, но но неприятный выбор, — доделать дело или опоздать — есть у всех.

Если на встречу, запланированную в 15:00 приехать в 13:00, острота выбора снимается — даже если вы чуть-чуть задержитесь и приедете в 13:15, никто не заметит разницы. Время с 13:15 до 15:00 тоже не пропадёт — поделаете рутинные дела. Если вы интроверт, как я, то ещё и настроитесь спокойно на встречу, сделав обстановку комфортной — удобно поставите ноутбук. привыкните к креслу, выпьете кофе.

Пользуюсь этим советом уже несколько лет, иногда даже встречаю коллег по лайфхаку — это когда договорился встретиться в кофейне в 20:00, приходишь туда в 18:30, а тебя уже ждут.

С 2018 года я публично ругаю привычку многих админов тащить с собой ИТ-инфраструктуру: поднимать локальные GitLab и Sentry, использовать собственные сервисы вместо PaaS, DBaaS и прочих -aaS. Вот пост об анализаторах логов и огородиках, с которого всё началось.

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

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

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

По мере роста владельцы защищаются от рисков — нанимают больше профессионалов, забирают себе больше инфраструктуры, выходят на другие рынки, чтобы диверсифицировать бизнес. Точно такая же картина и с SaaS-ами. Если вы стартап — у вас по прежнему нет ресурсов на операционную поддержку собственных огородиков. По мере роста вы становитесь всё более и более независимы. Когда дорастаете до Амазона — строите собственные датацентры.

После 24 февраля поменялся только набор SaaS — больше нет Mailchimp, Slack или продуктов Atlassian. Но у всех этих сервисов есть менее крупные аналоги, которые продолжают работать с русскими. Да и отечественный производитель не отстаёт — у большинства сервисов уже есть замены. И пусть эти замены обычно выглядят как жигули, и от езды на них болит спина — они всё равно снимают с бизнеса огромное количество нагрузки: вам не нужно мониторить серверы, обновлять версии ПО, разбираться в протоколах взаимодействия сервисов друг с другом.

Так что огородики — это норм, если вы можете себе позволить не есть огурцы с рынка. А если не можете — для вас картина сильно не поменялась.

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

Вот дежурите вы он-колл в выходные, с друзьями на шашлыках. Вам приходит сообщение — «сайт упал». Аларм! Бросаете все дела, залезаете на самую высокую берёзу и видите, что по графикам всё норм. Система решила, что сайт упал, потому что сервер один раз не ответил вашей пинговалке из заббикса. Будете ли вы и дальше доверять сообщениям такого мониторинга? Уже гораздо меньше. А если получите ещё пару СМС в тот же день — то и вообще перестанете. Если такие сообщения будут приходить каждый день — уведомления со временем превратятся в белый шум.

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

Если формулировать общее правило — ложные срабатывания дискредитируют всю вашу систему алёртов, как в басне про Мальчика и волков. Если ваша система сыпет мусором — смело вырубайте все уведомления от неё: всё равно никто из вашей команды их не читает, даже если и делает вид.

Дайте людям привыкнуть к тишине, а затем потихоньку вводите алёрты, в которых вы уверены на 100%.