«Упал прод — выпей чаю»: как IT-компании решают проблемы и что делают с провинившимися
В соцсетях активно обсуждается пост девопса с мнением, что каждый айтишник должен уронить что-то важное и не всегда стоит рваться сразу же устранять проблему. Highload подробнее разобрался в теме и опросил ряд продуктовых IT-компаний и стартапов, как они реагируют на падения и какие принимают меры. Спойлер: провинившихся больше не «сжигают на костре» и не увольняют (во всяком случае, редко).
О ситуации
В своей публикации в LinkedIn Head of DevOps Анастасия Сокова рассказала, что за пять лет работы девопсом видела много случаев, когда молодые специалисты роняли либо прод, либо тестовую, но очень важную среду. И каждый раз она наблюдала одну и ту же реакцию: паника, мольба о помощи во взгляде, раскаяние в содеянном.
«Я знаю цену падения прода, но подключаюсь к решению только в крайнем случае: уронить что-то важное — это опыт, который должен приобрести каждый. Без него ты вряд ли поймешь, почему нагромоздили такие барьеры безопасностей, а значит и сам не будешь использовать эти решения, — говорит Анастасия. — Но за время работы я столкнулась с проблемой, что человек в страхе и панике может наворотить еще больше дел, доломать то, что и так уже упало».
По мнению специалиста, лучшее, что люди могут сделать во время критичной проблемы, — это перестать паниковать. Но донести до сознания стрессующих айтишников эту мысль сложно. Потому однажды в момент падения прода она просто позвала «провинившегося» пить чай.
«Да, это было прямо в момент, когда прод лежал. За десять минут, пока мы пили чай, сотрудник успокоился, и у него родилась прекрасная идея о том, как поднять то, что упало. С тех пор при найме молодых специалистов у меня в списке правил красуется: “Упал прод — выпей чаю”», — рассказала Анастасия.
Что думают айтишники
Пост собрал почти 180 комментариев — айтишники реагировали по-разному. Большинство специалистов считают, что идея пить чай и не пороть горячку, может, и правильная, но чревата последствиями от менеджеров и топов.
Другие начали подшучивать над мнением автора.
Также айтишники посчитали подход к работе мудрым и стали делиться собственными альтернативными практиками. Например, мытье посуды тоже неплохо прочищает мозги.
Что происходит в компаниях: опыт Jooble
Jooble — популярный сайт по поиску работы, которым пользуются жители свыше 70 стран мира. Какой в компании план действий при падении прода, рассказывает Head of Engineering Jooble Назим Сулейманов.
«В целом мы используем подход Blue/Green Deployment, и при возникновении проблемы проводим практически мгновенный откат изменений, которые к ней привели. Большинство наших проблем решаются именно так, — говорит Назим. — Для остальных кейсов у нас есть специальная роль дежурного, который меняется каждую неделю. Задача этого человека — реагировать на инциденты, о которых он узнает из чата, системы мониторинга и других источников. После обнаружения специалист оценивает степень важности проблемы и занимается ее решением (или сам, или с привлечением других инженеров, если нужно)».
Он добавил, что после крупных падений компания ожидает от людей, которые устраняли инцидент, анализ причин и action pointsконкретные предложения, чтобы подобные проблемы не повторялись.
Опыт appflame
Appflame развивает собственные продукты в нише social network/lifestyle, например, приложение знакомств для ЛГБТК+ Taimi. По словам Chief System Engineer appflame Сергея Семенюка, в их компании как такового плана действий при падении прода нет.
«Мы постоянно в режиме реалтайм смотрим на всю экосистему и стараемся все сервисы зарезервировать. Если все-таки что-то привело к падению прода, мы начинаем дебажить с головы: клиент — load balancer — пару кластеров k8s — продукт — база, кэш, шины, — делится опытом Сергей. — Мы стараемся не давить на человека который уронил продакшн, а просто поговорить, почему так вышло, вынести полезные уроки из этого инцидента, чтобы в дальнейшем не наступать на похожие грабли».
Опыт Waka
Waka создали приложение для знакомств по мемам внутри Telegram. CTO Waka Илья Савчук согласен с мнением девопса о том, что увидеть, как все перестало работать именно из-за тебя, а затем с холодной головой сесть и починить — это важный боевой опыт для любого специалиста. Он поделился опытом решения аналогичной проблемы в своей команде.
«Если прод упал во время работы, то запускается disaster recovery server. Мы смотрим графики и логи, выявляем причину инцидента, устраняем его. Если упал во время деплоя — откатываем деплой и так же расследуем инцидент. По поводу мер по отношению к специалисту: если процессы на проекте настроены так, что один человек может сложить инфраструктуру — проблема, скорее всего, в самой инфраструктуре, — считает Илья. — Видимо, где-то не хватает тестов или есть проблема с доступами. Явно стоит обсудить происшествие с сотрудником, объяснить, какую цепочку действий он запустил».
Также СТО подчеркнул, что следует поменять процессы так, чтобы ситуация не повторилась.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: