DevOps *

Я тут недавно пытался попасть на бесплатные курсы от Aston, но получил отказ с такой формулировкой.

Денис, добрый день! После изучения вашей анкеты, к сожалению, мы не готовы пригласить вас к дальнейшему рассмотрению на обучение в компании. У нас очень большой поток кандидатов на курсы. В данный момент взяли в рассмотрение участников с показателями выше. Ваша анкета будет сохранена, возможно, вернемся к вашей кандидатуре, при наборе на следующий поток. Благодарим за внимание к нашей компании.

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

Сегодня хочу попробовать пройти тестовое задание от клауд.ру. Оно охватывает тот самый стек для devops, linux, docker, git, kubernetes.

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

Тестовое задание состоит из 4 задач, начнем с первой.

Kubernetes без магии и заучивания команд. Разберёмся, зачем он вообще нужен, как устроен кластер, чем Control Plane отличается от Worker Nodes и какую роль играют Pod, Scheduler, kubelet, etcd и другие основные компоненты.

Когда вы в последний раз проверяли свои репозитории на забытые токены? Пока вы скроллите ленту, боты парсят GitHub и подхватывают утекшие ключи за 2–3 минуты. Мы собрали главные дыры — от .env и CI-логов до ИИ-конфигов. В конце чек-лист, чтобы проверить себя за пару минут.

Когда говорят про High Availability, довольно быстро получается классическая картина: три сервера, балансировщик, кластер PostgreSQL, распределённое хранилище, мониторинг и ещё несколько компонентов, про которые никто не вспоминал, пока всё работало на одной виртуалке.

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

При этом хотелось выполнить несколько условий:

1) падение одной основной VM не должно останавливать систему;

2) PostgreSQL должен автоматически переключаться;

3) приложение должно понимать, на какой ноде ему разрешено выполнять активные операции;

4) пользовательские файлы должны оставаться доступными после переключения;

5) переключение не должно требовать ручного изменения DNS;

6) всё должно разворачиваться и обслуживаться через Ansible;

7) покупать третью полноценную машину только ради кворума не хотелось.

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

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

Sheeternetes держит кластер контейнеров, у которого control plane — электронная таблица. Этот пост — про то, как заставить два таких кластера работать как один: on-prem-кластер поверх локального Excel-файла и облачный поверх Google-таблицы — по сети, с общей ёмкостью, живой миграцией и рантаймом, которому не нужен Docker. Всё воспроизводимо; код — один небольшой репозиторий.

Привет, Хабр! Значю, что вам на это плевать и вы не хотите это читать, но я все равно продолжу это писать:) В общем, Sheet-Native Computing Foundation продолжает цвести и пахнуть и у нас даже есть сторонние контрибьюторы. А чего добились вы?

Итак, вот что теперь можно сделать в таблице: запушить в неё настоящий OCI-образ контейнера и вытянуть его обратно. Не ссылку на образ, не метаданные о нём — сами слои, хранящиеся как base64 по ячейкам, с адресацией по sha256, собирающиеся байт-в-байт на выходе. У SheetHub — нашего форжа в стиле GitLab, который работает на Google-таблице — появился реестр контейнеров, и он целиком живёт в ячейках.

Этот пост — про то, как это всё устроено.

Привет! Я Сергей Житинский, основатель Git in Sky. Мы занимаемся эксплуатацией и технической поддержкой ИТ-инфраструктуры. Agent-Ops — проект открытой отраслевой методологии совместной работы инженеров и ИИ-агентов. Мы начали разрабатывать его весной этого года и сейчас выложили первый кандидат версии 0.4.0 на GitHub и GitVerse. Одновременно, на конференции IT Elements 2026 мы договорились о совместной работе с инженерами из 2х других компаний, они стали у нас maintainers. Поэтому сегодня Agent-Ops - это не инициатива только одной компании, а совместной работа нескольких. Надеюсь, количество единомышленников будет увеличиваться. Приглашаем контрибуторов развивать этот проект вместе с нами.

