Как вырасти до мидла: на что на самом деле смотрят тимлиды при оценке DevOps-инженеров
В начале карьеры может казаться, что для перехода с junior-уровня на middle достаточно выучить новые инструменты или просто набить пару лет опыта. На практике всё решает не только техническая база, но и мышление. То, как вы смотрите на задачу: просто «закрыть тикет» или понять, как ваше решение встроится в систему и повлияет на соседние компоненты.Я Алексей Сартаков, тимлид команды DevOps-инженеров во «Фланте». За годы работы вижу одну закономерность: быстрее растут не те, кто знает больше, а те, кто умеет видеть связи, вовремя задавать вопросы и брать ответственность за результат, а не только за строчку в манифесте чарта.
Эксперты для облачной индустрии: старт набора в совет АОТ
Привет, Хабр! На связи Александр Титов, директор Ассоциации профессионалов индустрии облачно-ориентированных технологий «АОТ», организатор сообщества DevOps Moscow и генеральный директор «Фланта». Это первая публикация в блоге АОТ на Хабре, но вы уже могли видеть новости о нас, побывать на конференции Kuber Conf by АОТ или участвовать в нашем исследовании State of Cloud Native
Приглашаем экспертов в совет по развитию облачных технологий в России
Привет, Хабр! На связи Александр Титов, директор Ассоциации профессионалов индустрии облачно-ориентированных технологий «АОТ», организатор сообщества DevOps Moscow и генеральный директор «Фланта». Это первая публикация в блоге АОТ на Хабре, но вы уже могли видеть новости о нас, побывать на конференции Kuber Conf by АОТ или участвовать в нашем исследовании State of Cloud Native
Автотесты: опыт построения системы качества для Kubernetes-платформы
На старте проекта у нас не было ни одного автотеста. При этом продукт уже представлял собой полноценную платформу контейнеризации на базе Kubernetes с большим количеством управляемых сервисов и единой консолью управления. Любое изменение могло затронуть базы данных, брокеры сообщений, системы хранения данных или внутренние управляющие компоненты платформы.
Когда компании пора строить свой LLM-кластер, а не пользоваться внешними API
На раннем этапе внедрения LLM в компании выглядят как быстрый выигрыш: подключается внешний API (например, ChatGPT), ускоряется работа с текстами, автоматизируются ответы, появляются первые сценарии аналитики и агентных пайплайнов через Make или n8n.До определённого масштаба этого достаточно.По мере роста компании LLM перестаёт быть вспомогательным инструментом и становится частью операционных процессов. В системе появляются чувствительные данные, требования к контролю доступа, необходимость стабильной работы, интеграции во внутренние сервисы и вопросы экономики при больших объёмах запросов.
Загадка ядра Linux: почему на 36 vCPU Cilium падает, а на 32 — нет
Автор оригинальной статьи, Пьер Мане, рассказывает, как его команда столкнулась с на первый взгляд необъяснимым поведением Cilium и как поиск решения привёл его к конфигурации ядра Linux.Отладка сродни археологии: ты пробираешься сквозь слои абстракций, пока не доберёшься до коренной породы — ядра. Это история о том, как скрытая в коде Linux логика работы со степенями двойки приводила к случайным и загадочным падениям Cilium, из-за чего мы не могли выкатиться в production.
От Prometheus к Victoria Metrics: как мы пересобрали мониторинг в Kubernetes
1. ВведениеВсем привет! Меня зовут Яблоков Олег, я — ведущий инженер ИТ-отдела Navio и отвечаю за систему мониторинга основной инфраструктуры компании. Это работа на стыке разработки и эксплуатации (development & operations, DevOps), наблюдаемости (Observability) и обеспечения надёжности сервисов (Site Reliability Engineering, SRE). Моя основная задача не просто собирать метрики, а сделать так, чтобы по ним можно было быстро понять статусы сервисов и не утонуть в шуме оповещений.
Только Сигма выбирают Delta Lake
Привет, Хабр! Меня зовут Дмитрий Кравчук, я занимаюсь всем, что связано с данными в блоке AI&ML MAGNIT TECH. Расскажу про фундамент прибыльных проектов, которыми мы занимаемся в департаменте. Это начало цикла статей о наших достижениях за 5 лет и планах на будущее.
Model Predictive Control для Kubernetes autoscaling: что получилось, где HPA оказался сильнее
Горизонтальное автоскалирование в Kubernetes обычно начинается с HPA. Это понятный и практичный механизм: контроллер смотрит на метрику, например CPU, и меняет число реплик Deployment. Для многих сервисов этого достаточно.Проблема начинается там, где нагрузка меняется быстрее, чем контур успевает на неё отреагировать. Метрика должна быть собрана, решение должно быть принято, новые Pod’ы должны запуститься и пройти readiness. Пока всё это происходит, старые Pod’ы уже могут работать на пределе, а хвостовые задержки p95/p99 — расти.
