3

WebTech

Личный кабинет

Проекты, коммерческие предложения, документы и отчёты — в одном месте.

Войти Зарегистрироваться Забыли пароль?

Полезное

Услуги Кейсы Блог Калькулятор стоимости Бесплатный аудит
contact@webtechretail.com Telegram
DevOps на аутсорсе

Инфраструктура и релизы под управлением инженеров, а не одного человека

Приходим в проекты, где продукт уже работает и приносит выручку: интернет-магазины, SaaS-платформы, личные кабинеты, внутренние системы с очередями и интеграциями. Инфраструктура в таких проектах выросла стихийно — сервер настроен руками, релиз делает один человек, о падении узнают из звонка клиента. Приводим это в инженерный вид: конвейер с откатом одной командой, окружения из кода, наблюдаемость и договорённости о надёжности.

  • Первый результат — за первые недели
    Конвейер и автоматический выкат появляются в первые две недели и сразу используются командой
  • Откат проектируем вместе с выкатом
    Предыдущий образ, предыдущая версия схемы, выключенный флаг — одной командой
  • Начинаем с измерений, а не с инструментов
    Считаем время релиза, число инцидентов и часы ручной работы — иначе инструменты не решают проблему
  • Отдаём работающий процесс, а не отчёт
    Runbook, дашборды, обученная команда: через месяц инфраструктуру можно развивать без нас
Обсудить инфраструктуру Оценить зрелость

Разбор инфраструктуры

Оставьте контакт — вернёмся с планом работ, сроками и ориентиром стоимости.

Бесплатный аудит и медиаплан — без обязательств.

  • Направлений

    6

  • До автовыката

    3–6 недель

Ответим в рабочее время. Для оценки достаточно рассказать, как сейчас устроен релиз и где живёт продакшен.

GitLab CI GitHub Actions self-hosted раннеры Docker Kubernetes Helm GitOps Terraform Ansible Prometheus Grafana Loki OpenTelemetry Nginx PostgreSQL MySQL Redis RabbitMQ blue-green выкат canary-релизы feature flags миграции expand/contract SLO и error budget дежурства 24/7 DORA-метрики blameless postmortem
Направления работ

Шесть направлений, из которых собирается инфраструктура

Можно взять одно направление, можно весь контур. У каждого — своя страница с составом работ, этапами и разбором частых вопросов; ниже — краткая выжимка из неё.

CI/CD и автоматизация релизов

Конвейеры GitLab CI и GitHub Actions: линтеры, тесты, сборка образа, blue-green и canary-выкат, миграции без простоя, откат одной командой.

Состав работ

  • Конвейер сборки и проверок
  • Артефакты и окружения
  • Стратегии безопасного выката
  • Передача и эксплуатация
Полный разбор направления

Что это даёт

  • 5–10 мин

    от коммита до результата проверок

  • 1 команда

    на откат к предыдущей версии

  • DORA

    метрики, по которым видно прогресс

  • 0

    ручных шагов при выкате

Микросервисная архитектура

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

Состав работ

  • Границы и декомпозиция
  • Выделение сервисов из монолита
  • Интеграция и согласованность
  • Контракты и наблюдаемость
Полный разбор направления

Что это даёт

  • DDD

    границы по бизнес-возможностям

  • strangler

    постепенное выделение вместо переписи

  • at-least-once

    идемпотентность и outbox

  • контракты

    OpenAPI и проверка совместимости

Контейнеры и Kubernetes

Переносим приложение в Docker, разворачиваем кластер Kubernetes, настраиваем Helm и GitOps, ресурсы и автомасштабирование, бэкапы stateful-сервисов и выкат без простоя.

Состав работ

  • Контейнеризация приложения
  • Кластер и его безопасность
  • Декларативный выкат и GitOps
  • Stateful-сервисы и данные
Полный разбор направления

Что это даёт

  • multi-stage

    образы на минимальной базе

  • GitOps

    состояние кластера описано в git

  • HPA

    масштабирование по нагрузке

  • PITR

    восстановление данных на момент времени

