Может, у вас все было хорошо, а вот в других компаниях случилась детская неожиданность в 22. Пришлось срочно искать "кряки", чтобы оно продолжило нормально работать. Так что, видимо, все же проблема с лицензиями была, не правда ли?
Вы меня, конечно, простите, но не слышал - не значит, что не было. Как там с лицензиями Jetbrains или с лицензиями Cisco дела обстоят? Насколько хорошо они дали время перейти на "альтернативы"? Первое что вспомнил, а таких кейсов было явно больше двух и уверен, что тут в треде народ накидает.
С ии-ассистентами, конечно, очень смешно получилось. Наконец их эффективные внедренцы косты-сокращатели дошли до шальной мысли - а может сначала надо было просто внедрить цифрового помощника именно как помощника оператора, а не в качестве цифрового заслона клиента от линии тех поддержки? Неужто так много клиентов от всей это радости начали бежать стремглав и жаловаться во все возможные инстанции, что пришлось срочно переобуваться? А что сразу было непонятно, а что об этом разве не предупреждали инженеры высокое руководство, которое уволив половину тех поддержки тут же отчиталось о миллионах экономии после внедрения нового убийцы здравого смысла и миллионов нервных клеток ни в чем не повинных людей?
Пожелаем успехов всем вайбкодерам, которые внезапно столкнутся с необходимостью оптимизации творения тёмного разума ИИ. А ведь столько было копий сломано вокруг того, что дешевле залить инфру деньгами, нежели чем нанимать квалифицированных специалистов и давать им время на оптимизацию ПО. Будет весьма иронично если внезапно в мире разработке ПО правило "make it work, make it right, make it fast" начнёт работать в полную силу, а не лишь его часть. Да и закон Парето внезапно окажется не таким уж и непреодолимым. Одним словом есть шанс что при таких вводных скоро наступит благодать, правда не для всех :)
Какой однако новогодний подарочек, я уже успел забыть про пхп, про yii. Сколько правда хороших воспоминаний, аж олдскулы свело, и круто что дело живёт дальше, пусть уже другие времена, совсем иной технологический ландшафт, но уверен кому-то наверняка это принесёт пользу, а кто-то даже смахнет скупую слезу ностальгии :)
На самом деле статья занятная. Она про то что некоторые современные инженеры совершенно не представляют как в действительности работает железо и сеть, каким образом распределяется нагрузка и как строить распределенные системы, где даже отказ одного дата-центра не приведёт к даунтайму. У них вместо знания технологий один ответ - Kubernetes, магия там внутри, он решает все наши проблемы и даже немного больше. Большая беда конечно когда кубер магия перестаёт работать при определённой возросшей нагрузке, и тогда автор просыпается и проводит бессонную ночь, судорожно выясняя как в действительности магия устроена, если он вообще в состоянии это понять. Надо не искать серебряную пулю, а все-таки изучать как устроен кубер, и как все тоже самое можно спокойно повторить руками на железе или виртуалках, тогда возможно это вам сэкономит время, деньги, а ещё сбережёт драгоценные нервы.
Конечно, быть техно-жрецом здорово, но призываю вас быть скучным профессионалом, который каждую систему стремится разобрать на гайки, чтобы понять, как она в действительности функционирует.
Так была реальная конкуренция, и годами рутуб во многом благодаря такой реальной конкуренции никому был не нужен. Хотя казалось бы можно было что-то придумать. Не блокировать, а сделать так, чтобы реклама и монетизация на ютуб была невозможной по закону. Хотя думаю даже такие травоядные меры далеко бы не все поддержали, потому что реально что-то свое у нас не умеют, не могут и не хотят развивать да и пользоваться своим многие как-то не спешат, что конечно грустно.
В общем тут даже по архитектуре сети видно, что проектом реально начали заниматься фактически последние пять лет, а до этого он жил по принципу пусть живёт работает, много денег у Газпрома не требует, вестимо.
Ну в общем по факту толку мало, все равно подозреваю, что большая часть траффика мимо них ходит, увы. Хотя тема конечно несколько холиварная, как правильно фаерволить траффик, похоже нгфв ответом на это точно не является.
Статья нравится. А ngfw норм нагрузку держат? Это что-то у вас на богатом всякие palo alto шкафы, или получилось траффик пропускать через какие-нибудь ngfw построенные на базе dpdk?
На каком-то очередном абзаце, читая множество разных заумных слов выставленных к месту и не к месту, бесконечных ссылок на "авторитетные" опросы ознакомиться с которыми впрочем невозможно, я наконец понял, что читаю какую-то чатгпт-сгенерированную статью.
Конечно, тема несомненно интересная, но попробуйте все же хотя бы написать её самостоятельно.
Никаких технических подробностей, а хотелось бы узнать как это делается во "взрослом" проекте. Я-то свой простенький сервер поднимал, и ничего интересного, увы, из статьи не вынес.
Вот в качестве упражнения на досуге, ответьте, что вы думаете по поводу шардированного майна по типу проекта https://github.com/MultiPaper/MultiPaper? А как насчёт того, чтобы майн запихнуть в кубер? Почему да и почему нет? И как бы решали подобную задачу? Какие есть особенности тюнинга майна (всеми любимая жава с тысячами разных параметров и разными гс), что в первую очередь требуется потрогать, чтобы из-за взрыва сотен тнт сервер не падал? Какие стандартные настройки вы бы включили на сервере/установили нужные плагины, чтобы его не сломали за один вечер парочка скучающих школьников? Резервирование и восстановление мира (эксплоиты для серверов майна не такая и редкость, и лучше иметь бэкап на готове), как лучше это сделать? А как правильно мониторить работу сервера и на что смотреть?
Вот ответы хотя бы на эти вопросы дали бы огромную пищу для размышлений и позволили бы действительно запустить сервер в майнкрафте :)
>Devops-инжинер - звучит гордо. Только не надо заблуждаться. Чтобы насадить культуру ДевОпс инженером должен быть психолог, т.к. речь про поведение людей и групп
Это вообще так не работает. Культуру невозможно насадить, её можно только вырастить внутри. Честно говоря реальный девопс я мало где видел, не в части наличия каких-то автоматизаций, а именно как культуру разработки и не представляю даже близко, как это делается.
Я сам участвовал в проекте, где девопс действительно насадили причём в формате безальтернативно взяли и забрали доступ от продакшена (таковы были требования ИБ). К сожалению, но по итогу понимания что это и зачем даже спустя несколько лет пришло далеко не всем. Осталось не мало людей для которых не иронично "гит не инструмент разработчика" и вообще верните нам лучше доступ к нашим базам в продакшене (речь про DWH-аналитиков, если что).
Думаю, что подобное разделение чистая условность. Или если хотите маркетинговый ход. Платят больше денег за то, чтобы меня называли DevOps или SRE - и ладно.
Вот я был системным администратором все последние десять лет. Я занимался плюс-минус похожими вещами в разных направлениях и в разных компаниях. Если объяснить бизнесу что на самом деле админ и 10 лет назад умел поддерживать инфру, писал какую-то автоматизацию, занимался мониторингом, то их думаю данная мысль сведёт с ума.
Речь о том, что в целом частые релизы ником образом не снижают риски и не свидетельствуют об наличии автоматизированного тестирования. Сто быстрых выкаток могут быть не менее опасными, чем одна выкатка в месяц.
>Странный у вас "очень крупный финтех", если никакого тестирования перед продом не происходит, ни с вашей стороны ни с стороны заказчика (если он есть)
Там было некоторое приёмочное тестирование для отдельных принятых на сопровождение сервисов, но в чем оно заключалось сказать сложно. Я в целом не очень уверен, что оно велось в достаточной степени, скорее типичные банковские потемкинские деревни.
>Я тоже из этой области, и вот когда мы делали для банка приложение, которое просто по сути делала отчёты анализируя их проводки, они перед продом это всё месяц гоняли на тестовой базе
Ну банк это история смешная. Где-то у вас будет чуть ли не доскональное тестирование, а где-то оно будет отсутствовать в принципе, тк разработчики и заказчики так привыкли, им обязательно надо как можно более быстро выводить изменения. Вообще всегда когда раздаётся странный возглас надо быстрее всегда следует задать вопрос - зачем, какую проблему решаем, нет ли здесь проблемы с тем, что у людей чисто организационные проблемы, что у них плохо в целом с планированием, и они пытаются решить не ту проблему?
>Возможность релизить часто означает, что у вас маленькие, изолированные изменения, хороший уровень автоматизации и тестирования, это снижает риски
На практике, к сожалению, но частота релизов может быть индикатором как раз наоборот особенно дерьмовых процессов, когда менеджменту всегда надо ещё вчера, а как оно там у айти работает их совершенно не касается, и тогда ваш быстрый девопс ничем не лучше становится прямого доступа к продакшену разработчикам.
На моем проекте (очень крупный финтех) мы добились впечатляющей автоматизации, когда в целом изменение пусть и в качестве хотфикса можно было вывести за один час. А всего у нас в день через нашу автоматизацию успешно ставилось на продакшен несколько десятков релизов и ещё несколько сотен параллельно ставились на разные другие среды. Вы думаете у нас было тестирование? Или возможность быстро выводить снизило какие-то в сущности риски благодаря инкрементным изменениям? К сожалению, но это даже близко было не так. По факту мы просто дали разработчикам вместо прямого доступа к проду ровно такой же аналогичный прямой доступ к проду, но только через нашу трубу, и в головах собственно это и осталось, что это просто палка-копалка для доступа к проду.
В общем как и всегда проблема вовсе не в клозетах.
Ну в целом кто пользуется neovim действительно вряд ли нуждается в каких-то IDE, но тут уж вопрос вкусов, что считать нормальной IDE. Боюсь, что не все согласятся с вами. Даже в контексте VS Code.
Может, у вас все было хорошо, а вот в других компаниях случилась детская неожиданность в 22. Пришлось срочно искать "кряки", чтобы оно продолжило нормально работать. Так что, видимо, все же проблема с лицензиями была, не правда ли?
Вы меня, конечно, простите, но не слышал - не значит, что не было. Как там с лицензиями Jetbrains или с лицензиями Cisco дела обстоят? Насколько хорошо они дали время перейти на "альтернативы"? Первое что вспомнил, а таких кейсов было явно больше двух и уверен, что тут в треде народ накидает.
Вообще как старый параноик (правда уж изрядно смирившийся) отвечу правильно - никому. Zero trust и пусть никто не уйдёт обиженным.
С ии-ассистентами, конечно, очень смешно получилось. Наконец их эффективные внедренцы косты-сокращатели дошли до шальной мысли - а может сначала надо было просто внедрить цифрового помощника именно как помощника оператора, а не в качестве цифрового заслона клиента от линии тех поддержки? Неужто так много клиентов от всей это радости начали бежать стремглав и жаловаться во все возможные инстанции, что пришлось срочно переобуваться? А что сразу было непонятно, а что об этом разве не предупреждали инженеры высокое руководство, которое уволив половину тех поддержки тут же отчиталось о миллионах экономии после внедрения нового убийцы здравого смысла и миллионов нервных клеток ни в чем не повинных людей?
Пожелаем успехов всем вайбкодерам, которые внезапно столкнутся с необходимостью оптимизации творения тёмного разума ИИ. А ведь столько было копий сломано вокруг того, что дешевле залить инфру деньгами, нежели чем нанимать квалифицированных специалистов и давать им время на оптимизацию ПО. Будет весьма иронично если внезапно в мире разработке ПО правило "make it work, make it right, make it fast" начнёт работать в полную силу, а не лишь его часть. Да и закон Парето внезапно окажется не таким уж и непреодолимым. Одним словом есть шанс что при таких вводных скоро наступит благодать, правда не для всех :)
Чувствую, что не достанется. В целом старо как мир: "своим все, чужим закон".
Какой однако новогодний подарочек, я уже успел забыть про пхп, про yii. Сколько правда хороших воспоминаний, аж олдскулы свело, и круто что дело живёт дальше, пусть уже другие времена, совсем иной технологический ландшафт, но уверен кому-то наверняка это принесёт пользу, а кто-то даже смахнет скупую слезу ностальгии :)
На самом деле статья занятная. Она про то что некоторые современные инженеры совершенно не представляют как в действительности работает железо и сеть, каким образом распределяется нагрузка и как строить распределенные системы, где даже отказ одного дата-центра не приведёт к даунтайму. У них вместо знания технологий один ответ - Kubernetes, магия там внутри, он решает все наши проблемы и даже немного больше. Большая беда конечно когда кубер магия перестаёт работать при определённой возросшей нагрузке, и тогда автор просыпается и проводит бессонную ночь, судорожно выясняя как в действительности магия устроена, если он вообще в состоянии это понять. Надо не искать серебряную пулю, а все-таки изучать как устроен кубер, и как все тоже самое можно спокойно повторить руками на железе или виртуалках, тогда возможно это вам сэкономит время, деньги, а ещё сбережёт драгоценные нервы.
Конечно, быть техно-жрецом здорово, но призываю вас быть скучным профессионалом, который каждую систему стремится разобрать на гайки, чтобы понять, как она в действительности функционирует.
Так была реальная конкуренция, и годами рутуб во многом благодаря такой реальной конкуренции никому был не нужен. Хотя казалось бы можно было что-то придумать. Не блокировать, а сделать так, чтобы реклама и монетизация на ютуб была невозможной по закону. Хотя думаю даже такие травоядные меры далеко бы не все поддержали, потому что реально что-то свое у нас не умеют, не могут и не хотят развивать да и пользоваться своим многие как-то не спешат, что конечно грустно.
В общем тут даже по архитектуре сети видно, что проектом реально начали заниматься фактически последние пять лет, а до этого он жил по принципу пусть живёт работает, много денег у Газпрома не требует, вестимо.
Ну в общем по факту толку мало, все равно подозреваю, что большая часть траффика мимо них ходит, увы. Хотя тема конечно несколько холиварная, как правильно фаерволить траффик, похоже нгфв ответом на это точно не является.
Благодарю за такой развёрнутый ответ и ссылку на другую вашу статью, было очень познавательно :)
Статья нравится. А ngfw норм нагрузку держат? Это что-то у вас на богатом всякие palo alto шкафы, или получилось траффик пропускать через какие-нибудь ngfw построенные на базе dpdk?
На каком-то очередном абзаце, читая множество разных заумных слов выставленных к месту и не к месту, бесконечных ссылок на "авторитетные" опросы ознакомиться с которыми впрочем невозможно, я наконец понял, что читаю какую-то чатгпт-сгенерированную статью.
Конечно, тема несомненно интересная, но попробуйте все же хотя бы написать её самостоятельно.
Честно сказать статья откровенно проходная :)
Никаких технических подробностей, а хотелось бы узнать как это делается во "взрослом" проекте. Я-то свой простенький сервер поднимал, и ничего интересного, увы, из статьи не вынес.
Вот в качестве упражнения на досуге, ответьте, что вы думаете по поводу шардированного майна по типу проекта https://github.com/MultiPaper/MultiPaper? А как насчёт того, чтобы майн запихнуть в кубер? Почему да и почему нет? И как бы решали подобную задачу? Какие есть особенности тюнинга майна (всеми любимая жава с тысячами разных параметров и разными гс), что в первую очередь требуется потрогать, чтобы из-за взрыва сотен тнт сервер не падал? Какие стандартные настройки вы бы включили на сервере/установили нужные плагины, чтобы его не сломали за один вечер парочка скучающих школьников? Резервирование и восстановление мира (эксплоиты для серверов майна не такая и редкость, и лучше иметь бэкап на готове), как лучше это сделать? А как правильно мониторить работу сервера и на что смотреть?
Вот ответы хотя бы на эти вопросы дали бы огромную пищу для размышлений и позволили бы действительно запустить сервер в майнкрафте :)
>Devops-инжинер - звучит гордо. Только не надо заблуждаться. Чтобы насадить культуру ДевОпс инженером должен быть психолог, т.к. речь про поведение людей и групп
Это вообще так не работает. Культуру невозможно насадить, её можно только вырастить внутри. Честно говоря реальный девопс я мало где видел, не в части наличия каких-то автоматизаций, а именно как культуру разработки и не представляю даже близко, как это делается.
Я сам участвовал в проекте, где девопс действительно насадили причём в формате безальтернативно взяли и забрали доступ от продакшена (таковы были требования ИБ). К сожалению, но по итогу понимания что это и зачем даже спустя несколько лет пришло далеко не всем. Осталось не мало людей для которых не иронично "гит не инструмент разработчика" и вообще верните нам лучше доступ к нашим базам в продакшене (речь про DWH-аналитиков, если что).
Думаю, что подобное разделение чистая условность. Или если хотите маркетинговый ход. Платят больше денег за то, чтобы меня называли DevOps или SRE - и ладно.
Вот я был системным администратором все последние десять лет. Я занимался плюс-минус похожими вещами в разных направлениях и в разных компаниях. Если объяснить бизнесу что на самом деле админ и 10 лет назад умел поддерживать инфру, писал какую-то автоматизацию, занимался мониторингом, то их думаю данная мысль сведёт с ума.
Никакого вопроса доверия не стоит в принципе.
Речь о том, что в целом частые релизы ником образом не снижают риски и не свидетельствуют об наличии автоматизированного тестирования. Сто быстрых выкаток могут быть не менее опасными, чем одна выкатка в месяц.
>Странный у вас "очень крупный финтех", если никакого тестирования перед продом не происходит, ни с вашей стороны ни с стороны заказчика (если он есть)
Там было некоторое приёмочное тестирование для отдельных принятых на сопровождение сервисов, но в чем оно заключалось сказать сложно. Я в целом не очень уверен, что оно велось в достаточной степени, скорее типичные банковские потемкинские деревни.
>Я тоже из этой области, и вот когда мы делали для банка приложение, которое просто по сути делала отчёты анализируя их проводки, они перед продом это всё месяц гоняли на тестовой базе
Ну банк это история смешная. Где-то у вас будет чуть ли не доскональное тестирование, а где-то оно будет отсутствовать в принципе, тк разработчики и заказчики так привыкли, им обязательно надо как можно более быстро выводить изменения. Вообще всегда когда раздаётся странный возглас надо быстрее всегда следует задать вопрос - зачем, какую проблему решаем, нет ли здесь проблемы с тем, что у людей чисто организационные проблемы, что у них плохо в целом с планированием, и они пытаются решить не ту проблему?
>Возможность релизить часто означает, что у вас маленькие, изолированные изменения, хороший уровень автоматизации и тестирования, это снижает риски
На практике, к сожалению, но частота релизов может быть индикатором как раз наоборот особенно дерьмовых процессов, когда менеджменту всегда надо ещё вчера, а как оно там у айти работает их совершенно не касается, и тогда ваш быстрый девопс ничем не лучше становится прямого доступа к продакшену разработчикам.
На моем проекте (очень крупный финтех) мы добились впечатляющей автоматизации, когда в целом изменение пусть и в качестве хотфикса можно было вывести за один час. А всего у нас в день через нашу автоматизацию успешно ставилось на продакшен несколько десятков релизов и ещё несколько сотен параллельно ставились на разные другие среды. Вы думаете у нас было тестирование? Или возможность быстро выводить снизило какие-то в сущности риски благодаря инкрементным изменениям? К сожалению, но это даже близко было не так. По факту мы просто дали разработчикам вместо прямого доступа к проду ровно такой же аналогичный прямой доступ к проду, но только через нашу трубу, и в головах собственно это и осталось, что это просто палка-копалка для доступа к проду.
В общем как и всегда проблема вовсе не в клозетах.
Ну в целом кто пользуется neovim действительно вряд ли нуждается в каких-то IDE, но тут уж вопрос вкусов, что считать нормальной IDE. Боюсь, что не все согласятся с вами. Даже в контексте VS Code.