🚨Собираем пожарную команду на практикум Слёрма по SRE для инженеров. 

Будем тушить инцидент сервиса покупки билетов в кинотеатр, чтобы понять, как выглядит работа SRE-специалиста в реальности.

Программа сделана с участием SRE-инженеров из ведущих международных компаний — Google, Booking, Databricks, TangoMe, Яндекс, Ecommpay, Финам.

На курсе-интенсиве: 

🔹 научим быстро поднимать продакшн силами команды;
🔹 покажем, какие метрики собирать и как это делать правильно;
🔹 расскажем, как решать конкретные проблемы, связанные с надежностью сервиса;
🔹 внедрим правки прямо в прод;
🔹 рассмотрим, как снизить ущерб от отказов в будущем.

Старт — 17 марта. 
Посмотреть программу и подать заявку — по ссылке 📍

Реклама. ООО "СЛЁРМ". ИНН 3652901451. erid: 2W5zFGq9iRn

Kubernetes CPU Limits и их влияние на Go-приложения

Интересный разбор влияния CPU Limits в Kubernetes на производительность Go-приложений. В статье рассматривается, как ограничение CPU может привести к проблемам с планировщиком Go, вызывая значительные задержки из-за принудительного троттлинга.

Ключевые моменты:
- CPU Limits могут привести к увеличению времени работы GOMAXPROCS, что негативно сказывается на обработке горутин.
- Ограничение процессорного времени может вызвать неожиданные задержки в планировании задач, что особенно критично для высоконагруженных сервисов.
- Использование CPU Requests вместо жестких ограничений помогает избежать этих проблем, позволяя Kubernetes корректно распределять ресурсы.

https://www.ardanlabs.com/blog/2024/02/kubernetes-cpu-limits-go.html

#devops #девопс

Подпишись 👉@i_DevOps

🦾Хотите глубже понять управление процессами в микросервисах и повысить надёжность систем? На ум сразу приходят распределённые транзакции – классический, но, увы, проблематичный метод. Но мы предлагаем кое-что получше: шаблон «Сага»!

На открытом вебинаре "«Саги» vs распределённые транзакции: как моделировать рабочие потоки в распределённой архитектуре"

Вы узнаете:
- Почему распределённые транзакции могут быть непрактичны в контексте микросервисов
- Как работает Сага и в чём преимущества этого шаблона
- Какие типы «саг» существуют и как их применять
- Как использовать Сагу для моделирования сложных рабочих потоков

И, конечно же, получите важные рекомендации по внедрению саг в реальных проектах.

Будет интересно архитекторам ПО, системным аналитикам, бэкенд и фулстек-разработчикам.

💬Спикер: Сергей Прощаев Java-разработчик в ПАО «Сургутнефтегаз».

Бонус! Скидка 5% на любой курс OTUS и чек-лист «Подойдёт ли вам шаблон SAGA? Семь вопросов создателю проекта»

⏰6 марта, 19:00 МСК, Бесплатно

Записаться на событие: https://vk.cc/cJjOfj

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Nix: насколько хороша альтернатива Dockerfile?

Современная бэкенд‑разработка не обходится без средств контейнеризации. Самому простому приложению, скорее всего, будет нужна хотя бы база данных или пучок дополнительных зависимостей из веб‑серверов, балансировщиков, сборщиков логов и метрик. Для быстрого их развёртывания и настройки используются кастомные или готовые образы и контейнеры. И когда разговор заходит о контейнерах, первое, что приходит на ум, — это Docker и Dockerfile.

Для многих это стандарт, отклонения от которого вызывают недоумение и вопросы. Но даже у всего хорошего есть альтернативы. Одна из них — Nix. Насколько она сопоставима по удобству и скорости с Docker?

Меня зовут Борис Табачников, я разработчик отдела RnD в СберТехе. Кратко расскажу, что такое Nix в целом, зачем вам его использовать и подробно сравню скорость работы Nix и Docker.

Статья будет полезна DevOps‑инженерам и разработчикам, интересующимся контейнеризацией. И особенно — тем, кто ищет альтернативы для Docker и кого заинтересовал Nix, но при этом сферы его использования и применимость для сборки образов недостаточно понятна.

https://habr.com/ru/companies/sberbank/articles/887722/

#devops #девопс

Подпишись 👉@i_DevOps

Документация как код: принципы, рабочий процесс и вызовы

В современном мире разработки программного обеспечения концепция «Документация как код» (Documentation as Code, DaC) становится все более популярной. Этот подход использует инструменты и практики разработки программного обеспечения для написания, хранения и управления документацией.

🔹 Основные принципы

1. Хранение в системе контроля версий
Документация хранится в репозитории вместе с кодом, что позволяет отслеживать изменения, откатываться к предыдущим версиям и сотрудничать в команде.

2. Использование текстовых форматов (Markdown, AsciiDoc, reStructuredText и др.)
Вместо сложных редакторов документация пишется в простых текстовых форматах, что облегчает интеграцию с инструментами CI/CD.

