Фёдор Борщёв

Заметки с тегом «Инструменты»

Годовая подписка — обман

Почти всегда, когда производители софта предлагают купить месячную подписку на софт, нам предлагают сэкономить 20%, оплатив сразу на год. Почти всегда это — пустая трата денег.

Во-первых, ваши 20% экономии тут же превращаются в 10%, когда вы понимаете, что деньги можно было отдать не разработчику, а на год положить в любой доступный инвестиционный инструмент (историческая доходность по ETF Тинькова, один пай которого стоит 5 ₽, — 14% годовых).

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

Если бы вы платили помесячно, вы бы потратили 600 рублей. А за год вы заплатили 1000 — получается, либо вы потеряете 400 рублей, либо останетесь на Bear. Через 4 месяца вы наверняка забудете отказаться от подписки и оплатите ещё 1000 за будущий год.

Если цифры кажутся маленькими — представьте то же самое с каким-нибудь устаревшим Adobe Photoshop за сотни денег в месяц, который, как внезапно выясняется, можно заменить на прекрасный Pixelmator Pro с единоразовым платежом.

У меня есть только одна программа, за которую я плачу годами, — это дневник Day One. Для меня это программа больше про вечность, чем про фичи: мне приятно осознавать, что мои личные переживания и важные моменты из жизни уходят в облако, в котором пролежат, возможно, и после моей смерти. Наверное, если бы за Day One можно было платить десятилетиями, я бы и на этом сэкономил 20%. А вот за всё остальное я плачу помесячно, что и вам советую.

Инфостиль в заголовках задач

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

Но есть одно место, где я жёстко включаю Ильяхова — это заголовки задач в трекере. Насколько вы бы захотели работать в команде, которая целый день занимается какой-нибудь «необходимостью реализовать новый механизм построения отчётности» и, чтобы не произносить это дерьмо в слух, называет задачи по номерам (типа «Как там задача 1238?»). Я — не хотел бы.

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

  • Из заголовка чётко понятно, что нужно сделать. Не «доработать логику корзины», а «Сделать, чтобы при удалении последнего товара корзина очищалась».
  • Никакой воды: смело рубить всякие «необходимо реализовать» и «отсутствие возможности».
  • В заголовке есть понятные для всей команды ключевые слова. Если задача про вкладку Логистика, то так и писать «логистика», а не «интерфейс менеджера до доставке».
  • Если задача мало декомпозирована («привести в порядок учёт зарплаты») то заголовок должен описывать следующий понятный шаг, к примеру «Понять, почему заказ 100500 не пробросился в 1с» или «сделать кнопку «не согласен с расчётом».

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

Курс «стать тимлидом»

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

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

В соавторстве с Марьяной Онысько, руководителем новых проектов в МИФе, я собрал целый курс о навыках тимлида который так и называется «Стать тимлидом». Марьяна классно разбирается в продуктах и имеет огромный опыт в МИФе, и вместе мы покажем ситуацию с обоих сторон баррикад — я буду говорить со стороны разработки, а Марьяна — со стороны бизнеса.

Наш курс будет полезен тем, кто только собирается стать тимлидом, и тем, кто уже работает тимлидом и хочет прокачать навыки. Занятия стартуют 26 октября и продлятся 5 недель. На каждой неделе вы будете получать лонгрид, домашнее задание, публичную q&a сессию, и одного (а иногда и двух) признанных в индустрии спикеров, помимо нас с Марьяной.

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

Всем читателям моего блога — скидка 15% по промокоду FEDORBLOG.

Органы чувств в инфраструктуре

Вот упал у вас прод, вы заходите по ssh и видите, что Load Average в 10 раз больше, чем количество ядер. Люди не могут воспользоваться сервисом, партнёры задают вопросы, а всё, что вы знаете, — это то, что нагрузка выше номинальной. Где именно, из-за чего всё это случилось — непонятно.

Вы залезаете в консоль, ищете по логам (медленно, сервер-то перегружен), запускаете ps и strace, совершаете другие шаманские действия. Чувствуете, что двигаетесь по тёмному лесу с закрытыми глазами, как бегуны из старого клипа Pendulum.

Четыре золотых сигнала — время ответа, количество запросов, рейт ошибок и запас нагрузки

Выход простой — сделайте себе нормальные органы чувств. Заведите  дашборды, которые покажут 4 золотых сигнала (время ответа, количество запросов, рейт ошибок и запас нагрузки) и ТОП-10 самых нагруженных эндпоинтов (отдельно по количетву запросов, отдельно — по затраченному машинному времени). 4 сигнала заменяют кучу производных метрик и позволяют однозначно сказать, лежит ли прод:

Чётко видна авария с 16:00 до 18:00

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

Flame graph показывает, что PostgreSQL отвечал чуть меньше, чем 30мс: отличный результат

Такая работа с цифрами и статистикой называется APM — App Performance Management. Мой любимый сервис для APM — Datadog. Я выбрал его когда-то за хороший дизайн: Datadog не просто даёт инструменты, которые собирают цифры, но и подсвечивает и объясняет самые важные из них.

Дефолтный борд Датадога для PostgreSQL

Если у вас есть хоть какой-то продакшн, который до сих пор не обложен цифрами — прикрутите к нему APM. Не хотите Датадог —  есть куча конкурентов: New Relic, AppDynamics, AppOptics, Elastic APM.