Какие инструменты используют DevOps-инженеры?
Часть 3 из ... про devops

5. Часто какие-нибудь инструменты автоматизации инфраструктуры.

Например, Ansible (хотя не только его, бывает Puppet, SaltStack и другое).

Ansible -- это штука, в которой можно описать набор хостов (прям серверов, которые где-то запущены и работают), написать на yaml последовательность шагов которые нужно выполнить на этих хостах.

Ansible скомпилирует yaml в shell (да именно такой кошмар), подключится к этим хостам по ssh и просто выполнит их, прям в shell.

Да, там есть больше деталей, но, опять же, если вы хорошо знаете shell и Linux, то хватит 3-5 дней, чтобы начать на нём активно и хорошо писать.

6. Инструменты мониторинга. Тут зверьков много, они разные, но чаще всего это
- Zabbix
- Prometheus/InfluxDB для сбора метрик с работающих сервисов и их хранения (хотя запросто бывают и другие базы для этого)
- Grafana для отображения этих логов и сбора дашбордов.

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

7. Какой-нибудь из инструментов оркестрации: чаще Kubernetes, реже Docker Swarm, почти никогда Apache Methos.

Тут shell почти никак не поможет, но знание Linux даёт нужную эрудицию, чтобы этих зверёв также быстро освоить.

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

8. Хранилки для уже собранных артефактов: например, какой-нибудь Nexus SonarType (хотя есть разные). Это, обычно, самая простая часть.

9. Инструменты для работы с сетью.

Почему? Ну, потому что нынче всё в интернетах.

Тут всё очень по-разному, конкретные перечислять в этом месте смысла нет, но чем больше знаете про сетевые протоколы, тем всё проще и легче.

Догадаетесь на чём работают роутеры/маршрутизаторы/dns-сервера?

Какие инструменты используют DevOps-инженеры?
Часть 4 из ... про devops

10. Как правильно заметил Виктор в комментах (спасибо!), HashiCorp Terraform.

Почему? Потому что позволяет описать как должна быть развёрнута инфраструктура, но на довольно низком уровне.
Хочется настроить сеть сразу на множестве машин — там это можно; нужно написать сколько дисков и с каким разбиением выделяется вот этому набору виртуальных машин (на которые потом раскатится этот самый докер или куб, например) — там это можно. Да, кажется, всё, что угодно можно.

Но с небольшой оговоркой: терраформу нужен какой-нибудь провайдер виртуализации, на голое железо он не заедет без этого (см. OpenStack, Proxmox, VMWare VStack), если хочется совсем голое железо — то, опять же, Ansible и shell в руки и действуем. На облачных провайдеров из-за этого раскатывается также хорошо и бесшёвно.

Язык для описания довольно хороший (сильно лучше yaml), действительно человечный. Рекомендую глянуть, чтобы знать как нормально.

Но и небольшой дисклеймер: 1) их выкупил IBM, 2) они уже два года как забанили русских (а-та-та!)

ладна на этих выходных без постов, продолжу где-нибудь на днях

Кто такой DevOps? И какие у него есть друзья: MLOps

Часть 5 из ... про разный devops

Machine learning operations, акроним MLOps — это набор практик, направленных на последовательное и эффективное внедрение и поддержку моделей машинного обучения:
- через стандартизацию/унификацию релизного цикла;
- через автотесты;
- через CI и CD;
- через инструменты контейнеризации и оркестрации;

Кажется, слишком похоже на DevOps, да? Всё правильно поняли!

Инструменты точно такие же (почти), задачи такие же (почти), отличается только специфика или, правильнее сказать, доменная область (и зарплата, ведь в названии есть ML!!!): основной продукт, который сопровождают MLOps-инженеры -- это, как правило, модель машинного обучения.

Будучи MLOps можно ожидать, что будете ближе к данным, переливанию этих данных.
Сервисы, которые сопровождаются, будут связаны с этапами обучения/дообучения моделек и их валидации и тд.

Могут немного поменяться CD инструменты (Continuous Delivery, который про автоматическую доставку артефактов/релизов) под более специфичный для ML, но будет всё тот же линух, шелл-скрипты, тот же куб и докер (sic!) и теже терраформы. Знание сети также пригодится!

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


Не верите — на досуге открывайте хотя бы тот же hh.ru, вбивайте MLOps, сравнивайте сказанное с содержимым примерно любой вакансии.

А тут кружки Эйлера (вообще-то Венна, а совсем правильно Эйлера-Венна) про тоже самое.

Как обычно, круги Эйлера очень плохо подходят для точного описания (никогда не используйте их для понимания JOIN-ов в SQL, никогда!): здесь правильнее сместить MLOps сильно ближе к DevOps и совсем по верхам захватить ML, но чуть больше Data Engineering.

Но для обзора подойдут, ладна.

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

Вы, надеюсь, тоже отдыхать не забываете, лето всё-таки!


Пара хороших новостей:
- Регулярное вещание постепенно возвращаю.