Инфраструктура как код

Описываем серверы, сети, балансировщики и базы в Terraform и Ansible: воспроизводимые окружения вместо ручных настроек, ревью изменений, детектирование дрейфа, управление секретами и проверенный план восстановления.

Состав работ

  • Ресурсы в Terraform
  • Конфигурация серверов в Ansible
  • Секреты и доступы
  • Дрейф, образы и восстановление
Полный разбор направления

Что это даёт

  • plan

    изменения видны до применения

  • ревью

    инфраструктура меняется через pull request

  • дрейф

    расхождения ловятся автоматически

  • DR

    восстановление проверено учениями

Мониторинг и логирование

Метрики Prometheus и дашборды Grafana, централизованные логи и трейсинг OpenTelemetry, осмысленные алерты без шума, runbook на каждый алерт и политика хранения логов.

Состав работ

  • Метрики и дашборды
  • Централизованные логи
  • Трейсинг и профилирование
  • Алерты и дежурство
Полный разбор направления

Что это даёт

  • Prometheus

    метрики приложения и инфраструктуры

  • Loki

    логи с поиском по correlation id

  • OTel

    трейсы через сервисы и очереди

  • runbook

    порядок действий на каждый алерт

SRE и надёжность

SLI и SLO для ключевых сценариев, error budget, ротация дежурств и эскалация, blameless postmortem с планом работ и нагрузочные учения перед пиками.

Состав работ

  • SLI, SLO и бюджет ошибок
  • Дежурства и работа с инцидентами
  • Учения и проверка отказоустойчивости
  • Ёмкость и производительность
Полный разбор направления

Что это даёт

  • 3–5

    ключевых сценариев вместо сотни метрик

  • 28 дней

    скользящее окно расчёта SLO

  • error budget

    общий язык у продукта и эксплуатации

  • blameless

    разбор причин, а не поиск виноватых

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

С чем приходят

Как выглядит деплой до автоматизации

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

Релиз как спецоперация

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

Тесты не гоняются на каждый коммит

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

Миграции применяются руками

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

Окружений нет, проверяем на продакшене

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

Секреты и конфиги копируются по SSH

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

Откат означает восстановление из бэкапа

Если новая версия ломает сценарий оплаты, команда тратит один-три часа на разбор и восстановление вместо переключения на предыдущий релиз за минуту.

Что меняется

Четыре метрики DORA: чем измеряем результат

Отраслевой стандарт измерения — четыре показателя DORA. Мы замеряем их до начала работ и после каждого этапа, поэтому разговор про «стало лучше» опирается на числа, а не на ощущения.

Частота развёртывания

Обычно до

релиз раз в две недели, ночью

После автоматизации

несколько релизов в неделю

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

Время от коммита до продакшена

Обычно до

около месяца в очереди задач

После автоматизации

часы: конвейер и окружения

Отражает длину очереди между решением и результатом.

Доля неудачных изменений

Обычно до

регресс находят пользователи

После автоматизации

регресс ловит конвейер до выката

Говорит о качестве проверок внутри конвейера.

Время восстановления

Обычно до

часы на разбор и восстановление из бэкапа

После автоматизации

минуты: переключение на предыдущую версию

Показывает, насколько хорошо продуман откат.

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

Самопроверка

Отметьте, что уже сделано, — и увидите, с чего начинать

Двенадцать практик, по которым видно состояние инфраструктуры. Это не тест и не аттестация: отметки никуда не отправляются и считаются прямо в браузере.

Выполнено практик

0 / 12

Инфраструктура держится на людях

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

Начать с CI/CD

Основы есть, но много ручной работы

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

Инфраструктура как код

Процессы работают, но без цифр

Релизы и мониторинг в порядке, но решения принимаются без общих показателей: непонятно, где деградирует и когда нужны мощности. Логичный шаг — SLI/SLO и работа с инцидентами.

SRE и надёжность

Инженерная база выстроена

Практики автоматизации, наблюдаемости и надёжности работают вместе. Дальше имеет смысл заниматься ёмкостью и учениями: проверять, что система выдержит сезонный пик, и пересматривать SLO по фактам.

