6 GitHub-репозиториев для изучения DevOps

Kubernetes examples. Официальные примеры манифестов и приложений под k8s, на которых удобно разбираться, как это всё описывается на практике.
https://github.com/kubernetes/examples

Terraform AWS modules. Готовые проверенные модули под AWS. Отличный образец того, как писать переиспользуемый и аккуратный Terraform-код.
https://github.com/terraform-aws-modules/terraform-aws-modules

Prometheus. Исходники самой популярной системы мониторинга. Если хотите понять метрики и алертинг не на уровне дашбордов, а изнутри, это сюда.
https://github.com/prometheus/prometheus

Argo CD. GitOps-деплой в Kubernetes: состояние кластера описывается в git, а Argo приводит кластер к нему. Must-have для понимания современного CD.
https://github.com/argoproj/argo-cd

Kubernetes the Hard Way. Легендарный гайд Келси Хайтауэра: кластер поднимается полностью вручную, без скриптов и автоматики. Больно, но после него k8s перестаёт быть магией.
https://github.com/kelseyhightower/kubernetes-the-hard-way

The System Design Primer. Не совсем про DevOps, но без системного дизайна дальше джуна не уехать. Масштабирование, кеши, очереди, базы, всё с примерами.
https://github.com/donnemartin/system-design-primer

MemOps🤨

MemOps 😃

Практическое руководство по созданию локальной лаборатории платформенной инженерии с использованием vind, Sveltos и Argo CD. В нем рассматриваются GitOps, развёртывание на основе меток, исправление дрейфа конфигураций, а также сетевые проблемы, с которыми вы столкнетесь по ходу работы.

📌 Подробнее: https://itnext.io/local-platform-engineering-on-your-laptop-vind-sveltos-and-argocd-2b3e1341ebe7

MemOps🤨

MemOps 😃

Как VictoriaLogs хранит логи в колоночной структуре

В этой статье мы проследим путь одной записи лога — от поступления в VictoriaLogs до окончательного размещения на диске. Это поможет представить, что происходит внутри системы, и понять наблюдаемое поведение: почему запросы выполняются быстро, почему на диске иногда появляется множество файлов и какие флаги и метрики важны при поиске неполадок. Статья рассчитана на широкую аудиторию: не требуется ни опыт программирования, ни знание Go.

📌 Подробнее: https://habr.com/ru/articles/1067552/

MemOps🤨

MemOps 😃

Как работает Docker 🐳

MemOps🤨

MemOps 😃

Масштабирование развертываний Kubernetes на несколько регионов: эталонная архитектура GitOps

Эта статья описывает архитектуру, которую я бы построил, чтобы перейти от 2 до 25 регионов без страха: модель, в которой GitOps является приоритетом, где каждый регион представляет собой независимый, самовосстанавливающийся контур управления, развертывания являются декларативными коммитами, а откат — это git revert, ограниченный ровно одним регионом, — полностью изолированный от всех остальных.

📌 Подробнее: https://medium.com/@vtulasinadh/scaling-kubernetes-deployments-to-multiple-regions-a-gitops-reference-architecture-ad18a55bdaac

MemOps🤨

MemOps 😃

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

В статье Isolation. Security. Scale. разбирают связку kagent и Agent Substrate для безопасного запуска агентов. Изоляция строится на двух уровнях – gVisor перехватывает системные вызовы, а microVM обеспечивает дополнительную границу на уровне виртуализации.

Отдельный акцент авторы делают на масштабировании и мультитенантности. Агенты запускаются на время активной сессии, а после её завершения освобождают ресурсы. Такой подход позволяет приблизить запуск AI агентов в Kubernetes к production-ready модели, где изоляция, политики безопасности и управление жизненным циклом работают вместе.

📌 Подробнее: https://www.cncf.io/blog/2026/10/26/isolation-security-scale/

MemOps🤨

MemOps 😃

🚨 Как один из крупнейших хостеров Рунета отстрелил себе сеть (и заодно DNS). Тотальный блэкаут Beget.

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

Около 2-3 ночи (МСК) у провайдера начинает сыпаться сеть. Сначала деградируют базы данных MySQL, затем отваливается панель управления, а к 8 утра легло абсолютно ВСЁ. Виртуальный хостинг, VPS, почта, панель управления, биллинг и DNS-серверы.

Саппорт открестился от хацкеров, вирусов, кинетических прилетов по ЦОДу и происков РКН:

Проблема носит комплексный характер и затрагивает все уровни архитектуры. Инженеры выполняют ручную настройку инфраструктуры непосредственно в дата-центрах.

Вероятнее всего это суицид SDN или фатальная ошибка маршрутизации. Кто-то глубокой ночью решил накатить небольшой патч 🎩 на автоматизацию SDN или обновить конфигурацию BGP на core-роутерах. В итоге скрипт отработал так хорошо, что маршрутизаторы отрезали сами себя и всю сеть от внешнего мира.
Удаленный доступ отвалился. Единственный способ всё починить - физически ехать в ЦОД, брать монитор + клаву + тележку, втыкаться в стойки руками и откатывать конфиги терминал за терминалом. Отсюда и отсутствие таймингов на восстановление.

Куча контор, которые держали сами сайты на сторонних дедиках в Европе или Selectel, сегодня лежат. Потому как домены они делегировали на NS-сервера Бегета. ДНС умер - маршрутизация до живых серверов остановилась ⚰️

Также мелькает инфа, что параллельно лихорадит Честный Знак. Совпадение? Когда падает инфра такого масштаба, каскадный эффект и перестроение маршрутов могут положить соседние узлы обмена трафиком.

Инженерам Beget желаю запаса кофэ, валерьянки и прямых рук 🤙

Типичный 🥸 Сисадмин

Choosing Between ClickStack and Grafana for ClickHouse Observability

Кажется, в observability снова выбор без выбора: Grafana или ClickStack?

Статья разбирает вопрос выбора на примере ClickHouse. Если ClickHouse — центральное хранилище телеметрии, а инженеры чаще расследуют инциденты, чем смотрят на заранее созданные графики, авторы предлагают смотреть в сторону ClickStack: поиск, корреляция логов, метрик и трейсов, session replay и отдельный акцент на AI/SRE-агентов через MCP.

Grafana остаётся сильнее там, где инфраструктура неоднородная: Prometheus, ClickHouse и ещё десяток источников, которые нужно собрать на одном дашборде, добавить алертинг и не заставлять команду менять привычные процессы.

Так как статья опубликована в блоге Clickhouse, практичный вывод напрашивается сам собой: «А зачем выбирать?» Grafana можно оставить для дашбордов и мониторинга, а ClickStack использовать для глубоких расследований по данным ClickHouse. Причём данные и ingestion pipeline дублировать не придётся.

📌 Подробнее: https://clickhouse.com/blog/choosing-between-clickstack-and-grafana-for-clickhouse-observability

MemOps🤨

MemOps 😃