Честный диалог о DevOps

ММ: Сегодня поговорим про DevOps в разных контекстах, и начнем с того, что понимается под термином DevOps. Общаясь с клиентами, мы видим рассинхронизацию. Одна компания под DevOps понимает продвинутый уровень системного администрирования серверов на базе Linux. А другая – культуру, которая должна принести бизнес-ценность в виде сокращения time to market; сложный процесс с множеством шагов, где задействовано много команд, включая команду разработки, тестирования, сопровождения инфраструктуры, защиты ИТ-инфраструктуры.

РД: В моем понимании DevOps – это прежде всего культура, набор методологий, best practice и всего, что с этим связано. Каждый включает в эти практики свой пул инструментов и решений, и чем они лучше, тем лучше получится DevOps в компании. Но в целом это набор инструментов и практик, которые позволяют программный продукт выводить на рынок максимально быстро, бесшовно и без каких-либо ручных операций.

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

РД: Я думаю, драйвером DevOps у нас в стране послужил переход на облачные ресурсы. Так сложилось, что в наших компаниях ИТ следовали принципу «построим все свое». Возьмем пример 1C. Что делает компания, когда открывается? Ищет 1C-программиста. Зачем, пока не знает, но покупает сервер, программу 1C, начинает что-то настраивать, тратит на это кучу денег. Хотя есть облачные ресурсы, на которых то же самое можно получить быстро и за копейки. Это приводило к тому, что и сервера для эксплуатации приложений ставились у себя, и интернет-сайты хостились непосредственно в серверных компании. Плохо хостились, потому что не всегда такие серверные сравнимы с дата-центром, который использует много интернет-провайдеров.

Но затем произошел качественный скачок в осознании преимуществ облака, облако стало стандартом де факто. Появилось понимание, что инфраструктуру в облаке можно писать, как код, не обязательно строить ее вручную вместе с системным администратором. Именно в этот момент вспомнили про DevOps. Хотя на самом деле культура DevOps зарождалась в построении CI/CD-пайплайна. Но у нас пошло с другой стороны, со стороны облака, и пошло очень быстро, поэтому образовалась нехватка хороших специалистов.

ММ: Согласен. Если посмотреть статистику, откуда приходят в DevOps, то увидим большой перевес в сторону инфраструктуры. Это люди, которые изначально научились работать с cloud native инфраструктурой, с концепцией описания инфраструктуры как код, и уже потом погружались в CI/CD, в выстраивание процессов и т.д.

Если резюмировать, то облака стали драйвером DevOps, потому что они обеспечивают бизнесу скорость по сравнению с конкурентами. Скорость – это то, за что бизнес готов платить деньги, чтобы побольше «откусить» от рынка.

РД: Сейчас мы «живем» в интернете, для нас любая высокотехнологичная вещь, приложение становятся чем-то незаменимым. Поэтому выигрывает тот, кто быстро выводит на рынок новые «штучки». А ведь за этим стоит очень большой объем разработки и процессов.

ММ: Но важно понимать, что внедрение этих процессов и инструментов происходит в кардинально разные сроки, которые зависят от размера и ИТ-зрелости компании. Например, я недавно общался с одним банком и узнал, что там потратили полтора года на согласование со службой защиты ИТ использования инструмента Ansible. А таких инструментов очень много. Это не та скорость, с которой можно добежать до результата.

РД: Мы конкурируем с экосистемами, построенными в основном на банковских продуктах, например, подписки от известных банков, МТС, Яндекса. В банке другая культура, сложные процессы, которые очень долго переделываются. Банки неохотно идут в облако, они строят частные облака, а это сложнее, потому что меньше знаний.

ММ: Ты имеешь в виду на рынке?

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

ММ: Потому что в этом случае процессы гораздо проще и быстрее?

РД: Да, у нас, например, они гораздо проще.

ММ: И тут мы плавно переходим к проблемам, которые мешают DevOps развиваться еще быстрее. Как показал опрос, который мы провели перед митапом среди наших клиентов и всех, кто заинтересован в теме, проблема номер один – это найм высококлассных специалистов, способных решать реальные задачи. Таких специалистов очень мало, они обычно дорогие, и компания не всегда может себе позволить нанять этого специалиста, если даже его удалось найти. Перед началом митапа мы обсуждали, что для вас это тоже боль, и самые дефицитные позиции – разработчики на Go и DevOps-инженеры.

РД: Язык Go молодой, senior-разработчиков с приличными компетенциями мало. То же самое касается DevOps – это новое направление, если рассматривать полный спектр необходимых компетенций, таких как инфраструктура как код, пайплайны и др. Здесь тоже нет свободных людей с опытом, их надо переманивать, а они не все всегда готовы уходить. Да, кадровый голод ощущается очень сильно.

