Знакомая картина: в 3 часа ночи падает база данных, Alertmanager засыпает каналами, через 5 минут сеть восстанавливается, но… система остаётся «мёртвой». CPU на воркерах 100 %, Goodput на нуле, а перезапуск подов только усугубляет ситуацию. Все указывает на то, что вы столкнулись с метастабильным отказом — самым коварным типом аварий в распределённых системах.

Меня зовут Артём Баранов, в «Базисе» я занимаюсь автоматизацией и развитием инфраструктуры. В этой статье я хочу рассказать о математике метастабильного отказа и через теорию массового обслуживания — конкретно через модель и формулу Кингмана — проложить мост от математических абстракций к реальным логам, метрикам и алертам. Далее, предложить практикующему SRE-специалисту набор методик для анализа, диагностики и предотвращения катастроф, возникающих в информационных системах по тем или иным причинам (ошибки конфигурирования, сбои «железа» и т. д.). Это позволит инженеру распознать sustaining-эффект по логам и метрикам и осознанно выбрать рычаг (backoff, retry budget, shedding, circuit breaker), а не просто объяснить постфактум, почему возникла предыдущая авария.

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

У меня возникла такая задача: есть куча файлов, на которые хорошо бы натравить нейросеть, чтобы она искала ответы прямо по ним, а не выдумывала. Файлы разнородные, среди них тяжелые PDF. Закинуть их в модель целиком не выйдет: контекстное окно забьется раньше, чем она доберется до сути. Нужен способ скармливать модели не весь архив разом, а только нужный кусок. Так мне пришла идея применить MCP «с другой стороны» — не для агента, а для аккуратного доступа к большому архиву локальных документов.

По данным GitLab, 91% компаний держат в работе минимум два ИИ‑инструмента, 54% — три и более. 78% команд пишут и коммитят код быстрее, чем раньше, 60% говорят, что отдача от ИИ превзошла ожидания, 73% отмечают рост качества кода. По любым меркам внедрение состоялось. А теперь «менее успешная цифра»: 80% признают, что подключили ИИ‑инструменты раньше, чем придумали, как ими управлять. Скорость обогнала контроль, и вся история начинается ровно на этом стыке.

Последние несколько месяцев я пристально слежу за тем, как растет и меняется Flux CD. Для тех, кто с ним еще не сталкивался: Flux CD — это набор GitOps-контроллеров для Kubernetes. Он непрерывно следит за Git-репозиторием и приводит кластер к тому состоянию, которое там описано — ставит Helm-чарты, применяет Kustomize-оверлеи, подтягивает образы и секреты. Git становится единственным источником правды, а любое изменение инфраструктуры превращается в коммит: его можно отревьюить, откатить и проследить по истории.

Flux хорош модульностью. Это не монолит, а набор небольших контроллеров — source-controller, kustomize-controller, helm-controller и другие, — каждый решает свою узкую задачу и расширяется через CRD. Благодаря этому экосистема легко прирастает сторонними контроллерами. Один из них, Tofu Controller, и станет героем этой статьи.

В начале года я рассказывал, как мы запустили программу подготовки DevOps-инженеров для вузов. Сейчас в программе участвуют почти 40 вузов, через курс прошли тысячи студентов. Некоторые выпускники уже работают в моей команде. Успех? Успех. Кажется, процессы отлажены, материалы написаны, нужно только их поддерживать. Однако прошлый год преподнес сюрприз. Обычно мы запускаем три потока обучения в год, но тогда партнеры решили иначе: один поток, но с тройным количеством участников. Больше ста преподавателей вузов, которым нужно получить актуальные знания, обновленные материалы и доступ к стенду. А у нас немного устаревший курс и мало людей на сопровождение. В общем, есть место для подвига.

Задача звучит просто: взять чистый образ Linux, засунуть туда Docker, контейнерные образы, скрипты настройки — и сделать так, чтобы при первом запуске все заработало без единого обращения в сеть. Как консервная банка: открыл — и готово.

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

Запущенный на сервере OpenClaw решает большинство задач, которые пользователи ставят перед агентами. Для личного использования, параллельных запусков и несложной автоматизации его возможностей хватит с запасом. Одного VPS перестает хватать, когда приходят они: пиковые нагрузки.

