DevOps *

До Go 1.25 рантайм по умолчанию выставлял GOMAXPROCS по числу логических CPU на ноде — и в контейнерах это регулярно приводило к странным эффектам: лишние потоки, перерасход квоты и жёсткий троттлинг cgroups с неприятной просадкой задержек, особенно в «хвосте». В статье разбираем, как устроено планирование горутин, чем CPU-лимиты в Kubernetes отличаются от ограничения параллелизма, и почему новый дефолт GOMAXPROCS делает поведение Go в продакшене заметно предсказуемее.

Всем привет!
Меня зовут Хрулев Иван, я ведущий менеджер продукта Astra Automation.
Мы с командой создаем платформу, позволяющую закрыть все ключевые задачи автоматизации на ИТ-инфраструктурах любых масштабов.

За последние годы автоматизация стала «базой»: без неё невозможно ни масштабирование, ни стабильная эксплуатация, ни предсказуемая безопасность. 
При этом многие команды до сих пор живут в мире разрозненных скриптов, ручных операций и инструментов, которые сложно поддерживать и развивать.
В этой статье я расскажу, как новая версия Astra Automation 2.0 меняет сам подход к автоматизации и почему платформа сегодня выглядит совсем иначе, чем раньше.

Команда Deckhouse Storage рассказала о поддерживаемых в наших платформах CSI с использованием реализаций от вендора (для платформ Huawei, HPE, NetApp и Yadro), а также о собственном универсальном CSI-драйвере csi-scsi-generic, который поддерживает интеграцию с любыми системами хранения данных.

Мы забыли вовремя создать партиции, и все новые данные полетели в events_default_partition. Default дорос до ~1.1 ТБ, а простое «ATTACH PARTITION» требовало часов сканирования и долгой блокировки. В статье — почему «быстрые» рецепты оказываются медленными, как я перенёс данные в нужные диапазоны, и как мы уложили критическую блокировку в 44 с.

Default-партиция — это не озеро Байкал. Если туда всё сливать, экосистема потом мстит.

Как-то, у нашей компании накопился ряд задач, связанных с администрированием наших серверов, и руководство приняло решение, что всё-таки нам нужен DevOps, который закроет наши вопросы и будет в долгую сопровождать нашу команду. Решились. Разместили на https://hh.ru/ вакансию. Нашли человека в городе М.. Руководству было важно, чтобы он был с того же города, где и компания. Но мы никак не могли предположить, что этот человек, который проработал с нами буквально 6 месяцев, чуть не потопил всю нашу компанию. Но, обо всём по порядку.

Привет, Хабр. Это дайджест для тех, кто занимается бэкендом: от продакшен-Docker, CI/CD и Kubernetes до баз данных, мониторинга и архитектуры сервисов. Мы собрали открытые уроки и курсы, которые фокусируются не на абстрактной теории, а на реальных задачах — масштабировании, отказоустойчивости, наблюдаемости и поддержке сложных систем в проде. Если вы развиваете бэкенд-сервисы, отвечаете за их стабильность или хотите системно расти от уровня к уровню, здесь можно точечно закрыть пробелы и выстроить понятную траекторию обучения.

Nginx часто воспринимают как «просто веб-сервер», который достаточно поставить и запустить с дефолтным конфигом. На этом этапе обычно и останавливаются: процессы работают как попало, заголовки отдаются по умолчанию, SSL настроен формально, keepalive либо не используется, либо вредит, а маршрутизация запросов со временем обрастает хаотичными location. В результате конфигурация вроде бы выполняет свою задачу, но остаётся плохо управляемой, неочевидной и далёкой от оптимальной.

Эта статья — о базовых, но часто недооценённых возможностях Nginx. Мы последовательно разберём настройку рабочих процессов, управление HTTP-заголовками, корректную конфигурацию SSL, работу keepalive-соединений и маршрутизацию запросов. Без магии и редких трюков — только то, что действительно используется в продакшене и позволяет сделать конфигурацию понятной, предсказуемой и безопасной даже для начинающего администратора.

Подход 2 – «семь раз отмерь, один отрежь»

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

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

Всем привет! Меня зовут Андрей, с Банки.ру я связан уже больше 14 лет, а сейчас руковожу командой Платформы и забочусь о гильдии девопсов.

Итак, в течение своей работы я очень часто сталкивался с разными инцидентами продакшена. Конечно, в моменте бывало невесело: многие факапы были сложными и требовали довольно много времени на расследование.

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

Стабильность E2E-тестов: как добиться 100% успешных прогонов ?

