Mea maxima culpa 1/2

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

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

Ownership. Ответственность. Работник месяца, желательно с повышением зп и грейда.

План разбился об неожиданную особенность командной разработки: в ней есть команда.

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

Оказалось, что код был едва ли не самой дешёвой частью переписывания, а мой отпуск — не единственный ресурс компании. Странная система :))

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

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

Для таких случаев в IT есть такое понятие как postmortem — разбор инцидента после того, как всё починили.

Хороший постмортем отвечает на несколько вопросов:
• что произошло;
• кого и что затронуло;
• почему это стало возможным;
• как проблему обнаружили и исправили;
• что изменить, чтобы она не повторилась.

Последний пункт важнее всего. Постмортем без конкретных действий — ментальная мастурбация.

Ещё постмортем должен быть blameless — без поиска виноватого. Фраза «Вася нажал не туда» не объясняет, почему одна кнопка могла положить прод.

Нужно спросить: почему изменение прошло ревью? Почему его не поймали тесты? Почему откат занял сорок минут?

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

…