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

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


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

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

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

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

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

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

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


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

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

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

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

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

    1. Уделяйте должное внимание выстраиванию важных внутренних процессов компании и документированию.
    2. Не забывайте про бэкапы (и восстановление из них).
    3. Даже в стрессовых ситуациях сохраняйте адекватность по отношению к людям.
    Кого в такой истории действительно стоит уволить?

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

    Флант 341,33
    Специалисты по DevOps и высоким нагрузкам в вебе
    Поделиться публикацией
    Комментарии 376
    • +71

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

      • +31
        Джун вообще должен иметь такие права доступа, чтобы даже при большом желании ничего не смог поломать. Тех кто писал инструкцию, ответственного за бэкапы, и СТО — на ковер, а Джуна похвалить за найденную уязвимость во внутренних процессах.
        • +1
          Должны иметь доступ или нет — это вопрос совершенно другой. Вполне есть способы сделать так, что у каждого члена команды будет доступ к production, но это требует куда больших усилий, чем разграничение прав.
          Но с тем, что джуна похвалить, а CTO на ковер — согласен)
          • +7
            Ну хвалить — это вы перегнули конечно. Вот если бы он не грохнул базу, а пришел и сказал: «Кажется у вас креденшлы к продакшну в документации» — то однозначно похвалить. А в произошедшем случае хвалить не надо, он просто вступил в каку, оставленную кем-то.
            • 0
              Расскажите секрет определения креденшпы от продакшна и дева? Если они не называются TestUser:TestPassword, конечно.
              • 0
                Да, вот как то так и определить.
                В статье:
                После запуска определённой команды я должен был скопировать URL/пароль/юзера базы данных из её вывода и настроить dev-окружение, указав там эту базу.
                Теоретически там могло вернуться что то в духе Test Test на машине Test. И тогда можно было бы насторожиться, что на руках имеется 2 разных рабочих креденшла. Один с пометкой Test, второй какой то Admin e4jm0dlwe9jvfje на машине production01.somecorp.com
              • 0
                Вот если бы он не грохнул базу, а пришел и сказал: «Кажется у вас креденшлы к продакшну в документации» — то однозначно похвалить

                Тогда бы историю о его похвале никто бы не узнал )
            • +6
              бэкапы Шредингера =), как я пропустил этот замечательный термин
              • 0
                Все верно, какой продакшн без бекапов. Даже на дешевых хостингах бэкапы делаются
                • +1

                  Не только делаются, но и теряются вместе с основными данными.

                  • 0
                    Угумс. Наверное многие помнят истории, когда «бэкапы» таблиц mysql хранились в этой же базе Mysql :)
                • 0
                  ну а джун, как по мне, ни в чем не виноват.

                  Надо еще проверить, не диверсант ли это...

                  • +2
                    > ну а джун, как по мне, ни в чем не виноват

                    Пацан к успеху шел :)
                    • 0

                      Если бы это был диверсант, он бы там не только базу положил бы. С таким подходом, наверняка, там много целей.

                      • +1
                        Так диверсант же ещё только джун — не хватило опыта, чтобы сразу найти новые цели для атаки
                      • +2
                        Опять русский хакер…
                      • 0
                        Да что там продакшен доступы. Я могу сейчас всем разрабам разослать логин-пароль от продовой базы и её IP адрес, но они не смогут ничего с этим сделать, у них не будет к ней подключения. И наоборот быть не должно.
                        • 0
                          … ну а джун, как по мне, ни в чем не виноват.

                          его вина лишь в том, что… с такою кармой он пошел не в тестировщики
                          • +1
                            Ага, представляю продолжение истории: другая контора наняла этого напортачившего джуна тестировщиком
                            ожидание: джун выявил множество уязвимостей в тестируемых продуктах
                            реальность: джун стер базу данных фирмы вместе с бекапами
                            • +1
                              В описанном случае реальность и ожидание — это одно и то же. Он ведь выявил серьёзную уязвимость.
                        • +24

                          Там никого увольнять не надо — бизнес рассыпется, и все вылетят, а джун этому только поспособствовал как триггер нескольких уязвимостей.

                          • +32
                            Более того, зачем увольнять сотрудников, которым провели такой дорогостоящий тренинг.
                            • +51
                              Технический директор уже считай угробил бизнес. А судя по его последующим действиям, он даже не понимает причинно-следственной связи. Вместо того, чтобы повысить джуниора, который одним легким движением нашел ошибки в документации и протестировал систему резервного копирования, он повел себя как истеричка)) Гнать, однозначно!
                              • +14
                                так потому он и уволил джуниора, чтобы свои косяки попытаться скрыть
                                • +5
                                  Не факт. Я довольно много встречал людей, которые на месте техдира из этой истории были бы искренне убеждены, что в этой ситуации не их вина, а джуна.
                                  • +6
                                    Их наличие на этой должности с такой точкой зрения не означает что это норма и так должно быть.
                                    • +1
                                      Ну, рос рос человек идиотом, повышался в должностях… Идиот это не причина для увольнения, а причина для повышения.
                                      • +1
                                        Там не идиотизм, а воспаление ЧСВ в терминальной фазе.
                                      • 0
                                        Это просто известный закон Питера: «Каждый человек в компании растёт до уровня своей некомпетентности». И вот результат.
                                      • 0

                                        С точки зрения техдира в данной ситуации действительно очень логично прикрыть себя, найти виноватого и отчитаться перед начальством об успешно принятых мерах.

                                    • +6

                                      Не думаю что это причина кого-то повышать, не вижу здесь заслуг junior'а, если бы он нашел и указал на это а не все выяснилось в результате ошибки, можно говорить о вознаграждении.
                                      А вот разобраться почему доступ к проду не был защищен и более того креды попали в описание дев настройки нужно. Ну и соответственно потом делать выводы. Возможно это реально случайны косяк, хоть и серьезный, а возможно система.

                                      • 0
                                        Ну ведь на кредах же не написано, что они от прода. Потому джун даже ничего и не заподозрил. Он же не мог заранее сказать о том, чего не знал :)
                                        • +1

                                          А почему вы ждёте от джуна понимания чем опасен доступ к проду? Я вот пока разок случайной (неправильно набранной командой) не грохнул таблички на тестово-девелоперской базе тоже не понимал — просто не знал о возможных проблемах. Благо у нас бекап были обычные, рабочие… :)

                                  • +4
                                    Был похожий кейс, когда я поменял значение некоторых данных на продакшне. Данные были связаны с ценами на продукцию и компания понесла убытки. Но меня не уволили, хоть и критиковали)
                                    • +7
                                      Похожее дело было. Когда я обернул эксепшн, что бы в логи не сыпалась постоянная ошибка об необработанном эксепшене. Но оказалось, что этот необработанный эксепшн использовался что бы останавливать фродерские транзакции. Так за сутки магазин успел продать кучу товаров фродерам. Меня тогда поругали, но оставили в команде))
                                      • +19
                                        Вывод — не используйте исключение там, где не нужно)
                                        • +5

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

                                        • +8
                                          Ничего себе у вас бизнес-логика.
                                          • 0
                                            Полагаться на возникающую ошибку для отсечения левых транзакций — это, конечно, весьма спорный способ…
                                          • 0
                                            Это не вы офис за 5 баксов «продавали»?
                                            • 0
                                              Не я, хотя, возможно, следовало бы
                                            • +2
                                              Ну, для коллекции — я на своей первой работе почистил все «комментарии» на всех клиентских системах, которые успели обновиться до моих изменений. Произошло это из-за археологического костыля для удаления неверных записей, о котором я не знал. Меня тогда даже не ругали, посадили переписывать этот костыль чтобы он еще чего-нибудь не почистил :)
                                              • 0
                                                Мне кажется такие фейлы у многих встречаются. Я тоже один раз не так бекап снял и потерял данные за полдня работы, восстановить можно руками но долго. Заказчик говорил что там было заказов на неск десятков тыс уе)
                                                • –6
                                                  Я считаю, это не фейл (в моём случае). Я разработчик, моя работа и моё время в сто раз важнее, чем цены на носки. Я должен разрабатывать адекватное программное обеспечение, а то что при этом у каких-то торгашей невалидные данные на продакшне, не мои проблемы.
                                                  • 0
                                                    Я разработчик, моя работа и моё время в сто раз важнее, чем цены на носки

                                                    Надо запомнить. Буду знать, что сказать начальству после случайного массапдейта в боевой БД.
                                                    • 0
                                                      С такими заездами для «разработчика» цены на носки в короткий срок могут поднабрать субъективной важности.
                                                      • –3
                                                        Я так и сказал. Но в моём кейсе, я не портил бд. Я просто выгрузил билд проекта у себя дома, чтобы доработать некоторый функционал, связанный с UI для редактирования данных. Доработал, потестил. Но я не знал, что по дефолту в приложении назначен боевой API, а не тестовый. Вот если бы мне об этом говорили, тогда это была бы моя вина. А так — не мои проблемы.
                                                • +31
                                                  Если у них в инструкции для прописаны данные авторизации для продакшн базы, то туда им и дорога, всей компании целиком, от гендиректора до этого студента.
                                                  • +1

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

                                                    • +3
                                                      Ну собственно гендиректор может быть далек от айти сектора…
                                                      А вот тех-лид да, в /dev/pozor
                                                    • +3

                                                      Я правильно понял, что в инструкции для разработчиков была прописана команда, очищающая базу на проде?

                                                      • 0

                                                        В тестах, написано же

                                                        • 0
                                                          Мне дали документ с информацией о том, как настроить локальное окружение для разработки. Инструкции включают запуск маленького скрипта для создания личной копии БД с тестовыми данными.
                                                          • 0

                                                            Не, вот тут


                                                            Далее, как понимаю, тесты добавили ненастоящие данные и очистили существующие, то есть между запусками тестов все данные из БД в production были удалены
                                                            • +2

                                                              В инструкции стояли креды от продакшн-базы, и указание на тестовый скрипт, который надо запустить с выданными в другом месте кредами. Джун перепутал и вбил креды из инструкции. Тестовый скрипт, скорее всего, включал в себя drop database с совпадающим именем, либо вместе с кредами вбивалось и имя БД. Результат — дроп продакшн-базы.

                                                        • +2
                                                          Нет, нет, нет! Она ничего не очищала. Просто заменяла рабочие таблицы на пустые!
                                                        • +5
                                                          Базу не заваливал, но помогать восстанавливать заказчику приходилось. Он экономил сильно на разработке и некоторых частей для администратирования в софте не было реализовано. По этому данные правились руками, из SQL developer. Один раз один из айтишников заказчика написал крутой SQL апдейт, но выделил для запуска только часть до where и так проапдейтил всю табличку с центральной сущностью — накладными. В обед. То-есть пол дня прошло, десятки грузовиков стоят ждут отгрузки, а все накладные в статусе «closed». Неизвестно что отгружать, накладные даже распечатать невозможно. Бэкап есть, но он делается только по ночам, то-есть практически бесполезен.

                                                          Пришлось брать логи приложения и эмпирически восстанавливать статус. Два часа детективной работы. По крайней мере накладные за сегодня выправили. Потом восстановили бэкап в соседнюю базу данных и восстановили уже остальные.
                                                          • +3
                                                            Oracle SQL developer?
                                                            Там после SQL апдейт можно было заметить, что многовато обновилось и не жать Commit.
                                                            • 0
                                                              Ну если у него autocommit стоял, то могло быть и поздно что-то делать. Как у него это получилось не знаю достоверно, может и как-то по другому накосячил, мне так передали.
                                                              • +1
                                                                А если база оракловая, то с версии 10.1 есть Flashback Query, который вполне позволяет восстановить данные на некоторое время назад. В зависимости от нагруженности базы, размера UNDOTBS и значения параметра undo_retention (по умолчанию 15 минут вроде).
                                                                • +3
                                                                  Угу. Была такая история. Разработчик заметил и нажал Rollback. И огромная транзакция начала откатываться… В течение нескольких часов. DBA вежливо заметил разработчику, что если бы тот сначала спросил, то проще было бы нажать commit и восстановить таблицу из бэкапа — все бы произошло гораздо быстрее и не стоило бы компании нескольких часов простоя.
                                                                • 0
                                                                  В одном банке была аналогичная ситуация, только с владельцами счетов. К моему счастью, я участия в этом не принимал, но атмосфера чувствовалась.
                                                                  • 0
                                                                    Бывало со мной такое за многолетнюю практику. Именно такой случай — выделение в консоли без where.
                                                                    Обошлось «без жертв», т.к. шкурой чувствуешь — апдейт должен отработать за пару секунд максимум, а тут второй десяток пошел, уже рефлекс на кнопку «стоп»

                                                                    Ну и ошибки были, что приходилось из бекапов нужные куски данных тянуть. Правда пару раз за всю практику (тьфу-тьфу)
                                                                    • 0
                                                                      А как нажатие «стоп» поможет в таком случае (если апдейт не был оформлен в транзакцию)? Просто похерится меньше записей?
                                                                      • +1
                                                                        Если автокоммит не включен, то транзакция начинается после первого DML или DDL, смотря, что за база и настройки. С автокоммитом тут же и заканчивается. Как бы в нормальной базе данных «похерится меньше записей» не бывает.
                                                                        • 0
                                                                          У меня мало опыта в работе с БД, поэтому не обессудьте за вопрос. Получается, что если (возьмём MySQL) выключен режим автокоммита, то любой запрос создаёт транзакцию? И если запустить на огромной таблице большой апдейт, а потом остановить его — то все изменения откатятся, не будет такого что часть записей которые «успели» — будут обновлены, а часть — нет?
                                                                          • +1
                                                                            Если автокоммит отключен, то рабочая сессия постоянно находится в транзацкии. Можно сделать несколько апдейтов/делитов/инсертов, но эти изменения «применяться» только после коммита, после чего начнется новая транзакция.

                                                                            По сути, когда ВКЛЮЧЕН автокоммит, то каждый запрос выполняется в отдельной транзакции, которая коммитися сразу после выполнения запроса.

                                                                            а потом остановить его — то все изменения откатятся, не будет такого что часть записей которые «успели» — будут обновлены, а часть — нет?


                                                                            Даже без явно заданной транзакции большой апдейт можно остановить и все изменения, которые успели сделаться, будут отменены.
                                                                            • 0
                                                                              Спасибо за разъяснение! А то я слышал о транзакциях, но не знал что они неявно работают всегда, думал это механизм который работает только по требованию.
                                                                              • 0
                                                                                Вы оба правы. В базах данных где транзакции есть их отключить нельзя обычно — и всё как выше сказано. Но вот конкретно в MySQL есть MyISAM таблицы — там ничего не откатить… разве что убить сервер и покорраптить базу…
                                                                                • 0
                                                                                  Да, это важное замечание. Работа транзацкий зависит от движка, на котором работает таблица. Мой комментарий справедлив для InnoDB.
                                                                              • 0
                                                                                СУБД Postgresql, дефолтные настройки PgAdmin'а, автокоммит включен, но всё, что написано в консоли, выполняется в одной транзакции.

                                                                                То есть, если написать 5 мелких апдейтов и одни большой, и запустить всё это на выполнение, есть шанс остановить без последствий
                                                                              • 0
                                                                                Да
                                                                                • 0

                                                                                  По MySQL не знаю как сейчас, 5 лет назад на таблицах, работающих на движке MyISAM (кажется так называется) "транзакция" была предельно "атомарна" — остановленный в процессе апдейт таки внёс бы изменения в часть колонок и не откатил их после остановки.
                                                                                  Впрочем это не касается транзакционного движка MySQL и других известных мне СУБД.

                                                                                  • 0
                                                                                    MyISAM не транзакционная в принципе
                                                                              • 0

                                                                                Если взять какой-нибудь Postgres либо Oracle, то там можно через специальные функции отменить идущий запрос (если он еще закончился и, соответственно, не случился commit).


                                                                                Т.е.
                                                                                1) увидели, что запрос подозрительно затянулся
                                                                                2) перепроверили запрос и увидели ляп
                                                                                3) запросили у базы список запросов и нашли проблемный
                                                                                4) дали команду отменить запрос
                                                                                5) запрос отменяется, транзакция отказытвается, попорченные данные так и не становятся видимы для всех остальных, кто работает с базой
                                                                                Примечание: 3 и 4 требуют привелигированного доступа к базе.

                                                                                • 0
                                                                                  Да, только пункт 2 желательно на последнее место поставить, а то можно не успеть :)
                                                                              • 0
                                                                                Кстати, после этого случая я и узнал, что выполняется только выделенный кусок кода, что потом стал использовать в разработке: можно закомментить всё в окне, и по необходимости выполнять мелкие куски оттуда, не создавая новых окон.
                                                                              • –1
                                                                                А нельзя сделать бекап логов и прокрутить их поверх ночного бекапа до инцидента?
                                                                                • 0
                                                                                  Постфактум бэкапы делать нельзя =)
                                                                                  • –1
                                                                                    В MSSQL при наличии ночного бекапа можно сделать лог-бекап после инцидента и развернув оба прокрутить до нужной транзакции.
                                                                              • +23
                                                                                На то он и джуниор. Для этого у него должен быть наставник, и не только в самый первый день. Да я по себе помню — когда приходишь на новое место и тебе надо что то настроить себе, при этом ты не имеешь совершенно никаких понятий как и что в компании устроено… я будучи не джуниором, имея в инструкции админские пароли от продакшена, не уверен что я ничего не снесу :)
                                                                                • +5
                                                                                  В инструкциях никогда не храним пароли.
                                                                                  • +2
                                                                                    Пытаюсь сдать сейчас проект заказчику, одна из претензий: в инструкциях не указаны логины/пароли администраторов. На мои замечания что вообще-то, после того, как я уйду, вы их должны сменить и соответственно сразу же устареет инструкция, никто не обращает внимания (менять пароли тоже никто не будет).
                                                                                    • –1
                                                                                      заказчик олень. Советую пароль в инструкции указать неправильный.
                                                                                      • 0
                                                                                        Проходили уже, приходит другое замечание: логин/пароль не подходит.
                                                                                  • +4
                                                                                    Откуда вообще у разработчика доступ к production базе?
                                                                                    Доступ к ней должен быть только у админа/девопса/релиз менеджера — того, кто отвечает за деплой на продакшен, кто делает бэкапы. И в идеале доступ выдается временно, под определенным тикетом.

                                                                                    Это конкретно прокол организации и соответственно тех.директора, которые не поставил нормально работу, не добился понимания того, что бэкапы есть и проверены, не добился того, что инструкции адекватные…

                                                                                    Да в общем, тут как-бы очевидно все. Вопрос в том, насколько бизнес поднимется, если у них вообще бэкапов нет (нонсенс просто).
                                                                                    • +1
                                                                                      Да тут на самом деле очень много вопросов по организации работы. Но винить джуниора в том, что он пришёл и по незнанию и инструкции с админискими правами всё сломал — это верх безумия (хотя чего ожидать от руководителя, у которого таким образом построена работа!?).
                                                                                      Главное что б руководитель ушёл «по статье», если у них такое там есть.
                                                                                      • 0
                                                                                        >> Откуда вообще у разработчика доступ к production базе?
                                                                                        Я так понял, скрипт снимал бэкап прода и разворачивал на локальной машине. Проблема в том, что доступ был не только на чтение :)
                                                                                        • 0
                                                                                          В таком случае ничего бы не произошло.
                                                                                          Судя по описанию, скрипт создавал БД и заполнял её тестовыми данными.
                                                                                          • 0
                                                                                            Один скрипт именно что снимал бэкап и разворачивал его не то на локальной машине, не то на какой-то тестовой.
                                                                                            Второй скрипт убивал все данные в БД и заполнял их тестовыми значениями.
                                                                                            Джун должен был запускать второй скрипт с теми конфигами, что нагенерировал первый, но он запустил его с данными production базы.
                                                                                            • 0
                                                                                              Откуда вы это взяли?
                                                                                              Во-первых, это бессмысленная деятельность — тащить БД в полном объёме, чтобы тут же удалить данные (даже для такой конторы)
                                                                                              Во-вторых, как следует из рассказа, работающих бэкапов не было.
                                                                                              • +1
                                                                                                Откуда вы это взяли?


                                                                                                Вы не поверите, я пост прочитал.
                                                                                      • 0
                                                                                        А если сеньор приходит то он с первого дня понимает как что в компании устроено?
                                                                                        • 0
                                                                                          По-моему если прочитать мой каммент целиком — он отвечает на ваш вопрос :)
                                                                                      • +7
                                                                                        В истории прекрасно всё :) Не думал, что такое бывает в реальности.
                                                                                        • +2
                                                                                          В реальности еще и не такое бывает…
                                                                                          Не буду писать какая именно из СУБД, но при переполнении тома коцает базу. Естественно, ни в один лог не пишется, что место кончилось, да и вообще в логах ничего о проблеме нет. После этого у пользователей начинаются странности. То интерфейс не грузится, то грузится, но в какие-то моменты выпадает… Естественно, первая реакция саппорта на сообщения о проблемах — а давайте включим ведение подробных логов! Сразу после этого база убивается вообще до невосстановимого состояния. Единственный вариант — полностью восстановить базу и СУБД из бэкапа. Если он сделан до того, как СУБД покоцала базу… Самое смешное, что, кажется, на СХД даже было настроено автоувеличение объема тома по мере необходимости, но почему-то не сработало.
                                                                                          • 0
                                                                                            Это другое немного. Тут всё-таки в софте бага, а в оригинальной истории мегапофигистское отношение к бизнес-критикал вещам, это даже багой не назовёшь, это просто профнепригодность.
                                                                                            • +2
                                                                                              Тут забавное сочетание обстоятельств — проблема возникает из-за невозможности из линукса точно узнать объем свободного места, в сочетании с отсутствием ошибки при обнаружении недостатка места в софте, в сочетании с естественной натасканной реакцией саппорта — если что-то непонятно, включить журналирование всего и передать результат на уровень выше. В результате — журналов все больше, а боевой базы — все меньше. (по какой-то причине, журналы нормально писались и не бились...)
                                                                                              Плюс к этому — отсутствие живых бэкапов.
                                                                                              А исходная первопричина багов в софте — разработчики СУБД не тестировали СУБД в условиях недостатка места. Просто не пришло в голову, что у кого-то может переполниться том с боевой базой.

                                                                                              В описанной в топике истории — наложение трех багов в wetware: первый баг — автор документации забыл поменять в тексте после копипаста логин пароль боевой базы, второй — никто не догадался поменять логин-пароль боевой базы перед запуском в продакшн.
                                                                                              Баг номер три — джун после учебы натаскан вбивать примеры из учебника как есть не включая мозг. А уже потом разбираться, если вдруг что-то не заработает.
                                                                                              • 0
                                                                                                А исходная первопричина багов в софте — разработчики СУБД не тестировали СУБД в условиях недостатка места

                                                                                                Что-то самописное?

                                                                                                • 0
                                                                                                  Ну как бы авторы интерфейса — из «большой тройки» в своей области. Все это поверх СУБД из «большой тройки» в области СУБД…
                                                                                                  • +2

                                                                                                    Да Монга это, MongoDB. У нас с ней так же было...

                                                                                                    • 0
                                                                                                      В нашем случае — другая СУБД была, но… начинает складываться ощущение, что такая проблема есть очень много где…
                                                                                                      • +1
                                                                                                        А почему Вы скрываете название СУБД?
                                                                                                        • 0
                                                                                                          NDA еще не кончился…
                                                                                                  • 0
                                                                                                    Тут забавное сочетание обстоятельств — проблема возникает из-за невозможности из линукса точно узнать объем свободного места

                                                                                                    Видимо то вы просто не умеете его готовить. Заббикс, например, из коробки мне вкинул темплейт: Discovered by
                                                                                                    Mounted filesystem discovery, и по всем линуксово-аиксовым серверам показывает графики и алертит, если меньше 20%, 10%, 2% (с разным "приоритетом") свободного места. На рабочей машине скрипт, который смотрит все примаунченые файловые системы, и раз в 5 минут алертит через notify-send если занято более 90%. Короче не вижу "невозможности из линукса точно узнать объем свободного места".
                                                                                                    Возможно имеется ввиду, что бд внутри себя создает какой-то виртуальный том, но это изврат, как мне кажется.

                                                                                                    • 0
                                                                                                      А линукс вообще был какой-то ред-хэт… на виртуальной машине. А на чем физически СХД жила — вообще неизвестно было. И когда виртуальной машине на виртуальной СХД выдают виртуальный том… Там вообще много разного интересного может случиться и без участия СУБД…
                                                                                                      Как там было на баше в свое время: … старкон2, запущенный в DosBox, под иксами в Дебиане, который запущен в VMWare, которая в WinXP
                                                                                                      Куда мне вопрос о неработающем звуке задавать? ...
                                                                                                      • +1

                                                                                                        ну не знаю, ребят. У меня блейды с red hat мастер-машинами, на которых kvm'ные редхаты крутят оракл энтерпрайс, и ibm'ные машины, на которых aix'ы крутят оракл энтерпрайс. И везде с hitachi схд выделены диски.


                                                                                                        Но я не вижу таких проблем, как вы описываете. Может быть с этим столкнулись люди, которые настраивали всю инфраструктуру, но при развертывании новых бд я тоже не вижу таких проблем. Более того, в реальном времени мониторится как наличие свободного места на дисках (под арклоги, в основном), так и свободное место в tablespaces внутри оракла.


                                                                                                        Наверное, вы просто что-то не так сделали… или не дочитали.

                                                                                                        • +1
                                                                                                          Может быть данные хранились на разделе без ФС?
                                                                                                          • 0
                                                                                                            Со всеми своими извращениями с виртуальными машинами я пока только до одного не докатился: попробовать запустить VMware внутри VMware. Матрёшку сделать :)
                                                                                                            • 0
                                                                                                              На практике не работает. Вроде всё по Попеку и Голбергу в x86, но… не работает. Кажется сейчас можно запустить VMWare внутри VMWare, а вот уже там — VMWare не запустить. Притом, что у IBM 3-5 уровней работали уже в 70е.
                                                                                                              • 0

                                                                                                                Соответствие набора инструкций требованиям дает только теоретическую возможность. Инструкции виртуализации же надо еще правильно эмулировать в самой виртуальной машине — а это мало кому интересно.

                                                                                                                • 0
                                                                                                                  Короче, надо попробовать :)
                                                                                                                  • 0
                                                                                                                    А если VMware — VirtualBox — VMware — VirtualBox — …?
                                                                                                                    • +1
                                                                                                                      А какая разница? Как было выше замечено AMD-V или Intel VT-x можно виртуализовать — но, насколько я знаю, ни VMWare, ни VistualBox не заморачиваются. Так что процессор «внутри» оказывается как бы без этих технологий, и, соответственно в VMWare «второго уровня» VMWare уже не запустить.

                                                                                                                      Если это исправили (а могли — я довольно давно не смотрел), то можно вкладывать хоть 10 уровней (если памяти/скорости процессора хватит), если нет — то только три…
                                                                                                                    • 0
                                                                                                                      Вложенная виртуализация у VMware появилась в 2010 году и двух уровней хватает для лаб с гипервизорами.

                                                                                                                      А какой смысл практический смысл в 3-5 уровнях вложения? Какие-нибудь заморочки с MLS?
                                                                                                                • 0
                                                                                                                  Ну почему изврат, тот же оракл афаик так же поступает — он зажрет всё место на выделенном диске сразу под свою базу уже потом что-то там внутри своей базы распределяет, выделяет место итд, и о состоянии с местом внутри базы ты из самого линукса не узнаешь, по df ты всё время видишь 99%-100%.
                                                                                                                  Только это ни разу не линукса проблема, это на уровне БД такое веселье…
                                                                                                                  • 0
                                                                                                                    В моей практике были случаи, когда заббикс гасил триггер не потому, что место появилось, а потому, что свободное место на диске становилось отрицательное (на линуксе такое возможно, да), а заббикс хранил значение в unsigned типе, которое приводилось к 2^16-n. Не помню, правда, это во встроенных шаблонах было, или что-то самописное.
                                                                                                                • 0
                                                                                                                  это тоже своего рода баг. Баг в людях и политике «ну ты сделай так что бы работало, а потом поправишь(нет)»

                                                                                                                  и сразу вспомнился один ну очень бородатый анекдот:
                                                                                                                  — Расскажите о себе
                                                                                                                  — Могу копать, ну правда херово, могу не копать, в этом разбираюсь чуть лучше, могу сделать так что бы другой копал — с этим справляюсь на ура!
                                                                                                                  — Поздравляю с назначением на должность технического директора!
                                                                                                                • +1

                                                                                                                  Напишите уж пожалуйста, что это за СУБД, это же царь-баг!

                                                                                                                  • +1
                                                                                                                    Ну как видите, таких СУБД — более одной. Когда эту историю рассказал опытным бойцам с той СУБД (не связанным с нашей той ситуацией), то они только плечами пожали — типа это не неизвестный баг, это известная фича. Надо тщательно и регулярно поддерживать запас свободного места и иметь свежие бэкапы, если вдруг это не помогло.
                                                                                                                    (если действительно так интересно — пишите в личку)
                                                                                                                • +12
                                                                                                                  /ухмыляясь
                                                                                                                  Реальность — она вообще бредовей любой выдумки.

                                                                                                                  Вот это вот, например: http://kris-reid.livejournal.com/150232.html

                                                                                                                  Ну и маленький эпизод оттуда:
                                                                                                                  «вспомнилось: «Сидит Слава Логинов, пишет сельскохозяйственную фантастику. Мучается творчеством. Рядом сидит Женя Лукин. Логинов задумывается, отрываеться от работы и говорит...:
                                                                                                                  — У меня тут в рассказе есть один тракторист, который постоянно по пьянке трактора в речке топит. Hикак не могу решить, сколько же он их утопил. Два — вроде мало, три — не поверит никто…
                                                                                                                  — Да — говорит Женя. — Задачка… А на самом деле сколько он их утопил?
                                                                                                                  Логинов тяжело вздохнул.
                                                                                                                  — Одиннадцать… „
                                                                                                                  И обязательно с комментарием lemming_drover ( отсюда ):.»Это апокриф. Я как-то раз спросил Логинова о том трактористе. Так вот, во-первых, не все его трактора утонули, некоторые погибли иной смертью…
                                                                                                                  Во-вторых, загубленных тракторов было _четырнадцать _!!! «;)

                                                                                                                  Так что это в жизни может случиться что угодно, а в книгах все должно быть логичным;))“
                                                                                                                  • 0

                                                                                                                    Еще можно перепутать консоли и удалить постгрес в дебиане через --purge, хорошо что была реплика в стандалоне

                                                                                                                    • 0
                                                                                                                      От перепутывания консолей хорошо помогает назначение production-серверам другого цвета фона в терминале.
                                                                                                                      • 0
                                                                                                                        Спасибо, хорошая идея.

                                                                                                                        Правда, в том случае не помогло бы — оба сервера были на продакшине
                                                                                                                  • +11
                                                                                                                    Да уж, по возможности бегите из компаний, где у джуниоров есть доступ на удаление продакшн-баз. Это значит, что там все плохо, никто ничего не понимает, а руководить вами будут, по всей видимости, такие же джуниоры, которые в какой-то момент посчитали себя сеньорами-помидорами.
                                                                                                                    • 0

                                                                                                                      Если у джуниоров есть доступ к продакшену, то, на самом деле, два варианта. Либо в компании все очень плохо, либо, наоборот, все очень хорошо — все зарезервировано и автоматизировано так, что ничего страшного не случится.

                                                                                                                      • +6
                                                                                                                        Ну, тоже мнение. Но, лично я считаю, что любой доступ должен быть жестко лимитирован и разграничен. А, если он необходим, то также жестко аргументирован. Вопрос — зачем джуниору доступ в продакшн? В любой здоровой (от слово здоровье) компании сиди и разрабатывай локально у себя на машине. Потом деплой в тестовую среду. Как только прошли тесты, запрашивай деплой в QA, и далее по цепочке. Никаких доступов в продакшн, кроме лимитированного числа людей ни у кого не должно быть.
                                                                                                                        • +1
                                                                                                                          Вопрос — зачем джуниору доступ в продакшн?

                                                                                                                          Например, расследовать инциденты с прода или баги, воспроизводящиеся только на проде.
                                                                                                                          Тогда вполне разумно дать, например, ридонли доступ.
                                                                                                                          • 0
                                                                                                                            Это, опять же, говорит о совершенно дурной архитектуре распределения прав. Запрашивай базу к себе на локальную машину и расследуй, что там нужно расследовать.
                                                                                                                            Это помимо того, что сомневаюсь в компетенции джуниоров вообще что-то расследовать на продакшне (хотя джуниор джуниору рознь, конечно). Меня просто дико коробит связь «джуниор-продакшн», при любой аргументации.
                                                                                                                            • +1
                                                                                                                              Пример: есть реплика БД, которая используется для отчетов или еще каких-то некритичных процессов, которую нам не жалко даже положить в случае чего. БД размером 100500 мб. Почему бы не дать к ней доступ на чтение для разработчиков (в том числе джуниоров, потому что им тоже надо на чем-то учиться)? Чем лучше выкачивать БД каждый раз локально, особенно если нужно проверять данные несколько раз (до и после какой-то операции)?
                                                                                                                              • +1
                                                                                                                                потому что запрос к базе может быть довольно диким на чтение и положить сервер по нехватке памяти.
                                                                                                                                • –1
                                                                                                                                  Я же написал:
                                                                                                                                  БД, которая используется для отчетов или еще каких-то некритичных процессов, которую нам не жалко даже положить в случае чего
                                                                                                                                  • 0
                                                                                                                                    потому что она может быть на том же сервере что и рабочая…
                                                                                                                                    • 0
                                                                                                                                      А может и не быть, речь как-то не об этом.
                                                                                                                              • +1

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

                                                                                                                                • 0
                                                                                                                                  Да не вопрос, можно миллиард причин придумать, почему что-то должно делаться на продакшне, о чем разговор-то. Моя позиция — нужно максимально лимитировать доступ к продакшну. Так можно дорассуждаться и до того, что нафик QA и тестовые окружения, ибо на продакшне все удобнее делать и быстрее, чего уж там дамбы гонять туда-сюда.
                                                                                                                                  • 0

                                                                                                                                    Я же не голосую за всеобщую работу на проде и без QA. Просто есть ситуации и состояния бизнеса, когда приходится джуна пускать в огород. В моем случае, правда, прочитали 10 лекций, 5 раз напугали и 1 раз предупредили: "нет однозначного понимания — Enter не трогать"

                                                                                                                                    • +1
                                                                                                                                      Я вашу позицию услышал, но соверешнно не согласен. В моем понимании, единственное, почему что-то делается непосредственно на продакшне, это лень делать что-то на тестовом сервере. Вот нельзя на продакшне ничего делать, кроме деплоя и все тут — это моя религия. Ладно, останемся при своих мнениях. В конце концов, возможно у нас разное представление размеров продакшна.
                                                                                                                                      • 0
                                                                                                                                        хорошая религия. Жаль жизнь сложнее. Начиная с того что любой проект на началось стадии зачастую вообще существует в единственном виде, без тест/dev версий. И живет так долго, до определенного момента (до первого инцидента часто).
                                                                                                                              • 0
                                                                                                                                Указан же джуниор девелопер, а не L3 саппорт / QA / бизнес аналитик

                                                                                                                                Инциденты непосредственно на продакшене в первый день работы джуниор девелопером никто не расследует.
                                                                                                                                • 0
                                                                                                                                  Вопрос был такой:
                                                                                                                                  зачем джуниору доступ в продакшн?

                                                                                                                                  При чем тут первый день? Или во второй день он уже не джуниор?
                                                                                                                                  В компаниях, которых я работал и работаю, так повелось, что баги исправляют разработчики, а не L3 саппорт / QA / бизнес аналитик (если они вообще есть в компании).
                                                                                                                                  • +1
                                                                                                                                    По статье — человек даже свою рабочую машину еще не настроил, а доступ к продакшену валяется налево направо, причем на продакшене оказывается такая важная информация, что собираются юристов привлекать.
                                                                                                                                    Если данные такие важные — то доступ должен быть соответственным.

                                                                                                                                    Только пришедший джуниор же, еще хорошо если просто разбирается с языком программирования и технологиями, но с разрабатываемым продуктом он не знаком, и инвестигировать проблемы, не зная как работает проект — он не может по определению.
                                                                                                                                    • +1
                                                                                                                                      Со всем согласен, но мой ответ был на конкретное заявление:
                                                                                                                                      Вопрос — зачем джуниору доступ в продакшн? В любой здоровой (от слово здоровье) компании сиди и разрабатывай локально у себя на машине.

                                                                                                                                      И не относится к случаю в статье.
                                                                                                                                      • 0
                                                                                                                                        В некоторых компаниях важность данных определяется исключительно по их утере, к сожалению.
                                                                                                                                        • 0
                                                                                                                                          Классический пример: пока все работает -топам жаль денег на дополнительный жесткий диск, куда можно складывать бэкапы.
                                                                                                                                          Когда все упало, топы в первую очередь пытаются оторваться на рядовом персонале, который эти самые жесткие диски неоднократно и просил.
                                                                                                                                • 0

                                                                                                                                  У netflix-а есть Chaos Monkeys — специально, чтобы все ломалось регулярно, а система выдерживала, если не выдерживает — делают так, чтобы выдерживала.


                                                                                                                                  Чем джуниор не Chaos Monkey? ;)

                                                                                                                                • 0

                                                                                                                                  Если есть доступы на изменение данных это уже плохо. У вас какой то парадокс получается.)
                                                                                                                                  Но даже если предположить что все легко восстановимо, то за чем это? К тому же случайные небольшие изменения можно не заметить, и как вы их потом будите отлавливать и фиксить не понятно, а они будут втихую портить кому-то жизнь ухудшая качестве продукта.

                                                                                                                                • +3

                                                                                                                                  Вы забываете что это не у него был доступ, а у любого кто может почитать доки. У секретарши, например. То есть дела там еще хуже.