3. Автоматизация сборки и публикации
Документация может автоматически обновляться и развертываться при каждом изменении кода.

4. Документирование в процессе разработки
Документация пишется параллельно с кодом, а не после него, что делает её актуальной.

5. Использование инструментов рецензирования
Pull Request'ы, ревью и линтеры помогают поддерживать качество документации.

🔹 Рабочий процесс

1. Создание документации – разработчик или технический писатель пишет документацию в виде кода.
2. Рецензирование – команда проводит код-ревью документации.
3. Автоматическая проверка – линтеры и тесты проверяют синтаксис, ссылки и структуру.
4. Сборка и развертывание – система CI/CD публикует документацию в нужном формате.
5. Обновление и поддержка – документация развивается вместе с кодом.

🔹 Вызовы и сложности

🔸 Сопротивление со стороны команды – не все привыкли писать документацию в таком формате.
🔸 Необходимость в новых инструментах – Markdown или AsciiDoc, системы рендеринга (MkDocs, Docusaurus).
🔸 Поддержание актуальности – требуется дисциплина, чтобы обновлять документацию вместе с кодом.
🔸 Интеграция в CI/CD – настройка автоматического развертывания требует времени.

https://www.tabnine.com/blog/documentation-as-code-principles-workflow-and-challenges/

#devops #девопс

Подпишись 👉@i_DevOps

Станьте тем самым сыном маминой подруги 💪

Мечтаете попасть в Google, Microsoft, Яндекс, VK или другие корпорации? Расскажем по секрету — они активно используют Golang для разработки своей инфраструктуры.

Если вы хотите дополнить своё резюме крутым языком и стать на шаг ближе к заветному офферу, присоединяйтесь к потоку курса «Golang для инженеров».

За 3 месяца вы научитесь:
✔️ писать код на Go: переменные, типы данных, функции и структуры
✔️ создавать микросервисы, взаимодействуя с Docker и Kubernetes
✔️ разрабатывать и тестировать API-сервисы на языке Go
✔️ работать с Kubernetes, включая создание и использование операторов

Спикеры курса, Всеволод Севостьянов — Staff engineer в Lokalise, и Тигран Ханагян — Senior software engineer в HungerStation Delivery Hero, имеют более 10 лет опыта разработки и обучат вас уверенному владению Go.

📅 Старт 10 марта

По коду GoForOps10 вас ждет скидка 10% 💸
👉 Занять место на курсе

#реклама
О рекламодателе

Выходим за рамки: создание оператора для наблюдения за внешними ресурсами в Kubernetes

В этой статье мы рассмотрим, как создать оператор, который выходит за рамки кластера и взаимодействует с внешним миром. На примере мониторинга HTTP-серверов вы узнаете, как использовать kubebuilder для разработки custom-операторов и как организовать работу с внешними ресурсами. Статья будет полезна разработчикам, желающим расширить возможности своих Kubernetes-кластеров.

https://habr.com/ru/companies/flant/articles/884566/

#devops #девопс

Подпишись 👉@i_DevOps

Освойте управление кластерами в Kubernetes по программе Яндекса

Яндекс открыл доступ к базе знаний с программами, которые помогают девопсам освоить новые навыки. Например, «Managed Service for Kubernetes» составили эксперты Yandex Cloud и практикующие инженеры.

Программа рассчитана на 24 часа освоения и состоит из 60 практических заданий, а также теории по 7 темам. Материалы останутся с вами навсегда.

Вот, что конкретно с её помощью можно освоить:

▪️Развёртывание кластеров;
▪️Настройку сети;
▪️Автоматизацию работы;
▪️Контроль доступа через RBAC;
▪️Решение проблемы с кластером и приложениями;
▪️Работу с Yandex Managed Service for Kubernetes.

Внутри открытой базы знаний Яндекса множество полезных материалов для девопсов. Узнать о них подробнее и получить доступ можно по ссылке.

Какой код сигнала будет выполнен при исполнении команды kill <PID>?

Сигнал SIGTERM (код 15) — это сигнал по-умолчанию отправляемый при вызове команды kill. Это указывает процессу на завершение работы и обычно считается сигналом для использования при чистом завершении работы.

#devops #девопс

Подпишись 👉@i_DevOps

🔥 Как снизить Latency в Kubernetes? 🔥

Высокая задержка (latency) в Kubernetes может стать настоящей головной болью для DevOps-инженера. Давайте разберем, какие ключевые настройки помогут снизить задержку и ускорить ваш кластер!

🚀 1. Настройка Kube-Proxy
Если используете iptables-режим, попробуйте переключиться на IPVS:

kubectl edit configmap -n kube-system kube-proxy

Установите mode: "ipvs". Это значительно улучшает балансировку нагрузки и снижает задержку при обработке запросов.

