«Два типа людей в эксплуатации: кто уже сломал 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. Назначение этой публикации — напомнить об очевидных вещах:
- Уделяйте должное внимание выстраиванию важных внутренних процессов компании и документированию.
- Не забывайте про бэкапы (и восстановление из них).
- Даже в стрессовых ситуациях сохраняйте адекватность по отношению к людям.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (374)
vesper-bot
13.06.2017 09:49+24Там никого увольнять не надо — бизнес рассыпется, и все вылетят, а джун этому только поспособствовал как триггер нескольких уязвимостей.
uSasha
13.06.2017 10:20+32Более того, зачем увольнять сотрудников, которым провели такой дорогостоящий тренинг.
Guderian
13.06.2017 10:30+51Технический директор уже считай угробил бизнес. А судя по его последующим действиям, он даже не понимает причинно-следственной связи. Вместо того, чтобы повысить джуниора, который одним легким движением нашел ошибки в документации и протестировал систему резервного копирования, он повел себя как истеричка)) Гнать, однозначно!
vtabolin
13.06.2017 11:24+14так потому он и уволил джуниора, чтобы свои косяки попытаться скрыть
fireSparrow
13.06.2017 11:43+5Не факт. Я довольно много встречал людей, которые на месте техдира из этой истории были бы искренне убеждены, что в этой ситуации не их вина, а джуна.
xmixey
13.06.2017 12:28+6Их наличие на этой должности с такой точкой зрения не означает что это норма и так должно быть.
KoCMoHaBT61
13.06.2017 15:38+1Ну, рос рос человек идиотом, повышался в должностях… Идиот это не причина для увольнения, а причина для повышения.
Adel-S
16.06.2017 09:29Это просто известный закон Питера: «Каждый человек в компании растёт до уровня своей некомпетентности». И вот результат.
Akon32
14.06.2017 14:35С точки зрения техдира в данной ситуации действительно очень логично прикрыть себя, найти виноватого и отчитаться перед начальством об успешно принятых мерах.
AlexTheLost
13.06.2017 14:58+6Не думаю что это причина кого-то повышать, не вижу здесь заслуг junior'а, если бы он нашел и указал на это а не все выяснилось в результате ошибки, можно говорить о вознаграждении.
А вот разобраться почему доступ к проду не был защищен и более того креды попали в описание дев настройки нужно. Ну и соответственно потом делать выводы. Возможно это реально случайны косяк, хоть и серьезный, а возможно система.codemax
13.06.2017 16:40Ну ведь на кредах же не написано, что они от прода. Потому джун даже ничего и не заподозрил. Он же не мог заранее сказать о том, чего не знал :)
webkumo
13.06.2017 18:29+1А почему вы ждёте от джуна понимания чем опасен доступ к проду? Я вот пока разок случайной (неправильно набранной командой) не грохнул таблички на тестово-девелоперской базе тоже не понимал — просто не знал о возможных проблемах. Благо у нас бекап были обычные, рабочие… :)
fillpackart
13.06.2017 09:52+4Был похожий кейс, когда я поменял значение некоторых данных на продакшне. Данные были связаны с ценами на продукцию и компания понесла убытки. Но меня не уволили, хоть и критиковали)
igentuman
13.06.2017 10:44+7Похожее дело было. Когда я обернул эксепшн, что бы в логи не сыпалась постоянная ошибка об необработанном эксепшене. Но оказалось, что этот необработанный эксепшн использовался что бы останавливать фродерские транзакции. Так за сутки магазин успел продать кучу товаров фродерам. Меня тогда поругали, но оставили в команде))
PavelZhigulin
13.06.2017 13:13+19Вывод — не используйте исключение там, где не нужно)
AlexTheLost
13.06.2017 15:02+5Ну и ещё один, опытные сотрудники должны проводить ревью каждой задачи.
Ну и ещё один, в любой непонятной ситуации с бизнес логикой, спроси тех кто уже давно работает, все ли я понимаю правильно.
Хотя судя по тому что проброской эксепшенов отлавливают такие бизнес кейсы и не делают ревью и эти советы могут и не помоч.
yoshitoshi
15.06.2017 10:30Полагаться на возникающую ошибку для отсечения левых транзакций — это, конечно, весьма спорный способ…
saroff
14.06.2017 10:03+2Ну, для коллекции — я на своей первой работе почистил все «комментарии» на всех клиентских системах, которые успели обновиться до моих изменений. Произошло это из-за археологического костыля для удаления неверных записей, о котором я не знал. Меня тогда даже не ругали, посадили переписывать этот костыль чтобы он еще чего-нибудь не почистил :)
MasMaX
14.06.2017 12:00Мне кажется такие фейлы у многих встречаются. Я тоже один раз не так бекап снял и потерял данные за полдня работы, восстановить можно руками но долго. Заказчик говорил что там было заказов на неск десятков тыс уе)
fillpackart
14.06.2017 13:17-6Я считаю, это не фейл (в моём случае). Я разработчик, моя работа и моё время в сто раз важнее, чем цены на носки. Я должен разрабатывать адекватное программное обеспечение, а то что при этом у каких-то торгашей невалидные данные на продакшне, не мои проблемы.
hatari90
15.06.2017 10:48Я разработчик, моя работа и моё время в сто раз важнее, чем цены на носки
Надо запомнить. Буду знать, что сказать начальству после случайного массапдейта в боевой БД.fukkit
15.06.2017 10:59С такими заездами для «разработчика» цены на носки в короткий срок могут поднабрать субъективной важности.
fillpackart
15.06.2017 11:00-3Я так и сказал. Но в моём кейсе, я не портил бд. Я просто выгрузил билд проекта у себя дома, чтобы доработать некоторый функционал, связанный с UI для редактирования данных. Доработал, потестил. Но я не знал, что по дефолту в приложении назначен боевой API, а не тестовый. Вот если бы мне об этом говорили, тогда это была бы моя вина. А так — не мои проблемы.
Noa69
13.06.2017 10:06+31Если у них в инструкции для прописаны данные авторизации для продакшн базы, то туда им и дорога, всей компании целиком, от гендиректора до этого студента.
khanid
13.06.2017 14:57+1И не просто на авторизацию, но с правами на изменение (да, я там, где не требуется вносить изменений, делаю ридонли учётки, даже на самых микроскопических базах).
saboteur_kiev
13.06.2017 15:57+3Ну собственно гендиректор может быть далек от айти сектора…
А вот тех-лид да, в /dev/pozor
mayorovp
13.06.2017 10:08+3Я правильно понял, что в инструкции для разработчиков была прописана команда, очищающая базу на проде?
Veikedo
13.06.2017 10:13В тестах, написано же
mayorovp
13.06.2017 10:15Мне дали документ с информацией о том, как настроить локальное окружение для разработки. Инструкции включают запуск маленького скрипта для создания личной копии БД с тестовыми данными.
Veikedo
13.06.2017 10:20Не, вот тут
Далее, как понимаю, тесты добавили ненастоящие данные и очистили существующие, то есть между запусками тестов все данные из БД в production были удалены
vesper-bot
13.06.2017 10:48+2В инструкции стояли креды от продакшн-базы, и указание на тестовый скрипт, который надо запустить с выданными в другом месте кредами. Джун перепутал и вбил креды из инструкции. Тестовый скрипт, скорее всего, включал в себя drop database с совпадающим именем, либо вместе с кредами вбивалось и имя БД. Результат — дроп продакшн-базы.
mazahakajay
13.06.2017 16:53+2Нет, нет, нет! Она ничего не очищала. Просто заменяла рабочие таблицы на пустые!
gsaw
13.06.2017 10:09+5Базу не заваливал, но помогать восстанавливать заказчику приходилось. Он экономил сильно на разработке и некоторых частей для администратирования в софте не было реализовано. По этому данные правились руками, из SQL developer. Один раз один из айтишников заказчика написал крутой SQL апдейт, но выделил для запуска только часть до where и так проапдейтил всю табличку с центральной сущностью — накладными. В обед. То-есть пол дня прошло, десятки грузовиков стоят ждут отгрузки, а все накладные в статусе «closed». Неизвестно что отгружать, накладные даже распечатать невозможно. Бэкап есть, но он делается только по ночам, то-есть практически бесполезен.
Пришлось брать логи приложения и эмпирически восстанавливать статус. Два часа детективной работы. По крайней мере накладные за сегодня выправили. Потом восстановили бэкап в соседнюю базу данных и восстановили уже остальные.Bytamine
13.06.2017 14:23+3Oracle SQL developer?
Там после SQL апдейт можно было заметить, что многовато обновилось и не жать Commit.gsaw
13.06.2017 14:31Ну если у него autocommit стоял, то могло быть и поздно что-то делать. Как у него это получилось не знаю достоверно, может и как-то по другому накосячил, мне так передали.
Kits
14.06.2017 12:05+1А если база оракловая, то с версии 10.1 есть Flashback Query, который вполне позволяет восстановить данные на некоторое время назад. В зависимости от нагруженности базы, размера UNDOTBS и значения параметра undo_retention (по умолчанию 15 минут вроде).
minamoto
19.06.2017 18:20+3Угу. Была такая история. Разработчик заметил и нажал Rollback. И огромная транзакция начала откатываться… В течение нескольких часов. DBA вежливо заметил разработчику, что если бы тот сначала спросил, то проще было бы нажать commit и восстановить таблицу из бэкапа — все бы произошло гораздо быстрее и не стоило бы компании нескольких часов простоя.
hatari90
13.06.2017 15:03В одном банке была аналогичная ситуация, только с владельцами счетов. К моему счастью, я участия в этом не принимал, но атмосфера чувствовалась.
ploop
13.06.2017 16:43Бывало со мной такое за многолетнюю практику. Именно такой случай — выделение в консоли без where.
Обошлось «без жертв», т.к. шкурой чувствуешь — апдейт должен отработать за пару секунд максимум, а тут второй десяток пошел, уже рефлекс на кнопку «стоп»
Ну и ошибки были, что приходилось из бекапов нужные куски данных тянуть. Правда пару раз за всю практику (тьфу-тьфу)
vlreshet
13.06.2017 17:49А как нажатие «стоп» поможет в таком случае (если апдейт не был оформлен в транзакцию)? Просто похерится меньше записей?
gsaw
13.06.2017 18:01+1Если автокоммит не включен, то транзакция начинается после первого DML или DDL, смотря, что за база и настройки. С автокоммитом тут же и заканчивается. Как бы в нормальной базе данных «похерится меньше записей» не бывает.
vlreshet
13.06.2017 18:49У меня мало опыта в работе с БД, поэтому не обессудьте за вопрос. Получается, что если (возьмём MySQL) выключен режим автокоммита, то любой запрос создаёт транзакцию? И если запустить на огромной таблице большой апдейт, а потом остановить его — то все изменения откатятся, не будет такого что часть записей которые «успели» — будут обновлены, а часть — нет?
CrazyNiger
13.06.2017 19:42+1Если автокоммит отключен, то рабочая сессия постоянно находится в транзацкии. Можно сделать несколько апдейтов/делитов/инсертов, но эти изменения «применяться» только после коммита, после чего начнется новая транзакция.
По сути, когда ВКЛЮЧЕН автокоммит, то каждый запрос выполняется в отдельной транзакции, которая коммитися сразу после выполнения запроса.
а потом остановить его — то все изменения откатятся, не будет такого что часть записей которые «успели» — будут обновлены, а часть — нет?
Даже без явно заданной транзакции большой апдейт можно остановить и все изменения, которые успели сделаться, будут отменены.vlreshet
13.06.2017 21:37Спасибо за разъяснение! А то я слышал о транзакциях, но не знал что они неявно работают всегда, думал это механизм который работает только по требованию.
khim
14.06.2017 00:10Вы оба правы. В базах данных где транзакции есть их отключить нельзя обычно — и всё как выше сказано. Но вот конкретно в MySQL есть MyISAM таблицы — там ничего не откатить… разве что убить сервер и покорраптить базу…
CrazyNiger
14.06.2017 08:03Да, это важное замечание. Работа транзацкий зависит от движка, на котором работает таблица. Мой комментарий справедлив для InnoDB.
ploop
14.06.2017 08:04СУБД Postgresql, дефолтные настройки PgAdmin'а, автокоммит включен, но всё, что написано в консоли, выполняется в одной транзакции.
То есть, если написать 5 мелких апдейтов и одни большой, и запустить всё это на выполнение, есть шанс остановить без последствий
webkumo
14.06.2017 14:20По MySQL не знаю как сейчас, 5 лет назад на таблицах, работающих на движке MyISAM (кажется так называется) "транзакция" была предельно "атомарна" — остановленный в процессе апдейт таки внёс бы изменения в часть колонок и не откатил их после остановки.
Впрочем это не касается транзакционного движка MySQL и других известных мне СУБД.
Regis
14.06.2017 16:35Если взять какой-нибудь Postgres либо Oracle, то там можно через специальные функции отменить идущий запрос (если он еще закончился и, соответственно, не случился commit).
Т.е.
1) увидели, что запрос подозрительно затянулся
2) перепроверили запрос и увидели ляп
3) запросили у базы список запросов и нашли проблемный
4) дали команду отменить запрос
5) запрос отменяется, транзакция отказытвается, попорченные данные так и не становятся видимы для всех остальных, кто работает с базой
Примечание: 3 и 4 требуют привелигированного доступа к базе.ploop
15.06.2017 07:54Да, только пункт 2 желательно на последнее место поставить, а то можно не успеть :)
ploop
14.06.2017 08:10Кстати, после этого случая я и узнал, что выполняется только выделенный кусок кода, что потом стал использовать в разработке: можно закомментить всё в окне, и по необходимости выполнять мелкие куски оттуда, не создавая новых окон.
navion
14.06.2017 00:51-1А нельзя сделать бекап логов и прокрутить их поверх ночного бекапа до инцидента?
saboteur_kiev
16.06.2017 11:01Постфактум бэкапы делать нельзя =)
navion
16.06.2017 15:56-1В MSSQL при наличии ночного бекапа можно сделать лог-бекап после инцидента и развернув оба прокрутить до нужной транзакции.
KorP
13.06.2017 10:10+23На то он и джуниор. Для этого у него должен быть наставник, и не только в самый первый день. Да я по себе помню — когда приходишь на новое место и тебе надо что то настроить себе, при этом ты не имеешь совершенно никаких понятий как и что в компании устроено… я будучи не джуниором, имея в инструкции админские пароли от продакшена, не уверен что я ничего не снесу :)
mrMendoza
13.06.2017 10:34+5В инструкциях никогда не храним пароли.
vlivyur
13.06.2017 17:24+2Пытаюсь сдать сейчас проект заказчику, одна из претензий: в инструкциях не указаны логины/пароли администраторов. На мои замечания что вообще-то, после того, как я уйду, вы их должны сменить и соответственно сразу же устареет инструкция, никто не обращает внимания (менять пароли тоже никто не будет).
saboteur_kiev
13.06.2017 15:34+4Откуда вообще у разработчика доступ к production базе?
Доступ к ней должен быть только у админа/девопса/релиз менеджера — того, кто отвечает за деплой на продакшен, кто делает бэкапы. И в идеале доступ выдается временно, под определенным тикетом.
Это конкретно прокол организации и соответственно тех.директора, которые не поставил нормально работу, не добился понимания того, что бэкапы есть и проверены, не добился того, что инструкции адекватные…
Да в общем, тут как-бы очевидно все. Вопрос в том, насколько бизнес поднимется, если у них вообще бэкапов нет (нонсенс просто).KorP
13.06.2017 15:36+1Да тут на самом деле очень много вопросов по организации работы. Но винить джуниора в том, что он пришёл и по незнанию и инструкции с админискими правами всё сломал — это верх безумия (хотя чего ожидать от руководителя, у которого таким образом построена работа!?).
Главное что б руководитель ушёл «по статье», если у них такое там есть.
kir_rik
16.06.2017 10:39>> Откуда вообще у разработчика доступ к production базе?
Я так понял, скрипт снимал бэкап прода и разворачивал на локальной машине. Проблема в том, что доступ был не только на чтение :)Busla
16.06.2017 13:40В таком случае ничего бы не произошло.
Судя по описанию, скрипт создавал БД и заполнял её тестовыми данными.
Ogra
16.06.2017 16:05Один скрипт именно что снимал бэкап и разворачивал его не то на локальной машине, не то на какой-то тестовой.
Второй скрипт убивал все данные в БД и заполнял их тестовыми значениями.
Джун должен был запускать второй скрипт с теми конфигами, что нагенерировал первый, но он запустил его с данными production базы.Busla
16.06.2017 17:04Откуда вы это взяли?
Во-первых, это бессмысленная деятельность — тащить БД в полном объёме, чтобы тут же удалить данные (даже для такой конторы)
Во-вторых, как следует из рассказа, работающих бэкапов не было.
rkosolapov
13.06.2017 10:15+7В истории прекрасно всё :) Не думал, что такое бывает в реальности.
Igor_O
13.06.2017 11:46+2В реальности еще и не такое бывает…
Не буду писать какая именно из СУБД, но при переполнении тома коцает базу. Естественно, ни в один лог не пишется, что место кончилось, да и вообще в логах ничего о проблеме нет. После этого у пользователей начинаются странности. То интерфейс не грузится, то грузится, но в какие-то моменты выпадает… Естественно, первая реакция саппорта на сообщения о проблемах — а давайте включим ведение подробных логов! Сразу после этого база убивается вообще до невосстановимого состояния. Единственный вариант — полностью восстановить базу и СУБД из бэкапа. Если он сделан до того, как СУБД покоцала базу… Самое смешное, что, кажется, на СХД даже было настроено автоувеличение объема тома по мере необходимости, но почему-то не сработало.rkosolapov
13.06.2017 12:00Это другое немного. Тут всё-таки в софте бага, а в оригинальной истории мегапофигистское отношение к бизнес-критикал вещам, это даже багой не назовёшь, это просто профнепригодность.
Igor_O
13.06.2017 13:50+2Тут забавное сочетание обстоятельств — проблема возникает из-за невозможности из линукса точно узнать объем свободного места, в сочетании с отсутствием ошибки при обнаружении недостатка места в софте, в сочетании с естественной натасканной реакцией саппорта — если что-то непонятно, включить журналирование всего и передать результат на уровень выше. В результате — журналов все больше, а боевой базы — все меньше. (по какой-то причине, журналы нормально писались и не бились...)
Плюс к этому — отсутствие живых бэкапов.
А исходная первопричина багов в софте — разработчики СУБД не тестировали СУБД в условиях недостатка места. Просто не пришло в голову, что у кого-то может переполниться том с боевой базой.
В описанной в топике истории — наложение трех багов в wetware: первый баг — автор документации забыл поменять в тексте после копипаста логин пароль боевой базы, второй — никто не догадался поменять логин-пароль боевой базы перед запуском в продакшн.
Баг номер три — джун после учебы натаскан вбивать примеры из учебника как есть не включая мозг. А уже потом разбираться, если вдруг что-то не заработает.
faiwer
13.06.2017 13:54А исходная первопричина багов в софте — разработчики СУБД не тестировали СУБД в условиях недостатка места
Что-то самописное?
Igor_O
13.06.2017 14:42Ну как бы авторы интерфейса — из «большой тройки» в своей области. Все это поверх СУБД из «большой тройки» в области СУБД…
Crystal_HMR
13.06.2017 15:59Тут забавное сочетание обстоятельств — проблема возникает из-за невозможности из линукса точно узнать объем свободного места
Видимо то вы просто не умеете его готовить. Заббикс, например, из коробки мне вкинул темплейт: Discovered by
Mounted filesystem discovery, и по всем линуксово-аиксовым серверам показывает графики и алертит, если меньше 20%, 10%, 2% (с разным "приоритетом") свободного места. На рабочей машине скрипт, который смотрит все примаунченые файловые системы, и раз в 5 минут алертит через notify-send если занято более 90%. Короче не вижу "невозможности из линукса точно узнать объем свободного места".
Возможно имеется ввиду, что бд внутри себя создает какой-то виртуальный том, но это изврат, как мне кажется.Igor_O
13.06.2017 16:45А линукс вообще был какой-то ред-хэт… на виртуальной машине. А на чем физически СХД жила — вообще неизвестно было. И когда виртуальной машине на виртуальной СХД выдают виртуальный том… Там вообще много разного интересного может случиться и без участия СУБД…
Как там было на баше в свое время: … старкон2, запущенный в DosBox, под иксами в Дебиане, который запущен в VMWare, которая в WinXP
Куда мне вопрос о неработающем звуке задавать? ...Crystal_HMR
14.06.2017 17:31+1ну не знаю, ребят. У меня блейды с red hat мастер-машинами, на которых kvm'ные редхаты крутят оракл энтерпрайс, и ibm'ные машины, на которых aix'ы крутят оракл энтерпрайс. И везде с hitachi схд выделены диски.
Но я не вижу таких проблем, как вы описываете. Может быть с этим столкнулись люди, которые настраивали всю инфраструктуру, но при развертывании новых бд я тоже не вижу таких проблем. Более того, в реальном времени мониторится как наличие свободного места на дисках (под арклоги, в основном), так и свободное место в tablespaces внутри оракла.
Наверное, вы просто что-то не так сделали… или не дочитали.
Muzzy0
20.06.2017 13:23Со всеми своими извращениями с виртуальными машинами я пока только до одного не докатился: попробовать запустить VMware внутри VMware. Матрёшку сделать :)
khim
20.06.2017 14:42На практике не работает. Вроде всё по Попеку и Голбергу в x86, но… не работает. Кажется сейчас можно запустить VMWare внутри VMWare, а вот уже там — VMWare не запустить. Притом, что у IBM 3-5 уровней работали уже в 70е.
mayorovp
20.06.2017 15:08Соответствие набора инструкций требованиям дает только теоретическую возможность. Инструкции виртуализации же надо еще правильно эмулировать в самой виртуальной машине — а это мало кому интересно.
stalinets
20.06.2017 22:20А если VMware — VirtualBox — VMware — VirtualBox — …?
khim
21.06.2017 01:53+1А какая разница? Как было выше замечено AMD-V или Intel VT-x можно виртуализовать — но, насколько я знаю, ни VMWare, ни VistualBox не заморачиваются. Так что процессор «внутри» оказывается как бы без этих технологий, и, соответственно в VMWare «второго уровня» VMWare уже не запустить.
Если это исправили (а могли — я довольно давно не смотрел), то можно вкладывать хоть 10 уровней (если памяти/скорости процессора хватит), если нет — то только три…
hungry_ewok
13.06.2017 19:41Ну почему изврат, тот же оракл афаик так же поступает — он зажрет всё место на выделенном диске сразу под свою базу уже потом что-то там внутри своей базы распределяет, выделяет место итд, и о состоянии с местом внутри базы ты из самого линукса не узнаешь, по df ты всё время видишь 99%-100%.
Только это ни разу не линукса проблема, это на уровне БД такое веселье…
Kits
14.06.2017 12:13В моей практике были случаи, когда заббикс гасил триггер не потому, что место появилось, а потому, что свободное место на диске становилось отрицательное (на линуксе такое возможно, да), а заббикс хранил значение в unsigned типе, которое приводилось к 2^16-n. Не помню, правда, это во встроенных шаблонах было, или что-то самописное.
Sushkov_AA
16.06.2017 09:46это тоже своего рода баг. Баг в людях и политике «ну ты сделай так что бы работало, а потом поправишь(нет)»
и сразу вспомнился один ну очень бородатый анекдот:
— Расскажите о себе
— Могу копать, ну правда херово, могу не копать, в этом разбираюсь чуть лучше, могу сделать так что бы другой копал — с этим справляюсь на ура!
— Поздравляю с назначением на должность технического директора!
ctacka
13.06.2017 16:07+1Напишите уж пожалуйста, что это за СУБД, это же царь-баг!
Igor_O
13.06.2017 16:54+1Ну как видите, таких СУБД — более одной. Когда эту историю рассказал опытным бойцам с той СУБД (не связанным с нашей той ситуацией), то они только плечами пожали — типа это не неизвестный баг, это известная фича. Надо тщательно и регулярно поддерживать запас свободного места и иметь свежие бэкапы, если вдруг это не помогло.
(если действительно так интересно — пишите в личку)
hungry_ewok
13.06.2017 11:54+12/ухмыляясь
Реальность — она вообще бредовей любой выдумки.
Вот это вот, например: http://kris-reid.livejournal.com/150232.html
Ну и маленький эпизод оттуда:
«вспомнилось: «Сидит Слава Логинов, пишет сельскохозяйственную фантастику. Мучается творчеством. Рядом сидит Женя Лукин. Логинов задумывается, отрываеться от работы и говорит...:
— У меня тут в рассказе есть один тракторист, который постоянно по пьянке трактора в речке топит. Hикак не могу решить, сколько же он их утопил. Два — вроде мало, три — не поверит никто…
— Да — говорит Женя. — Задачка… А на самом деле сколько он их утопил?
Логинов тяжело вздохнул.
— Одиннадцать… „
И обязательно с комментарием lemming_drover ( отсюда ):.»Это апокриф. Я как-то раз спросил Логинова о том трактористе. Так вот, во-первых, не все его трактора утонули, некоторые погибли иной смертью…
Во-вторых, загубленных тракторов было _четырнадцать _!!! «;)
Так что это в жизни может случиться что угодно, а в книгах все должно быть логичным;))“
tankistua
13.06.2017 12:01Еще можно перепутать консоли и удалить постгрес в дебиане через --purge, хорошо что была реплика в стандалоне
Jholinar
13.06.2017 10:24+11Да уж, по возможности бегите из компаний, где у джуниоров есть доступ на удаление продакшн-баз. Это значит, что там все плохо, никто ничего не понимает, а руководить вами будут, по всей видимости, такие же джуниоры, которые в какой-то момент посчитали себя сеньорами-помидорами.
symbix
13.06.2017 10:28Если у джуниоров есть доступ к продакшену, то, на самом деле, два варианта. Либо в компании все очень плохо, либо, наоборот, все очень хорошо — все зарезервировано и автоматизировано так, что ничего страшного не случится.
Jholinar
13.06.2017 10:33+6Ну, тоже мнение. Но, лично я считаю, что любой доступ должен быть жестко лимитирован и разграничен. А, если он необходим, то также жестко аргументирован. Вопрос — зачем джуниору доступ в продакшн? В любой здоровой (от слово здоровье) компании сиди и разрабатывай локально у себя на машине. Потом деплой в тестовую среду. Как только прошли тесты, запрашивай деплой в QA, и далее по цепочке. Никаких доступов в продакшн, кроме лимитированного числа людей ни у кого не должно быть.
zTrue
13.06.2017 10:50+1Вопрос — зачем джуниору доступ в продакшн?
Например, расследовать инциденты с прода или баги, воспроизводящиеся только на проде.
Тогда вполне разумно дать, например, ридонли доступ.Jholinar
13.06.2017 10:56Это, опять же, говорит о совершенно дурной архитектуре распределения прав. Запрашивай базу к себе на локальную машину и расследуй, что там нужно расследовать.
Это помимо того, что сомневаюсь в компетенции джуниоров вообще что-то расследовать на продакшне (хотя джуниор джуниору рознь, конечно). Меня просто дико коробит связь «джуниор-продакшн», при любой аргументации.zTrue
13.06.2017 11:04+1Пример: есть реплика БД, которая используется для отчетов или еще каких-то некритичных процессов, которую нам не жалко даже положить в случае чего. БД размером 100500 мб. Почему бы не дать к ней доступ на чтение для разработчиков (в том числе джуниоров, потому что им тоже надо на чем-то учиться)? Чем лучше выкачивать БД каждый раз локально, особенно если нужно проверять данные несколько раз (до и после какой-то операции)?
zeronice
13.06.2017 12:13+1Некоторые баги воспроизводятся только при реальной нагрузке, эмулятор которой еще никто не писал, а баг ловить надо сейчас. На текущей работе, когда я только устроился несколько лет назад, очень жутко было осматриваться и обживаться на прод-сервере с боевой базой. Но деваться было некуда и спустя время стало понятно, что не от хорошей жизни оно так устроено, а как компромисс между затратами и эффективностью
Jholinar
13.06.2017 12:38Да не вопрос, можно миллиард причин придумать, почему что-то должно делаться на продакшне, о чем разговор-то. Моя позиция — нужно максимально лимитировать доступ к продакшну. Так можно дорассуждаться и до того, что нафик QA и тестовые окружения, ибо на продакшне все удобнее делать и быстрее, чего уж там дамбы гонять туда-сюда.
zeronice
13.06.2017 13:22Я же не голосую за всеобщую работу на проде и без QA. Просто есть ситуации и состояния бизнеса, когда приходится джуна пускать в огород. В моем случае, правда, прочитали 10 лекций, 5 раз напугали и 1 раз предупредили: "нет однозначного понимания — Enter не трогать"
Jholinar
13.06.2017 14:15+1Я вашу позицию услышал, но соверешнно не согласен. В моем понимании, единственное, почему что-то делается непосредственно на продакшне, это лень делать что-то на тестовом сервере. Вот нельзя на продакшне ничего делать, кроме деплоя и все тут — это моя религия. Ладно, останемся при своих мнениях. В конце концов, возможно у нас разное представление размеров продакшна.
Ivan22
19.06.2017 15:32хорошая религия. Жаль жизнь сложнее. Начиная с того что любой проект на началось стадии зачастую вообще существует в единственном виде, без тест/dev версий. И живет так долго, до определенного момента (до первого инцидента часто).
saboteur_kiev
13.06.2017 15:37Указан же джуниор девелопер, а не L3 саппорт / QA / бизнес аналитик
Инциденты непосредственно на продакшене в первый день работы джуниор девелопером никто не расследует.zTrue
13.06.2017 15:42Вопрос был такой:
зачем джуниору доступ в продакшн?
При чем тут первый день? Или во второй день он уже не джуниор?
В компаниях, которых я работал и работаю, так повелось, что баги исправляют разработчики, а не L3 саппорт / QA / бизнес аналитик (если они вообще есть в компании).saboteur_kiev
13.06.2017 15:48+1По статье — человек даже свою рабочую машину еще не настроил, а доступ к продакшену валяется налево направо, причем на продакшене оказывается такая важная информация, что собираются юристов привлекать.
Если данные такие важные — то доступ должен быть соответственным.
Только пришедший джуниор же, еще хорошо если просто разбирается с языком программирования и технологиями, но с разрабатываемым продуктом он не знаком, и инвестигировать проблемы, не зная как работает проект — он не может по определению.zTrue
13.06.2017 15:50+1Со всем согласен, но мой ответ был на конкретное заявление:
Вопрос — зачем джуниору доступ в продакшн? В любой здоровой (от слово здоровье) компании сиди и разрабатывай локально у себя на машине.
И не относится к случаю в статье.
Jholinar
13.06.2017 16:34В некоторых компаниях важность данных определяется исключительно по их утере, к сожалению.
Areso
15.06.2017 16:58Классический пример: пока все работает -топам жаль денег на дополнительный жесткий диск, куда можно складывать бэкапы.
Когда все упало, топы в первую очередь пытаются оторваться на рядовом персонале, который эти самые жесткие диски неоднократно и просил.
symbix
13.06.2017 22:42У netflix-а есть Chaos Monkeys — специально, чтобы все ломалось регулярно, а система выдерживала, если не выдерживает — делают так, чтобы выдерживала.
Чем джуниор не Chaos Monkey? ;)
AlexTheLost
13.06.2017 15:10Если есть доступы на изменение данных это уже плохо. У вас какой то парадокс получается.)
Но даже если предположить что все легко восстановимо, то за чем это? К тому же случайные небольшие изменения можно не заметить, и как вы их потом будите отлавливать и фиксить не понятно, а они будут втихую портить кому-то жизнь ухудшая качестве продукта.
nochnoj
13.06.2017 17:08+3Вы забываете что это не у него был доступ, а у любого кто может почитать доки. У секретарши, например. То есть дела там еще хуже.
jehy
13.06.2017 10:26+14Довольно очевидный вопрос. Джуниор ни в чём не виноват — он по определению не должен иметь доступ к продуктовой базе. Более того, желательно, чтобы у него даже доступа в сеть с продуктовой средой не было. Так что к нему вообще никаких вопросов.
Ответственный за бэкапы — да, облажался. Но это со всеми бывает. Дорогостоящее обучение, да. Выговор, но не более.
А технический директор — просто редкостно некомпетентный идиот, раз он сделал такие выводы. И на своём месте принесёт больше вреда, чем пользы. Так что в расход без сожалений.
Jholinar
13.06.2017 10:37+4Я не силен в юруспруденции США, но мне кажется в тамошнем современном мире этот джуниор, при желании, вообще мог бы подать в суд на эту контору и взыскать с них еще и компенсацию за стресс и моральные издержки в виде потери доверия к профессии и профессиональной области, например.
AsianCat
22.06.2017 12:39Человек ни в чем не виноват, он по инструкции выполнил задачу. А вешать надо того, кто допустил наличие боевых реквизитов в таких инструкциях.
Ma5k
13.06.2017 12:20+2Да вообще все девелоперы максимум должны иметь только доступ для чтения.
В случае если в базу все-таки надо влезть, для девелоперов должны быть специальные учетные записи(breakglass account), пароли к которым генерируются когда этот доступ нужен. Пароль действителен в течении нескольких часов.
Aingis
13.06.2017 14:51+1Ответственный за бэкапы — да, облажался. Но это со всеми бывает. Дорогостоящее обучение, да. Выговор, но не более.
Интересный вопрос, а был ли таковой. А если был, то имел ли необходимые ресурсы для полноценной работы (читай: проверки тех же бэкапов)?
saboteur_kiev
13.06.2017 15:44«Ответственный за бэкапы — да, облажался. Но это со всеми бывает. Дорогостоящее обучение, да. Выговор, но не более.»
То есть бэкапы не работают, а он просто немного облажался?
Отсюда с дивана конечно картина целиком не видна, но просто наличие каких-то там файлов с расширением .bkp, .rar или .rman еще не означает, что это именно бэкапы, и что в них хранится именно то, что нужно для восстановления, так что выговор — это недостаточно.navion
14.06.2017 01:07"Не можешь написать свой SureBackup? Вон из профессии!" или что-то вроде этого?
saboteur_kiev
16.06.2017 11:02Нет, просто кроме того, что настроить бэкапы, необходимо периодически проводить тестовое восстановление из них, чтобы убедиться, что они делаются корректно.
fillpackart
13.06.2017 10:31Самое печальное, что парню теперь будет тяжеловато устроится, хотя по факту он реально не причем.
Jholinar
13.06.2017 10:40+7Да нет, конечно. Любое интервью это возможность. Если он будет рассказывать об этом кейсе как о негативном опыте, который приобрел — это только плюс. Лично я бы точно не умалчивал, будь я на месте этого джуниора. Ибо это еще был бы и маркер, чтобы понять, в какую контору я устраиваюсь — любой профессиональный в области наниматель поймет, что вина 100% лежала на конторе и CTO.
fillpackart
13.06.2017 10:51+1Так он джуниор. Они редко могут выбирать, где работать.
PavelZhigulin
13.06.2017 13:25+3Если не тупой джуниор, то никаких проблем не будет. Вакансий на джуниоров дофига, только туда такой треш приходит на собеседования, что иногда не веришь в реальность. Если джуниор не тупой, ты получаешь годного работника, который будет работать задешёво.
fillpackart
13.06.2017 13:46+2Тут речь о том, что джуниоры не в таком кейсе, чтобы выбирать из кучи работодателей и решать, типа этот неадекватный, к нему не пойду и т.д.
piranuy
13.06.2017 16:47Так из истории вроде складывается впечатление, что он уже и стажировки какие-то проходил. А опыт он и есть опыт, все таки не чисты лист после универа.
saboteur_kiev
13.06.2017 20:02Стажировка могла проходить в нормальной компании, где пароли от продакшена просто так не валяются =)
И вообще, приходите вы в новую компанию — откуда вы знаете, что на srvxp1 находится продакшен? Вам инструкцию же дали. Тут любого уровня специалист мог бы промахнуться.hatari90
14.06.2017 09:14Поэтому вдвойне хорошо, когда под боевую базу и хостнейм «говорящий», и само название базы. Вроде somename-sql-prod/production. Дополнительный шанс того, что человек лишний раз задумается, а стоит ли туда что-то лить.
piranuy
14.06.2017 10:23Нет, это я про то, что он не зеленый новичок с 0 опытом и вдруг на улице с таким фейлом, а имеет и положительные строчки в резюме. Поэтому думаю с поиском новой работы будет легче :)
varnav
14.06.2017 15:05Ну, в США всё довольно формализовано, прежнему руководителю позвонят в 95% случаев, а тот не слишком похвалит нашего джуна.
fireSparrow
13.06.2017 11:46Может, на фоне шумихи вокруг этой истории ему кто-нибудь предложит работу.
plartem
13.06.2017 16:40+2А вы бы предложили работу человеку, о уровне знаний которого вы не имеете ни малейшего понятия и который зафакапил часть, с которой остальные нормально справились?
Да, технический директор виноват, но все же читать внимательно инструкции тоже нужно.
edogs
13.06.2017 18:14+1Самое печальное, что парню теперь будет тяжеловато устроится, хотя по факту он реально не причем.
Тестером пойти, оторвут с руками:)
И на самом деле это самый обычный косяк джуниора — он случайно взял не те данные, да, бывает, поэтому он и джуниор, все его действия даже при вываливании в дев должны проверяться.
Реально накосячили те, кто а) прописал продакшен пароли в инструкцию б) дал продакшен пароли джуниору
Докапываться до джуниора в данном случае это все равно что уборщицу на атомной станции наказывать за расплавившиеся стержни, потому что она вставила свою карточку доступа не в тот терминал.
JekaMas
13.06.2017 10:43+13Я знаю одного первоклассного руководителя над тимлидами, который давным-давно в первые дни своей работы нанес ущерб на десятки тысяч уе. CTO был достаточно умен, чтобы от высшего руководства потребовать «не увольнять новичка, в обучение которого мы только что вложили несколько миллионов».
vctork
13.06.2017 10:47указанные там значения — от базы данных в production (не знаю, почему они задокументированы в инструкции по настройке dev-окружения)
Ну, собсна, а чего они хотели?) Согласен с комментаторами выше, тех.дир. тут больше виноват. Парня жаль, конечно.
relia
13.06.2017 10:54+2Junior не виноват в том, что слишком тщательно подошел к выполнению инструкции, и в результате легкого переусердствования выступил очень крутым бета-тестером систем компании :) Уволили его однозначно дураки и скорее всего от того, что не знали куда выместить злобу на самих себя. Пацан прошел бы хорошую подготовку при восстановлении удаленного и скорее всего стал бы одним из преданных сотрудников компании.
Дураки-с ©Goodkat
13.06.2017 11:15Пацан прошел бы хорошую подготовку при восстановлении удаленного и скорее всего стал бы одним из преданных сотрудников компании.
Какую подготовку пройдёт Software Developer при восстановлении базы данных? Если только моральную :)
Там работа для админов или операторов ЭВМ — заново вбивать все данные.relia
13.06.2017 11:20+1Мы же не знаем что было убито и на какие задачи брали этого пацана. А чувство причастности к важным процессам и с ходу поработать на смежных участках не за жизнь, а насмерть — это прекрасная мотивация и бесценный опыт.
ertaquo
13.06.2017 11:01Тех. директор на то и нужен, чтобы контролировать работу сотрудников тех. отдела. В частности, написание документации, работу бэкапов и обучение джуниоров. Я не говорю, что именно он должен заниматься всем этим, но как минимум контролировать своих же работников.
Goodkat
13.06.2017 11:13-16Разработчика, конечно же, нужно уволить — зачем компании такой невезучий сотрудник, который в первый же день сломал всё? :)
Технического директора увольнять не следует — кому-то же надо всё восстанавливать, да и обучение нового потребует времени и денег, но ущерб с него надо взыскать, весь или частично.
Ответственного за бэкапы наказать в соответствии со степенью ответственности — если это какой-то рядовой сотрудник, то можно премии лишить там, но увольнять-то за что? Увольнять если, то его начальника, который не озаботился проверкой бэкапов.YNechaev
13.06.2017 13:22+10Сотрудник который может сломать всё в первый же день — очень ценный сотрудник. Указывает на потенциальные проблемы.
Кто и зачем будет обучать технического директора? Это c-level должность.
Goodkat
13.06.2017 14:30-3Сотрудник который может сломать всё в первый же день — очень ценный сотрудник. Указывает на потенциальные проблемы.
Там смайлик был, но многие этого не заметили. Боюсь, что следующий комментарий я смогу оставить только через час :)
Это c-level должность.
Люди на c-level-должности изначально знают все бизнес-процессы, системный ландшафт и IT-процессы во всех компаниях или способны мгновенно вступить в должность и ознакомиться со всей структурой компании?
oappot
13.06.2017 11:24+5есть вариант уволить двоих, и директора, и отв. за бэкапы?
varnav
14.06.2017 15:06+1если у них нет бекапов — то нет и ответственного за бекапы
vesper-bot
14.06.2017 17:22Но бэкапы-то у них были, просто нерабочие, как впоследствии оказалось. Значит, ответственный мог быть. Другое дело, если его по факту не было — но тогда опять отвечает техлид.
zarikus
13.06.2017 11:25+3Джуниора перевести на должность бета-тестера, технического директора — на должность джуниора, ответственного за бекапы — дать в пользование новому джуниору на сутки: )
PavelZhigulin
13.06.2017 11:25+7Серьезно? У них credentials от продакшн БД в инструкции? Что курят их безопасники (если они есть там вообще)?
saboteur_kiev
13.06.2017 16:12+1Тут есть апдейт от автора
«EDIT Just to make it even more embarrassing, i just realized that i took the laptop i was issued home with me (i have no idea why i did this at all).»
Безопасников видимо совсем нет, раз уволенный (или недопринятый) джуниор в первый день работы смог вдобавок свободно унести корпоративный ноутбук с работы =)
selivanov_pavel
13.06.2017 20:57+2Тут не особо давно проскакивали посты о том, что злоумышленники насканили инстансов монги с террабайтами продакшн данных, не защищённых паролем, и зашифровали/удалили. Что уж удивляться, что у кого-то пароли от продакшена в инструкции напечатаны.
heartdevil
13.06.2017 11:25+1Ему судиться надо. Народ и правда на его стороне.
lightman
13.06.2017 15:49Вот только денег на это у безработного джуна сразу после универа (наверняка висит студенчесая ссуда) скорее всего нет. Если только всем реддитом ему скидываться.
saboteur_kiev
13.06.2017 15:55+1Я думаю, лучше реддитом скинуться на адвоката, чтобы засудить компанию, которая предоставила нелепую инструкцию а теперь собирается с юристами предъявлять претензии (я в принципе надеюсь, что юристы достаточно вменяемые, чтобы понять что тут не так и на подобное не пойдут)
Я практически уверен, что выиграть подобное дело на стороне джуниор-разработчика будет не проблема, зато огласка такого дела возможно заставит подобных тех.директоров подумать что не везде можно прикрыться подчиненными.
Tsimur_S
13.06.2017 16:11А зачем ему судиться? пока что на него никто в суд не подает, а его права вроде никто и не нарушил.
edogs
13.06.2017 18:18«Покинуть работу и больше не возвращаться» — похоже на увольнение.
Учитывая то, что по факту джун совершил совершенно рядовой косяк, увольнение за это скорее всего оверкилл (хотя хз конечно что у них там в контрактах), поэтому можно судиться за восстановление на работе как минимум.vsb
13.06.2017 21:33В Америке с увольнением не цацкаются, там у компании гораздо больше прав чем, например, в России. Ну понятно, что если негра или бабу уволишь, могут и привлечь, но тут-то дело другое.
edogs
13.06.2017 21:45Не цацкаются в том смысле, что в договоре могут прописать что попало.
Но за необоснованное увольнение вздрючат только так, а тут пахнет как раз этим вариантом.
fukkit
14.06.2017 09:24Если уволишь 5 негробаб подряд, при этом наберешь на их место пять белых мужиков. Иначе — уже лет 10 никого не волнуют твои расовые и половые особенности.
Igor_O
14.06.2017 10:18+2Ну это тоже не просто так. Как раз чуть больше десяти лет назад в новостях пробегало, как два мужика отсудили по паре миллионов у Форда (ЕМНИП) за то, что их дискриминировали по рассово-полово-сексуально-возрастному признаку: они доказали в суде, что их уволили потому, что они были единственными в отделе гетеросексуальными белыми мужчинами от 30 до 40 лет.
fukkit
14.06.2017 10:26доказали в суде
Очень важно, когда есть суд, который может защитить нарушенные права.
piranuy
14.06.2017 10:25Я помню передачу, как женщина отсудила себе обратно работу бармена, когда ее уволили из-за того, что она растолстела и более не привлекательна для клиентов. Все дело в том, захотят ли уволенные судиться или найдут все таки работу по силам.
fukkit
14.06.2017 10:31она растолстела и более не привлекательна для клиентов
Очевидная потеря квалификации же.
Есть некоторое лицемерие в том, чтобы сначала запрещать компаниям указывать реальные требования в должностной инструкции и вакансии (предположим: «стройная, внешне привлекательная по оценке компании молодая женщина»), а потом судами навязывать неэффективного работника, так как формальных оснований в должностной нет.
JGooLaaR
13.06.2017 11:25На мой взгляд виноват тот, кто писал документацию. И тот кто ее принимал. Обоих отшлёпать, джуна зря почикали.
EvilPartisan
13.06.2017 16:45+1А документацию наверняка писал такой же вчерашний джуниор, который лишь по счастливой случайности не завали продакшн. Никто не любит писать документации, а потому скинули эту работу тому кого не жалко.
Kekoc
13.06.2017 11:25+9Да с тестами есть такой опасный нюанс, но всё же оставлять удалёный доступ к прод. бд такое себе ) Наверное это их первый случай, у меня на локалке было подобное где не страшно.
Опишу свой случай. Сам устроился на мою первую практику в универе "кодить" особо было нечего и мне дали отремонтировать камеру дорогущую, и запитать через (стабилизатор я так понял) и подключить к серверу. Показал директору он всё проверил, сказал "красавчик после обеда вместе доделаем".
И знаете что было после обеда ребята? Серверная горела! Матерясь директор повыдёргивал питание и потушили всё дело, благо только сетевой фильтр успел больше всех пострадать (но огонь был, хоть и немного). Директор сказал, что это наша вместе вина, выдал мне 1500р. я пошёл купил новый стабилизатор и потом ещё много с ним дел вместе переделывали и вообще крутой мужик оказался )
Мораль такова, что старший товарищ всегда отвечает. И да, не доверяйте предохранителям иногда они просто не работают и техника уже горит !
xii
13.06.2017 12:31+8В свой первый день работы лаборантом в колледже я взорвал пару кандеев на блоке питания (дёрнул на включеном БП переключатель с 220в на 110в) в момент лекции, реакция руководителя была прекрасна —
А так взрываются кондёры. А еще дым от них вреден для здоровья, потому закачиваем лекцию
Не выговоров, ни доносов, ни прессования со стороны коллег, а только грамотный подзатыльник :)
Igor_O
13.06.2017 17:04+1Предохранители — это да… В середине 90-х… Прихожу как-то зимой на одну из своих работ (эникеил в 5 или 7 конторах помимо «основного» места работы)… Чувствую — запах расплавленного пластика… Начинаю искать источник запаха. Нахожу. Пилот. В пилот включен компьютер, лазерный принтер на котором распечатывают какие-то бумаги (пошла вторая пачка за тот день), два калорифера по 2.2 киловатта… Холодно же! А до розеток тянуть калориферы далеко… Пилот стекал на ковролин расплавленным пластиком. 10-амперный плавкий предохранитель и автомат в распредщите героически держались!
st0ne_c0ld
13.06.2017 11:39Копия прода должна лежать в виде артефакта в jenkins, если уж она так часто снимается для тестирования.
Доступ к подсистемам прода — только через CI/CD. И проблемы бы не существовало.
Бекапы шрёдингера — это классика :-)Eldhenn
13.06.2017 11:45+2Так он не снимал копию прода для тестирования. Он как раз залил на прод данные «артефакта».
MasMaX
14.06.2017 12:05+1Прод в виде артифакта дженкинса? Базу вообще не должна лежать в артифактах, только код.
А если уж и хранить базу то как минимум система Артифактори.
varnav
14.06.2017 15:10+4Доступ к подсистемам прода — только через CI/CD чтоб значит не случайно вручную сломать один сервер, а автоматизированно и сразу все!
EvilsInterrupt
13.06.2017 11:48+3Джун выступил лишь «лакмусовой бумажкой», что в компании не все тех.процессы настроены должным образом. Нести ответственность должен тот, кто настраивает тех.процессы в компании и это далеко не джуниор.
Зона ответственности по настройке тех.процессов лежит на тех.дире! Не хочет этим заниматься, то пусть уступит более компетентному товарищу. Это он был поинтересоваться у подчиненных:
* настроен ли процесс бэкапа?
* Как часто делается бэкап?
* Проверена ли процедура восстановления?
* Сможет ли кто-то еще восстановить из бэкапа не считая его создавшего?
* Описана ли процедура по созданию\восстановлению из бэкапа?
Это минимальный набор того, что он должен был взять под свой контроль.
Если кого и увольнять в этой истории, то только тех.дира!
dimon_durak
13.06.2017 11:50-2На мой взгляд, в вариантах ответа на вопрос кого увольнять в такой ситуации не хватает эйчаров или кто там занимается приёмом на работу.
Это ж идеальный тестировщик! С первого раза, в первый же день найти даже не уязвимость, а дырищу в разработке! Талант, не побоюсь этого слова. Пропустить такое дарование надо постараться...
shurup
13.06.2017 11:52+1Автор этой истории, кстати, пишет, что связаться с HR'ом ему даже не дали: «I haven't heard from HR, or anything and i am panicking to high heavens». Т.е. CTO психанул и решил всё, минуя этого самого HR.
JohnLivingston
13.06.2017 13:07+1Мне лично ещё сильно не хватает возможности отметить к увольнению и СТО и ответственного за бэкапы, ибо виноваты они оба одновременно. СТО — за то, что допустил данные с продакшена в тестовом примере, а бэкапер — за то, что бэкапы не работали.
selivanov_pavel
13.06.2017 21:00+2Скорее всего, ответственного за бекапы уволить не получится, потому что его нет.
aglgl
13.06.2017 12:12Уморили, я думал на прошлой моей работе были абсолютно ленивые люди, но как оказалось это были ещё цветочки. Мне вообще хотелось бы посмотреть на че? лове? ка который додумался реальные доступы вписать.
Написали скрипт судного дня и дали его джуниору.staticlab
13.06.2017 12:21+1Этот скрипт рано или поздно всё равно кто-нибудь запустил бы "как есть". То, что в нём прописаны креденшиалы прода — одновременно и баг, и дыра в безопасности.
DarthVictor
13.06.2017 12:23+13Отличный вариант логической бомбы, я вполне допуcкаю, что инструкцию написал обиженный админ.
Wolfas
13.06.2017 14:11Чаще бывает все ироничнее. К примеру из моего опыта. Небрежность аутсорсинга, и невнимательность принимающих.
Приняли инструкцию по настройке прод и дев сред. Но потом возникла потребность в поднятии тестовой среды. Поднимали ее на основе дев среды. Но там была опечатка. И данные (при миграции) лились в прод. Благо это были всего на всего справочники.
erwins22
13.06.2017 12:23+1Пришел человек в контору и сразу доступ к продакшену? (у него не должно быть прав на нее)
что за бред
Бакапы должны делаться ежедневно и ежедневно восстанавливаться в копию рабочей базы, так называемая копия вчерашнего дня.
сложно судить возможно ли у них это.
Wolfas
13.06.2017 13:06Джуна то за что?
Человек наверняка делал то о чем его просили.
Очень много вопросов возникает…
1. Почему у джуна доступы к боевой среде. Ее обычно берегут оберегают всеми способами.
2. То что в инструкции не ДЕВ, не ново… Такое иногда бывает. Камень нужно кинуть в того кто ставил задачу, а не в исполнителя. От куда ему знать было.
shgurbanov
13.06.2017 13:06+41.Какого черта данные подключения к продакшн базе были в инструкции?
Они должны храниться зашифрованноми и доступ к ним сугубо согласно политике ИБ компании.
2.Какого черта с IP адреса джуниора вообще имеется доступ к продакшн базе?
Прод база даже пинговаться не должна.
3.Почему не изолирована команда DROP DATABASE?
Nicholas_J
13.06.2017 13:06А вообще делать зеркало живой базы — задача никак не Разраба, хоть где, это задача админа. Так как ответственность за такие косяки будет на нём и только на нём.
Ну а в данной ситуации вина, бэкапера, так как бекапов не было и они не восстанавливаются. Делать разностные бэкапы никто не мешает, хоть каждый час… Правда, если место позволяет. Другое дело. Что человека уволили за то, что он обнаружил(обнажил) дыру в безопастности, и протестировал систему бэкапов на вшивость. QA — минимум, плюс премия за квартал досрочно в двукратном размере.
Директора лишить 30% гонорара, и обязать работать в ручном режиме для восстановления, а в помощь ему ответственных за бэкапов.
Зачем кого-то увольнять… Да потеря данных, да важная информация. Но урок полезный раз. Убытки, два… Зато системы NAS и тому подобное для всех вариниантов бэкапов будут. И ещё 100500 раз переспросят относительно того, что сделались у нас резервные?
gds1
13.06.2017 13:19-2автор жжёт!!!
Wolfas
13.06.2017 14:21А что не так в статье? Момент достаточно распространенный. Когда прикрываясь маленьким человеком руководство сохраняет за собой места. В таких командах все ка правило на иголках. От части, надеюсь что автор статьи найдет себе хорошую команду. В которой ему не просто дадут бумажку и скажут делай. А как минимум уточнят все ли он понял… Так как в первый же день. Не представляя себе архитектуры…
djaa
13.06.2017 13:29+16Парню повезло, я считаю. Он избежал карьеры в коллективе мудаков и сохранил свой ум от практик принятых в этом коллективе.
dikkini
13.06.2017 13:37-1- Доступ к production среде без VPN'a или общий доступ и к dev среде и к production? Раздели это!
- Учетная запись с доступом для к БД у разработчика? И не важно в инструкции она или где. Не должно быть доступа к БД вообще. Автоматизируй это!
Cyberneticist
13.06.2017 13:39-1Уволить нужно:
— CTO (составил потенциально опасную / недостаточно понятную документацию )
— team lead (не добавил «защиту» от дурака, которая не позволила бы выполнить потенциально опасные процедуры на production instance, не провел достаточный инструктаж / не проконтролировал как новичок осуществляет local deployment приложения)
— DevOps (не обеспечил своевременное резервирование системы, оставил возможность коннекта к продакшн базе с машины любого дева)fillpackart
13.06.2017 13:48+2Может, никого не нужно увольнять, но сделать выводы и исправить уязвимость? Или нет?
Cyberneticist
13.06.2017 13:52ну как минимум выговор / штраф и чтобы сделали выводы
ну а вообще согласно здравому смыслу админ который допустил доступ к прод базе откуда угодно своей должности не заслуживает
это как пожарник который с попкорном наблюдает за горящим домом и ничего не делает
или переговорщик с террористами который говорит «убивайте хоть всех мне все равно»hatari90
13.06.2017 14:02Тут косяк безопасника, если такой там имеется, конечно. А сетевик, ограничивающий доступ, в вашем примере ассоциируется скорее с пожарным, который не приехал, потому что его никто не вызвал.
Wolfas
13.06.2017 14:13Организации бывают разные. И у них есть определенный образ жизни. Когда человека могут просто принести в жертву корпоративным принципам
zsergeant
13.06.2017 14:33+1Стартапы такие стартапы. Количество классических проколов (я бы сказал канонических примеров как делать не надо) просто зашкаливает. Еще удивительно, что этот
дятел, рушащий цивилизациюджуниор-убийца целого бизнеса так долго не мог до них долететь… Аж с 2013 года.
acidcherry
13.06.2017 15:07+3вспомнилось, из личного опыта
когда работала специалистом по информ. сопровождению одной справочно-правовой системы для бухов/кадровиков/юристов, в обязанности входило обновлять базы данных у пользователей. и где-то на 4 день самостоятельной работы в одной из контор грохнулась винда примерно после моего ухода, в течение часа-двух. приходящий админ убедил главбуха, что именно я и виновата. наши технари связались, объяснили ей, что это никак не могло повлиять. но вот именно меня они больше видеть не захотели, всё думали, я им винду сломала. хорошо на нашей стороне все понимали, что я ни при чем, и никаких санкций не последовало. им другого сотрудника на сопровождение направили. но вообще, было неприятно, когда приходишь, а тебе с порога — девушка, идите отсюда, мы после вашего прошлого визита месяц информацию восстанавливали. и не докажешь буху ничего. и к теме бэкапов — 1с база хранилась только там, на ноуте главбуха.
Apatic
13.06.2017 19:57+2Классика. Начинал карьеру во франче 1С, студентом еще.
Еще 7.7 была жива и относительно популярна. Пришел, написал какую-то обработку, все работает.
Только вышел из кабинета, выбегает бухгалтер и грозно просит назад, потому что «все в номенклатуре сломалось».
Оказалось, что она просто случайно нажала кнопку «Отключить иерархический просмотр» (или как там) и, видимо, сделала это впервые в жизни, поэтому сильно испугалась, увидев, что папочек больше нет. В итоге, показал как вернуть все обратно, но потом через другого специалиста попросили, чтоб я туда больше не приезжал, хотя обработка работала нормально.
vasiliysenin
15.06.2017 22:10Бухгалтера они такие :)
Они же бухгалтерский учёт учили 5 лет. Целых 5 лет Карл!!!
Drac013
15.06.2017 22:33+2Я хоть и являюсь классовым врагом бухгалтеров, но все же ваш сарказм не уместен. Действительно квалифицированный и хороший бухгалтер на важной должности в крупной компании — это постоянное изучение нового законодательства, судебных и административных практик. Как в ИТ работники отличаются от эникейщиков до топовых программистов и администраторов, так и в бухгалтерии есть операторы по вводу первички и главбухи организовывающие учетную политику холдинга с десятками тысячами сотрудников.
khim
16.06.2017 17:00Понимаете какая история. Эффект Даннинга — Крюгера в случае с бухгалтерами почему-то выражен особенно остро. То есть вот те самые «квалифицированные и хорошие бухгалтера на важной должности в крупной компании» никогда не пытаются строить из себя невесть что. Они хорошо знают цену и себе и тем, кто к ним приходит компьютеры чинить.
А больше всего гонору — это как раз у тех, которые 5 лет отсидели и всё благополучно забыли, работают, фактически, операторами ЭВМ, понятия не имеют ни о компьютерах, ни о, собственно, бухгалетрии (всё что они умеют — вводить данные в формы, разработанные кем-то другим), но при этом «дуют щёки» невероятно…Drac013
16.06.2017 17:22Честно говоря, оценить остроту проявления этого в эффекта в разных профессиях лично мне видится проблематично. Это все же общая проблема некомпетентных людей.
vasiliysenin
16.06.2017 20:07А сарказма и нет. Я имел в виду что объём знаний по теме стандартного бухгалтерского учёта помещается в одну небольшую книжку.
Я видел в книжном магазине учебник по бухучёту под названием «Бухгалтерский учёт за 7 дней», за 10 дней и за 14 дней. Сам я проходил курсы 3 месяца по два занятия в неделю по 2 часа, хотя можно было просто прочитать учебник за несколько дней, причём в учебнике конечно всё подробнее написано.Drac013
16.06.2017 23:09А вот и замечательная демонстрация эффекта Даннинга — Крюгера :)
Я видел книгу «C++ за 21 день». Это о чем-то должно говорить? Чтобы быть бухгалтером уровня главбуха большого холдинга надо знать очень хорошо: ПБУ, НК, частично ГК, частично ТК, хорошо МСФО, следить за многими регулирующими ФЗ, письмами минфина, наголовой и кучей всего остального. И все это с риском уголовной ответственности при косяках с налогами.
MrShoor
17.06.2017 01:26+1Напомнили про комикс «C++ за 21 день».
Вот он:
vasiliysenin
17.06.2017 03:39+2Работал я в крупной компании, бухгалтера с подразделений приносили балансы, я их в экселе суммировал, а у главбуха даже компьютера не было, потому что главбух в крупной компании это больше руководящая должность, а не исполнительская (по произведению подсчётов). Я же писал про стандартный бухгалтерский учёт, который легко освоить на начальном уровне за несколько дней, а не 5 лет.
Drac013
17.06.2017 15:04Наверное, я плохо владею терминологией, но что такое «стандартный бухгалтерский учет»? Это там же, где «стандартное администрирование» и «стандартное программирование»?
Scarred
19.06.2017 04:59«стандартный бухгалтерский учет» — это типовые "приход", "расход", которые разносятся типовыми проводками описанными в куче учебников. В принципе многим хватает на начальном этапе или при небольшом обороте...
Ну а потом либо компания растет и выходит за пределы «стандартного бухгалтерского учета» и начинаются "налоговые и бухгалтерские оптимизации" с использованием различных особенностей законодательства и учета, либо компания закрывается...
Drac013
19.06.2017 12:24-1А, ну, то есть, это как установил винду и подключил принтер — уже администратор, написал макрос в Excel — уже программист.
И такие бухгалтера, и такие администраторы с программистами где-то востребованы. Но какое они имеют отношение к настоящим высококвалифицированным специалистам?Scarred
19.06.2017 12:52-1Ну теоретически они могут дорасти до высококлассных специалистов… :)
но это маловероятно, т.к. в большинстве случае такие "спецы" не могут учится… любой нестандартный вопрос вводит их в ступор или словесное недержание без смысла… Но понтов у таких бухгалтеров выше крыши…Drac013
19.06.2017 14:50Я тут пытаюсь вам прозрачно намекнуть, что проблема некомпетенции и эффект Даннинга — Крюгера, это общая проблема, присущая всем профессиям, но вы все равно возвращаетесь к ненавистным вам бухгалтерам, так и не осознав, что своим первых постом вы умалили в том числе и тех специалистов, до уровня которых в своей стезе и вам, и мне, как до Китая пешком. Жаль.
acidcherry
16.06.2017 02:34имею экономическое образование за плечами (ну так вышло, в ИТ ушла позже). у меня бухучет был один семестр, и мало какой предмет вызывал у меня такое отчаяние от того, что ну никак не могу понять. притом, что с точки зрения бухгалтерии, там были достаточно базовые вещи, и примитивные задачки, которые мы решали на бумаге ("самолетики", план счетов до сих пор с ужасом вспоминаю:) ). и, пожалуй, я вполне могу представить, чему там можно учиться 5 лет, чтобы вникнуть во все нюансы и тонкости. ну и присоединяюсь к предыдущему ответившему на ваш комментарий. законодательства — море, оно запутанное, противоречащее друг другу и постоянно меняющееся. причем незнание его может быть чревато оочень серьезными последствиями.
да, к слову, первую в своей жизни "единицу" я получила на 4 курсе, когда на бухучете решала на доске задачку. у меня появилась иллюзия, что я все поняла :-D но по факту, после курса осталось ощущение, что ни черта я въехала в бухучет, как будто что-то ключевое-основополагающее не вкурила, и все.vasiliysenin
16.06.2017 20:24С тем что законодательства море, согласен. Раньше занимался установкой системы «Лига-закон», база на несколько гигабайт, более 400 000 документов. Такой объём текста невозможно даже прочитать за всю жизнь, а тем более за 5 лет. А если учесть что законодательство ещё и меняется постоянно, то то что было выучено в институте всё равно устареет уже во время учёбы. А если учесть что в России с 2018 года вводится МФСО, то…
Iqorek
13.06.2017 15:10+3Я просил и умолял позволить мне как-то помочь реабилитироваться
Его просьбы остаться можно объяснить только его неопытностью. Оттуда нужно бежать роняя тапки, ничему хорошему там не научат. Допустим с бекапами многие грешат, для этого нужно сделать какие то усилия, потратить время, как минимум до первой потери данных, руки могут не дойти ;) Но как можно в инструкции напечатать пароль от production? Это каким нужно быть клоуном, рыжим или белым?zsergeant
13.06.2017 15:40Вероятно, пароля там и не было. Он мог запрашиваться в скрипте и джуниор их честно ввел. Но указывать в учебном скрипте данные боевого сервера Плюс наличие прав у него же на удаление целой БД вряд ли сильно лучше.
Iqorek
13.06.2017 16:05На листике было все
я должен был скопировать URL/пароль/юзера базы данных… я по какой-то причине использовал значения из самого документа.
AllanStark
13.06.2017 15:26+2Когда-то очень давно во время командировки на подшефное предприятие (завод) попросили помочь с восстановлением DBF базы 1С 7.7 с рухнувшего сервера.
Было подозрение на то, что начал сыпаться винт (в дальнейшем подтвердилось по индивидуальному снятию SMART-а в обход RAID контроллера).
Так вот, времени было мало, дело было вечером, перед поездом. Несмотря на развал RAID-а БД удалось успешно скопировать. Посоветовал местным админам прогнать тестирование БД средствами самой 1С без исправления (не ТИС).
Прогнали, все ок, засунули БД в другой сервер, взлетели…
А через трое суток прилетает гневный звонок главбуха с того завода — «Зачем вы нам своими советами базу 1С сломали?»
Начали разбираться. Оказалось, что за последние 5 лет местный франч 1С эту БД каждый год усекал, но без компенсации движений по регистрам и бухсчетам. Причем контрольное тестирование БД не проводилось НИ РАЗУ. Хотя в договоре было прописано, что подрядчик несет ответственность за целостность данных в результате проведения обновлений, доработок и прочих манипуляций.
Даже при «чистом» тестировании 7-я 1С-ка в обязательном порядке все же пересчитывает промежуточные итоги. С закономерным результатом.
Ну а заводские бухи три дня стучали данными в базу, пока не заметили что что-то там по остаткам не сходится…
Ругань. Мат. Написание объяснительных. Вызов стороннего известного франча 1С для экспертной оценки.
Наказание невиновных и награждение непричастных. Занавес.
unclechu
13.06.2017 15:33- Слишком много ждут от человеческих обезъян, можно сказать что совершение ошибок заложены в них by design;
- Ответ на вопрос «кто действительно виноват» был дан тут:
указанные там значения — от базы данных в production (не знаю, почему они задокументированы в инструкции по настройке dev-окружения)
- Увольнять никого не надо, это бы противоречило пт. 1, а тех. директору надо меньше рефлексировать, глубже изучать истоки проблем и наконец осознать склонность людей к совершению ошибок, пусть книжек там почитает о работе мозга и когнитивных искажениях.
UncleAndy
13.06.2017 15:34-1На мой взгляд, у ЛЮБОГО нового разработчика в компании в принципе не должно быть доступа на продакшен. Ни в базу ни в код. Соответственно, ошибка тут в построении IT-инфраструктуры компании, за которую несет ответственность технический директор.
AllanStark
13.06.2017 15:43+1А, еще был старый случай.
Стояла очень кучерявая учетная система, написанная на дельфях и в качестве СУБД пользующая конечно же Firebird.
Система работала почти круглосуточно в режиме онлайн, крутилось куча разных скриптов-роботов для автоматизации ряда операций.
Из-за этого, а также из-за криворукости не то разработчиков системы, не то Firebird-а (подозреваю что там был коллективный «путь к успеху» в этом вопросе), резервное копирование выполнялось каждую ночь скриптом, писанным в системе Automate. Скрипт солидный, в несколько страниц мелкого текста. Рубились/запускались роботы, стопалась/стартовала СУБД и т.д. Automate там был вынужденной мерой, т.к. в целях автоматизации этих процессов требовалось ловить окна и жать в них кнопки.
А каждые выходные из-за дури со сбором мусора в FB 1.5 Classic требовалось сделать т.наз. бекап-роллбек. Иначе база всего за неделю выростала до гигантских размеров (в 2-3 раза от свежеразвернутого с бекапа номинала) и все начинало тормозить. Литература по FB (единственная имеющаяся на русском книжка Хелен Бори) и их офсайт были вычитаны полностью, всякие хитрости типа бекапа со свипом по БД переведенной в однопользовательский режим и попытка подстройки мусорщика — результатов упорно не давали.
Короче полная дичь.
Так вот, в один прекрасный день что-то в мозгах Automate-а помутилось и он пропустил с ошибками ряд команд своего скрипта и развернул из бекапа не последнюю версию, а на сутки ранее. А свежий бекап просто грохнул.
В итоге сутки работы довольно немаленького дистрибьюторского предприятия были потеряны полностью.
По факту были сделаны оргвыводы.
Automate был быстро, решительно выкинут на мороз. А все телодвижения были переписаны чуть более чем полностью на новомодном тогда powershell 2.0. С кучей проверок на каждом этапе, промежуточных резервных копий, логов и прочих уровней безопасности.Areso
15.06.2017 17:13> Automate там был вынужденной мерой, т.к. в целях автоматизации этих процессов требовалось ловить окна и жать в них кнопки.
> были переписаны чуть более чем полностью на новомодном тогда powershell 2.0.
Позволю себе глупый вопрос: как?
pabloesc
13.06.2017 16:00А у меня тоже был случай с инструкцией и PROD, только там в UPDATE были данные живых клиентов, и получились дубли. Рефлекторный копипаст, как правило, может закончиться по разному.
Мне объяснили момент, что в инструкциях не должно быть живых данных ну и необидно поржали.
А по ситуации могло быть такое, что основной показатель искупления FUCKUP-ов — расстрел виновных, директор доложил наверх, что виновные расстреляны и его не ругали)))
В любом случае, парню сплошной профит, будет знать, где лежат эти грабли.
rrrrex
13.06.2017 17:08+3
Ну а зачем директору оправдываться за работу через одно место. Видать таких сотрудников нанимают, которым пофиг, есть бэкапы или нет их, и это проявляется во всем.
spopovru
13.06.2017 17:16+10Будучи разработчиком, причём уже отнюдь не джуном, дёрнул функцию внутренней библиотеки для работы с файлохранилищем, передав ей NULL в качестве аргумента (а должен был, помнится, id файла). В силу «особенностей» реализации библиотеки она восприняла NULL как потребность удалить корень файлопомойки.
Результат — терабайт с лишним удалённой бизнес-информации в 6 утра в субботу, и трёхдневное колдовство с бэкапами.
И огромное спасибо коллегам и руководству, которые с пониманием отнеслись к произошедшему (функция так себя не должна была вести, её в итоге поправили) и всё обошлось без особых последствий.
Так что я этого разработчика очень даже понимаю, да…khanid
13.06.2017 19:26+1Вот это — всем багам баг.
spopovru
13.06.2017 19:47Это да. С одной стороны, не стоило доверять библиотеке, которую пилил неизвестно кто и неизвестно когда, но с другой — сложно было ожидать такое поведение.
Правда, на моей стороне тоже была ошибка, из-за которой NULL и получил — неверно сделал JOIN в запросе… Да. Sad, but true…Semy
15.06.2017 17:47не стоило доверять библиотеке, которую пилил неизвестно кто и неизвестно когда
Точно. В любой непонятной ситуации пиши свою библиотеку!
Tufed
14.06.2017 11:27Вставлю и свои 5 копеек. Состою в тестерах в проекте LIF ММО, ждали тестов функции судного часа, все хорошо, перед началом плановая перезагрузка всех серверов, и загрузившись обнаруживаем что все монументы (которые ответственны за область территории, объявленной в собственность) — исчезли! Все постройки на всех серверах стали ничейными и все объекты тоже. При разборе выяснили, что один из глав кланов не делал делегирование на заместителей, а сделал таким же полноправным главой еще одного человека. В итоге функция обрабатывающая эти данные не знала что с этим делать, и как следствие удалила из базы все монументы (через которые и происходит управление). Вот так недочет в одной функции порушил всю базу. Потом бэкапы, восстановление,… эх.
basili4
13.06.2017 17:35Не так давно правил код класса там в коде было
rm -rf $path\*заменил на exec('rm -rf $path*'). Удалился массив данных которые никто не бекапил.
nivorbud
13.06.2017 18:10+2Очень исполнительный джуниор — всё сделал строго по инструкции: что там написано, то и ввёл. Пусть привлекают юристов… флаг им в руки. Юристы и суды работают с документами, документы любят, там эта инструкция будет весьма кстати.
d_pa
13.06.2017 18:10У меня такие факапы случались с MS SQL Server:
до того, как писать апдейты в стиле
update t set f = value --select t.* from mytable t where 1 = 1 and --всякие фильтры
я писал их в стиле
update mytable set f = value --select t.* from mytable t where 1 = 1 and --всякие фильтры
и как-то не закомментил вторую строку и запустил на выполнение.
Т.е. всю таблицу проапдейтил (вдруг кто не догадался).vlivyur
15.06.2017 14:17А я пишу наоборот: сначала select и закомменченный update, и ещё строку пустую всегда добавляю после команды. А то когда выделяешь с шифтом несколько строк, начиная с 'update...' будет выделено по where 1=1, но не последний and, а рука уже занесена над F5…
ArsenAbakarov
13.06.2017 18:27Парень то не виноват… просто осадок неприятный, главное не сдавайся, коллега
dadyjo
13.06.2017 18:46-4Я тут что то нажал и все пропало
Tairesh
13.06.2017 21:09+4До сих пор вспоминаю как вместо rm ./cache/ -rf ввёл что-то вроде rm ./ и отправил в девнул все гигабайты фотографий с крупного сайта. Вернее отправил то весь вебрут, но скрипты и стили тут же восстановил из репозитория. Потом стал искать бэкапы. Нашёл бэкапы бд, кода и ещё кучу всего. А вот гигабайты фотографий то нигде не бэкапились. Но никто не узнал, что это был я . Даже не знаю почему веб-студия та вскоре обанкротилась и так и не выплатила работникам последнюю зарплату.
CrazyNiger
14.06.2017 08:11Именно из-за такого, при разработке системы где будет много загружаемых файлов, теперь всегда начинаю с продумывания организации бэкапа для этих файлов. Что бы хотя бы ежесуточный дамп диска был у хостера.
hdfan2
14.06.2017 08:21У нас коллега на своём компе как-то раз хотел удалить рекурсивно временные файлы с именем ~ и ввёл rm -rf ~. Когда его SSD как-то странно призадумался, до него наконец дошло, но многое успело удалиться.
adrianolamo
13.06.2017 21:51Джуну премию нужно было выдать. Если б не он неизвестно когда бы еще произошел сбой требующий восстановления, а он бы был рано или поздно. А так возник повод пересмотреть не только бекапы а и все процессы в компании начиная с инструкции по дев окружению… Жаль только что СТО в компании тугой и не понимает этого.
degs
13.06.2017 21:56+1Минимум дважды за свою жизнь видел похожие случаи, оба раза были сделаны выводы об организации процесса но никого не уволили. Кстати, по крайней мере в одном из них тот самый джуниор через пару лет стал вполне адекватным и ценным сотрудником.
stagnantice
13.06.2017 22:10-2Директор наверно и писал эту инструкцию, раз так отреагировал, джиниор молодец, сразу сломал прод, карьера будущего хакера в гору пошла. Его тестером надо брать!
MeGaPk
13.06.2017 22:10+3У меня был забавный кейс на работе.
В продакшене вбилchown -R www-data /var /www
Первым упал Postgres :). Благо была копия виртуалки и по ней восстановил права и все работало как обычно. Но тогда кирпичей отложил знатно. И да, меня за это не уволили и даже не гнали.
MetaDone
14.06.2017 13:45веселее сделать так
sudo chmod 0777 -R /
или же опечататься в /etc/sudoers как я сделал относительно недавно и после восстановления, слава Ктулху, пустого сервера узнал о существовании visudo
Roquie
14.06.2017 00:56Помню, я работал с данными таблицы на разных вкладках в Valentina Studio и каким-то чудом я снес основную таблицу на продакшене ближе к концу рабочего дня. От нее зависела работа бизнеса. Благо, у меня осталась выборка из таблицы в неизменном виде на отдельной вкладке, откуда это удалось «достать». Доставал записи построчно (export row as csv), т.к. на тот момент в программе нельзя было сделать экспорт целиком. Вот так, за каких-то 20-30 минут, я руками, с тачпада, откопировал >1500 записей без единой запинки сделав построчный дамп. Хорошо хоть 1.5к, а не пару сотен тысяч. Все обошлось, никто ничего практически не заметил, только посмеялись, когда сам попозже рассказал :)
Тот драйв заставил делать меня бэкапы баз и регулярно, и перед каждым чихом, и проверять их работоспособность. Правда делать бэкапы личных данных я научился, когдапроетерял, т.е. повредились важные документы на съемном носителе (1 файл защищенный AES-ом). Больше про бэкапы, во всех аспектах, я не забывал.
molecularmanvlz
14.06.2017 04:57+2Очень похожая ситуация на нашу. Для хранения кода мы используем концепцию «clean trunk» (это когда все коммитят в мастер и нет брэнчей). Так вот пришел новый парень, сделал пулл, че-то там покодил пару часов и пушнул назад с ключом --force. Когда мы ему предъявили что он потер код он показал страницу из нашей «онбоардинг» документации где было черным по белому написана инструкция что надо делать именно так. Разумеется все претензии были сняты и доки переписаны.
ReklatsMasters
14.06.2017 09:35Из reflog всё парой команд достаёт я. Разумеется, если историю не потёрли.
myrslok
16.06.2017 18:11+1Можно чуть подробнее про clean trunk, в чем его прелесть?
molecularmanvlz
22.06.2017 19:55Все не так плохо — есть один чистый мастер в котором всегда есть рабочий код, который в любой момент оттестирован и готов к релизу. Каждый разраб полностью ответственнен за его коммиты и если что-то сломано — он тут же должен это исправить. Я не топлю за эту концепцию, но у нас вот так.
ashv24
14.06.2017 04:58У меня начальник с опытом с 90-х выставил базу 1С наружу (ну чебы бухгалтеры ходили из дома работать) и вот случилось, базу и всю машину зашифровали (было еще до вона край). Вот такие вот спецы бывають… Но его пронесло… отделался испугом (нашли где-то бэкап который когда то кому то оправляли)
Wolfas
14.06.2017 11:131C это вообще отдельная тема) Я когда фрилансил. Бекапы от греха подальше держал у себя на съемных дисках.
Ибо от криптухи мало кто защищен. Особенно если письмо с вложением приходит бухгалтерам которым за 60…
Arbane
14.06.2017 04:58Считаю, что никого
Скорее всего сама команда разработки, где, наверное не один человек, виновата. А еще точнее — начальник отдела, человек ответственный за инструкции, человек ответственный за архитектуру, ну и за бекапы. Косячнули все. У нас был похожий случай, потерялся правда всего день работы, зато рестор теперь тщательно тестируется для каждого бекапа автоматом.
А парень мог быть внимательнее, но не был, бывает. Насколько он виноват, это надо знать всю историю не в пересказе, а по секундам. Epic fail команды это не отменяет.
r-moiseev
14.06.2017 04:58Два вопроса.
1. Почему доступ к продакшну валяется в почти свободно распространяемых документах?
2. Почему в базу продакшна можно просто взять и подключится из окружения разработчика?
matraskin
14.06.2017 04:58-3Джун — траблмэйкер. Таких не очень любят в америках и стараются от них избавляться. Уволили чтобы беды не притягивал в дальнейшем.
Wolfas
14.06.2017 07:51Вопрос. Если не будет джунов. То от куда взять через 30 лет новых спецов?
Ведь джун, фактически ученик. Который работает почти задаром. Но компания его взращивает так, как им нужно. Если просто набирать людей с опытом… Правильно ли это?matraskin
15.06.2017 16:46-1Я не всех джунов имел в виду, а конкретно этого. Просто приходилось очень часто встречаться с новичками, да и не только новичками, с раздутым самомнением, которые боятся задать лишний вопрос, лишь бы не оказаться в дураках. И в итоге с умным видом попадают еще в более дурацкие положения. Может быть этот случай будет ему наукой и на следующей работе он уже будет прежде чем что-то сделать включать мозг и задавать вопросы, а не тупо по инструкции выполнять.
mayorovp
15.06.2017 19:37Мысль правильная (про то, что в следующий раз спрашивать будет) — но выводы из нее сделаны какие-то странные...
Wolfas
14.06.2017 07:47Ребят есть хорошая поговорка:
Рыба гниет с головы.
Обычно когда приходит новый человек, совершаются некоторые действия:
1) Согласование доступов СБ.(В этот момент руководитель высылает описание архитектуры всех сред)
Если СБ не выдавало доступов, то на мой Взгляд Виновата служба безопасности.
Если Руководитель не выслал описание сред, то вина руководителя
Если же человеку все дали, но он решил «показать себя», то что же… Вина однозначно джуна.
2) Вводная — Обычно человека знакомят что используется в компании. И карта проекта. Какие базы где лежат и как к ним стучаться.
Если вводной нету, то опять же вина руководителя. Ну или Тим лида.
Если же Джун ее пропустил. То его.
Эти два пункта статье не описаны. И на мой взгляд это какой то подводный камень.
moooV
14.06.2017 08:35+2У меня была похожая история 4 года назад — год назад на гиктаймсе писал комментарий про это.
Скопирую сюда, т.к. по ссылкам обычно ходить лень:
Тянет на отдельный пост, но у меня была похожая история три года назад — я убил базу и многомиллионный бизнес почти накрылся. Причем считаю, что идиоты они, а не я — при организации компании как 10+ менеджеров и один программист/админ этого следовало ожидать рано или поздно.
В общем, есть некая баннерная сеть (сейчас проверил — еще жива), а у нее ушел единственный программист — у них полный ахтунг, попросили через знакомых меня помочь (само собой, без договора и всего такого). Начал разбираться — не документировано вообще ни чего, даны только исходники системыи логин-пасс от дедика. Соответственно, моей задачей было именно разобраться и задокументировать что и как для новых программистов.
Поковырял исходники, полез смотреть в бд. Работал ночью, был упорот, перепутал две одинаковые вкладки phpmyadmin и сделал из продакшен-базы тестовую базу. Жопу обнаружил только когда запустил на продакшене mysqldump и понял, что он как-то быстро завершился.
Побежал за бекапами — а их нет. Пишу в скайп старому программисту с вопросом «Куда делаются бекапы?», он ответил, что вообще не парился с этим, они не предусмотрены, и ему вообще плевать.
Понял, насколько случилась жопа, когда у них на утро встал бизнес и мне позвонили и сказали: «Мы знаем, что у тебя есть квартира — продавай и возмещай.»
Мне чудом повезло, что они использовали стороннюю SAAS систему подсчета кликов/лидов, из которой я сумел вытащить данные за последний месяц. Они потеряли бд за несколько лет, но их волновал только последний месяц и от меня отстали.
Я тогда чуть не поседел, после чего решил уйти из веб-разработки (7 лет опыта на стартапах и хайлоаде к тому моменту) и сделать из хобби работу (3д-графика) — нервы целее будут.
Пару месяцев назад тут тоже была веселая история с кастомной рендер-фермой, но это уже другая история и все решилось намного менее нервно. Но теперь я знаю, что в области 3д влететь на стоимость хаты тоже можно (не влетел).
ploop
14.06.2017 09:11само собой, без договора и всего такого
Мы знаем, что у тебя есть квартира — продавай и возмещай
— Ребят, а вы кто такие? Не делал я ничего, да и в компьютерах не шарю, так, примусы починяю…
Можно было как-то так на крайний случай. Возможно, поседеть пришлось бы не «почти», а по настоящему, но квартира бы осталась :)moooV
14.06.2017 09:15Она и так осталась, но урок на всю жизнь.
А еще я теперь знаю, зачем у PMA так много тем оформления и цветовых схем — чтобы вкладки не перепутать.ploop
14.06.2017 09:19Она и так осталась, но урок на всю жизнь.
Да понятно, это я на случай, если бы не удалось (неоткуда было) вытянуть данные.
MINYSMOAL
14.06.2017 13:49Не совсем понял, как связано отсутствие вменяемой документации и вашей ошибки по невнимательности?
Про бэкапы в целом согласен, но с тем условием, что неплохо было бы сначала убедиться, что они есть, а уже потом преступать к работе упоротым ночью ;)
VladimirAndreev
14.06.2017 09:02-1кого уволить:
1. разработчика. блин, чувак, если ты ЧИТАТЬ не умеешь — тебе не место в профессии
2. ответственного за БД. блин, чувак провафлил фатальную базу. казнить однозначно.
кого пытать:
1. кто инструкцию писал — ну как можно было додуматься в ней настоящие данные от продакшна указать?
2. техдира, как ответственного за провалы всех остальных…
fukkit
14.06.2017 09:19-7В комментах 99% вой на тему какая плохая организация в организации и как все кругом виноваты, а стажера, беднягу золотейшего, уволили без премии и даже в зад непоцелованного.
А я вот _лично_ очень хорошо понимаю того чувака, который выгнал к чертям собачьим пакостливого джуна с дырявой кармой, который, как оказалось, не только прод грохнул в первый же день, но и после заслуженного(!) увольнения потащился на реддит ныть «пожалейте меня, поругайте дядек».
Косяк в своей инструкции дядьки, разумеется, поправят и следующих джунов заборчиком огородят. А юношу этого в приличную организацию брать бы не следовало, дабы не полоскаться лишний раз в соцсетях по внутрикорпоративным вопросам.ploop
14.06.2017 09:34+2То есть, вы предлагаете уволить уборщицу, которая случайно наступила на витуху и оставила без связи несколько офисов по всей стране, ибо карма плохая?
Или всё-таки сетевика, который бросил эту витуху на пол?fukkit
14.06.2017 09:50-1В общем случае, того, кто делает это систематически.
Если уборщица постоянно находит, что оторвать, а сетевик — что раскидать, при рецидиве после нескольких разъяснительных мероприятий, к сожалению, будут выгнаны на мороз оба.
А если им не повезло втянуть контору в большой убыток единоразово — с большой вероятностью пойдут искать работу тут же, причем, уборщица — с большей, ибо рынок.mayorovp
14.06.2017 10:04И где же вы в одном случае-то систему нашли?
fukkit
14.06.2017 10:10-3Вы предложили абстрактный кейс, я Вам абстрактно ответил.
В статье статистики для увольнения, кого бы то ни было, я считаю, недостаточно. Но там есть свой руководитель, он решил иначе. Фактов для его категорического осуждения также, имхо, нет.michael_vostrikov
15.06.2017 21:52+1но и после заслуженного(!) увольнения
В статье статистики для увольнения, кого бы то ни было, я считаю, недостаточно.Угу, я не я, и корова не моя.
mayorovp
14.06.2017 09:40Эпитет "пакостливый" происходить от слова "пакость", что означает намеренное (умышленное) действие. На каком основании вы подозреваете злой умысел в действиях джуна?
И что такое "дырявая карма"? В чем это проявляется? Существуют ли доказательства наличия у людей кармы?
fukkit
14.06.2017 10:02-2Вот Вы кого-нибудь уволите за дело, а человек, вместо осознания своей ошибки внутри своей светлой головы и позитивных выводов пойдёт страдать по интернетам. Не пакостливый — образец нормы?
Выражение «дырявая карма» применительно к человеку используется для указания на его патологическую неудачливость. Нужно объяснять, в чем это проявляется?
Русский язык богат на образы, это не программа, а Вы — не транслятор, не стоит искать смысл в словах по отдельности.mayorovp
14.06.2017 10:04Кто вам сказал, что он "пошел страдать по интернетам" вместо осознания своей ошибки?
Что такое патологическая неудачливость и существуют ли исследования на эту тему?
fukkit
14.06.2017 10:18-1Человек сам не способен сделать правильный вывод из простой ситуации и просит общественной поддержки, поднимая этот вопрос, очевидно же.
Вероятность того, что суть Ваших вопросов относительно используемой терминологии сводится к необходимости получить в ответе больше сложных терминов и рекурсивно задать вопрос к каждому из них, я оцениваю как высокую, и предлагаю сиё занятие прекратить и вести диалог конструктивно, либо не вести вовсе.
Ogra
14.06.2017 11:12патологическую неудачливость
Одна ошибка — уже патология? Суровые у вас критерии нормальности.fukkit
14.06.2017 11:25Одно увольнение — тоже совершенно не страшно. Если патологии нет, легко найдёт себе работу в другом месте.
Одни люди более склонны к риску и не видят плохого в том, чтобы ставить дорогие эксперименты на собственном бизнесе, другие склонны менее, и стараются с помощью интуиции, хрустального шара и известной матери снизить потенциальный риск различными способами.
Простого правила тут, разумеется, нет.Ogra
14.06.2017 11:29Одни люди более склонны к риску и не видят плохого в том, чтобы ставить дорогие эксперименты на собственном бизнесе, другие склонны менее, и стараются с помощью интуиции, хрустального шара и известной матери снизить потенциальный риск различными способами.
Так все и говорят, что увольнять надо CTO =) Ведь это он радостно поставил эксперимент на бизнесе, допустив не меньше пяти серьезных ошибок. Не настроить бэкапы, выдать джуну полный доступ к продакшен базе — вот эти действия вполне квалифицируются как «патологическая неудачливость».fukkit
14.06.2017 11:39-2Я не оправдываю руководителей. Однако, реалии таковы, что эффективного руководителя найти в разы сложнее, потому уволить его моментально — неверное бизнес-решение. Каждый случай индивидуальный, для решения нужен весь контекст и история отношений.
С джуном таких вопросов нет. Начал работу с удаления прода — подарком будет увольнение без статьи, ежели реально не виноват.Ogra
14.06.2017 11:45+2эффективного руководителя
Вот именно — он неэффективен. Это он совершил ряд потрясающих (правда, потрясающих, до такого довести — умудриться надо) ошибок, которые привели к безвозвратному удалению базы. Сегодня оказалось, что он бэкапы для базы не сделал, завтра окажется, что пароли лежат в базе в открытом виде, послезавтра выйдет релиз с критическими ошибками и компания потеряет миллионы долларов. Под конец накопится технический долг и его будет не исправить. Только найдется еще какой-нибудьстрелочникджун, на которого спихнут все косяки, а «эффективный менеджер» останется на посту.fukkit
14.06.2017 11:51Эффективность — комплексное понятие.
Неужели Вы думаете, что если выяснится, что он такой злодей и несёт одни убытки, он долго там продержится?Ogra
14.06.2017 11:52Такие «эффективные менеджеры» часто держатся очень долго, и все время все вокруг виноваты, но только не они.
fukkit
14.06.2017 12:13Бывает так, что с точки зрения Васи, менеджеры неэффективные и не нужны, а с точки бизнеса — эффективные и нужны.
Ogra
14.06.2017 13:10Он также сообщил, что из-за важности потерянных данных к делу подключат юристов
Это называется «эффективен с точки бизнеса»?fukkit
14.06.2017 13:39Это называется «одна баба сказала». Засуженного работяги пока не видно.
Ogra
14.06.2017 13:41Я про важные потерянные данные. Вы считаете, что СТО, допустивший потерю важных данных эффективен?
fukkit
14.06.2017 14:01На мой взгляд, для оценки эффективности конкретного СТО информации недостаточно. Есть сведения только о некоторых его косяках.
Ogra
14.06.2017 14:05Зато информации для «заслуженного увольнения» джуниора вам достаточно. Он ведь, пакостник этакий, ошибся в 1й день работы. Это же патология и дырявая карма…
fukkit
14.06.2017 14:11Выше уже писал, что лично мне — недостаточно. Но руководителя, так поступившего, понять могу и осуждать не готов.
Ogra
14.06.2017 14:15+1Я тоже могу понять руководителя так поступившего — в нашей истории это называется «назначить стрелочника». Правда, ничего хорошего об этом «эффективном руководителе» я сказать не могу.
Igor_O
14.06.2017 12:17Есть такая категория специальная «эффективных менеджеров». Приходит руководить, проводит какую-нибудь эффективную реорганизацию, проводит сокращение расходов и еще чего-нибудь модное. Потом все начинает рассыпаться, он получает два годовых оклада своего «золотого парашюта», ищет новую компанию для приложения своих талантов. В резюме добавляется запись на тему «CxO в компании XYZ, сократил издержки на 50%, сократил расходы на зарплату на 30%, поднял капитализацию на 12.5%.» (То, что контора еще через пол года разорилась и продалась за пол цены — это уже мелочи)
fukkit
14.06.2017 12:28В нормальной компании такие пинка получат, а не парашюта вовсе. И не резюме будут хвастаться, а прятать трудовую с соответствующей записью.
А вот если рыбья голова изволила сгнить, так и бизнесу тому конец, рано или поздно.
springimport
16.06.2017 19:58Вы прямо таки описали ситуацию в некоторых сферах с которыми в последнее время много новостей)
Dzen1
14.06.2017 10:17-1Джун-Ждун ))). Может эт был засланный казачок.
Ogra
14.06.2017 11:13Я бы на месте засланного казачка радостно бы сливал продакшен-базу, а не убивал бы её. Откуда мне знать, что бэкапов нет?
Dzen1
14.06.2017 12:22-1А зачем, может цель была именно база и именно у конкурентов и то что бэкап не смогли поднять это бонус в догонку. Я бы сказал бонусище
Ogra
14.06.2017 13:11А если бы подняли за пять минут? Штирлиц облажался, расстрел и все. А сливать базу конкурентам — это годы оперативной работы, лычки полковника и орден за заслуги.
Dzen1
14.06.2017 13:39Если бы подняли сказали бы ая яй так больше низяяя. И возможно этот джунанджи дальше бы работал.
И кто знает что бы он еще «натворил» ))) этот коварный тип гражданской наружности. А тут вроде как «сработало». Еще надо бы пристально присмотреться к бекапщику, он тоже парень не промах ))).
deadkrolik
14.06.2017 12:05Примерно в 2008 году работал я в одной структуре. Там велся разный такой учет в старой-старой БД FLINT, которая еще под DOS. Штука, кстати, отличная по задумке. И тут понадобилось мне кое что поправить в базе, а хранит она все в обычных DBF-файлах, ну я экселем стороки подвинул как мне надо было. Но кто же знал, что FLINT оперирует не каким-то там ключом, а порядковым номером строки в DBF файле. Я этого не знал и база поехала, целиком.
Так как там был немного бардак и я был еще одним эникеем, то о бэкапах и прочем никто не думал. Чудом сохранились файлы базы недельной давности и 6 человек старательно вбивали данные заново.
После этого я провел ревизию вообще всего, что можно забэкапить, настроил кроны на виндовсах, синхронизации и хранил бэкапы N месяцев на разных тачках. Сильно выручало очень много раз. А сейчас работая над проектом первое что я делаю — прошу настроить бэкапы, и иногда прошу мне дать бэкап за вчера.
troublegum
14.06.2017 13:48-2Уволить надо всех! Потому что все раздолбаи!
Тех. директор не следит за процессом.
Разраб зачем то полез на бой, даже не спросив есть бекапы или нет?
Ответственного за бекапы тоже надо уволить, потому что ковырял в носу и даже не удосужился делать бекапы.
В общем на лицо банальное раздолбайство, которое всегда есть в крупных компаниях!
ooprizrakoo
14.06.2017 22:56+2Помнится, году в 2008 к нам в команду присоединился новый программист, хороший умный парень, сишник, через пару дней спрашиваю у лида — как паренек? — лид ответил «хорошо втягивается, уже смог убить базу» :)
Ну там правда все было на дев-сервере, но это звучало как похвала — чтобы смочь убить базу тоже нужен некий уровень экспертизы внутри проекта :)
speller
15.06.2017 09:35Люди делятся на два типа — кто уже запускал тесты на прод базе, а кто еще нет.
navion
15.06.2017 14:58+1Странно, что никто не вспомнил про пиццерию, которая запустила тестовый скрипт с настоящими реквизитами от Яндекс.Кассы.
Adel-S
16.06.2017 09:54Так им же всё вернули в итоге. Случай не настолько фееричный.
ploop
20.06.2017 12:49Как сказать, 200к в итоге на комиссиях и СМС пришлось заплатить. Но самое интересное вот что, прямо в тему топика:
«Безусловно, мы сделаем серьезнейшие выводы из этой критической ошибки. Мы не будем наказывать людей — мы просто сделаем все, чтобы такого больше не повторилось.»
Hiyori_o
15.06.2017 19:39Мне кажется, любая уважающая себя крупная компания должна думать об ограничении прав доступа к важным продуктивным данным. Ну а так-то… fails happen.
iit
16.06.2017 07:41Если в компании меньше 3.5 програмистов то разворачиванием среды для джуна должен занисаться опытный разраб (раньше это делал я сам), если больше то такой документ (естественно без боевых доступов) + бэкап базы, если есть возможность то вообще сделать процесс создания тестового окружения в виде виртуалки или docker контейнера.
В этой ситуации всиновны все по немногу.
- Джун по сути уничтожил компанию, с точки зрения бизнеса это очень плохо и естественно что у руководства бомбануло и его выгнали на мороз.
- Создатель документа — ибо писать туда боевое подключение это тот еще косяк. Такие данные должны знать 1.5 человека а не джун. Это хорошо что он его уронил а не сделал копию и унес конкурентам.
- Коллеги джуна так как не проследили за тем как он разворачивает систему и не помогли ему с этим.
- Техдир за то что не выстроил автоматизированный просесс подготовки тестовой среды
- Админы с бэкапом шрёдингера — всегда проверяйте бэкапы на то что из них можно восстановиттся
- Опять Техдир который опять не выстроил процессы востановления данных и не пнул админов
- HR и руководство компании которое наняли идиота техдира, идиота админа и приправили это джуном и надеялись что и так сойдет.
P.S Когда-то я сам был джуном и ронял базу на проде, и не было бэкапов, вообще никаких ибо в разрабах было всего два человека я и мой одногрупник.
Тогда с матами контентщики за 2 дня восстановили данные, благо копии контента у них были. После этого начали делать бэкапы.
Потом я еще раз уронил базу — но бэкапы не были актуальны — потеряли данные за 2 месяца, выстроили проверку бэкапов.
После меня еще многие роняли продакшен базу — всего раз 35 за 5 лет, но в этом случае всегда были вчерашние недельные и месячные бэкапы и по одной копии прода у всех разрабов на локальных компах и копия прода на тестовой версии сайта. когда не в очередной раз уронили базу на проде а бэкапов не было так как место кончилось — такие копии нас спасли, у меня оказалась копия прода за 3 часов до его падения но без одной таблицы а у одного человека нашлась эта самая таблица — сделали слияние и настроили ротацию бэкапов и отправку бэкапов на отдельный сервер с этими бэкапами.
Теперь появились микросервисы и для того чтобы уронить все их базы нужно еще постараться, тем более что на каждый сервис есть свои бэкапы.
Да понятно ресурсы ограничены и не всегда есть время и деньги покрывать такие риски — но если их за этих рисков компания загнулась то это не вина джуна, это вина руководства и его коллег.
Phoenix86
16.06.2017 10:44Да о чем тут говорить…
Джун тут вовсе не виноват. Сама позиция, подразумевает то что сотрудник должен быть ограничен в правах. У него не должно быть прав для сноса базы.
Да и админы с бэкапом должны проверять их
Scf
16.06.2017 16:48+1Видите, в какой хорошей стране мы живем — в РФ наемного работника без материальной ответственности не могут оштрафовать на сумму, превышающую его месячный оклад.
Джун, конечно же, не виновен. Джун *в принципе* не может быть в виновен в одиночных косяках. Виновен ответственный за невозможность случайного нанесения вреда продакшну. Или тот, кто этого ответственного не назначил.
pazitiffcheg
19.06.2017 15:08Я работал в одной маленькой компании, где техдиректор (если его можно так назвать) в ответственный момент мог забухать и не придти на работу. Из-за этого выплывало много проблем и ложилось на плечи рядовых сотрудников. За пол года моей работы, подобное случалось несколько раз и многим приходилось до 11 вечера сидеть на работе, чтобы сдать проект без него. При этом он даже спасибо ни разу не сказал. Он и владелец компании друзья. Ему никогда ничего не было за такие прогулы, раздолбайство на лицо (какие ж тут бекапы, доступы и т.д.). Я не смог работать с такими людьми и покинул компанию, но я не думаю что после этого что-то изменилось. Виноват был бы джуниор, работая в подобной компании и беря пример с проиходящего? Конечно нет! Однозначно всегда рабочий процесс должен контролировать технический директор. Значит прежде всего виноват именно он.
BubaHamona
20.06.2017 12:18Джуниоры никогда не получают прямой доступ к проду на запись. Чтение только с реплики (на то он и джуниор, чтобы еще научиться не класть базу одним запросом). В документации никогда нет паролей, которые, к слову, должны регулярно меняться, согласно политике безопасности. Ну и проверка восстановимости бекапов…
В общем, тут про** СТО по всем фронтам.
Itachi261092
20.06.2017 12:56Помню, когда работал с сайтом одного не очень известного банка в админке, рядом открыл копию сайта для разработчиков. И меня сильно подгоняли по времени, я поспешил, и по ошибке удалил целый кусок бд с продакшена, когда надо было его удалить на тестовом. и я тоже не сразу понял что я это сделал на боевом сайте. доделал работу и сдал задачу. через час звонят из банка, говорят «вы чо ахринели, у нас целый раздел сайта пропал и ошибки выдаёт»
Хорошо что перед работой я делал полный бекап базы и с помощью старшего специалиста мы в течении полу часа восстанавливали вручную нужные таблицы. благо там не затронуты были транзакции и прочие сложные записи. просто контент.
evil_kabab
22.06.2017 09:53Ну идиоты конечно. Объявили стрелочником человека, который вообще не понимал что делает и был в состоянии стресса (первый день на первом рабочем месте).
Им бы стоило создать юзера БД (продакшн) с правами «только чтение» и катастрофы бы не случилось.
AsianCat
22.06.2017 12:30Это знамение. А чуваку премию и в какую-нибудь приличную компанию его на работу.
WildZero
Ну сами виноваты ж. продакшн доступы в дев-инструкии, чего они ждали то. ну и да, действительно, бекапы Шредингера. ну а джун, как по мне, ни в чем не виноват.
Zavtramen
Джун вообще должен иметь такие права доступа, чтобы даже при большом желании ничего не смог поломать. Тех кто писал инструкцию, ответственного за бэкапы, и СТО — на ковер, а Джуна похвалить за найденную уязвимость во внутренних процессах.
hlogeon
Должны иметь доступ или нет — это вопрос совершенно другой. Вполне есть способы сделать так, что у каждого члена команды будет доступ к production, но это требует куда больших усилий, чем разграничение прав.
Но с тем, что джуна похвалить, а CTO на ковер — согласен)
MrShoor
Ну хвалить — это вы перегнули конечно. Вот если бы он не грохнул базу, а пришел и сказал: «Кажется у вас креденшлы к продакшну в документации» — то однозначно похвалить. А в произошедшем случае хвалить не надо, он просто вступил в каку, оставленную кем-то.
CarambaPirat
Расскажите секрет определения креденшпы от продакшна и дева? Если они не называются TestUser:TestPassword, конечно.
MrShoor
Да, вот как то так и определить.
Теоретически там могло вернуться что то в духе Test Test на машине Test. И тогда можно было бы насторожиться, что на руках имеется 2 разных рабочих креденшла. Один с пометкой Test, второй какой то Admin e4jm0dlwe9jvfje на машине production01.somecorp.comВ статье:
MuratovTM
Тогда бы историю о его похвале никто бы не узнал )
saboteur_kiev
бэкапы Шредингера =), как я пропустил этот замечательный термин
al3xshaman
Все верно, какой продакшн без бекапов. Даже на дешевых хостингах бэкапы делаются
Akon32
Не только делаются, но и теряются вместе с основными данными.
ooprizrakoo
Угумс. Наверное многие помнят истории, когда «бэкапы» таблиц mysql хранились в этой же базе Mysql :)
BelBES
Надо еще проверить, не диверсант ли это...
MadWombat
> ну а джун, как по мне, ни в чем не виноват
Пацан к успеху шел :)
khanid
Если бы это был диверсант, он бы там не только базу положил бы. С таким подходом, наверняка, там много целей.
alex4321
Так диверсант же ещё только джун — не хватило опыта, чтобы сразу найти новые цели для атаки
georgevp
Опять русский хакер…
varnav
Да что там продакшен доступы. Я могу сейчас всем разрабам разослать логин-пароль от продовой базы и её IP адрес, но они не смогут ничего с этим сделать, у них не будет к ней подключения. И наоборот быть не должно.
mavriq
его вина лишь в том, что… с такою кармой он пошел не в тестировщики
burzooom
Ага, представляю продолжение истории: другая контора наняла этого напортачившего джуна тестировщиком
ожидание: джун выявил множество уязвимостей в тестируемых продуктах
реальность: джун стер базу данных фирмы вместе с бекапами
k0ldbl00d
В описанном случае реальность и ожидание — это одно и то же. Он ведь выявил серьёзную уязвимость.