нет не прикалываюсь, я говорю что мне прилетали в li реально годные вакансии с нормальной ЗП и норм конторами

Если в офис Европы, то может быть. Меня же больше интересует удаленка. RU, UA, KZ Ну, или офисы в МСК/СПБ или на юге.

Коллеги, я готова поделиться, как hrs воспринимают работные площадки. Может, это добавит ясности?!

Коллеги, я готова поделиться, как hrs воспринимают работные площадки. Может, это добавит ясности?!

Мне лично интересно

hh - популярный сайт, на нем я размещаю вакансии. Резюме вообще сегмента ИТ там мало (на самом деле все там, но резюме закрыты в поиске не участвуют, отсылаются, когда ты нашел кого-то на Гитхабе, LI кровью и потом, например, он, бац и развернутое на Нн даёт тебе на твою же вакансию там).

Кто-то может перевести?

LI годный ресурс, но там пустые профили или вообще нет. По мобилке чуть получше, суровые и честные сисадмины, похоже его вообще не уважают.))

Кто-то может перевести?

Что?? Я пытаюсь шутить.)

LI годный ресурс, но там пустые профили или вообще нет. По мобилке чуть получше, суровые и честные сисадмины, похоже его вообще не уважают.))

"По мобилке" - это что значит?

По теме - ммобильные разработчики.

в Украине LinkedIn #1

хлеб насущный по поиску

Мой круг - вроде возрождается медленно, hr and рептилоиды им пользуются.

Что?? Я пытаюсь шутить.)

А можно попросить поделиться той информацией, которую вы изначально предложили донести?

вакансии на Доу выстреливают

лучше всего - на джинни

там самая релевантная инфа

лучше всего - на джинни

Ой!)) Джинни - это вообще что-то с чем-то. Убогое место. Вечно оттуда полуспам идет.

☺️☺️😉

я слышал все время другую инфу)

смотря что ты ждешь от него

Я говорю, что жизнь есть везде. И на hh имеет смысл публиковаться, так как там хотя бы поиск как-то работает и вид и вакансии и резюме стандартный.

после того как там прирутили репутацию и возможность жаловаться на ваки не по твоему профилю - самая воспитанная площадка)

А в LI нужно заполнить нормально профиль и ждать в засаде. Но поиск для hrs там сверх- дебильный и можно счастья не дождаться, если название компании, например, не брендовое и не топ 200 в сегменте.

а мы ща про платный или free?

после того как там прирутили репутацию и возможность жаловаться на ваки не по твоему профилю - самая воспитанная площадка)

Я просто работу ищу от 3к. Поэтому на таких площадках мне явно ловить нечего.

Я говорю, что жизнь есть везде. И на hh имеет смысл публиковаться, так как там хотя бы поиск как-то работает и вид и вакансии и резюме стандартный.

имеет.

Site reliability engineer, #IPONWEB, Москва Требования: Linux, Puppet, Python, SLA, Zabbix (or others), cloud service provoders, English Задачи: - отдел внутренних сервисов => поддержка их (Atlassian stack, CI/CD tools, internal corporative tools) - улучшение инфраструктуры и настройка метрик в мониторинге - написание документации, консультация коллег Условия: 150-180 тыс руб net м.Шаболовкая ДМС, оплата английского, участия в конференциях, питание международный опыт гибкий график и иногда возможность работать из дома

Site reliability engineer, #IPONWEB, Москва Требования: Linux, Puppet, Python, SLA, Zabbix (or others), cloud service provoders, English Задачи: - отдел внутренних сервисов => поддержка их (Atlassian stack, CI/CD tools, internal corporative tools) - улучшение инфраструктуры и настройка метрик в мониторинге - написание документации, консультация коллег Условия: 150-180 тыс руб net м.Шаболовкая ДМС, оплата английского, участия в конференциях, питание международный опыт гибкий график и иногда возможность работать из дома

а в каком месте это Site reliability engineer? - обычный operations

в том месте, где он инфраструктуру настраивает и мониторинг, чтобы во время отслеживать проблемы

А может все же подумать, что можно и правда сделать лушче? Но ок, мне бы про вакансию поговорить.

кто-то и на worki.ru/hr находит айтишников, что странно)