Я ожидаю масштабных изменений в ИТ-отрасли, поэтому решил лично заняться этой работой внутри Git in Sky, а наши подходы и предложения вынести на обсуждение профессионального сообщества. Меняется сама организация работы: кто исследует проблему, на каком основании предлагает решение, кто разрешает изменение и кто отвечает, если оно привело к аварии.

Ниже расскажу, как мы предлагаем устроить этот процесс и что вошло в редакцию 0.4.0. Её текущий статус — публичный нормативный кандидат: проект правил для обсуждения и дальнейшего развития.

Я ожидаю масштабных изменений в ИТ-отрасли, поэтому решил лично заняться этой работой внутри Git in Sky, а наши подходы и предложения вынести на обсуждение профессионального сообщества. Меняется сама организация работы: кто исследует проблему, на каком основании предлагает решение, кто разрешает изменение и кто отвечает, если оно привело к аварии.

Ниже расскажу, как мы предлагаем устроить этот процесс и что вошло в редакцию 0.4.0. Её текущий статус — публичный нормативный кандидат: проект правил для обсуждения и дальнейшего развития.

Меня зовут Кирилл Манин, я почти шесть лет работаю в команде SQL DBA и занимаюсь развитием платформы баз данных Авито.

Почти всё это время к нам регулярно обращались разработчики микросервисов: «Можно нам читать с реплик?» и «Как подключиться к реплике для чтения?». Мы всегда отвечали одинаково: платформа не поддерживает чтение с реплик, и добавлять такую возможность мы пока не планируем.

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

Практические приёмы снижения копипасты и упрощения конфигурирования множества сходных проектов в TeamCity.

Подготовили чек-лист по готовности к платформенной инженерии. Внутри - Не тест на знание команд – команды гуглятся. Список из десяти задач, каждую из которых вы либо делали руками от начала до конца, либо нет. Дальше будет сам чек-лист, разбор каждого пункта (почему формулировка именно такая и как проверить себя за вечер) и шкала интерпретации.

Привет! Это Скутин Антон. Я работаю в «Петрович-Тех» руководителем отдела обеспечения доступности ИТ-сервисов. Моя предыдущая статья была про ITIL. В этот раз я решил рассказать о том, как построить наблюдаемость, когда нет ни CMDB, ни oncall.

Эту тему я рассказывал на Observability Conf, коллеги завалили вопросами, поэтому решил поделиться здесь, подключайтесь в комментарии — обсудим!

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

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

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

В статье разберём, как организован сбор покрытия в ОС «Нейтрино»: от сборки компонентов и получения файлов .gcno и .gcda до формирования трассировочных файлов и объединения результатов из различных CI/CD‑конвейеров. Также рассмотрим особенности формирования итоговых отчётов и расскажем, почему в дальнейшем планируется переход с lcov на gcovr.

SRE‑инженер Mindbox Дима Рыбалка рассказывает, как команда за два месяца перенесла 40 кластеров ClickHouse в Yandex Cloud. Внутри — как выбирали стратегию миграции, связывали кластеры без VPN, переключали клиентов через cutover без даунтайма и с какими столкнулись проблемами после миграции. Материал будет полезен SRE‑, DevOps‑ и DBA‑инженерам, которые работают с ClickHouse в Kubernetes.

По прогнозу Gartner, к концу 2026 года task-specific AI-агенты будут встроены в 40% корпоративных приложений против менее чем 5% в 2025-м по оценке той же Gartner. Безопасность агента обычно сводят к guardrails, промпт-фильтрам и хорошо написанной системной инструкции. Однако в июле 2025-го случился инцидент —  агент Replit удалил прод-базу SaaStr, хотя его несколько раз просили ничего не менять. А в июле 2026-го на Хабре был опубликован разбор того, как имя, работодатель и город пользователя ушли наружу через Claude без единого клика с его стороны.

Об этих случаях известно только потому, что их публично разобрали — и спасибо тем, кто это делает. Но о скольких ещё случаях мы не знаем? CNCF за восемь июльских дней выпустил три материала подряд об изоляции агентов. Посмотрим, что они предлагают и как собрать из этого рабочий контур из трёх слоёв, с манифестами.

