Информация
- В рейтинге
- 541-й
- Откуда
- Россия
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Администратор баз данных, DevOps-инженер
Ведущий
От 350 000 ₽
Git
SQL
Базы данных
Разработка программного обеспечения
Проектирование баз данных
T-SQL
Microsoft SQL Server
Microsoft SQL
Как вы в забиксе планы анализируете? Как список сессий смотрите, как блокирующие процессы в текущий момент? Zabbix хорош для долгосрочного хранения метрик. Spotlight - для оперативного анализа здоровья сервера. Один инструмент для всех задач. Каждому своё, не понимаю, зачем вы "обиделся что ушли" сюда приплели, как то совсем не уместно))
Zabbix и Spotlight - это не аналоги. Spotlight, Idera - топовые системы для мониторинга и анализа СУБД, оба сейчас не доступны в РФ. При всем уважении, если Вы думаете, что есть "куча аналогов", то вы просто не работали с этими системами и не в контексте.
А накладные расходы не превышают расходы аналогичных систем.
Именно, вопросы могут быть только к повторинию основного функционала, код разумеется полностью свой, используемые коллекторы универсальные, вся аналитика давно предоставлена в лучших практиках. Возможно сначала стоит развить больше собственного функционала и модет быть немного переосмыслить внешний вид.
Опытом я поделился, решение описано полностью. Пользуйтесь.
Показать что уже есть, вдруг кто-то заинтересуется и захочет присоединиться например к разработке.
Проект находится в приватном гите, опасаюсь возможных претензий от Quest Software)
Тоже было желание собрать что-то подобное на 4х 3090. Как я понял, результат все равно получился не айс. Учитывая, что карты все равно будут выходить из строя и цена сборки продолжит расти.
У нас в командах только один человек ответственен за деплой изменений в прод и у него задача, что-бы деплой прошел штатно. Делать, что-то или не делать в этом случае, он сам принимает решение. В любом случае, он убедится, что миграция была протестирована.
Не понятно просто что именно вы хотите. Если не хотите проверять миграции, которые вы накатываете на прод - не проверяйте. Если хотите проверять - проверяйте.
Тем временем мы вполне успешно пользуемся системой, которая готовит миграции по 11 тысяч строк:
Которая успешно была сначала протестирована и залетела на прод.
Одно другому не мешает, уверяю, нет ничего сложного глазами пробежаться по подготовленному скрипту миграции, выкатить его на stage, а после теста на прод.
Всегда нужно тестировать то, что выкатываем на прод.
Было бы отлично, если бы вы написали об этом аналогичную статью. Это было бы очень полезно!
Если мы говорим обо одном и том же.
В какой момент RedGate Flyway генерирует миграцию, как выглядит эта миграция? Это пересоздание объектов или он так же обработает новые столбцы в таблицах, изменения триггера, а не пересоздание его вместе с таблицей? Переименование объектов и ли полей внутри таблицы? Возможно мы и изобрели велосипед, такое зачастую случается в наше работе, разве я не прав?)
Ну разве такие операции делаются ежедневно и под нагрузкой? На моей практике такие операции выполняются крайне редко, а если вам нужно изменить тип колонки для таблицы с миллиардом записей, то такие операции поручаются DBA и заранее планируются.
Да, конечно, LLM отлично справляется с распознаванием таких операций.
Qwen-code позволяет использовать облачную модель через консоль. Задача сначала разбивается на шаги и каждый шаг передается отдельному агенту. Те задачу выполняет сразу оркестр агентов, которыми управляет агент-дережор.
У любого деплоя должно быть имя фамилия и отчество) Тимлид на то и тимлид, что-бы быть ответственным за выкатываемые изменения, это скорее организационная составляющая нежели техническая часть процесса. DDL логи хорошо, но они позволяют понять кто уже сломал.
Наш процесс сейчас только на начале своего пути, перед деплоем в прод, миграции сначала будут тестироваться в stage окружении.
Простите, первый опыт.
sqlproj в данном сервисе не применяется. В данной реализации не предусмотрен pipeline на stage, просто потому, что команда находится в процессе "эволюции" подхода к разработке и о тестовой среде еще не договорились, но разумеется это легко реализуется в данной схеме. Реализацию revert миграций мы пока поставили на паузу, обсудив с разработчиками, они пришли к выводу, что быстрее будет внести изменения просто следующей миграцией, а не откатывать все. Данные, которые требуется вносить руками вносятся руками) На это нет запретов, для чего-то есть специально предназначенные модули или простая заявка на выполнение скрипта.