Алексей, Сергей Горностаев, C15H22N6O5S,
Коллеги, это уже флейм.
Разработчики без блата в СПБ и Москве на сложных актуальных стеках и зарплатой от 250, это не мифологическое явление, а достаточно распространенное. Я бы даже сказал, что сеньер на java, kotlin только начинается от 200. Да, часто вкусные вакансии расходятся в среде знакомых, но не по блату, а просто потому, что пока человек дорос до сильного разработчика он сменил уже достаточное кол-во компании и познакомился с достаточно большим кол-во других разработчиков, знает их уровень и ему комфортно работать с проверенными людьми, по этому когда компании открывается вакансия ее часто в первую очередь предлагают по сарафанному радио. Плюс у некоторых компаний есть практика приведи друга и получи очень не маленькую премию, но блата здесь тоже не получится, поскольку такая практика у достаточно крупных компаний и вы со своим другом в них можете за несколько лет даже друг друга не разу ни встретить, а другу еще нужно будет пройти испытательный срок, плюс разработчики в таких компаниях не плохо зарабатывают, и не захотят портить свою репутацию предлагая заведомо слабую кандидатуру ради премии.
Так же есть крайне сильная фрагментация рынка.
По Питеру имхо он выглядит так( для стэка java )
От 400 штучные вакансии очень квалифицированных спецов.
От 300 достаточно заметное кол-во вакансий, но часто с не указанной вилкой, квалификация от сеньера или тимлида.
От 200 до 300, массовые вакансии сеньера.
От 150 до 200, топовые вакансии мидла
От 120 до 160, массовые вакансии мидла
От 80 до 120 какое-то сумеречное поле, здесь есть как хорошие специалисты, так и эникейшики почему-то считающие себя разработчиками, но в основном здесь или, тот кто быстро растет из джунов или люди которые так и не смогли выбрать специализацию и стать уверенными мидлами, плюс множество людей которые просто не могу/хотят менять работу по этому получают ниже рынка и самое плохое для них не растут профессионально, часто засиделись на одном месте, возможно возрастные сотрудники которые не могут угнаться за рынком.
До 80 сильные джуны
Около 40, огромная армия джунов которые к сожалению выбрали деньги, а не профессию и по факту прогрессируют ОЧЕНЬ медленно, разработка чаще всего это просто не их, они после попадают в сумеречное поле около 80 и их рост прекращается, даже если они готовы менять место.
Я могу быть не прав, но мое окружение и практика найма показывает такую картину.
Северное Сияние, я не говорю, что 300 массовая ЗП в ИТ. 120 это медиана по всей отрасли включая админов, суппорт, менеджмент и т.д.
Да, 300 это сеньер с 10 опытом т.е. вполне достижимо к 35 годам.
Я говорю о том, что свичинг из разработчика должен иметь не финансовые причины, и вероятно приведет к падению дохода.
По идее это противоречит концепции контейнера как изолированной стабильной среды.
Я так понимаю будет правильно или переподписать контейнер или рестартавать его с внешними параметрами.
LAG_LAGbI4, это не технический вопрос.
Вы должны обеспечить процесс "апрува" обновлений. Т.е. отслеживать обновления, тестировать обновления, выкатывать обновления.
В простейшем случае есть сотрудник который:
1. Постоянно следит за бюллетенями безопасности и незамедлительно на них реагирует.
2. Определяет какие обновления для вашей организации желательные, а какие нет на постоянной основе, т.е. не реже чем раз в недели. И не апрувит все подряд, а именно понимает, вот это обновление нужно, а вот это лишнее.
3. На регулярной основе делает ревизию состояния обновления на рабочих станциях и решает проблемы с их установкой. А проблем там бывает много и часто, то сюда, что-то не ставится, то сюда, то нужно порядок установки обеспечить, то машина никак не хочет репорить свой статус и т.д.
4. Обеспечивает тестирование обновлений, т.е. подготавливает группу компьютеров которые максимально широко покрывают используемые конфигурации и сценарии. Апрувит обновления на них. Контролирует на них, что обновления установились и что пользователи за ними реально работают. Собирает обратную связь и сам наблюдает за журналами ошибок на этих машинах.
kerneus,
Ну собственно говоря все так. Для решения проблем sip придумали iax. Но не кто ни говорит не используйте sip, просто sip и nat плохо сочетаются, по этому подобных конфигураций следует избегать.
Сложности с маршрутизацией решаются различными методами, например ospf.
Маскарадинг и connection traking работают вместе не очень если исходящий интерфейс может меняться, это известная особенность, если заменить маскарадинг на src nat проблемы не будет, или нужно при изменении маршрутов сбрасывать состояние соединений.
Alexey Dmitriev, контролируемая установка обновлении это не только wsus, и даже не столько wsus, это процесс. WSUS это инструмент упрощающий этот процесс, но не подменяющий его. Если процесса нет, проблема решаемая этим процессом не сформулирована, квалификационных и человеческих ресурсов под этот процесс не выделено, то процесс работать не будет.
WSUS это хорошо, но не надо думать, что это волшебная палочка, в большинстве малых организаций смысла в нем нет.
L2 туннели штука часто не тривиальная, имеющая различные подводные камни у разных ведеров, из безпроблемных, вроде openvpn так умеет, но не уверен, что в исполнении miktotik.
SSTP и другие распространенные протоколы, это l3, так что никаких dhcp и прочего общего l2 домена не будет.
Я бы рекомендовал все же убрать требования реализации на втором уровне.
Лично я предпочитаю связку ipsec ike2 + ipip, на mikrotik работает идеально, но для клиентских подключений, особенно windows есть нюансы.
Основные сложности качество связи, эхо, разрывы, сигнал отбоя. Проблема в том, что все это требует специальных знаний из телефонии, а это специфическая область с наскока в ней не разберёшься и ИТ специалисты ей чаще всего не владеют, да и поиск проблем там не тривиальный. По этому лучше оставаться в рамках ip и избегать смешения.
Кратко, чтобы не зависит от реализации конкретного класса.
Условно говоря, чтобы накачать колесо, тебе не важно от какого оно авто, т.е. нужны только те параметры которые относятся к процессу накачивания, если все колеса реализуют эти параметры и методы нужны для накачивания, на них указанно давление и у них унифицирован ниппель, нет необходимости знать какое это конкретно колесо.
Передавая в класс объект, а не интерфейс, происходит привязка к конкретной реализации, это стимулирует программиста сильнее связать данные классы, чем необходимо, что усложнит дальнейшую разработку, это усложняет тестирование, ты не можешь подпихнуть в тест другую реализацию, это делает код менее универсальным и порождает дублирование, это усиливает связность кода, усложняя его последующую модификацию.
Испытательный срок это затраты. Затраты на найм, затраты на онбординг, затраты в виде заработной платы и в конце концов время. Если вы не нанимаете специалистов на потоке вы не можете себе позволить прогнать десяток кандидатов через испытательный срок.
Там же где нанимают на потоке часто делают это через условно бесплатную стажировку, а потом растят кадры внутри.
VaneS Ri_Lax, значит и сейчас у вас лицензии нет, обновить до 10 можно было только легально приобретенные на физ.лицо копии 7, если вы смогли обойти данное ограничение, это не делает систему лицензионной.
Aloha0, быстродействие виртуальной машин зависит от ресурсов которые вы ей выделяет. Очевидно оно будет ниже если машина будет делить ресурсы с другой ОС.
Коллеги, это уже флейм.
Разработчики без блата в СПБ и Москве на сложных актуальных стеках и зарплатой от 250, это не мифологическое явление, а достаточно распространенное. Я бы даже сказал, что сеньер на java, kotlin только начинается от 200. Да, часто вкусные вакансии расходятся в среде знакомых, но не по блату, а просто потому, что пока человек дорос до сильного разработчика он сменил уже достаточное кол-во компании и познакомился с достаточно большим кол-во других разработчиков, знает их уровень и ему комфортно работать с проверенными людьми, по этому когда компании открывается вакансия ее часто в первую очередь предлагают по сарафанному радио. Плюс у некоторых компаний есть практика приведи друга и получи очень не маленькую премию, но блата здесь тоже не получится, поскольку такая практика у достаточно крупных компаний и вы со своим другом в них можете за несколько лет даже друг друга не разу ни встретить, а другу еще нужно будет пройти испытательный срок, плюс разработчики в таких компаниях не плохо зарабатывают, и не захотят портить свою репутацию предлагая заведомо слабую кандидатуру ради премии.
Так же есть крайне сильная фрагментация рынка.
По Питеру имхо он выглядит так( для стэка java )
От 400 штучные вакансии очень квалифицированных спецов.
От 300 достаточно заметное кол-во вакансий, но часто с не указанной вилкой, квалификация от сеньера или тимлида.
От 200 до 300, массовые вакансии сеньера.
От 150 до 200, топовые вакансии мидла
От 120 до 160, массовые вакансии мидла
От 80 до 120 какое-то сумеречное поле, здесь есть как хорошие специалисты, так и эникейшики почему-то считающие себя разработчиками, но в основном здесь или, тот кто быстро растет из джунов или люди которые так и не смогли выбрать специализацию и стать уверенными мидлами, плюс множество людей которые просто не могу/хотят менять работу по этому получают ниже рынка и самое плохое для них не растут профессионально, часто засиделись на одном месте, возможно возрастные сотрудники которые не могут угнаться за рынком.
До 80 сильные джуны
Около 40, огромная армия джунов которые к сожалению выбрали деньги, а не профессию и по факту прогрессируют ОЧЕНЬ медленно, разработка чаще всего это просто не их, они после попадают в сумеречное поле около 80 и их рост прекращается, даже если они готовы менять место.
Я могу быть не прав, но мое окружение и практика найма показывает такую картину.