«Будет очень много боли»: когда лучше ничего не менять в инфраструктуре проекта

Переехать в облако или докупить ещё серверов? Перейти на Kubernetes или Swarm? Организовать хранение данных с помощью NFS или CephFS? Любое из этих решений может принести компании как пользу, так и боль. Много боли. Мы 14 лет занимаемся инфраструктурными проектами на аутсорсе и случается, что мы отказываем клиентам, которые собираются внедрить глобальные изменения. Расскажем, почему.

Банально, но факт: если в компании не знают, зачем хотят что-то изменить, то работы лучше отложить до тех пор, пока не будет ясна цель и definition of done. Если цель есть, но не слишком чёткая, толку от неё не больше.

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

Мы стараемся не начинать работы с заказчиком, пока он не определится, какого результата хочет достичь и какие конкретно проблемы решить. Запросы вроде «чтобы приложение лучше работало» всегда конкретизируем. Что значит «лучше»? Чтобы сервер отвечал быстрее, чтобы не было задержек в загрузке — это уже более конкретная задача.

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

Любое изменение требует ресурсов — это всем ясно. Но не всегда ясно, каких именно и в каком количестве.

Для простоты снова возьмём пример с Kubernetes. Вот компания решила поднять кластер, нашла подрядчика, выяснила стоимость работ — выделила деньги. Казалось бы, что ещё нужно. Но переход на микросервисную архитектуру, которую подразумевает внедрение Kubernetes, нельзя осуществить только силами подрядчика.

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

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

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

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

Заоблачные требования. Мы отказываем компаниям, чьи юристы предъявляют заоблачные требования к проекту. Что значит заоблачные? Это когда стоимость проекта 100 тыс., а штрафы за малейшее нарушение — 10 млн. Одно и другое несоизмеримо, но не всегда удаётся убедить в этом юридический отдел. В таком случае мы вынуждены сказать «нет».

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

Отказ от начальной настройки. Чтобы обеспечить безопасность, производительность и высокую скорость реакции на инциденты, мы следуем правилу: инфраструктуру для каждого нового проекта настраиваем с нуля, согласно стандартам. Если заказчик не согласен на первичную настройку, то высока вероятность, что сотрудничество не состоится. Компромисс возможен, но для этого должна быть веская причина.

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

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

Взаимодействие строится так:

1. Клиент заполняет бриф, команда инженеров его изучает. Это первый этап.
2. Организуем техническую встречу, где уточняем цели заказчика и текущее состояние инфраструктуры. Это второй этап.
3. Формируем предварительное коммерческое предложение. Это третий этап.
4. Если предложение клиента устраивает, организуем аудит, а после этого согласовываем техническое задание — финальный список работ. И это последний этап. Когда он пройден, берёмся за дело.

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

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