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

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

Инхаус – бестпрактиc в DevOps?

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

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

Но здесь, конечно, не без минусов. Все мы знаем о так называемом бас-факторе, под которым подразумевается риск остановки проекта в случае ухода ключевого специалиста. Если завтра девопса собьёт автобус, сколько времени и сил понадобится на поднятие из мёртвых поиск, найм, сбор по крупицам знаний о системе и доступах? И хорошо, если ваш прошлый девопс предрёк свою неловкую кончину и оставил документацию, описанный процесс онбординга, а на сладкое все доступы с пояснением, что куда и как. Но ведь не все так вежливы и предусмотрительны.

Второй подводный камень — это, конечно же, экспертиза. Современный DevOps требует от специалистов всё более и более масштабных знаний. Технологии растут как грибы после дождя, и многие мои коллеги жалуются на вечное ощущение безуспешной гонки за существующим стеком. При этом то, что появилось ещё до эры Kubernetes, не спешит покрываться вековым слоем пыли, и список требований в некоторых вакансиях сейчас больше напоминает страничку из Википедии с перечислением всех применяющихся в DevOps тулзов. Это сказывается на цене специалистов, и думаю, что многие, глядя на стоимость масштабирования команды, ощущают холодные жабьи лапки на шее. Ну и совсем уж мелкие камни вроде болезней, увольнений, выгораний и итальянских забастовок, думаю, даже не стоят отдельных абзацев. Все эти риски в модели инхаус берёт на себя бизнес.

Аутстафф — инхаус без риска?

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

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

Аутсорс — бездушная машина или недооцененная серебряная пуля?

Вот мы и добрались до аутсорса. Начну с преимуществ. Первое и, пожалуй, самое очевидное — команда вместо человека. И не просто команда, а отсутствие части рисков и сложностей, связанных с людьми в этой команде. Не надо думать над кадровыми вопросами, HR-процессами, беспокоиться об автобусах, в конце концов. У вас просто есть специалисты и точка взаимодействия.

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

Еще одним важным преимуществом является, конечно же, возможность технической поддержки 24/7. Довольно сложно и дорого выстроить у себя три, две, да даже одну линию технической поддержки проекта. А как же онколл, спросите вы? Небольшие компании вполне вывозят 24/7 с помощью пары специалистов на онколле, но так лояльность своих сотрудников точно не повысить, разве что в противовес вы предложите им ДМС с включённым туда психологом.

Закончим, пожалуй, с очевидными штуками и перейдём к менее очевидным. Чёткие договорные отношения. С аутсорс-компанией обычно заключается договор, в котором прописываются сроки выполнения работ, SLA, обязательства и штрафы. Значит, заказчик делит финансовые риски с исполнителем. А исполнитель высоко замотивирован сделать всё хорошо и в срок. Отсюда вытекают отстроенные процессы. На счету аутсорс-компаний обычно не одна сотня построенных инфраструктур, множество различных миграций, а значит, всегда есть набор подробных чек-листов и бестпрактисов на все случаи жизни.

Не сто́ит упускать из виду и партнёрки. У аутсорс-компаний часто бывает доступ к партнёрским программам с облачными провайдерами, популярными платформами и сервисами. А это обычно означает дополнительные скидки, интересные акции и возможности тестирования новых инструментов и услуг. Такие партнёрства нередко ускоряют процесс, поскольку в выделенных партнерских чатиках вопросы решаются куда быстрее.

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

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

Вместо выводов

Что в итоге? Однозначно ли инхаус девопс всегда будет лучшим выбором, как об этом говорят евангелисты? В идеальном мире — да. В мире, где мимо нас по радуге бегут единороги, а где-то высоко висит в вакууме тот самый сферический конь инхаус девопс будет работать как и задумано. В этом идеальном мире переезды происходят без подводных камней и скелетов, внезапно выпадающих из самых разных конфигов, а люди никогда не ошибаются, не болеют и не выгорают.

А в настоящем, если у вас есть какая-то глобальная задача, или даже набор, конечная цель, желательно с крайними сроками, понимание, как измерить результаты, а то и какой-то базовый набор тестов – девопс аутсорс, скорее всего, окажется выгоднее.

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

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

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

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

Отдельно сто́ит получить себе всё sla, которые предоставляет и не предоставляет компания, а также флоу работы с задачами. Важно понимать – факт обсуждения задачи и ее условий совсем не значит, что она уйдёт в работу сегодня или даже завтра. Но если грамотно распределить приоритеты, понять крайние сроки и главное — обсудить всё это с исполнителем, то проблем и разочарований будет куда меньше.

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