Переименование проекта в Docker Compose может создать новые пустые volumes, пока старые данные спокойно остаются на диске. Разбираю, какие внутренние идентификаторы нельзя менять через Replace All и как провести ребрендинг с возможностью отката.

Объём неиспользуемых ресурсов не уменьшается (хотя вроде как должен), а узлы бесконечно ротируются. Это нормально для автоскейлера или пора что-то чинить?

В статье — детально о механизме консолидации в Karpenter, а главное — можно (и нужно) ли как-то его исправлять.

Привет! Меня зовут Женя, я деврел в Банки.ру. Короче, у нас есть подкаст “про код.ии.прод” и на Хабре в комментариях нам предложили расшифровать выпуски и оформить их в статьи. Мы любим эксперименты — поэтому решили попробовать. Главное, чтоб зашло вам, друзья.

В прошлый раз мы разгоняли про вайбкодинг: усиливает он инженера или ведет к деградации навыков. Идем дальше. Принимаем как факт, что ИИ помогает писать код быстрее. Но разработка это не только написание кода. Есть постановка задач, ревью, тесты, интеграция, деплой, поддержка, инциденты... Главный вопрос выпуска: ИИ ускоряет путь от идеи до прода целиком или просто генерирует больше кода и пулл-реквестов?

Эта статья — история о том, как небольшая команда перевела медицинскую информационную систему с устаревшей платформы 1С 7.7 на 1С 8.3 и выстроила вокруг неё современные практики разработки: контроль версий, код-ревью, автотесты, CI/CD. Дальше — сама история.

В начале двухтысячных классные специалисты разработали систему для клиники на базе 1С 7.7. Функционал включал как административно-хозяйственную часть, так и работу с пациентами. Программный продукт проработал почти два десятилетия, код отладили и протестировали самой жизнью, а идея, что новый код может оказаться лучше старого, казалась совершенно абсурдной. Система при этом технологически устарела: ручное формирование XML отнимало значительное количество времени у программиста, а запросы к БД и обработка данных таблиц для отчётов могли занимать десятки минут. Казалось бы, простые интеграции как XML и REST реализовывали через костыли. Экстренную правку кода приходилось вносить с отключением всех пользователей программы на несколько минут — динамическое обновление для семёрки попросту не разрабатывали.

В 2020 году руководство клиники приняло решение о миграции на новый технологический стек и через год привлекли разработчиков. Всерьёз рассматривался только вариант 1С 8.3: на момент принятия решения других вариантов, сопоставимых по зрелости экосистемы и доступности специалистов на рынке, просто не существовало. Речь шла не о внедрении готового отраслевого решения, а о разработке под одного конкретного заказчика — максимально повторяющей то, к чему сотрудники клиники привыкли за два десятилетия. Устоявшиеся процессы, интерфейсы документов и порядок работы заказчик менять не планировал.

Продолжая поиски интересных курсов(в этот раз не авито), я наткнулся на необычный материал по контейнеризации. Обычно всё выглядит одинаково: Docker, команды, образы, и в конце внезапно появляются Ansible и Kubernetes. Как будто без них нельзя объяснить, что такое контейнер. Или авторы просто пытаются запихнуть побольше в один курс, чтобы казалось, будто его стоимость оправдана. Ну да ладно.

А мне хотелось чего-то другого. Помните книгу про внутреннее устройство Linux Кетова?
Ещё в 2022 году мне понравилось, как подавался материал про контейнеризацию — от самых её зачатков (chroot) до самого Docker. Вот именно такое я хотел увидеть у кого-нибудь, но с актуализированной информацией.

И такой курс нашёлся на Степике(не реклама если что). Автор как раз пошёл от самого начала: chroot, пространства имён, контрольные группы, ручной запуск контейнера без Docker, и только потом — сам Docker со всеми его фишками. По сути, это получилась современная версия той самой главы из книги Кетова про контейнеризацию.