Кто такой 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!

Хаос — часть процесса
Часть 10 из 10 про разный DevOps.

Когда говорим о DevOps и SRE, кажется, что наша цель — создать идеально автоматизированные, устойчивые системы.

Это было бы круто: всё протестировано, отлажено и работает как швейцарские часы. Но реальность такова, что всюду царит хаос, а энтропия никогда не бывает нулевой.

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


Мы работаем не только с компутерами и кодом, но и с людьми. А люди — это галлюцинирующие обезьяны! Наш мозг обманывает нас, мы делаем ошибки, принимаем решения под влиянием эмоций и опыта (не всегда положительного).


Бизнес-процессы далеки от идеала. Можно проектировать идеальные системы, вводить метрики, устанавливать SLO, но бизнес — это всегда компромисс между скоростью, качеством и необходимостью выживать.

Когда дело доходит до разработки и эксплуатации, процессы "ломаются" на пересечении интересов команд. Инженерам SRE приходится не только поддерживать стабильность, но и справляться с постоянными изменениями требований, а иногда — и с их отсутствием.


В итоге работа DevOps и SRE — это бесконечный цикл улучшений без финиша. В лучшем случае, мы создаём "достаточно хорошую" систему, которую придётся постоянно дорабатывать и оптимизировать.

Это может расстраивать, но такова реальность.


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

Немного правды

Бонусная Часть 11 из 10 про разный DevOps.

Вообще, что DevOps что SRE -- это сисадмины (ого!), хоть и с разным уклоном.

Да, научившиеся писать код + в идеале понимающие в разработке. Но все-таки больше сисадмины, чем программисты. Точка.


Попробовать переубедить меня можно в комментах.

А пока вот вам мой любимый мем на тему: