Особенность DevOps‬ в крупных ‪компаниях

Прежде чем перейти к особенностям DevOps, стоит разобраться, в чем отличие крупных компаний и систем, поддерживающих их работу. Это и командообразование по технологиям (часто называют silos), и жесткие требования регуляторов, и большое количество согласований и, безусловно, крупные, масштабные релизы.
Такие системы имеют долгую историю, соответственно, аккумулируют занния, костыли и решения от нескольких поколений разработчиков, архитекторов, аналитиков; технологических изменений в мире. Приходилось вам видеть монолит, в котором часть кода на java 1.4, часть на 1.6, часть на 1.7?
И разумеется, грандиозные размеры и колоссальные инвестиции, вследствие чего и страшно и жалко.

Теперь немного конкретики.

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

База данных, которая как попало росла и множилась в течении 15 лет, в которой 10К строк pl/sql кода, 5K таблиц и еще неизвестно что, в которой непонятно кто/что использует — вот где специализация проявляется в полный рост. А если повернуть время вспять, то первая версия наверняка была разработана небольшой кроссфункциональной командой. Просто архитектура такая. Просто пока система небольшая, кажется, что следить за качеством не надо. И из ребенка вырастает неуправляемый, неуравновешанный, не пойми кто.

Дальше — больше. Команды по специализациям зачастую не ориентированы на бизнес-ценность. Не потому, что они плохие, конечно нет. Ценность несет конкретная фича. Каждой команде достается кусок технической реализации и никому фича целиком. А теперь представим команду по поддержке базы данных. На неё валится 5 фич. Причем только часть по работе с базой данных. И все эти фичи — важные и срочные. С командой бэкенда общаться некогда, от них же все и сразу ждут результат. Вообще все ждут результат от всех и в итоге никто не может договориться о решении (замкнутый круг). Что получаем? Стресс. Целью становится борьба со стрессом через «поскорее реализовать фичу хоть как-то чтобы отстали наконец эти все», а не «быстро и качественно».

Встает вопрос — с чего начать изменения? Однозначного ответа на этот вопрос найти не удастся, его просто не существует. Хотя бы потому, что все системы разные, все люди разные и бизнес-цели отличаются. Однако, высокоуровнево, именно поэтому DevOps говорит нам — культура, процессы и инструменты. Культура, где границы между silos тают, образуются команды, движимые поставкой ценности, открыто общающиеся между собой и свободно несущие свет знаний коллегам. Процессы, позволяющие координировать выпуск релизов, построить процесс непрерывной поставки, непрерывного мониторинга и улучшения. Продуктовый мониторинг позволяет командам принимать лучшие инженерные решения и проактивно реагировать на проблемы в проде. Во всем этом нам помогают инструменты автоматизации, версионирования (в том числе инфраструктуры), репликации, мониторинга и деплоймента.

Стоит акцентировать внимание, что процесс непрерывной поставки и инструмент непрерывной поставки — это не одно и то же. Если человек не умеет писать, то никакой карандаш ему в этом не поможет.

К чему я это все. К тому, что многие кровавые интерпрайзы когда-то были подобием стартапа, но не уделили должного внимания качеству, не донесли ценность до новых коллег при неменуемом росте, где-то совершили ошибки в архитектурных решениях и решили не исправлять, где-то не уследили за нерадивым code monkey. Но никогда не поздно дать второй шанс вашей системе, в мире нет невозможного и сейчас одним из наиболее «зрелых» эликсиров является как раз DevOps.


Leave a Reply