- Я почти дописал курс на stepik по Unix.
Он мне не очень нравится, кажется, я в целом очень критичен к своим материалам, но скоро обязательно принесу вам его показывать.

- omp.wiki жива, хотя пролежала чуть больше месяца.
По аналитике вижу, что там время от времени бывают пользователи, пингуйте, если ляжет вновь.

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


Серию постов про DevOps скоро закончу (правда-правда!), а пока держите небольшую годность.

Awesome!

Вот вам лайфхак: хотите по любому интересующему направлению быстро найти актуальные (и, скорее всего, популярные) книги, тулы, туториалы и пр.?

Вбивайте в гугле: awesome <тематика> github

Например, awesome ci github.

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

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


Например,
- https://github.com/krispo/awesome-haskell
- https://github.com/SE-ML/awesome-seml
- https://github.com/ligurio/awesome-ci


+ бывают мета-awesome списки, в смысле awesome списки awesome списков:
- https://github.com/fleveque/awesome-awesomes
- https://github.com/sindresorhus/awesome

Я, кстати, был неправ (никогда такого не было и вот опять), когда написал, что Ansible компилирует YAML в Shell.

Хорошо, что умные люди меня поправили на одном собесе.

Всё немного прозаичнее:
- Ansible старается использовать Python везде, где это возможно; в т.ч. для исполнения на конечном хосте; ну те натурально компилирует YAML в Python, отправляет его на конечный хост, там интерпретатором исполняет;
- В некоторых ситуациях, при этом, может пытаться использовать shell (или какой-нибудь PowerShell): некоторые задачи проще делать в нем и некоторые модули написаны на нем;


Суть меняется не особо, правда: представляете какой кошмар??

Как найти себя?

Когда-то обещал немного про софтовое, вот и про софтовое.
Мне это кажется очевидным, но очевидным для меня это было, кажется, не всегда.


Как найти себя? А никак.

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

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


Можно, при этом, найти какие из навыков от природы вам легче прокачивать, а какие очень сложно. Выяснить в какой из навыков рандом уронил множитель x3, а в какой x0.1.

Быстрее выясните -- быстрее поймёте куда складывать дорогие и конечные поинты, очевидно. Вам про это потом и скажут: вы себя нашли.

Что почитать на каникулах?

К прочтению рекомендую такую вещь: The Architecture of Open Source Applications.

Внутри описания основных архитектурных решений разных опен-сурсных инструментов. Например, есть про ZeroMQ, nginx, git, Continous integration, Python packaging, Hadoop Filesystem.

Секцию 500 Lines or Less тоже смотреть обязательно, там краткие реализации разных прикольных программ и идей, можно взять код для начала своего интересного pet-проекта.


Короче, отличный источник для вдохновения и общей насмотренности.
#литература

Навигация

Для удобства и всех вновь прибывающих:

Харды
- Серия постов про DevOps: часть 1, часть 2, часть 3, часть 4, часть 5, часть 6.
- Посты про языки разметки: часть 1, часть 2, часть 3.

Софты
- Как стать крутым инженером?
- Как найти себя?

Материалы
- Подборка хороших авторских каналов по теме.
- Awesome: как быстро найти актуальную информацию по интересующей теме на github
- Архитектура разных open-source приложений

- omp.wiki — здесь вики, в которой собираются хорошие материалы, по которым читались курсы в Питерской Вышке и ИТМО. Сейчас там неплохо написана часть про Начальное окружение, она почти полная, остальное пишется.

Обсуждения
- Конечно, тёплый домашний чатик ОМП — там можно задать любые вопросы и обменяться котиками с другими котиками хорошими людьми, ищущими знания.


Этот пост будет обновляться

Как и обещано, пора заканчивать серию постов про DevOps и их друзей!

Возможно, ничего нового для вас, но лишний раз артикулировать текстом мне самому полезно.


Постов будет еще примерно 3:

- про DevSecOps,
- про SRE,
- про неизбежную энтропию в жизни и индустрии;

Кто такой DevOps? И какие у него есть друзья: DevSecOps

Часть 6 из .. про разный devops

DevSecOps — это как DevOps, но больше про безопасность.

DevOps направлен на автоматизацию процессов разработки и доставки ПО, DevSecOps добавляет к этому важный аспект: запары про безопасность на каждом из этапов разработки.


Чем занимаются DevSecOps-инженеры?

- Интеграция проверок в CI/CD.
- Автоматизируют тесты безопасности.
- Харденинг контейнеров: делают так, чтобы контейнеры, используемые в проде, не были уязвимыми для взломов и разных ошибок.
- Как и другие DevOps, пишут Infrastructure as a Code в виде Terraform и пр.


Чем DevSecOps пользуются (список, очевидно, не полный, но по нему можно примерно понять):

