Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 20
А ты тоже мошенник?😸
Интересно, бодро написано и, главное, применимо почти ко всем видам деятельности. Спасибо!
Имхо, правило 1 и правило 4 коррелируют.
"Никаких релизов в пятницу" это международное правило, которое я видел и в российских, и в зарубежных командах. Знаю одну крупную контору, которая один из БтБ продуктов именно в пятницу вечером уже после рабочего дня релизит, когда клиенты перестают работать, но у них те, кто релизят они сознательно готовы в субботу/воскресенье работать. И работают.
У вас что, один энв, прод и все? Обычно код живет на каком-нибудь QA, потом то, что планируется зарелизить, ставят на Staging - полную копию прода, включая копии баз данных из прод. бакапов. И уж когда на этой копии все зеленое, тогда ставят на прод.
Вы серьезно в базах данных ручками изменения фигачите? И прям поля удаляете? Обычно ОРМ позволяют делать изменения миграциями. А у миграций есть два метода, грубо говоря "накатить" и "откатить". И в "накатить" делается копия таблицы из которой поля удаляются, или меняются с возможной потерей данных. А в "откатить" поле восстанавливается и заполняется значениями из копии. Конечно если пользователей очень много и кто-то уже успел что-то изменить все равно придется ручками искать и исправлять, но для 99.99% пользователей откат все сразу починит.
Фичефлаги хорошо, но так-то это отдельная тема, не для сценария с удалением поля.
Момент номер раз. Удаление поля из БД. Не знаю что там за БД, но, работаю с "дибитухой" (DB2) уже 9 лет и вот там поле из существующей таблицы удалить невозможно. Оно просто не даст это сделать. Выдаст ошибку. Да что там удалить, там не то что тип поля, описание его уже не поменять... Единственное допустимое изменение в таблице - добавление нового поля в конец записи. Все. Остальное только полным пересозданием таблицы с потерей данных (хочется сохранить данные? делай скрипт для миграции, требуется отдельное согласование т.к. мигрировать несколько десятков а то и сотен миллионов записей такое себе...)
Момент номер два. Разделение зон ответственности. БД достаточно большая - несколько десятков тысяч таблиц. И она разделена на "зоны ответственности" разных команд. Так вот, доступ в "чужие" таблицы только через ретриверы и модули внешнего ввода. Никак иначе.
Момент номер три. Тестирование. Первый этап - песочница. Еженедельно пересоздаваемая копия компонентного юнита. Поставка туда разворачивается руками (системой сборки) из гита. Дальше - компонентный юнит. Тут уже установка через devops сервисы - доставка должна быть собрана и размещена в artifactory. Потом бизнес-юнит (бизнес-тест). Далее нагрузочное тестирование на копии промсреды и техтест на прелайве (тоже копия прома). И только после этого внедрение в пром. При внедрении в пром обязательно должен быть прописан план отката. На случай если что. Установками в бизнес-юнит и выше занимается дежурная смена по заявке. Т.е. в пром поставка попадает только после прохождения всех этапов тестирования - компонентного, бизнес, нагрузка, интеграция.
Поскольку всегда с поставкой идет план отката, то внедрение в пятницу нормальное дело. Если, не дай бог, что - поставка просто откатывается силами дежурной смены и все. Единственный мораторий на внедрения (за исключением хотфиксов) - период пиковых нагрузок с середины декабря и до конца новогодних праздников.
работаю с "дибитухой" (DB2) уже 9 лет и вот там поле из существующей таблицы удалить невозможно. Оно просто не даст это сделать
ALTER TABLE <TABLE> DROP COLUMN <COLUMN>;
Или я вас не правильно понял ? Но у меня обратная ситуация - я лет 9 уже не работал с дибицвай...
ALTER TABLE <TABLE> DROP COLUMN <COLUMN>;
И получите
Состояние SQL: 57014
Код вендора: -952
Сообщение: [SQL0952]
Обработка оператора SQL завершена.
Код причины: 10
Reason code 10 означает "A cancel reply to an inquiry message was received."
Аналогичный результат есть попробовать сделать это через DDS командой CHGPF.
А вы на на Db2 для I Series. Там, на сколько я помню, немного по другому чем на LUW. Тогла ок, но мне казалось, что все-таки можно удалить колонку, потому что код, что вы показали означает, что требуется подтверждение небезопасной операции, а клиент его не отправил. Но в system i я не эксперт, могу путать.
В любом случае, такое поведение нетипично для современных баз данных.
Да, IBM i.
И удаление поля из середины записи небезопасная операция. В больших БД с большим количеством интеграций я бы даже сказал недопустимая. Потому что обвал прода в mission-critical системе это уже практически катастрофа.
И мне не кажется что нетипичной такого поведения для БД это хорошо.
Кстати, там нет ожидания ответа. Там именно отправлен ответ отмены операции автоматом. "A cancel reply to an inquiry message was received."
Кабы оно ждало ответа, то задание висело бы в ожидании, а не вывалило бы ошибку.
Вот, не поленился джоблог поднять:
alter table y2ku.tstidxpf drop column tidxclc;
DIAGNOSTIC Изменение в поле TIDXCLC может привести к потере данных.
DIAGNOSTIC Change of file TSTIDXPF in Y2KU canceled.
ESCAPE Файл TSTIDXPF в библиотеке Y2KU не изменен.
DIAGNOSTIC Обработка оператора SQL завершена. Код причины: 10.
Я всё понимаю, и с уважением отношусь к вашем опыту. Но просто расскажу, как это происходит в 2026, а не в 1986 или какого там года ваша "дибиту".
В dBase III (файлы формата dbf) тоже нельзя удалить или изменить поле:) Только с этим *овном, как и с db2, работают единичные мамонты.
В нормальных современных базах (не мускуле) вы можете начать транзакцию, изменить схему, прогнать тесты и потом решить - коммитить транзакцию или нет. Ну, понятно, что железо должно такое тащить.
Дальше, вы закоммитили изменение схемы. Но, если вдруг вам потом, через сутки например, не понравилось, и вы решили откатывать релиз. Вы можете откатиться назад до транзакции изменения схемы. И, если у вас нормально написан софт (привет, event sourcing), накатить (сделать replay) все изменения данных на старую базу. Разумеется, это требует определённой строгости при разработке и тестировании, но это возможно.
У вас в API-доке было указано поле, доку видели внешние потребители. Как Кирилл может ставить жёпу что это поле никто не юзает? Может Кирилл самодур (тут другое слово). А вы как лид - некомпетентный юнит? Придумали правил леса, а придумать здравый смысл забыли? Это имхо больше похоже на правду.
API меняется только через версионирование, как только схема ушла во вне - ничего нельзя менять в ней (ну на край можно добавить полей если прям горит). Удалять, переименовывать - бан.
За изменение контракта без обеспечения обратной совместимости должен быть пожизненный эцих с гвоздями...
Да блин, ну поставь ты логирование в отдельный файл, что юзер vasya_pupkin сделал запрос с этим полем. И посмотри логи хотя бы через месяц. Обязательно сделай пару запросов от себя, чтобы убедиться, что логирование работает.
Дальше либо у тебя будут доказательства, что этим никто не пользуется. Либо ты будешь знать, что надо идти к конкретному Васе и просить обновить АПИ. (Да, если Вася работает в другой конторе или хотя бы отделе, он тебя пошлёт к своему менеджеру, а тот просто пошлёт. Но у тебя должен быть свой менеджер)
Каждый раз, когда я нарушал одно из правил леса, я всегда вспоминал этот список.
Это классическая логическая ошибка, называется инверсия импликации.
Как будет правильно (при условии что в выдуманной статье персонаж говорит правду)? Правильно будет: "каждый раз когда обнаруживались проблемы - выяснялось, что я нарушал одно из правил".
Чуть-чуть по-другому да?
Однако обе крайности - быть параноиком и совсем не заботится о безопасности вредны.
Параноик платит кратным снижением производительности, беззаботный - повышением числа инцидентов.
Профессионал же умеет отличать безобидные ситуации от потенциально опасных. В безобидных - не тратит лишнее время на перестраховку. В потенциально опасных - тратит больше ресурсов на уменьшение рисков.
Кажется, он смог глубже посмотреть на эти правила и интерполировать их не просто на лес, а на всю рабочую среду, которая ничем не хуже, да, возможно, и не лучше леса.
Когда не знаешь физику, весь мир кажется магией. Правило леса, как и ваше "велосипедостроение" очень далеки от реальности и к обычному рабочему процессу не имеют никакого отношения.
Чтобы не "обсираться" при проведении любых технических работ, давным-давно была придумана политика управления изменениями (change management). Там описано всё: что можно делать, что нельзя, как проводить работы, как их проверять, как выполнять откаты обратно и т.д.
Восстанавливаем схему БД. Нет, не случайная авария. Просто я удалил поле.
Все, кто хоть немного работают с базами данных, знают, что никогда нельзя что-либо удалять из схемы БД. Схему можно расширить добавлением полей и столбцов, но никогда нельзя их из схемы удалять, чтобы не ломать обратную совместимость. Так что при добавлении чего-либо в схему БД, нужно 10 раз подумать, а нужно оно там или нет, т.к. это изменение останется там навсегда.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кирилл, моя задница и 4 правила леса