⚡️ Интерактивный чеклист по готовности приложений и кластеров Kubernetes к проду

Как убедиться, что ваша инфраструктура отказоустойчива, безопасна и масштабируема перед запуском в продакшен? Можно пойти путем проб и ошибок, а можно обратиться к чек-листу и пройтись по нему всей командой.

Представляем репозиторий kubernetes-production-best-practices, который удобно использовать как внутренний стандарт компании при деплое новых сервисов. Он помогает избежать классических ошибок (падение кластера из-за отсутствия лимитов по памяти, падение приложения во время деплоя из-за неверных Readiness-проб).

5 категорий чек-листа:

⚪️ Разработка приложений
⚪️ Манифесты Kubernetes
⚪️ Безопасность
⚪️ Масштабирование и ресурсы
⚪️ Выход в продакшен и эксплуатация

К большинству пунктов прилагаются пояснения, почему это важно, и готовые YAML-манифесты с корректной конфигурацией.

Пользуйтесь и делитесь с коллегами🫡

@DevOpsKaz 😛

🔥 NVIDIA полностью перевела платформу Run:ai в open source

NVIDIA открыла исходный код всей платформы Run:ai для GPU-оркестрации в Kubernetes Раньше открытым был только планировщик KAI Scheduler, теперь добавились control plane, CLI, веб-интерфейс и ещё три модуля: GPU Fractioning Operator с нативным дроблением GPU на CUDA, KAI Resource Management с квотами по департаментам и Workload Map, единый контракт для описания разных типов воркблоудов вроде PyTorchJob и RayCluster.

Код лежит на GitHub и NGC с Helm-чартом.

Платная подписка для установки не нужна.

👈 Узнать, что это и зачем

Платформу уже встраивают восемь партнёров DSX — Nebius даёт её в один клик в своём облаке, Crusoe объединяет с managed Kubernetes, Rafay разворачивает как полностью управляемый сервис от инфраструктуры до control plane. Рядом NVIDIA показала два смежных проекта: Model Streamer ускоряет загрузку весов моделей в GPU в разы, а Grove оркестрирует связанные компоненты инференса вроде prefill и decode как единое целое.

Платформенные команды получают ещё один вариант GPU-оркестрации без обязательной привязки к подписке — вопрос в том, станет ли он стандартом или просто добавится к списку альтернатив.

@DevOpsKaz 😛

🔥 Вакансия: Cloud DevOps Engineer

Компания Prime Cloud ищет Cloud DevOps Engineer уровня Middle-Senior с сильной базой Linux + Terraform + GitLab CI/CD + Kubernetes Architecture + troubleshooting.

Важно уметь самостоятельно проектировать и сопровождать production Kubernetes-платформу, стандартизировать IaC/CI/CD и работать как managed-service инженер в многоклиентской среде.

Уровень: Middle-Senior
Опыт: 3–5+ лет в DevOps / Cloud / System Engineering, включая самостоятельную ответственность за production-среды
Зарплата: 1 200 000 тенге на руки
Формат: Удаленка / Гибрид

Цель — развивать и эксплуатировать управляемый DevOps-сервис Prime Cloud для нескольких клиентов: автоматизировать инфраструктуру и delivery-процессы, стандартизировать CI/CD и IaC, сопровождать Kubernetes, monitoring и клиентские среды по SLA.

👈 Полное описание вакансии

Ключевые задачи

⚪️Разработка и сопровождение стандартных CI/CD-процессов для клиентов Prime Cloud.
⚪️Создание и поддержка Terraform-модулей, Ansible-ролей и повторяемых шаблонов инфраструктуры.
⚪️Автоматизация создания VM, сетевых и сервисных компонентов, environments и клиентского onboarding.
⚪️Проектирование, развертывание и сопровождение Kubernetes-кластеров и приложений: HA, Helm, CNI/CSI, ingress, storage, RBAC и multi-tenancy.
⚪️Настройка monitoring, alerting, logging и базовой observability для клиентских сред.
⚪️Работа с Git/registry/secrets и интеграциями между DevOps-платформой, ITSM и клиентскими системами.
⚪️Диагностика Linux, network, container, Kubernetes и CI/CD инцидентов; участие в RCA.
⚪️Подготовка runbook, эксплуатационной документации и типовых процедур для Service Desk / CloudOps.
⚪️Участие в изменениях production по согласованному change-процессу и SLA.
⚪️Участие в дежурствах и эскалации критических инцидентов согласно графику.

Инженер не должен решать повторяющиеся задачи вручную, если их можно стандартизировать и автоматизировать. Все reusable-решения должны превращаться в модули, роли, шаблоны, runbook и каталожные элементы сервиса.

👈 Контакты для связи:

igorbelikov84@gmail.com
+7 701 222 67 30 в TG

@DevOpsKaz 😛

🔥 4 вакансии в облачную платформу национального масштаба

Коллеги из Alem.ai Global (дочерней организации Astana Hub) создают облачную платформу национального масштаба для работы с госорганами, квазигос сектором и бизнесом, а также развивают международные проекты экосистемы Хаба. Команда только собирается — вы будете среди первых.