Учения и ёмкость
Разобрать мою ситуацию

Уровни — ориентир для разговора, а не оценка команды: мы регулярно видим проекты, где половина практик держится на одном инженере, и это не вина команды, а следствие роста.

Как идёт работа

Четыре этапа: от аудита релиза до передачи команде

Работаем итерациями: первая версия конвейера появляется в первые две недели и сразу используется, а не собирается «до идеала» в стороне. Ниже — сроки для проекта на Laravel с одним-двумя окружениями; системы из нескольких сервисов занимают от двух месяцев.

  1. 01 3–5 дней

    Аудит процесса релиза

    Отчёт: время выката, частота сбоев, узкие места, план работ

  2. 02 1–2 недели

    Сборка конвейера

    Конвейер на каждый merge request, кэш зависимостей, параллельные тесты

  3. 03 1–2 недели

    Окружения и выкат

    Стенд из кода, выбранная стратегия выката, откат одной командой

  4. 04 1–2 недели

    Обкатка и передача

    Несколько реальных релизов вместе с командой, runbook, обучение

Итого до полностью автоматического выката — от трёх до шести недель.

Объём фиксируем после аудита: он же показывает, что в вашем случае даст эффект первым, а что можно отложить без риска.

Стек

Инструменты, на которых это собирается

Выбираем из распространённых решений с большим рынком специалистов: инфраструктуру должно быть кому поддерживать, кроме автора настройки. Если у вас уже есть стек, работаем в нём.

CI/CD и релизы

  • GitLab CI
  • GitHub Actions
  • self-hosted раннеры
  • Docker registry
  • feature flags
  • blue-green и canary

Контейнеры и оркестрация

  • Docker
  • Kubernetes
  • Helm
  • GitOps
  • HPA и автомасштабирование

Инфраструктура как код

  • Terraform
  • Ansible
  • ревью через pull request
  • детектирование дрейфа

Наблюдаемость

  • Prometheus
  • Grafana
  • Loki
  • OpenTelemetry
  • алерты и runbook

Надёжность

  • SLI и SLO
  • error budget
  • ротация дежурств
  • blameless postmortem
  • учения

Данные и окружения

  • PostgreSQL
  • MySQL
  • Redis
  • RabbitMQ
  • PITR и проверка восстановления
  • Nginx

Площадки

  • Yandex Cloud
  • VK Cloud
  • Selectel
  • ваши собственные серверы
  • закрытый контур без внешних сервисов
Сопровождение

Дальше — сопровождение с дежурством и SLA

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

Базовый

от 45 000 ₽/мес

Реакция до 4 часов

До 5 серверов, рабочие часы

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

  • До 5 серверов или сервисов
  • Мониторинг и алерты
  • Резервное копирование
  • Обновления безопасности
  • Реакция в рабочие часы
  • Отчёт раз в месяц
Обсудить сопровождение
Чаще всего берут

Бизнес

от 95 000 ₽/мес

Реакция до 30 минут

До 20 серверов, 24/7

Для продакшена с постоянным трафиком: круглосуточное дежурство, инфраструктура как код, оптимизация расходов.

  • До 20 серверов или сервисов
  • Дежурство 24/7
  • Инфраструктура как код
  • Проверка восстановления ежеквартально
  • Оптимизация расходов на облако
  • Ежемесячный отчёт и план работ
Обсудить сопровождение

Критичный

от 180 000 ₽/мес

Реакция до 15 минут

Кластеры, высокие требования к доступности

Для систем, где простой стоит дорого: отказоустойчивые конфигурации, выделенный инженер, регламенты восстановления.

  • Объём без ограничений
  • Реакция до 15 минут, 24/7
  • Выделенный инженер и план развития
  • Отказоустойчивые конфигурации
  • Учения по восстановлению
  • Квартальный разбор архитектуры
Обсудить сопровождение

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

Услуги сопровождения

Дежурство

Время реакции по приоритетам

