Это же соц. сеть верно? Значит опробуем писать посты 👍 Пока без картинок)

Месяц назад довелось прочитать книгу "Успех через провал: парадокс дизайна" (Генри Петроски). Материал в целом про инженерию (и много там про строительство мостов), решил что будет полезно. Ключевая идея - успех построенный на успехе это скользкая дорожка, т.к. можно не учесть ошибки предыдущего успеха. Например, это можно отнести к копипасте продуктов - если вы не строили продукт, который копируете, то можете не учесть опыт отдельных вещей в нем и ошибочно их вырезать. А это может сильно навредить или даже привести к краху (как бывало с разрушениями мостов при смене поколений инженеров). Но этот пост не об этом. Он об ошибках и о том, чему они нас учат. Или чему они научили меня... Пусть этот пост будет первый в серии, если не сдуюсь :)

Начну со смешного фейла, который привел к совершенно не смешному результату - положил прод на лопатки.

Однажды сервер положили снежинки в шапке приложения)

А было это так:

• 1 Ноября, в промежутке с 00:00 по 01:00 прилетает алерт, что на сервере проц улетает в космос.
• спавший разработчик взлетает с постели и начинает тыкать в клавиатуры мышки и браузеры. Ищет причину происходящего. За 10 минут ничего не находит и по правилу "прод должен работать 24/7" перезапускает таки сервер. Прод ожил. Разработчик потыкал логи сонными глазами, не нашел ничего и пошел спать с мыслями "какой-то мэджик, нужно на свежую голову смотреть". Но засыпал с подозрением.
• В районе 04:00 снова алерт, разработчик спит. Благо есть второй разраб. Он подхватывает жалобу делает все то же, что и первый. В итоге перезапуск сервера. Уходит спать с теми же мыслями.
• 11:00 - история повторяется, первый разраб у руля. Видит что перезапускали сервер где-то в 4:10. 3 раза закономерность! Идет копаться в логах, метриках мониторинга, конфигах, предварительно перезапустив сервер...
• следующие 6 часов два разработчика копаются в логах, коде и конфигах, периодически перезапуская сервер. Все техническое проверили и исключили. Сервис работал месяцами без проблем, а тут вдруг на тебе, как по расписанию в 00 начинается фейерверк. Возникает гипотеза, что где-то в коде или зависимостях есть бомба на 1 Ноября. Через некоторое время её находят - 1го Ноября включаются снежинки в шапке сайта :)))

Как снежинки могут положить весь сервис? Оказывается могут, если их написал кто-то через ИИ в январе прошлого года, запихал туда setTimeout, не сделал проверку на отключение снежинок в SSR, да еще и не сделал чистку при onDestroy. А потом кто-то (я) заметил закомментированный запуск снежинок летом и решил навести порядок - убрать комментирование и подставить запуск на 1е Ноября. Ну а что, безобидные снежинки, уже работали, запуск по дате и готово. Но почему не упало прошлой зимой, снежинки же работали?  Оказывается тогда небыло SSR, его сделали только в Июле. А снежинки копились на серверной стороне в SSR на каждый новый запрос!

Итоговый набор ошибок, приведших к инциденту:

1. Отсутствие грамотного code-review на проекте какое-то время. Было два разраба, фронт-джун и фуллстак-мидл. При этом джун работал первый месяц, а мидл был поуши в своих задачах. Отстроенных процессов у них небыло, как и команды. Мидл проверял работу джуна сквозь пальцы из-за сжатых сроков (если вообще проверял конкретно эту задачу). Где-то в конце февраля пришел я и CR наладили, но код уже был в гнезде.
2. Доверие к коду, который ты не проверял и не разбирал считая достаточным того, что он работал в прошлом году. Это целиком и полностью моя ошибка. И она прямо по книжке - провал на предыдущем успехе. "Раз работало, то будет работать" - нет это так не работает.

Чему можно научиться:

1. не пренебригать CodeReviw. Тем более с джунами. Это важно и для них и для проекта.
2. не доверять тому что уже работает, не разобравшись в этом. Лучше потратить час на то, чтобы разобраться в коде, чем потом иметь день потери нервних клеток и денег бизнеса.

Еще стоит грамотно настраивать лимиты на контейнерах, чтобы не клали всю машину. Записано ✏️