Привет! На связи Никита Ветров, менеджер проектов компании «Флант». Сегодня я поделюсь тем, как устроена услуга DevOps as a Service с точки зрения процессов взаимодействия наших команд с клиентами.
У внутренней и внешней DevOps-команд одинаковые обязанности. Они отвечают за то, чтобы все стабильно работало. Например, следят за тем, чтобы приложения исправно функционировали, а при сбоях исправляют ошибки. Но, чтобы выполнять эти обязанности, DevOps-команда должна быть сформирована и готова к задачам. В этом и есть основное отличие внешней команды от внутренней.
Внешняя DevOps-команда — это готовая команда. Для сотрудничества с ней не нужно тратить время на наем и думать о рисках отбора специалистов. Также в сторонних командах уже отлажены все процессы, есть свой отлаженный и протестированный набор решений и инструментов, поэтому не приходится тратить время на настройку рабочей среды. При этом у сторонней DevOps-команды могут возникать сложности в работе. Например, клиенту могут не понравиться реакция на инциденты, недостаточная экспертиза сторонних инженеров или жесткие ограничения на выполняемые задачи.
В этой статье я расскажу, как DevOps-инженеры «Фланта» интегрируются в команду клиента и по каким правилам мы работаем, чтобы сотрудничество было комфортным для всех. Мы пройдемся по каждому этапу внедрения и разберем основные принципы, проблемы и риски при интеграции сторонних DevOps-команд.
Статья будет полезна тем, кто только задумался о привлечении в свою компанию сторонней команды и хочет узнать, как строится процесс внедрения. Также она будет интересна тем, кто и сам оказывает похожие услуги или формирует внутреннюю DevOps-команду.
В целом жизненный цикл интеграции в команду клиента устроен вот так:
Теперь разберем каждый этап подробнее.
Знакомство с клиентом и заключение договора
На этом этапе мы впервые взаимодействуем с клиентом. Здесь несколько шагов:
Клиент рассказывает о себе.
Мы рассказываем о себе.
Проводим первоначальный аудит.
Заключаем договор с клиентом.
1. Клиент рассказывает о себе
На первую встречу от компании клиента приходят специалисты уровня СТО, например руководители разработки, инфраструктуры. Обычно они рассказывают о себе следующее:
Что представляет из себя их бизнес, что они предлагают рынку.
Из чего состоит их инфраструктура сейчас, какие используют технологии, с какими проблемами сталкиваются.
Что из себя представляют их приложения, на каких технологиях написаны, какие инфраструктурные компоненты используют.
Как сейчас выглядит процесс сборки и доставки приложений.
Какие сейчас есть боли и проблемы.
Что ожидает бизнес клиента от нашего сотрудничества.
2. Мы рассказываем о себе
На знакомство с клиентом от «Фланта» приходят менеджер проектов, тимлид и менеджер отдела продаж. Мы рассказываем о процессах нашей совместной работы:
Как мы работаем с плановыми задачами.
Какие инструменты мониторинга используем.
Как мы реагируем на критические инциденты и эскалации.
Какие используем подходы к реализации сборки и доставки приложений.
На этом этапе мы сразу уточняем, что работаем на инфраструктуре клиента. То есть используем его виртуальные машины для развертывания кластера. Также мы рассказываем, что обычно приходим со своим стеком, например werf, Deckhouse, потому что знаем, как использовать их наиболее эффективно. Но у клиента уже может быть реализован какой-нибудь инструмент, например пайплайн сборки и доставки, или есть своя инсталляция Kubernetes. В этом случае мы предлагаем переходный этап, когда мы поддерживаем текущую инфраструктуру, а параллельно готовим новую с применением наработанных нами практик и своих инструментов.
Когда клиент не готов сразу перенастраивать инфраструктуру, мы даем свои рекомендации по необходимым изменениям. Если он будет готов к ним, мы снова можем обсудить сотрудничество.
3. Проводим первоначальный аудит
На первоначальном аудите мы стараемся комплексно оценить текущую инфраструктуру, готовность приложений к работе в K8s, понять текущие нюансы и проблемы, ближайшие цели клиента и его ожидания. В итоге мы решаем, получится ли помочь с проблемой, и оцениваем, сколько это будет стоить.
В процессе аудита приложений мы опираемся на 12 факторов разработки cloud native-приложений. По ним мы оцениваем приложение клиента. И если оно не соответствует каким-либо пунктам, мы получим ограничения, из-за которых приложение будет работать менее эффективно.
Например, мы понимаем, что приложение может быть сконфигурировано только при сборке. Это значит, что можно получить разные образы приложения для разных окружений, что приведет к проблемам с воспроизводимостью, например, в production- и stage-окружениях.
Чтобы получить все бонусы от использования Kubernetes, это необходимо исправить. А для этого требуется участие команды разработки. Поэтому клиент должен быть готов к изменениям в инфраструктуре, иначе у нас не получится полноценно кубернетизировать приложение. DevOps-команда не сможет решить это самостоятельно.
Заключение договора с клиентом
Если все участники понимают, что готовы к сотрудничеству, команда «Фланта» формирует коммерческое предложение, и менеджер отдела продаж отправляет его клиенту. В нем прописываются условия сотрудничества:
Услуги, которые будут оказаны, например работа с плановыми задачами по развитию проекта, техническая поддержка 24/7, консультации для специалистов команды клиента.
Состав DevOps-команды. Обычно это тимлид, менеджер и 5–8 инженеров.
Описание процесса работ, например сбор и обработка алертов, работа с авариями и инцидентами, плановые задачи.
Схема конечной инфраструктуры, к которой мы стремимся.
Стоимость обслуживания для клиента.
Если коммерческое предложение подходит клиенту, мы согласовываем и оформляем договор. На этом этапе мы совместно прорабатываем документы, решаем спорные моменты и подписываемся.
Еще на этом этапе клиент может попросить составить и подписать соглашение о неразглашении (NDA), чтобы защитить конфиденциальную информацию.
Знакомство с командой
После подписания договора наша DevOps-команда знакомится с командой клиента. Здесь нам важно выяснить, кто из специалистов у клиента за какой процесс отвечает. Например, кто отвечает за разработку приложения, эксплуатацию и безопасность. Еще мы знакомимся с лицом, принимающим решения (ЛПР). Этот тот человек, который может однозначно решить вопрос со стороны клиента, несмотря на то, сколько там команд.
Например, у клиента может быть несколько команд разработки. У каждой свои задачи со своими приоритетами. Но мы не можем оценить важность задачи, так как не настолько погружены в процессы. Здесь и нужен ЛПР, который сможет помочь нам разобраться с приоритетами среди всех команд и заказчиков.
Также мы обязательно рассказываем про нашу команду. Объясняем, за что отвечают менеджер проектов и тимлид, и знакомим с инженерами. Еще на этом этапе более подробно изучаются потребности, проблемы и боли клиента. Если не уделить этому должного внимания, может возникнуть эффект неоправданных ожиданий.
Например, клиент ожидает, что все его приложения будут разворачиваться с нулевым даунтаймом (0-downtime). Мы не знаем этого, поэтому строим инфраструктуру и готовим сценарии сборки/доставки без учета такой потребности. Из-за этого каждый деплой приложений приводит к потере трафика. В итоге клиент недоволен проделанной работой. А чтобы исправить проблему, потребуется дополнительное время, которое мы могли бы использовать для других задач.
Именно поэтому в течение первых пары недель мы выясняем, с кем и чем работаем и что от нас нужно.
Получение доступов и первые настройки
Так как мы работаем на инфраструктуре клиента, нам нужно получить к ней доступ. В зависимости от специфики клиента мы либо просим его выделить необходимое количество виртуальных машин для развертывания кластера, либо получаем доступ в клиентское облако и уже там заказываем необходимые ресурсы самостоятельно.
Чтобы наша DevOps-команда могла работать с проектом клиента, мы должны получить доступы:
к серверам;
к админ-панелям хостеров/ЦОД;
во все личные кабинеты, с которыми нужно будет работать инженерам «Фланта» для выполнения условий договора.
Мы начинаем работать, как только нам выдадут доступы. Если их будут выдавать слишком долго (например, в течение месяца согласовывать все нюансы с руководством или службой безопасности), может возникнуть простой. То есть за это время ни к одной из оговоренных задач приступить мы не сможем, а договор уже действует. Получится так, что на решение оговоренных задач уйдет больше времени и денег.
Настройка коммуникаций
Пока ждем доступы, мы настраиваем каналы коммуникаций. Они нужны, чтобы обмениваться информацией с клиентом: дежурными, инженерами команды, линией технической поддержки и остальными участниками процесса.
Наше основное средство коммуникации — Slack. По нашему мнению, он отвечает нашим требованиям и у него есть широкие возможности для интеграции.
Для каждого клиента в Slack заводятся два канала:
канал с представителями клиента, где обсуждаются организационные вопросы;
канал для команды, которая работает над текущими задачами.
Иногда клиенты предлагают другие способы связи, например мессенджеры или электронную почту. Но для нас Slack — это не просто мессенджер, это наш инструмент и большая часть наших процессов. В нем реализованы боты, интеграции с другими нашими инструментами, выстроены все коммуникации. Поэтому мы не можем отказаться от него, так как это приведет к снижению уровня нашего сервиса, на что мы пойти не можем.
Еще мы проводим видеовстречи в Google Meet. Но, если этот инструмент не подходит, мы готовы подстроиться под клиента.
Обычно на таких встречах обсуждаются текущие задачи или срочные вопросы, которые нельзя решить в переписке. Видеовстречи организовывает менеджер проектов совместно с клиентом.
Коммуникация важна в нашей работе. Если клиент перестает идти на контакт, нам приходится приостанавливать работы до восстановления диалога. Мы не можем самостоятельно принимать решения, даже если они кажутся нам правильными, так как это помешает достичь совместной цели.
Работа с клиентом
Когда доступы получены и настроена рабочая среда, мы начинаем подготавливать инфраструктуру под кластер K8s и разворачиваем сам кластер. После этого мы начинаем подготовку приложений к деплою в кластер.
Еще мы составляем первичный скоуп — список работ, которые нужно выполнить для достижения цели. Он обсуждается с клиентом. Если перечень задач всех устраивает, мы приступаем к работе.
Так как во время работы могут происходить незапланированные ситуации, скоуп может изменяться. Например, сейчас у клиента может проходить аудит безопасности, по результатам которого была найдена критическая уязвимость, требующая исправления прямо сейчас. Из-за этого задачи могут сдвинуться.
Задачи распределяются по спринтам. Обычно спринт — это неделя. Каждую неделю мы созваниваемся с командой клиента и обсуждаем, что сделали за прошедший спринт, какие изменения произошли и какие проблемы могут возникнуть. Также мы обсуждаем и утверждаем задачи на следующий спринт.
Помимо задач, на встрече обсуждаются предложения нашей команды и команды клиента. Например, мы заметили, что одно из ключевых приложений клиента работает в одной реплике и не масштабируется при увеличении нагрузки. И мы знали, как это исправить. Поэтому мы предложили исправление клиенту, обсудили и приняли решение по его реализации.
Важно отметить, что все задачи и изменения происходят сообща с клиентом. Но бывают ситуации, когда нам нужно сделать что-то здесь и сейчас. Например, если мы видим, что заканчивается место на диске, мы не будем ждать реакции клиента. Мы решим эту проблему сразу. А после этого обсудим с клиентом, что необходимо сделать для устранения подобной проблемы в будущем. Работающий production важнее, чем обязательное согласование изменений.
Встречи могут проходить в разные дни в зависимости от договоренности. С нашей стороны обычно присутствуют менеджер проекта и тимлид. Со стороны клиента чаще всего присутствуют руководители разного уровня и представители команд.
Иногда руководители перестают ходить на встречи, так как полностью доверяют нам. Мы стараемся не допускать этого и просим их всегда присутствовать, участвовать в обсуждениях и смотреть, как продвигается работа. Так существенные решения не будут для них неожиданностью, что исключит недопонимание в работе.
Также совместно с руководителями устанавливаются приоритеты задач. Например, разработчики на стороне клиента могут убеждать, что их работа более значимая. Но в наши обязанности не входит регулировать отношения между сотрудниками компании клиента. Поэтому здесь нужен их руководитель, который поможет принять правильное решение. Это особенно важно, когда количество задач растет и нужна жесткая приоритизация целей.
Еще неотъемлемой частью работы нашей команды являются дежурства. Мы 24/7/365 следим за состоянием приложений и инфраструктуры и своевременно реагируем на инциденты. Об их появлении нам приходят уведомления. Время реакции на самый важный или критический инцидент — до 5 минут.
Когда появляется проблема, наши дежурные первой линии сообщают об этом клиенту, а также дежурному инженеру команды. При этом клиент тоже может настроить отправку уведомлений об инцидентах в удобные ему каналы, например на почту или в Telegram.
Подробнее о том, как эволюционировали наша служба технической поддержки и система обработки инцидентов и к чему мы в итоге пришли, можно прочитать в статье «10 лет on-call. Чему мы научились?».
Расставание с клиентом
Любой бизнес рассчитывает на долгосрочную работу и развитие. Но бывают ситуации, когда нам приходится расставаться с клиентом. Например, ожидания владельцев бизнеса не оправдываются либо возникают обстоятельства, когда дальнейшее развитие бизнеса невозможно.
Еще бывает так, что команда клиента состоит из специалистов с небольшим опытом работы в используемых нами технологиях. За время сотрудничества они перенимают наши опыт и знания. В итоге наступает момент, когда клиент считает, что вырастил собственных экспертов и отказывается от наших услуг.
В таких случаях мы останавливаем сотрудничество по договоренности с клиентом, но всегда оставляем возможность вновь поработать в будущем.
Когда приходит время прощаться, мы делаем так, чтобы клиент мог продолжать работать без нас. Но, чтобы все работало, мы рекомендуем ему нанять хотя бы одного DevOps-инженера, который смог бы сопровождать отлаженные процессы. А если переложить эти задачи на разработчика, могут быстро появиться новые проблемы, так как это не его зона ответственности.
Что мы обещаем при расторжении договора:
Все изменения и процессы остаются у клиента. Благодаря подходу Infrastructure as Code (IaC) все создаваемые сценарии CI/CD, конфигурация приложений и инфраструктурных компонентов остаются в Git'е клиента.
Консультируем клиента, чтобы он снова не столкнулся с проблемами. При этом мы не обучаем команду клиента, так как это не входит в перечень наших услуг. Но мы всегда отвечаем на вопросы, чтобы не оставлять его лицом к лицу с чем-то с неизвестным.
Оставляем все доступы клиенту, а сами отказываемся от прав на них. Поэтому клиенту не нужно беспокоиться, что наша работа станет предметом спора или исчезнет из его Git’а.
Процесс окончания работы:
Договариваемся с клиентом о сроках, за которые передаются все дела. Обычно на это уходит месяц.
Во время передачи дел прекращаем развитие совместного проекта. При этом поддержка не прекращается до окончания срока договора.
Передаем дела сотрудникам команды клиента, которые теперь будут работать с инфраструктурой и осуществлять поддержку.
Согласуем и оформляем соглашение о расторжении договора.
Проблемы и риски при интеграции сторонних DevOps-команд и как их избежать
Непрозрачность в работе. Когда сторонняя и внутренняя команды не коммуницируют, это может привести к тому, что выполняются не те задачи, которые сейчас необходимы клиенту. Например, мы занимаемся оптимизацией используемых ресурсов, а клиенту сейчас важнее развернуть новый сервис, который требуется его бизнесу. В итоге это приведет к конфликту между сторонами договора. Чтобы избежать этой проблемы, нужно постоянно синхронизировать выполнение работ со всеми инженерами из команд клиента, а не только с ЛПР.
Единственная точка входа в DaaS-команду. Когда все коммуникации проходят через одного человека, это может привести к задержкам в реагировании на возникающие ситуации. А это может плохо отразиться на работе инфраструктуры клиента.
Специализация инженеров на одной технологии. Если DevOps-инженеры работают каждый в своей области (например, один занимается только созданием сценариев CI/CD, второй — обслуживанием баз данных, третий — обслуживанием ELK), это делает их незаменимыми. Получается, что в случае болезни, отпуска или увольнений задачей клиента будет некому заниматься. Лучше распределять задачи таким образом, чтобы каждый инженер работал со всем технологическим стеком клиента и мог справиться в любой ситуации.
Отсутствие гибкости при планировании. Допустим, в течение спринта у клиента возникла более приоритетная задача — развернуть дополнительное окружение для приложения, так как это необходимо для демонстрации функционала бизнесу. Но у вас уже запланирован пул задач на спринт, поэтому вы решили отложить новые. В итоге произошел простой production’а. Гибкость в тайм-менеджменте очень важна. Поэтому надо быть готовым менять список первоочередных работ при необходимости.
Каждый сам за себя. Инженеры не должны предпочитать самостоятельно разбираться в проблемах. Наоборот, при непонимании или недостатке знаний следует всегда обращаться за поддержкой к коллегам. Это позволяет всей команде быть в курсе событий, накапливать опыт и своевременно реагировать на проблемы.
Вместо заключения
Прежде чем приступить к решению задач в проекте клиента, мы проходим несколько этапов подготовки: знакомимся, рассказываем о себе, изучаем текущую инфраструктуру и готовность приложений, получаем доступы и настраиваем рабочую среду. То есть мы не начнем сотрудничество с клиентом, пока не будем уверены, что справимся с поставленной задачей, а также не будем подготовлены к работе.
За многолетний опыт мы настроили взаимодействие с клиентом так, что даже расставание с нами происходит максимально комфортно. Поэтому нашими практиками пользуются как компании с похожими услугами, так и те, которые формируют внутреннюю DevOps-команду.
В следующих статьях мы продолжим рассказывать о том, что из себя представляет Daas, по каким принципам мы сотрудничаем с клиентами и как устроена работа внутри «Фланта».
P. S.
Читайте также в нашем блоге: