👩‍💻 В эту субботу Debian исполняется 32 года!

Немного истории: Один из старейших дистрибутивов Linux был анонсирован в 1993 году Яном Мёрдоком как альтернатива плохо поддерживаемым коммерческим сборкам. Debian был создан с целью устранить ошибки, обеспечить регулярные обновления и привлечь разработчиков к открытому процессу, а не к закрытым коммерческим инициативам.

Версии Debian 1.0 никогда не существовало. С анонса в 1993 году по 1995 год разработчики дистрибутива выпускали только 0.X версии. Когда поставщик компакт-дисков InfoMagic выпустил Debian с названием 1.0, Debian объявили, что этот выпуск является лишь ранней разрабатываемой версией. Он не могла корректно загружаться или работать. Во избежание путаницы между преждевременным релизом на компакт-диске и действительным выпуском Debian, проект переименовал свой первый мажорный релиз в "Debian 1.1 — Buzz". Большинство названий дистрибутива, кстати, берутся из фильма История игрушек. Скорее всего так делают потому, что Брюс Пиренс, перенявший лидерство в проекте у Яна Мёрдока, работал в компании Pixar.

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

А ещё рекомендуем посмотреть видео о ранней истории Debian от одного из разработчиков.

Желаем всем хороших выходных и спокойных дежурных смен без серьёзных алертов!

#devops #debian

💻 Управление триггерами в PostgreSQL

Триггер в PostgreSQL — это специальная процедура, которая автоматически срабатывает при событиях INSERT, UPDATE, DELETE или TRUNCATE в таблице.

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

Создать триггер можно следующим образом:

CREATE OR MODIFY TRIGGER trigger_name
WHEN EVENT
ON table_name TRIGGER TYPE
EXECUTE stored_proccedure

⏩ Выполнять их можно:
• BEFORE — до действия
• AFTER — после действия (например для логов, уведомлений).
• INSTEAD OF — используется с views и полностью заменяет стандартное поведение.

⏩ Различают несколько видов триггеров, например:
• FOR EACH ROW — применяется для каждой строки
• FOR EACH STATEMENT — срабатывает один раз на всю операцию, независимо от числа строк

Удаляется триггер тоже довольно просто, с помощью DROP TRIGGER trigger_name.

📎 Совет: следите за производительностью — при большом количестве триггеров сложнее отлаживать поведение из-за повышенной нагрузки на БД.

#devops #postgresql #sql #триггеры

👩‍💻 Linux исполнилось 34 года!

25 августа 1991 года 21-летний студент Линус Торвальдс опубликовал знаменитое заявление о том, что он работает над свободной операционной системой просто в качестве «хобби».

Это не будет чем-то большим и профессиональным.

С этими словами он поделился с миром Linux — самой активно разрабатываемой операционной системой из всех существующих. С первого релиза в 1994 году кодовая база ядра выросла с 176 тыс. строк кода до 40,8 миллионов.

Сегодня Linux окружает нас практически повсюду: от смартфонов на Android, Wi-Fi-роутеров и холодильников до спутников и самолётов. Помимо бытовой жизни, Linux добился полного доминирования в сфере высокопроизводительных вычислений, став основой для 500 самых быстрых суперкомпьютеров мира.

Кстати, талисман и лого ядра — пингвин Tux (Torvalds UniX) был выбран в результате конкурса в 1996 году. Пингвин, как мирное живое существо, отражает дух командной работы и взаимопомощи. Также его принято ассоциировать с лояльностью и выдержкой, что описывает политику ядра Linux. Рассуждения Линуса насчет пингвинов можно почитать здесь.

#devops #linux

🔐 Всем пятничный DevOps! Сегодня делимся небольшой подборкой репозиториев с интересными отчетами.

– Annual Security Reports. Ежегодные отчеты по кибербезопасности от крупнейших ИТ компаний.
– Phishing campaigns. Репозиторий, где собраны разборы о фишинговых кампаниях с примерами писем и описанием инструментов, с помощью которых осуществлялась рассылка.
– Hackerone Reports. Подборка отчетов от Hacker One, которые включают примеры найденных уязвимостей, их описание и влияние на систему

#devops #security #репозиторий

Хотим рассказать про митап для DevOps-инженеров в Новосибирске!

♾️ DevOps-митап 2ГИС ♾️

Три истории и афтепати.

Паша Гладких из 2ГИС расскажет, как собрать продакшен-кластер с GPU из обычных десктопов, когда бюджет диктует архитектуру.

Пётр Рукин из Nixys порассуждает, что там с KeyDB и стоит ли использовать DragonflyDB и Redis в современных реалиях.

Андрей Морозов из 2ГИС поделится опытом, где стоит применять Helmfile, а где — нет.

🟢24 сентября, Новосибирск, офис 2ГИС.

Бесплатно, регистрация обязательна.

🔵Пятничная подборка подкастов: Octopus Deploy, Wing Cloud и AI в командах

На этой неделе делимся записью выступления Team Lead-а Nixys Петра Рукина на DevOps-митапе в офисе 2ГИС— теперь её можно посмотреть на YouTube и RuTube, а пока ловите три истории о развитии инструментов, рождении стартапов и испытании идей об AI в командах.

Octopus Deploy и взгляд изнутри от Azure & DevOps Podcast
Джон Бристоу делится опытом более чем за два десятка лет. В его багаже Microsoft, Progress, роль в HashiCorp Ambassador и участие в сообществе Octopus Deploy. В выпуске подкаста он рассказывает о практиках управления, общении с сообществом и том, как сохранять интерес в индустрии без пафоса и лишних слов.
Уроки стартапа Wing Cloud от Packet Pushers
Элад Бен-Израэль вспоминает запуск Wing Cloud, разработку языка Winglang и выводы, которые он сделал о создании и закрытии стартапа. Разговор о рисках, смелости и технологиях, которые появляются, когда инженеры решают пойти своим путём.
AI: ожидания и реальность. Цифры от Лауры Тачо, CTO DX от Agentic DevOps
Лаура Тачо, CTO DX, рассказывает, как команды внедряют AI и агентов в повседневную разработку. В выпуске обсуждают цифры, как показатели успехов и неудач таких подходов, и представляют фреймворк для оценки влияния AI на жизненный цикл продукта. Лаура Тачо рассказывает, где автоматизация поддерживает процессы, а где превращается в лишний груз.

🙂Хороших выходных и спокойных дежурств тем, кто в смене!

#devops #подкаст #пятничный_devops

🌐Автоматизируем увеличение EBS-объёма без даунтайма

Всем DevOps! Сегодня разберём, как упростить жизнь, если диск внезапно “упирается” в предел.

Когда EBS-том на AWS почти заполняется, большинство команд обновляют размер вручную — через консоль или CLI. Это рутинно, медленно и иногда приводит к задержкам в проде. Автор одного из свежих гайдов показал, как полностью автоматизировать процесс расширения.

Вот ключевые шаги, которые он предлагает:

• Использовать CloudWatch для отслеживания порогового заполнения тома
• С помощью Lambda вызывать скрипт, который увеличивает EBS-объём
• Прописать событие в EventBridge для регулярной проверки
• После изменения размера инициировать расширение на уровне файловой системы
• Настроить уведомления (SNS), чтобы команда знала о срабатывании

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

🗄Если хотите внедрить у себя:
• Не полагайтесь на device names — используйте VolumeId. CloudWatch его не даёт, поэтому лучше резолвить через SSM.
• Выберите один интеграционный паттерн и настройте его корректно (например, Alarm → SNS → Lambda).
• Держите курс на безопасность: уберите “first volume” fallback, добавьте идемпотентность, чёткие алармы и логи.

Итог: автоматизация EBS через алармы работает стабильно. Если правильно продумать интеграцию и добавить защитные проверки, у решения нет минусов — только ускорение и предсказуемость.

#devops #aws #infrastructure

Legacy vs прогресс: как работать с системами прошлого

👤На Reddit обсудили боль DevOps-инженеров: как работать с системами, которые устарели пять лет назад и блокируют внедрение новых решений.
Каждое обновление с Legacy-системами превращается в квест: старые решения не интегрируются с современными процессами, руководство действует по правилу "не чини, если не сломано", инженеры тратят силы на сопровождение устаревшей инфраструктуры вместо развития.

Что предлагают коллеги?

jbandinixx:если не можешь уничтожить, заставь их работать на тебя. Оберни в API, автоматизируй рутину и устраняй проблемы по частям. Для повторяющихся задач (ввод данных, создание аккаунтов, планирование и т.д.) инструменты вроде Cyberdesk реально помогают снять часть нагрузки.

sysadmintemp: старое редко умирает, потому что всё ещё используется, а новое ПО не покрывает все сценарии. Автоматизируй процессы. У нас была C++ .exe программа, мы обернули её в Python API и загрузили рабочую версию в артефакт-репозиторий. Это позволило разворачивать ПО с актуальным Python-кодом и часто обновлять хост.

elucify: мне понадобилось 3 года, чтобы убедить руководство поменять систему. Менеджменту не нужны проблемы, им нужны решения с цифрами.