В продакшене пиковые нагрузки у OpenClaw появляются раньше, чем можно ожидать. И когда это случается, варианта остается два: подбросить в печь больше вычислительных мощностей или пересмотреть архитектуру. Если второй вариант вам ближе, то эта статья для вас. Сегодня мы разберем контейнеризацию в Docker, отказоустойчивый деплой через Kubernetes, а также управление stateful-хранилищем, без которого стабильный запуск нескольких инстансов невозможен.

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

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

Какие именно ошибки деплоя в Kubernetes встречаются чаще всего и как их устранять? Будь то CrashLoopBackOff, зависшие поды, проблемы в синтаксисе YAML — рассмотрим 10 распространенных проблем и к каждой приложим простые и проверенные советы, как избежать их появления в будущем.

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

Один и тот же тренинг. Кому-то все понятно и доступно. Кто-то раздражен — материал кажется очевидным и бесполезным. А кто-то полностью потерян — слишком абстрактно, оторвано от практики. Материал один, результаты — разные.

В предыдущей статье я рассказал, как вместе с командой превратил небольшую группу инженеров в структурированное подразделение Professional Services (PS). В этой хочу рассказать, как мы создали PS 2.0 — объединили внедрение и техподдержку в цельную команду, добавили автоматизации и цифровых помощников, а также организовали процессы так, чтобы команда работала круглосуточно, но без ночных смен.

Если вам когда-либо приходилось расследовать загадочные проблемы с инфраструктурой, вы наверняка сталкивались с дрейфом. Так почему он доставляет столько неприятностей и как порождает для инженеров ситуации в духе «кто ел из моей миски»?

Привет, Хабр! На связи Денис Романов, директор департамента Professional Services компании «Базис». Яркое появление китайских языковых моделей заставило нас по-новому посмотреть на возможности нейросетей, и вот уже несколько месяцев мы активно внедряем их в рабочие процессы — от автоматизации рутинных задач до поддержки клиентов.

Привет, Хабр! Меня зовут Денис Романов, и я руковожу подразделением Professional Services, которое сейчас занимается внедрением и поддержкой продуктов «Базис».

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

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

Знаете, как обычно проходит первая встреча с сертификацией ФСТЭК? Примерно как встреча с медведем в лесу. Все знают, что он где-то есть, все слышали истории о том, как другие его видели, но пока не столкнешься сам — не поймешь масштаба. В какой-то момент нам стало понятно: либо научимся проходить сертификацию и последующие проверки красиво, либо увязнем в бесконечном марафоне.

Однажды мне стало интересно: а что будет, если отправить пакет с несуществующим транспортным протоколом? Не TCP, не UDP, не ICMP — вообще что-то выдуманное. Пропустит ли его ОС? Дойдет ли он хотя бы до сетевого интерфейса? Не зарежет ли его какой-нибудь промежуточный маршрутизатор? А вдруг он еще и быстрее обычного дойдет, потому что никто не знает, что с ним делать?

Ответа у меня не было. Так что я решил проверить.

Работать с YADRO мы начали еще несколько лет назад, главной задачей нашего сотрудничества было и остается обеспечение совместимости между СХД TATLIN и нашей платформой управления динамической инфраструктурой Basis Dynamix Enterprise. Наша платформа и раньше умела работать с различными СХД — Hitachi, Huawei и других. Однако где-то были реализованы не все возможности, где-то не хватало веб-интерфейса и приходилось работать через консоль, где-то страдало быстродействие. Тесное сотрудничество с YADRO позволяло подходить к решению этих проблем с обеих сторон, плюс, многие наши заказчики регулярно интересовались развитием поддержки TATLIN.UNIFIED в наших продуктах. И вот на этой неделе мы объявили о более глубокой интеграции между TATLIN.UNIFIED Gen 2 и Basis Dynamix Enterprise, включающей поддержку репликации и мгновенных снимков через интерфейс платформы. О чем и хотим рассказать подробнее.

Хабр, привет! Меня зовут Игорь Сомов, я работаю инженером по внедрению в компании «Базис». До этого почти 20 лет работал в ИТ — начинал монтажником, был эникеем на заводах, системным администратором в разных компаниях. Даже уходил из ИТ на какое-то время, но в итоге вернулся в профессию. В «Базис» пришел пару лет назад, в создающуюся команду внедрения, вместе с которой делал первые шаги в автоматизации разворачивания платформы Basis Dynamix. Сейчас выбранный нами подход выглядит немного наивным, но тогда это был существенный результат, который позволил нам создать базу для дальнейшей работы. О том, как это было, я и хочу рассказать.