Платформу сейчас разрабатывает опытный подрядчик, а Alem.ai Global собирает свою техническую команду, которая примет ее и будет развивать дальше.

Кого ищут:

⚪️ Технический директор (CTO)

Собрать и вести техническую команду. Развивать архитектуру и инфраструктуру. Готовить платформу к ИБ-испытаниям.

⚪️ DevOps-инженер

Принять инфраструктуру и отвечать за нее: Kubernetes (3 master, 5 worker), Helm, ArgoCD, GitLab CI. PostgreSQL и MongoDB Primary/Standby, Redis-кластер, RabbitMQ, Qdrant. Prometheus, Grafana, ELK, OpenTelemetry.

⚪️ Low-Code разработчик

Собирать интерфейсы, бизнес-логику, сценарии и автоматизации. Писать функции и скрипты на Js. Проектировать модели данных, интегрировать AI.

⚪️ Системный / бизнес-аналитик

Писать ТЗ, user stories, схемы BPMN и UML, критерии приемки. Принимать работу подрядчика. Вести интеграции с гос системами.

👈 Резюме отправляйте на почту cv@astanahub.com. В теме письма укажите: «Alem.ai Global — Название вакансии»

@DevOpsKaz 😛

🔥 BPF ksock — API для Linux

В ядре Linux предлагают API BPF ksock: он даёт BPF-программам собственные сетевые сокеты и позволяет слать данные прямо из ядра, без отдельного процесса в пользовательском пространстве.

👈 Детали — в cтатье.

Первая версия даёт 5 kfunc для UDP:

⚪️ создание сокета
⚪️ подключение к удалённому адресу
⚪️ отправка данных
⚪️ закрытие соединения
⚪️ и освобождение ресурсов

Пригодится для событий безопасности из BPF LSM и телеметрии без лишнего копирования данных между ядром и userspace. В планах авторов — поддержка TCP, приём данных и другие операции с сокетами.

Если направление приживётся, часть observability- и security-агентов со временем может меньше зависеть от постоянного процесса в userspace — но пока это тема для обсуждения на конференции разработчиков ядра, а не принятый патч.

@DevOpsKaz 😛

🔥 IT-инфраструктура на практике: разборы и решения

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

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

⚪️ Cлишком большие VLAN, ненужный STP и другие ошибки в дизайне L2/L3

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

⚪️ Чтобы понять Kubernetes, я написал свой Kubernetes

На примере оркестратора на Go автор рассказывает о маршрутизации контейнеров, работе iptables и циклах согласования. Показывает, какие ошибки помогают понять архитектуру K8s.

⚪️ Как настроить nftables на удалённом сервере без риска потерять SSH‑доступ

Как менять правила фаервола на удалённом Linux-сервере, не обрывая SSH-сессию. Разобраны атомарная загрузка конфигурации, автоматический откат и типичные ошибки с conntrack.

⚪️ Как диагностировать тормоза Linux‑сервера без перезагрузки вслепую

Пошаговая проверка загрузки CPU, памяти и дисковой подсистемы с помощью top, vmstat, iostat и других утилит. Помогает найти причину замедления сервера без перезагрузки.

⚪️ Статистика PostgreSQL: почему запросы выполняются медленно

Как PostgreSQL оценивает стоимость запросов и выбирает план выполнения. Разбор статистики в pg_class и pg_stats, работы ANALYZE и причин ошибочных оценок, замедляющих запросы.

⚪️ Как собрать Linux‑контейнер с нуля без Docker: unshare, pivot_root и rootfs

Как работают пространства имён, изоляция файловой системы и монтирование в Linux на практике. Помогает разобраться в механизмах, лежащих в основе Docker и Kubernetes.

@DevOpsKaz 😛

⚡️ Знаете, что сильнее всего экономит время и нервы в IT?

💡 Чужой опыт, за который уже заплатили другие.

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

Именно ради такого обмена опытом мы с коллегами по цеху объединились в общую папку.

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

В папке плотная выжимка по всем фронтам:

— от жесткого бэкенда, DevOps и кибербезопасности
— до системного анализа, искусственного интеллекта и внутренней кухни управления разработкой

Читаешь чужие разборы, подсматриваешь неочевидные заходы, забираешь готовые схемы себе в проекты и экономишь кучу времени на тестах.
━━━━━━━━━━━━━━━━
👈 Саму папку можно добавить в один клик.

🔥 Как мокирование зависимостей влияет на надёжность CI/CD

Мокирование зависимостей делает CI/CD быстрее и стабильнее: с ним тесты не зависят от сетевых задержек, лимитов чужого API и перебоев сторонних сервисов. Но есть риск в том, что мок перестаёт отражать реальный сервис: пайплайн остаётся зелёным, а в продакшене интеграция падает, потому что контракт изменился, а мок — нет.

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

Как снизить риск дрейфа между моком и реальным сервисом, читайте в новой статье.

👈 Читать