Чего это не сидят? На hh очень удобно готовить подробное резюме, а потом давать на него линк :-) в moikrug часто пишут, когда это нужно. Но чаще всего пишут в linkedin, на деле же с самой малой пользой.

Build Engineer — человек, отвечающий за сборку кода. Подтягивание зависимостей, разбор конфликтов в коде — это все про него. Примерно вот тут закончил читать. С каких пор есть отдельный человек, который будет за всеми косяки исправлять? Мне казалось с приходом контейнеров это целиком легло на плечи разработчиков, пишущих сервис. И вообще как раз этого хотели избежать, придумывая практику.

Двойка по чтению! ...Условно, в DevOps культуре можно выделить несколько ролей, которые очень хорошо соотносятся с профессиями:.. Там же нижеб Обычно эти роли совмещает один человек. Как можно не видеть разницы между ролью и человеком? Тем более в такой чуткой сфере, как автоматизация всего

... К примеру, роль билд инженера можно отдать в руки разработчика... Мда

только в этом чатике я слышал негатив на этот счет

в других источниках как-то все сходятся во мнении, что в эпоху контейнеров нормальная сборка приложения - зона ответственности разработчика: он лучше знает кухню зависимостей - ему этим и заниматься

Если меня бесят в вакансиях AWS, Azure or GCP это старость?

Например, никогда не разворачивал в латинской америке или китае локализованную копию продукта что бы протестировать маркетинговую гипотезу, не настраивал автоскелинг глобально по регионам в зависимости от времени суток и еще куча других не... главное из которых не питал интереса к современным технологиям

в других источниках как-то все сходятся во мнении, что в эпоху контейнеров нормальная сборка приложения - зона ответственности разработчика: он лучше знает кухню зависимостей - ему этим и заниматься

Пастернака не читал, но осуждаю.

Беда не в обсуждении подхода, а в критике статьи, не заслуженной с моей точки зрения.

Например, никогда не разворачивал в латинской америке или китае локализованную копию продукта что бы протестировать маркетинговую гипотезу, не настраивал автоскелинг глобально по регионам в зависимости от времени суток и еще куча других не... главное из которых не питал интереса к современным технологиям

Как соотносится тестирование и высоконагруженный продакшен? Про серваки для тестирования в вакансиях не пишут. Автоскейлинг актуален когда у тебя клауд провайдер умеет в нужный регион. А с селфхостинг клауд можно забраться в такие жепи, что ни один клауд провайдер не заберется. Про цену такого решения я уже писал.

Заберись в китай, например

Можно еще офисы строить самому, например

Можно вобще все на свете, вопрос в чем фокус твоего бизнеса? Если есть охуенные люди в клауд, сделайте пожалуйста в россии аналог AWS/Azure/Alibaba. Ну ведь станете богачами!

В чем посыл всех этих букв?

Очевидно что для тебя ни в чем. В этом чате собрались те, для кого облачные технологии - повседневная работа. Или те, кто хочет этому научится. Если тебя тошнит от этих букв, то лучше разобраться с причинами и постараться найти что-то хорошее. Награда за старанее будет :)

Очевидно что для тебя ни в чем. В этом чате собрались те, для кого облачные технологии - повседневная работа. Или те, кто хочет этому научится. Если тебя тошнит от этих букв, то лучше разобраться с причинами и постараться найти что-то хорошее. Награда за старанее будет :)

Я вообще не вижу от тебя понимания того о чём я написал или понимания значения тех терминов что я использовал. Или ты сознательно игнорируешь нормальный смысл того что я написал и вместо него выдумываешь свою собсивенную интерпретацию моих слов?

Плюсую, господа разрабы даже баш в ёбаш конвертируют, судя по хистори :) А ещё в докероимадже с пыхой нужны иксы.....

в других источниках как-то все сходятся во мнении, что в эпоху контейнеров нормальная сборка приложения - зона ответственности разработчика: он лучше знает кухню зависимостей - ему этим и заниматься

Сборка тесено связана с инфраструктурой и другими сервисами. Продовскими, продлайк, девовскими средами, куча переменных и всё это нужно учитывать в настройки сборок. Плюсуй сюда пересечение с другими проектами где уже свои разрабы. Какроче, просто так это девам не отдать.