Приоритет определяем вместе на этапе регламента. Ниже — типовые условия; в договоре они фиксируются под ваш режим работы.

Приоритеты обращений, время реакции и восстановления
Приоритет Что произошло Реакция Восстановление
P1 — Критичный Сервис недоступен или недоступен частично, затрагивает всех пользователей 15 минут до 4 часов
P2 — Высокий Заметная деградация: ошибки у части пользователей, падение производительности 30 минут до 8 часов
P3 — Средний Проблема не блокирует работу, есть обходной путь 4 часа до 3 рабочих дней
P4 — Низкий Вопросы, консультации, плановые изменения 1 рабочий день по плану работ

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

Форматы

Как с нами можно работать

Формат выбирается по задаче: от одного направления до полного сопровождения. Можно начать с аудита и решить по фактам.

Аудит и план

Разбираем текущее состояние: процесс релиза, окружения, секреты, мониторинг, восстановление. Замеряем DORA-метрики и отдаём план работ с приоритетами.

Подходит: Когда непонятно, с чего начинать и что действительно болит

Проект по направлению

Берём одно направление целиком: CI/CD, контейнеры и Kubernetes, инфраструктура как код, наблюдаемость или SRE. Фиксируем состав, этапы и критерии приёмки.

Подходит: Когда задача уже сформулирована и нужен результат к дате

Сопровождение с дежурством

Мониторинг, обновления, бэкапы с проверкой восстановления, реагирование по SLA и плановое развитие инфраструктуры по фиксированной месячной стоимости.

Подходит: Когда продакшен работает и его нужно удерживать в форме

Выделенный инженер

Инженер работает в вашей команде и в вашем процессе: задачи в общем трекере, участие в планировании, передача знаний вашим разработчикам.

Подходит: Когда нужны руки внутри команды, но нанимать в штат рано

Когда DevOps-услуги, скорее всего, не нужны

  • Продукт ещё не в продакшене и не приносит выручку — сначала важнее продукт, а не пайплайн
  • Один сервер, редкие релизы и один разработчик: ручной выкат дешевле автоматизации
  • В команде уже есть инженер, который закрывает инфраструктуру, и он не перегружен
  • Задача решается настройкой существующего конвейера — это консультация, а не проект

Принципы, по которым устроена работа

Частые вопросы о DevOps-услугах

Зачем отдавать DevOps на аутсорс, если можно нанять инженера в штат?

Это не взаимоисключающие варианты, и мы честно говорим, когда выгоднее нанять. Штатный инженер оправдан, если инфраструктура — постоянная большая работа и вам нужен человек внутри команды на годы. Внешняя команда выгодна в трёх случаях: работа конечна (настроить конвейер, переехать в контейнеры, внедрить IaC), нужны разные компетенции по очереди (сеть, Kubernetes, базы, безопасность), или нужен круглосуточный режим реакции, который одному человеку не по силам. Часто получается комбинация: мы делаем проект и передаём его вашему инженеру вместе с runbook и обучением.

Сколько времени занимает внедрение CI/CD?

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

Сколько стоит сопровождение инфраструктуры?

Сопровождение считается фиксированной месячной стоимостью: базовый пакет — от 45 000 ₽ в месяц для систем до пяти серверов с реакцией в рабочие часы, «Бизнес» — от 95 000 ₽ с дежурством 24/7 и реакцией до 30 минут, «Критичный» — от 180 000 ₽ с реакцией до 15 минут, выделенным инженером и учениями по восстановлению. Аудит перед началом услуги оплачивается отдельно и занимает 1–2 недели. Задачи вне пакета — по согласованной ставке.

Обязательно ли переходить на Docker и Kubernetes?

Нет, и мы не предлагаем это «по умолчанию». Для проекта на классическом сервере конвейер может собирать артефакт и раскладывать файлы с переключением симлинка — это уже даёт воспроизводимость и мгновенный откат без переезда на контейнеры. Docker нужен там, где важно одинаковое окружение на всех машинах, горизонтальное масштабирование и предсказуемая сборка зависимостей. Kubernetes оправдан при нескольких сервисах и переменной нагрузке; для одного приложения он чаще добавляет сложности, чем решает задач.