sschueller: по-нашему “модернизация” — это упаковать умирающий сервер в Docker и кинуть его в облако.

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

С какими сложностями вы сталкиваетесь при работе с legacy системами?

#devops #reddit #legacy

👩‍💻 Автоматическое восстановление служб в Kubernetes — контроль, прозрачность и спокойный сон

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

Что внедрить первым?
- Экспорт метрик и базовые алерты в тестовом namespace.
- Оператор расширения дискового пространства в dry-run с трассировкой действий.
- Сценарии отказов в staging: full-disk, failed-resize, node-failure.

🤝После базовой настройки включаем контроль.
Что проверить?
- Snapshots перед изменениями.
- Ограничение параллельных операций.
- Метрики эффективности: MTTR, число автопочиненных инцидентов, вмешательств оператора.

📎 Совет: встраивайте автоматизацию с runbooks и audit-логами рядом — так автоматические действия остаются прозрачными и воспроизводимыми. Читайте весь гайд по ссылке.

👩‍💻 Делимся репозиториями:
• Draino — оператор от Planet Labs, который автоматически изолирует и очищает (cordon/drain) узлы Kubernetes, когда они переходят в неработоспособное состояние.
• Volume Expander Operator — проект от Red Hat COP для автоматического расширения Persistent Volumes при достижении порога заполнения.

#devops #kubernetes #storage #autoremediation

Привет! Вы в DevOps FM 🚀
Канал про DevOps, администрирование и людей, которые это совершенствуют👍

