Говорим о DevOps: ответственность и задачи
В определённый момент каждый опс сталкивается с вопросами «Кто я?», «Зачем я здесь?» и «Что делать?», порождающими многочисленные споры и дискуссии. С одной стороны, у нас есть текущие проблемы, которые надо решить, с другой — логичная и непротиворечивая архитектура девопса. Мне кажется, логика есть и там, и там, поэтому стоит обернуться назад и посмотреть на историю возникновения девопс-культуры.
Допустим, у нас есть бизнес — разработка какого-то софта. Таким образом, внутри у нас уже есть несколько команд, которые разрабатывают различные компоненты и сервисы. Независимо от языка, который они используют, разные команды делают это по-разному. Кто-то может позволить себе stateless, кто-то нет. Кто-то хочет использовать какие-то архитектурные решение, а кто-то просто не может в силу специфики продукта. В своих рассуждениях я беру за отправную точку то, что все команды имеют разные задачи и стараются сделать их максимально точно и просто.
Опс
Спустя какое-то время становится ясно, что команды, пусть и решают разные задачи, сталкиваются с одинаковыми или похожими проблемами. Решение некоторых из них будет одним и тем же независимо от сервиса.
Соответственно, бизнес думает так: если можно выделить что-то общее, то можно сформировать отдел людей, которые будут заниматься только этим и извлекать выгоду.
Экономия на разнице стоимости работы
Если у нас есть дорогой девелопер, время которого стоит 30 долларов в час, то зачем ему делать ту работу, с которой справляется человек стоимостью 10 долларов в час? Если выделить всю низкооплачиваемую и простую работу, то можно сэкономить.
К тому же дорогой девелопер будет делать сложные задачи, которые ему интересны, а дешёвый опс — простые, которые девелоперу не интересны.
Экономия на простоях
Если внутри команды есть люди, которые занимаются только опс-задачами, то у них будет время простоя, пока команда не сгенерирует новые задачи.
Объединяя людей в общий отдел, можно «шарить» их на несколько команд и получать от этого выгоду.
Экономия на экспертизе
Если есть задачи, общие для всех, то разные отделы всё равно приходят к примерно одним и тем же решениям. Развивать экспертизу сразу в нескольких командах всегда дороже, чем содержать нескольких экспертов, которые решат задачу и быстрее, и качественнее.
К тому же, имея нескольких экспертов, которые замещают друг друга, можно не бояться, что кто-то станет незаменимым просто потому, что никто кроме него не умеет обновлять хитрый сетап.
Опс эра
В до-девопс эру принято было поручать отдельной команде решение задач такого типа:
- настройка производительности OS (экспертиза);
- управление базами данных (экспертиза);
- работа с другим open source софтом (экспертиза);
- мониторинг продукта (экспертиза);
- доставка обновлений продукта (экспертиза/стоимость);
- производительность продукта (экспертиза);
- управление серверами\инфраструктурой (экспертиза/стоимость);
- бекапы (экспертиза/стоимость);
- безопасность (экспертиза);
- обеспечение стабильности работы (экспертиза/стоимость);
- мелкая поддержка 24/7 (стоимость).
Самое смешное, что почти всё из списка выше не вопрос стоимости, как обычно считают, а вопрос экспертизы: когда люди, которые умеют что-то делать, помогают другим людям, которые не умеют этого делать. Таким образом, редко получается нанять дешёвого человека, который будет опытным и при этом не против поделать какую-то рутинную фигню.
Так как занимать дорогих спецов рутиной не получается, а дешёвые спецы творят фигню, то обычно внутри такой команды формируется (эволюционно или специально) структура разделения запросов в зависимости от сложности.
Вроде звучит здорово. Но, как мы все знаем, чаще всего чем больше хопов, тем выше латенси. Следовательно, такая структура повышает время решения любой задачи.
И это ещё не всё: любой человек или группа людей почти всегда делает только то, что от них требуют. В итоге у нас образовывается несколько команд, у которых в приоритете новые фичи, и одна команда, которая отвечает исключительно за стабильность. И если у этих команд нет ничего общего, то начинается игра с нулевой суммой. А она, как известно, для бизнеса ничем хорошим не заканчивается: опсы хотят стабильности настолько, что саботируют фичи и новые технологии, а девы хотят как можно меньше заниматься чем-то, кроме фичей, потому что именно по этой метрике их судит бизнес.
Как результат, страдает культура внутри компаний и понижается конкурентоспособность. Бизнес перестаёт использовать все те возможности, которые мог бы использовать. К тому же проблема роста одного отдела, количество задач которого зависит от других отделов, это очень сложная тема. Как-то поговорим отдельно :)
Devops
Столкнувшись с этими проблемами, можно прийти к простому решению: давайте наймём дорогих специалистов, которые будут автоматизировать рутинные задачи, и при помощи всяких культурных штук оформим диалог людей, которые поддерживают продукт, с теми, кто его деплоит.
Для уменьшения задержек мы сделаем команды инженеров ответственными как за новые фичи, так и за стабильность работы продукта. Потому что как одно, так и второе, — часть пользовательского опыта от использования сервиса. И фичи, и стабильность — это и есть продукт. К тому же, если надо выстроить приоритеты между стабильностью и скоростью, то лучше это делать в одной команде, где понимают, что чем чревато, чем на бесконечных совещаниях двух команд с совершенно противоположными целями.
Тут внимательный читатель обратит внимание, что почти всё, чем занимался опс-отдел, связано со стабильностью, и будет прав. Поэтому работа опсов должна быть вынесена в команды, которые разрабатывают и используют продукт.
Я знаю, это очень громкое утверждение. Проблемы, с которыми сталкиваются при таком переходе, были описаны ещё в начале статьи, но давайте подумаем: можно ли решить эти проблемы другим путём? Что если у нас будет отдел, который при помощи автоматизации уберёт рутинные задачи и будет иметь необходимую экспертизу, чтобы делиться ею с другими командами? Одни проблемы могут быть решены обучением и совместным внедрением, а другие (в том числе и шаринг экспертизы) — скриптами. А немногое общее может стать внутренним продуктом, который эта команда будет предоставлять:
- настройка производительности OS (автоматизация/обучение/совместные проекты);
- управление базами данных (автоматизация/внутренний SaaS);
- работа с другим open source софтом (автоматизация/внутренние best practices/ответственность команд);
- мониторинг продукта (автоматизация/внутренний SaaS/обучение);
- доставка обновлений продукта (автоматизация);
- производительность продукта (ответственность команд);
- управление серверами\инфраструктурой (автоматизация);
- бекапы (автоматизация);
- безопасность (экспертиза/обучение/автоматизация/совместные проекты);
- обеспечение стабильности работы (автоматизация/обучение);
- мелкая поддержка 24/7 (автоматизация?).
И получается, что сложные и общие вопросы решает одна команда, а все остальные команды не следят за тем, как обновляется графит или как меняются тренды докеров. Они просто используют внутренние продукты и утилиты, которые и являются лучшими практиками.
Никто не пишет свой мониторинг, никто не придумывает своё докерное извращение — об этом думает специальная команда.
Но если вы хотите получать метрики и доставлять свои приложения на продакшн, у вас есть набор утилит/практик, помогающих делать это правильно, не наступая на одни и те же грабли. И не надо каждый раз изобретать велосипед и получать экспертизу там, где она вам не нужна.
Подобная схема удобна. Команда опсов превращается в мультикоманду инженеров, которая занимается всем, чем может, и помогает везде, где надо. В список задач может прийти и переписывание/оптимизация высокопроизводительного кода, и внутренний PaaS, и упрощение сборки/доставки приложения.
И такая команда занимается не поддержкой всего на свете, а конкретными продуктами, как и в других продуктовых командах. И как для других продуктовых команд для неё можно выставлять собственные приоритеты, ориентируясь на общее инженерное виденье, делать продукт для конкретных пользователей.
А остальные продуктовые команды лучше понимают то, как работает их код в продакшене, и это достаточно благостно и отрезвляюще влияет на продукт-менеджмент и стабильность, ведь если вы отвечаете за пользовательский опыт, то обычно очень быстро находите нужную и выгодную именно вам точку между стабильностью и новыми возможностями.
Описанная выше схема, помимо всего прочего, стимулирует делиться знаниями и опытом вместо сосредоточения умений в одних руках и дополнительно даёт свободу там, где она необходима, решая проблему масштабирования команд: хочешь использовать тарантул, монгу, очереди, постгрю? Не надо упрашивать опсов, чтобы они этим занялись. Ставь и зарабатывай свой опыт. Но отвечаешь за это тоже ты.
И если всё идёт правильно, то побеждают тот, кто берёт на себя ответственность, а не тот, кто лучше всех перекладывает её на других. Это ведь здорово, правда?
Послесловие
Для того чтобы девопс заработал, в него надо вложить немало сил. Но кроме этого много сил надо и для поддержки. Надо постоянно учиться, постоянно искать, что можно сделать лучше, и делать это лучше. Надо думать не только о сегодняшнем дне, но и том, что будет через год. Со стороны этой общей экспертной команды надо всегда смотреть на несколько шагов вперёд и стараться облегчить жизнь другим. Надо делать продукты максимально автономными и в меру абстрактными. Такими, чтобы они подходили как можно большему количеству инженеров. Сделать так, чтобы у остальных команд было как можно меньше проблем. А другие продуктовые команды должны принять на себя ответственность за свой продукт, ответственность за опыт своих пользователей и постоянно пересматривать свой продукт со стороны этого опыта.