ММ: Вторая организационная история – это ИТ-структура компании. Люди понимают, что процессы в организации надо перестраивать, но либо нет компетенций, либо нет понимания, как это сделать, либо просто нет возможности перекроить процессы в текущих реалиях компании.

Еще один момент – защита ИТ-инфраструктуры. 18% респондентов отметили это как ограничение. На конференции по безопасности в банках, где я недавно был, коллеги со стороны инфобеза объясняли причину – безопасники не всегда успевает за скоростью инноваций в разработке или управлении инфраструктурой. Если разработчики уже несколько лет активно пишут в Docker, то в безопасники к этой теме многие пока только подступаются. А в крупных организациях – банках, промышленности и т.д., если служба защиты ИТ чего-то не знает, не понимает или не может быстро погрузиться, то просто запрещает.

РД: Да, соглашусь. Мы унаследовали структуру, в которой отдел системного администрирования – отдельно стоящий департамент, отдел разработки – тоже, и они конкурировали. В корпоративной культуре не было задачи строить один продукт вместе. Декларировалось, что все хорошо, но на практике всегда был конфликт. В таких реалиях невозможно работать эффективно. Инфобез тоже стоял отдельным направлением и тоже конкурировал со всеми ними.

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

ММ: Поговорим про технологические ограничения. Как показывает опрос, самые большие блоки – это несовместимость с текущими системами, сложность в интеграции как на сетевом уровне, так и в приложениях. Чаще всего речь идет про legacy-стек, который в новой парадигме не применим. Как я вижу, все эти проблемы решаемы. Для этого надо разбить большую задачу на мелкие блоки, например, монолит перевести в микросервисную архитектуру и выстраивать интеграции по каждой системе. Сетевые проблемы, если мы говорим про Kubernetes, можно решать, подбирая или кастомизируя тот или иной плагин. Решения есть, надо просто планомерно подходить к этому с более глубокими знаниями.

РД: Абсолютно соглашусь, здесь нет ничего такого, что нельзя было бы сделать. Есть определенные ограничения с точки зрения законодательства, например использование оборудования, сертифицированного госрегулятором, но это касается банков и тоже не является препятствием к тому, чтобы обеспечить совместимость. Подходов много, нужны желание и экспертные знания. 

ММ: Итак, есть набор организационных и технических ограничений и текущая ситуация на рынке. Вопрос – что может сделать организация, которая хочет реализовать DevOps-культуру, но либо нет кадров и компетенций, либо другие ограничения влияют?

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

Другой путь – получить DevOps как сервис. Это привлечение внешних команд консультантов и инженеров, которые помогут выстроить под ключ процессы пайплайна и межкомандного взаимодействия, определить зоны ответственности за каждый микросервис или за продукт в целом; внедрить нужные инструменты и настроить интеграцию – развернуть кластеры Kubernetes, инфраструктурную обвязку и затем эту контейнерную инфраструктуру поддерживать, администрировать и развивать. Это то, чем занимается моя команда.

Видишь ли ты какой-то третий путь?

РД: Третий путь – это микс между первым и вторым. «Серебряной пули» здесь нет и нельзя определенно сказать, что аутсорсинг – это хорошо или плохо, все зависит от ситуации. Если аутсорс-команда приходит к текущей, крайне редко складывается удачное взаимодействие, потому что сталкиваются две практики и каждый хочет сделать хорошо, но по-своему.

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

ММ: Ты верно отметил частый сценарий, когда заказчик для быстрого старта и решения своей задачи обращается к нашей команде или к другой на рынке. Получает результат, но при этом пытается параллельно вырастить внутреннюю экспертизу – подключает людей, и они учатся на боевых задачах. Мы не учебный центр, но можем прокомментировать, объяснить, как работает тот или иной процесс, как мы делали кластер Kubernetes или т.д. Это помогает, и мы видим, как со временем у заказчика формируются свои компетенции.

РД: Самый частый случай использования DevOps на аутсорсинге – когда сервис написан на собственных серверах и вы пытаетесь вывести его в облако и параллельно «сделать обвязку» в виде DevOps-культуры. Это очень хорошо сделать аутсорсом, задокументировать, а специалисты в компании, которые за этим наблюдают и помогают, одновременно учатся, уже имея документацию «под капотом».

ММ: Кстати, заметил, что культура документирования далеко не везде развита. Когда ты берешь аутсорс-команду, это может быть одним из требований в договоре. Но внутри у клиента часто нет документации на сервисы.

РД: Внутри нет, потому что это отдельные затраты, которые сложно обосновать бизнесу, особенно в условиях скоростного развития.

ММ: Для меня удивительно, что в крупных компаниях нет документации: «Спрашивайте, что надо, мы расскажем». В этих условиях сложнее онбордить людей, сложнее сохранять независимость от отдельных специалистов, если знания об архитектуре хранятся в голове конкретного человека и не перенесены на бумагу.