Сборка тесено связана с инфраструктурой и другими сервисами. Продовскими, продлайк, девовскими средами, куча переменных и всё это нужно учитывать в настройки сборок. Плюсуй сюда пересечение с другими проектами где уже свои разрабы. Какроче, просто так это девам не отдать.

И иб поимеет, если у разраба есть креды к проду.

Сборка тесено связана с инфраструктурой и другими сервисами. Продовскими, продлайк, девовскими средами, куча переменных и всё это нужно учитывать в настройки сборок. Плюсуй сюда пересечение с другими проектами где уже свои разрабы. Какроче, просто так это девам не отдать.

а "просто так" отдавать и не надо, девопс вроде как дисциплина совместного сближения. Не могу найти щас цитату, но мысль была следующая: "последние 10 лет девопсом называли практику приучения админов к гиту и коду, в том числе инфраструктурному. Отлично, приучили, последующие годы будут про то, чтобы привить разрабом контекст той динамичной облачной среды, в которой их код исполняется"

И иб поимеет, если у разраба есть креды к проду.

с каких щей у разрабов должны быть креды к проду? На прод деплой идет только через CD пайплайн с тестами и прочими светофорами. Пайплайн сетапит админ, креды в пайплайн вливаются через секреты на твой вкус.

а "просто так" отдавать и не надо, девопс вроде как дисциплина совместного сближения. Не могу найти щас цитату, но мысль была следующая: "последние 10 лет девопсом называли практику приучения админов к гиту и коду, в том числе инфраструктурному. Отлично, приучили, последующие годы будут про то, чтобы привить разрабом контекст той динамичной облачной среды, в которой их код исполняется"

ГудПрактис: deploy.md.

ГудПрактис: deploy.md.

имхо это провал, когда вместо Jenkinsfile в репе лежит deploy.md

имхо это провал, когда вместо Jenkinsfile в репе лежит deploy.md

Когда хочется убить разраба, а сам Jfile ещё не написан - спасает, проверено.

Когда хочется убить разраба, а сам Jfile ещё не написан - спасает, проверено.

ну дак не надо называть запасой/переходный вариант бест практисом :)

с каких щей у разрабов должны быть креды к проду? На прод деплой идет только через CD пайплайн с тестами и прочими светофорами. Пайплайн сетапит админ, креды в пайплайн вливаются через секреты на твой вкус.

Это всё красиво только на бумаге. По сути, то что ты описал выглядит так, что, к примеру, лид фронтов, лид бэков и админ, должны собраться и порешать как будет взаимодействовать вся сисема между собой во всех энвайрометсах и вмсвязке со всеми средами. Но в реальности так не бывает. Всегда будет тот, кому это будет больше всех нужно и кто будет пинать всех остальных. И не важно будет это разраб или админ, вот он то и будет выполнять роль девопса.

Это всё красиво только на бумаге. По сути, то что ты описал выглядит так, что, к примеру, лид фронтов, лид бэков и админ, должны собраться и порешать как будет взаимодействовать вся сисема между собой во всех энвайрометсах и вмсвязке со всеми средами. Но в реальности так не бывает. Всегда будет тот, кому это будет больше всех нужно и кто будет пинать всех остальных. И не важно будет это разраб или админ, вот он то и будет выполнять роль девопса.

то есть проблема в том, что попадаются немотивированный сброд вместо коллег? Технических проблем нет? У меня в моей микро-шарашке получается, общаюсь с людьми, у которых получается на куда больших масштабах. Вполне это все реально.

то есть проблема в том, что попадаются немотивированный сброд вместо коллег? Технических проблем нет? У меня в моей микро-шарашке получается, общаюсь с людьми, у которых получается на куда больших масштабах. Вполне это все реально.

Это вполне реально только в микро шаражках. С ростом проекта это, во первых начинает занимать слишком много времени, во вторых становится слишком объемным в плане инфраструктуры которую нужно держать в голове и учитывать. Что становится сложно делать сочетая такие обязанности ещё и с разработкой.

Всё можно, другое дело какой ценой.

