Говорим о DevOps: ответственность и задачи

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

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

Опс

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

Соответственно, бизнес думает так: если можно выделить что-то общее, то можно сформировать отдел людей, которые будут заниматься только этим и извлекать выгоду.

Экономия на разнице стоимости работы

Если у нас есть дорогой девелопер, время которого стоит 30 долларов в час, то зачем ему делать ту работу, с которой справляется человек стоимостью 10 долларов в час? Если выделить всю низкооплачиваемую и простую работу, то можно сэкономить.

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

Экономия на простоях

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

Объединяя людей в общий отдел, можно «шарить» их на несколько команд и получать от этого выгоду.

Экономия на экспертизе

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

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

Опс эра

В до-девопс эру принято было поручать отдельной команде решение задач такого типа:

  • настройка производительности OS (экспертиза);
  • управление базами данных (экспертиза);
  • работа с другим open source софтом (экспертиза);
  • мониторинг продукта (экспертиза);
  • доставка обновлений продукта (экспертиза/стоимость);
  • производительность продукта (экспертиза);
  • управление серверами\инфраструктурой (экспертиза/стоимость);
  • бекапы (экспертиза/стоимость);
  • безопасность (экспертиза);
  • обеспечение стабильности работы (экспертиза/стоимость);
  • мелкая поддержка 24/7 (стоимость).

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

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

Вроде звучит здорово. Но, как мы все знаем, чаще всего чем больше хопов, тем выше латенси. Следовательно, такая структура повышает время решения любой задачи.

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

Как результат, страдает культура внутри компаний и понижается конкурентоспособность. Бизнес перестаёт использовать все те возможности, которые мог бы использовать. К тому же проблема роста одного отдела, количество задач которого зависит от других отделов, это очень сложная тема. Как-то поговорим отдельно :)

Devops

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

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

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

Я знаю, это очень громкое утверждение. Проблемы, с которыми сталкиваются при таком переходе, были описаны ещё в начале статьи, но давайте подумаем: можно ли решить эти проблемы другим путём? Что если у нас будет отдел, который при помощи автоматизации уберёт рутинные задачи и будет иметь необходимую экспертизу, чтобы делиться ею с другими командами? Одни проблемы могут быть решены обучением и совместным внедрением, а другие (в том числе и шаринг экспертизы) — скриптами. А немногое общее может стать внутренним продуктом, который эта команда будет предоставлять:

  • настройка производительности OS (автоматизация/обучение/совместные проекты);
  • управление базами данных (автоматизация/внутренний SaaS);
  • работа с другим open source софтом (автоматизация/внутренние best practices/ответственность команд);
  • мониторинг продукта (автоматизация/внутренний SaaS/обучение);
  • доставка обновлений продукта (автоматизация);
  • производительность продукта (ответственность команд);
  • управление серверами\инфраструктурой (автоматизация);
  • бекапы (автоматизация);
  • безопасность (экспертиза/обучение/автоматизация/совместные проекты);
  • обеспечение стабильности работы (автоматизация/обучение);
  • мелкая поддержка 24/7 (автоматизация?).

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

Никто не пишет свой мониторинг, никто не придумывает своё докерное извращение — об этом думает специальная команда.

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

Подобная схема удобна. Команда опсов превращается в мультикоманду инженеров, которая занимается всем, чем может, и помогает везде, где надо. В список задач может прийти и переписывание/оптимизация высокопроизводительного кода, и внутренний PaaS, и упрощение сборки/доставки приложения.

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

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

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

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

Послесловие

Для того чтобы девопс заработал, в него надо вложить немало сил. Но кроме этого много сил надо и для поддержки. Надо постоянно учиться, постоянно искать, что можно сделать лучше, и делать это лучше. Надо думать не только о сегодняшнем дне, но и том, что будет через год. Со стороны этой общей экспертной команды надо всегда смотреть на несколько шагов вперёд и стараться облегчить жизнь другим. Надо делать продукты максимально автономными и в меру абстрактными. Такими, чтобы они подходили как можно большему количеству инженеров. Сделать так, чтобы у остальных команд было как можно меньше проблем. А другие продуктовые команды должны принять на себя ответственность за свой продукт, ответственность за опыт своих пользователей и постоянно пересматривать свой продукт со стороны этого опыта.

Похожие статьи:
Нещодавно зʼявилася інформація, що Дмитро Шоломко йде з Google Ukraine після 17 років на цій посаді. Зараз компанія шукає нового керівника для...
Привет, Доу! Меня зовут Олег, и мне 29 лет. 2 месяца назад я стал разработчиком приложений для iOS, а ещё я работаю фейсером (тот самый...
Цель семинара-практикума от зарегистрированного поставщика обучения PMI — подготовить слушателей к успешному прохождению...
«Я знаю, что ничего не знаю» © Сократ Для кого: для IT-шников, которые плевали на всех разработчиков и хотят поиграть в свои...
Рекрутери складають вакансії разом з провідними технічними експертами своїх компаній. Їхня співпраця дозволяє врахувати...
Яндекс.Метрика