Но за последние полгода я вижу позитивный тренд. Даже клиенты, которые делают все инсорс, начинают исправлять ситуацию с документацией.

РД: Могу подтвердить. По прошествии полугода мы поняли, что технический писатель нужен и надо все документировать целиком и полностью.

ММ: У вас столько задач, что технический писатель занят на полный рабочий день?

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

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

РД: Тут все зависит от архитектуры продукта. Монолит и микросервис – это не чаша весов, чтобы выбирать, что лучше, что хуже. По своему опыту могу сказать, что монолит очень удобен на старте – он делается быстро, четко, без межкомандного взаимодействия и нестыковок. Если речь идет о MVP, монолит, на мой взгляд, это must have. Дальше его можно пилить, либо не пилить, либо пилить частично. Все зависит от того, как масштабируется сервис – нужно ли его масштабировать целиком или достаточно отделить небольшой микросервис и масштабировать его.

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

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

Надо выстроить удобный пайплайн, чтобы команда этим пользовалась, чтобы был унифицированный технологический стек, чтобы product owner в jira «запушил» свою идею, ее сразу взяли в работу, она пошла по пайпу с определенным SLA на каждом этапе, и все это было покрыто автоматизацией и еще сделан кусочек security и т.д. И тогда получишь результат. Но это долгий процесс.

Поэтому сам по себе распил, по нашему с Романом мнению, это не панацея. Много работы есть как после этого, так и до, с точки зрения понимания, а нужно ли это в принципе.

Второй вопрос: что лучше – Continuous Delivery или Continuous Deployment? Но для начала давай поясним, что означают эти термины.

Continuous Delivery – непрерывная доставка. В пайплайне CI/CD после того, как произошло тестирование и сборка билда, есть процесс по доставке билда в продуктивную среду. В концепции Continuous Delivery он включает как минимум один ручной этап – проверку тимлидом. Человек должен сказать ОК на выкатку кода в продуктив.

Continuous Deployment делает шаг вперед с точки зрения автоматизации и скорости доставки: каждое изменение, внесенное разработчиком, автоматически выкатывается в продуктив. Какие подводные камни? В организации должны быть две очень важные вещи. Во-первых, развитая культура тестирования, чтобы быть уверенным, что билд действительно корректно собран и готов к выкатке в продуктив. Во-вторых, культура мониторинга. Вы должны сразу понять, что билд выкатился не так, это влияет на продуктивное приложение, и есть механизмы, чтобы быстро откатиться на предыдущую версию. То есть в случае Continuous Deployment пайп полностью автоматизирован, но есть инструменты для моментального отката, так чтобы пользователи этого практически не заметили.

Есть «за» и «против», очень интересно послушать твое мнение, Роман.

РД: Есть также законодательные ограничения. Например, в банке без проверки и подписания документации человеком ничего нельзя выкатить, поэтому они не смотрят с сторону Continuous Deployment.

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

ММ: «Волшебной таблетки» не будет сегодня?

РД: Нет, не будет. Но надо стремиться к лучшему. Есть лучшая практика, есть понимание, как она строится, почему бы ее не делать? Да, возможно с ограничениями, с ручным участием, которое желательно всегда минимизировать, но двигаться в эту сторону можно и нужно.

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

РД: Я думаю, да. Банки, у которых улучшены технологические процессы, не используют старые шаблоны и стремятся к лучшим практикам.

ММ: Заключительный вопрос: что будет с DevOps в России через 3 года?

РД: DevOps останется востребованным. Тренд на облако взят, никакая ситуация его не изменит.

Но есть нюансы. Раз мы идем в облако, значит, нам будет актуальна тема «инфраструктура как код». Почему DevOps-специалисты так сильно востребованы сейчас? Потому что очень мало инструментов для того, чтобы сделать это «по кнопке», и DevOps-ы пишут много кода вручную. Я попутно даже готов ответить на вопрос «Что лучше: Kubernetes или OpenShift?», это как раз в тему.

Что такое Kubernetes: вы руками пишете большой код, разворачиваете кластер, следите за серверами, отслеживаете баги до уровня ядра, смотрите, почему тот или иной код выпадает. Что такое OpenShift: вы запустили, кликнули мышкой – у вас все работает. Это дорогой инструментарий, но он позволяет сэкономить на DevOps-специалистах. Им не надо будет писать целыми днями код и следить за ним, за них все это уже сделано. Такие программные продукты будут появляться. Будут они дорогими или дешевыми, сейчас сложно сказать. Но они будут упрощать работу DevOps-а и уменьшать его ценность, он перестанет быть незаменимым.

