— Дмитрий, расскажи, как ты попал в МойСклад?
Очень традиционно: в конце 2024 года разместил резюме на hh.ru. На предыдущем месте вырос с системного архитектора до руководителя DevOps. За это время закрыл большой проект по выбору облачного провайдера для всей группы компаний и запустил перестройку внутренней инфраструктуры. После этого решил, что пришло время двигаться дальше.
Примерно пару раз в месяц просматривал предложения. И однажды увидел вакансию от МоегоСклада. Случился полный мэтч: стек, задачи, тип компании. Очень хотелось попробовать силы в большом SaaS-проекте.
В МоемСкладе интересный подход к собеседованиям: меня собеседовали коллеги из команды, которой предстояло руководить. Это волнительно — важно не только подтвердить компетенции, но и сойтись с людьми по коммуникации, по духу. К счастью, эта часть прошла отлично: сразу случился живой обмен опытом.
Финальный этап — интервью с техническим директором. Обсудили инфраструктуру, ее устройство, а главное — будущие задачи. Это оказалось самым ценным — еще на собеседовании стало понятно, что меня ждет, и онбординг пролетел незаметно, потому что я сразу включился в работу.
— Как устроен отдел IT-инфраструктуры в МоемСкладе?
Инфраструктурный отдел разделен на две команды с разными зонами ответственности. Первая линия — это системные администраторы и инженеры. Они занимаются раскаткой релизов (используя централизованную систему деплоя), мониторингом, поддержкой пользователей, разбором и маршрутизацией тикетов и эскалацией проблем. По сути, это ребята, которые первыми принимают удар и либо решают задачу сами, либо передают ее дальше.
Вторая линия — DevOps-инженеры. Они проектируют и разворачивают сервисы, занимаются обновлениями, миграциями и обеспечением отказоустойчивости, следят за соблюдением SLA. На них же автоматизация деплоя, патч-менеджмент и исследование новых продуктов. Причем работа с новыми инструментами у нас всегда идет в два этапа: сначала тестирование и пилот, а если решение показало себя — масштабирование на всю инфраструктуру.
Отдельно в команде DevOps выделен DevSecOps-специалист, который отвечает за информационную безопасность — регулярное проведение пентестов, харденинг нашей инфраструктуры и программу Bug Bounty.
Работаем по терциям — так мы называем четырехмесячные планы. Сейчас мы все больше смещаемся в сторону продуктового подхода: инфраструктура и ее сервисы — это набор внутренних продуктов. Наши пользователи — разработчики, продуктовые команды, техподдержка и мы сами. У каждого продукта есть свои задачи, план развития и SLA.
Еще мы контролируем расходы на серверный парк: анализируем нагрузку на наши сервисы, прогнозируем ее рост, планируем апгрейды.
— Расскажи про самые интересные проекты, которые делала твоя команда.
— Один из самых интересных проектов — развертывание кластеров OpenShift (OKD) с с выделенными хранилищами данных на базе «железных» СХД с NVMe. OKD — это, по сути, прокачанный Kubernetes от Red Hat. Он умеет работать и с контейнерами, и с виртуальными машинами, плюс внутри уже есть куча готовых инструментов: операторы, CNI и прочие полезные в эксплуатации надстройки.
Этот проект позволил нам сделать то, к чему давно шли, — мигрировать с Proxmox на OpenShift и перейти от классической виртуализации к платформенному подходу: контейнеры, VM и инфраструктурные сервисы управляются через единый Control Plane.
По финансовой части переход на новое решение позволил даже немного сэкономить — во время миграции подрезали избыточную аллокацию ресурсов и консолидировали ряд сервисов.
Еще один интересный проект — внедрение мониторинга сети.
Инфраструктура МоегоСклада — это сотни выделенных серверов («дедиков»), арендуемых в нескольких дата-центрах. На серверах расположены кластеры Kubernetes (OKD), реляционные и аналитические базы данных (PostgreSQL, ClickHouse), а также десятки внутренних сервисов. Сеть между этими серверами устроена гибридно: провайдеры отвечают за связность между регионами, а все, что выше третьего уровня, — наша зона ответственности. Это шлюзы, VPN-туннели, балансировщики и точки доступа для сотрудников.
И долгое время у нас была проблема: мы не видели, что именно происходит в этой сети. Кто к кому ходит, сколько трафика, какие протоколы — просто слепая зона.
Поэтому последние полгода внедряли ntopng — инструмент сетевой наблюдаемости, который собирает информацию о трафике с разных точек сети. Он показывает, кто к кому ходит, сколько данных передает, разбирает протоколы, резолвит хосты через наш DNS, а публичные адреса привязывает к автономным системам. Вся эта аналитика доступна в интерфейсе — и в реальном времени, и в ретроспективе (данные храним в ClickHouse).
На основе этих данных настроили алерты на аномалии. Теперь сразу видно, если кто-то неожиданно забил канал, если на сервере завелся подозрительный протокол или какой-то сотрудник решил скачать торренты через рабочий VPN.
— А были за период твоей работы какие-то критические ситуации?
— Не без этого. Одна из них — инцидент с охлаждением у одного из наших провайдеров. Нас заранее предупредили, что в дата-центре растет температура и есть риск перегрева серверов. А перегрев ведет к троттлингу — процессоры начинают пропускать такты, чтобы не сгореть, и это напрямую влияет на скорость работы сервисов для пользователей.
Мы быстро подготовились: проверили, что готовы переключиться на резервные серверы в другой геозоне, куда у нас настроена репликация. И заодно вывели на дашборды метрики по температуре и троттлингу со всех хостов, чтобы в будущем видеть такие проблемы заранее. Теперь у нас алерты срабатывают не просто на критические значения, а на устойчивый рост температуры — это помогает поймать проблему до того, как она ударит по пользователям.
Второй случай — когда на одном из серверов начала сбоить память. Внешне выглядело странно: нагрузка на виртуалки обычная, а процессор вел себя так, будто ему плохо. На тех же задачах, где пару часов назад было 30% загрузки, вдруг стало под 100%. На этой ноде крутился корпоративный VPN — мы сразу переключились на резервный хост. А вот с самим сервером еще несколько часов не могли понять, в чем дело. Пока не залезли в логи ядра и не увидели там ошибки по памяти и исполнению прерываний.
Этот случай лишний раз подтвердил: когда у тебя парк серверов измеряется сотнями, отказы железа становятся не исключением, а данностью. К ним нужно быть готовым всегда.
— Как ты подбираешь людей в команду? На что смотришь в первую очередь?
— Я всегда ищу не просто исполнителя, а думающего инженера.
Во-первых, смотрю на базу. Без нее никуда: операционные системы, сети, работа в командной строке с типовыми тулами, системное мышление. Это фундамент, на котором все держится.
Во-вторых, важна осознанность. Можно год кнопки нажимать и не понимать, зачем. А можно сделать один раз, но вдумчиво. Мне важно не просто услышать, что человек делал, а понять его ход мыслей. Если он объясняет, почему выбрал именно такое решение, а не другое — это хороший знак.
Третье качество — умение видеть последствия. В инфраструктуре любое действие может отозваться где-то в другом месте. Важно, чтобы человек прокручивал в голове: «А что будет, если это упадет? А если нагрузка вырастет в десять раз?»
Коммуникация — отдельная тема. DevOps — это не про «я в домике». У нас всегда есть заказчики: разработчики, техподдержка, смежные команды. Нужно уметь договариваться, слышать других и объяснять сложное простыми словами.
Еще важна документация. Не для галочки, а чтобы через полгода можно было зайти, прочитать и понять, что к чему, даже если автор уже забыл детали.
И последнее — вовлеченность. Мне всегда интересно, чем человек горит вне рабочих задач. Собирает дома сервер, играет с железом, пишет какие-то тулы для души, следит за новинками. Это показывает, что ему реально интересно то, чем он занимается.
— Как у вас проходит адаптация новых сотрудников?
— У нас выстроена довольно четкая система. За каждым новичком закрепляется ментор из числа действующих инженеров. Он сопровождает человека на всем пути знакомства с инфраструктурой.
В первую неделю мы проводим несколько встреч-погружений, где показываем, что у нас где лежит, как устроены сервисы, какие есть нюансы. Но доступа к продакшену в испытательный срок у сотрудника нет — это принципиальная позиция. К критическим сервисам, релизам и бэкапам мы пускаем только после того, как человек прошел испытательный срок и подтвердил, что он адекватно оценивает риски.
Но это не значит, что новичку нечего делать. У нас есть куча окружений, не связанных с продакшеном: тестовые стенды, стейджинг, сервисы для разработки. Туда доступ даем достаточно быстро, и человек сразу может включиться в работу.
При этом мы стараемся не давать синтетических задачек «для галочки». Сразу привлекаем к реальным делам, которые приносят пользу команде. Чтобы человек видел: то, что он делает, реально нужно.
И еще важный момент. Несмотря на то, что доступ к продакшену закрыт, мы уже в первый квартал привлекаем сотрудника к присутствию на релизах. Он может посидеть рядом с инженером, который выкатывает обновления, посмотреть, как это происходит живьем, задать вопросы. Это прописано прямо в чек-листе адаптации — чтобы человек видел процесс изнутри, даже если пока не может в него руками вмешиваться.
— А можно ли вырасти из системного администратора в девопса внутри МоегоСклада?
— Да, такое происходит довольно часто. Обычно путь выглядит так: стартуешь как системный администратор, дальше прокачиваешься до системного инженера, и уже потом становишься DevOps-инженером.
Стартовать можно с первой линии — как раз там работают сисадмины и инженеры. А для перехода в DevOps нужно прокачать несколько вещей.
Первое — end-to-end развертывание. Человек должен уметь поднять сервис с нуля: прописать сценарии деплоя, настроить мониторинг, организовать сбор логов.
Второе — автоматизация рутины. Если сисадмин любит вручную настраивать серверы и боится писать скрипты — в DevOps ему будет тяжело. Нужно, чтобы любая повторяющаяся задача вызывала желание ее автоматизировать и забыть.
Третье — хорошее знание сетей. Это прямо база, на которой все строится.
И четвертое — понимание отказоустойчивых систем. Тут без классики не обойтись — та самая «книжка с кабанчиком» («Высоконагруженные приложения» Мартина Клеппмана). Если человек ее читал и усвоил основные принципы — это большой плюс.
— Что самое сложное в твоей работе?
— Первое и главное — ответственность. От того, как работает инфраструктура, зависит доступность всех сервисов МоегоСклада и работа всей разработки. Если что-то падает, счет иногда идет на минуты. По ощущениям это очень похоже на работу в отделении скорой помощи: нужно реагировать мгновенно, четко, и главное — не навредить, пока чинишь.
Второе — подбор людей. Это, пожалуй, самая тонкая история. У нас в команде сложилась очень классная атмосфера: взаимопомощь, обмен компетенциями, поддержка друг друга — и между линиями, и внутри команд. Когда берешь нового человека, всегда переживаешь, вольется ли он в коллектив. Потому что технике можно научить, а человеческий фактор — это лотерея.
Третье — постоянное развитие. В инфраструктуре нельзя остановиться. Появляются новые инструменты, меняются подходы, растут нагрузки. Нужно все время учиться, прокачивать насмотренность, понимать, что происходит на рынке, что можно забрать себе, а что не взлетит.
— Чем увлекаешься в свободное время?
— Начну с того, что я заядлый автомобилист. Раньше серьезно занимался тюнингом, а сейчас переключился на картинг и, конечно, симрейсинг — это такие гонки в симуляторе (я предпочитаю iRacing) с набором специализированных железяк.
Люблю автопутешествия. Как-то проехали на машине от Москвы до Праги. За две недели посмотрели Вену, Берлин, Будапешт и Братиславу. На Кипре объездил все вдоль и поперек, много ездил по Черногории и Армении, даже в Таиланде удалось поездить самостоятельно. Для меня автомобиль — это способ увидеть страну изнутри: уехать с туристических маршрутов, заехать в обычный придорожный магазин, в мелкую лавочку или на рынок. Отели не люблю, формат Airbnb с его возможностью жить «как местный» мне гораздо ближе.
Не так давно стал молодым отцом — теперь это главное увлечение на долгие годы.
Ну и куда без айтишного. Иногда для души что-то кручу дома — от банальных апгрейдов домашней сети до экспериментов со списанными энтерпрайз железками и IoT. В 2025-м подсел на локальный запуск опенсорсных LLM — скорее как технический эксперимент для себя, чем рабочая задача. Такие занятия — это уже чистое удовольствие.
