а не проще заодно ещё бд сменить? хотя бы на tidb и clickhouse? разнести функционал и жить спокойно? dba поможет облегчить инциденты, синтаксис у tidb схожий с mysql, функционал поддерживается, а большие выборки по меню и тп вынести в клик.
Потому что это подразумивает не сдельную оплату труда, а процент от прибыли, во вторых, внизу задачи и так берут, только вот задачи должны быть грамотно поставлены, а этого делать не умеют, потому что идёт гонка волевых решений и кто их больше примет. Вы же предлагаете ещё больше ответственности внизу, и вообще убрать сверху.
а про глупость и не сказано, сказано, что всех интересует только имитация деятельности, надо принять как можно больше решений, ведь их эффект будет только среди челяди, а верхи и дальше будут жить спокойно
а ещё способ который описан про панель задач работает только с главным монитором, на второй и 3 не работает, в итоге у тебя 1 монитор будет сверху панель, а остальные снизу, но самая жесть это языковая панель, в одной из обнов она исчезла, кое как её вывел отдельным виджетом который теперь болтается на экране....
Сам Яндекс уже вроде как слезает с клика, на YDB, которая совсем не клик. это как кассандра и инстаграмм, выкинули в опенсорс чтобы посмотреть как будет жить вне их экосистемы самостоятельно.
Реклама конечно шикарная, только вот потом приходишь на проект, где внедрена эта чудо БД, и не знаешь, когда данные потеряются(если говорить мягко), а программисты один хрен его не понимают и главное не хотят его понимать, конфигурация ужасно неудобная. После Oracle/Vertica конфиги кликхауса выносят мозг.
Простота очень спорное утверждение, на вопросы которые у нас возникали найти решения чаще всего было просто негде, даже по Elassandra проще. Документация написана для своих, банально создать юзера с нужными значениями выходит чтение 12 разных страниц доки, и зачастую даже достаточно криво написанных, особенно в сравнении с Oracle. Описание движков достаточно скудное, и многие вещи программистам часто непонятны вообще.
На мой взгляд кликхаус удобная бд для аналитики, но хранить в нём данные и использовать его как фронт — это мазохизм.
Клиенты были подключены на чтение, данные, как было написано старые, записям более 5 часов. Более подробно не распишу, т.к. доступа к серверам того клиента которому выполняли работу более нет. Руками перенесли 10 записей. Причём каждый раз не хватало разных записей, если говорим про удалить таблицы и залить заново.
Проблема ещё во времени процессора, и не всегда разрешены или будут использоваться инкрементальные бэкапы, зачастую клиент хочет полный бэкап данных раз в 1-2-4-6-8-12 часов.
проблема в том, что даже это не до конца помогает, причём даже на небольших объёмах, например pg_dump иногда игнорирует некоторые записи, и при переносе базы на новый сервер через backup вы имеете отставание на n записей, а настроить репликацию тоже можно не всегда.
Приведу пример, есть бд, размер 30 гб, делается pg_dumpall чтобы переехать на более новую версию пг и на новый сервер, делается pg_dumpall, после рестора оказывается не хватает 5 юзеров и 8 счетов на оплату, хотя они были сделаны ещё 5 часов назад. С просто pg_dump выходит таже история, магическим образом не попадают в дамп 10-16 записей.
Не знаю как с выше описанным инструментом дела обстоят, но причуды бывают везде. А когда говорим ещё о базах где iowait зачастую под 80%, тк индекс существенно больше оперативной памяти, и там идёт сложный запрос с джойнами, то многие способы бэкапа могут вообще поставить бд раком, и проблема в статье автора, что по факту пользы она не несёт никакой, кроме рекламы инструмента, который даже не ясно как себя ведёт на нагруженных бд, а не где 2 кб данных.
Не говоря уже про то, что использование cron в 2020 году уже в принципе так себе затея и лучше использовать systemd-timer, который в отличии от крона имеет нормальные отчёты и нормально мониторится.
проблема в том, что сам бэкап делается быстро и pg_dumpall, а вот restore это отдельная боль, особенно, если база стоит на hdd и у вас медленный(низкой частоты) процессор, и в итоге мы приходим к тому, что при базах свыше 40 тб большая часть способов бэкапа пг бесполезные практически
методология работает, когда под неё перестраивают бизнес процессы, и добавляется новая роль sre\devops\devsecops, но добавляется новая роль, а не убирается 5 старых и садится 1 человек на обязанности 5.
а он не обязан разбираться в этом, это отдельный мир сетей, там нужно знать очень много, и поддерживать в актуальном состоянии знания по мере изменения, например если у тебя больше 2 spine свичей, то извните, но вам на ipv6, а это вообще отдельный мир, который не каждый сетевик знает.
ещё веселее когда код есть, но он уже не применяется, и в зависмостях в 1 из 200 файлов маскируется, и вот сиди думай… а такие часто, особенно когда ролей тьма и их сотни
да, теперь 2 недели чтобы разобрать роли, зависимости и проблемы.
зачастую проще вообще с нуля всё писать, и переносить всё в 0, что опять же 2-3 недели, но раньше было существенно меньше сервисов ненужных, а сейчас зачастую только nginx это 30-50 контейнеров.
Тм более как говорят техдиры с большой з\п — технологии и тд не их проблемы, их задача делать волевые решения и находить виновных, наказал — молодей вот премия за волевые решения. Решения приводят к проблемам, но это плохие девупсы и кодеры, а он хороший, решение то волевое принял.
а не проще заодно ещё бд сменить? хотя бы на tidb и clickhouse? разнести функционал и жить спокойно? dba поможет облегчить инциденты, синтаксис у tidb схожий с mysql, функционал поддерживается, а большие выборки по меню и тп вынести в клик.
Потому что это подразумивает не сдельную оплату труда, а процент от прибыли, во вторых, внизу задачи и так берут, только вот задачи должны быть грамотно поставлены, а этого делать не умеют, потому что идёт гонка волевых решений и кто их больше примет.
Вы же предлагаете ещё больше ответственности внизу, и вообще убрать сверху.
а про глупость и не сказано, сказано, что всех интересует только имитация деятельности, надо принять как можно больше решений, ведь их эффект будет только среди челяди, а верхи и дальше будут жить спокойно
Скорее я человек с 2 по русскому, которому ставили 3, чтобы не парится))))
а ещё способ который описан про панель задач работает только с главным монитором, на второй и 3 не работает, в итоге у тебя 1 монитор будет сверху панель, а остальные снизу, но самая жесть это языковая панель, в одной из обнов она исчезла, кое как её вывел отдельным виджетом который теперь болтается на экране....
Сам Яндекс уже вроде как слезает с клика, на YDB, которая совсем не клик. это как кассандра и инстаграмм, выкинули в опенсорс чтобы посмотреть как будет жить вне их экосистемы самостоятельно.
Простота очень спорное утверждение, на вопросы которые у нас возникали найти решения чаще всего было просто негде, даже по Elassandra проще. Документация написана для своих, банально создать юзера с нужными значениями выходит чтение 12 разных страниц доки, и зачастую даже достаточно криво написанных, особенно в сравнении с Oracle. Описание движков достаточно скудное, и многие вещи программистам часто непонятны вообще.
На мой взгляд кликхаус удобная бд для аналитики, но хранить в нём данные и использовать его как фронт — это мазохизм.
Проблема ещё во времени процессора, и не всегда разрешены или будут использоваться инкрементальные бэкапы, зачастую клиент хочет полный бэкап данных раз в 1-2-4-6-8-12 часов.
Приведу пример, есть бд, размер 30 гб, делается pg_dumpall чтобы переехать на более новую версию пг и на новый сервер, делается pg_dumpall, после рестора оказывается не хватает 5 юзеров и 8 счетов на оплату, хотя они были сделаны ещё 5 часов назад. С просто pg_dump выходит таже история, магическим образом не попадают в дамп 10-16 записей.
Не знаю как с выше описанным инструментом дела обстоят, но причуды бывают везде. А когда говорим ещё о базах где iowait зачастую под 80%, тк индекс существенно больше оперативной памяти, и там идёт сложный запрос с джойнами, то многие способы бэкапа могут вообще поставить бд раком, и проблема в статье автора, что по факту пользы она не несёт никакой, кроме рекламы инструмента, который даже не ясно как себя ведёт на нагруженных бд, а не где 2 кб данных.
Не говоря уже про то, что использование cron в 2020 году уже в принципе так себе затея и лучше использовать systemd-timer, который в отличии от крона имеет нормальные отчёты и нормально мониторится.
зачастую проще вообще с нуля всё писать, и переносить всё в 0, что опять же 2-3 недели, но раньше было существенно меньше сервисов ненужных, а сейчас зачастую только nginx это 30-50 контейнеров.