ММ: Согласен. Но если продолжать сравнивать Kubernetes и OpenShift, то в OpenShift не всегда есть возможность кастомизировать параметры или использовать инструменты, которые нужны конкретно тебе. В Kubernetes ты берешь движок, а все, что поверх, с точки зрения обвязки, настраиваешь под себя как хочешь. Да, действительно, там намного больше ручного труда. Если у тебя за плечами десятки проектов и множество сделанной автоматизации, будет проще. Если начинаешь с нуля, потребуется очень много усилий и компетенций в каждом из продуктов инфраструктурной обвязки. Но в результате ты получаешь решение, которое не так удобно администрировать, как в OpenShift, но оно закрывает твои задачи целиком. И при этом не платишь за лицензии.

РД: Верно, но если что-то сломается, ответственность несешь ты сам.

Кастомизация – это интересно, но единицам. Большинству интересно быстро, четко и с минимальными затратами вывести продукт на рынок. Поэтому я сомневаюсь, что в AWS кто-нибудь разворачивает Kubernetes сам, когда есть готовые сервисы.

Кроме того, поддержка Kubernetes от Google прекращается в обозримом будущем. Я не верю в то, что останутся люди, которые будут кастомизировать k8s до нюансов, связанных с ядром. Я верю, что будет появляться масса удобных и приятных продуктов типа OpenShift, в том числе и бесплатных. Рынок будет развиваться, инструменты будут удобнее и проще.

Вопрос. Разные продуктовые команды используют разные технологии и поэтому разные средства мониторинга. При выстраивании процесса ITSM инцидент происходит в разных зонах ответственности, как в рамках одного продукта – Kubernetes, СУБД, сеть, так и в разных продуктах. Должен ли специалист совмещать роли сетевика, админа, Kubernetes, DBA?

РД: Это зависит от проекта. Но как мне кажется, мониторинг должен быть всегда независимым. Это что-то промежуточное между бизнес-заказчиком и отделом разработки, который поставляет продукт. Там должны быть отдельные люди, которые будут разбираться, в чем на самом деле проблема – в некорректно написанном продукте, в некорректно написанной инфраструктуре, некорректно сделанной СУБД. Видеть картинку в целом, не вдаваясь в подробные детали.

ММ: Все зависит от масштабов организации и продукта. В стартапах я знаю людей, которые успешно совмещают все эти роли. В больших компаниях один человек не сможет объединить все компетенции по стеку решений. Там всегда идет четкое разделение зон ответственности.

РД: Как минимум DBA стоит отдельно, потому что глубокое понимание баз данных очень сложно совместить с знаниями по сети или другим. База данных — это один из основных компонентов любого продукта. А, например, для запуска Kubernetes, как мы сегодня обсуждали, достаточно будет нажать веб-кнопку, как это уже реализовано в AWS. Эти роли совместятся с другими, потому что не будет необходимости в глубоких знаний «нутра».

Вопрос. Должны ли быть продуктовые команды, которые целиком отвечают за конкретный продукт, или специалисты, обслуживающие свой сервис?

ММ: Как я вижу из своего опыта, в больших банках сложилась практика, когда создается продуктовая команда из 5-6 человек – product manager, аналитик, разработчики и DevOps-инженеры, и эта команда отвечает целиком за продукт, который они делают от момента формирования идеи, согласования и разработки до выкатки продукта и дальнейшего сопровождения.

Вопрос. Продуктовые команды должны давать метрики специалисту по мониторингу, который выстраивает показатели в некой книге рецептов для специалистов поддержки. Какие есть средства автоматизации данного процесса в рамках идеологии DevOps?

РД: Системы автоматизации – это стандартный набор инструментов DevOps, все их знают и ежедневно используют. Задача DevOps-а сделать так, чтобы физические метрики с микросервисов и инфраструктуры попали в телеметрию. Задача группы мониторинга – правильно выстроить их у себя на экране, задать себе алармы и добавить бизнесовые метрики. Продуктовая команда должна дать информацию о том, что сигнализирует о стабильности работы продукта – те или иные показатели микросервисов или частота или количество обращений в брокера сообщений. Группа мониторинга прежде всего должна следить за «здоровьем» продукта, которое отображается в показателях, заложенных в бизнес-логике, а не на уровне инфраструктуры или кода.

ММ: Поддержу, мы тоже видим тренд на изменение культуры мониторинга. Это большой процесс. В компаниях, которые внедряют DevOps, он распространяется на мониторинг CI/CD и даже на мониторинг билда и его состояния.

***

ММ: Резюмирую. Волшебной пилюли выдать не получилось. Все очень сильно зависит от компании, от состояния текущей команды, от продукта, который вы делаете, от того, для чего вы его делаете и что вообще хочет видеть бизнес в результате проекта. Исходя из этого принимаются решения как технологические – нужен ли распил монолита на микросервисы, так и организационные – посадить зерно культуры DevOps, его взращивать, выстраивать правильно процессы, зоны ответственности и так далее.