Наши рубрики:
- Понедельник — Познавательные (#tools #opensource)
- Среда — Информационные дайджесты (#kubernetes #docker)
- Пятница — Развлекательное / пятничное чтиво (#debugging #podcasts)
- Каждые 2 недели — «Партнёр недели» (#партнёрский_пост)

💡 Совет: используйте хештеги для поиска по интересующим темам.
Например, #postgresql, #security, #architecture

Авто-ресурсы в Kubernetes, Pulumi NEO и Google MCP: инфраструктура на автопилоте

🔔Всем срединедельный DevOps! Обсудим свежие апдейты авто-выделения ресурсов в K8s и инструментов GitOps. Полезно тем, кто хочет меньше крутить кластеры вручную.

🟡 Kubernetes 1.34 и динамическое выделение ресурсов
В версии Kubernetes 1.34 кластер сам подбирает ресурсы GPU, CPU и I/O под конкретные задачи — без необходимости заранее прописывать лимиты в PodSpec. Теперь через API можно запрашивать устройства с нужными параметрами (тип GPU, версия CUDA, объём памяти) — и Kubernetes подберёт подходящее оборудование.
Это снижает долю простаивающих ресурсов, особенно при ML- и AI-нагрузках, где требования к железу меняются на лету.

⚫️ Pulumi NEO упрощает GitOps
Pulumi NEO читает IaC-код, сам формирует план изменений инфраструктуры, проверяет его через Policy as Code и применяет. Он понимает зависимости, окружения и может откатывать изменения без ручного kubectl apply. Полезен, когда GitOps-потоки разрастаются, а ручное управление окружениями тормозит релизы.

🟡 Google MCP для баз данных
Google представил MCP Toolbox — серверный набор инструментов, который реализует MCP для безопасной автоматизации доступа к базам данных. SQL-операции задаются декларативно в tools.yaml , а MCP управляет подключениями, пулами и правами доступа. Поддерживает Cloud SQL, AlloyDB, Spanner, PostgreSQL и MySQL. Система следит за нагрузкой, масштабирует кластеры и перестраивает схемы без ручного вмешательства DBA. Ещё один шаг к инфраструктуре, где всё крутится само.

#DevOps #Kubernetes #SRE

5 мифов о DevSecOps, из-за которых теряется скорость релизов и контроль над безопасностью

🤝Сегодня обсудим, почему DevSecOps — не про замедление, бюрократию и ещё один набор инструментов. Разберём 5 мифов, которые мешают это увидеть.

💬DevSecOps замедляет разработку
Миф: проверки безопасности добавляют фрикцию — значит, релизы будут идти медленнее.
Реальность: скорость падает не из-за DevSecOps, а из-за ручных и разрозненных проверок.
Когда безопасность встроена в CI/CD-поток (например, через автоматические SAST-, SCA- и DAST-сканеры), разработчики получают обратную связь в момент сборки или при коммите — ещё до ревью. Такая интеграция позволяет исправлять уязвимости до того, как они попадут в прод. Например, по данным Veracode, клиенты, использующие Veracode Fix, сокращают время устранения уязвимостей примерно на 92 % по сравнению с ручными подходами.

💬DevSecOps — это просто ещё один набор инструментов
Миф: купим несколько сканеров, включим проверки — и у нас DevSecOps.
Реальность: сами инструменты ничего не дают без культуры взаимодействия между разработчиками, DevOps и специалистами по безопасности. Если сканеры не интегрированы с CI/CD, issue-трекерами (например, Jira, GitLab Issues) или IDE, безопасность превращается в хаос уведомлений, которые никто не успевает обработать.

💬Разработчики должны быть экспертами по безопасности
Миф: разработчик должен стать специалистом по кибербезопасности для внедрения DevSecOps.
Реальность: грамотно выстроенный DevSecOps-процесс автоматизирует рутину и даёт понятные подсказки там, где работает разработчик — в IDE (VS Code, IntelliJ), в pull-requestах или пайплайне CI. Безопасность становится частью привычного цикла: написал код → прогнал тесты → получил подсказку по уязвимости → исправил.

💬DevSecOps не подходит малому бизнесу
Миф: DevSecOps — это история для корпораций с большими бюджетами.
Реальность: DevSecOps можно начать с малого и масштабировать по мере роста.
Даже небольшие команды могут настроить:
- SAST-проверку через бесплатные инструменты — Semgrep, SonarQube Community, Bandit;
- SCA-анализ с помощью OWASP Dependency-Check, Snyk Open Source или GitHub Dependabot.
Малый бизнес выигрывают за счёт гибкости процессов: меньше согласований, быстрее адаптация.

💬DevSecOps — это только защита от внешних атак
Миф: DevSecOps нужен только для защиты от хакеров и DDoS.
Реальность: DevSecOps охватывает всю цепочку безопасности — от конфигураций инфраструктуры до зависимостей и прав доступа.

#DevSecOps #Security #CICD #Automation

Kubernetes под микроскопом: как SPO видит действия пользователей

👩‍💻Всем DevOps! Сегодня поговорим о том, как отслеживать, что происходит внутри контейнеров в Kubernetes. В стандартной конфигурации Kubernetes аудит фиксирует только действия на уровне API: кто применил kubectl exec или kubectl debug. Что именно происходило внутри pod’а после входа в контейнер увидеть нельзя. Эту проблему решает Security Profiles Operator (SPO) — отслеживайте действия пользователей и процессов внутри pod’ов и на узлах.

🔄Принцип работы
SPO использует системные источники данных — например, /var/log/audit/audit.log и /proc/<pid>. Каждое событие записывается в JSON-формате, а JSON Enricher связывает его с соответствующим API-запросом через request UID. Это позволяет восстановить полную цепочку: API-запрос → контейнер → процесс → результат

🔓Как включить Security Profiles Operator?
- Установите cert-manager
Он нужен для автоматического управления сертификатами, используемыми SPO.
- Разверните Security Profiles Operator
Используйте официальный манифест из подборки репозиториев.
- Настройте хранение логов
SPO может сохранять логи: локально на узле (по умолчанию в /var/log/security-profiles-operator/ ), в общем томе (PVC), или выводить в stdout — удобно для интеграции с системами сбора логов вроде Loki или Elasticsearch;
- Включите JSON Enricher
Он обогащает события дополнительной информацией о процессе.
- Настройте seccomp-профиль для отслеживания системных вызовов
Он фиксирует вызовы вроде execve и clone, а объект ProfileBinding применяет профиль ко всем pod’ам в выбранном пространстве имён ( namespace ).

📎Репозитории с инструкциями по установке:
audit-logging-guide — описывает, как включить аудит действий внутри pod’ов и узлов через Security Profiles Operator.
installation-usage — показывает, как установить Security Profiles Operator и применить seccomp-профили к pod’ам.

С SPO вы поймете, что произошло, почему и кем было сделано — без лишней нагрузки и сложных интеграций.

#devops #kubernetes #spo

Инфраструктура на автопилоте: Java 2025 и новые инструменты

🔄В середине этой недели обсудим релизы в экосистеме Java — Jakarta Query стандартизирует работу с данными, Spring AI учится общаться через MCP, а Open Liberty получает автозависимости и патчи. Если в проектах не хватает автоматизации — самое время взглянуть на новые инструменты Java 2025.

🟡 Jakarta Query: единый язык запросов для Java-приложений
Jakarta EE готовится к включению нового Jakarta Query — стандартизированного языка запросов, который объединяет Jakarta Persistence Query Language (JPQL) и Jakarta Data Query Language (JDQL). Разработчик теперь может описывать запросы на уровне объектов, а платформа сама преобразует их в SQL или другой язык конкретного хранилища. Это делает код переносимым и позволяет писать запросы единообразно — независимо от используемой базы данных.

⚫️ Spring AI 1.1: протокол MCP и интеграция с облачными памятью и БД
Spring AI получил обновление с поддержкой Model Context Protocol (MCP) — теперь приложения могут безопасно делиться контекстом между AI-модулями, сервисами и хранилищами. Добавлены интеграции с Azure Cosmos DB и GemFire, улучшено управление метаданными и обработкой чатов.

🟡 Open Liberty 25.0.0.10: управление зависимостями и патчи безопасности
В новой версии Open Liberty появилась поддержка JDK 25 и настройка overrideLibraryRef, что позволяет библиотекам перекрывать классы приложения.
Это упрощает изоляцию и обновление зависимостей без перекомпиляции приложений — полезно при CI/CD-потоках с микросервисами. Исправлена уязвимость CVE-2020-36732 в библиотеке crypto-js, улучшена работа с Node-зависимостями и класс-лоадером.

🚀Java 2025 всё больше похожа на инфраструктуру, которая управляется через код:
запросы — декларативно, интеграции — модульно, обновления — без боли

Дайте знать, что думаете об инструментах Java в комментариях💬

#Java #SpringAI #JakartaEE #OpenLiberty

Пятничная подборка подкастов: от AI в инфраструктуре до архитектурных решений

🗣В эту пятницу будет, что послушать DevOps-инженеру. Делимся свежей подборкой подкастов.

⏺Готова ли инфраструктура к AI? Разбираем на практике — DevOps Paradox #319
Ведущие Дарин Поуп и Виктор Фарчик подчеркивают, разницу между ожиданиями разработчиков AI-платформ и реальностью на примере кейсов. Главным барьером в работе они называют отсутствие опыта взаимодействия с агентами и векторными базами данных.

⏺Workload identity: меньше ручного контроля, больше прозрачности — Day Two DevOps #284
Ведущий Нед Беллаванс и гость Кристиан Поста обсуждают, как сервисы и агенты взаимодействуют между собой без участия человека. Разбирают, как работают workload identities — цифровые удостоверения, по которым системы подтверждают подлинность и права доступа друг к другу.

⏺Лидерство и инженерные решения — Azure & DevOps Podcast
Джимас Стейли беседует с Джонатаном Джей Тауэром, Microsoft MVP и основателем Trailhead Technology Partners о том, как техническим лидерам принимать осознанные решения, исходя из целей продукта. Говорят о кейсе, в котором отказ от микросервисов в пользу простой архитектуры ускорил релизы и снизил затраты на поддержку.

👍Пусть сервисы не падают, а кофе не заканчивается! Хороших выходных и приятного прослушивания.

#devops #подкаст #AI #лидерство

Макросы в коде: что стоит учитывать при ревью и CI/CD

👩‍💻Линус Торвальдс прошёлся по коду, где был предложен макрос make_u32_from_two_u16()— инструмент для объединения двух 16-битных чисел в одно 32-битное. На первый взгляд, решение удобно, но Линус назвал реализацию "мусорной": такая абстракция усложняет понимание и сопровождение кода.

Как улучшить код и ревью
⏺Используйте явную запись
Прямое выражение показывает порядок и логику:



((uint32_t)a << 16) | (uint32_t)b

⏺Добавляйте абстракции только при необходимости
Макросы и функции избавляют от дублирования или повышают безопасность, а не просто «упаковывают» очевидные выражения.

⏺Следите за переносимостью
Добавляйте приведения типов и маскирование, чтобы избежать ошибок на разных архитектурах:

#define MAKE_U32_FROM_TWO_U16(high, low) \
    (((uint32_t)(high) << 16) | ((uint32_t)(low) & 0xFFFF))



⏺Сохраняйте ясность и локальность изменений
Если нужна общая утилита — поместите её в отдельный модуль и документируйте назначение. Так, вы снижаете вероятность конфликтов и улучшаете читаемость кода.

⏺Используйте ИИ-инструменты осознанно
Генераторы кода (ChatGPT, Gemini и пр.) могут предложить готовое решение, но итоговый вариант важно проверять: читаемость, переносимость, соответствие стилю проекта — всё это остаётся задачей разработчика.

Даже небольшие абстракции требуют осознанного подхода.
Если операция проста, прозрачна и понятна, лучше записать её явно. Так, код становится надёжнее, ревью — быстрее, а CI/CD-процессы — стабильнее.

#DevOps #Linux #CICD