Экономика DevOps

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

Бизнес

Business first. Это мантра девопса. Можно делать крутые штуки, но какой в них прок, если они не используются? Допустим, существует некий Петя и он делает простой продукт, который приносит ему 3 миллиона долларов в месяц, а есть Гриша, который делает такую же штуку, но которая приносит 100 тысяч в месяц. Как вы думаете, кто из них может вложить больше денег в то, что он делает, и в итоге одержать победу?

Задача любого хорошего инженера — понимать, что может принести деньги или снизить убытки, а что — нет. Хотя главное, конечно же, не деньги, а бизнес.

Влияние

Естественно, ни Петя, ни Гриша не знают всего, что заставляет их продукт работать. Они умеют делегировать. В итоге по цепочке перераспределяются полномочия. И самое важное полномочие DevOps инженера — коммуникации.

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

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

Как вы поступите? Попробуете с ним сразиться? Обойти ущелье? Но за это время принцессу могут убить или испортить.

Может, стоит попробовать договориться с троллем? Такой выход очевиден, если ваша цель — не показать, какой вы правильный или умный и сильный, а спасти принцессу. Договаривайтесь, коммуницируйте, решайте проблему, а не показывайте себя.

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

Классика

Есть несколько разных способов смотреть на экономику. Адам Смит считал, что если каждый субъект экономики будет руководствоваться своими личными эгоистичными интересами, это будет создавать конкуренцию и в итоге приведёт ко всеобщей выгоде. Он жил в конце XVIII-начале XIX века. Его идеи до сих пор находят отклик.

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

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

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

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

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

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

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

Неоклассическая

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

То есть если инженер тратит две недели на то, чтобы страница загружалась не 0.1 секунду, а 0.05 секунды, эта работа может быть менее ценной, чем изменение картинки на лендинге, если второе в итоге приносит больше положительных результатов.

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

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

Например, можно бездумно использовать SaaS, не учитывая стоимость миграции в будущем.

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

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

От каждого по потребностям, каждому по способностям

Другие компании строят коммунизм в отдельно взятом обществе. Они руководствуются простой логикой:

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

Из этого правила растут ноги у современной luxury стартап культуры: офис менеджеры, релакс и музыкальные комнаты, массажисты, бесплатная еда и свобода действий внутри компании.

Хочешь — пилишь базу данных. Хочешь — ускоряешь загрузку страниц. Самое главное, чтобы в итоге все уложились в план. А лучше не просто выполнить, а перевыполнить :)

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

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

С другой стороны, если продажи идут, то команды могут вообще заниматься не тем, чем надо. «Пацаны фигачат». Но вот что они фигачат? Если план выполняется силами маркетинга, то программистам нет смысла писать быстрый код. Всё это будет работать до тех пор, пока не начнутся любые трудности, а потом наступит бардак и перестройка. К тому же, система слабо устойчива к манипуляциям изнутри.

Кроме прочего, подобные системы очень сложны для масштабирования. Именно с этим связано всё нытье в стиле «Ох, этот стартапнейм утратил свой дух». Я понимаю, что пока вас 20 человек и вы ищете 21-го, то достаточно просто судить о том, что можно вообще не строить планов, а просто дать каждому делать всё, что он считает правильным. Но когда начинаешь масштабироваться, балласт неизбежен так же, как и пивной живот после 30.

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

Шумпеританская школа

Сначала инновации, всё остальное потом.

Если вы в чём-то первый — сделайте из этого бизнес.

На этой идее построена книга Re:work, в которой ребята из 37signals хвалятся тем, что из внутреннего продукта сделали внешний.

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

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

Инновации стоит пилить, но всегда надо понимать, что вы с этого получите.

Бихевиоризм

Имея набор правил и ограничений, можно построить идеальную систему.

И я в принципе согласен с этой теорией. В идеальном мире.

В реальном появляются процессы ITIL, которым невозможно следовать.

С другой стороны, комбинируя создание ограничений с другими системами, можно прийти к интересным результатам. Ключевое: ограничение на создание правил должно включать в себя критерий Парето в одной из «мягких» вариаций. Не усложняйте. Если никто не может использовать правила, то никто не будет их использовать.

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

Выводы

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

Если вы делаете быстрый мониторинг, подумайте, нужен ли он. Возможно, на текущем этапе в короткой перспективе выгоднее использовать statsd\graphite совместимые решения от стороннего производителя? Согласовывайте с бизнесом и считайте. Если посчитать по деньгам сложно, пользуйтесь теоремой Байеса.

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

Если принять решение сложно, попробуйте ответить на вопросы:

• Моё решение приносит прибыль?
• Могу ли я сделать что-то, что будет ценнее?
• Согласовывается ли моё решение с планом бизнеса?
• Экономлю ли я время других сотрудников? Сколько?
• Если я решаю проблему стабильности\безопасности, есть ли что-либо, что может быть важнее конкретно сейчас?
• Сколько будет стоить миграция?
• Сколько будет стоить поддержка и развитие при наихудшем сценарии?

Думайте, оценивайте последствия своих действий, делайте. И удачи!