🚀 2. Подключение eBPF (Cilium)
Классические iptables могут быть узким местом. Попробуйте Cilium с eBPF, который обеспечивает более быструю маршрутизацию:

helm install cilium cilium/cilium --namespace kube-system

🚀 3. Использование NodeLocal DNSCache
DNS-запросы — частая причина высокой задержки. Включите локальный кэш:

kubectl apply -f https://k8s.io/examples/admin/dns/nodelocaldns.yaml

Это уменьшит нагрузку на CoreDNS и ускорит обработку запросов.

🚀 4. Tuning TCP (sysctl)
Настройте TCP-параметры для более быстрой передачи данных:

sysctl -w net.core.somaxconn=1024
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192

Эти параметры помогут лучше обрабатывать соединения и снижать задержку.

🚀 5. Использование Multi-NIC и CNI-плагинов
Если у вас высокий сетевой трафик, попробуйте Multus CNI для распределения нагрузки между несколькими сетевыми интерфейсами.

#devops #девопс

Подпишись 👉@i_DevOps

Поможем освоить методологию DevOps и выйти на новый профессиональный уровень за 4 месяца

Старт: 17 марта. Оставьте заявку на сайте или напишите нашему менеджеру в Телеграм @Codeby_Academy

Программа курса:
- Контейнеризация и оркестрация: Docker и Kubernetes
- Основы Linux и Git
- Принципы работы с инфраструктурой, контейнерами, CI/CD
- Методы статического анализа для оценки безопасности кода
- Компьютерные сети, базы данных и Bash-скрипты

Кому подойдет этот курс?
- Новичкам: для старта карьеры в команде продуктовой разработки
- Разработчикам: для автоматизации и оптимизации процессов
- Руководителям проектов: для повышения эффективности своей команды

Pipeline CI/CD, объясненный простыми словами

Раздел 1 - SDLC с CI/CD
Жизненный цикл разработки программного обеспечения (SDLC) состоит из нескольких ключевых этапов: разработка, тестирование, развертывание и сопровождение. CI/CD автоматизирует и интегрирует эти этапы, чтобы обеспечить более быстрые и надежные релизы.
Когда код размещается в git-репозитории, он запускает автоматизированный процесс сборки и тестирования. Для проверки кода запускаются сквозные (e2e) тесты. Если тесты пройдены, код может быть автоматически развернут на этапе staging/продакшен. Если обнаружены проблемы, код возвращается в разработку для исправления ошибок. Такая автоматизация обеспечивает быструю обратную связь с разработчиками и снижает риск появления ошибок в продакшене.

Раздел 2 - Разница между CI и CD
Непрерывная интеграция (CI) автоматизирует процесс сборки, тестирования и слияния. Она запускает тесты при коммите кода, чтобы обнаружить проблемы интеграции на ранней стадии. Это стимулирует частые коммиты кода и быструю обратную связь.

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

Раздел 3 - CI/CD Pipeline
Типичный pipeline CI/CD состоит из нескольких взаимосвязанных этапов:
- Разработчик коммитит изменения кода в системе контроля исходного кода
- CI-сервер обнаруживает изменения и запускает сборку
- Код компилируется, тестируется (модульные, интеграционные тесты)
- Результаты тестирования сообщаются разработчику
- При успешном завершении артефакты развертываются в среде staging.
- Дальнейшее тестирование может быть проведено в среде staging перед выпуском.
- Система CD развертывает одобренные изменения в продакшене

#devops #девопс

Подпишись 👉@i_DevOps

10 шагов к созданию оркестратора Terragrunt

1. Определите цели – Четко обозначьте, какие задачи должен решать оркестратор: управление инфраструктурой, стандартизация, масштабируемость.

2. Выберите подходящую структуру каталогов – Используйте рекомендуемые шаблоны Terragrunt (например, live и modules), чтобы упростить поддержку кода.

3. Разделите окружения и компоненты – Используйте отдельные файлы для разных окружений (dev, staging, prod), что обеспечит гибкость и контроль.

4. Оптимизируйте конфигурации – Настройте Terragrunt, чтобы минимизировать дублирование кода с помощью наследования (include).

5. Создайте систему автоматизации – Интегрируйте оркестратор в CI/CD-пайплайны для автоматизированного развертывания.

6. Реализуйте контроль доступа – Используйте IAM-роли и политики, чтобы ограничить доступ к инфраструктуре.

7. Настройте работу с зависимостями – Определите порядок применения модулей и настройте зависимости между ними.

8. Добавьте мониторинг и логи – Внедрите системы логирования (например, AWS CloudWatch) для отслеживания изменений.

9. Проводите тестирование инфраструктуры – Используйте инструменты вроде terraform validate, terragrunt plan и checkov для проверки конфигураций.

10. Документируйте процессы – Поддерживайте актуальную документацию, чтобы упростить онбординг новых членов команды.


https://nordcloud.com/tech-community/10-steps-to-building-terragrunt-orchestrator/

#devops #девопс

Подпишись 👉@i_DevOps