«Самая дорогая моя ошибка - миграция, несовместимая с выкаткой. Я переименовывал колонку в таблице сделок: owner_id стал assignee_id, потому что поле уже давно значило не то, что называлось. Сделал одной миграцией - ALTER TABLE ... RENAME COLUMN, - поправил код и выкатил всё одним релизом.

Проблема в том, что раскатка в Kubernetes идёт постепенно: несколько минут в проде живут одновременно старые и новые поды. Миграция применилась мгновенно, а старые поды продолжали спрашивать owner_id - колонки уже не было. Примерно шесть минут часть запросов к сделкам падала пятисотками. И вторая, более неприятная часть: откатить релиз было нельзя - откат приложения вернул бы код, который тоже не работает с новой схемой. То есть я сам себя лишил кнопки отката.

Чинил движением вперёд: добил раскатку новой версии до всех подов, чтобы старых не осталось. Это заняло минуты три, ошибки прекратились. Правильнее было бы иметь возможность откатиться, но её у меня в тот момент не было - и это была ровно моя ошибка, а не стечение обстоятельств.

После этого я поменял три вещи, и они живут в команде до сих пор. Первое - правило расширяй-и-сжимай: любое изменение схемы растягивается минимум на три релиза. Сначала добавляем новую колонку и пишем в обе, потом переводим чтение на новую, и только потом, когда старого кода в проде уже нет, отдельным релизом удаляем старую. То есть каждая отдельная миграция совместима и со старым, и с новым кодом. Второе - миграции стали отдельным шагом пайплайна до раскатки приложения, и в ревью миграций появился явный чек-лист: работает ли старый код с этой схемой, есть ли откат, берёт ли операция тяжёлые блокировки. Третье - на опасные конструкции повесили проверку в CI: DROP COLUMN, RENAME, CREATE INDEX без CONCURRENTLY, ALTER без lock_timeout требуют явного подтверждения в описании PR.

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

«Живой пример: у нас тормозил список сделок - p99 около двух секунд, менеджеры жаловались. Коллега предложил закэшировать выдачу в Redis: быстро, эффект сразу. Я был против и предлагал сначала разобраться в самом запросе.

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

Дальше предложил не спорить, а посчитать, и сформулировал критерии: какая будет латентность, во сколько нам обойдётся инвалидация и насколько мы рискуем показать менеджеру устаревшие данные. Последнее в CRM важно: сделка меняется постоянно, и увидеть старый статус - это реальная бизнес-проблема, а не косметика. Взял час, снял EXPLAIN ANALYZE: там был seq scan по таблице сделок с фильтром по владельцу и статусу плюс классический N+1 при подтягивании последнего контакта. Собрал составной индекс, убрал N+1 одним запросом - получилось 210 миллисекунд без всякого кэша.

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

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

Бывало и наоборот. Я предлагал вынести отчёты в отдельный сервис, тимлид решил оставить в монолите и читать с реплики. Я остался при своём мнении, но сделал вариант с репликой качественно и не возвращался к этому спору каждую неделю. Мы договорились о точке пересмотра - если отчёты начнут влиять на основную нагрузку. Через полгода это случилось, мы вернулись к разговору уже с графиками, и сервис выделили. Мне кажется, это правильный способ: спорить до решения, работать после него, и заранее договориться, что заставит нас пересмотреть выбор.»

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

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

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

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

И последнее - договариваюсь о точке контроля. Например: "проверим в четверг; если к четвергу тестовый контур не появится, идём по урезанному варианту". Тогда решение принимается спокойно и заранее, а не в вечер дедлайна. Чего я стараюсь не делать - это молча догонять по вечерам. Даже если получится, команда узнает о риске последней, и в следующий раз мне просто не поверят на слово.»

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

Я поэтому свои истории специально проверяю на два вопроса: "есть ли тут кто-то виноватый, кроме меня" и "что изменилось в системе после этого". Если на первый ответ "да", а на второй "ничего" - историю надо переписывать или брать другую.»