CI/CD
Сборка, проверки, публикация и откат выполняются по воспроизводимому пайплайну. Для публичного сайта это подготовка артефакта и публикация, для серверного приложения дополнительно учитываются образ, миграции и порядок отката.
Услуги
Инфраструктура, на которой продукт можно выпускать спокойно
Настраиваем сборки, окружения и наблюдаемость так, чтобы публикация, откат и диагностика не зависели от одного специалиста. Состав инфраструктуры определяем по типу приложения, нагрузке и требованиям к эксплуатации.
Кому подходит
- Команды, у которых сборка и рабочее окружение зависят от компьютера одного инженера
- Продукты в эксплуатации без централизованных логов, резервных копий и процедуры отката
- Компании, которым нужно разделить среды разработки, тестирования и эксплуатации
Что делаем
Окружения
Для сред разработки, тестирования и эксплуатации фиксируем зависимости, секреты, флаги и права на публикацию. Ключевые сценарии проверяются в тестовой среде до выпуска в рабочую.
Секреты и доступы
Ключи хранятся вне репозитория и рабочих чатов. Разделяем права на публикацию, доступ к базе и просмотр журналов. Порядок выдачи и ротации доступов фиксируется документально.
Наблюдаемость
Метрики, логи, при необходимости трейсы. Алерты по симптому пользователя: форма не уходит, 5xx, очередь растёт. «Диск 90%» само по себе мало говорит, если никто не смотрит, жив ли сценарий входа.
Инфраструктура как код
Конфигурация окружения хранится в репозитории и документации. Инфраструктура как код полезна для нескольких повторяемых окружений; для одного сервера может быть достаточно описанного образа, systemd и проверенного резервного копирования.
Бэкапы и инцидент
Настраиваем копирование данных, проверку восстановления и краткую инструкцию по инциденту: контакты, порядок отката и расположение журналов. Возможность восстановления подтверждаем тестовой процедурой.
Состав работ
- Инвентаризация: как собирается сейчас, кто выкладывает, где секреты, что падает чаще
- Пайплайн на один сервис или на статическую витрину до предсказуемого релиза
- Окружения и правила продвижения изменений от тестовой среды к рабочей
- Секреты, доступы, HTTPS, базовый файрвол
- Бэкап и одна проверенная процедура восстановления
- Минимальные оповещения и каналы их доставки
- Инструкция по инцидентам и схема владения компонентами после завершения работ
Как связаны части решения
Базовый технический контур направления. Конкретные границы, интеграции и способ размещения фиксируем после разбора задачи.
01Изменение
- Git
- Проверки
- Сборка
02Поставка
- Артефакт
- Окружения
- Секреты
03Эксплуатация
- Мониторинг
- Бэкап
- Откат
Стек
GitHub Actions / GitLab CIDockerTerraformNginxLinuxPrometheusGrafanaSentry
Этапы
01
Инвентаризация
1–2 недели
Фиксируем текущий процесс сборки и публикации, расположение секретов, владельцев доступов и известные инциденты.
Приёмка: Схема текущей инфраструктуры и список рисков первого этапа.
02
Минимальный пайплайн
2–4 недели
Один сервис или витрина до предсказуемого релиза и отката. Затем копируем подход, а не проектируем «платформу на всё».
Приёмка: Выкладка с ветки повторяется другим человеком по инструкции.
03
Наблюдаемость и резервные копии
1–2 недели
Алерты, права, копия базы, проба восстановления, куда писать при падении.
Приёмка: Восстановление из резервной копии проверено, тестовое оповещение получено.
04
Документация и доступы
несколько дней
Передаём схемы, инструкции по инцидентам и доступы. Конфигурация инфраструктуры зафиксирована в документации и репозитории.
Приёмка: Заказчик может выложить и откатиться без нас по регламенту.
Нормы и ограничения
DORA как рамка зрелости
DORA использует показатели частоты развёртывания, времени прохождения изменения, доли неуспешных изменений и времени восстановления. Применяем их как диагностическую рамку, если для проекта доступны исходные данные.
Сначала пайплайн, потом оркестратор
Оркестратор рассматриваем при достаточном количестве сервисов и эксплуатационных требований. Для небольшого контура может быть достаточно CI, контейнеров и управляемого серверного окружения.
Секреты вне git
Утечка .env из репозитория это типовой инцидент, не гипотеза. Ключи в менеджере секретов или в переменных окружения хоста, ротация после смены людей.
Наблюдаемость по сценарию
Лог без контекста запроса и метрика «сервер жив» не заменяют сигнал «форма дошла». Для сайта достаточно доступности и ошибок доставки письма. Для кабинета нужны ещё очередь и ошибки API.
Сроки
Инвентаризация, пайплайн, окружения и базовый мониторинг для одного-двух сервисов обычно занимают 3–8 недель при наличии доступов и документации. Состояние существующей системы может изменить оценку.
Срок растёт, если:
- Нет репозитория, рабочая версия собирается с локального компьютера
- База данных без резервной копии и описанной схемы восстановления
- Несколько команд кладут на один хост без границ
- Требование «сразу Kubernetes и service mesh» без нагрузки, которая это окупает
Не входит
- Круглосуточный NOC и дежурство 24/7 без отдельного договора
- Сертификация облака и формальный аудит ИБ в стандартном этапе
- Переезд монолита «на микросервисы» как цель сама по себе
- Сопровождение хостинга без доступа к панели управления и DNS
Результат
Результат: воспроизводимая публикация, описанные окружения и согласованный набор сигналов о работе системы. Инфраструктура и доступы принадлежат заказчику. Сопровождение фиксируется отдельным регламентом.
Вопросы направления
Когда нужен Kubernetes?+
Решение зависит от числа сервисов, требований к отказоустойчивости, масштабированию и компетенций команды. Для небольшого контура часто достаточно CI, контейнеров и управляемого серверного окружения.
Работаете ли с виртуальным хостингом?+
Да, если требования публичного сайта совместимы с возможностями площадки. Кабинеты, фоновые задачи и очереди обычно размещаются в отдельном серверном или облачном окружении.
Можно ли оставить сопровождение на вас?+
Да, по ежемесячному регламенту: обновления, оповещения, небольшие изменения и реакция в согласованные часы. Круглосуточное дежурство и расширенный состав работ оцениваются отдельно.
Что такое DORA и зачем она вам?+
Это показатели поставки программного обеспечения. Они помогают определить, что требует улучшения: частота выпусков, время прохождения изменения, доля неуспешных изменений или время восстановления.
Какой объём работ по безопасности входит?+
В базовый контур могут входить управление секретами и доступами, HTTPS, резервное копирование и обновления. Тестирование на проникновение, программы поиска уязвимостей и сертификация выполняются отдельными специалистами.
Что делать, если рабочая инфраструктура находится в аккаунте подрядчика?+
Сначала размещаем доступы, DNS, секреты и базу данных в аккаунтах заказчика. После этого настраиваем пайплайн и регламент эксплуатации.
Следующий шаг
Обсудить задачу
Опишите задачу, срок и ограничения. Ответим в рабочий день: берёмся ли и каким будет первый этап.