это совсем не так: вы просто заставите большинство людей страдать из-за несоответствия вашим стандартам и всё. Т.е. всё останется по-прежнему, но с дополнительным чувством обиды у обвиняемых и с развращением обвиняющих.
Взросление неизбежно. Смена интересов весьма вероятна. И я видел уже много хороших технарей, которые были готовы в руководители, но типовые внутренние регламенты блокировали рост из-за отсутствия высшего образования. И получить высшее в 30+ лет, будучи обремененным семьёй, обязательствами и работой на фуллтайм становится чертовски сложно. И чем старше, тем чаще бюрократия будет влиять на карьеру: лишь единицы из сотен тысяч настолько уникально общеизвестны что ради них нарушат или поменяют правила. Так что вышка нужна и нужна своевременно.
наезд на коллег возрастом 40+ необоснован: понятию иерархия многие тысячилетия и любые блокировки, если вдруг они есть, легко решаются вердиктом ближайшего иерарха. Пара эталонных решений и правила будут усвоены и применяться автоматически
фишкой этих наушников для меня является то, что можно включить тихую музыку и будет комфортно тихо. В противовес десятилетию работы в ревущих наушниках для меня это стало просто откровением
bose quietcomfort 25/35/45 и вы с лёгкостью уединитесь в шумном опенспейсе или рядом с шумными домочадцами. Они не самые лучшие по качеству звука, они это разработка промышленной компании для вертолётов и других шумных мест, где надо с комфортом провести долгое время. Мне помогло. Я даже спустя 5 лет помню свой физический комфорт, наступивший после перехода на них в шумном офисе.
Я в своей инженерной практике не припоминаю софта на C за пределами частей операционной системы или чего-нибудь вроде СУБД, соответственно не вижу массового рынка заработка на разработке на С, сопоставимого с заработками в прикладной разработке сетевых сервисов, хоть могу и ошибаться.
Мне кажется, что Вам стоит дать шанс языку Golang, который проектировался в том числе для тех, кто умеет в C. Он очень хорош для многопоточной обработки и не страдает вашими вымышленными "для 1024 клиентов она потребит 100Gb и 10CPU": его делали те, кто делали С и Unix и они досконально знают про всё, связанное с производительностью и переносимостью.
Я с точно таким же бэкграундом: возраст, жизнь в ИТ, широкий набор навыков, сейчас зарабатываю как DevOps-инженер. Я тоже из поколения, чей карьерный путь начался в буме внедрения массового ИТ в России и с которым по мере взросления в обществе сдвигается приемлемый возраст для ИТ-инженера. Более того: я отлично вижу фундаментальные вещи, на основе которых строятся каркасы современных инфраструктур и могу переточить решения своими навыками между онпремом, Yandex Cloud, AWS и GCP. Мне без разницы на чём строить CI/CD: Gitlab, Jenkins, Bamboo: я смогу сделать CI/CD даже на shell :) Я регулярно хихикаю, когда вижу как очередной стек инфра-технологий замечательно автоматизируется через старый добрый shell scripting несмотря на все верхнеуровневые кнопки "сделать всё зашибись". Я умею в python/golang/c/cpp, но как инфраструктурщику мне обычно хватает unix way с его гениальным shell scripting, отточенным нуждой в переносимости и требованиями приемлемой производителности, когда окружение даёт кучу специализированных инструментов, которые ты как кубики Лего склеиваешь между собой. Опыт позволяет мне успешно строить прозрачность и наблюдаемость решений. Опыт позволяет мне успешно заниматься выявлением и устранением узких мест в производительности инфраструктуры и я успешно помогая командам притащить эти инструменты в продукты и облегчить им процесс поддержки стабильности в продуктиве. Более того, накопленный опыт позволяет мне строить процессы и я знаю как построить команду и процессы в ней, чтобы бизнес имел на руках максимально адекватный импульс от инфраструктуры для его продуктов, работающих и развивающихся в режиме 24/7. Опять же, доступен левелап: процессами и уровнем обслуживания можно успешно заниматься сколько угодно времени, платя за это существенной частью жизни на совещаниях.
И я не жалею о выборе карьерного пути.
Мне не очень понятен выбор C вместо Golang: гошечка даёт продуктовые вакансии, где инженеры это часть контура зарабатывания денег и поэтому обласканы множеством компаний. И у go есть всё, чтобы массово и успешно писать востребованный быстрые высоконагруженные сервисы: её делали те самые дядьки, которые делали C и они применили весь свой опыт, отточенный многими десятилетиями mainstream IT: gperf, прозрачность, каналы, мощная простота и нативная жизнь в сети. Тогда как по ощущению C это практически только железо или древнючее легаси, что в российских условиях жизни электроники только в Китае смутно ощущается как тотальное кроилово на людях внутри чего-то, похожего на советские НИИ с их специфичной атмосферой.
Всем надо автоматизировать инфраструктуру. Автоматически создать виртуалку терраформом, настроить её ansible и подключить в инфраструктуру с автодобавлением в мониторинг. В инфраструктуре нужен оркестратор kubernetes, чтобы сервисам абстрагироваться от железа, операционных систем и понимания в онпреме оно или в облаке у провайдера. В кубер всё нужно деплоить автоматически: инфраструктурное через GitOps-подход Application-of-Applications от ArgoCD, и прикладное через CI/CD на Gitlab. Всё в кубере надо уметь сделать прозрачным: поднять мониторинг на Promeheus и сбор логов на Loki + promtail. Этой базы достаточно для замены любой перечисленной составляющей на кучу аналогичных: принципы одни и те же, однако сразу надо учиться на хорошем.
Самому надо освоить кубер (для экономии времени и денег лучше по этому курсу за 10$ https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/ с выполнением всех лаб), helm, CI/CD на базе Gitlab и основы мониторинга на связке Grafana+Prometheus. Этого достаточно для уверенной работы джуном в компании из нескольких девопсов, от которых уже нахватаешься более широкого спектра систем.
linux cgroups вместе со связанными механизмами это вообще не виртуализация. И Любой контейнер технологически ничем не отличается от system-unit, почему собственно при запуске контейнеров нет никакой привязки к собственно продуктам docker, podman и подобным. Более того, большинство фич, приписываемых контейнерам докер полностью доступны для настройки для любого systemd-unit. Накладных расходов от виртуализации у контейнеров нет, у них производительность нативного приложения со всеми плюсами "всё своё ношу с собой", когда нет разницы чем и какими версиями наполнена выполняющая контейнер система.
Promtail можно гонять локально со всеми тестами, как и любой другой парсер логов. Сам loki не умничает и отказоустойчиво гонит данные без парсинга в хранилище а затем работает по принципу распределённого grep. За счёт параллелизации можно получить чумовые скорости и всё это при одной копии сохранённых данных. Ну и связка grafana loki + grafana tempo + grafana чертовски удобна как единая точка доступа ко всем артефактам наблюдаемости и перехода между логами и трейсами.
у RabbitMQ есть фатальный недостаток: авторы в issue на Github не рекомендуют запускать его в Kubernetes из-за нежности встроенной базы данных, а просто подключить внешний PostgreSQL/MySQL нельзя. И в облаках особо не продаётся Managed RabbitMQ. Поэтому если можно жить на Redis, каковой лишён этого недостатка, или можно просто начать использовать Kafka вместо RabbitMQ, то всё выглядит так, что лучше так и поступить.
Не исключено, что это совсем неверное впечатление, но когда мне это потребовалось при миграции Django-приложения с Celery с VM в Kubernetes, то оказалось что у RabbitMQ как-то не очень с массовыми современными материалами по HA RabbitMQ и его Disaster Recovery.
Я много лет предпочитал книги, но заметил что для знакомства с новыми технологиями хороший курс с udemy дает мне достаточно хорошее полноценное введение за неделю со всей визуализацией куда тыкал и заходил преподаватель, тогда как книгу я читаю месяц. И этого введения достаточно для перехода на официальную документацию и для того, чтобы быстро подхватить из книги пару не освещенных в курсе глав. Но фундаментальное да, обычно только в книгах.
Насколько я вижу это не CNCF подхватил, а другая коммерческая компания. Годик спустя будет видно получилось ли из этого что-нибудь или нет с точки зрения комьюнити-версии.
Ничего они не отказываются: демографический кризис и сложность самообучения не дают им толп желающих за забором. Важно не давать себе быть непрофессиональным и остальное приложится.
А ещё стоит упомянуть, что компания разработчик Flux CD обанкротилась, а она была ключевым коммиттером в проект. Они выложили в публичный доступ своё коммерческое детище https://github.com/weaveworks/weave-gitops-enterprise и выразили надежду, что проект подхватит CNCF.
В целом я ел и то и то и FLuxCD по возможностям примерно как 20 процентов от ArgoCD с достаточным количеством тараканов вроде отсутствия зависимостей между ресурсами разных контроллеров и специфической политикой совместимости версий.
Мой персональный выбор после года работы с тем и 3 месяцев с другим - ArgoCD и я его могу аргументированно обосновать как глазами пользователя, которому не нужны никакие kubernetes-клиенты и доступы к k8s API, так и инфраструктурного инженера, который может по одному клику в Argo-интерфейсе увидеть все проблемные места всего кластера со всеми его CRD вместе.
Ко мне несколько раз приходили рекрутеры из Яндекса и каждый раз у них было "удалённый вариант работы", который после первого же вопроса обязательно превращался в "ой, ну нет, только офис или гибрид". :)
На мой скромный и некомпетентный взгляд старый мем "работать у нас большая честь" не в ироническом плане спецу сейчас можно применить почти ни к какой компании: все в рынке.
а на основании чего делается спорное утверждение, что удалёнка нужна только тем, кто работает из-за границы? Мне вот из Воронежа она очень нужна, поскольку до неё тут был полный швах в массовой доступности широкого спектра специализаций: было много техподдержки и 1С, с небольшими вкраплениями иного. Сейчас доступно всё, ты только качайся.
история успеха в том, что на удалёнке моя семья меня хотябы видит и общается со мной, а при офисной работе мы встречались в бодрствующем состоянии только в выходные. А еще мне из Воронежа недоступны московские офисы, заточенные на 25% жителей России, проживающих в Московской агломерации и большинству из которых до офисов совсем не пешком.
под понятием "коммутатор" живут устройства от копеечных мыльниц до многопортовых стэкируемых неблокирующих магистральных коммутаторов с портами по 10 гигабит, ценой в чугунный мост. Мы какие обсуждаем?
это совсем не так: вы просто заставите большинство людей страдать из-за несоответствия вашим стандартам и всё. Т.е. всё останется по-прежнему, но с дополнительным чувством обиды у обвиняемых и с развращением обвиняющих.
Взросление неизбежно. Смена интересов весьма вероятна. И я видел уже много хороших технарей, которые были готовы в руководители, но типовые внутренние регламенты блокировали рост из-за отсутствия высшего образования. И получить высшее в 30+ лет, будучи обремененным семьёй, обязательствами и работой на фуллтайм становится чертовски сложно. И чем старше, тем чаще бюрократия будет влиять на карьеру: лишь единицы из сотен тысяч настолько уникально общеизвестны что ради них нарушат или поменяют правила. Так что вышка нужна и нужна своевременно.
наезд на коллег возрастом 40+ необоснован: понятию иерархия многие тысячилетия и любые блокировки, если вдруг они есть, легко решаются вердиктом ближайшего иерарха. Пара эталонных решений и правила будут усвоены и применяться автоматически
фишкой этих наушников для меня является то, что можно включить тихую музыку и будет комфортно тихо. В противовес десятилетию работы в ревущих наушниках для меня это стало просто откровением
bose quietcomfort 25/35/45 и вы с лёгкостью уединитесь в шумном опенспейсе или рядом с шумными домочадцами. Они не самые лучшие по качеству звука, они это разработка промышленной компании для вертолётов и других шумных мест, где надо с комфортом провести долгое время. Мне помогло. Я даже спустя 5 лет помню свой физический комфорт, наступивший после перехода на них в шумном офисе.
Я в своей инженерной практике не припоминаю софта на C за пределами частей операционной системы или чего-нибудь вроде СУБД, соответственно не вижу массового рынка заработка на разработке на С, сопоставимого с заработками в прикладной разработке сетевых сервисов, хоть могу и ошибаться.
Мне кажется, что Вам стоит дать шанс языку Golang, который проектировался в том числе для тех, кто умеет в C. Он очень хорош для многопоточной обработки и не страдает вашими вымышленными "для 1024 клиентов она потребит 100Gb и 10CPU": его делали те, кто делали С и Unix и они досконально знают про всё, связанное с производительностью и переносимостью.
В любом случае удачи!
Я с точно таким же бэкграундом: возраст, жизнь в ИТ, широкий набор навыков, сейчас зарабатываю как DevOps-инженер. Я тоже из поколения, чей карьерный путь начался в буме внедрения массового ИТ в России и с которым по мере взросления в обществе сдвигается приемлемый возраст для ИТ-инженера. Более того: я отлично вижу фундаментальные вещи, на основе которых строятся каркасы современных инфраструктур и могу переточить решения своими навыками между онпремом, Yandex Cloud, AWS и GCP. Мне без разницы на чём строить CI/CD: Gitlab, Jenkins, Bamboo: я смогу сделать CI/CD даже на shell :) Я регулярно хихикаю, когда вижу как очередной стек инфра-технологий замечательно автоматизируется через старый добрый shell scripting несмотря на все верхнеуровневые кнопки "сделать всё зашибись". Я умею в python/golang/c/cpp, но как инфраструктурщику мне обычно хватает unix way с его гениальным shell scripting, отточенным нуждой в переносимости и требованиями приемлемой производителности, когда окружение даёт кучу специализированных инструментов, которые ты как кубики Лего склеиваешь между собой. Опыт позволяет мне успешно строить прозрачность и наблюдаемость решений. Опыт позволяет мне успешно заниматься выявлением и устранением узких мест в производительности инфраструктуры и я успешно помогая командам притащить эти инструменты в продукты и облегчить им процесс поддержки стабильности в продуктиве. Более того, накопленный опыт позволяет мне строить процессы и я знаю как построить команду и процессы в ней, чтобы бизнес имел на руках максимально адекватный импульс от инфраструктуры для его продуктов, работающих и развивающихся в режиме 24/7. Опять же, доступен левелап: процессами и уровнем обслуживания можно успешно заниматься сколько угодно времени, платя за это существенной частью жизни на совещаниях.
И я не жалею о выборе карьерного пути.
Мне не очень понятен выбор C вместо Golang: гошечка даёт продуктовые вакансии, где инженеры это часть контура зарабатывания денег и поэтому обласканы множеством компаний. И у go есть всё, чтобы массово и успешно писать востребованный быстрые высоконагруженные сервисы: её делали те самые дядьки, которые делали C и они применили весь свой опыт, отточенный многими десятилетиями mainstream IT: gperf, прозрачность, каналы, мощная простота и нативная жизнь в сети. Тогда как по ощущению C это практически только железо или древнючее легаси, что в российских условиях жизни электроники только в Китае смутно ощущается как тотальное кроилово на людях внутри чего-то, похожего на советские НИИ с их специфичной атмосферой.
Всем надо автоматизировать инфраструктуру. Автоматически создать виртуалку терраформом, настроить её ansible и подключить в инфраструктуру с автодобавлением в мониторинг. В инфраструктуре нужен оркестратор kubernetes, чтобы сервисам абстрагироваться от железа, операционных систем и понимания в онпреме оно или в облаке у провайдера. В кубер всё нужно деплоить автоматически: инфраструктурное через GitOps-подход Application-of-Applications от ArgoCD, и прикладное через CI/CD на Gitlab. Всё в кубере надо уметь сделать прозрачным: поднять мониторинг на Promeheus и сбор логов на Loki + promtail. Этой базы достаточно для замены любой перечисленной составляющей на кучу аналогичных: принципы одни и те же, однако сразу надо учиться на хорошем.
Самому надо освоить кубер (для экономии времени и денег лучше по этому курсу за 10$ https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/ с выполнением всех лаб), helm, CI/CD на базе Gitlab и основы мониторинга на связке Grafana+Prometheus. Этого достаточно для уверенной работы джуном в компании из нескольких девопсов, от которых уже нахватаешься более широкого спектра систем.
Крайне рекомендую использовать канал Артура Крюкова https://www.youtube.com/channel/UCU55LZT7oRxhX4GTvb5H4HA на котором он честно делится всеми основами и всем кодом.
linux cgroups вместе со связанными механизмами это вообще не виртуализация. И Любой контейнер технологически ничем не отличается от system-unit, почему собственно при запуске контейнеров нет никакой привязки к собственно продуктам docker, podman и подобным. Более того, большинство фич, приписываемых контейнерам докер полностью доступны для настройки для любого systemd-unit. Накладных расходов от виртуализации у контейнеров нет, у них производительность нативного приложения со всеми плюсами "всё своё ношу с собой", когда нет разницы чем и какими версиями наполнена выполняющая контейнер система.
Promtail можно гонять локально со всеми тестами, как и любой другой парсер логов. Сам loki не умничает и отказоустойчиво гонит данные без парсинга в хранилище а затем работает по принципу распределённого grep. За счёт параллелизации можно получить чумовые скорости и всё это при одной копии сохранённых данных. Ну и связка grafana loki + grafana tempo + grafana чертовски удобна как единая точка доступа ко всем артефактам наблюдаемости и перехода между логами и трейсами.
у RabbitMQ есть фатальный недостаток: авторы в issue на Github не рекомендуют запускать его в Kubernetes из-за нежности встроенной базы данных, а просто подключить внешний PostgreSQL/MySQL нельзя. И в облаках особо не продаётся Managed RabbitMQ. Поэтому если можно жить на Redis, каковой лишён этого недостатка, или можно просто начать использовать Kafka вместо RabbitMQ, то всё выглядит так, что лучше так и поступить.
Не исключено, что это совсем неверное впечатление, но когда мне это потребовалось при миграции Django-приложения с Celery с VM в Kubernetes, то оказалось что у RabbitMQ как-то не очень с массовыми современными материалами по HA RabbitMQ и его Disaster Recovery.
Моё впечатление неверно?
Я много лет предпочитал книги, но заметил что для знакомства с новыми технологиями хороший курс с udemy дает мне достаточно хорошее полноценное введение за неделю со всей визуализацией куда тыкал и заходил преподаватель, тогда как книгу я читаю месяц. И этого введения достаточно для перехода на официальную документацию и для того, чтобы быстро подхватить из книги пару не освещенных в курсе глав. Но фундаментальное да, обычно только в книгах.
Добавлю про деплой во множество кластеров всякого унифицированного при помощи ArgoCD: https://argo-cd.readthedocs.io/en/stable/user-guide/application-set/ совместно с https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Generators/ поможет поставить в кучу голых кластеров всё желаемое и восстановить в них всё с отклонениями. Вот пример: https://codefresh.io/learn/argo-cd/argocd-applicationset-multi-cluster-deployment-made-easy-with-code-examples/
Вот тут после базовой регистрации есть шикарный курс по GitOps на базе ArgoCD https://learning.codefresh.io/path-player?courseid=gitops-at-scale&unit=gitops-at-scale_62f502dfa277dUnit
https://control-plane.io/posts/controlplane-backs-the-cncf-flux-project-by-employing-maintainers/
Насколько я вижу это не CNCF подхватил, а другая коммерческая компания. Годик спустя будет видно получилось ли из этого что-нибудь или нет с точки зрения комьюнити-версии.
Ничего они не отказываются: демографический кризис и сложность самообучения не дают им толп желающих за забором. Важно не давать себе быть непрофессиональным и остальное приложится.
А ещё стоит упомянуть, что компания разработчик Flux CD обанкротилась, а она была ключевым коммиттером в проект. Они выложили в публичный доступ своё коммерческое детище https://github.com/weaveworks/weave-gitops-enterprise и выразили надежду, что проект подхватит CNCF.
В целом я ел и то и то и FLuxCD по возможностям примерно как 20 процентов от ArgoCD с достаточным количеством тараканов вроде отсутствия зависимостей между ресурсами разных контроллеров и специфической политикой совместимости версий.
Мой персональный выбор после года работы с тем и 3 месяцев с другим - ArgoCD и я его могу аргументированно обосновать как глазами пользователя, которому не нужны никакие kubernetes-клиенты и доступы к k8s API, так и инфраструктурного инженера, который может по одному клику в Argo-интерфейсе увидеть все проблемные места всего кластера со всеми его CRD вместе.
Ко мне несколько раз приходили рекрутеры из Яндекса и каждый раз у них было "удалённый вариант работы", который после первого же вопроса обязательно превращался в "ой, ну нет, только офис или гибрид". :)
На мой скромный и некомпетентный взгляд старый мем "работать у нас большая честь" не в ироническом плане спецу сейчас можно применить почти ни к какой компании: все в рынке.
а на основании чего делается спорное утверждение, что удалёнка нужна только тем, кто работает из-за границы? Мне вот из Воронежа она очень нужна, поскольку до неё тут был полный швах в массовой доступности широкого спектра специализаций: было много техподдержки и 1С, с небольшими вкраплениями иного. Сейчас доступно всё, ты только качайся.
история успеха в том, что на удалёнке моя семья меня хотябы видит и общается со мной, а при офисной работе мы встречались в бодрствующем состоянии только в выходные. А еще мне из Воронежа недоступны московские офисы, заточенные на 25% жителей России, проживающих в Московской агломерации и большинству из которых до офисов совсем не пешком.
под понятием "коммутатор" живут устройства от копеечных мыльниц до многопортовых стэкируемых неблокирующих магистральных коммутаторов с портами по 10 гигабит, ценой в чугунный мост. Мы какие обсуждаем?