Comments 52
Потому что святая заповедь - не трожь пока работает
DevOps из вас так себе
Ибо завещал великий Учитель Инь Во Фу: не чини что не поломано!
фигня это а не заповедь
чем дольше не трогаешь тем больнее будет когда потрогать прийдётся, а однажды прийдётся потрогать 100%, и скорее всего в срочном порядке.
"работает - не трожь" это поговорка ленивцев любящих стрелять себе в ноги, не раз видел как блюстителей этой "заповеди" шумно увольняли за дорогостоящие факапы/взломы/etc.
Ну поговорка времен моей работы электронщиком но тут тоже подойдет.
Обновление еще не делает програму надежнее - пример тому недавний сбой в винде по всему миру. Обновили на свою голову - причем ПО именно безопасности
Нужно решать проблемы по мере поступления - есть лырка конкретная ее и надо затыкать
а проблемы производительности зачастую можна рещить просто добавить памяти ядер проца или перемещением на ssd диск
Лет пять наад в моей фоирме был проект итальянского банка дописать работающее там черти сколько лет ПО на языке Cobol.
Просто посчитали деньги и рещили что проще дописать хоть и пришлось ставить эмулятор AIX
У нас уже бы убедили заказчика что все надо переписать (на яваскрипте естественно) добавить блокчейн ну и само собой ИИ
Ну так почитать ченджлоги, погонять на тестовом стенде, при достаточном уровне компетенций и в diff заглянуть.. Всё это входит в процесс обновления и идёт в разрез с "работает - не трожь".
И да, бывает что не закапывать стюардессу выгоднее чем найти живую, но во первых выгодно не значит правильно, а во вторых то что выгодно в ближайшей перспективе может оказаться очень невыгодно на дальней дистанции. Конечно клиент может захотеть сэкономить сейчас а завтра пусть трава не растёт, и это его право ибо это его инфра, но для себя в своей инфре я такого не допускал бы..
Допускал не допускал, это слова старшего админа, максимум начальника отдела, а правильные слова - есть бюджет, вы в него попадаете с учётом рисков потенциального снижения устойчивости сервиса при нештатной работе улучшайзингов?
если обслуживание сервиса X выходит за рамки бюджета значит надо или похоронить сервис X или изменить размер бюджета, но никак не класть на сервис X большой и ржавый болт.
многие сервисы могут не приносить прямого дохода, являясь инфраструктурными и их обновления откладывают до тех пор пока не становится невозможно работать, потому что переход с постгри 10 до 14 не принесет бизнесу...ничего, только минусовую строчку в расходах...так зачем это делать? потенциальный рост производительности? а если там и так запас по скорости на 10 лет роста вперед? а такие работы только повышают риск простоев....кругом минусы, а радуются только перфекционисты админы
Этим кстати объясняется существование кобол систем до сих пор
многие сервисы могут не приносить прямого дохода
простите, но для меня странно в этом контексте делить доход на прямой и косвенный, как и забывать про такую графу как "потенциальные убытки" к которым может привести любое забытое CVE в каком нибудь неприкрытом сервисе. И да, тут речь не только про финансовые убытки но и репутационные потери которые тоже косвенно ведут к финансовым убыткам. и да, речь тут больше не про СУБД которые крайне редко торчат жопой в интернет а про весь софт в целом, но я считаю что подход к обслуживанию ЛЮБОГО софта в инфраструктуре должен быть максимально насколько это возможно одинаков.
потенциальный рост производительности
вот это как раз чаще всего для субд внутренних нужд не самое важное, куда как важнее потенциально продолбать данные от какого нибудь незакрытого бага или найти свои данные в продаже..
а такие работы только повышают риск простоев
простои не всегда обязательны, а те которые не избежать должны быть заложены в план работ ещё на этапе планирования сервиса.
кругом минусы
но минусов я что-то не увидел
а радуются только перфекционисты админы
обычно радостный префекционист-админ уже означает нормально работающую а потому приносящую прибыль инфраструктуру, бояться надо админов рвущих седые волосы со всего тела и яростно листающих HH в поисках куда бы сбежать с тонущего корабля..
не принесет бизнесу...ничего, только минусовую строчку в расходах
к тому же если расходы финансов и человекочасов обновление постгри или любого другого софта пусть даже в не самом важном для функционирования компании сервиса становится ЗАМЕТНЫМИ в общей массе значит инфраструктура (или весь бизнес в целом) спланированы настолько печально что гораздо лучше будет ВСЕМ такой бизнес остановить и отправить на свалку истории.
P.S.: я в целом согласен что именно для постгри процесс апгрейда выглядит как какой-то привет из прошлого и шаманство, но это не значит что стоит лениться его делать.
но я считаю что подход к обслуживанию ЛЮБОГО софта в инфраструктуре должен быть максимально насколько это возможно одинаков.
я тоже так считаю, но бизнес так не считает и это прямое его право, потому что он деньги платит за нашу с вами работу
может привести любое забытое CVE в каком нибудь неприкрытом сервисе
иногда дешевле огородить сервис вокруг чем его переписать или обновить
куда как важнее потенциально продолбать данные от какого нибудь незакрытого бага или найти свои данные в продаже..
Бизнес учитывает и эти риски тоже, но это зачастую решается изоляцией контуров и внедрение всяких IDS систем и систем обнаружения утечек
там есть такая штука что утечка как таковая - это инцидент который измеряется деньгами и совсем не факт то деньги этого инцидента будут больше чем содержание отдела разработки и поддержки постоянного обновления, с учетом вероятности наступления этого риска в рамках иных действий
например я своими ушами слышал фразу "если у нас украдет данные сотрудник, то мы просто подадим на него в суд, зачем нам еще както ограничивать доступы? у него в договоре написано что ему это запрещено делать" (с)
и вот также по всем пунктам. бюджет на всякие репутационные потери и компенсации это отдельная строка бюджета и кпи работы департаментов зачастую не связана с уменьшением подобных затрат
Это вот факт с которым мы все живем, практически без исключений.
простои не всегда обязательны, а те которые не избежать должны быть заложены в план работ ещё на этапе планирования сервиса.
простой может возникнуть если чтото пойдёт не так, на моем опыте было пару раз такое... ни 5 тестовых контуров ни многонедельная подготовка не смогла предусмотреть что на боевой СУБД не посыпятся индексы в момент миграций, а сотрудник который этим занимался решил забить на предварительную проверку резервного контура который тупо не стартанул в самый ответственный момент.
но минусов я что-то не увидел
минусы - это затраты, а плюсы - уменьшения какихто иллюзорных рисков вероятность наступления которых довольно спорная
Думайте как топ-менеджер, а не как админ, будет понятнее
к тому же если расходы финансов и человекочасов обновление постгри или любого другого софта пусть даже в не самом важном для функционирования компании сервиса становится ЗАМЕТНЫМИ в общей массе значит инфраструктура (или весь бизнес в целом) спланированы настолько печально что гораздо лучше будет ВСЕМ такой бизнес остановить и отправить на свалку истории.
как вы думаете в банковском процессинге, ключевой системой инфраструктуры является СУБД, её обновление это огромный и очень сложный поход к которому готовятся несколько лет... нужно на свалку истории его отправлять?
В банке, АРМ операторов, они работают на терминальных серврерах, замена и существенное обновление инфраструктуры влечет за собой риски что "всё упало, все наши 100500 отделений сегодня закрыты"..это дорого и сложно. у меня было около 300 отделений и ферма на 10 серверов которая их обслуживала...даже просто апдейты виндовые ставились там по определенному расписанию чтобы не всё сразу упало...а оно падало иногда...было весело.
но бизнес так не считает и это прямое его право, потому что он деньги платит за нашу с вами работу
я не знаю как у вас, но мне платят за работу целиком а не за её часть. я не являюсь конечным исполнителем который только делает ровно то что приказано и ни шагу в сторону, я принимаю участие в подобных решениях.
иногда дешевле огородить сервис вокруг чем его переписать или обновить
это тот случай когда я говорю: не "или" а "и"!
уменьшения какихто иллюзорных рисков
кирпич по голове на выходе из подъезда тоже считался илюзорным когда-то, а сейчас все выходы имеют защитные козырьки, нам с вами повезло что в нашей профессии ошибка не часто стоит чьей-то жизни, но это не повод допускать ошибки пачками
как вы думаете в банковском процессинге, ключевой системой инфраструктуры является СУБД, её обновление это огромный и очень сложный поход к которому готовятся несколько лет... нужно на свалку истории его отправлять?
как по мне так все банки и текущую экономику в целом давно пора отправить на помойку истории, в кучку с названием "позор человечества".
по вашему комментарию насквозь протекает идея экономии на спичках
что-то пошло не так при обновлении - долгий простой, а не быстрый откат на снапшот
упал терминальный сервер - все операторы не работают, а не переключаются на резервный автоматически.
меня жизнь давно научила что экономия на спичках приводит к ещё большим тратам "кроилово приводит к попадалову ©" инными словами.
я не знаю как у вас, но мне платят за работу целиком а не за её часть. я не являюсь конечным исполнителем который только делает ровно то что приказано и ни шагу в сторону, я принимаю участие в подобных решениях.
у меня есть опыт работы в крупных холдингах и компаниях, я конечно отвечаю за разработку, но некоторые пересечения есть с указанной темой
грубо говоря у меня есть план развития продукта на полгода вперед и если я вдруг скажу что следующие два спринта команда будет не пилить фичи, а переезжать на новую версию кубенрнетса...который ничего не даст в плане появления новых фич. ко мне придет финотдел и спросит "а чем вы там вообще занимаетесь? у нас TTM у продукта не пострадает? пользователи от вашей работы получат фичи позже на полгода? что?"
Мои предшевственники тут занимались тем что 3 года разрабатывали продукты которые вообще ниразу не добрались до MVP стадии, зато они написано на свежайшем питоне, свежайшей джанги, раскатывается всё новейшей версией ci/cd ..офигеть да..можно еще лет 5 пилить
это тот случай когда я говорю: не "или" а "и"!
Я рад за вас что вы можете такие решения принимать и их реализуют, я пока до такого не дорос
но это не повод допускать ошибки пачками
Что имеем то имеем, ошибки это всеголишь цифры в списке оценок рисков...все риски предусмотреть невозможно, все хотят чтобы все разработчики были сеньорами, чтобы софт писался быстро и без багов и бюджеты были безлимитные... а в реальности это не так и чемто надо жертвовать чтобы попадать в доходность продуктов
вон возьмите яндекс который на любой спор выдает промокод, потому что оценили риск лояльности клиентов в условные 200 рублей и вообще забили на исправление некоторых бизнескейсов...и что? а ничего! все счастливы и рады..бабло капает такси ездит. вот тут тоже самое
можно с этим не соглашаться, но с этим придется жить
как по мне так все банки и текущую экономику в целом давно пора отправить на помойку истории, в кучку с названием "позор человечества".
весь мир до основания я разрушу...а потом... дада, всё понятно ;) но это уже тема другого спора
по вашему комментарию насквозь протекает идея экономии на спичках
Вы спичками считаете цифры измеряемые сотнями тысяч долларов
вас не поражает с какой лёгкостью корпорации сокращают людей? я вот попал разов в этот процесс. утром на дейлик приходит HR и говорит что ваша команда работает последнюю неделю, а некоторые участники последний день...а потом ты узнаешь что сократили 3 департамента... потому что риск падения доходности компании чуть вырос, а продукт то дальше продолжает работать без персонала...и что? ох ох беда, никто не обновляет и не следит? а потому что риск остановки продукта ниже риска падения доходности...вон посмотрите на твиттер...там вообще всех уволили..и что? потрясло немного сервис но он работает дальше. и бизнес это отличное понимает
поймите что решения принимаются именно из таких соображений, а не потому что ядро линукса надо срочно обновить на 800серверах компании и потратить на это 500тыщ долларов потому что в редакторе vi уязвимость нашли которая возможна именно с нашим ядром линукса
вас не поражает с какой лёгкостью корпорации сокращают людей?
А должно? Если меня сократят это не мои проблемы, я то себе работу найду всегда, а вот моя контора останется без хорошего лояльного сотрудника. Если их это устраивает, ну ок, это их выбор кто я такой чтобы его оспаривать.
Более того, есть ряд вещей в случае которых я сам покину контору без обсцждений и не поддамся ни на какие уговоры.
я указываю на то что компании принимают решения руководствуясь совершенно другими сущностями и мнение админов на то как должна выглядеть инфраструктура ИТ тут даже не в первой десятке таких аргументов
"контора останется без лояльного сотрудника" - вы преувеличиваете свою значимость, останется без лояльного, возьмут другого лояльного. тут нет смысла рассуждать их потери.
еще раз, им вообще плевать как там и что у айтишников, им важны бабки, сроки и риски. всё
принимают решения руководствуясь совершенно другими сущностями и мнение админов на то как должна выглядеть инфраструктура ИТ тут даже не в первой десятке таких аргументов
Такие конторы обречены тратить на инфру больше а получать с неё меньше
вы преувеличиваете свою значимость, останется без лояльного, возьмут другого лояльного. тут нет смысла рассуждать их потери
Я не преувеличиваю свою значимость и не рассуждаю об их потерях, я лишь показываю своё отношение к таким ситуациям
А "взять" другого лояльного это фантастические сказки от HR. Лояльным сотрудник станет лишь со временем (правда с тем же успехом он может стать не лояльным а ненавидящим).
Такие конторы обречены тратить на инфру больше а получать с неё меньше
Вы делаете такой вывод с позиции с которой не видите все финансовые потоки, а лишь предполагаете как они проходят и на что тратятся
Вот вы как рассуждаете? "Оо, компания тратит 100000долларов в месяц на исправление багов, потому что у нас всего 2 админ которые разрываются на части чтобы собирать рассыпающуюся инфру и наверное теряет деньги из-за 1-2 падений в квартал" надо взять отдел из 15 человек, с дежурными, с пятью сеньорами, и сделать инфру сверхустойчивой... и тратить по 900000долларов в месяц!
т.е. получается что в первом варианте компания тратит 300тыщ долл в квартал, а во втором 2млн700
А устойчивость возрастет с 1-2 падений в квартал, до 1 падения в год! ВСЕГО!!
т.е. рост устойчивости сервиса стоит очень дохрена, а выхлоп в бабле будет минимальный
А "взять" другого лояльного это фантастические сказки от HR
незаменимых людей нет (за очень редким исключением и касающегося зачастую топменеджеров, а не рядовых сотрудников), сказки не сказки, но бизнесу плевать на людей.
Я вот сейчас попал на работу где ушел ведущий разработчик, вот просто ему захотелось сменить работу и всё (очень своеобразный товарищ)...и сработал эффект автобуса..потому что никто документацию не вел, а продукт у нас крайне сложный...и что все померли? а ничо не случилось, даже сроки выпуска мвп не съехали... но тут он сам ушел...а сократить его могла и компания по своим какимто соображениям, и продукт также передали бы комуто ещё
Бюджет - штука многофакторная. Есть свои риски при не-обновлении. Есть стоимость поддержки - например, другая система регулярно обновляется, и приходится коннектор между ней и легаси постоянно обновлять.
Так что правильный ответ тут простой и сложный одновременно: универсального решения нет, всё надо считать для конкретного ландшафта.
Буквально на днях обновили у одного из клиентов 9.5 до 15 :)
Работало с 2015 без проблем - предполагаю, что теперь ещё 10 лет проработает.
Основная причина обновлений - исправление обнаруженных уязвимостей.
Многие не меняют, простите, трусы и носки и одежду годами, да-да я имею ввиду как обычных так и IT субъектов. И как раз ход мыслей большинства людей направлен на то, что оптимизация это и есть "не трогать и не менять ничего на новое! Как раз новое и "пресловутое исправление" чего-то — это скорее мутация, нежели правило повседневное! Рекламная жизнь и рекламные лозунги о новом гаджете и новом ПО, совсем не отражают реальную жизнь и психику людей.
Наверное 80 процентов проектов используют postgres для стандартных insert/update/select/delete причем через какой нибудь фреймворк, который все эти запросы генерирует и большинству все равно, что за база данных там. Работает и ладно. Если MySQL в свое время своими лицензиями не запутал, то может и MySQL оставался выбором номер один для мелких и средних проектов. Теперь postgres вытеснил MySQL.
А вторая причина, это наверное стоимость миграции. В энтерпрайзе любое движение стоит огромных денег. Просто так переезжать никто не будет, сначала надо найти того, кто оплатит этот банкет. А ещё если проект и категории выше, так вообще будут тянуть, пока поддержку версии прекратят. Зачем если и так работает.
Из моей практики причина в Легаси коде и не совместимости между версиями, что заставит переписать часть кода, а на это обычно нет рук
С другой стороны стоит безопасность, конечно же
Все новые проекты делаются с новейшими базами, а вот старые обновить иногда на гране фентези, правда у нас проекты не смотрят во вне.
Думаю, если бы постгрес не требовал танцев с бубном над своей базой, а просто автоматически обновлял схему при запуске новой версии, то и обновляли бы охотнее :(
А так, новый постгрес поставь, старый оставь, потом всё останови, в нужной последовательности оба постгреса запусти...нунафиг в это лезть
А так, новый постгрес поставь, старый оставь, потом всё останови, в нужной последовательности оба постгреса запусти...нунафиг в это лезть
pg_upgradecluster давно уже завезли - делает как раз это
Что-то не вижу упоминания такой штуки в документации
https://www.postgresql.org/docs/current/upgrading.html
Все официальные методы — либо через дамп в SQL, либо через танцы с двумя постгресами
Похоже это чисто убунтовая обёртка над pg_upgrade / pg_ctl
В версии 12 реализован ряд изменений, которые могут повлиять на совместимость с предыдущими выпусками.
Некоторые ведь используют oid.
Если бы postgres старался поддержать обратную совместимость. Любой клиент, который ты скачал начинает кидать кучу ошибок при подключении к новой версии. Дампы у каждой версии особенные. Молчу про расширения, настройку параметров и поиск нужных драйверов. Сейчас версии выходят слишком часто, можно только этим заниматься периодически. Сайтик (что упускаешь из-за старой версии) - это круто, конечно. Но останавливать прод чтобы снова этим заниматься, когда только успел забыть еще круче.
Любой клиент, который ты скачал начинает кидать кучу ошибок при подключении к новой версии.
Странно это - протокол не менялся со времён царя Гороха
Сейчас версии выходят слишком часто, можно только этим заниматься периодически.
А вот это - да! Раньше раз в несколько лет выходило с долгожданными добавлениями, а теперь не успеваешь changelog читать!
Первые три предложения - феерический бред, уж пардон
Скачайте какой-нить pgAdmin постарее или попробуйте восстановить дамп через несколько версий одними и теми же инструментами.
Но это фигня. Феерично, если еще есть специфичные расширения, вместе пакетами в ОС, или вообще собраны из исходников.
Скачайте какой-нить pgAdmin постарее
(вспомнил pgadmin в доэлектронной версии...заплакал от приступа ностальгии и безысходности)
у меня помнится был тимлид который юзал старый пгадмин с какимито костылями чтобы он работал на новых версиях постгри....ошибками сыпал влево и вправо но кое как работал...
А почему я должен скачивать pgAdmin постарее (отдельный вопрос, на кой черт для восстановления дампа вообще pgAdmin)? Берете софт от новой версии (pgAdmin, pg_restore, psql) и заливаете дамп со старой версии в новую. Проблем обычно не будет (все incompatibilities описаны первым пунктом в Release notes).
В обратную сторону не сработает, так никто и не стремился это обеспечить (по факту через минимальные правки SQL дампа ручками сработает почти всегда).
Вы конкретизируйте свои претензии, а то читается действительно как бред. Например:
Любой клиент, который ты скачал начинает кидать кучу ошибок при подключении к новой версии
Да ну. Работоспособность клиента только от версии протокола зависит, а он сто лет не менялся. Вы, скорее всего, имели в виду свой pgAdmin, который тул для администрирования СУБД и лезет ей в кишки для выполнения своих задач. Ну как бы странная претензия - берите инструмент, совместимый с вашей версией, иначе ССЗБ.
Молчу про расширения, настройку параметров и поиск нужных драйверов
Что не так с расширениями? Ставьте совместимые с вашей версией, благо они по большей части прямо в комплекте идут. Нестандартные расширения компилируйте под нужную версию. Проблемы с совместимостью специфических расширений пусть решают их разработчики - как тут даже теоретически совместимость можно обеспечить, если расширение - это библиотека, встраиваемая в сервер, и оно вообще может творить все, что угодно?
Параметры... ну такое. Обычно их вообще трогать не нужно (не считая настройки производительности через какой-нибудь pgtune). А если у вас там мега-кластер с репликацией во все стороны и тонкими настройками, то за это обычно DBA деньги и платят - пусть читает доки и разбирается.
И что за драйверы вы там потеряли?
Ничего не понял, как будто повторили мой фееричный бред. Тут уже писали про танцы с бубном, хотя по факту ничего особо не меняется. Раз в полгода можно и более полезными вещами заниматься.
Я не противник постгреса, если вы из адептов) Аптайм старой базы около 2 тыс дней, штука максимально надежная. Есть похожий сервис в котором постоянно обновляется постгрес через разные действия, но не сказать, что это прям что-то дало за столь большое время.
pgAdmin просто как пример чтобы было понятно, он уже давно умер скорей всего. Драйверы обычно во всяких языковых библиотеках, только в идеальном мире достаточно обновить базу.
По некоторым комментам сразу видно тех кто не проводил увлекательное время в попытке восстановить систему :) солнце давно зашло, а утром кровь-из-носа все должно работать.
После такого опыта как то по другому относишься к 'быстренько обновить, новая версия лучше же'
В облаках, емнп, последняя рабочая версия, 15. Можно сделать себе сервер и самому развлекаться, но это деньги.
Потому что прекрасно помнится история перехода на 14, когда у одного параметра дефолтное значение поменялось на противоположное и получилось очень увлекательное приключение (когда читаешь).
Ну и исходя из этого, не хочется разгребать проблемы на реальном рабочем месте из-за того, что кто-то что-то где-то изменил в коде движка базы и он теперь работает совсем не так. Тестовый контур тут тоже не особо может помочь, из реального опыта два одинаковых дистриба линукса, одна и та же версия ПГ, настройки абсолютно идентичные, но в одном Archive settings при WAL репликации работают по одному, а в другой по другому. Хоть клонируй прод в тестовый контур, но проблема подхвата учёток в данных встанет в рост.
В MS SQL Server у баз есть свойство compatibility level - специально для того, чтобы при переходе на новую версию СУБД база вела себя как раньше (ну, по крайней мере в теории). В Постргес такого не завезли?
У меня в банковской системе версию PostgreSQL обновляют с опозданием, новые версии сразу не ставят, ждут проверку временем, наличие стабильности без баг. Так например более полугода назад только перешли с версии PostgreSQL 13.6, на PostgreSQL 15.3, в данный момент только на новые БД ставят PostgreSQL 15.6, на 17 наверное перейдет только через год.
я вообще боюсь что то нажимать, влево вправо, вске к чертям слететь может, так что нуево это обновление
Интересно, а проблему неподнимаемости слетевших индексов они решили?
Я пару раз нарвался и зарекся связываться, когда официальная поддержка на вопрос: как починить слетевшие индексы, рекомендует поднять рабочую копию из бэкапов...
Почему многие пользуются древними версиями Postgres?