Size: a a a

2021 February 19

AP

Andrey Pashinkin in uptime.community
Здесь должна быть картинка с буром на который намотан кабель.
источник

AT

Askar Timirgazin in uptime.community
«Пелдожи-Кончезеро»  — маленькая Италия прям
источник

AP

Andrey Pashinkin in uptime.community
Там еще Гавнозеро есть.
источник
2021 February 24

A

Artem Artemev in uptime.community
А может у кого то есть удобный процесс контролирования миграций на базу данных?
Не хочется ограничивать dev team в этом. Чтобы они таки могли сами позвать какие то миграции. Но эти ребята умудряются запустить миграции которые на десятки минут блочат базу и это очень больно.
В итоге хочется понять кто и как должен это контролировать.
Как у вас организовано?
источник

S

Stanislav in uptime.community
Ко мне девопсы наши подкатили за этим. Походу носителей знаний о недеструктивных миграциях - единицы
источник

S

Stanislav in uptime.community
Если говорить серьезно, то это то, что стоит бабок. Уверен, что коллеги из ИТСуммы и конкурирующих компаний обладают и этими ноу хау. Так как иначе зачем они существуют?)
источник

IB

Ivan Brotkin in uptime.community
Artem Artemev
А может у кого то есть удобный процесс контролирования миграций на базу данных?
Не хочется ограничивать dev team в этом. Чтобы они таки могли сами позвать какие то миграции. Но эти ребята умудряются запустить миграции которые на десятки минут блочат базу и это очень больно.
В итоге хочется понять кто и как должен это контролировать.
Как у вас организовано?
У нас получается только на организационном уровне контролировать. ПМ при принятии решения о релизе в том числе определяет, есть ли миграции в изменениях и могут ли они пригрузить бд (естественно, решение принимается с участием лидов и ДБшников). но даже с такими ограничениями регулярно бывает больно
источник

S

Stanislav in uptime.community
У вас на пайплайнах должен быть мониторинг таймингов и для каждого шага пайплайна и выявляться отклонение от нормы. И один или несколько из шагов должны являться только миграциями. И все это должны контролировать RE, SRE или DRE
источник

IB

Ivan Brotkin in uptime.community
Stanislav
У вас на пайплайнах должен быть мониторинг таймингов и для каждого шага пайплайна и выявляться отклонение от нормы. И один или несколько из шагов должны являться только миграциями. И все это должны контролировать RE, SRE или DRE
но это уже будет реакцией на отклонение. то есть проблему не предотвратит
источник

S

Stanislav in uptime.community
Я методически выделяю три шага в миграциях: пререквизитная фаза: заливка новых данных, включая копирование данных из старых структур в новые, основная фаза: модификция основных структур и операторов СУБД, пост-миграционная фаза: конвертация или перенос данных, которые можно в фоне задним числом доперенести
источник

S

Stanislav in uptime.community
Ivan Brotkin
но это уже будет реакцией на отклонение. то есть проблему не предотвратит
Если вы мониторите это например на стейджинге(препроде), то в прод гавно не попадет без вашего ведома
источник

IB

Ivan Brotkin in uptime.community
Stanislav
Если вы мониторите это например на стейджинге(препроде), то в прод гавно не попадет без вашего ведома
а, понял. как способ диагностировать возможные проблемы релиза. да
источник

S

Slach in uptime.community
Artem Artemev
А может у кого то есть удобный процесс контролирования миграций на базу данных?
Не хочется ограничивать dev team в этом. Чтобы они таки могли сами позвать какие то миграции. Но эти ребята умудряются запустить миграции которые на десятки минут блочат базу и это очень больно.
В итоге хочется понять кто и как должен это контролировать.
Как у вас организовано?
DBA это контроллирует

сама миграция должна быть встроена в CI/CD
не на пустой базе, а желательно на клоне

миграции для PostgreSQL можно проверять через клоны https://postgres.ai/

скорость миграции если больше чемХХХ то билд не прошел

как то так
источник

IB

Ivan Brotkin in uptime.community
Slach
DBA это контроллирует

сама миграция должна быть встроена в CI/CD
не на пустой базе, а желательно на клоне

миграции для PostgreSQL можно проверять через клоны https://postgres.ai/

скорость миграции если больше чемХХХ то билд не прошел

как то так
а есть опыт использования? выглядит интересно
источник

S

Stanislav in uptime.community
Женя, хороший критерий - отклонять деплой по таймингу, его нужно на базе допустимого норматива простоя делать.
источник

S

Slach in uptime.community
ой тьфу
источник

S

Stanislav in uptime.community
Викторию кстати кто-то с Украины разрабатывает?
источник

S

Slach in uptime.community
чатиками ошибся
источник

S

Slach in uptime.community
Stanislav
Викторию кстати кто-то с Украины разрабатывает?
@valyala + еще несколько разрабов делают
источник

S

Slach in uptime.community
Ivan Brotkin
а есть опыт использования? выглядит интересно
у меня clickhouse основная база, у этой штуки основной клиент gitlab
они это дело хорошо юзают
источник