@DevOpsKaz 😛

🔥 Вакансия: Начальник Управления ИТ инфраструктуры

Компания Alatau City Invest (онлайн-брокер, предоставляющий клиентам полный доступ к инвестиционным инструментам) ищет специалиста, который возьмет под контроль управление и развитие IT-инфраструктуры.

👈 Полное описание вакансии и отклик

Основные задачи:

⚪️ Организация бесперебойной работы и развитие ИТ-инфраструктуры (серверы, сети, виртуализация, облачные сервисы, СУБД, почтовая система).
⚪️ Планирование, распределение задач, контроль исполнения, наставничество и оценка сотрудников.
⚪️ Обеспечение резервного копирования, аварийного восстановления и непрерывности ИТ-сервисов; поддержание актуальности DR-плана.
⚪️ Обеспечение соответствия ИТ-инфраструктуры требованиям АРРФР/НБК и внутренних документов; взаимодействие с Управлением информационной безопасности по вопросам уязвимостей и инцидентов.
⚪️ Организация мониторинга ИТ-систем и управление инцидентами и изменениями.
⚪️ Планирование ИТ-бюджета, организация закупок, взаимодействие с вендорами и подрядчиками.
⚪️ Подготовка и актуализация технической документации и регламентов, устранение замечаний аудита.
⚪️ Руководство проектами по миграции, модернизации и внедрению ИТ-систем.

Пожелания по hard skills:

⚪️ Высшее техническое образование (информационные технологии, информационная безопасность, телекоммуникации или смежные направления)
⚪️ опыт не менее 3 лет, из них на руководящей должности не менее 1 года, приветствуется опыт работы в финансовой организации, регулируемой АРРФР/НБК
⚪️опыт работы с Windows Server, Active Directory, VMware vSphere / VMware Cloud Director, Linux, Kubernetes, FortiGate, Microsoft 365 / Exchange, СУБД (Oracle, PostgreSQL, MongoDB), NAKIVO, IBM Instana, Prometheus/Grafana

@DevOpsKaz 😛

🔥 Как K2 Cloud построили облако на 5 ЦОДов и автоматизировали железо

Любое облако физически живет на серверах. Если на базовом физическом уровне хаос — упадет все. Тимлид K2 Cloud поделился историей инфраструктуры K2 Cloud: от кабельного кошмара и сгоревших PDU до тотальной автоматизации физического слоя.

Статья описывает эволюцию физической и программной инфраструктуры: от хаотичного ручного управления железом на заре проекта к жесткой стандартизации стоек, классической архитектуре сети (Leaf-Spine) и тотальной автоматизации жизненного цикла оборудования через GitOps-подобный подход (манифесты, Ansible, DCIM, Zabbix).

👈 Читать статью

Надежность облака начинается с железа. Без стандартизации стоек и кабельной системы неизбежны физические аварии.

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

Декларативность рулит железом. Перенос подходов IaC на коммутаторы, конфигурации BIOS/BMC и размещение серверов через DCIM-интеграции превращает хаотичные ручные операции в быстрый, предсказуемый и безопасный конвейер.

А мы напоминаем, что сравнить облачных провайдеров Казахстана можно на нашей специальной странице. Также Core 24/7 может помочь с миграцией вашей инфраструктуры из одного облака в другое, с железа в облако или внедрить гибридный сценарий.

@DevOpsKaz 😛

🔥 Лабораторные работы по Kubernetes

Как же приятно исправлять ошибки и восстанавливать работу кластеров без стресса, переживаний и спешки. Такой опыт могут подарить лабораторки SnowOps Labs: выбираете сценарий → запускаете → пытаетесь разобраться с проблемой. Сценарии можно выбрать в веб-интерфейсе.

Лабы разбиты на категории:

⚪️ SRE
⚪️ Observability
⚪️ GitOps & CI/CD
⚪️ Security & Compliance
⚪️ Chaos Engineering
⚪️ Autoscaling Under Load и др.

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

Пользуйтесь и делитесь с коллегами — особенно с теми, кто только начинает путь в профессии 🫡

@DevOpsKaz 😛

🔥 Почему PHP2Shell критичен для инженерных команд и что с этим делать

Наверняка вы слышали про PHP2Shell — 2 критические уязвимости с оценкой CVSS 9.2, которые поставили весь интернет на ноги, ведь они позволяют неаутентифицированному злоумышленнику удалённо выполнить код почти на любом PHP-сервере. Напомним, что 70% всех сайтов написаны именно на PHP. Примечательно, что обе уязвимости выявлены с помощью AI-ассистентов.

Уязвимости затрагивают все способы обслуживания web-запросов — PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed, причём наибольший риск, по оценке команды PHP, несёт mod_php.

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

👈 В новой статье — разбор уязвимостей PHP2Shell и того, как поведенческий Runtime-контроль защищает контейнеры и Kubernetes, пока раскатываются патчи

Делитесь постом с коллегами, чтобы и они могли обезопасить свои системы 🫡

@DevOpsKaz 😛