Pull to refresh
Флант
DevOps-as-a-Service, Kubernetes, обслуживание 24×7

Junior, который в первый день работы удалил базу данных с production

Reading time2 min
Views145K
Reddit и другие иностранные ресурсы буквально покорила история о младшем разработчике, который, придя на свою первую работу, в первый же день удалил базу данных на production.


«Два типа людей в эксплуатации: кто уже сломал production, кто ещё только собирается это сделать»

Опубликованная 10 дней назад заметка собрала более 23 тысяч положительных голосов на Reddit и разошлась по другим специализированным ресурсам вроде The New Stack. Суть истории такова:

Сегодня был мой первый день на работе в роли младшего разработчика программного обеспечения (Junior Software Developer) и моя первая позиция после университета, не являющаяся стажировкой. К сожалению, я сильно напортачил.

Мне дали документ с информацией о том, как настроить локальное окружение для разработки. Инструкции включают запуск маленького скрипта для создания личной копии БД с тестовыми данными. После запуска определённой команды я должен был скопировать URL/пароль/юзера базы данных из её вывода и настроить dev-окружение, указав там эту базу. К сожалению, вместо копирования данных нужной команды я по какой-то причине использовал значения из самого документа.

К несчастью, оказалось, что указанные там значения — от базы данных в production (не знаю, почему они задокументированы в инструкции по настройке dev-окружения). Далее, как понимаю, тесты добавили ненастоящие данные и очистили существующие, то есть между запусками тестов все данные из БД в production были удалены. Честное слово, не имел представления, что я сделал, а чтобы это выяснить/осознать, кому-то из коллег потребовалось даже не полчаса.

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

Дальнейшее обсуждение сотрудников компании в Slack показало, что бэкапы для этой базы данных не восстанавливались, а «вся команда разработки пребывала в режиме паники».


«Бэкап Шрёдингера: состояние любого бэкапа остаётся неизвестным, пока его не попробовали восстановить»

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

Проведённый на The Register опрос среди 13+ тысяч пользователей показал, что младшего разработчика считают правильно уволенным всего около 1 % человек, а вот уволить CTO захотели 47,5 % интернет-пользователей. А как думаете вы?

P.S. В комментариях Reddit указывают на похожую историю в Amazon, случившуюся в 2012 году, и, конечно, ещё весьма свежий кейс с GitLab.

P.P.S. Назначение этой публикации — напомнить об очевидных вещах:

  1. Уделяйте должное внимание выстраиванию важных внутренних процессов компании и документированию.
  2. Не забывайте про бэкапы (и восстановление из них).
  3. Даже в стрессовых ситуациях сохраняйте адекватность по отношению к людям.
Only registered users can participate in poll. Log in, please.
Кого в такой истории действительно стоит уволить?
1.02% Разработчика78
57.27% Технического директора4374
25.39% Ответственного за бэкапы1939
16.32% Никого1246
7637 users voted. 859 users abstained.
Tags:
Hubs:
Total votes 139: ↑136 and ↓3+133
Comments376

Articles

Information

Website
flant.ru
Registered
Founded
Employees
201–500 employees
Location
Россия
Representative
Александр Лукьянов