Что такое devops простыми словами
Кто такие DevOps?
На данный момент это чуть ли не самая дорогая позиция на рынке. Суета вокруг «DevOps» инженеров превосходит все мыслимые пределы, а тем хуже с Senior DevOps инженерами.
Я работаю руководителем отдела интеграции и автоматизации, угадайте английскую расшифровку — DevOps Manager. Отражает ли именно английская расшифровка нашу повседневную деятельность — вряд ли, а вот русский вариант в данном случае более точен. По роду моей деятельности, естественно, что мне, необходимо собеседовать будущих членов моей команды и, за прошедший год, через меня прошло человек 50, а еще столько же срезалось на прескрине с моими сотрудниками.
Мы все еще находимся в поиске коллег, потому как за лейблом DevOps прячется очень большая прослойка разного рода инженеров.
Все написанное ниже является моим личным мнением, вы не обязаны соглашаться с ним, однако допускаю, что внесет оттенок в ваше отношение к теме. Несмотря на риск попасть в немилость, я публикую свое мнение, поскольку считаю что ему есть место быть.
Компании по-разному понимают кто такие DevOps инженеры и ради быстрого найма ресурса вешают этот лейбл всем. Ситуация достаточно странная, поскольку компании готовы платить нереальные вознаграждения этим людям, получая за них, в большинстве случаев, админа-тулзиста.
Так кто же такие DevOps инженеры?
Давайте начнем с истории появления — Development Operations появился как еще один шаг к оптимизации взаимодействия в малых командах для повышения скорости производства продукта, как ожидаемое следствие. Идея заключалась в том, чтобы усилить команду разработки знаниями о процедурах и подходах в управлении продуктовой средой. Иными словами, разработчик должен понимать и знать как его продукт работает в тех или иных условиях, должен понимать как деплоить его продукт, какие характеристики среды подкрутить, чтобы повысить производительность. Так, в течение некоторого времени, появились разработчики с DevOps подходом. DevOps разработчики писали скрипты сборки и упаковки для упрощения своей деятельности и работоспособности продуктивной среды. Однако, сложность архитектуры решений и взаимное влияние компонентов инфраструктуры с течением времени начало ухудшать рабочие показатели сред, с каждой итерацией требовались все более глубокие понимания тех или иных компонентов, снижая продуктивность самого разработчика из-за дополнительных затрат на понимание компонентов и тюнинга систем под конкретную задачу. Собственная стоимость разработчика росла, стоимость продукта вместе с ним, резко подскочили требования к новым разработчикам в команде, ведь им необходимо было также покрывать обязанности «звезды» разработки и, естественно, «звезды» становились все менее доступны. Также стоит отметить, что, по моему опыту, мало кому из разработчиков интересна специфика обработки пакетов ядром операционной системы, правила маршрутизации пакетов, аспекты безопасности хоста. Логичным шагом было привлечь администратора, который именно с этим знаком и возложить подобного формата обязанности именно на него, что, благодаря его опыту, позволило достичь тех же показателей меньшей стоимостью в сравнении со стоимостью «звезды» разработки. Таких администраторов помещали в команду и основной его задачей было управление тестовыми и продуктивными средами, на правилах конкретно взятой команды, с ресурсами выделенными именно этой команде. Так, собственно, и появились DevOps в представлении большинства.
Частично или полностью, со временем, данные системные администраторы начали понимать потребности именно этой конкретной команды в области разработки, как упростить жизнь разработчикам и тестировщикам, как выкатить обновление и не остаться ночевать в пятницу в офисе, исправляя ошибки деплоя. Время шло, теперь «звездами» становились системные администраторы, понимающие чего хотят разработчики. С целью минимизации импакта начали подтягиваться утилиты управления, все вспомнили старые и надежные методы изоляции уровня ОС, которые позволяли минимизировать требования по безопасности, управлению сетевой части, да и конфигурации хоста в целом и, как следствие снизить требования к новым «звездам».
Появилась «замечательная» вещь — docker. Почему замечательная? Да только лишь потому, что создание изоляции в chroot или jail, равно как OpenVZ, требовало нетривиальных знаний ОС, в контру утилите позволяющей элементарно создать изолированную среду приложения на неком хосте со всем необходимым внутри и передать бразды правления разработке вновь, а системному администратору управлять только лишь одним хостом, обеспечивая его безопасность и высокую доступность — логичное упрощение. Но прогресс не стоит на месте и системы вновь становятся все сложнее и сложнее, компонентов все больше и больше, один хост уже не удовлетворяет потребностям системы и необходимо строить кластеры, мы вновь возвращаемся к системным администраторам, которые способны построить данные системы.
Цикл за циклом, появляются различные системы упрощающие разработку и/или администрирование, появляются системы оркестрации, которые, ровно до тех пор, пока не требуется отойти от стандартного процесса, просты в использовании. Микросервисная архитектура также появилась с целью упрощения всего описанного выше — меньше взаимосвязей, проще в управлении. В своем опыте я не застал полностью микросервисную архитектуру, я бы сказал 50 на 50 — 50 процентов микросервисов, черные коробки, пришло на вход, вышло обработанное, другие 50 — разодранный монолит, сервисы неспособные работать отдельно от других компонентов. Все это вновь наложило ограничения на уровень знаний как разработчиков, так администраторов.
Подобные «качели» уровня экспертных знаний того или иного ресурса продолжаются и по сей день. Но мы немного отвлеклись, есть немало моментов которые стоит осветить.
Build Engineer/Release Engineer
Весьма узкоспециализированные инженеры, появившиеся как средство стандартизации процессов сборки ПО и его релизов. В процессе введения повального Agile казалось бы они перестали быть востребованы, однако это далеко не так. Эта специализация появилась как средство стандартизации именно сборки и поставки ПО в промышленных масштабах, т.е. используя стандартные техники для всех продуктов компании. С появлением DevOps разработчиков частично утратили функции, поскольку именно разработчики стали подготавливать продукт к поставке, а учитывая изменяющуюся инфраструктуру и подход в максимально быстрой поставке без оглядки на качество со временем превратились именно в стопор изменений, поскольку следование стандартам качества неизбежно замедляет поставки. Так, постепенно, часть функционала Build/Release инженеров перекочевала на плечи системных администраторов.
Ops’ы такие разные
DevOps — (в теории) персона, не понаслышке понимающая все процессы цикла разработки — разработку, тестирование, понимающая архитектуру продукта, способная оценить риски безопасности, знакомая с подходами и средствами автоматизации, хотя бы на высоком уровне, помимо этого понимающая также пред и пост-релизную поддержку продукта. Персона способная выступать адвокатом как Operations, так Development, что позволяет выстроить благоприятное сотрудничество между этими двумя столпами. Понимающая процессы планирования работ командами и управления ожиданиями заказчика.
Для выполнения подобного рода работ и обязанностей данная персона должна иметь средства управления не только процессами разработки, тестирования, но и управления инфраструктурой продукта, а также планирования ресурсов. DevOps в данном понимании не может находится ни в IT, ни в R&D, ни даже в PMO, он должен иметь влияние во всех этих областях — технический директор компании, Chief Technical Officier.
Так ли это в вашей компании? — Сомневаюсь. В большинстве случаев это или IT, или R&D.
Недостаток средств и возможности влияния хотя бы на одно из этих трех направлений деятельности произведет смещение веса проблем в сторону где эти изменения проще применить, как например применение технических ограничений на релизы в связи с «грязным» кодом по данным систем статического анализатора. То есть когда PMO устанавливает жесткий срок на выпуск функционала, R&D не может выдать качественный результат в эти сроки и выдает его как может, оставив рефакторинг на потом, DevOps относящийся к IT, техническими средствами блокирует релиз. Недостаток полномочий на изменение ситуации, в случае с ответственными сотрудниками ведет к проявлению гиперответственности за то, на что они не могут повлиять, тем паче если эти сотрудники понимают и видят ошибки, и как их исправить — «Счастье в неведении», и как следствие к выгоранию и потери этих сотрудников.
Рынок DevOps ресурсов
Давайте рассмотрим несколько вакансий на позицию DevOps от разных компаний.
Резюмируя по данной вакансии можно сказать, что ребятам достаточно Middle/Senior System Administrator.
Кстати, не стоит сильно разделять админов на Linux/Windows. Я конечно понимаю, что сервисы и системы этих двух миров различаются, но основа у всех одна и любой уважающий себя админ знаком как с одним, так и с другим, и даже если не знаком, то для грамотного админа не составит труда ознакомится с этим.
Рассмотрим иную вакансию:
Резюмируя — Middle/Senior System Administrator
Хотелось бы также оставить ремарку относительно 3 пункта, дабы укрепить понимание, почему этот пункт покрывается сисадмином. Kubernetes всего лишь оркестрация, тулза которая оборачивает прямые команды драйверам сети и хостам виртуализации/изоляции в пару команд и позволяет сделать общение с ними абстрактным, вот и все. Для примера возьмем ‘build framework’ Make, коего фреймворком я, к слову, не считаю. Да, я знаю про моду пихать Make куда угодно, где нужно и не нужно — обернуть Maven в Make например, серьезно?
По сути Make просто обертка над shell, упрощающая именно команды компиляции, линковки, окружения компиляции, так же как и k8s.
Однажды, я собеседовал парня, который использовал k8s в своей работе поверх OpenStack, и он рассказывал как развертывал сервисы на нем, однако, когда я спросил именно про OpenStack, оказалось, что он администрируется, равно как и подымается системными администраторами. Вы правда думаете, что человек поднявший OpenStack вне зависимости от того какую платформу он использует позади него не способен использовать k8s?=)
Данный соискатель на самом деле не DevOps, а такой же Системный Администратор и, чтобы быть точнее, Kubernetes Administrator.
Резюмируем в очередной раз — Middle/Senior System Administrator им будет достаточно.
Сколько вешать в граммах
Разброс предлагаемых зарплат для указанных вакансий — 90к-200к
Теперь хотелось бы провести параллель между денежными вознаграждениями Системных Администраторов и DevOps Engineers.
В принципе, для упрощения можно грейды по опыту работы раскидать, хоть это и не будет точным, для целей статьи хватит.
Сайт поиска сотрудников предлагает:
System Adminsitrators:
По стажу «DevOps»’ов использовался стаж, хоть как то затрагивающий SDLC.
Из вышеозначенного следует, что на самом деле компаниям не нужны DevOps’ы, а также что они могли сэкономить не менее 50 процентов от изначально запланированных затрат, наняв именно Администратора, более того, они могли бы четче определить обязанности искомого человека и быстрее закрыть потребность. Не стоит также забывать, что четкое разделение ответственности позволяет снизить требования к персоналу, а также создать более благоприятную атмосферу в коллективе, ввиду отсутствия пересечений. В подавляющем большинстве вакансии пестрят утилитами и DevOps лейблами, однако не имеющие в основе действительно требования к DevOps Engineer, лишь запросы на тулзового администратора.
Процесс обучения DevOps инженеров также ограничен лишь набором специфичных работ, утилит, не дает общего понимания процессов и их зависимостей. Это конечно хорошо, когда человек может используя Terraform задеплоить AWS EKS, в связке с Fluentd сайд-каром в этом кластере и AWS ELK стеком для системы логирования за 10 минут, используя лишь одну команду в консоли, но если он не будет понимать сам принцип обработки логов и для чего они нужны, не знать как собирать метрики по ним и отслеживать деградацию сервиса, то это будет все тот же эникей, умеющий использовать некоторые утилиты.
Спрос, однако, порождает предложение, и мы видим крайне перегретый рынок позиции DevOps, где требования не соответствуют реальной роли, а лишь позволяют системным администраторам зарабатывать больше.
Так кто же они? DevOps’ы или жадные системные администраторы? =)
Как дальше жить?
Работодателям — точнее формулировать требования и искать именно тех кто нужен, а не разбрасываться лейблами. Вы не знаете чем занимаются DevOps — они вам не нужны в таком случае.
Работникам — Учиться. Постоянно совершенствовать свои знания, смотреть на общую картину процессов и отслеживать путь к поставленной цели. Можно стать кем захочешь, надо лишь постараться.
Кто такой DevOps-инженер, что он делает, сколько зарабатывает и как им стать
DevOps-инженеры — это многопрофильные специалисты, которые умеют автоматизировать процессы и знают, как работают разработчики, QA и менеджеры. Они умеют программировать, быстро осваивают сложные инструменты и не теряются перед незнакомой задачей. DevOps-инженеров мало — им готовы платить по 200–300 тысяч рублей, но вакансий всё равно много.
Дмитрий Кузьмин рассказывает, чем конкретно занимается DevOps и что нужно изучить, чтобы претендовать на такую должность. Бонусом — важные ссылки на книги, видео, каналы и профессиональное сообщество.
Чем занимается DevOps-инженер
В ситуации с DevOps важно не путать термины. Дело в том, что DevOps — это не какое-то конкретное направление деятельности, а профессиональная философия. Это методология, которая помогает разработчикам, тестировщикам и системным администраторам работать быстрее и эффективнее за счёт автоматизации и бесшовности.
Соответственно, DevOps-инженер — это специалист, который внедряет эту методологию в процесс работы:
Всё, что написано выше, происходит в близких к идеальным проектах. В реальном же мире приходится стартовать в проекте, где планирование пропустили, с архитектурой ошиблись, а об автоматизации задумались, когда все проекты встали. И разобраться во всех этих проблемах, решить их и сделать так, чтобы всё работало — ключевой навык DevOps-специалиста.
На рынке кадров есть путаница. Иногда бизнес ищет DevOps-инженеров на позицию системного инженера, билд-инженера или кого-то ещё. Обязанности в зависимости от размера компании и направления тоже меняются — где-то ищут человека на консалтинг, где-то просят всё автоматизировать, а где-то требуют выполнять расширенные функции системного администратора, умеющего программировать.
Что нужно для старта в профессии
Вход в профессию требует предварительной подготовки. Просто прийти на курсы с нуля, ничего не понимая в IT, и выучиться до уровня junior не получится. Нужен технический бэкграунд:
Что должен знать DevOps
Хороший DevOps-инженер — это многопрофильный специалист с очень большим кругозором. Для успешной работы вам придётся разобраться сразу в нескольких IT-направлениях.
Разработка
DevOps напишет скрипт, который поможет разработчикам устанавливать код на сервер. Сделает программу, которая «на лету» тестирует отзывчивость баз данных. Напишет приложение для контроля за версионностью. Наконец, просто заметит потенциальную проблему в разработке, которая может появиться на сервере.
Сильный DevOps-специалист знает несколько языков, подходящих для автоматизации. Разбирается в них не досконально, но быстро напишет небольшую программу или прочитает чужой код. Если раньше с разработкой не сталкивались, начните с Python — у него простой синтаксис, на нём легко работать с облачными технологиями, есть много документации и библиотек.
Операционные системы
Знать все возможности каждой версии каждой системы невозможно — на такое обучение можно потратить тысячи часов и толку не будет. Вместо этого хороший DevOps понимает общие принципы работы на любой ОС. Хотя, судя по упоминаниям в вакансиях, большинство сейчас работают в Linux.
Хороший инженер понимает, в какой системе лучше разворачивать проект, какими инструментами пользоваться и какие потенциальные ошибки могут появиться в процессе внедрения или эксплуатации.
Облака
Рынок облачных технологий растёт в среднем на 20-25% в год — такая инфраструктура позволяет автоматизировать операции тестирования кода, сборки приложений из компонентов, доставки обновлений до пользователей. Хороший DevOps разбирается как в полностью облачных, так и в гибридных решениях.
В стандартных же требованиях к инженерам обычно значится GCP, AWS и Azure.
Сюда можно отнести и владение инструментами CI/CD. Обычно для непрерывной интеграции используется Jenkins, но стоит попробовать и аналоги. Их много, например, Buddy, TeamCity и Gitlab CI. Полезным будем изучить Terraform — это декларативный инструмент, помогающий удалённо поднимать и настраивать инфраструктуру в облаках. И Packer, который нужен для автоматического создания образов ОС.
Системы оркестрации и микросервисы
У микросервисной архитектуры есть много преимуществ — стабильность, возможность быстрого масштабирования, упрощение и повторные использования. DevOps понимает, как работают микросервисы, и может предупредить потенциальные проблемы.
Досконально знает Docker и Kubernetes. Понимает, как работают контейнеры, как строить систему так, чтобы можно было отключать часть из них без последствий для общей системы в целом. Например, умеет построить Kubernetes-кластер при помощи Ansible
Что ещё попробовать будущему DevOps
Перечислять инструменты, которые могут пригодиться в работе DevOps-инженеру, можно бесконечно. Кто-то работает над оркестрацией проектов, другие большую часть времени занимаются автоматизацией развёртывания и тестирования, третьи повышают эффективность в управлении конфигурациями. В процессе будет понятно, куда копать и какие проекты пригодятся.
Вот ещё небольшой минимум, который поможет на старте:
Почему стоит начать изучать DevOps сейчас
На рынке DevOps-инженеров — кадровый голод. Это условно подтверждается количеством и качеством вакансий:
Обратите внимание на зарплатные требования соискателей
Не меньше востребован DevOps и в мире — если вы собрались на релокацию в США или Европу, то только на портале Glassdoor таких специалистов ищут больше 34 тысяч компаний. Из частых требований — опыт 1–3 года, умение работать с «облаками» и не бояться консалтинговых функций.
На фрилансе предложений в разы меньше — DevOps-инженеров в основном ищут в штат и на полный день.
Найти подходящий проект на фрилансе сложно, но можно
Условный карьерный путь DevOps-инженера можно представить примерно так:
DevOps — это сложно. Нужно сочетать в себе навыки сразу нескольких профессий. Стать человеком, который готов предложить улучшение там, где другие IT-специалисты даже не думают о чем-то другом. За это много платят, но и объем знаний потребуется большой.
Сколько зарабатывают DevOps
Средняя медианная зарплата по данным за второй квартал 2019 года у девопсов находится в вилке между 90 и 160 тысячами рублей. Есть предложения дешевле — в основном 60–70 тысяч.
Постоянно есть предложения до 200 тысяч, встречаются вакансии с зарплатой до 330 тысяч рублей.
Среди специалистов по эксплуатации DevOps оплачивается выше остальных. Источник: Хабр.Карьера
DevOps-инженеры, в том числе начинающие, сейчас требуются в крупные банки, корпорации, облачные сервисы, торговые системы и другие организации, которые заботятся о поддержании своих IT-решений.
Отличным кандидатом на младшую вакансию с зарплатой в 60–90 тысяч станет начинающий системный администратор с опытом около года и профильным дипломом.
Такой статистики нет, но по ощущениям, людям, у которых есть опыт в Linux, платят больше
Что смотреть и читать для роста в профессии
Чтобы погрузиться в мир DevOps, попробуйте сразу несколько источников информации:
Где учиться на DevOps
Получить структурированные знания можно на курсе «DevOps-инженер» в Нетологии. Вы научитесь полному циклу методологии:
DevOps: о самом важном. Часть 1. Про то, о чем мало говорят
Привет! Меня зовут Каро Манасян, я Chief DevOps Officer Московской биржи, и сегодня мы поговорим про… DevOps. Вокруг этого слова поднят такой уровень хайпа, что каждый интерпретирует его, как хочет. То ли это методология, то ли культура, то ли человек… Однако, на данный момент это понятие можно систематизировать и, не побоюсь этого слова, получить некоторую хрестоматию, так как с момента появления этой формы процессов разработки прошло достаточно много времени и можно все самое важное собрать в одном месте.
Давать классические определения DevOps или xOps не буду, так как на просторах habr достаточно много материала на эту тему. Я же не хочу, чтобы ты еще раз почитал, что DevOps – это «методология, направленная на ускорение процессов разработки…» Скучно 😄 Поэтому статья будет построена таким образом, чтобы ты узнал некоторые важные аспекты DevOps, о которых никто не упоминает в разговорах, а еще понял, как применить его здесь и сейчас (или с чего начать этот процесс в большой корпорации). Будет две части: в первой мы поговорим про soft-направления, такие как коммуникации, качество информации и единые цели, а во второй – про hard: технологии, разработку, CI/CD, архитектуру, тестирование и метрики.
Трехзвенная модель DevOps
Состав модели я поделил на 3 слоя:
Информация и коммуникации
Основой всего и вся является информация и связи между объектами, которые мы называем коммуникацией. Залогом успеха любого процесса или конвейера считаются правильно выстроенные коммуникации, где поток информации имеет высокий уровень качества.
Если каждый член команды или подразделение компании имеют разные цели (в глобальном смысле слова), то все остальные практики не будут иметь никакой ценности. Вспомните известную басню «Лебедь, рак и щука», которая отлично показывает, что бывает, когда каждый тянет в свою сторону, а работа с места не двигается, даже если у тележки есть прекрасные колеса.
После коммуникаций и единой цели, технологии являются тем компонентом, которые упрощают и ускоряют процессы (про это – во второй части статьи).
Отличным практическим примером приведенной мной модели является опыт Сергея Павловича Королева, гения и основоположника отечественной космонавтики. Я всегда привожу именно его пример, так как создание космических аппаратов является очень сложной задачей с высокими рисками и неопределенностью. К тому же многих методологов и экспертов обвиняют в том, что они рассказывают теорию и в реальной жизни так не бывает, а опыт Сергея Павловича показывает обратное.
Итак, перед ним стояла задача создать первый космический пилотируемый корабль. Первым делом он объединил рабочих и проектировщиков в одну команду, так как не признавал делений и ограничений между разными ведомствами и подразделениями. Это позволило значительно упростить и ускорить обмен информацией между командами: согласитесь, быстрее и легче договориться с человеком, если он рядом. После этого он определил главную цель для всех – построить безопасный и качественный корабль. А затем применил некоторые технологии, которые позволили ускорить процессы разработки и исключить человеческий фактор. Отметим также фигуру самого Королева – он был настоящим лидером, который заряжал всех вокруг своими идеями и взглядами, а также умел набирать в команду поистине лучших. Конечно, это не все практики и подходы, но определяющую роль в этой задаче играла именно эта модель.
Коммуникации, или научите всех общаться
Что такое качество информации?
Обычно под качеством информации понимают набор свойств и характеристик, которые позволяют использовать ее эффективно и с низкими временными, человеческими и материальными ресурсами на ее обработку для получения ценности. Представим простой технический пример, где есть звено, обрабатывающее входящий звук. Чем больше помех и шумов в звуке, тем хуже будет выходной сигнал. Конечно же, сегодня различные технические решения позволяют обрабатывать практически любой сигнал, но ресурсы, потраченные на эту операцию, могут быть неоправданными. Качество информации можно измерить соотношением количества обратно возвращенных артефактов к количеству передач информации с одного звена в другое. Под артефактом мы понимаем некоторый результат, который получается в конце каждого этапа, готовый к передаче на следующее звено для обработки. Представим схему, на которой отображены 3 этапа:
Как видно из схемы, артефакты перемещаются между этапами слева направо, и одна из важнейших задач – минимизировать число возвратов артефакта на предыдущий этап для дополнительной доработки. Идеально, если таких возвратов не будет. Это будет означать, что все участники процесса понимают не только контекст своей задачи, но и контексты смежных этапов. Поэтому очень важно до внедрения CI/CD и всего инженерного нормализовать информацию, ее качество, структуру и восприятие. Говоря простым языком, стремитесь получать всегда максимально завершенный и понятный артефакт, который будет готов к обработке последующими звеньями. Как это понять? Очень просто – собирайте обратную связь от коллег.
Инженерная культура и сообщества
Важную роль в построении DevOps в компании играет фактор готовности людей к изменениям. Процесс внедрения новых практик в разы усложняется, если члены команд не готовы принять их или не понимают целей. Чтобы не допустить этого, необходимо ввести практику непрерывного обучения и повышения технической зрелости людей и команд. Любой новый инструмент или новый подход должны быть четко описаны и презентованы командам. Очень часто ошибочно делается акцент на инструментах и на процессах, но на самом деле на переднем плане в DevOps — люди, которые должны понимать, зачем и для каких целей внедряются те или иные паттерны.
Один из самых действенных вариантов упрощения коммуникаций и повышения осведомленности команд о новых практиках и подходах – это организация сообществ по направлениям. При этом нужно учесть, что сообщество должно иметь всегда:
четко определенные цели и повестку;
Развитие сообществ — это не задача одного дня или месяца. Это долгая и последовательная работа лидеров и заинтересованных людей. И здесь как раз начинает формироваться инженерная культура без выделения отдельных «DevOps-команд».
На Московской Бирже IT-сообщества — это объединение людей, связанных общими интересами и целями по технологическим практикам и подходам, направленным на ускорение принятия решений, сокращение времени доставки ценностей, а также развитие экспертизы сотрудников, обучение и личностный рост Сейчас мы находимся на начальном этапе создания сообществ и в будущем выпустим отдельную статью про наши достижения и успехи.
Мы у себя выделили 4 основных задачи в рамках развития инженерной культуры и сообществ. Их решения четко показывают системный подход, когда DevOps – не один человек отвечающий за все, а каждый айтишник в компании.
Единая цель, или куда мы идем
Стратегия DevOps-трансформации, или как двигать в правильном направлении
Блок единой цели я решил начать именно со стратегии DevOps в больших компаниях и это неспроста. Обычно мы привыкли под стратегией понимать некий большой и «страшный» документ, где описан план развития компании. Но в случае с DevOps это некоторое видение и шаги, как компания с точки А придет в точку Б. Без этого, мы получаем, как правило, эффект «слепых улучшений», когда бесконечно внедряем практики DevOps, но на что они влияют и какую ценность несут – не знаем.
Первая моя стратегия DevOps, которую я отправил CIO состояла из одной странички, где была показана текущая картина, картинка to-be с переходом на платформенную модель и тезис, какую это несет в себе пользу и ценности. В дальнейшем эту структуру as is/to be нужно детализировать до конкретных команд, шагов и местами технологий. Важно подчеркнуть, что на Мосбирже такая стратегия является частью ИТ-стратегии и тесно связана с ней. Если у вас в компании со стороны CIO и менеджмента нет целей трансформации в сторону DevOps, то ваша стратегия не сможет ни на что повлиять, и это будет подход «снизу», который, как правило, не работает или работает частями.
Один из самых распространенных вопросов на тему стратегий – это «Кто должен ее написать?» Составлять такой план должна роль, равноудаленная от подразделений разработки и сопровождения. В противном случае оценка текущего состояния может быть необъективной. Но при этом в составлении так или иначе принимают участие лидеры команд для получения более точной картины. Если рассматривать пример Московской биржи, то эту роль на себя взял новый Департамент по производственным процессам и инновациям, куда в свою очередь вошла команда DevOps-платформы.
Оргструктура и платформы
С вопросом, кто должен составить стратегию, мы разобрались, теперь давайте поймем, с чего начать блок as is. По моему мнению, оценка текущего состояния должна начинаться с организационной структуры, которая предполагает получение наглядного представления основных единиц. Данный этап позволит не только понять, как устроена структура, но и установить все связи между подразделениями. Иными словами, мы должны получить некую текущую карту со всеми взаимосвязями. Выше мы говорили про качество информации и коммуникаций, и здесь как раз мы смотрим на реальные связи, которые в конечном счете выдают ценность. Задача, на самом деле непростая, хотя, на мой взгляд, очевидная, но традиционные организационные диаграммы не помогают понять, каковы фактические модели коммуникации в вашей организации.
Чтобы получить такую картину необходимо обрисовать текущую структуру, формальную и далее на эту схему спроецировать фактическую схему взаимодействия с неформальной точки зрения, которая способствует созданию новых ценностей в компании. Представим 2 команды: разработка и сопровождение.
Однозначно можно сказать, что если мы рассматриваем весь поток создания некоторой ценности, то в отдельности – без взаимодействия и неформальной структуры – эти команды не смогут способствовать созданию продукта. Именно поэтому мы на формальную структуру наносим все взаимосвязи между разными людьми и командами, которые можно объединить в «круги создания ценностей».
Такую модель можно брать за основу для оценки текущего состояния структуры, которая поможет правильно определить вектор и тип стратегии по DevOps-трансформации. Подчеркну очень важный момент: к этому процессу нужно подходить масштабно и системно, по всей организации, так как локальные оптимизации отдельно взятых подразделений или групп помогают непосредственно вовлеченным сотрудникам и командам, но не помогают улучшить общую доставку ценности конечным клиентам. Их влияние на всю цепочку доставки ценностей может быть незначительным (в каких-то случаях даже отрицательным), если в процессе доставки имеются более серьезные узкие места (чуть дальше мы поговорим про это в контексте Value-Stream Mapping – VSM). Например, если команды внедряют подходы CI, инфраструктуру как код, решения контейнеризации, оркестрации или «умный» мониторинг, это может сократить время подготовки инфраструктуры или тестовых полигонов с нескольких месяцев или недель до нескольких часов или минут. Но если при этом каждое изменение требует долгих согласований или утверждений с разными уровнями руководителей, которые собираются раз в неделю или раз в месяц, то ценности будут доставляться в лучшем случае еженедельно, или же скорость вообще останется на прежнем уровне. Поэтому повторю еще раз: прежде чем внедрять разного рода практики и технологии, необходимо понять и изменить организационную структуру, культуру и взаимодействия таким образом, чтобы они способствовали результативному внедрению технологий, паттернов и подходов.
Чтобы этот раздел был полным, давайте поговорим про платформы. Сейчас практически все мировые IT-издания пишут, что создание платформ в больших компаниях значительно ускоряет и улучшает процессы и продукты. И в эту же историю сейчас идут компании при масштабировании DevOps. Почему такой подход кардинально отличается от подхода «DevOps-команды»? Инфраструктура как сервис, которая имеет готовые автоматизированные инструменты управления внутренними сервисами, является ядром платформенной модели. При таком видении предполагается, что любой разработчик и член команды сможет по нажатию кнопки получить нужный ему ресурс и начать разработку. Само слово «платформа» означает некоторый слой, над которым строятся производственные процессы, в отличие от «DevOps-команды», которая является частью и звеном производственного процесса. Рекомендую почитать книгу Team Topologies: Organizing Business and Technology Teams for Fast Flow. Там очень хорошо описаны эти аспекты.
Каждая компания может по-своему создавать платформы. Вот один из примеров структуры с DevOps-платформой, которая состоит из:
команды сложной подсистемы или complicated subsystem team;
департамента разработки(dev) с продуктовыми командами;
департамента информационной безопасности;
команда-драйвер всего процесса.
И здесь мы видим, что команда платформы не имеет интеграций в команды разработки, а наоборот, является для них boost-площадкой, где есть все самое нужное.
Чтобы такая история полетела в правильном направлении, платформа должна обладать некоторыми свойствами, а именно:
обязательно давать возможность продуктовым командам (stream-aligned), выполнять работу с существенной автономией от команды платформы;
команда платформы должна относиться к сервисам, которые она предлагает, как к продуктам, которые должны быть удобными, понятными и легкими в использовании;
платформа создается для разработчиков и инженеров. Они являются клиентами для команды платформы, поэтому вы должны учесть их особенности и хотелки. И конечно же обращать внимание на UX/DevEx, чтобы решениями было приятно пользоваться;
масштабирование DevOps должно происходить по всей организации, а не только в небольших частях;
непрерывная обратная связь от команд: развитие, основанное на информации от конечных пользователей;
культура постоянного экспериментирования и обучения всех команд;
платформенная модель должна быть направлена на сокращение стоимостей разработки, сопровождения и выпуска релизов. Насколько именно – определяется в рамках метрик для каждой из команд.
Командообразование и лидерство
Давайте попробуем взглянуть на термин командообразования с точки зрения одной из основ DevOps. Эта основа нам говорит, что когда-то давно, были раздельные команды разработки и сопровождения, между ними были высокие и толстые стены, через которые они занимались перекидыванием софта, в какой-то момент эту стену сломали и получился DevOps. Окей, а как это сделать? В начале статьи мы как раз говорили про культуру и сообщества, которые сильно влияют на все команды и помогают им стать сильнее, но когда мы говорим про отдельно взятые команды, то здесь необходимы чуть другие подходы, которые смогут повысить результативность и командный дух, а также сформировать у них общие навыки работы в команде. Гугл мне подсказал, что «командообразование» – это бизнесовый термин, который используется в рамках создания и повышения эффективности команд. Тогда получается, что тимбилдинг — это набор инструментов, которыми сломали ту самую стену между dev и ops.
Процесс командообразования можно поделить на много частей, но основных – семь. Это:
формирование единой цели для команды;
повышение ответственности за весь продукт и результат у каждого члена команды;
совместное выполнение задач;
быстрый шаринг информации;
1-2-1 митинги и получение обратной связи;
повышение доверия между членами команды.
Центральный игрок в командообразовании – это лидер команды. Он должен постоянно поддерживать этот процесс и применять новые техники. Но многим руководителям мешают личные составляющие: гордость, страх набирать в команду людей, сильнее самого себя, неумение говорить «спасибо» и хвалить коллег, а также признавать собственные ошибки. Я привел всего несколько примеров, но весьма показательных, так как уверен, что именно они порой не дают команде состояться, а также найти линии продуктивной коммуникации и работы с другими подразделениями. Прежде чем ты пойдешь дальше по статье, послушай рецензию от Максима Лапина (CFO Московской Биржи) на книгу “Окружи себя лучшими” и поймешь, почему команда должна состоять из лучших.
Командообразование и лидерство являются важнейшей составляющей в практиках DevOps, именно поэтому параллельно рисованию стратегий, топологий и планов нужно учесть фактор командообразования и способы, которые помогут сделать этот процесс лучше.
VSM: карта потока ценностей
Value-stream mapping или карта потока ценностей позволяют найти в процессах проблемы и уязвимые точки. В целом можно сказать, что весь DevOps (имею в виду знак бесконечности) представляет из себя VSM. Говоря простым языком, если мы возьмем любой процесс, разложим на мелкие кубики или подпроцессы, выставим им исполнителей и определим начальную и конечную цели, то получим карту потока ценностей. Запрос VSM в интернете выдает очень много разных результатов, иногда даже пугающих и непонятных. С первого взгляда может показаться, что создание таких карт может быть весьма трудозатратным процессом, но на самом деле это не так, если начать с самого простого. Возьмите очень маленький кейс, выявите контекст и цели, расскажите про это всей команде и сделайте наброски на бумаге. Все, ваш первый VSM готов, и по нему уже можно сделать выводы и найти проблемные точки. Как раз такие VSM должны стать частью вашего плана по масштабированию DevOps.
Выводы
Качество информации и коммуникаций – наше все. Научите людей общаться и строить взаимоотношения, а руководителей – быть лидерами, которые набирают в команду сильнейших. Те самые soft-skills, которые я перечислил, развивать сложнее всего, но DevOps в первую очередь именно про это, а не только про CI/CD и про то, как задеплоить свой сервис в k8s, о чем сейчас много говорят и пишут. Я очень часто убеждаюсь в том, что всякие hard-задачи легко решить, когда люди и команды умеют общаться и поддерживать хорошую атмосферу. В свою очередь, это позволит создать крутую и сильную инженерную культуру в компании. Согласен, вещи очевидные, но далеко не все об этом говорят и обращают на них внимание. У меня у самого не всегда получается, но я стараюсь 😉.
Следующий важный блок – это стратегия и видение, которые должны описывать, где вы сейчас и к чему должны прийти с указанием стримов создания ценности (VSM), на которые направлена будет ваша стратегия. Те практики и мысли, про которые мы сегодня поговорили в статье, сейчас активно развиваются и совершенствуются на Московской бирже. Мы активно усиливаем инженерную культуру, создаем крутые продукты и сервисы, которые являются уникальными во всем мире.
На этом я заканчиваю первую часть большого материала по DevOps. Во второй части, которая выйдет чуть позже, расскажу про технологии и процессные паттерны, которые мы используем, а также о том, что из них работает отлично, а что не очень.