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