Это вполне реально только в микро шаражках. С ростом проекта это, во первых начинает занимать слишком много времени, во вторых становится слишком объемным в плане инфраструктуры которую нужно держать в голове и учитывать. Что становится сложно делать сочетая такие обязанности ещё и с разработкой.

как пример, активно общаюсь вот с этим человеком: https://www.docker.com/captains/viktor-farcic он нифига не микро-шарашки консультирует. При этом он убежден, что в конечном счете (после переходного периода) писать деплойменты для кубера должны авторы микросервиса, а не админы, и довольно плотно эту точку зрения аргументирует.

как пример, активно общаюсь вот с этим человеком: https://www.docker.com/captains/viktor-farcic он нифига не микро-шарашки консультирует. При этом он убежден, что в конечном счете (после переходного периода) писать деплойменты для кубера должны авторы микросервиса, а не админы, и довольно плотно эту точку зрения аргументирует.

Да писать деплойменты для кубера авторы микросервиса конечно могут. Тем более сейчас всё делается чтобы это было максимально просто. Только сколько это будет занимать времени и усилий, когда в деплойментах нужно будет учитывать всю сложную инфраструктуру и нужно будет взаимодействовать с другими проектами где будет свой писатель деплойментов. Сколько будет стоить в конечном итоге время этого разработчика? И что делать с инфраструктурой не связанной с проектом того или иного разработчика? Как быть безопастностю и с тем, чтобы сервисы друг друга не дублировали? На маленьких проектах конечно можно обойтись без отдельного человека, но на крупных просто необходим человек, который будет видеть инфраструктуру и взаимодействия целиком. Иначе это может потом очень дорого стать бизнесу.

как пример, активно общаюсь вот с этим человеком: https://www.docker.com/captains/viktor-farcic он нифига не микро-шарашки консультирует. При этом он убежден, что в конечном счете (после переходного периода) писать деплойменты для кубера должны авторы микросервиса, а не админы, и довольно плотно эту точку зрения аргументирует.

придерживаюсь совершенно противоположного мнения. Разработчик должен разрабатывать. Если он параллельно пишет dockerfile jenkinsfile deployment.yml то он берёт на себя чужую и несвойственную ему роль.

> а потом дает разрабу куски тут важно, в каком виде ему это прилетает. Если это шаблон Dockerfile, в котором ему нужно вызвать make, то это ещё норм

ну так норм

ну примерно так и есть: сначала админ все поднимает, нарабатывает бест-практисы для типичных случаев, совместно с разработчиками, а потом отдает им кусочки конфигов, чтобы они сами свой кирпичик отжигали

разработчику в основном надо научится делать микросервисы. Чтоб он понимал, что его приложение не должно безконтрольно писать на диск, что он не должно брать хранить state локально, что должно уметь работать распределённо, и тд

что логи на стдаут надо отдавать

ну то есть 12factor вбить в голову

не читал про 12factor, но подозреваю, что это оно

все так: исследование на передовой и внедрение в команду. Ну и плюс никто никогда разрабам не отдаст сам кластер, мониторинг, логи, бекапы и все вот это сервисное

разработчику не имеет смысла уметь в gitlab/jenkins/kuber/aws/etc, потому что завтра требования бизнеса поменяются и будут деплоить в частное облако с openshift

ему нужно разбираться в написании приложения и сборке. Плюс IDE.

apache httpd и nginx тоже разрабы пишут. Но заворачивают это в докер/кубер/хелм уже другие люди

я этого конечно не застал, но думаю лет 10-15 назад были специальные люди, которые внедряли в конторах гит, определяли политики веток, разруливали мердж-конфликты и т.д... Сейчас это данность для каждого джуна, думаю с через 5 лет на джуна будут косо смотреть, если он не сможет докерфайл для своей поделки написать

Ну а мы будем что-то новое хайповое исследовать и внедрять

apache httpd и nginx тоже разрабы пишут. Но заворачивают это в докер/кубер/хелм уже другие люди

https://www.youtube.com/watch?v=xqIVgtYBVDw

хороший фильм :)

как говорится, каждый должен заниматься своим делом

rke up мне кажется поднять голый HA k8s сейчас не сложнее и не дольше, чем обжать пару патчкордов))

просто что сам по себе голый k8s так же бесполезен, как и обжатый провод без настройки сетевого оборудования))