Роль DevOps (менеджера) в организации

С одной стороны роль DevOps (менеджера) одна из самых важных в современной организации, в наше время экономики скорости (Economy of Speed, Death by Efficiency Is Slow and Painful). Ведь DevOps (как роль) отвечает за то, чтобы компания как можно быстрее и, главное, стабильнее вносила изменения в существующие продукты и доставляла их клиенту в готовом виде. Даже есть мнение, что именно их задача сделать так, чтобы всё работало на конце клиента.

В идеале поставка клиенту (от момента внесения последних изменений разработчиками) должна происходить по принципу “холодной и темной фабрики”, т.е. полностью автоматизированна (холодной и темной потому, что “роботам” не нужен свет и тепло, они могут работать и в темноте). Это задача DevOps.

С другой стороны, такие DevOps не работают над своими продуктами, а помогают другим руководителям быстрее и качественнее доставлять их продукты конечным потребителям. Исполнители такого DevOps менеджера работают непосредственно с командами руководителей продуктов (как бизнес, так и IT). И на нем сконцентрировано внимание многих служб, ожидающих от него результата. Ведь без технологий сейчас невозможно обслуживать клиентов с ожидаемой скоростью и качеством.

Зона ответственности DevOps (менеджера)

Получается, что DevOps действительно находится в центре переплетения всего и вся в организации.

Но где же будет его зона ответственности? Я не согласен, что его ответственность “чтобы всё работало на конце клиента”. Такая ответственность обычно только у руководителей, которые работают напрямую с клиентами (клиентами банка), именно они принимают на себя весь “огонь”. Вернее их подчиненные (скажем, кассиры/менеджеры по работе с клиентами/c кредитами…, работающие непосредственно с клиентом в зале). А уже потом сами руководители.

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

Получается очень организационно сильная позиция. Но с другой такой DevOps постоянно тушит пожары (чужие) и огребает в чужой зоне ответственности. Как можно это понять? Легко. Спросите у него кто получает нагоняй (и главное от кого) если что-то не работает? А потом кто получает поощрения и премии (и опять от кого?), когда все работает как часы? Сильно сомневаюсь, что наш DevOps.

DevOps как владелец чего-то end2end

Как такой DevOps может стать ответственным за свою работу и только за нее? Получая поощрения и премии за хорошую работу и не получая нагоняи за чужие просчеты? Ниже – один из вариантов ответа. Мне кажется, что он единственный, но who knows.

Для этого DevOps (менеджер) должен:

1) Выделить из своей работы платформу, перевести на нее все отделы с которыми он работает. Перевести с помощью своей команды.

2) Структурировать свой отдел на платформенную команду отдельно (со всеми метриками и показателями, особенно финансовыми) и на интеграторов отдельно (их структурировать в соответствии со структурой тех кто платформой пользуется). Платформенная команда будет заниматься поддержкой и развитием платформы, а команда интеграторов будет по-старинке помогать отделам, но на платформе.

3) На 3м этапе передать интеграторов в отделы, которые платформой пользуются, а у себя оставить только ту часть интеграторов (“enablement team”), которая бы онбордила новые отделы и помогала внедрять новые элементы платформы и выпиливать старые.

4) Отвечать только за платформу, ее развитие и ее метрики. Метрики доступности, надежности, отказоустойчивости. И, конечно же, метрики стоимости. А еще полезно собирать информацию о пользователях платформы. Как часто и как полно они ей пользуются, дружить с лояльными пользователями и делать из их успехов Case Studies и показывать их. В общем делать все то, что делает грамотный Product Manager.

Вот только тогда DevOps будет владеть чем-то end2end. Своей платформой.

Под платформой я имею ввиду вот это: https://martinfowler.com/articles/talk-about-platforms.html Именно из такой платформы появился AWS клауд.

Что конкретно делать и куда вести свою DevOps платформу?

Об этом написано десятки книг, масса статей и видео в интернете. Есть пример Public Clouds – того идеала к которому нужно стремиться. Полный Self-service для ваших пользователей. Причем нам сейчас проще. Можно выбрать из тех же Public Clouds и других доступных технологий.

Процессы, зоны ответственности, так же можно взять из книг и методологий – это не так принципально. Вы все равно в первый раз ошибетесь, важно умение учиться и исправлять свои ошибки (помните: стратегия – ничто, стратегирование – все).

Одна из таких книг – это учебник Системной Инженерии (от ШСМ). В нем (а далее учебнике Системного Менеджмента эта мысль разворачивается дальше) про DevOps/SRE/platform engineering говорится достаточно много. Про то как определить границы систем и платформы, как организовать работу людей, какие компетенции нужны.

Но есть маленькая проблемка. Она даже не в том, что именно технически делается внутри DevOps, а как это все вписывается в общую работу фирмы. В этом вся сложность. Мало понимать как надо и где место DevOps на предприятии: “DevOps вот тут, занимается вот таким”.

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

Как таким стать или как его найти – читаем дальше.

Но подожди, как всех вокруг договорить?

Получается, что мало знать куда мы хотим придти, это только половина дела. Да, Системная Инженерия и Системный менеджмент (и другие книги) дают ответы на то как нужно. Еще важно именно договорить всех вокруг себя. А это сильно непросто.

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

По сути, DevOps сталкиваются ровно с той же проблемой, с которой сталкиваются при внедрении любой IT системы уровня предприятия:

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

б) Инвентаризация, каталогизация и шире “configuration management” оставляет желать лучшего. Snowflake configuration антипаттерн как один из аспектов.

Поэтому такие решения должны приниматься на уровне CIO/CTO или хотя бы на уровне portfolio manager (portfolio в терминах SAFe, например). Нужно с ними договариваться, у них брать бюджеты, от них получать авторитет и право вносить изменения на уровне каждой подсистемы предприятия или подсистемы portfolio.

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

Дашборд и уровни зрелости должны быть предоставлены нашим DevOps менеджером.

В итоге оказывается, что тут вопрос по мотивации и стратегии организации. Такие изменения не сделать предварительно не разобравшись в лидерстве и стратегировании (или не пройдя предварительно курс Системного Менеджмента и Стратегирования).

Т.е. да, у ШСМ есть ответы. Но пройти этот путь нужно каждому самостоятельно.

И да, идеально, чтобы системный инженер был в должности CTO (директора по развитию) – ему проще всех договаривать.

Заключение

Еще я бы добавил, что далеко не на всех предприятиях, где “созрела необходимость”, эту необходимость понимают на уровне разработки стратегии. Зачастую проще и безопаснее, чтобы работники продолжали работать по-старому. “Работает ведь? Ч0 париться-то?”. Да и репутация не страдает в случае неудачи. Ведь всегда так делали-то.

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

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