Comments 376
Ну сами виноваты ж. продакшн доступы в дев-инструкии, чего они ждали то. ну и да, действительно, бекапы Шредингера. ну а джун, как по мне, ни в чем не виноват.
Джун вообще должен иметь такие права доступа, чтобы даже при большом желании ничего не смог поломать. Тех кто писал инструкцию, ответственного за бэкапы, и СТО — на ковер, а Джуна похвалить за найденную уязвимость во внутренних процессах.
Должны иметь доступ или нет — это вопрос совершенно другой. Вполне есть способы сделать так, что у каждого члена команды будет доступ к production, но это требует куда больших усилий, чем разграничение прав.
Но с тем, что джуна похвалить, а CTO на ковер — согласен)
Но с тем, что джуна похвалить, а CTO на ковер — согласен)
Ну хвалить — это вы перегнули конечно. Вот если бы он не грохнул базу, а пришел и сказал: «Кажется у вас креденшлы к продакшну в документации» — то однозначно похвалить. А в произошедшем случае хвалить не надо, он просто вступил в каку, оставленную кем-то.
Расскажите секрет определения креденшпы от продакшна и дева? Если они не называются TestUser:TestPassword, конечно.
Да, вот как то так и определить.
В статье:
В статье:
После запуска определённой команды я должен был скопировать URL/пароль/юзера базы данных из её вывода и настроить dev-окружение, указав там эту базу.Теоретически там могло вернуться что то в духе Test Test на машине Test. И тогда можно было бы насторожиться, что на руках имеется 2 разных рабочих креденшла. Один с пометкой Test, второй какой то Admin e4jm0dlwe9jvfje на машине production01.somecorp.com
Вот если бы он не грохнул базу, а пришел и сказал: «Кажется у вас креденшлы к продакшну в документации» — то однозначно похвалить
Тогда бы историю о его похвале никто бы не узнал )
бэкапы Шредингера =), как я пропустил этот замечательный термин
Все верно, какой продакшн без бекапов. Даже на дешевых хостингах бэкапы делаются
ну а джун, как по мне, ни в чем не виноват.
Надо еще проверить, не диверсант ли это...
Да что там продакшен доступы. Я могу сейчас всем разрабам разослать логин-пароль от продовой базы и её IP адрес, но они не смогут ничего с этим сделать, у них не будет к ней подключения. И наоборот быть не должно.
… ну а джун, как по мне, ни в чем не виноват.
его вина лишь в том, что… с такою кармой он пошел не в тестировщики
Там никого увольнять не надо — бизнес рассыпется, и все вылетят, а джун этому только поспособствовал как триггер нескольких уязвимостей.
Более того, зачем увольнять сотрудников, которым провели такой дорогостоящий тренинг.
Технический директор уже считай угробил бизнес. А судя по его последующим действиям, он даже не понимает причинно-следственной связи. Вместо того, чтобы повысить джуниора, который одним легким движением нашел ошибки в документации и протестировал систему резервного копирования, он повел себя как истеричка)) Гнать, однозначно!
так потому он и уволил джуниора, чтобы свои косяки попытаться скрыть
Не факт. Я довольно много встречал людей, которые на месте техдира из этой истории были бы искренне убеждены, что в этой ситуации не их вина, а джуна.
Не думаю что это причина кого-то повышать, не вижу здесь заслуг junior'а, если бы он нашел и указал на это а не все выяснилось в результате ошибки, можно говорить о вознаграждении.
А вот разобраться почему доступ к проду не был защищен и более того креды попали в описание дев настройки нужно. Ну и соответственно потом делать выводы. Возможно это реально случайны косяк, хоть и серьезный, а возможно система.
Был похожий кейс, когда я поменял значение некоторых данных на продакшне. Данные были связаны с ценами на продукцию и компания понесла убытки. Но меня не уволили, хоть и критиковали)
Похожее дело было. Когда я обернул эксепшн, что бы в логи не сыпалась постоянная ошибка об необработанном эксепшене. Но оказалось, что этот необработанный эксепшн использовался что бы останавливать фродерские транзакции. Так за сутки магазин успел продать кучу товаров фродерам. Меня тогда поругали, но оставили в команде))
UFO just landed and posted this here
Ну и ещё один, опытные сотрудники должны проводить ревью каждой задачи.
Ну и ещё один, в любой непонятной ситуации с бизнес логикой, спроси тех кто уже давно работает, все ли я понимаю правильно.
Хотя судя по тому что проброской эксепшенов отлавливают такие бизнес кейсы и не делают ревью и эти советы могут и не помоч.
Ничего себе у вас бизнес-логика.
Полагаться на возникающую ошибку для отсечения левых транзакций — это, конечно, весьма спорный способ…
Это не вы офис за 5 баксов «продавали»?
Ну, для коллекции — я на своей первой работе почистил все «комментарии» на всех клиентских системах, которые успели обновиться до моих изменений. Произошло это из-за археологического костыля для удаления неверных записей, о котором я не знал. Меня тогда даже не ругали, посадили переписывать этот костыль чтобы он еще чего-нибудь не почистил :)
Мне кажется такие фейлы у многих встречаются. Я тоже один раз не так бекап снял и потерял данные за полдня работы, восстановить можно руками но долго. Заказчик говорил что там было заказов на неск десятков тыс уе)
Я считаю, это не фейл (в моём случае). Я разработчик, моя работа и моё время в сто раз важнее, чем цены на носки. Я должен разрабатывать адекватное программное обеспечение, а то что при этом у каких-то торгашей невалидные данные на продакшне, не мои проблемы.
Я разработчик, моя работа и моё время в сто раз важнее, чем цены на носки
Надо запомнить. Буду знать, что сказать начальству после случайного массапдейта в боевой БД.
С такими заездами для «разработчика» цены на носки в короткий срок могут поднабрать субъективной важности.
Я так и сказал. Но в моём кейсе, я не портил бд. Я просто выгрузил билд проекта у себя дома, чтобы доработать некоторый функционал, связанный с UI для редактирования данных. Доработал, потестил. Но я не знал, что по дефолту в приложении назначен боевой API, а не тестовый. Вот если бы мне об этом говорили, тогда это была бы моя вина. А так — не мои проблемы.
Если у них в инструкции для прописаны данные авторизации для продакшн базы, то туда им и дорога, всей компании целиком, от гендиректора до этого студента.
Я правильно понял, что в инструкции для разработчиков была прописана команда, очищающая базу на проде?
В тестах, написано же
Мне дали документ с информацией о том, как настроить локальное окружение для разработки. Инструкции включают запуск маленького скрипта для создания личной копии БД с тестовыми данными.
Не, вот тут
Далее, как понимаю, тесты добавили ненастоящие данные и очистили существующие, то есть между запусками тестов все данные из БД в production были удалены
В инструкции стояли креды от продакшн-базы, и указание на тестовый скрипт, который надо запустить с выданными в другом месте кредами. Джун перепутал и вбил креды из инструкции. Тестовый скрипт, скорее всего, включал в себя drop database с совпадающим именем, либо вместе с кредами вбивалось и имя БД. Результат — дроп продакшн-базы.
Нет, нет, нет! Она ничего не очищала. Просто заменяла рабочие таблицы на пустые!
Базу не заваливал, но помогать восстанавливать заказчику приходилось. Он экономил сильно на разработке и некоторых частей для администратирования в софте не было реализовано. По этому данные правились руками, из SQL developer. Один раз один из айтишников заказчика написал крутой SQL апдейт, но выделил для запуска только часть до where и так проапдейтил всю табличку с центральной сущностью — накладными. В обед. То-есть пол дня прошло, десятки грузовиков стоят ждут отгрузки, а все накладные в статусе «closed». Неизвестно что отгружать, накладные даже распечатать невозможно. Бэкап есть, но он делается только по ночам, то-есть практически бесполезен.
Пришлось брать логи приложения и эмпирически восстанавливать статус. Два часа детективной работы. По крайней мере накладные за сегодня выправили. Потом восстановили бэкап в соседнюю базу данных и восстановили уже остальные.
Пришлось брать логи приложения и эмпирически восстанавливать статус. Два часа детективной работы. По крайней мере накладные за сегодня выправили. Потом восстановили бэкап в соседнюю базу данных и восстановили уже остальные.
Oracle SQL developer?
Там после SQL апдейт можно было заметить, что многовато обновилось и не жать Commit.
Там после SQL апдейт можно было заметить, что многовато обновилось и не жать Commit.
Ну если у него autocommit стоял, то могло быть и поздно что-то делать. Как у него это получилось не знаю достоверно, может и как-то по другому накосячил, мне так передали.
А если база оракловая, то с версии 10.1 есть Flashback Query, который вполне позволяет восстановить данные на некоторое время назад. В зависимости от нагруженности базы, размера UNDOTBS и значения параметра undo_retention (по умолчанию 15 минут вроде).
Угу. Была такая история. Разработчик заметил и нажал Rollback. И огромная транзакция начала откатываться… В течение нескольких часов. DBA вежливо заметил разработчику, что если бы тот сначала спросил, то проще было бы нажать commit и восстановить таблицу из бэкапа — все бы произошло гораздо быстрее и не стоило бы компании нескольких часов простоя.
В одном банке была аналогичная ситуация, только с владельцами счетов. К моему счастью, я участия в этом не принимал, но атмосфера чувствовалась.
Бывало со мной такое за многолетнюю практику. Именно такой случай — выделение в консоли без where.
Обошлось «без жертв», т.к. шкурой чувствуешь — апдейт должен отработать за пару секунд максимум, а тут второй десяток пошел, уже рефлекс на кнопку «стоп»
Ну и ошибки были, что приходилось из бекапов нужные куски данных тянуть. Правда пару раз за всю практику (тьфу-тьфу)
Обошлось «без жертв», т.к. шкурой чувствуешь — апдейт должен отработать за пару секунд максимум, а тут второй десяток пошел, уже рефлекс на кнопку «стоп»
Ну и ошибки были, что приходилось из бекапов нужные куски данных тянуть. Правда пару раз за всю практику (тьфу-тьфу)
UFO just landed and posted this here
Если автокоммит не включен, то транзакция начинается после первого DML или DDL, смотря, что за база и настройки. С автокоммитом тут же и заканчивается. Как бы в нормальной базе данных «похерится меньше записей» не бывает.
UFO just landed and posted this here
Если автокоммит отключен, то рабочая сессия постоянно находится в транзацкии. Можно сделать несколько апдейтов/делитов/инсертов, но эти изменения «применяться» только после коммита, после чего начнется новая транзакция.
По сути, когда ВКЛЮЧЕН автокоммит, то каждый запрос выполняется в отдельной транзакции, которая коммитися сразу после выполнения запроса.
Даже без явно заданной транзакции большой апдейт можно остановить и все изменения, которые успели сделаться, будут отменены.
По сути, когда ВКЛЮЧЕН автокоммит, то каждый запрос выполняется в отдельной транзакции, которая коммитися сразу после выполнения запроса.
а потом остановить его — то все изменения откатятся, не будет такого что часть записей которые «успели» — будут обновлены, а часть — нет?
Даже без явно заданной транзакции большой апдейт можно остановить и все изменения, которые успели сделаться, будут отменены.
UFO just landed and posted this here
СУБД Postgresql, дефолтные настройки PgAdmin'а, автокоммит включен, но всё, что написано в консоли, выполняется в одной транзакции.
То есть, если написать 5 мелких апдейтов и одни большой, и запустить всё это на выполнение, есть шанс остановить без последствий
То есть, если написать 5 мелких апдейтов и одни большой, и запустить всё это на выполнение, есть шанс остановить без последствий
Да
По MySQL не знаю как сейчас, 5 лет назад на таблицах, работающих на движке MyISAM (кажется так называется) "транзакция" была предельно "атомарна" — остановленный в процессе апдейт таки внёс бы изменения в часть колонок и не откатил их после остановки.
Впрочем это не касается транзакционного движка MySQL и других известных мне СУБД.
Если взять какой-нибудь Postgres либо Oracle, то там можно через специальные функции отменить идущий запрос (если он еще закончился и, соответственно, не случился commit).
Т.е.
1) увидели, что запрос подозрительно затянулся
2) перепроверили запрос и увидели ляп
3) запросили у базы список запросов и нашли проблемный
4) дали команду отменить запрос
5) запрос отменяется, транзакция отказытвается, попорченные данные так и не становятся видимы для всех остальных, кто работает с базой
Примечание: 3 и 4 требуют привелигированного доступа к базе.
Кстати, после этого случая я и узнал, что выполняется только выделенный кусок кода, что потом стал использовать в разработке: можно закомментить всё в окне, и по необходимости выполнять мелкие куски оттуда, не создавая новых окон.
А нельзя сделать бекап логов и прокрутить их поверх ночного бекапа до инцидента?
На то он и джуниор. Для этого у него должен быть наставник, и не только в самый первый день. Да я по себе помню — когда приходишь на новое место и тебе надо что то настроить себе, при этом ты не имеешь совершенно никаких понятий как и что в компании устроено… я будучи не джуниором, имея в инструкции админские пароли от продакшена, не уверен что я ничего не снесу :)
В инструкциях никогда не храним пароли.
Пытаюсь сдать сейчас проект заказчику, одна из претензий: в инструкциях не указаны логины/пароли администраторов. На мои замечания что вообще-то, после того, как я уйду, вы их должны сменить и соответственно сразу же устареет инструкция, никто не обращает внимания (менять пароли тоже никто не будет).
Откуда вообще у разработчика доступ к production базе?
Доступ к ней должен быть только у админа/девопса/релиз менеджера — того, кто отвечает за деплой на продакшен, кто делает бэкапы. И в идеале доступ выдается временно, под определенным тикетом.
Это конкретно прокол организации и соответственно тех.директора, которые не поставил нормально работу, не добился понимания того, что бэкапы есть и проверены, не добился того, что инструкции адекватные…
Да в общем, тут как-бы очевидно все. Вопрос в том, насколько бизнес поднимется, если у них вообще бэкапов нет (нонсенс просто).
Доступ к ней должен быть только у админа/девопса/релиз менеджера — того, кто отвечает за деплой на продакшен, кто делает бэкапы. И в идеале доступ выдается временно, под определенным тикетом.
Это конкретно прокол организации и соответственно тех.директора, которые не поставил нормально работу, не добился понимания того, что бэкапы есть и проверены, не добился того, что инструкции адекватные…
Да в общем, тут как-бы очевидно все. Вопрос в том, насколько бизнес поднимется, если у них вообще бэкапов нет (нонсенс просто).
Да тут на самом деле очень много вопросов по организации работы. Но винить джуниора в том, что он пришёл и по незнанию и инструкции с админискими правами всё сломал — это верх безумия (хотя чего ожидать от руководителя, у которого таким образом построена работа!?).
Главное что б руководитель ушёл «по статье», если у них такое там есть.
Главное что б руководитель ушёл «по статье», если у них такое там есть.
>> Откуда вообще у разработчика доступ к production базе?
Я так понял, скрипт снимал бэкап прода и разворачивал на локальной машине. Проблема в том, что доступ был не только на чтение :)
Я так понял, скрипт снимал бэкап прода и разворачивал на локальной машине. Проблема в том, что доступ был не только на чтение :)
В таком случае ничего бы не произошло.
Судя по описанию, скрипт создавал БД и заполнял её тестовыми данными.
Судя по описанию, скрипт создавал БД и заполнял её тестовыми данными.
Один скрипт именно что снимал бэкап и разворачивал его не то на локальной машине, не то на какой-то тестовой.
Второй скрипт убивал все данные в БД и заполнял их тестовыми значениями.
Джун должен был запускать второй скрипт с теми конфигами, что нагенерировал первый, но он запустил его с данными production базы.
Второй скрипт убивал все данные в БД и заполнял их тестовыми значениями.
Джун должен был запускать второй скрипт с теми конфигами, что нагенерировал первый, но он запустил его с данными production базы.
А если сеньор приходит то он с первого дня понимает как что в компании устроено?
В истории прекрасно всё :) Не думал, что такое бывает в реальности.
В реальности еще и не такое бывает…
Не буду писать какая именно из СУБД, но при переполнении тома коцает базу. Естественно, ни в один лог не пишется, что место кончилось, да и вообще в логах ничего о проблеме нет. После этого у пользователей начинаются странности. То интерфейс не грузится, то грузится, но в какие-то моменты выпадает… Естественно, первая реакция саппорта на сообщения о проблемах — а давайте включим ведение подробных логов! Сразу после этого база убивается вообще до невосстановимого состояния. Единственный вариант — полностью восстановить базу и СУБД из бэкапа. Если он сделан до того, как СУБД покоцала базу… Самое смешное, что, кажется, на СХД даже было настроено автоувеличение объема тома по мере необходимости, но почему-то не сработало.
Не буду писать какая именно из СУБД, но при переполнении тома коцает базу. Естественно, ни в один лог не пишется, что место кончилось, да и вообще в логах ничего о проблеме нет. После этого у пользователей начинаются странности. То интерфейс не грузится, то грузится, но в какие-то моменты выпадает… Естественно, первая реакция саппорта на сообщения о проблемах — а давайте включим ведение подробных логов! Сразу после этого база убивается вообще до невосстановимого состояния. Единственный вариант — полностью восстановить базу и СУБД из бэкапа. Если он сделан до того, как СУБД покоцала базу… Самое смешное, что, кажется, на СХД даже было настроено автоувеличение объема тома по мере необходимости, но почему-то не сработало.
Это другое немного. Тут всё-таки в софте бага, а в оригинальной истории мегапофигистское отношение к бизнес-критикал вещам, это даже багой не назовёшь, это просто профнепригодность.
Тут забавное сочетание обстоятельств — проблема возникает из-за невозможности из линукса точно узнать объем свободного места, в сочетании с отсутствием ошибки при обнаружении недостатка места в софте, в сочетании с естественной натасканной реакцией саппорта — если что-то непонятно, включить журналирование всего и передать результат на уровень выше. В результате — журналов все больше, а боевой базы — все меньше. (по какой-то причине, журналы нормально писались и не бились...)
Плюс к этому — отсутствие живых бэкапов.
А исходная первопричина багов в софте — разработчики СУБД не тестировали СУБД в условиях недостатка места. Просто не пришло в голову, что у кого-то может переполниться том с боевой базой.
В описанной в топике истории — наложение трех багов в wetware: первый баг — автор документации забыл поменять в тексте после копипаста логин пароль боевой базы, второй — никто не догадался поменять логин-пароль боевой базы перед запуском в продакшн.
Баг номер три — джун после учебы натаскан вбивать примеры из учебника как есть не включая мозг. А уже потом разбираться, если вдруг что-то не заработает.
Плюс к этому — отсутствие живых бэкапов.
А исходная первопричина багов в софте — разработчики СУБД не тестировали СУБД в условиях недостатка места. Просто не пришло в голову, что у кого-то может переполниться том с боевой базой.
В описанной в топике истории — наложение трех багов в wetware: первый баг — автор документации забыл поменять в тексте после копипаста логин пароль боевой базы, второй — никто не догадался поменять логин-пароль боевой базы перед запуском в продакшн.
Баг номер три — джун после учебы натаскан вбивать примеры из учебника как есть не включая мозг. А уже потом разбираться, если вдруг что-то не заработает.
А исходная первопричина багов в софте — разработчики СУБД не тестировали СУБД в условиях недостатка места
Что-то самописное?
Тут забавное сочетание обстоятельств — проблема возникает из-за невозможности из линукса точно узнать объем свободного места
Видимо то вы просто не умеете его готовить. Заббикс, например, из коробки мне вкинул темплейт: Discovered by
Mounted filesystem discovery, и по всем линуксово-аиксовым серверам показывает графики и алертит, если меньше 20%, 10%, 2% (с разным "приоритетом") свободного места. На рабочей машине скрипт, который смотрит все примаунченые файловые системы, и раз в 5 минут алертит через notify-send если занято более 90%. Короче не вижу "невозможности из линукса точно узнать объем свободного места".
Возможно имеется ввиду, что бд внутри себя создает какой-то виртуальный том, но это изврат, как мне кажется.
А линукс вообще был какой-то ред-хэт… на виртуальной машине. А на чем физически СХД жила — вообще неизвестно было. И когда виртуальной машине на виртуальной СХД выдают виртуальный том… Там вообще много разного интересного может случиться и без участия СУБД…
Как там было на баше в свое время: … старкон2, запущенный в DosBox, под иксами в Дебиане, который запущен в VMWare, которая в WinXP
Куда мне вопрос о неработающем звуке задавать? ...
Как там было на баше в свое время: … старкон2, запущенный в DosBox, под иксами в Дебиане, который запущен в VMWare, которая в WinXP
Куда мне вопрос о неработающем звуке задавать? ...
ну не знаю, ребят. У меня блейды с red hat мастер-машинами, на которых kvm'ные редхаты крутят оракл энтерпрайс, и ibm'ные машины, на которых aix'ы крутят оракл энтерпрайс. И везде с hitachi схд выделены диски.
Но я не вижу таких проблем, как вы описываете. Может быть с этим столкнулись люди, которые настраивали всю инфраструктуру, но при развертывании новых бд я тоже не вижу таких проблем. Более того, в реальном времени мониторится как наличие свободного места на дисках (под арклоги, в основном), так и свободное место в tablespaces внутри оракла.
Наверное, вы просто что-то не так сделали… или не дочитали.
Может быть данные хранились на разделе без ФС?
Со всеми своими извращениями с виртуальными машинами я пока только до одного не докатился: попробовать запустить VMware внутри VMware. Матрёшку сделать :)
На практике не работает. Вроде всё по Попеку и Голбергу в x86, но… не работает. Кажется сейчас можно запустить VMWare внутри VMWare, а вот уже там — VMWare не запустить. Притом, что у IBM 3-5 уровней работали уже в 70е.
Соответствие набора инструкций требованиям дает только теоретическую возможность. Инструкции виртуализации же надо еще правильно эмулировать в самой виртуальной машине — а это мало кому интересно.
Короче, надо попробовать :)
А если VMware — VirtualBox — VMware — VirtualBox — …?
А какая разница? Как было выше замечено AMD-V или Intel VT-x можно виртуализовать — но, насколько я знаю, ни VMWare, ни VistualBox не заморачиваются. Так что процессор «внутри» оказывается как бы без этих технологий, и, соответственно в VMWare «второго уровня» VMWare уже не запустить.
Если это исправили (а могли — я довольно давно не смотрел), то можно вкладывать хоть 10 уровней (если памяти/скорости процессора хватит), если нет — то только три…
Если это исправили (а могли — я довольно давно не смотрел), то можно вкладывать хоть 10 уровней (если памяти/скорости процессора хватит), если нет — то только три…
Вложенная виртуализация у VMware появилась в 2010 году и двух уровней хватает для лаб с гипервизорами.
А какой смысл практический смысл в 3-5 уровнях вложения? Какие-нибудь заморочки с MLS?
А какой смысл практический смысл в 3-5 уровнях вложения? Какие-нибудь заморочки с MLS?
Ну почему изврат, тот же оракл афаик так же поступает — он зажрет всё место на выделенном диске сразу под свою базу уже потом что-то там внутри своей базы распределяет, выделяет место итд, и о состоянии с местом внутри базы ты из самого линукса не узнаешь, по df ты всё время видишь 99%-100%.
Только это ни разу не линукса проблема, это на уровне БД такое веселье…
Только это ни разу не линукса проблема, это на уровне БД такое веселье…
В моей практике были случаи, когда заббикс гасил триггер не потому, что место появилось, а потому, что свободное место на диске становилось отрицательное (на линуксе такое возможно, да), а заббикс хранил значение в unsigned типе, которое приводилось к 2^16-n. Не помню, правда, это во встроенных шаблонах было, или что-то самописное.
это тоже своего рода баг. Баг в людях и политике «ну ты сделай так что бы работало, а потом поправишь(нет)»
и сразу вспомнился один ну очень бородатый анекдот:
— Расскажите о себе
— Могу копать, ну правда херово, могу не копать, в этом разбираюсь чуть лучше, могу сделать так что бы другой копал — с этим справляюсь на ура!
— Поздравляю с назначением на должность технического директора!
и сразу вспомнился один ну очень бородатый анекдот:
— Расскажите о себе
— Могу копать, ну правда херово, могу не копать, в этом разбираюсь чуть лучше, могу сделать так что бы другой копал — с этим справляюсь на ура!
— Поздравляю с назначением на должность технического директора!
Напишите уж пожалуйста, что это за СУБД, это же царь-баг!
Ну как видите, таких СУБД — более одной. Когда эту историю рассказал опытным бойцам с той СУБД (не связанным с нашей той ситуацией), то они только плечами пожали — типа это не неизвестный баг, это известная фича. Надо тщательно и регулярно поддерживать запас свободного места и иметь свежие бэкапы, если вдруг это не помогло.
(если действительно так интересно — пишите в личку)
(если действительно так интересно — пишите в личку)
/ухмыляясь
Реальность — она вообще бредовей любой выдумки.
Вот это вот, например: http://kris-reid.livejournal.com/150232.html
Ну и маленький эпизод оттуда:
«вспомнилось: «Сидит Слава Логинов, пишет сельскохозяйственную фантастику. Мучается творчеством. Рядом сидит Женя Лукин. Логинов задумывается, отрываеться от работы и говорит...:
— У меня тут в рассказе есть один тракторист, который постоянно по пьянке трактора в речке топит. Hикак не могу решить, сколько же он их утопил. Два — вроде мало, три — не поверит никто…
— Да — говорит Женя. — Задачка… А на самом деле сколько он их утопил?
Логинов тяжело вздохнул.
— Одиннадцать… „
И обязательно с комментарием lemming_drover ( отсюда ):.»Это апокриф. Я как-то раз спросил Логинова о том трактористе. Так вот, во-первых, не все его трактора утонули, некоторые погибли иной смертью…
Во-вторых, загубленных тракторов было _четырнадцать _!!! «;)
Так что это в жизни может случиться что угодно, а в книгах все должно быть логичным;))“
Реальность — она вообще бредовей любой выдумки.
Вот это вот, например: http://kris-reid.livejournal.com/150232.html
Ну и маленький эпизод оттуда:
«вспомнилось: «Сидит Слава Логинов, пишет сельскохозяйственную фантастику. Мучается творчеством. Рядом сидит Женя Лукин. Логинов задумывается, отрываеться от работы и говорит...:
— У меня тут в рассказе есть один тракторист, который постоянно по пьянке трактора в речке топит. Hикак не могу решить, сколько же он их утопил. Два — вроде мало, три — не поверит никто…
— Да — говорит Женя. — Задачка… А на самом деле сколько он их утопил?
Логинов тяжело вздохнул.
— Одиннадцать… „
И обязательно с комментарием lemming_drover ( отсюда ):.»Это апокриф. Я как-то раз спросил Логинова о том трактористе. Так вот, во-первых, не все его трактора утонули, некоторые погибли иной смертью…
Во-вторых, загубленных тракторов было _четырнадцать _!!! «;)
Так что это в жизни может случиться что угодно, а в книгах все должно быть логичным;))“
Еще можно перепутать консоли и удалить постгрес в дебиане через --purge, хорошо что была реплика в стандалоне
Да уж, по возможности бегите из компаний, где у джуниоров есть доступ на удаление продакшн-баз. Это значит, что там все плохо, никто ничего не понимает, а руководить вами будут, по всей видимости, такие же джуниоры, которые в какой-то момент посчитали себя сеньорами-помидорами.
Если у джуниоров есть доступ к продакшену, то, на самом деле, два варианта. Либо в компании все очень плохо, либо, наоборот, все очень хорошо — все зарезервировано и автоматизировано так, что ничего страшного не случится.
Ну, тоже мнение. Но, лично я считаю, что любой доступ должен быть жестко лимитирован и разграничен. А, если он необходим, то также жестко аргументирован. Вопрос — зачем джуниору доступ в продакшн? В любой здоровой (от слово здоровье) компании сиди и разрабатывай локально у себя на машине. Потом деплой в тестовую среду. Как только прошли тесты, запрашивай деплой в QA, и далее по цепочке. Никаких доступов в продакшн, кроме лимитированного числа людей ни у кого не должно быть.
Вопрос — зачем джуниору доступ в продакшн?
Например, расследовать инциденты с прода или баги, воспроизводящиеся только на проде.
Тогда вполне разумно дать, например, ридонли доступ.
Это, опять же, говорит о совершенно дурной архитектуре распределения прав. Запрашивай базу к себе на локальную машину и расследуй, что там нужно расследовать.
Это помимо того, что сомневаюсь в компетенции джуниоров вообще что-то расследовать на продакшне (хотя джуниор джуниору рознь, конечно). Меня просто дико коробит связь «джуниор-продакшн», при любой аргументации.
Это помимо того, что сомневаюсь в компетенции джуниоров вообще что-то расследовать на продакшне (хотя джуниор джуниору рознь, конечно). Меня просто дико коробит связь «джуниор-продакшн», при любой аргументации.
Пример: есть реплика БД, которая используется для отчетов или еще каких-то некритичных процессов, которую нам не жалко даже положить в случае чего. БД размером 100500 мб. Почему бы не дать к ней доступ на чтение для разработчиков (в том числе джуниоров, потому что им тоже надо на чем-то учиться)? Чем лучше выкачивать БД каждый раз локально, особенно если нужно проверять данные несколько раз (до и после какой-то операции)?
Некоторые баги воспроизводятся только при реальной нагрузке, эмулятор которой еще никто не писал, а баг ловить надо сейчас. На текущей работе, когда я только устроился несколько лет назад, очень жутко было осматриваться и обживаться на прод-сервере с боевой базой. Но деваться было некуда и спустя время стало понятно, что не от хорошей жизни оно так устроено, а как компромисс между затратами и эффективностью
Да не вопрос, можно миллиард причин придумать, почему что-то должно делаться на продакшне, о чем разговор-то. Моя позиция — нужно максимально лимитировать доступ к продакшну. Так можно дорассуждаться и до того, что нафик QA и тестовые окружения, ибо на продакшне все удобнее делать и быстрее, чего уж там дамбы гонять туда-сюда.
Я же не голосую за всеобщую работу на проде и без QA. Просто есть ситуации и состояния бизнеса, когда приходится джуна пускать в огород. В моем случае, правда, прочитали 10 лекций, 5 раз напугали и 1 раз предупредили: "нет однозначного понимания — Enter не трогать"
Я вашу позицию услышал, но соверешнно не согласен. В моем понимании, единственное, почему что-то делается непосредственно на продакшне, это лень делать что-то на тестовом сервере. Вот нельзя на продакшне ничего делать, кроме деплоя и все тут — это моя религия. Ладно, останемся при своих мнениях. В конце концов, возможно у нас разное представление размеров продакшна.
Указан же джуниор девелопер, а не L3 саппорт / QA / бизнес аналитик
Инциденты непосредственно на продакшене в первый день работы джуниор девелопером никто не расследует.
Инциденты непосредственно на продакшене в первый день работы джуниор девелопером никто не расследует.
Вопрос был такой:
При чем тут первый день? Или во второй день он уже не джуниор?
В компаниях, которых я работал и работаю, так повелось, что баги исправляют разработчики, а не L3 саппорт / QA / бизнес аналитик (если они вообще есть в компании).
зачем джуниору доступ в продакшн?
При чем тут первый день? Или во второй день он уже не джуниор?
В компаниях, которых я работал и работаю, так повелось, что баги исправляют разработчики, а не L3 саппорт / QA / бизнес аналитик (если они вообще есть в компании).
По статье — человек даже свою рабочую машину еще не настроил, а доступ к продакшену валяется налево направо, причем на продакшене оказывается такая важная информация, что собираются юристов привлекать.
Если данные такие важные — то доступ должен быть соответственным.
Только пришедший джуниор же, еще хорошо если просто разбирается с языком программирования и технологиями, но с разрабатываемым продуктом он не знаком, и инвестигировать проблемы, не зная как работает проект — он не может по определению.
Если данные такие важные — то доступ должен быть соответственным.
Только пришедший джуниор же, еще хорошо если просто разбирается с языком программирования и технологиями, но с разрабатываемым продуктом он не знаком, и инвестигировать проблемы, не зная как работает проект — он не может по определению.
Со всем согласен, но мой ответ был на конкретное заявление:
И не относится к случаю в статье.
Вопрос — зачем джуниору доступ в продакшн? В любой здоровой (от слово здоровье) компании сиди и разрабатывай локально у себя на машине.
И не относится к случаю в статье.
В некоторых компаниях важность данных определяется исключительно по их утере, к сожалению.
У netflix-а есть Chaos Monkeys — специально, чтобы все ломалось регулярно, а система выдерживала, если не выдерживает — делают так, чтобы выдерживала.
Чем джуниор не Chaos Monkey? ;)
Если есть доступы на изменение данных это уже плохо. У вас какой то парадокс получается.)
Но даже если предположить что все легко восстановимо, то за чем это? К тому же случайные небольшие изменения можно не заметить, и как вы их потом будите отлавливать и фиксить не понятно, а они будут втихую портить кому-то жизнь ухудшая качестве продукта.
Вы забываете что это не у него был доступ, а у любого кто может почитать доки. У секретарши, например. То есть дела там еще хуже.
Довольно очевидный вопрос. Джуниор ни в чём не виноват — он по определению не должен иметь доступ к продуктовой базе. Более того, желательно, чтобы у него даже доступа в сеть с продуктовой средой не было. Так что к нему вообще никаких вопросов.
Ответственный за бэкапы — да, облажался. Но это со всеми бывает. Дорогостоящее обучение, да. Выговор, но не более.
А технический директор — просто редкостно некомпетентный идиот, раз он сделал такие выводы. И на своём месте принесёт больше вреда, чем пользы. Так что в расход без сожалений.
Я не силен в юруспруденции США, но мне кажется в тамошнем современном мире этот джуниор, при желании, вообще мог бы подать в суд на эту контору и взыскать с них еще и компенсацию за стресс и моральные издержки в виде потери доверия к профессии и профессиональной области, например.
Так может еще и подаст. К искам, особенно там, надо хорошо готовиться.
Нет, он ничего не получит. Но вот судить его тоже бесполезно.
Ну это если он наймёт более дорогого юриста чем контора.
Человек ни в чем не виноват, он по инструкции выполнил задачу. А вешать надо того, кто допустил наличие боевых реквизитов в таких инструкциях.
Да вообще все девелоперы максимум должны иметь только доступ для чтения.
В случае если в базу все-таки надо влезть, для девелоперов должны быть специальные учетные записи(breakglass account), пароли к которым генерируются когда этот доступ нужен. Пароль действителен в течении нескольких часов.
В случае если в базу все-таки надо влезть, для девелоперов должны быть специальные учетные записи(breakglass account), пароли к которым генерируются когда этот доступ нужен. Пароль действителен в течении нескольких часов.
UFO just landed and posted this here
«Ответственный за бэкапы — да, облажался. Но это со всеми бывает. Дорогостоящее обучение, да. Выговор, но не более.»
То есть бэкапы не работают, а он просто немного облажался?
Отсюда с дивана конечно картина целиком не видна, но просто наличие каких-то там файлов с расширением .bkp, .rar или .rman еще не означает, что это именно бэкапы, и что в них хранится именно то, что нужно для восстановления, так что выговор — это недостаточно.
То есть бэкапы не работают, а он просто немного облажался?
Отсюда с дивана конечно картина целиком не видна, но просто наличие каких-то там файлов с расширением .bkp, .rar или .rman еще не означает, что это именно бэкапы, и что в них хранится именно то, что нужно для восстановления, так что выговор — это недостаточно.
Самое печальное, что парню теперь будет тяжеловато устроится, хотя по факту он реально не причем.
Да нет, конечно. Любое интервью это возможность. Если он будет рассказывать об этом кейсе как о негативном опыте, который приобрел — это только плюс. Лично я бы точно не умалчивал, будь я на месте этого джуниора. Ибо это еще был бы и маркер, чтобы понять, в какую контору я устраиваюсь — любой профессиональный в области наниматель поймет, что вина 100% лежала на конторе и CTO.
Так он джуниор. Они редко могут выбирать, где работать.
UFO just landed and posted this here
Так из истории вроде складывается впечатление, что он уже и стажировки какие-то проходил. А опыт он и есть опыт, все таки не чисты лист после универа.
Стажировка могла проходить в нормальной компании, где пароли от продакшена просто так не валяются =)
И вообще, приходите вы в новую компанию — откуда вы знаете, что на srvxp1 находится продакшен? Вам инструкцию же дали. Тут любого уровня специалист мог бы промахнуться.
И вообще, приходите вы в новую компанию — откуда вы знаете, что на srvxp1 находится продакшен? Вам инструкцию же дали. Тут любого уровня специалист мог бы промахнуться.
Поэтому вдвойне хорошо, когда под боевую базу и хостнейм «говорящий», и само название базы. Вроде somename-sql-prod/production. Дополнительный шанс того, что человек лишний раз задумается, а стоит ли туда что-то лить.
Нет, это я про то, что он не зеленый новичок с 0 опытом и вдруг на улице с таким фейлом, а имеет и положительные строчки в резюме. Поэтому думаю с поиском новой работы будет легче :)
Ну, в США всё довольно формализовано, прежнему руководителю позвонят в 95% случаев, а тот не слишком похвалит нашего джуна.
Может, на фоне шумихи вокруг этой истории ему кто-нибудь предложит работу.
Самое печальное, что парню теперь будет тяжеловато устроится, хотя по факту он реально не причем.Тестером пойти, оторвут с руками:)
И на самом деле это самый обычный косяк джуниора — он случайно взял не те данные, да, бывает, поэтому он и джуниор, все его действия даже при вываливании в дев должны проверяться.
Реально накосячили те, кто а) прописал продакшен пароли в инструкцию б) дал продакшен пароли джуниору
Докапываться до джуниора в данном случае это все равно что уборщицу на атомной станции наказывать за расплавившиеся стержни, потому что она вставила свою карточку доступа не в тот терминал.
Я знаю одного первоклассного руководителя над тимлидами, который давным-давно в первые дни своей работы нанес ущерб на десятки тысяч уе. CTO был достаточно умен, чтобы от высшего руководства потребовать «не увольнять новичка, в обучение которого мы только что вложили несколько миллионов».
указанные там значения — от базы данных в production (не знаю, почему они задокументированы в инструкции по настройке dev-окружения)
Ну, собсна, а чего они хотели?) Согласен с комментаторами выше, тех.дир. тут больше виноват. Парня жаль, конечно.
Junior не виноват в том, что слишком тщательно подошел к выполнению инструкции, и в результате легкого переусердствования выступил очень крутым бета-тестером систем компании :) Уволили его однозначно дураки и скорее всего от того, что не знали куда выместить злобу на самих себя. Пацан прошел бы хорошую подготовку при восстановлении удаленного и скорее всего стал бы одним из преданных сотрудников компании.
Дураки-с ©
Дураки-с ©
Тех. директор на то и нужен, чтобы контролировать работу сотрудников тех. отдела. В частности, написание документации, работу бэкапов и обучение джуниоров. Я не говорю, что именно он должен заниматься всем этим, но как минимум контролировать своих же работников.
Разработчика, конечно же, нужно уволить — зачем компании такой невезучий сотрудник, который в первый же день сломал всё? :)
Технического директора увольнять не следует — кому-то же надо всё восстанавливать, да и обучение нового потребует времени и денег, но ущерб с него надо взыскать, весь или частично.
Ответственного за бэкапы наказать в соответствии со степенью ответственности — если это какой-то рядовой сотрудник, то можно премии лишить там, но увольнять-то за что? Увольнять если, то его начальника, который не озаботился проверкой бэкапов.
Технического директора увольнять не следует — кому-то же надо всё восстанавливать, да и обучение нового потребует времени и денег, но ущерб с него надо взыскать, весь или частично.
Ответственного за бэкапы наказать в соответствии со степенью ответственности — если это какой-то рядовой сотрудник, то можно премии лишить там, но увольнять-то за что? Увольнять если, то его начальника, который не озаботился проверкой бэкапов.
Сотрудник который может сломать всё в первый же день — очень ценный сотрудник. Указывает на потенциальные проблемы.
Кто и зачем будет обучать технического директора? Это c-level должность.
Сотрудник который может сломать всё в первый же день — очень ценный сотрудник. Указывает на потенциальные проблемы.Там смайлик был, но многие этого не заметили. Боюсь, что следующий комментарий я смогу оставить только через час :)
Это c-level должность.Люди на c-level-должности изначально знают все бизнес-процессы, системный ландшафт и IT-процессы во всех компаниях или способны мгновенно вступить в должность и ознакомиться со всей структурой компании?
есть вариант уволить двоих, и директора, и отв. за бэкапы?
Джуниора перевести на должность бета-тестера, технического директора — на должность джуниора, ответственного за бекапы — дать в пользование новому джуниору на сутки: )
UFO just landed and posted this here
Вероятно, их нет. И даже админов (настоящих админов), вероятно, тоже нет.
Тут есть апдейт от автора
«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).»
Безопасников видимо совсем нет, раз уволенный (или недопринятый) джуниор в первый день работы смог вдобавок свободно унести корпоративный ноутбук с работы =)
«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).»
Безопасников видимо совсем нет, раз уволенный (или недопринятый) джуниор в первый день работы смог вдобавок свободно унести корпоративный ноутбук с работы =)
Тут не особо давно проскакивали посты о том, что злоумышленники насканили инстансов монги с террабайтами продакшн данных, не защищённых паролем, и зашифровали/удалили. Что уж удивляться, что у кого-то пароли от продакшена в инструкции напечатаны.
Ему судиться надо. Народ и правда на его стороне.
Вот только денег на это у безработного джуна сразу после универа (наверняка висит студенчесая ссуда) скорее всего нет. Если только всем реддитом ему скидываться.
Я думаю, лучше реддитом скинуться на адвоката, чтобы засудить компанию, которая предоставила нелепую инструкцию а теперь собирается с юристами предъявлять претензии (я в принципе надеюсь, что юристы достаточно вменяемые, чтобы понять что тут не так и на подобное не пойдут)
Я практически уверен, что выиграть подобное дело на стороне джуниор-разработчика будет не проблема, зато огласка такого дела возможно заставит подобных тех.директоров подумать что не везде можно прикрыться подчиненными.
Я практически уверен, что выиграть подобное дело на стороне джуниор-разработчика будет не проблема, зато огласка такого дела возможно заставит подобных тех.директоров подумать что не везде можно прикрыться подчиненными.
А зачем ему судиться? пока что на него никто в суд не подает, а его права вроде никто и не нарушил.
«Покинуть работу и больше не возвращаться» — похоже на увольнение.
Учитывая то, что по факту джун совершил совершенно рядовой косяк, увольнение за это скорее всего оверкилл (хотя хз конечно что у них там в контрактах), поэтому можно судиться за восстановление на работе как минимум.
Учитывая то, что по факту джун совершил совершенно рядовой косяк, увольнение за это скорее всего оверкилл (хотя хз конечно что у них там в контрактах), поэтому можно судиться за восстановление на работе как минимум.
А смысл? Компания, судя по последствиям, так и так банкрот :)
UFO just landed and posted this here
Не цацкаются в том смысле, что в договоре могут прописать что попало.
Но за необоснованное увольнение вздрючат только так, а тут пахнет как раз этим вариантом.
Но за необоснованное увольнение вздрючат только так, а тут пахнет как раз этим вариантом.
Если уволишь 5 негробаб подряд, при этом наберешь на их место пять белых мужиков. Иначе — уже лет 10 никого не волнуют твои расовые и половые особенности.
Ну это тоже не просто так. Как раз чуть больше десяти лет назад в новостях пробегало, как два мужика отсудили по паре миллионов у Форда (ЕМНИП) за то, что их дискриминировали по рассово-полово-сексуально-возрастному признаку: они доказали в суде, что их уволили потому, что они были единственными в отделе гетеросексуальными белыми мужчинами от 30 до 40 лет.
Я помню передачу, как женщина отсудила себе обратно работу бармена, когда ее уволили из-за того, что она растолстела и более не привлекательна для клиентов. Все дело в том, захотят ли уволенные судиться или найдут все таки работу по силам.
она растолстела и более не привлекательна для клиентов
Очевидная потеря квалификации же.
Есть некоторое лицемерие в том, чтобы сначала запрещать компаниям указывать реальные требования в должностной инструкции и вакансии (предположим: «стройная, внешне привлекательная по оценке компании молодая женщина»), а потом судами навязывать неэффективного работника, так как формальных оснований в должностной нет.
в России есть испытательный срок, на то он и придуман, чтобы разойтись с сотрудником по упрощённой процедуре.
Вряд ли он захочет там работать.
На мой взгляд виноват тот, кто писал документацию. И тот кто ее принимал. Обоих отшлёпать, джуна зря почикали.
Да с тестами есть такой опасный нюанс, но всё же оставлять удалёный доступ к прод. бд такое себе ) Наверное это их первый случай, у меня на локалке было подобное где не страшно.
Опишу свой случай. Сам устроился на мою первую практику в универе "кодить" особо было нечего и мне дали отремонтировать камеру дорогущую, и запитать через (стабилизатор я так понял) и подключить к серверу. Показал директору он всё проверил, сказал "красавчик после обеда вместе доделаем".
И знаете что было после обеда ребята? Серверная горела! Матерясь директор повыдёргивал питание и потушили всё дело, благо только сетевой фильтр успел больше всех пострадать (но огонь был, хоть и немного). Директор сказал, что это наша вместе вина, выдал мне 1500р. я пошёл купил новый стабилизатор и потом ещё много с ним дел вместе переделывали и вообще крутой мужик оказался )
Мораль такова, что старший товарищ всегда отвечает. И да, не доверяйте предохранителям иногда они просто не работают и техника уже горит !
В свой первый день работы лаборантом в колледже я взорвал пару кандеев на блоке питания (дёрнул на включеном БП переключатель с 220в на 110в) в момент лекции, реакция руководителя была прекрасна —
А так взрываются кондёры. А еще дым от них вреден для здоровья, потому закачиваем лекциюНе выговоров, ни доносов, ни прессования со стороны коллег, а только грамотный подзатыльник :)
Предохранители — это да… В середине 90-х… Прихожу как-то зимой на одну из своих работ (эникеил в 5 или 7 конторах помимо «основного» места работы)… Чувствую — запах расплавленного пластика… Начинаю искать источник запаха. Нахожу. Пилот. В пилот включен компьютер, лазерный принтер на котором распечатывают какие-то бумаги (пошла вторая пачка за тот день), два калорифера по 2.2 киловатта… Холодно же! А до розеток тянуть калориферы далеко… Пилот стекал на ковролин расплавленным пластиком. 10-амперный плавкий предохранитель и автомат в распредщите героически держались!
Копия прода должна лежать в виде артефакта в jenkins, если уж она так часто снимается для тестирования.
Доступ к подсистемам прода — только через CI/CD. И проблемы бы не существовало.
Бекапы шрёдингера — это классика :-)
Доступ к подсистемам прода — только через CI/CD. И проблемы бы не существовало.
Бекапы шрёдингера — это классика :-)
Так он не снимал копию прода для тестирования. Он как раз залил на прод данные «артефакта».
Прод в виде артифакта дженкинса? Базу вообще не должна лежать в артифактах, только код.
А если уж и хранить базу то как минимум система Артифактори.
А если уж и хранить базу то как минимум система Артифактори.
Доступ к подсистемам прода — только через CI/CD чтоб значит не случайно вручную сломать один сервер, а автоматизированно и сразу все!
Джун выступил лишь «лакмусовой бумажкой», что в компании не все тех.процессы настроены должным образом. Нести ответственность должен тот, кто настраивает тех.процессы в компании и это далеко не джуниор.
Зона ответственности по настройке тех.процессов лежит на тех.дире! Не хочет этим заниматься, то пусть уступит более компетентному товарищу. Это он был поинтересоваться у подчиненных:
* настроен ли процесс бэкапа?
* Как часто делается бэкап?
* Проверена ли процедура восстановления?
* Сможет ли кто-то еще восстановить из бэкапа не считая его создавшего?
* Описана ли процедура по созданию\восстановлению из бэкапа?
Это минимальный набор того, что он должен был взять под свой контроль.
Если кого и увольнять в этой истории, то только тех.дира!
Зона ответственности по настройке тех.процессов лежит на тех.дире! Не хочет этим заниматься, то пусть уступит более компетентному товарищу. Это он был поинтересоваться у подчиненных:
* настроен ли процесс бэкапа?
* Как часто делается бэкап?
* Проверена ли процедура восстановления?
* Сможет ли кто-то еще восстановить из бэкапа не считая его создавшего?
* Описана ли процедура по созданию\восстановлению из бэкапа?
Это минимальный набор того, что он должен был взять под свой контроль.
Если кого и увольнять в этой истории, то только тех.дира!
На мой взгляд, в вариантах ответа на вопрос кого увольнять в такой ситуации не хватает эйчаров или кто там занимается приёмом на работу.
Это ж идеальный тестировщик! С первого раза, в первый же день найти даже не уязвимость, а дырищу в разработке! Талант, не побоюсь этого слова. Пропустить такое дарование надо постараться...
Автор этой истории, кстати, пишет, что связаться с HR'ом ему даже не дали: «I haven't heard from HR, or anything and i am panicking to high heavens». Т.е. CTO психанул и решил всё, минуя этого самого HR.
Мне лично ещё сильно не хватает возможности отметить к увольнению и СТО и ответственного за бэкапы, ибо виноваты они оба одновременно. СТО — за то, что допустил данные с продакшена в тестовом примере, а бэкапер — за то, что бэкапы не работали.
Уморили, я думал на прошлой моей работе были абсолютно ленивые люди, но как оказалось это были ещё цветочки. Мне вообще хотелось бы посмотреть на че? лове? ка который додумался реальные доступы вписать.
Написали скрипт судного дня и дали его джуниору.
Написали скрипт судного дня и дали его джуниору.
Отличный вариант логической бомбы, я вполне допуcкаю, что инструкцию написал обиженный админ.
Чаще бывает все ироничнее. К примеру из моего опыта. Небрежность аутсорсинга, и невнимательность принимающих.
Приняли инструкцию по настройке прод и дев сред. Но потом возникла потребность в поднятии тестовой среды. Поднимали ее на основе дев среды. Но там была опечатка. И данные (при миграции) лились в прод. Благо это были всего на всего справочники.
Приняли инструкцию по настройке прод и дев сред. Но потом возникла потребность в поднятии тестовой среды. Поднимали ее на основе дев среды. Но там была опечатка. И данные (при миграции) лились в прод. Благо это были всего на всего справочники.
Пришел человек в контору и сразу доступ к продакшену? (у него не должно быть прав на нее)
что за бред
Бакапы должны делаться ежедневно и ежедневно восстанавливаться в копию рабочей базы, так называемая копия вчерашнего дня.
сложно судить возможно ли у них это.
что за бред
Бакапы должны делаться ежедневно и ежедневно восстанавливаться в копию рабочей базы, так называемая копия вчерашнего дня.
сложно судить возможно ли у них это.
Джуна то за что?
Человек наверняка делал то о чем его просили.
Очень много вопросов возникает…
1. Почему у джуна доступы к боевой среде. Ее обычно берегут оберегают всеми способами.
2. То что в инструкции не ДЕВ, не ново… Такое иногда бывает. Камень нужно кинуть в того кто ставил задачу, а не в исполнителя. От куда ему знать было.
Человек наверняка делал то о чем его просили.
Очень много вопросов возникает…
1. Почему у джуна доступы к боевой среде. Ее обычно берегут оберегают всеми способами.
2. То что в инструкции не ДЕВ, не ново… Такое иногда бывает. Камень нужно кинуть в того кто ставил задачу, а не в исполнителя. От куда ему знать было.
1.Какого черта данные подключения к продакшн базе были в инструкции?
Они должны храниться зашифрованноми и доступ к ним сугубо согласно политике ИБ компании.
2.Какого черта с IP адреса джуниора вообще имеется доступ к продакшн базе?
Прод база даже пинговаться не должна.
3.Почему не изолирована команда DROP DATABASE?
Они должны храниться зашифрованноми и доступ к ним сугубо согласно политике ИБ компании.
2.Какого черта с IP адреса джуниора вообще имеется доступ к продакшн базе?
Прод база даже пинговаться не должна.
3.Почему не изолирована команда DROP DATABASE?
А вообще делать зеркало живой базы — задача никак не Разраба, хоть где, это задача админа. Так как ответственность за такие косяки будет на нём и только на нём.
Ну а в данной ситуации вина, бэкапера, так как бекапов не было и они не восстанавливаются. Делать разностные бэкапы никто не мешает, хоть каждый час… Правда, если место позволяет. Другое дело. Что человека уволили за то, что он обнаружил(обнажил) дыру в безопастности, и протестировал систему бэкапов на вшивость. QA — минимум, плюс премия за квартал досрочно в двукратном размере.
Директора лишить 30% гонорара, и обязать работать в ручном режиме для восстановления, а в помощь ему ответственных за бэкапов.
Зачем кого-то увольнять… Да потеря данных, да важная информация. Но урок полезный раз. Убытки, два… Зато системы NAS и тому подобное для всех вариниантов бэкапов будут. И ещё 100500 раз переспросят относительно того, что сделались у нас резервные?
Ну а в данной ситуации вина, бэкапера, так как бекапов не было и они не восстанавливаются. Делать разностные бэкапы никто не мешает, хоть каждый час… Правда, если место позволяет. Другое дело. Что человека уволили за то, что он обнаружил(обнажил) дыру в безопастности, и протестировал систему бэкапов на вшивость. QA — минимум, плюс премия за квартал досрочно в двукратном размере.
Директора лишить 30% гонорара, и обязать работать в ручном режиме для восстановления, а в помощь ему ответственных за бэкапов.
Зачем кого-то увольнять… Да потеря данных, да важная информация. Но урок полезный раз. Убытки, два… Зато системы NAS и тому подобное для всех вариниантов бэкапов будут. И ещё 100500 раз переспросят относительно того, что сделались у нас резервные?
автор жжёт!!!
А что не так в статье? Момент достаточно распространенный. Когда прикрываясь маленьким человеком руководство сохраняет за собой места. В таких командах все ка правило на иголках. От части, надеюсь что автор статьи найдет себе хорошую команду. В которой ему не просто дадут бумажку и скажут делай. А как минимум уточнят все ли он понял… Так как в первый же день. Не представляя себе архитектуры…
Парню повезло, я считаю. Он избежал карьеры в коллективе мудаков и сохранил свой ум от практик принятых в этом коллективе.
- Доступ к production среде без VPN'a или общий доступ и к dev среде и к production? Раздели это!
- Учетная запись с доступом для к БД у разработчика? И не важно в инструкции она или где. Не должно быть доступа к БД вообще. Автоматизируй это!
Уволить нужно:
— CTO (составил потенциально опасную / недостаточно понятную документацию )
— team lead (не добавил «защиту» от дурака, которая не позволила бы выполнить потенциально опасные процедуры на production instance, не провел достаточный инструктаж / не проконтролировал как новичок осуществляет local deployment приложения)
— DevOps (не обеспечил своевременное резервирование системы, оставил возможность коннекта к продакшн базе с машины любого дева)
— CTO (составил потенциально опасную / недостаточно понятную документацию )
— team lead (не добавил «защиту» от дурака, которая не позволила бы выполнить потенциально опасные процедуры на production instance, не провел достаточный инструктаж / не проконтролировал как новичок осуществляет local deployment приложения)
— DevOps (не обеспечил своевременное резервирование системы, оставил возможность коннекта к продакшн базе с машины любого дева)
Может, никого не нужно увольнять, но сделать выводы и исправить уязвимость? Или нет?
ну как минимум выговор / штраф и чтобы сделали выводы
ну а вообще согласно здравому смыслу админ который допустил доступ к прод базе откуда угодно своей должности не заслуживает
это как пожарник который с попкорном наблюдает за горящим домом и ничего не делает
или переговорщик с террористами который говорит «убивайте хоть всех мне все равно»
ну а вообще согласно здравому смыслу админ который допустил доступ к прод базе откуда угодно своей должности не заслуживает
это как пожарник который с попкорном наблюдает за горящим домом и ничего не делает
или переговорщик с террористами который говорит «убивайте хоть всех мне все равно»
Организации бывают разные. И у них есть определенный образ жизни. Когда человека могут просто принести в жертву корпоративным принципам
Стартапы такие стартапы. Количество классических проколов (я бы сказал канонических примеров как делать не надо) просто зашкаливает. Еще удивительно, что этот дятел, рушащий цивилизацию джуниор-убийца целого бизнеса так долго не мог до них долететь… Аж с 2013 года.
Надо пойти проверить бэкапы…
UFO just landed and posted this here
Классика. Начинал карьеру во франче 1С, студентом еще.
Еще 7.7 была жива и относительно популярна. Пришел, написал какую-то обработку, все работает.
Только вышел из кабинета, выбегает бухгалтер и грозно просит назад, потому что «все в номенклатуре сломалось».
Оказалось, что она просто случайно нажала кнопку «Отключить иерархический просмотр» (или как там) и, видимо, сделала это впервые в жизни, поэтому сильно испугалась, увидев, что папочек больше нет. В итоге, показал как вернуть все обратно, но потом через другого специалиста попросили, чтоб я туда больше не приезжал, хотя обработка работала нормально.
Еще 7.7 была жива и относительно популярна. Пришел, написал какую-то обработку, все работает.
Только вышел из кабинета, выбегает бухгалтер и грозно просит назад, потому что «все в номенклатуре сломалось».
Оказалось, что она просто случайно нажала кнопку «Отключить иерархический просмотр» (или как там) и, видимо, сделала это впервые в жизни, поэтому сильно испугалась, увидев, что папочек больше нет. В итоге, показал как вернуть все обратно, но потом через другого специалиста попросили, чтоб я туда больше не приезжал, хотя обработка работала нормально.
Бухгалтера они такие :)
Они же бухгалтерский учёт учили 5 лет. Целых 5 лет Карл!!!
Они же бухгалтерский учёт учили 5 лет. Целых 5 лет Карл!!!
Я хоть и являюсь классовым врагом бухгалтеров, но все же ваш сарказм не уместен. Действительно квалифицированный и хороший бухгалтер на важной должности в крупной компании — это постоянное изучение нового законодательства, судебных и административных практик. Как в ИТ работники отличаются от эникейщиков до топовых программистов и администраторов, так и в бухгалтерии есть операторы по вводу первички и главбухи организовывающие учетную политику холдинга с десятками тысячами сотрудников.
Понимаете какая история. Эффект Даннинга — Крюгера в случае с бухгалтерами почему-то выражен особенно остро. То есть вот те самые «квалифицированные и хорошие бухгалтера на важной должности в крупной компании» никогда не пытаются строить из себя невесть что. Они хорошо знают цену и себе и тем, кто к ним приходит компьютеры чинить.
А больше всего гонору — это как раз у тех, которые 5 лет отсидели и всё благополучно забыли, работают, фактически, операторами ЭВМ, понятия не имеют ни о компьютерах, ни о, собственно, бухгалетрии (всё что они умеют — вводить данные в формы, разработанные кем-то другим), но при этом «дуют щёки» невероятно…
А больше всего гонору — это как раз у тех, которые 5 лет отсидели и всё благополучно забыли, работают, фактически, операторами ЭВМ, понятия не имеют ни о компьютерах, ни о, собственно, бухгалетрии (всё что они умеют — вводить данные в формы, разработанные кем-то другим), но при этом «дуют щёки» невероятно…
А сарказма и нет. Я имел в виду что объём знаний по теме стандартного бухгалтерского учёта помещается в одну небольшую книжку.
Я видел в книжном магазине учебник по бухучёту под названием «Бухгалтерский учёт за 7 дней», за 10 дней и за 14 дней. Сам я проходил курсы 3 месяца по два занятия в неделю по 2 часа, хотя можно было просто прочитать учебник за несколько дней, причём в учебнике конечно всё подробнее написано.
Я видел в книжном магазине учебник по бухучёту под названием «Бухгалтерский учёт за 7 дней», за 10 дней и за 14 дней. Сам я проходил курсы 3 месяца по два занятия в неделю по 2 часа, хотя можно было просто прочитать учебник за несколько дней, причём в учебнике конечно всё подробнее написано.
А вот и замечательная демонстрация эффекта Даннинга — Крюгера :)
Я видел книгу «C++ за 21 день». Это о чем-то должно говорить? Чтобы быть бухгалтером уровня главбуха большого холдинга надо знать очень хорошо: ПБУ, НК, частично ГК, частично ТК, хорошо МСФО, следить за многими регулирующими ФЗ, письмами минфина, наголовой и кучей всего остального. И все это с риском уголовной ответственности при косяках с налогами.
Я видел книгу «C++ за 21 день». Это о чем-то должно говорить? Чтобы быть бухгалтером уровня главбуха большого холдинга надо знать очень хорошо: ПБУ, НК, частично ГК, частично ТК, хорошо МСФО, следить за многими регулирующими ФЗ, письмами минфина, наголовой и кучей всего остального. И все это с риском уголовной ответственности при косяках с налогами.
Напомнили про комикс «C++ за 21 день».
Вот он:
Работал я в крупной компании, бухгалтера с подразделений приносили балансы, я их в экселе суммировал, а у главбуха даже компьютера не было, потому что главбух в крупной компании это больше руководящая должность, а не исполнительская (по произведению подсчётов). Я же писал про стандартный бухгалтерский учёт, который легко освоить на начальном уровне за несколько дней, а не 5 лет.
Наверное, я плохо владею терминологией, но что такое «стандартный бухгалтерский учет»? Это там же, где «стандартное администрирование» и «стандартное программирование»?
«стандартный бухгалтерский учет» — это типовые "приход", "расход", которые разносятся типовыми проводками описанными в куче учебников. В принципе многим хватает на начальном этапе или при небольшом обороте...
Ну а потом либо компания растет и выходит за пределы «стандартного бухгалтерского учета» и начинаются "налоговые и бухгалтерские оптимизации" с использованием различных особенностей законодательства и учета, либо компания закрывается...
А, ну, то есть, это как установил винду и подключил принтер — уже администратор, написал макрос в Excel — уже программист.
И такие бухгалтера, и такие администраторы с программистами где-то востребованы. Но какое они имеют отношение к настоящим высококвалифицированным специалистам?
И такие бухгалтера, и такие администраторы с программистами где-то востребованы. Но какое они имеют отношение к настоящим высококвалифицированным специалистам?
Ну теоретически они могут дорасти до высококлассных специалистов… :)
но это маловероятно, т.к. в большинстве случае такие "спецы" не могут учится… любой нестандартный вопрос вводит их в ступор или словесное недержание без смысла… Но понтов у таких бухгалтеров выше крыши…
Я тут пытаюсь вам прозрачно намекнуть, что проблема некомпетенции и эффект Даннинга — Крюгера, это общая проблема, присущая всем профессиям, но вы все равно возвращаетесь к ненавистным вам бухгалтерам, так и не осознав, что своим первых постом вы умалили в том числе и тех специалистов, до уровня которых в своей стезе и вам, и мне, как до Китая пешком. Жаль.
UFO just landed and posted this here
С тем что законодательства море, согласен. Раньше занимался установкой системы «Лига-закон», база на несколько гигабайт, более 400 000 документов. Такой объём текста невозможно даже прочитать за всю жизнь, а тем более за 5 лет. А если учесть что законодательство ещё и меняется постоянно, то то что было выучено в институте всё равно устареет уже во время учёбы. А если учесть что в России с 2018 года вводится МФСО, то…
Я просил и умолял позволить мне как-то помочь реабилитироваться
Его просьбы остаться можно объяснить только его неопытностью. Оттуда нужно бежать роняя тапки, ничему хорошему там не научат. Допустим с бекапами многие грешат, для этого нужно сделать какие то усилия, потратить время, как минимум до первой потери данных, руки могут не дойти ;) Но как можно в инструкции напечатать пароль от production? Это каким нужно быть клоуном, рыжим или белым?
Когда-то очень давно во время командировки на подшефное предприятие (завод) попросили помочь с восстановлением DBF базы 1С 7.7 с рухнувшего сервера.
Было подозрение на то, что начал сыпаться винт (в дальнейшем подтвердилось по индивидуальному снятию SMART-а в обход RAID контроллера).
Так вот, времени было мало, дело было вечером, перед поездом. Несмотря на развал RAID-а БД удалось успешно скопировать. Посоветовал местным админам прогнать тестирование БД средствами самой 1С без исправления (не ТИС).
Прогнали, все ок, засунули БД в другой сервер, взлетели…
А через трое суток прилетает гневный звонок главбуха с того завода — «Зачем вы нам своими советами базу 1С сломали?»
Начали разбираться. Оказалось, что за последние 5 лет местный франч 1С эту БД каждый год усекал, но без компенсации движений по регистрам и бухсчетам. Причем контрольное тестирование БД не проводилось НИ РАЗУ. Хотя в договоре было прописано, что подрядчик несет ответственность за целостность данных в результате проведения обновлений, доработок и прочих манипуляций.
Даже при «чистом» тестировании 7-я 1С-ка в обязательном порядке все же пересчитывает промежуточные итоги. С закономерным результатом.
Ну а заводские бухи три дня стучали данными в базу, пока не заметили что что-то там по остаткам не сходится…
Ругань. Мат. Написание объяснительных. Вызов стороннего известного франча 1С для экспертной оценки.
Наказание невиновных и награждение непричастных. Занавес.
Было подозрение на то, что начал сыпаться винт (в дальнейшем подтвердилось по индивидуальному снятию SMART-а в обход RAID контроллера).
Так вот, времени было мало, дело было вечером, перед поездом. Несмотря на развал RAID-а БД удалось успешно скопировать. Посоветовал местным админам прогнать тестирование БД средствами самой 1С без исправления (не ТИС).
Прогнали, все ок, засунули БД в другой сервер, взлетели…
А через трое суток прилетает гневный звонок главбуха с того завода — «Зачем вы нам своими советами базу 1С сломали?»
Начали разбираться. Оказалось, что за последние 5 лет местный франч 1С эту БД каждый год усекал, но без компенсации движений по регистрам и бухсчетам. Причем контрольное тестирование БД не проводилось НИ РАЗУ. Хотя в договоре было прописано, что подрядчик несет ответственность за целостность данных в результате проведения обновлений, доработок и прочих манипуляций.
Даже при «чистом» тестировании 7-я 1С-ка в обязательном порядке все же пересчитывает промежуточные итоги. С закономерным результатом.
Ну а заводские бухи три дня стучали данными в базу, пока не заметили что что-то там по остаткам не сходится…
Ругань. Мат. Написание объяснительных. Вызов стороннего известного франча 1С для экспертной оценки.
Наказание невиновных и награждение непричастных. Занавес.
- Слишком много ждут от человеческих обезъян, можно сказать что совершение ошибок заложены в них by design;
- Ответ на вопрос «кто действительно виноват» был дан тут:
указанные там значения — от базы данных в production (не знаю, почему они задокументированы в инструкции по настройке dev-окружения)
- Увольнять никого не надо, это бы противоречило пт. 1, а тех. директору надо меньше рефлексировать, глубже изучать истоки проблем и наконец осознать склонность людей к совершению ошибок, пусть книжек там почитает о работе мозга и когнитивных искажениях.
На мой взгляд, у ЛЮБОГО нового разработчика в компании в принципе не должно быть доступа на продакшен. Ни в базу ни в код. Соответственно, ошибка тут в построении IT-инфраструктуры компании, за которую несет ответственность технический директор.
А, еще был старый случай.
Стояла очень кучерявая учетная система, написанная на дельфях и в качестве СУБД пользующая конечно же Firebird.
Система работала почти круглосуточно в режиме онлайн, крутилось куча разных скриптов-роботов для автоматизации ряда операций.
Из-за этого, а также из-за криворукости не то разработчиков системы, не то Firebird-а (подозреваю что там был коллективный «путь к успеху» в этом вопросе), резервное копирование выполнялось каждую ночь скриптом, писанным в системе Automate. Скрипт солидный, в несколько страниц мелкого текста. Рубились/запускались роботы, стопалась/стартовала СУБД и т.д. Automate там был вынужденной мерой, т.к. в целях автоматизации этих процессов требовалось ловить окна и жать в них кнопки.
А каждые выходные из-за дури со сбором мусора в FB 1.5 Classic требовалось сделать т.наз. бекап-роллбек. Иначе база всего за неделю выростала до гигантских размеров (в 2-3 раза от свежеразвернутого с бекапа номинала) и все начинало тормозить. Литература по FB (единственная имеющаяся на русском книжка Хелен Бори) и их офсайт были вычитаны полностью, всякие хитрости типа бекапа со свипом по БД переведенной в однопользовательский режим и попытка подстройки мусорщика — результатов упорно не давали.
Короче полная дичь.
Так вот, в один прекрасный день что-то в мозгах Automate-а помутилось и он пропустил с ошибками ряд команд своего скрипта и развернул из бекапа не последнюю версию, а на сутки ранее. А свежий бекап просто грохнул.
В итоге сутки работы довольно немаленького дистрибьюторского предприятия были потеряны полностью.
По факту были сделаны оргвыводы.
Automate был быстро, решительно выкинут на мороз. А все телодвижения были переписаны чуть более чем полностью на новомодном тогда powershell 2.0. С кучей проверок на каждом этапе, промежуточных резервных копий, логов и прочих уровней безопасности.
Стояла очень кучерявая учетная система, написанная на дельфях и в качестве СУБД пользующая конечно же Firebird.
Система работала почти круглосуточно в режиме онлайн, крутилось куча разных скриптов-роботов для автоматизации ряда операций.
Из-за этого, а также из-за криворукости не то разработчиков системы, не то Firebird-а (подозреваю что там был коллективный «путь к успеху» в этом вопросе), резервное копирование выполнялось каждую ночь скриптом, писанным в системе Automate. Скрипт солидный, в несколько страниц мелкого текста. Рубились/запускались роботы, стопалась/стартовала СУБД и т.д. Automate там был вынужденной мерой, т.к. в целях автоматизации этих процессов требовалось ловить окна и жать в них кнопки.
А каждые выходные из-за дури со сбором мусора в FB 1.5 Classic требовалось сделать т.наз. бекап-роллбек. Иначе база всего за неделю выростала до гигантских размеров (в 2-3 раза от свежеразвернутого с бекапа номинала) и все начинало тормозить. Литература по FB (единственная имеющаяся на русском книжка Хелен Бори) и их офсайт были вычитаны полностью, всякие хитрости типа бекапа со свипом по БД переведенной в однопользовательский режим и попытка подстройки мусорщика — результатов упорно не давали.
Короче полная дичь.
Так вот, в один прекрасный день что-то в мозгах Automate-а помутилось и он пропустил с ошибками ряд команд своего скрипта и развернул из бекапа не последнюю версию, а на сутки ранее. А свежий бекап просто грохнул.
В итоге сутки работы довольно немаленького дистрибьюторского предприятия были потеряны полностью.
По факту были сделаны оргвыводы.
Automate был быстро, решительно выкинут на мороз. А все телодвижения были переписаны чуть более чем полностью на новомодном тогда powershell 2.0. С кучей проверок на каждом этапе, промежуточных резервных копий, логов и прочих уровней безопасности.
Зачем его увольнять? Просто надо перевести на должность тестировщика!
А у меня тоже был случай с инструкцией и PROD, только там в UPDATE были данные живых клиентов, и получились дубли. Рефлекторный копипаст, как правило, может закончиться по разному.
Мне объяснили момент, что в инструкциях не должно быть живых данных ну и необидно поржали.
А по ситуации могло быть такое, что основной показатель искупления FUCKUP-ов — расстрел виновных, директор доложил наверх, что виновные расстреляны и его не ругали)))
В любом случае, парню сплошной профит, будет знать, где лежат эти грабли.
Мне объяснили момент, что в инструкциях не должно быть живых данных ну и необидно поржали.
А по ситуации могло быть такое, что основной показатель искупления FUCKUP-ов — расстрел виновных, директор доложил наверх, что виновные расстреляны и его не ругали)))
В любом случае, парню сплошной профит, будет знать, где лежат эти грабли.
Ну а зачем директору оправдываться за работу через одно место. Видать таких сотрудников нанимают, которым пофиг, есть бэкапы или нет их, и это проявляется во всем.
Будучи разработчиком, причём уже отнюдь не джуном, дёрнул функцию внутренней библиотеки для работы с файлохранилищем, передав ей NULL в качестве аргумента (а должен был, помнится, id файла). В силу «особенностей» реализации библиотеки она восприняла NULL как потребность удалить корень файлопомойки.
Результат — терабайт с лишним удалённой бизнес-информации в 6 утра в субботу, и трёхдневное колдовство с бэкапами.
И огромное спасибо коллегам и руководству, которые с пониманием отнеслись к произошедшему (функция так себя не должна была вести, её в итоге поправили) и всё обошлось без особых последствий.
Так что я этого разработчика очень даже понимаю, да…
Результат — терабайт с лишним удалённой бизнес-информации в 6 утра в субботу, и трёхдневное колдовство с бэкапами.
И огромное спасибо коллегам и руководству, которые с пониманием отнеслись к произошедшему (функция так себя не должна была вести, её в итоге поправили) и всё обошлось без особых последствий.
Так что я этого разработчика очень даже понимаю, да…
Вот это — всем багам баг.
Вставлю и свои 5 копеек. Состою в тестерах в проекте LIF ММО, ждали тестов функции судного часа, все хорошо, перед началом плановая перезагрузка всех серверов, и загрузившись обнаруживаем что все монументы (которые ответственны за область территории, объявленной в собственность) — исчезли! Все постройки на всех серверах стали ничейными и все объекты тоже. При разборе выяснили, что один из глав кланов не делал делегирование на заместителей, а сделал таким же полноправным главой еще одного человека. В итоге функция обрабатывающая эти данные не знала что с этим делать, и как следствие удалила из базы все монументы (через которые и происходит управление). Вот так недочет в одной функции порушил всю базу. Потом бэкапы, восстановление,… эх.
UFO just landed and posted this here
Очень исполнительный джуниор — всё сделал строго по инструкции: что там написано, то и ввёл. Пусть привлекают юристов… флаг им в руки. Юристы и суды работают с документами, документы любят, там эта инструкция будет весьма кстати.
У меня такие факапы случались с 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 --всякие фильтры
и как-то не закомментил вторую строку и запустил на выполнение.
Т.е. всю таблицу проапдейтил (вдруг кто не догадался).
А я пишу наоборот: сначала select и закомменченный update, и ещё строку пустую всегда добавляю после команды. А то когда выделяешь с шифтом несколько строк, начиная с 'update...' будет выделено по where 1=1, но не последний and, а рука уже занесена над F5…
надо так:
begin tran
update…
запускаем, смотрим. Пугаемся. Делаем rollback. Выдыхаем.
begin tran
update…
запускаем, смотрим. Пугаемся. Делаем rollback. Выдыхаем.
Так заботливо делает SSMS то ли Boost то ли Tools (скорее всего он) — в новом окне query уже стоят begin tran и rollback.
А я обхожусь тем же запросом, но он сразу в двух вариантах (один для проверки, второй для действия):
А я обхожусь тем же запросом, но он сразу в двух вариантах (один для проверки, второй для действия):
select*,
--update a set
field=100500
from dbo.objects as a
where id=1;UFO just landed and posted this here
UFO just landed and posted this here
До сих пор вспоминаю как вместо rm ./cache/ -rf ввёл что-то вроде rm ./ и отправил в девнул все гигабайты фотографий с крупного сайта. Вернее отправил то весь вебрут, но скрипты и стили тут же восстановил из репозитория. Потом стал искать бэкапы. Нашёл бэкапы бд, кода и ещё кучу всего. А вот гигабайты фотографий то нигде не бэкапились. Но никто не узнал, что это был я . Даже не знаю почему веб-студия та вскоре обанкротилась и так и не выплатила работникам последнюю зарплату.
Так это был ты???????
Именно из-за такого, при разработке системы где будет много загружаемых файлов, теперь всегда начинаю с продумывания организации бэкапа для этих файлов. Что бы хотя бы ежесуточный дамп диска был у хостера.
У нас коллега на своём компе как-то раз хотел удалить рекурсивно временные файлы с именем ~ и ввёл rm -rf ~. Когда его SSD как-то странно призадумался, до него наконец дошло, но многое успело удалиться.
Джуну премию нужно было выдать. Если б не он неизвестно когда бы еще произошел сбой требующий восстановления, а он бы был рано или поздно. А так возник повод пересмотреть не только бекапы а и все процессы в компании начиная с инструкции по дев окружению… Жаль только что СТО в компании тугой и не понимает этого.
Минимум дважды за свою жизнь видел похожие случаи, оба раза были сделаны выводы об организации процесса но никого не уволили. Кстати, по крайней мере в одном из них тот самый джуниор через пару лет стал вполне адекватным и ценным сотрудником.
Директор наверно и писал эту инструкцию, раз так отреагировал, джиниор молодец, сразу сломал прод, карьера будущего хакера в гору пошла. Его тестером надо брать!
У меня был забавный кейс на работе.
В продакшене вбил
Первым упал Postgres :). Благо была копия виртуалки и по ней восстановил права и все работало как обычно. Но тогда кирпичей отложил знатно. И да, меня за это не уволили и даже не гнали.
В продакшене вбил
chown -R www-data /var /www
Первым упал Postgres :). Благо была копия виртуалки и по ней восстановил права и все работало как обычно. Но тогда кирпичей отложил знатно. И да, меня за это не уволили и даже не гнали.
Помню, я работал с данными таблицы на разных вкладках в Valentina Studio и каким-то чудом я снес основную таблицу на продакшене ближе к концу рабочего дня. От нее зависела работа бизнеса. Благо, у меня осталась выборка из таблицы в неизменном виде на отдельной вкладке, откуда это удалось «достать». Доставал записи построчно (export row as csv), т.к. на тот момент в программе нельзя было сделать экспорт целиком. Вот так, за каких-то 20-30 минут, я руками, с тачпада, откопировал >1500 записей без единой запинки сделав построчный дамп. Хорошо хоть 1.5к, а не пару сотен тысяч. Все обошлось, никто ничего практически не заметил, только посмеялись, когда сам попозже рассказал :)
Тот драйв заставил делать меня бэкапы баз и регулярно, и перед каждым чихом, и проверять их работоспособность. Правда делать бэкапы личных данных я научился, когдапроетерял, т.е. повредились важные документы на съемном носителе (1 файл защищенный AES-ом). Больше про бэкапы, во всех аспектах, я не забывал.
Тот драйв заставил делать меня бэкапы баз и регулярно, и перед каждым чихом, и проверять их работоспособность. Правда делать бэкапы личных данных я научился, когда
Джуниора надо уволить. Тем более за такое и в первый день. Найти джуниора — не проблема. Остальных сложнее.
Очень похожая ситуация на нашу. Для хранения кода мы используем концепцию «clean trunk» (это когда все коммитят в мастер и нет брэнчей). Так вот пришел новый парень, сделал пулл, че-то там покодил пару часов и пушнул назад с ключом --force. Когда мы ему предъявили что он потер код он показал страницу из нашей «онбоардинг» документации где было черным по белому написана инструкция что надо делать именно так. Разумеется все претензии были сняты и доки переписаны.
Как, в итоге, они поднимали базу? Как я вижу, сейчас у них все на месте.
У меня начальник с опытом с 90-х выставил базу 1С наружу (ну чебы бухгалтеры ходили из дома работать) и вот случилось, базу и всю машину зашифровали (было еще до вона край). Вот такие вот спецы бывають… Но его пронесло… отделался испугом (нашли где-то бэкап который когда то кому то оправляли)
Считаю, что никого
Скорее всего сама команда разработки, где, наверное не один человек, виновата. А еще точнее — начальник отдела, человек ответственный за инструкции, человек ответственный за архитектуру, ну и за бекапы. Косячнули все. У нас был похожий случай, потерялся правда всего день работы, зато рестор теперь тщательно тестируется для каждого бекапа автоматом.
А парень мог быть внимательнее, но не был, бывает. Насколько он виноват, это надо знать всю историю не в пересказе, а по секундам. Epic fail команды это не отменяет.
Скорее всего сама команда разработки, где, наверное не один человек, виновата. А еще точнее — начальник отдела, человек ответственный за инструкции, человек ответственный за архитектуру, ну и за бекапы. Косячнули все. У нас был похожий случай, потерялся правда всего день работы, зато рестор теперь тщательно тестируется для каждого бекапа автоматом.
А парень мог быть внимательнее, но не был, бывает. Насколько он виноват, это надо знать всю историю не в пересказе, а по секундам. Epic fail команды это не отменяет.
Два вопроса.
1. Почему доступ к продакшну валяется в почти свободно распространяемых документах?
2. Почему в базу продакшна можно просто взять и подключится из окружения разработчика?
1. Почему доступ к продакшну валяется в почти свободно распространяемых документах?
2. Почему в базу продакшна можно просто взять и подключится из окружения разработчика?
Джун — траблмэйкер. Таких не очень любят в америках и стараются от них избавляться. Уволили чтобы беды не притягивал в дальнейшем.
Вы работаете в америках?
Вопрос. Если не будет джунов. То от куда взять через 30 лет новых спецов?
Ведь джун, фактически ученик. Который работает почти задаром. Но компания его взращивает так, как им нужно. Если просто набирать людей с опытом… Правильно ли это?
Ведь джун, фактически ученик. Который работает почти задаром. Но компания его взращивает так, как им нужно. Если просто набирать людей с опытом… Правильно ли это?
Я не всех джунов имел в виду, а конкретно этого. Просто приходилось очень часто встречаться с новичками, да и не только новичками, с раздутым самомнением, которые боятся задать лишний вопрос, лишь бы не оказаться в дураках. И в итоге с умным видом попадают еще в более дурацкие положения. Может быть этот случай будет ему наукой и на следующей работе он уже будет прежде чем что-то сделать включать мозг и задавать вопросы, а не тупо по инструкции выполнять.
Ребят есть хорошая поговорка:
Рыба гниет с головы.
Обычно когда приходит новый человек, совершаются некоторые действия:
1) Согласование доступов СБ.(В этот момент руководитель высылает описание архитектуры всех сред)
Если СБ не выдавало доступов, то на мой Взгляд Виновата служба безопасности.
Если Руководитель не выслал описание сред, то вина руководителя
Если же человеку все дали, но он решил «показать себя», то что же… Вина однозначно джуна.
2) Вводная — Обычно человека знакомят что используется в компании. И карта проекта. Какие базы где лежат и как к ним стучаться.
Если вводной нету, то опять же вина руководителя. Ну или Тим лида.
Если же Джун ее пропустил. То его.
Эти два пункта статье не описаны. И на мой взгляд это какой то подводный камень.
Рыба гниет с головы.
Обычно когда приходит новый человек, совершаются некоторые действия:
1) Согласование доступов СБ.(В этот момент руководитель высылает описание архитектуры всех сред)
Если СБ не выдавало доступов, то на мой Взгляд Виновата служба безопасности.
Если Руководитель не выслал описание сред, то вина руководителя
Если же человеку все дали, но он решил «показать себя», то что же… Вина однозначно джуна.
2) Вводная — Обычно человека знакомят что используется в компании. И карта проекта. Какие базы где лежат и как к ним стучаться.
Если вводной нету, то опять же вина руководителя. Ну или Тим лида.
Если же Джун ее пропустил. То его.
Эти два пункта статье не описаны. И на мой взгляд это какой то подводный камень.
Ответственного за бекапы надо увольнять.
У меня была похожая история 4 года назад — год назад на гиктаймсе писал комментарий про это.
Скопирую сюда, т.к. по ссылкам обычно ходить лень:
Скопирую сюда, т.к. по ссылкам обычно ходить лень:
Тянет на отдельный пост, но у меня была похожая история три года назад — я убил базу и многомиллионный бизнес почти накрылся. Причем считаю, что идиоты они, а не я — при организации компании как 10+ менеджеров и один программист/админ этого следовало ожидать рано или поздно.
В общем, есть некая баннерная сеть (сейчас проверил — еще жива), а у нее ушел единственный программист — у них полный ахтунг, попросили через знакомых меня помочь (само собой, без договора и всего такого). Начал разбираться — не документировано вообще ни чего, даны только исходники системыи логин-пасс от дедика. Соответственно, моей задачей было именно разобраться и задокументировать что и как для новых программистов.
Поковырял исходники, полез смотреть в бд. Работал ночью, был упорот, перепутал две одинаковые вкладки phpmyadmin и сделал из продакшен-базы тестовую базу. Жопу обнаружил только когда запустил на продакшене mysqldump и понял, что он как-то быстро завершился.
Побежал за бекапами — а их нет. Пишу в скайп старому программисту с вопросом «Куда делаются бекапы?», он ответил, что вообще не парился с этим, они не предусмотрены, и ему вообще плевать.
Понял, насколько случилась жопа, когда у них на утро встал бизнес и мне позвонили и сказали: «Мы знаем, что у тебя есть квартира — продавай и возмещай.»
Мне чудом повезло, что они использовали стороннюю SAAS систему подсчета кликов/лидов, из которой я сумел вытащить данные за последний месяц. Они потеряли бд за несколько лет, но их волновал только последний месяц и от меня отстали.
Я тогда чуть не поседел, после чего решил уйти из веб-разработки (7 лет опыта на стартапах и хайлоаде к тому моменту) и сделать из хобби работу (3д-графика) — нервы целее будут.
Пару месяцев назад тут тоже была веселая история с кастомной рендер-фермой, но это уже другая история и все решилось намного менее нервно. Но теперь я знаю, что в области 3д влететь на стоимость хаты тоже можно (не влетел).
само собой, без договора и всего такого
Мы знаем, что у тебя есть квартира — продавай и возмещай— Ребят, а вы кто такие? Не делал я ничего, да и в компьютерах не шарю, так, примусы починяю…
Можно было как-то так на крайний случай. Возможно, поседеть пришлось бы не «почти», а по настоящему, но квартира бы осталась :)
Она и так осталась, но урок на всю жизнь.
А еще я теперь знаю, зачем у PMA так много тем оформления и цветовых схем — чтобы вкладки не перепутать.
А еще я теперь знаю, зачем у PMA так много тем оформления и цветовых схем — чтобы вкладки не перепутать.
— Ребят, а вы кто такие? Не делал я ничего, да и в компьютерах не шарю, так, примусы починяю…
Как говорится, в России спрашивают не по договорам, а по понятиям. Так что вряд ли помогло бы
А по договору можно было бы повесить все убытки юрика на физика или это чем-то всё таки ограничивается?
Не совсем понял, как связано отсутствие вменяемой документации и вашей ошибки по невнимательности?
Про бэкапы в целом согласен, но с тем условием, что неплохо было бы сначала убедиться, что они есть, а уже потом преступать к работе упоротым ночью ;)
Про бэкапы в целом согласен, но с тем условием, что неплохо было бы сначала убедиться, что они есть, а уже потом преступать к работе упоротым ночью ;)
кого уволить:
1. разработчика. блин, чувак, если ты ЧИТАТЬ не умеешь — тебе не место в профессии
2. ответственного за БД. блин, чувак провафлил фатальную базу. казнить однозначно.
кого пытать:
1. кто инструкцию писал — ну как можно было додуматься в ней настоящие данные от продакшна указать?
2. техдира, как ответственного за провалы всех остальных…
1. разработчика. блин, чувак, если ты ЧИТАТЬ не умеешь — тебе не место в профессии
2. ответственного за БД. блин, чувак провафлил фатальную базу. казнить однозначно.
кого пытать:
1. кто инструкцию писал — ну как можно было додуматься в ней настоящие данные от продакшна указать?
2. техдира, как ответственного за провалы всех остальных…
В комментах 99% вой на тему какая плохая организация в организации и как все кругом виноваты, а стажера, беднягу золотейшего, уволили без премии и даже в зад непоцелованного.
А я вот _лично_ очень хорошо понимаю того чувака, который выгнал к чертям собачьим пакостливого джуна с дырявой кармой, который, как оказалось, не только прод грохнул в первый же день, но и после заслуженного(!) увольнения потащился на реддит ныть «пожалейте меня, поругайте дядек».
Косяк в своей инструкции дядьки, разумеется, поправят и следующих джунов заборчиком огородят. А юношу этого в приличную организацию брать бы не следовало, дабы не полоскаться лишний раз в соцсетях по внутрикорпоративным вопросам.
А я вот _лично_ очень хорошо понимаю того чувака, который выгнал к чертям собачьим пакостливого джуна с дырявой кармой, который, как оказалось, не только прод грохнул в первый же день, но и после заслуженного(!) увольнения потащился на реддит ныть «пожалейте меня, поругайте дядек».
Косяк в своей инструкции дядьки, разумеется, поправят и следующих джунов заборчиком огородят. А юношу этого в приличную организацию брать бы не следовало, дабы не полоскаться лишний раз в соцсетях по внутрикорпоративным вопросам.
То есть, вы предлагаете уволить уборщицу, которая случайно наступила на витуху и оставила без связи несколько офисов по всей стране, ибо карма плохая?
Или всё-таки сетевика, который бросил эту витуху на пол?
Или всё-таки сетевика, который бросил эту витуху на пол?
В общем случае, того, кто делает это систематически.
Если уборщица постоянно находит, что оторвать, а сетевик — что раскидать, при рецидиве после нескольких разъяснительных мероприятий, к сожалению, будут выгнаны на мороз оба.
А если им не повезло втянуть контору в большой убыток единоразово — с большой вероятностью пойдут искать работу тут же, причем, уборщица — с большей, ибо рынок.
Если уборщица постоянно находит, что оторвать, а сетевик — что раскидать, при рецидиве после нескольких разъяснительных мероприятий, к сожалению, будут выгнаны на мороз оба.
А если им не повезло втянуть контору в большой убыток единоразово — с большой вероятностью пойдут искать работу тут же, причем, уборщица — с большей, ибо рынок.
Эпитет "пакостливый" происходить от слова "пакость", что означает намеренное (умышленное) действие. На каком основании вы подозреваете злой умысел в действиях джуна?
И что такое "дырявая карма"? В чем это проявляется? Существуют ли доказательства наличия у людей кармы?
Вот Вы кого-нибудь уволите за дело, а человек, вместо осознания своей ошибки внутри своей светлой головы и позитивных выводов пойдёт страдать по интернетам. Не пакостливый — образец нормы?
Выражение «дырявая карма» применительно к человеку используется для указания на его патологическую неудачливость. Нужно объяснять, в чем это проявляется?
Русский язык богат на образы, это не программа, а Вы — не транслятор, не стоит искать смысл в словах по отдельности.
Выражение «дырявая карма» применительно к человеку используется для указания на его патологическую неудачливость. Нужно объяснять, в чем это проявляется?
Русский язык богат на образы, это не программа, а Вы — не транслятор, не стоит искать смысл в словах по отдельности.
Кто вам сказал, что он "пошел страдать по интернетам" вместо осознания своей ошибки?
Что такое патологическая неудачливость и существуют ли исследования на эту тему?
Человек сам не способен сделать правильный вывод из простой ситуации и просит общественной поддержки, поднимая этот вопрос, очевидно же.
Вероятность того, что суть Ваших вопросов относительно используемой терминологии сводится к необходимости получить в ответе больше сложных терминов и рекурсивно задать вопрос к каждому из них, я оцениваю как высокую, и предлагаю сиё занятие прекратить и вести диалог конструктивно, либо не вести вовсе.
Вероятность того, что суть Ваших вопросов относительно используемой терминологии сводится к необходимости получить в ответе больше сложных терминов и рекурсивно задать вопрос к каждому из них, я оцениваю как высокую, и предлагаю сиё занятие прекратить и вести диалог конструктивно, либо не вести вовсе.
патологическую неудачливость
Одна ошибка — уже патология? Суровые у вас критерии нормальности.
Одно увольнение — тоже совершенно не страшно. Если патологии нет, легко найдёт себе работу в другом месте.
Одни люди более склонны к риску и не видят плохого в том, чтобы ставить дорогие эксперименты на собственном бизнесе, другие склонны менее, и стараются с помощью интуиции, хрустального шара и известной матери снизить потенциальный риск различными способами.
Простого правила тут, разумеется, нет.
Одни люди более склонны к риску и не видят плохого в том, чтобы ставить дорогие эксперименты на собственном бизнесе, другие склонны менее, и стараются с помощью интуиции, хрустального шара и известной матери снизить потенциальный риск различными способами.
Простого правила тут, разумеется, нет.
Одни люди более склонны к риску и не видят плохого в том, чтобы ставить дорогие эксперименты на собственном бизнесе, другие склонны менее, и стараются с помощью интуиции, хрустального шара и известной матери снизить потенциальный риск различными способами.
Так все и говорят, что увольнять надо CTO =) Ведь это он радостно поставил эксперимент на бизнесе, допустив не меньше пяти серьезных ошибок. Не настроить бэкапы, выдать джуну полный доступ к продакшен базе — вот эти действия вполне квалифицируются как «патологическая неудачливость».
Я не оправдываю руководителей. Однако, реалии таковы, что эффективного руководителя найти в разы сложнее, потому уволить его моментально — неверное бизнес-решение. Каждый случай индивидуальный, для решения нужен весь контекст и история отношений.
С джуном таких вопросов нет. Начал работу с удаления прода — подарком будет увольнение без статьи, ежели реально не виноват.
С джуном таких вопросов нет. Начал работу с удаления прода — подарком будет увольнение без статьи, ежели реально не виноват.
эффективного руководителя
Вот именно — он неэффективен. Это он совершил ряд потрясающих (правда, потрясающих, до такого довести — умудриться надо) ошибок, которые привели к безвозвратному удалению базы. Сегодня оказалось, что он бэкапы для базы не сделал, завтра окажется, что пароли лежат в базе в открытом виде, послезавтра выйдет релиз с критическими ошибками и компания потеряет миллионы долларов. Под конец накопится технический долг и его будет не исправить. Только найдется еще какой-нибудь
Эффективность — комплексное понятие.
Неужели Вы думаете, что если выяснится, что он такой злодей и несёт одни убытки, он долго там продержится?
Неужели Вы думаете, что если выяснится, что он такой злодей и несёт одни убытки, он долго там продержится?
Такие «эффективные менеджеры» часто держатся очень долго, и все время все вокруг виноваты, но только не они.
Бывает так, что с точки зрения Васи, менеджеры неэффективные и не нужны, а с точки бизнеса — эффективные и нужны.
Он также сообщил, что из-за важности потерянных данных к делу подключат юристов
Это называется «эффективен с точки бизнеса»?
Это называется «одна баба сказала». Засуженного работяги пока не видно.
Я про важные потерянные данные. Вы считаете, что СТО, допустивший потерю важных данных эффективен?
Есть такая категория специальная «эффективных менеджеров». Приходит руководить, проводит какую-нибудь эффективную реорганизацию, проводит сокращение расходов и еще чего-нибудь модное. Потом все начинает рассыпаться, он получает два годовых оклада своего «золотого парашюта», ищет новую компанию для приложения своих талантов. В резюме добавляется запись на тему «CxO в компании XYZ, сократил издержки на 50%, сократил расходы на зарплату на 30%, поднял капитализацию на 12.5%.» (То, что контора еще через пол года разорилась и продалась за пол цены — это уже мелочи)
Вы прямо таки описали ситуацию в некоторых сферах с которыми в последнее время много новостей)
Джун-Ждун ))). Может эт был засланный казачок.
Я бы на месте засланного казачка радостно бы сливал продакшен-базу, а не убивал бы её. Откуда мне знать, что бэкапов нет?
Примерно в 2008 году работал я в одной структуре. Там велся разный такой учет в старой-старой БД FLINT, которая еще под DOS. Штука, кстати, отличная по задумке. И тут понадобилось мне кое что поправить в базе, а хранит она все в обычных DBF-файлах, ну я экселем стороки подвинул как мне надо было. Но кто же знал, что FLINT оперирует не каким-то там ключом, а порядковым номером строки в DBF файле. Я этого не знал и база поехала, целиком.
Так как там был немного бардак и я был еще одним эникеем, то о бэкапах и прочем никто не думал. Чудом сохранились файлы базы недельной давности и 6 человек старательно вбивали данные заново.
После этого я провел ревизию вообще всего, что можно забэкапить, настроил кроны на виндовсах, синхронизации и хранил бэкапы N месяцев на разных тачках. Сильно выручало очень много раз. А сейчас работая над проектом первое что я делаю — прошу настроить бэкапы, и иногда прошу мне дать бэкап за вчера.
Уволить надо всех! Потому что все раздолбаи!
Тех. директор не следит за процессом.
Разраб зачем то полез на бой, даже не спросив есть бекапы или нет?
Ответственного за бекапы тоже надо уволить, потому что ковырял в носу и даже не удосужился делать бекапы.
В общем на лицо банальное раздолбайство, которое всегда есть в крупных компаниях!
Тех. директор не следит за процессом.
Разраб зачем то полез на бой, даже не спросив есть бекапы или нет?
Ответственного за бекапы тоже надо уволить, потому что ковырял в носу и даже не удосужился делать бекапы.
В общем на лицо банальное раздолбайство, которое всегда есть в крупных компаниях!
Помнится, году в 2008 к нам в команду присоединился новый программист, хороший умный парень, сишник, через пару дней спрашиваю у лида — как паренек? — лид ответил «хорошо втягивается, уже смог убить базу» :)
Ну там правда все было на дев-сервере, но это звучало как похвала — чтобы смочь убить базу тоже нужен некий уровень экспертизы внутри проекта :)
Ну там правда все было на дев-сервере, но это звучало как похвала — чтобы смочь убить базу тоже нужен некий уровень экспертизы внутри проекта :)
Люди делятся на два типа — кто уже запускал тесты на прод базе, а кто еще нет.
Странно, что никто не вспомнил про пиццерию, которая запустила тестовый скрипт с настоящими реквизитами от Яндекс.Кассы.
Мне кажется, любая уважающая себя крупная компания должна думать об ограничении прав доступа к важным продуктивным данным. Ну а так-то… fails happen.
Если в компании меньше 3.5 програмистов то разворачиванием среды для джуна должен занисаться опытный разраб (раньше это делал я сам), если больше то такой документ (естественно без боевых доступов) + бэкап базы, если есть возможность то вообще сделать процесс создания тестового окружения в виде виртуалки или docker контейнера.
В этой ситуации всиновны все по немногу.
- Джун по сути уничтожил компанию, с точки зрения бизнеса это очень плохо и естественно что у руководства бомбануло и его выгнали на мороз.
- Создатель документа — ибо писать туда боевое подключение это тот еще косяк. Такие данные должны знать 1.5 человека а не джун. Это хорошо что он его уронил а не сделал копию и унес конкурентам.
- Коллеги джуна так как не проследили за тем как он разворачивает систему и не помогли ему с этим.
- Техдир за то что не выстроил автоматизированный просесс подготовки тестовой среды
- Админы с бэкапом шрёдингера — всегда проверяйте бэкапы на то что из них можно восстановиттся
- Опять Техдир который опять не выстроил процессы востановления данных и не пнул админов
- HR и руководство компании которое наняли идиота техдира, идиота админа и приправили это джуном и надеялись что и так сойдет.
P.S Когда-то я сам был джуном и ронял базу на проде, и не было бэкапов, вообще никаких ибо в разрабах было всего два человека я и мой одногрупник.
Тогда с матами контентщики за 2 дня восстановили данные, благо копии контента у них были. После этого начали делать бэкапы.
Потом я еще раз уронил базу — но бэкапы не были актуальны — потеряли данные за 2 месяца, выстроили проверку бэкапов.
После меня еще многие роняли продакшен базу — всего раз 35 за 5 лет, но в этом случае всегда были вчерашние недельные и месячные бэкапы и по одной копии прода у всех разрабов на локальных компах и копия прода на тестовой версии сайта. когда не в очередной раз уронили базу на проде а бэкапов не было так как место кончилось — такие копии нас спасли, у меня оказалась копия прода за 3 часов до его падения но без одной таблицы а у одного человека нашлась эта самая таблица — сделали слияние и настроили ротацию бэкапов и отправку бэкапов на отдельный сервер с этими бэкапами.
Теперь появились микросервисы и для того чтобы уронить все их базы нужно еще постараться, тем более что на каждый сервис есть свои бэкапы.
Да понятно ресурсы ограничены и не всегда есть время и деньги покрывать такие риски — но если их за этих рисков компания загнулась то это не вина джуна, это вина руководства и его коллег.
Да о чем тут говорить…
Джун тут вовсе не виноват. Сама позиция, подразумевает то что сотрудник должен быть ограничен в правах. У него не должно быть прав для сноса базы.
Да и админы с бэкапом должны проверять их
Джун тут вовсе не виноват. Сама позиция, подразумевает то что сотрудник должен быть ограничен в правах. У него не должно быть прав для сноса базы.
Да и админы с бэкапом должны проверять их
Видите, в какой хорошей стране мы живем — в РФ наемного работника без материальной ответственности не могут оштрафовать на сумму, превышающую его месячный оклад.
Джун, конечно же, не виновен. Джун *в принципе* не может быть в виновен в одиночных косяках. Виновен ответственный за невозможность случайного нанесения вреда продакшну. Или тот, кто этого ответственного не назначил.
Джун, конечно же, не виновен. Джун *в принципе* не может быть в виновен в одиночных косяках. Виновен ответственный за невозможность случайного нанесения вреда продакшну. Или тот, кто этого ответственного не назначил.
Я работал в одной маленькой компании, где техдиректор (если его можно так назвать) в ответственный момент мог забухать и не придти на работу. Из-за этого выплывало много проблем и ложилось на плечи рядовых сотрудников. За пол года моей работы, подобное случалось несколько раз и многим приходилось до 11 вечера сидеть на работе, чтобы сдать проект без него. При этом он даже спасибо ни разу не сказал. Он и владелец компании друзья. Ему никогда ничего не было за такие прогулы, раздолбайство на лицо (какие ж тут бекапы, доступы и т.д.). Я не смог работать с такими людьми и покинул компанию, но я не думаю что после этого что-то изменилось. Виноват был бы джуниор, работая в подобной компании и беря пример с проиходящего? Конечно нет! Однозначно всегда рабочий процесс должен контролировать технический директор. Значит прежде всего виноват именно он.
Джуниоры никогда не получают прямой доступ к проду на запись. Чтение только с реплики (на то он и джуниор, чтобы еще научиться не класть базу одним запросом). В документации никогда нет паролей, которые, к слову, должны регулярно меняться, согласно политике безопасности. Ну и проверка восстановимости бекапов…
В общем, тут про** СТО по всем фронтам.
В общем, тут про** СТО по всем фронтам.
Помню, когда работал с сайтом одного не очень известного банка в админке, рядом открыл копию сайта для разработчиков. И меня сильно подгоняли по времени, я поспешил, и по ошибке удалил целый кусок бд с продакшена, когда надо было его удалить на тестовом. и я тоже не сразу понял что я это сделал на боевом сайте. доделал работу и сдал задачу. через час звонят из банка, говорят «вы чо ахринели, у нас целый раздел сайта пропал и ошибки выдаёт»
Хорошо что перед работой я делал полный бекап базы и с помощью старшего специалиста мы в течении полу часа восстанавливали вручную нужные таблицы. благо там не затронуты были транзакции и прочие сложные записи. просто контент.
Хорошо что перед работой я делал полный бекап базы и с помощью старшего специалиста мы в течении полу часа восстанавливали вручную нужные таблицы. благо там не затронуты были транзакции и прочие сложные записи. просто контент.
Ну идиоты конечно. Объявили стрелочником человека, который вообще не понимал что делает и был в состоянии стресса (первый день на первом рабочем месте).
Им бы стоило создать юзера БД (продакшн) с правами «только чтение» и катастрофы бы не случилось.
Им бы стоило создать юзера БД (продакшн) с правами «только чтение» и катастрофы бы не случилось.
Это знамение. А чуваку премию и в какую-нибудь приличную компанию его на работу.
Junior, который в первый день работы удалил базу данных с production