Sysadmin, DevOps и SRE: как понимать эти роли, чтобы они не вредили карьере и бизнесу

Спасибо за комментарий 🤝

Сам по себе подход вряд ли изменится, должен быть внешний раздражитель и информация на тему "что делать" :)

Зумеры на работе: почему мы уходим на обед и не возвращаемся. Якобы просто так

Спасибо за статью 🌝

Жаль тема зумеров осталась не раскрыта :)

КМК, стереотипы о молодом поколении строятся на непонимании мировосприятия последних:
Зумерам, являющимся цифровыми аборигенами (интернет был с ними с детства), часто нужно сильно больше времени на понимание того, что человека характеризует именно его труд. Цифровая среда, в свою очередь, диктует мысль, что важно именно показывать как ты живёшь (см. социальные сети). Из-за сбитого фокуса, работа часто воспринимается не как способ реализации, а как инструмент, например, для получения денег, чтобы потом поехать путешествовать или тусить, чтобы показать другим в название_соц_сети свой неповторимой жизненный стиль. Естественно, когда реальность оказывается совсем не тем, что впитывалось через цифровую среду с самого детства, а трансляция своего образа жизни не приносит удовлетворения реализации, первая реакция - бегство. "Уход после обеда", беспрерывный поиск "своей атмосферы(вайбик)", видеоигры или инфантильные увлечения - просто проявление побега от реальности, которая оказывается совсем не такой, как казалось.

В целом, всё по старому, те кто хотят работать - стараются работать.

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

Sysadmin, DevOps и SRE: как понимать эти роли, чтобы они не вредили карьере и бизнесу

Спасибо за комментарий.

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

Если продолжать медицинские аналогии, легко выучить, что при некоторых симптомах эффективен некоторый набор средств. Но для грамотной диагностики и эффективного лечения, необходим научный базис и специализация.

Как мне кажется, пока рынок транслирует необходимость в навыках работы с инструментами, а не необходимость получения бизнес-ценности, тенденция будет сохраняться, к сожалению.

P.S.:

Всё вышесказанное справедливо не только для сотрудников команд эксплуатации, но и для команд разработки. В качестве эксперимента, поспрашивайте разработчиков о том, что такое процесс операционной системы, предоставляет ли операционная система какой-то API или, например о том, какой транспорт использует HTTPS.

Sysadmin, DevOps и SRE: как понимать эти роли, чтобы они не вредили карьере и бизнесу

Спасибо за комментарий.

То о чём писал в статье - именно адаптация к эволюции отрасли 🤝

Sysadmin, DevOps и SRE: как понимать эти роли, чтобы они не вредили карьере и бизнесу

Хорошо, больше заблуждаться не буду 🤷‍♂️
Можно ссылку на вашу статью, расставляющую точки над [ё] ?
В вашем профиле не нашёл 🥲

Sysadmin, DevOps и SRE: как понимать эти роли, чтобы они не вредили карьере и бизнесу

Спасибо за комментарий 🌝
Если подняться выше заголовка, можно найти дисклеймер, в котором прямо говориться:

Все нижесказанное — мои наблюдения и собирательный опыт. Они не отражают положение дел в MWS или другой реальной компании.

Если подняться ещё выше (на 2 абзаца), можно найти упоминание какого-то сообщества:

И... кажется, в ИТ‑сообществе...

Т.к. всё вышесказанное - мнение одного человека, то, кто знает, может быть речь вообще про ИТ-сообщество айтишных человеков пауков?

Sysadmin, DevOps и SRE: как понимать эти роли, чтобы они не вредили карьере и бизнесу

Спасибо за ваше мнение 🤝

Как допилить GitLab CI/CD и перестать переписывать пайплайны

Спасибо за комментарий!
Приятно знать, что кто-то приходит к схожим решениям 🤝

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

Что-то вроде такого:

# Родительский конвейер
...

example_job:
  stage: "--> Artifactoring"
  script:
    - echo "artifacts" > arti.txt
  artifacts:
    paths:
      - arti.txt

downstream_trigger:
  stage: "--> Transition"
  needs:
    - example_job
  variables:
    PARENT_PROJECT_PATH: "$CI_PROJECT_PATH"
    REFERENCE_BRANCH: "$CI_COMMIT_REF_NAME"
  trigger:
    project: my/downstream
    branch: master
    strategy: depend

