Вопрос с почтой на собственном домене это только часть проблемы, которую предстоит решить, благо вариантов решения много. В куда большей проблеме оказались те, кто использовал аккаунт G Suite в качестве основного для Android и на котором находятся все покупки и подписки в Google Play.
Есть надежда на то, что Google всё же сделает миграцию с G Suite аккаунтов на free Gmail аккаунт, после того как 19 января поднялась волна недовольства пользователей, которые использовали G Suite для личных и семейных целей и оказались в ситуации "плати или потеряешь все своим покупки в Play", 27 января на Arstechnica появилась обнадёживающая статья со ссылками на последовавшими изменениями в документацию G Suite (сама статья - https://arstechnica.com/gadgets/2022/01/google-relents-legacy-g-suite-users-will-be-able-to-migrate-to-free-accounts).
Вот тут поясняется, в чем проблема и «что изменится»: developers.redhat.com/blog/2017/03/14/java-inside-docker TL;DR: JVM «видит» объём памяти хостовой машины и не обращает внимания на limit указанный контейнеру, получаются интересные эффекты. Этим отличается запуск JVM на машине с ограниченными ресурсами и в контейнере с «ограниченными ресурсами».
Извините за занудство, но то, что вы описали это распределённый firewall. Централизованным здесь можно назвать управление политиками фильтрации, которые хранятся в БД и которые агент получает от сервера, а сама функция фильтрации трафика всё таки распределённая.
Ко всему прочему здесь и в статье присутствует системная ошибка. Junior, Middle, Senior — это про уровень профессионального развития, уровень компетенций, в данном случае разработчика, в то время как Архитектор — это должность или роль, которую может выполнять разработчик уровня и Middle и Senior, например. Как они оказались ступенями одной классификации, большой вопрос.
Тема интересная, результаты любопытные, спасибо. Смущает только то, что статью Вы начали с упоминания IPVS, как классического средства L4 балансировки, но в тестах в пару к NFT почему-то решили поставить Nginx, хотя логичнее было бы сравнивать именно с IPVS. Всё таки задачи, которые решаются балансировкой на IPVS\NFT, принципиально отличаются от тех, в которых применяется Nginx\HAproxy\любой другой L7 балансировщик.
Кстати, отсутствие четкого пика там где он должен быть, может сигнализировать, что перед нами четкая возможность войти в этот рынок.
Зависит от того, как интерпретировать данные. Возможно, рынок нашел баланс и наиболее устойчивыми (по соотношению группы показателей, например, качество\возможности\цена) оказались те модели, которые, к примеру, дают достаточный функционал за минимамальные деньги или богатые возможности за б0льшие деньги, а вариант «ни то ни сё» оказался не востребованным (что, собственно и видно по большинству графиков).
> Допустим, у сотрудников три KPI: объём продаж и дебиторка.
И, видимо, третий, который и определяет итоговый размер вознаграждения, как обычно. За статью спасибо, хотя о «пользе» KPI на этом ресурсе уже дискутировали не раз (например, здесь). Тем не менее, когда читаю подобные статьи, задаюсь вопросом, раз уж компания выбрала KPI в качестве системы оценки эффективности и оперативной оценки, по какому-то недоразумению, то зачем увязывать линейно значение KPI с размером материального вознаграждения. Тем более, что в большинстве случаев в качестве системы мотивации KPI не годится, совсем.
Видимо это очень маленькая компания и веб-ресурс, которой 5Mbps «за глаза». В этом случае еще менее очевидно, зачем здесь три web-сервера в бэкенде. В итоге решение не обеспечивает ни высокую доступность (единственный виртуалных балансер — spof) ни высокую производительность (лимит в 5Mbps). Наиболее подходящий сценарий для express это обкатка конфигурации\скриптов, перед деплоем в продакшен.
Что касается моего опыта, то работал с keepalived, haproxy, Netscaler, F5, Brocade, MS NLB. F5 оказался самым гибким и машстабируемым решением, используем платформу F5 VIPRION в кластерной конфигурации на C2400 качестве основны балансировки и управления трафиком, в дополнение к десятку младших платформ от 2200S до 8900. В основном используем функционал модулей GTM и LTM. Виртуальне балансеры не используем из-за проигрыша в производительности в операциях с SSL-offload. Инфрастуктура используется для хостинга нескольких крупных европейских онлайн-ретейлеров.
Могу сказать, что подходы Netscaler и F5 близки, Brocade несколько отличается. Нет никакого смысла завязываться на конкретного вендора, если в дальнейшем не планируется продолжение сотрудничества. Если 5Mbps это «за глаза», и требуется только балансировка web-трафика, то в случа nix можно ограничится keepalived/haproxy/nginx, если же это MS, то даже стандартного NLB будет достаточно.
Совершенно не понятно, почему именно этот продукт предлагается использовать в качестве решения. Вернее даже так, использование ADC — правильный подход, однако «решение» не органичивается этим конкретным продуктом. Аналогичные варианты (в смысле «бесплатности») есть и у других вендоров. Если я не ошибаюсь, у express-версии, о которой и идет речь, есть ограничение в пропускной способности в 5Mbps, соответственно далеко вы на нём не уедете.
Похоже, что я не достаточно ясно сформулировал мысль. Позвольте пару простых примеров, думаю идею вы поймаете.
«KPI — написание качественного кода для успешного прохождения тестов». Что хочет получить работодатель? Качестенный код. А что он получит? Код успешно проходящий тесты.
«KPI — количество открытых инцидентов в стеке». Что хочет работодатель? Что бы запросы клиентов обрабатывались максимально быстро. А что он получит? Чистый стек и абы как закрытые инциденты.
Я имею ввиду, что введение жестких KPI подменяет для сотрудника цель его работы, с «выполнение работы», каким бы субъективным ни было это понятие, на «получение зеленого KPI». Т.е. для индивида, подменяется связь «результат работы-компенсация», на «зеленый KPI-компенсация». То, что «результат работы» и «зеленый KPI» это будут две принципиально разные цели, видимо, сомнений возникать не должно.
Я согласен, что для менеджера всё должно быть измеримым, по-другому это не работает, но для конкретных исполнителей, чем сильнее бъет «линейка», тем больше желание что-нибудь с этим сделать, и на работу времени уже не остается.
Отнюдь, позволю себе не согласиться с этим утверждением. Если заранее известен набор параметров и вес каждого из них, то при такой постановке вопроса, сотрудник будет думать ни о клиенте, а о том как оптимизировать соотношение затраченные усилия\вознаграждение, и выберет из возможного набора KPI те, которые конкретно ему будет проще, в силу каких-то причин, закрыть с минимальными усилиями при максимальной личной выгоде, причем часто будет оказываться, что цели закрываются не совсем с теми результатами, на какие рассчитывает разработчик KPI. Оставшиеся же показатели будут либо выполнены формально, либо вовсе проигнорированы. Так как для сотрудника не будет иметь ровным счетом никакого значения, на сколько выбранный им показатель важен в конечном счете. Всё что мы увидели, получив систему KPI, так это то, что она отлично стимулирует оставаться посредственностями. Ну и смекалку развивает у сотрудников, это тоже стоит отметить.
Если хотите, мнение сотрудника одной крупной компании, которая после нескольких лет работы, решила внедрить и поставить во главу угла KPI, вроде тех, о каких написано в статье, только сфера деятельности другая.
Знаете, в какой момент ломается вся эта стройная игра в KPI? После первой выплаты вознаграждения по итогам отчетного периода. А знаете почему? Потому что сотрудники не настолько глупы, что бы не понять, что теперь они получают деньги не за выполнение работы, а за выполнение показателей KPI. И весь рабочий процесс рядового сотрудника перестраивается на то, что бы показатели стали «зелеными», при этом ни о каком качестве выполнения работ, или хоть каком-то желании что-то оптимизировать или внедрять новое речи уже не идет. Просто нет смысла. И всё становится еще хуже, когда до сотрудников начинает доходить, что они бегут за морковкой которая болтается на веревке перед их носом, в то время как затраченные усилия не соответствуют уровню получаемой за них компенсации. Ну и розочкой на торте является любимая песня менеджмента про коллективную ответственность, — «ну мы же все в одной лодке», вот после этого самые талантливые и производящие добавленную стоимость окончательно понимают, что с пудовой гирей на ногах далеко не убежишь. Собственно занавес.
Вопрос с почтой на собственном домене это только часть проблемы, которую предстоит решить, благо вариантов решения много. В куда большей проблеме оказались те, кто использовал аккаунт G Suite в качестве основного для Android и на котором находятся все покупки и подписки в Google Play.
Есть надежда на то, что Google всё же сделает миграцию с G Suite аккаунтов на free Gmail аккаунт, после того как 19 января поднялась волна недовольства пользователей, которые использовали G Suite для личных и семейных целей и оказались в ситуации "плати или потеряешь все своим покупки в Play", 27 января на Arstechnica появилась обнадёживающая статья со ссылками на последовавшими изменениями в документацию G Suite (сама статья - https://arstechnica.com/gadgets/2022/01/google-relents-legacy-g-suite-users-will-be-able-to-migrate-to-free-accounts).
Всё же под давлением формируются алмазы, а бриллиантами они становятся лишь после огранки. К сути статьи, кстати, эта разница так же применима.
Вот оно что…
Зависит от того, как интерпретировать данные. Возможно, рынок нашел баланс и наиболее устойчивыми (по соотношению группы показателей, например, качество\возможности\цена) оказались те модели, которые, к примеру, дают достаточный функционал за минимамальные деньги или богатые возможности за б0льшие деньги, а вариант «ни то ни сё» оказался не востребованным (что, собственно и видно по большинству графиков).
И, видимо, третий, который и определяет итоговый размер вознаграждения, как обычно. За статью спасибо, хотя о «пользе» KPI на этом ресурсе уже дискутировали не раз (например, здесь). Тем не менее, когда читаю подобные статьи, задаюсь вопросом, раз уж компания выбрала KPI в качестве системы оценки эффективности и оперативной оценки, по какому-то недоразумению, то зачем увязывать линейно значение KPI с размером материального вознаграждения. Тем более, что в большинстве случаев в качестве системы мотивации KPI не годится, совсем.
Что касается моего опыта, то работал с keepalived, haproxy, Netscaler, F5, Brocade, MS NLB. F5 оказался самым гибким и машстабируемым решением, используем платформу F5 VIPRION в кластерной конфигурации на C2400 качестве основны балансировки и управления трафиком, в дополнение к десятку младших платформ от 2200S до 8900. В основном используем функционал модулей GTM и LTM. Виртуальне балансеры не используем из-за проигрыша в производительности в операциях с SSL-offload. Инфрастуктура используется для хостинга нескольких крупных европейских онлайн-ретейлеров.
Могу сказать, что подходы Netscaler и F5 близки, Brocade несколько отличается. Нет никакого смысла завязываться на конкретного вендора, если в дальнейшем не планируется продолжение сотрудничества. Если 5Mbps это «за глаза», и требуется только балансировка web-трафика, то в случа nix можно ограничится keepalived/haproxy/nginx, если же это MS, то даже стандартного NLB будет достаточно.
Об этом и речь.
«KPI — написание качественного кода для успешного прохождения тестов». Что хочет получить работодатель? Качестенный код. А что он получит? Код успешно проходящий тесты.
«KPI — количество открытых инцидентов в стеке». Что хочет работодатель? Что бы запросы клиентов обрабатывались максимально быстро. А что он получит? Чистый стек и абы как закрытые инциденты.
Я согласен, что для менеджера всё должно быть измеримым, по-другому это не работает, но для конкретных исполнителей, чем сильнее бъет «линейка», тем больше желание что-нибудь с этим сделать, и на работу времени уже не остается.
Знаете, в какой момент ломается вся эта стройная игра в KPI? После первой выплаты вознаграждения по итогам отчетного периода. А знаете почему? Потому что сотрудники не настолько глупы, что бы не понять, что теперь они получают деньги не за выполнение работы, а за выполнение показателей KPI. И весь рабочий процесс рядового сотрудника перестраивается на то, что бы показатели стали «зелеными», при этом ни о каком качестве выполнения работ, или хоть каком-то желании что-то оптимизировать или внедрять новое речи уже не идет. Просто нет смысла. И всё становится еще хуже, когда до сотрудников начинает доходить, что они бегут за морковкой которая болтается на веревке перед их носом, в то время как затраченные усилия не соответствуют уровню получаемой за них компенсации. Ну и розочкой на торте является любимая песня менеджмента про коллективную ответственность, — «ну мы же все в одной лодке», вот после этого самые талантливые и производящие добавленную стоимость окончательно понимают, что с пудовой гирей на ногах далеко не убежишь. Собственно занавес.