Кто такой 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 -- это сисадмины (ого!), хоть и с разным уклоном.

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


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

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