Что делать, если проект живёт на shared-хостинге?

При наличии SSH и доступа к git можно построить минимальный, но честный конвейер: тесты и сборка на отдельном раннере, выкат по SSH с переключением симлинка и возвратом на предыдущую версию. Полноценные окружения, канареечный выкат и горизонтальное масштабирование потребуют VPS или контейнерной платформы — это отдельный этап, который имеет смысл планировать после базовой автоматизации.

Наши данные и код не должны покидать наш контур. Это возможно?

Да. Разворачиваем GitLab Runner или self-hosted раннер GitHub Actions на вашей инфраструктуре и настраиваем кэш зависимостей локально — исходный код, артефакты и секреты не покидают периметр. Секреты хранятся в управляемом хранилище, а не в файлах на сервере, и ротируются по регламенту. Дополнительный плюс собственных раннеров — нет ограничений на минуты сборки и очередей облачных сервисов.

Мы уже работаем с другим подрядчиком по разработке. Вы сработаетесь?

Да, это обычная ситуация: инфраструктурой занимаемся мы, продукт развивает ваша команда или другой подрядчик. Всё, что мы делаем, лежит в вашем репозитории: конвейер, описания инфраструктуры, дашборды и runbook. Разработчикам не нужно изучать закрытую систему — им нужно знать две команды: как посмотреть состояние выката и как откатиться. Это мы и проводим на этапе обучения.

Насколько быстро вы реагируете на аварию?

По регламенту SLA приоритеты выглядят так: P1 — сервис недоступен полностью или частично для всех пользователей, реакция 15 минут, восстановление до 4 часов; P2 — заметная деградация для части пользователей, реакция 30 минут; P3 — проблема не блокирует работу и есть обходной путь, реакция 4 часа; P4 — вопросы и плановые изменения, реакция 1 рабочий день. Время реакции — это начало работы над инцидентом. После каждого P1 готовим разбор: что произошло, почему и что меняем, чтобы не повторилось.

Что именно вы передаёте в конце проекта?

Работающий процесс, а не отчёт. В репозитории — конвейер, описания инфраструктуры и конфигурации; в системе мониторинга — дашборды и алерты; в документации — runbook «как выпустить и как откатить» для нового инженера, регламент восстановления и метрики DORA по этапам. Плюс обучение команды: разбор пайплайна, работа с секретами, разбор инцидентов. Через месяц вы можете развивать инфраструктуру без нас — обычно так и происходит.

Мы небольшая команда. Есть ли смысл начинать?

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

Коротко о главном

Что такое DevOps-услуги на практике

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

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

Почему начинают с CI/CD, а не с Kubernetes

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

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

Чем измеряется результат

Отраслевой стандарт — четыре метрики DORA: частота развёртывания, время от коммита до продакшена, доля неудачных изменений и время восстановления. Они хороши тем, что не зависят от размера компании и технологий: и стартап, и крупная система измеряются одинаково.

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

Технические детали каждого направления — состав работ, этапы и разбор частых вопросов — на страницах CI/CD, Kubernetes, инфраструктуры как кода, мониторинга и SRE.

Разберём вашу инфраструктуру

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

Телефон
+7 (495) 368-39-51
Что будет после заявки
Свяжемся, разберём процесс релиза и текущее состояние окружений, после чего пришлём план работ с приоритетами, сроками и ориентиром стоимости. Если задача решается консультацией — скажем об этом прямо.
Если в команде есть инженер
Работаем вместе с ним: делаем проект по одному направлению и передаём его вашей команде вместе с runbook и обучением.

Полезное рядом: управляемые услуги, разработка ERP, все услуги разработки, контакты.

Заявка на разбор инфраструктуры

Опишите, как устроен релиз, где живёт продакшен и что уже автоматизировано, — вернёмся с планом работ, сроками и ориентиром стоимости.

Не передаём данные третьим лицам и не звоним с рекламой.

Обсудить инфраструктуру