Практика, проверенная на реальном проекте.

Флаки-тесты убивают доверие к автоматизации. В этой статье — проверенные подходы, которые помогают превратить нестабильные E2E-прогоны в надёжный инструмент проверки продукта.

В статье — проверенные практики от сообщества Kubernetes: от выбора версии API и работы с YAML до управления подами и лейблами. Плюс несколько советов от команды Deckhouse по работе с ресурсами и автомасштабированием.

Настроить сервер FreeIPA (систему управления идентификацией) с использованием собственного (внешнего) корневого сертификата вместо самоподписанного.

Год назад я не знал о Kubernetes практически ничего. Сегодня у меня свой pet-проект развернут в облачном кубере, и я чувствую себя достаточно уверенно, чтобы делиться опытом. Что изменилось? Я начал преподавать в МАИ и проходить сертификацию по работе.

Звучит парадоксально, правда? Обычно всё наоборот - сначала учишься, потом учишь других. Но в моем случае именно преподавание стало катализатором интенсивного обучения. И в этой статье я расскажу, как это работает и какой путь я прошел.

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

Если совершенно случайно в вашей работе возникают критические ошибки на проде, которые исправляются слишком долго. А еще, возможно,  специалисты по безопасности начинают выявлять уязвимости только после релиза. Или вдруг в команде используются ручные проверки, например: сборки кода выгружаются вручную, а ИБ их «бесконечно долго» сканируют и отдают вместе со своим рукописным отчетом.

Эта статья по мотивам моего доклада на UWDC для тех, кто хочет глубже разобраться в DevSecOps и больше узнать про пользу, которую он может принести. Поговорим о том, как находить баланс между технологиями и людьми, достигать результата, и, главное, какие ошибки проще предотвращать, чем потом исправлять.

Меня зовут Павел, я руководитель направления Professional Services в Orion soft. Мы занимаемся экспертным аудитом и решением сложных задач, а Orion soft производит программное обеспечение для инфраструктурного слоя, в том числе контейнеризации и виртуализации (Nova и zVirt). Мы тоже не сразу пришли к DevSecOps и поломали немало граблей, поэтому мне есть чем поделиться.

Недавно получил задачу сделать автоматизированную оцифровку характеристик из паспортов товаров в БД, а не изменение параметров вручную в ERP. Я подумал, было бы здорово поделиться, как я это сделал, с вами на Хабре!

Продолжение серии статей о BareMetal CI. В первой части мы рассмотрели базовый подход к автоматизации тестирования микроконтроллеров с использованием J-Link и RTT. Эта статья посвящена масштабируемому решению на базе Docker, которое поддерживает различные типы оборудования и CI-платформы.

Мы тут в Cozystack в очередной раз решаем проблему курицы и яйца: как задеплоить CNI и kube-proxy через Flux, но при этом обеспечить работу самого flux без CNI и kube-proxy.

Сам Flux запустить без CNI и kube-proxy можно используя проект flux-aio (от создателя Flux), который запускает единый deployment со всеми контроллерами настроенными на коммуникацию друг с другом через localhost.

Специфика Cozystack заключается в том, что на каждый кластер мы деплоим внутри небольшой HTTP-сервер с Helm-чартами и другими ассетами используемыми в платформе. Flux эти чарты читает и устанавливает в систему.

Но вот как организовать доступ флюксу к внутреннему HTTP-серверу, запущенному как под внутри того же кластера?

Несмотря на то что в России последние годы идет явный тренд на импортозамещение, многие компании продолжают пользоваться не только отечественными, но и зарубежными облаками. У кого‑то остались подразделения за границей, кто‑то завязан на legacy‑решения, которые дешевле оставить как есть, чем переезжать, а кому‑то просто лень. Причины у всех разные, но объединяет их одно: необходимость свести этот облачный зоопарк в понятную модель затрат, с которой будет удобно работать всем. 

Мы в Ситидрайве строим микросервисную архитектуру. Сегодня у нас 200+ сервисов, за которыми стоят свыше 20 автономных команд — всего больше 150 инженеров. Казалось бы, идеальная модель: каждая команда быстро выкатывает свои фичи без лишней бюрократии. Но была и обратная сторона — нет единого понимания, какие сервисы действительно критичны, как они связаны друг с другом и куда развивать систему дальше.

Но нам удалось с этим справиться — мы привели сотни микросервисов в порядок и сделали систему предсказуемой. В этой статье я расскажу про путь команды к внедрению тир-листа, модели зрелости, управлению зависимостями и приоритетами инцидентов.