...

# Дочерний конвейер
...

downstream_job:
  stage: "--> Reader"
  rules:
    - if: $CI_PIPELINE_SOURCE == "pipeline"
    - when: never
  needs:
    - project: "${PARENT_PROJECT_PATH}"
      job: "example_job"
      ref: "${REFERENCE_BRANCH}"
      artifacts: true
  script:
    - cat arti.txt

...

Нюанс в том, что нужно знать название задачи из родительского конвейера 👾

Как допилить GitLab CI/CD и перестать переписывать пайплайны

Привет и спасибо за комментарий!

• В обозримом будущем, скорее всего не стоит, но если вдруг - обязательно прикреплю ссылку к статье.

• Да, цель была именно описать подход + возможное количество доказательств, что сделать так возможно :)

• Общая проблема, как мне кажется, в том, что отдельные от кода CI решения, в целом не очень принимаются рынком. Из личного опыта, пробывал dron и woodpecker, было это примерно в 2019-2020 годах и этот опыт был скорее разочаровывающим.

• Не уверен что есть какой-то смысл запрещать разработчикам доступ к конвейерам, когда эти самые конвейеры
  1) Собирают код, который эти разработчики пишут
  2) Собирают контейнеры/артефакты
  Невозможность доступа к конвейерам, на мой взгляд, ещё больше сепарирует разработку от эксплуатации, что не играет на руку ни мне ни бизнесу 🤷‍♂️
  
  Что касается безопасности в целом, в компании применяются многочисленные подходы безопасной разработки и все необходимые проверки/сканирования. По крайней мере, по моему опыту.

Надеюсь, ответил на все вопросы 🤝

Как допилить GitLab CI/CD и перестать переписывать пайплайны

Спасибо за комментарий!
Рад что понравилась 🤝

Как допилить GitLab CI/CD и перестать переписывать пайплайны

Конечно, можно смотреть на это и с такой стороны, но это в первую очередь именно фреймворк. Его превращение в шаблоны, возможно только при качественной реализации черновиков задач и желанием поделиться ими конкретного инженера :)

Как допилить GitLab CI/CD и перестать переписывать пайплайны

Спасибо за комментарий!

Идея зародилась сильно раньше, чем появилась возможность её реализации. Прототип был с генератором на bash и использовал огромное количество разных утилит. Он органически вырос за 3 месяца. Его развитие успевало за потребностями команды и не встречало сопротивления коллег.

Т.к. в ужасном ( без иронии ) скрипте на bash коллегам - DevOps-инженерам c других продуктов, было тяжело разобраться, генератор был переписан на Python. Если верить истории в git - это заняло неделю, но, скорее всего, чуть дольше ( не помню сколько времени прошло с первой строки на localhost до первого коммита )

Если бы передо мной стояла задача написания такого фреймворка в качестве единственной, я бы закладывал на её решение 1.5 месяца.

Про скрипт:
Показать, наверно, не могу, а вот описать, да.

repobootstrap.py:
Одна функция main, первым идёт словарь со всеми необходимыми переменными, дальше логика обработки аргументов ( при вызове скрипта ) и обращение к API с ветвлением в зависимости от того запущен ли скрипт для группы или проекта ( Отличаются конечные точки API )

PipelineGenerator:
main ( содержит такие константы как порядок задач для стандартных процессов, стадии, название workflow и т.д. ) -> загрузка конфигурации -> определение путей по переменным окружения ( отдельный метод отдельного класса ) -> разделение директорий по типам ( стандартный / не стандартный процесс ) -> запуск генератора

4 класса:
Для обработки директорий ( группировка )
Навигации ( по переменным окружения )
Построения графика ( как утилита tree, для наглядности, но совсем не обязательно )
Генерации выходного yaml - файла + набор вспомогательных функций для него

Отдельно есть функции для логирования и непосредственной обработки конфигураций

├── lib
│   ├── directory_processor.py
│   ├── gen_helpers
│   │   └── pipegen_helper.py
│   ├── navigator.py
│   ├── pipeline_generator.py
│   ├── tree_builder.py
│   └── utils.py
├── main.py
├── pyproject.toml
└── requirements.txt

Надеюсь, ответил на все вопросы 🤝