Postgres 17.0 уже вышла, и она замечательная, но реальность такова: большинство пользователей Postgres не выполняют апгрейд сразу же. Многие, вероятно, сейчас даже не на 16.4, и даже не на 16, они пользуются Postgres 15 или ещё более старой версией. Ситуация с Postgres не такая же, как с новыми Call of Duty, когда каждый хочет скачать обновление сразу же после его выхода.
Почему же люди так неохотно идут на апгрейд?
На то есть множество причин, но всё сводится к двум основным: качество работы Postgres и неудобство апгрейдов.
▍ Фундаментальное величие Postgres
Наша команда контрибьютила в Postgres 17, и мы в восторге от новых возможностей и оптимизаций. Но большинство разработчиков не похожи на нас, для них база данных — это просто инструмент.
И Postgres был отличным инструментом за много версий до 17. Старые версии Postgres более чем справляются с тем, что нужно большинству разработчиков. Базовая функциональность Postgres присутствует в ней уже много лет. Фундаментальная мощь Postgres заключается в том, что она позволяет разработчикам создавать надёжные масштабируемые приложения, не задумываясь о версии базы данных.
Но это не значит, что Postgres не совершенствуется
Например, допустим, вы сейчас работаете с версией 12. С её выпуска производительность Postgres существенно выросла:
- В Postgres 13 повышена скорость обработки запросов, использующих агрегатные функции или разделённые на секции таблицы (partitioned table).
- В Postgres 14 появилось множество улучшений производительности, связанных с параллельными запросами, активно использующими конкурентность нагрузками, partitioned table, логической репликацией и высвобождением пространства (vacuuming).
- В Postgres 15 внедрены улучшения производительности, в частности, связанные с сортировкой в памяти и на диске.
- В Postgres 16 повышена производительность vacuum freezing и логической репликации из реплик.
Такие внутренние улучшения крайне важны для повышения качества приложений. Между версиями Postgres 8 и 16 время задержки уменьшилось наполовину (за секунду):
И мы ещё не говорили об усилении безопасности, устранении багов и, разумеется, о новых возможностях. В новых версиях появилась поддержка SQL-команды MERGE, конструкторов SQL/JSON, тождественных отображений, распараллеленного vacuuming индексов…
Но стоит взглянуть и на другую сторону медали: если вы не стремитесь действительно достичь пределов производительности Postgres и не ищите любые возможные улучшения или вам не нужна новая функциональность, то Postgres 12 вас вполне устроит.
▍ Затраты на изменения
Именно в этом заключается первая причина нежелания апгрейда Postgres многими пользователями: Postgres и так их вполне устраивает. Но мы бы обманывали себя, если бы не признали, насколько мучительным может быть переход на основные версии Postgres, особенно в случае крупных баз данных в продакшене.
Основные версии Postgres могут вносить обратно несовместимые изменения (с младшими версиями такого не бывает), поэтому компаниям гораздо сложнее выполнять автоматический апгрейд.
▍ Истории об апгрейде из реальной жизни
Чтобы осознать картину, давайте рассмотрим две опубликованные истории компаний, выполнивших апгрейды Postgres в продакшене с перепрыгиванием нескольких основных версий: Knock (она обновлялась с Postgres 11 до 15) и Retool (с Postgres 9 на 13). Это серьёзный переход, к которому нужно готовиться стратегически.
Этим компаниям пришлось сделать следующее:
- Оценка и планирование. Они оценили размеры и рабочие нагрузки своих баз данных (у Retool была база данных на 4 ТБ; Knock владела несколькими базами данных). Компании поставили следующие цели: минимизация даунтайма и апгрейд до завершения end-of-life. Они выбрали целевые версии Postgres и составили подробные графики реализации проекта и оценку рисков.
- Подготовка репликации Были запущены новые инстансы баз данных с целевыми версиями Postgres и выполнена логическая репликация со старых на новые базы данных. Для реализации первоначального дампа и восстановления Retool воспользовалась Warp, а Knock создал собственные публикации и подписки для инкрементальной миграции.
- Инкрементальная миграция данных. Таблицы были разбиты на категории по размеру и частоте обновлений. Маленькие таблицы добавили в репликацию и синхронизировались быстро. Для крупных таблиц, рассчитанных только на добавление данных, компании использовали отдельные публикации с copy_data = false с последующим backfilling. Для крупных часто обновляющихся таблиц были разработаны индивидуальные стратегии миграции.
- Тестирование и верификация. На новых версиях баз данных было проведено тщательное тестирование. Компании сравнивали количество строк и сэмплировали данные между старыми и новыми базами данных, проводили нагрузочные тесты для проверки производительности и выполнили множественные тестовые прогоны в staging-окружениях.
- Изменения в приложениях. После тестирования компании внесли изменения в свои приложения, обеспечив поддержку подключений и к старым, и к новым базам данных. Были реализованы механизмы для переключения трафика со старых на новые базы данных, например, флаги фич.
- Стратегия окончательного переключения. Этап окончательного перехода был запланирован на периоды с низким трафиком. Retool использовала окно технического обслуживания длительностью примерно один час, а Knock обеспечила почти нулевой даунтайм с небольшой паузой в новых запросах.
- Задачи после миграции. Далее они верифицировали целостность данных и функциональность приложений, оптимизировали новые базы данных (например, выполнили переиндексацию и vacuuming), проводили в последующие дни мониторинг, удалили старые системы репликации и вывели из эксплуатации старые базы данных.
Да, это большой объём работы, и его никак не избежать. Апгрейд базы данных Postgres в продакшене вперёд на несколько версий требует существенных вложений времени и ресурсов. Многие организации может пугать такой объём затрат, поэтому они часто откладывают апгрейды до тех пор, пока те не станут абсолютно необходимы.
▍ Аргументы в пользу апгрейдов
Несмотря на всё это, мы рекомендуем вам апгрейдиться!
Даже если вас не убедили потрясающие новые возможности Postgres 17, то есть и другие причины:
- Вам всё равно придётся это сделать рано или поздно. Версии Postgres имеют жизненный цикл, и поддержка каждой версии когда-то закончится (спустя пять лет после релиза).
- Перепрыгивать несколько версий за раз сложнее. Чем дольше вы откладываете апгрейд, тем больше версий вам придётся в итоге перепрыгнуть. В случае апгрейда лучше перепрыгивать как можно больше версий, но если вы пропустите пять или больше версий, то возникнет множество проблем с совместимостью и изменений, ломающих обратную совместимость.
- Ваше приложение может потерять актуальность. Новые версии Postgres содержат оптимизации производительности и новые возможности, которые могут улучшить ваши приложения. Оставаясь на старой версии, вы не сможете воспользоваться теми улучшениями, которые могут повысить скорость и эффективность вашей системы.
- Совместимость. Новые фреймворки, библиотеки и инструменты могут выпускаться без совместимости со старыми версиями Postgres. Обновлённые API или расширения могут не иметь обратной совместимости, мешая интеграции инструментов или требуя сложных обходных решений.
▍ Проверьте, что вы теряете: pgversions.com
Частично отсутствие мотивации к апгрейду вызвано необходимостью ручного сравнения release notes между версиями и выявлением недостающих вам улучшений. Чтобы упростить этот процесс, мы создали инструмент https://pgversions.com/. Он позволяет быстро выявлять улучшения, которые вам недоступны из-за использования старой версии Postgres. Например, если у вас установлена Postgres 16.1, то pgversions.com сообщит, что вам недоступны:
- 4 улучшения безопасности.
- 177 баг-фиксов.
- 24 улучшения производительности.
- 10 новых функций.
Если pgversions наконец-то придаст вам мотивации к апгрейду, то можете изучить раздел отчёта
How to upgrade, в котором приведены ссылки на документацию различных поставщиков.Telegram-канал со скидками, розыгрышами призов и новостями IT ?
Комментарии (50)
ky0
21.10.2024 14:11Буквально на днях обновили у одного из клиентов 9.5 до 15 :)
Работало с 2015 без проблем - предполагаю, что теперь ещё 10 лет проработает.
redfox0
21.10.2024 14:11PostgreSQL 9.6.5 от 2016 года.
Версию оракла же даже называть стыдно, где-то 2003 года, работает до сих пор (и работает даже лучше, так как за эти года стало меньше десктопных клиентов, которые открывали по 10-20 соединений за раз)
juniorcoder
21.10.2024 14:11Многие не меняют, простите, трусы и носки и одежду годами, да-да я имею ввиду как обычных так и IT субъектов. И как раз ход мыслей большинства людей направлен на то, что оптимизация это и есть "не трогать и не менять ничего на новое! Как раз новое и "пресловутое исправление" чего-то — это скорее мутация, нежели правило повседневное! Рекламная жизнь и рекламные лозунги о новом гаджете и новом ПО, совсем не отражают реальную жизнь и психику людей.
gsaw
21.10.2024 14:11Наверное 80 процентов проектов используют postgres для стандартных insert/update/select/delete причем через какой нибудь фреймворк, который все эти запросы генерирует и большинству все равно, что за база данных там. Работает и ладно. Если MySQL в свое время своими лицензиями не запутал, то может и MySQL оставался выбором номер один для мелких и средних проектов. Теперь postgres вытеснил MySQL.
А вторая причина, это наверное стоимость миграции. В энтерпрайзе любое движение стоит огромных денег. Просто так переезжать никто не будет, сначала надо найти того, кто оплатит этот банкет. А ещё если проект и категории выше, так вообще будут тянуть, пока поддержку версии прекратят. Зачем если и так работает.
Ign0r
21.10.2024 14:11А ещё бывает что инсталляция с конкретной версией PG "прибита" в каком-то сертификате на соответствие (за негуманные деньги) и проводить процедуру повторно ну очень не хочется.
oller
21.10.2024 14:11Из моей практики причина в Легаси коде и не совместимости между версиями, что заставит переписать часть кода, а на это обычно нет рук
С другой стороны стоит безопасность, конечно же
Все новые проекты делаются с новейшими базами, а вот старые обновить иногда на гране фентези, правда у нас проекты не смотрят во вне.
morijndael
21.10.2024 14:11Думаю, если бы постгрес не требовал танцев с бубном над своей базой, а просто автоматически обновлял схему при запуске новой версии, то и обновляли бы охотнее :(
А так, новый постгрес поставь, старый оставь, потом всё останови, в нужной последовательности оба постгреса запусти...нунафиг в это лезть
ahdenchik
21.10.2024 14:11А так, новый постгрес поставь, старый оставь, потом всё останови, в нужной последовательности оба постгреса запусти...нунафиг в это лезть
pg_upgradecluster давно уже завезли - делает как раз это
morijndael
21.10.2024 14:11Что-то не вижу упоминания такой штуки в документации
https://www.postgresql.org/docs/current/upgrading.html
Все официальные методы — либо через дамп в SQL, либо через танцы с двумя постгресами
akhkmed
21.10.2024 14:11В версии 12 реализован ряд изменений, которые могут повлиять на совместимость с предыдущими выпусками.
Некоторые ведь используют oid.
zartdinov
21.10.2024 14:11Если бы postgres старался поддержать обратную совместимость. Любой клиент, который ты скачал начинает кидать кучу ошибок при подключении к новой версии. Дампы у каждой версии особенные. Молчу про расширения, настройку параметров и поиск нужных драйверов. Сейчас версии выходят слишком часто, можно только этим заниматься периодически. Сайтик (что упускаешь из-за старой версии) - это круто, конечно. Но останавливать прод чтобы снова этим заниматься, когда только успел забыть еще круче.
ahdenchik
21.10.2024 14:11Любой клиент, который ты скачал начинает кидать кучу ошибок при подключении к новой версии.
Странно это - протокол не менялся со времён царя Гороха
Сейчас версии выходят слишком часто, можно только этим заниматься периодически.
А вот это - да! Раньше раз в несколько лет выходило с долгожданными добавлениями, а теперь не успеваешь changelog читать!
galaxy
21.10.2024 14:11Первые три предложения - феерический бред, уж пардон
zartdinov
21.10.2024 14:11Скачайте какой-нить pgAdmin постарее или попробуйте восстановить дамп через несколько версий одними и теми же инструментами.
Но это фигня. Феерично, если еще есть специфичные расширения, вместе пакетами в ОС, или вообще собраны из исходников.
DMGarikk
21.10.2024 14:11Скачайте какой-нить pgAdmin постарее
(вспомнил pgadmin в доэлектронной версии...заплакал от приступа ностальгии и безысходности)
у меня помнится был тимлид который юзал старый пгадмин с какимито костылями чтобы он работал на новых версиях постгри....ошибками сыпал влево и вправо но кое как работал...
galaxy
21.10.2024 14:11А почему я должен скачивать pgAdmin постарее (отдельный вопрос, на кой черт для восстановления дампа вообще pgAdmin)? Берете софт от новой версии (pgAdmin, pg_restore, psql) и заливаете дамп со старой версии в новую. Проблем обычно не будет (все incompatibilities описаны первым пунктом в Release notes).
В обратную сторону не сработает, так никто и не стремился это обеспечить (по факту через минимальные правки SQL дампа ручками сработает почти всегда).
Вы конкретизируйте свои претензии, а то читается действительно как бред. Например:
Любой клиент, который ты скачал начинает кидать кучу ошибок при подключении к новой версии
Да ну. Работоспособность клиента только от версии протокола зависит, а он сто лет не менялся. Вы, скорее всего, имели в виду свой pgAdmin, который тул для администрирования СУБД и лезет ей в кишки для выполнения своих задач. Ну как бы странная претензия - берите инструмент, совместимый с вашей версией, иначе ССЗБ.
Молчу про расширения, настройку параметров и поиск нужных драйверов
Что не так с расширениями? Ставьте совместимые с вашей версией, благо они по большей части прямо в комплекте идут. Нестандартные расширения компилируйте под нужную версию. Проблемы с совместимостью специфических расширений пусть решают их разработчики - как тут даже теоретически совместимость можно обеспечить, если расширение - это библиотека, встраиваемая в сервер, и оно вообще может творить все, что угодно?
Параметры... ну такое. Обычно их вообще трогать не нужно (не считая настройки производительности через какой-нибудь pgtune). А если у вас там мега-кластер с репликацией во все стороны и тонкими настройками, то за это обычно DBA деньги и платят - пусть читает доки и разбирается.
И что за драйверы вы там потеряли?
zartdinov
21.10.2024 14:11Ничего не понял, как будто повторили мой фееричный бред. Тут уже писали про танцы с бубном, хотя по факту ничего особо не меняется. Раз в полгода можно и более полезными вещами заниматься.
Я не противник постгреса, если вы из адептов) Аптайм старой базы около 2 тыс дней, штука максимально надежная. Есть похожий сервис в котором постоянно обновляется постгрес через разные действия, но не сказать, что это прям что-то дало за столь большое время.
pgAdmin просто как пример чтобы было понятно, он уже давно умер скорей всего. Драйверы обычно во всяких языковых библиотеках, только в идеальном мире достаточно обновить базу.
Armann
21.10.2024 14:11По некоторым комментам сразу видно тех кто не проводил увлекательное время в попытке восстановить систему :) солнце давно зашло, а утром кровь-из-носа все должно работать.
После такого опыта как то по другому относишься к 'быстренько обновить, новая версия лучше же'
mc2
21.10.2024 14:11В облаках, емнп, последняя рабочая версия, 15. Можно сделать себе сервер и самому развлекаться, но это деньги.
LeVoN_CCCP
21.10.2024 14:11Потому что прекрасно помнится история перехода на 14, когда у одного параметра дефолтное значение поменялось на противоположное и получилось очень увлекательное приключение (когда читаешь).
Ну и исходя из этого, не хочется разгребать проблемы на реальном рабочем месте из-за того, что кто-то что-то где-то изменил в коде движка базы и он теперь работает совсем не так. Тестовый контур тут тоже не особо может помочь, из реального опыта два одинаковых дистриба линукса, одна и та же версия ПГ, настройки абсолютно идентичные, но в одном Archive settings при WAL репликации работают по одному, а в другой по другому. Хоть клонируй прод в тестовый контур, но проблема подхвата учёток в данных встанет в рост.
Gummilion
21.10.2024 14:11В MS SQL Server у баз есть свойство compatibility level - специально для того, чтобы при переходе на новую версию СУБД база вела себя как раньше (ну, по крайней мере в теории). В Постргес такого не завезли?
LeVoN_CCCP
21.10.2024 14:11Я так скажу, что это свойство просто форму плана возвращает к прежней, есть также опыт когда приходилось оставлять 110 на 2016 и нельзя было переходить на 110/2019 из-за нюансов старого приложения с запросами.
Отвечая на ваш вопрос - подобного в ПГ (Compatibility level) я не помню.
kamenschikov
21.10.2024 14:11У меня в банковской системе версию PostgreSQL обновляют с опозданием, новые версии сразу не ставят, ждут проверку временем, наличие стабильности без баг. Так например более полугода назад только перешли с версии PostgreSQL 13.6, на PostgreSQL 15.3, в данный момент только на новые БД ставят PostgreSQL 15.6, на 17 наверное перейдет только через год.
rinace
21.10.2024 14:11наличие стабильности без баг
А как вы узнаете отсутствие баг в новой минорной версии ?
Например - баг с online_analyze после обновления на 15.8.1.
Hve2024
21.10.2024 14:11я вообще боюсь что то нажимать, влево вправо, вске к чертям слететь может, так что нуево это обновление
esisl
21.10.2024 14:11Интересно, а проблему неподнимаемости слетевших индексов они решили?
Я пару раз нарвался и зарекся связываться, когда официальная поддержка на вопрос: как починить слетевшие индексы, рекомендует поднять рабочую копию из бэкапов...
leon-mbs
Потому что святая заповедь - не трожь пока работает
amarkevich
DevOps из вас так себе
leon-mbs
так я и не devops потому и не тянутся руки все обновлять переустанавливать и перенастраивать чтобы оправвдать свою зарплату.
особенно с учетом что devops это маркетинговая мулька ПО ФАКТУ - это те же системные алминистраторы
vanxant
отличный девопс, если что:) опытный)
turbotankist
Sre это)
MaxxDamage
Девопес
Wesha
Ибо завещал великий Учитель Инь Во Фу: не чини что не поломано!
13werwolf13
фигня это а не заповедь
чем дольше не трогаешь тем больнее будет когда потрогать прийдётся, а однажды прийдётся потрогать 100%, и скорее всего в срочном порядке.
"работает - не трожь" это поговорка ленивцев любящих стрелять себе в ноги, не раз видел как блюстителей этой "заповеди" шумно увольняли за дорогостоящие факапы/взломы/etc.
leon-mbs
Ну поговорка времен моей работы электронщиком но тут тоже подойдет.
Обновление еще не делает програму надежнее - пример тому недавний сбой в винде по всему миру. Обновили на свою голову - причем ПО именно безопасности
Нужно решать проблемы по мере поступления - есть лырка конкретная ее и надо затыкать
а проблемы производительности зачастую можна рещить просто добавить памяти ядер проца или перемещением на ssd диск
Лет пять наад в моей фоирме был проект итальянского банка дописать работающее там черти сколько лет ПО на языке Cobol.
Просто посчитали деньги и рещили что проще дописать хоть и пришлось ставить эмулятор AIX
У нас уже бы убедили заказчика что все надо переписать (на яваскрипте естественно) добавить блокчейн ну и само собой ИИ
13werwolf13
Ну так почитать ченджлоги, погонять на тестовом стенде, при достаточном уровне компетенций и в diff заглянуть.. Всё это входит в процесс обновления и идёт в разрез с "работает - не трожь".
И да, бывает что не закапывать стюардессу выгоднее чем найти живую, но во первых выгодно не значит правильно, а во вторых то что выгодно в ближайшей перспективе может оказаться очень невыгодно на дальней дистанции. Конечно клиент может захотеть сэкономить сейчас а завтра пусть трава не растёт, и это его право ибо это его инфра, но для себя в своей инфре я такого не допускал бы..
DMGarikk
Допускал не допускал, это слова старшего админа, максимум начальника отдела, а правильные слова - есть бюджет, вы в него попадаете с учётом рисков потенциального снижения устойчивости сервиса при нештатной работе улучшайзингов?
13werwolf13
если обслуживание сервиса X выходит за рамки бюджета значит надо или похоронить сервис X или изменить размер бюджета, но никак не класть на сервис X большой и ржавый болт.
DMGarikk
многие сервисы могут не приносить прямого дохода, являясь инфраструктурными и их обновления откладывают до тех пор пока не становится невозможно работать, потому что переход с постгри 10 до 14 не принесет бизнесу...ничего, только минусовую строчку в расходах...так зачем это делать? потенциальный рост производительности? а если там и так запас по скорости на 10 лет роста вперед? а такие работы только повышают риск простоев....кругом минусы, а радуются только перфекционисты админы
Этим кстати объясняется существование кобол систем до сих пор
13werwolf13
простите, но для меня странно в этом контексте делить доход на прямой и косвенный, как и забывать про такую графу как "потенциальные убытки" к которым может привести любое забытое CVE в каком нибудь неприкрытом сервисе. И да, тут речь не только про финансовые убытки но и репутационные потери которые тоже косвенно ведут к финансовым убыткам. и да, речь тут больше не про СУБД которые крайне редко торчат жопой в интернет а про весь софт в целом, но я считаю что подход к обслуживанию ЛЮБОГО софта в инфраструктуре должен быть максимально насколько это возможно одинаков.
вот это как раз чаще всего для субд внутренних нужд не самое важное, куда как важнее потенциально продолбать данные от какого нибудь незакрытого бага или найти свои данные в продаже..
простои не всегда обязательны, а те которые не избежать должны быть заложены в план работ ещё на этапе планирования сервиса.
но минусов я что-то не увидел
обычно радостный префекционист-админ уже означает нормально работающую а потому приносящую прибыль инфраструктуру, бояться надо админов рвущих седые волосы со всего тела и яростно листающих HH в поисках куда бы сбежать с тонущего корабля..
к тому же если расходы финансов и человекочасов обновление постгри или любого другого софта пусть даже в не самом важном для функционирования компании сервиса становится ЗАМЕТНЫМИ в общей массе значит инфраструктура (или весь бизнес в целом) спланированы настолько печально что гораздо лучше будет ВСЕМ такой бизнес остановить и отправить на свалку истории.
P.S.: я в целом согласен что именно для постгри процесс апгрейда выглядит как какой-то привет из прошлого и шаманство, но это не значит что стоит лениться его делать.
DMGarikk
я тоже так считаю, но бизнес так не считает и это прямое его право, потому что он деньги платит за нашу с вами работу
иногда дешевле огородить сервис вокруг чем его переписать или обновить
Бизнес учитывает и эти риски тоже, но это зачастую решается изоляцией контуров и внедрение всяких IDS систем и систем обнаружения утечек
там есть такая штука что утечка как таковая - это инцидент который измеряется деньгами и совсем не факт то деньги этого инцидента будут больше чем содержание отдела разработки и поддержки постоянного обновления, с учетом вероятности наступления этого риска в рамках иных действий
например я своими ушами слышал фразу "если у нас украдет данные сотрудник, то мы просто подадим на него в суд, зачем нам еще както ограничивать доступы? у него в договоре написано что ему это запрещено делать" (с)
и вот также по всем пунктам. бюджет на всякие репутационные потери и компенсации это отдельная строка бюджета и кпи работы департаментов зачастую не связана с уменьшением подобных затрат
Это вот факт с которым мы все живем, практически без исключений.
простой может возникнуть если чтото пойдёт не так, на моем опыте было пару раз такое... ни 5 тестовых контуров ни многонедельная подготовка не смогла предусмотреть что на боевой СУБД не посыпятся индексы в момент миграций, а сотрудник который этим занимался решил забить на предварительную проверку резервного контура который тупо не стартанул в самый ответственный момент.
минусы - это затраты, а плюсы - уменьшения какихто иллюзорных рисков вероятность наступления которых довольно спорная
Думайте как топ-менеджер, а не как админ, будет понятнее
как вы думаете в банковском процессинге, ключевой системой инфраструктуры является СУБД, её обновление это огромный и очень сложный поход к которому готовятся несколько лет... нужно на свалку истории его отправлять?
В банке, АРМ операторов, они работают на терминальных серврерах, замена и существенное обновление инфраструктуры влечет за собой риски что "всё упало, все наши 100500 отделений сегодня закрыты"..это дорого и сложно. у меня было около 300 отделений и ферма на 10 серверов которая их обслуживала...даже просто апдейты виндовые ставились там по определенному расписанию чтобы не всё сразу упало...а оно падало иногда...было весело.
13werwolf13
я не знаю как у вас, но мне платят за работу целиком а не за её часть. я не являюсь конечным исполнителем который только делает ровно то что приказано и ни шагу в сторону, я принимаю участие в подобных решениях.
это тот случай когда я говорю: не "или" а "и"!
кирпич по голове на выходе из подъезда тоже считался илюзорным когда-то, а сейчас все выходы имеют защитные козырьки, нам с вами повезло что в нашей профессии ошибка не часто стоит чьей-то жизни, но это не повод допускать ошибки пачками
как по мне так все банки и текущую экономику в целом давно пора отправить на помойку истории, в кучку с названием "позор человечества".
по вашему комментарию насквозь протекает идея экономии на спичках
что-то пошло не так при обновлении - долгий простой, а не быстрый откат на снапшот
упал терминальный сервер - все операторы не работают, а не переключаются на резервный автоматически.
меня жизнь давно научила что экономия на спичках приводит к ещё большим тратам "кроилово приводит к попадалову ©" инными словами.
DMGarikk
у меня есть опыт работы в крупных холдингах и компаниях, я конечно отвечаю за разработку, но некоторые пересечения есть с указанной темой
грубо говоря у меня есть план развития продукта на полгода вперед и если я вдруг скажу что следующие два спринта команда будет не пилить фичи, а переезжать на новую версию кубенрнетса...который ничего не даст в плане появления новых фич. ко мне придет финотдел и спросит "а чем вы там вообще занимаетесь? у нас TTM у продукта не пострадает? пользователи от вашей работы получат фичи позже на полгода? что?"
Мои предшевственники тут занимались тем что 3 года разрабатывали продукты которые вообще ниразу не добрались до MVP стадии, зато они написано на свежайшем питоне, свежайшей джанги, раскатывается всё новейшей версией ci/cd ..офигеть да..можно еще лет 5 пилить
Я рад за вас что вы можете такие решения принимать и их реализуют, я пока до такого не дорос
Что имеем то имеем, ошибки это всеголишь цифры в списке оценок рисков...все риски предусмотреть невозможно, все хотят чтобы все разработчики были сеньорами, чтобы софт писался быстро и без багов и бюджеты были безлимитные... а в реальности это не так и чемто надо жертвовать чтобы попадать в доходность продуктов
вон возьмите яндекс который на любой спор выдает промокод, потому что оценили риск лояльности клиентов в условные 200 рублей и вообще забили на исправление некоторых бизнескейсов...и что? а ничего! все счастливы и рады..бабло капает такси ездит. вот тут тоже самое
можно с этим не соглашаться, но с этим придется жить
весь мир до основания я разрушу...а потом... дада, всё понятно ;) но это уже тема другого спора
Вы спичками считаете цифры измеряемые сотнями тысяч долларов
вас не поражает с какой лёгкостью корпорации сокращают людей? я вот попал разов в этот процесс. утром на дейлик приходит HR и говорит что ваша команда работает последнюю неделю, а некоторые участники последний день...а потом ты узнаешь что сократили 3 департамента... потому что риск падения доходности компании чуть вырос, а продукт то дальше продолжает работать без персонала...и что? ох ох беда, никто не обновляет и не следит? а потому что риск остановки продукта ниже риска падения доходности...вон посмотрите на твиттер...там вообще всех уволили..и что? потрясло немного сервис но он работает дальше. и бизнес это отличное понимает
поймите что решения принимаются именно из таких соображений, а не потому что ядро линукса надо срочно обновить на 800серверах компании и потратить на это 500тыщ долларов потому что в редакторе vi уязвимость нашли которая возможна именно с нашим ядром линукса
13werwolf13
А должно? Если меня сократят это не мои проблемы, я то себе работу найду всегда, а вот моя контора останется без хорошего лояльного сотрудника. Если их это устраивает, ну ок, это их выбор кто я такой чтобы его оспаривать.
Более того, есть ряд вещей в случае которых я сам покину контору без обсцждений и не поддамся ни на какие уговоры.
DMGarikk
я указываю на то что компании принимают решения руководствуясь совершенно другими сущностями и мнение админов на то как должна выглядеть инфраструктура ИТ тут даже не в первой десятке таких аргументов
"контора останется без лояльного сотрудника" - вы преувеличиваете свою значимость, останется без лояльного, возьмут другого лояльного. тут нет смысла рассуждать их потери.
еще раз, им вообще плевать как там и что у айтишников, им важны бабки, сроки и риски. всё
13werwolf13
Такие конторы обречены тратить на инфру больше а получать с неё меньше
Я не преувеличиваю свою значимость и не рассуждаю об их потерях, я лишь показываю своё отношение к таким ситуациям
А "взять" другого лояльного это фантастические сказки от HR. Лояльным сотрудник станет лишь со временем (правда с тем же успехом он может стать не лояльным а ненавидящим).
DMGarikk
Вы делаете такой вывод с позиции с которой не видите все финансовые потоки, а лишь предполагаете как они проходят и на что тратятся
Вот вы как рассуждаете? "Оо, компания тратит 100000долларов в месяц на исправление багов, потому что у нас всего 2 админ которые разрываются на части чтобы собирать рассыпающуюся инфру и наверное теряет деньги из-за 1-2 падений в квартал" надо взять отдел из 15 человек, с дежурными, с пятью сеньорами, и сделать инфру сверхустойчивой... и тратить по 900000долларов в месяц!
т.е. получается что в первом варианте компания тратит 300тыщ долл в квартал, а во втором 2млн700
А устойчивость возрастет с 1-2 падений в квартал, до 1 падения в год! ВСЕГО!!
т.е. рост устойчивости сервиса стоит очень дохрена, а выхлоп в бабле будет минимальный
незаменимых людей нет (за очень редким исключением и касающегося зачастую топменеджеров, а не рядовых сотрудников), сказки не сказки, но бизнесу плевать на людей.
Я вот сейчас попал на работу где ушел ведущий разработчик, вот просто ему захотелось сменить работу и всё (очень своеобразный товарищ)...и сработал эффект автобуса..потому что никто документацию не вел, а продукт у нас крайне сложный...и что все померли? а ничо не случилось, даже сроки выпуска мвп не съехали... но тут он сам ушел...а сократить его могла и компания по своим какимто соображениям, и продукт также передали бы комуто ещё
K0styan
Бюджет - штука многофакторная. Есть свои риски при не-обновлении. Есть стоимость поддержки - например, другая система регулярно обновляется, и приходится коннектор между ней и легаси постоянно обновлять.
Так что правильный ответ тут простой и сложный одновременно: универсального решения нет, всё надо считать для конкретного ландшафта.