Первые результаты за 2 недели: внедрение спринтами

Разговор о переходе на DevOps-аутсорсинг часто заходит в тупик на одном и том же месте. Клиент спрашивает: «Сколько времени займёт, пока мы увидим хоть что-то?» Подразумевается тревога о другом: «Мы заплатим за полгода работы, а в процессе ничего не изменится, и мы не поймём, работает это или нет».

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

Как выглядит первый спринт

Онбординг начинается с обследования. Это не формальность: за 3–5 рабочих дней мы проходим инфраструктуру вдоль и поперёк, смотрим на реальное состояние, собираем карту сервисов и зависимостей. Параллельно разговариваем с командой: кто что обслуживает, где самые болезненные точки, какие инциденты повторяются.

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

Это первая точка принятия решения. Клиент видит картину до того, как начинается основная работа, и может скорректировать приоритеты: возможно, CI/CD важнее, чем казалось, или наоборот — первый спринт лучше потратить на мониторинг критичного сервиса, который уже шатается.

После согласования плана развёртывание сопровождения занимает 1–2 недели. Именно этот срок мы называем, когда говорим о «первых результатах».

Что клиент видит к концу второй недели

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

Дашборды подняты, алертинг настроен, дежурная смена подключена. Реакция на инцидент — от 15 минут, 24/7.

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

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

Клиент получает список этих точек с метриками и предложением по каждой: что делать дальше, в каком приоритете, с какими трудозатратами.

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

Дальше итерациями

Дальше работа идёт итерационно. Каждый следующий спринт — конкретная задача с конкретным результатом: развернуть CI/CD, перевести конфигурацию в Terraform, настроить автоскейлинг, закрыть критичную точку нестабильности из карты.

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

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

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

Честный trade-off: что за 2 недели не происходит

Здесь важно быть прямыми.

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

Но за две недели не происходит полной трансформации инфраструктуры. CI/CD не развёрнут, конфигурация не переведена в код, технический долг не закрыт. Это работа следующих спринтов.

Чего точно не стоит ждать к концу второй недели:

Экономии на облачном счёте. FinOps — наша типовая вилка 20–40% — требует сначала накопленных данных об утилизации. Без нескольких недель метрик мы не можем обоснованно рекомендовать rightsizing или изменение конфигурации. Торопиться здесь опасно: downsizing без данных — это риск деградации под нагрузкой.

Исчезновения всех точек нестабильности. Карта составляется за две недели, устранение точек — это работа следующих спринтов, каждая в своём приоритете.

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

Понимание этого разграничения помогает правильно оценивать первые результаты: не как «мало», а как «ровно то, что запланировано на этом этапе».

Почему итерации, а не большой проект

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

Инфраструктура за год меняется. Бизнес-приоритеты меняются. То, что казалось критичным на старте, оказывается второстепенным через полгода. Итерационная модель позволяет встраивать эти изменения в работу, а не фиксировать их как отклонение от плана.

Спринты также снижают риск для обеих сторон. Если что-то идёт не так, это видно раньше, а не когда уже потрачены ресурсы за весь год.

Ещё один практический эффект: итерационная модель проще в управлении с точки зрения бюджетирования. Клиент утверждает спринт, видит результат, принимает решение о следующем. Это работает лучше, чем защищать перед финансовым директором годовой бюджет на «DevOps-трансформацию» с расплывчатым описанием результата.

С чего начать

Первый шаг — обследование. Оно занимает 3–5 рабочих дней и заканчивается конкретным планом: что делать, в каком порядке, с какими результатами на каждом шаге. NDA подписываем до начала технических переговоров.

Подробнее о том, как устроена работа, — на странице DevOps-аутсорсинга.