- Конечно, статический анализ кода: SonarQube и Checkmarx.
- Инструменты динамического анализа безопасности сервисов и аппок: OWASP ZAP и Tenable.io и пр.
- Сканеры контейнеров: Anchore, Sysdig, Trivy.
- Хранилки секретов для безопасного управления ключами и паролями, типа HashiCorp Vault.

Добавил ссылку на чатик ОМП, обязательно заглядывайте — там кайфово и котятки, много котяток.

Кто такой SRE?

Часть 8 из 10 про разный devops (и не только)

Если говорить совсем грубо, то Software reliability engineering (SRE) — это такой хитрый сисадмин, умеющий писать код.
Но давайте попробуем разобраться чуть менее грубо.

Что делают SRE?

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

SRE должен сделать так, чтобы сервисы не падали, а если упали, то очень быстро случился alert, поступила реакция от самих же SRE и желательно случилось быстрое, если не мгновенное, восстановление.
А после инцидента еще и разобраться почему все упало и желательно сделать так, чтобы больше не падало.

Для описания целей SRE часто используют такие буковки:
- Service Level Agreements (SLA) — какую функциональность мы обещаем конечному пользователю,
- Servie Level Objectives (SLO) — какие цели мы преследуем в рамках предоставления этой функциональности,
- и Service Level Indicators (SLI) — какие метрики мы используем, чтобы убедиться, что SLO в рамках SLA достигнуты.
Например, uptime/downtime в процентном соотношении.

Что используют SRE?
- Инструменты мониторинга и визуализации: Kibana, Grafana и тп;
- Инструменты конфигурации: Terraform, Ansible, SaltStack и тп;
- Языки программирования, чтобы дописывать всевозможную автоматизацию;
- Управление инцидентами и оповещения: PagerDuty, OpsGenie и тп;
- Логирование: Filebeat, Logstash, Fluentd и пр.
- Безопасность: Vault и пр.
- Запросто метрики в InfluxDB, Prometheus и пр
- Запросто CI/CD: Jenkins, GitLab CI, Spinnaker, Selenium.
- Linux и разные базы данных, а также всевозможные брокеры сообщений, потому что часто настройка этого всего -- их ответственность;
- Kubernetes, Docker и что угодно еще, что используется в компании;

Чем SRE отличается от DevOps?

Часть 9 из 10 про разный devops (и не только)

SRE больше про доступность и админство сервисов в проде, DevOps про доставку.

Фокус:
- DevOps: культура и инструменты разработки, акцент на быструю непрерывную доставку;
- SRE: обеспечение надежности, масштабируемости и доступности систем, с упором на упомянутые выше метрики;

Подход к инцидентам:
- DevOps: инциденты — возможность для улучшения культуры и процессов;
- SRE: инциденты — критичны для бизнеса и надежности, должны быстро решаться с четкими процессами, включая дежурства, пост-мортемы и анализ причин;

Автоматизация:
- DevOps: сосредоточен на автоматизации CI/CD.
- SRE: автоматизирует операционные задачи, такие как масштабирование и отказоустойчивость.

Метрики:
- DevOps: основная — скорость и надежность релизов;
- SRE: упомянутые раньше SLO и SLI;


Ссылки по теме:

- https://sre.google/
- https://www.redhat.com/en/topics/devops/what-is-sre

Как обезапасить себя и своих близких свой сервер

Вдогонку к размусоливаниям про DevSecOps вот такой важный материал:
https://cheatsheetseries.owasp.org/index.html

Это cheatsheet от OWASP: краткое, но покрывающее очень многие топики, собрание информации по всевозможным темам безопасности приложений.
Собран разными спецами-экспертами в своей области.

Пытаться прочитать все, если вы не безопасник, скорее всего, нет смысла, но полистать и быть знакомым с Open Worldwide Application Security Project точно полезно.

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


Тут top 10 частовстречаемых категорий дыр в безопасности: https://owasp.org/Top10/
(как эти категории собирались: https://owasp.org/Top10/#how-the-data-is-used-for-selecting-categories)

Fantastic Learning Resources

А здесь хороший качественный контент от Алексея Кладова.

1. Отсюда сам сейчас читаю Software Architecture, рекомендую, как и остальные материлы: https://matklad.github.io/2023/08/06/fantastic-learning-resources.html
И блог полистайте, если интересны Rust/Zig/C++ и программирование в целом.

Вообще, Леша раньше преподавал в computer science center, здесь в Питере, вот два крайне годных курса от него на youtube:
2. Плейлист Программирование на Rust: https://www.youtube.com/playlist?list=PLlb7e2G7aSpTfhiECYNI2EZ1uAluUqE_e
3. Плейлист Программирование на Python я немного отсюда приворовывал материалы, но никому не говорите!!: https://www.youtube.com/playlist?list=PLlb7e2G7aSpQhNphPSpcO4daaRPeVstku


И гитхаб Леши как отдельный вид искусства: https://github.com/matklad

продолжаем облучение

Why does man print gimme gimme gimme

Пятничная пасхалочка!

https://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gimme-gimme-at-0030

Пора заканчивать про DevOps!