Как я не съездил в Лондон, но поучаствовал в London DevOps Enterprise Summit

Буквально недавно я был на митапе «в Челябинске», на следующий день — «в Новосибирске», а еще через несколько дней — в Калифорнии: физически сделать это было бы крайне затруднительно. Конечно, существуют записи, но само ощущение выделения времени для обучения, кажется, помогает учиться.

И тут возникает вопрос: конференций много… как посмотреть всё, что хочется посмотреть?

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

Что такое DevOps Enterprise Summit? Чем она отличается от других конференций?

Любая статья про DevOps-конференцию, конечно же, должна начаться с рассуждения о том, что такое DevOps, — и, конечно же, от этого устали все. Поэтому я постараюсь быть лаконичным!

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

Рискну навлечь на себя гнев за «упрощение», но по сути: для разработки привнесение «админских» методов и возможностей видоизменило процесс самой разработки идеологически и превратило DevOps в новый Agile — когда мы слышим о менеджерских конференциях про DevOps, мы слышим об изменениях в методологии разработки. А DevOps Enterprise Summit — одна из тех конференций, что имеют полезность для «админов»: здесь были и доклады ближе к техническим.

Итак, DevOps Enterprise Summit проводится с 2014-го года, и ее организатором является компания IT Revolution с основателем Gene Kim, известного очень многим по книге «Проект Феникс». IT Revolution — это как раз издательство, запустившее целую серию книг по DevOps и его связи с гибкими методологиями. Почему именно Enterprise? Это особенно важный момент.

Ввести гибкие методологии в небольшой компании просто: в компаниях, состоящих из нескольких человек, они, скорее всего, и так существуют с самого начала — просто надо их таким образом назвать. С компаниями в тысячи, десятки тысяч человек всё сильно сложнее. В них существует огромное количество процессов, выстроенных для того, чтобы эта махина продолжала движение, и это можно сравнить с большим кораблем. Когда корабль идёт через океан от одного материка на другой, он выполняет свою роль, но корабль не может в кратчайшие сроки изменить маршрут и сменить курс — на этого требуется время, особенно в технологических бизнесах. Молодая компания из нескольких человек может за несколько дней построить прототип того, что компания из тысяч человек будет строить годы — если не изменится. Поэтому большие компании хотят меняться и использовать методики «молодняка», однако им надо понять, как не порушить свои процессы. Я уже приводил пример в другой своей статье: в Excel 1900-й год считается високосным, и сделано это для обратной совместимости с версиями Lotus 1-2-3, в которых был такой баг. Эти версии были выпущены в 80-х годах — и вопрос: нужно ли сохранять эту совместимость? Насколько можно допускать баги в подходе «потом исправим», когда ты ставишь ПО в банках на серверы, которые вообще отключены от интернета? Как при этом сохранить ту самую гибкость? Про это и была конференция.
 

Формат

Каждая конференция пытается выдумывать как перевести себя в онлайн, и это интересно. В DOES можно отметить следующее:

• Доклады по-прежнему разбиты по трекам, зритель может переключаться между треками в процессе.
• Доклады записаны до дня конференции, чтобы избежать технических проблем с трансляцией, докладчик во время доклада находится в слак-канале и общается с аудиторией. Это, наверное, самое интересное, что я вынес из организации. Решение противоречивое — с одной стороны, пропадает интерактив, с другой стороны, гораздо больше времени на вопросы (и гораздо больше возможностей у докладчика ответить на большее количество вопросов). Однако я, например, в основном, слушал доклад и не хотел переключаться на обсуждение, поэтому приходил в конце, когда оставалось мало времени и на следующий доклад приходил уже новый докладчик.
• Общение ведется в слаке, на каждый трек сделан свой слак-канал, отдельно слаки сделаны по спонсорам и нетворкинговой активности.
• Нетворкинговую активность увеличили в несколько раз, но мне не понравилось, что во всех активностях, которые были запущены, нельзя было «постоять в стороне», в зум-митапах всех просили представиться, в круглых столах все пришедшие обсуждали вопросы итд, иногда хочется просто вначале послушать и уйти, если не понравится.

Выжимка

• Конференция фокусируется на практике компаний-Horses, а не компаний-Unicorns — говоря по-русски, фокус идет на практику «рабочих лошадок», не надутых капитализацией на бирже, а доказавших свою пригодность за годы долгой работы — дальше в примерах будут страховая компания, которой сотня лет, крупнейшая в Европе служба доставки и т.д. Можно сказать, что в какой-то мере это «анти-хипстерный» тренд, когда рассказ идет о том, как новые методологии (и новые технологии) применяются в реальной жизни (вводный доклад от Gene Kim).
• Важнейшей частью DevOps как методологии является создание «коллективной гениальности» — scenius. Scenius в данном случае противопоставляется единичной «гениальности» — genius, и задача объединения ранее противопоставляющихся друг другу команд, задача организации взаимодействия как раз в том, чтобы, сформировав scenius, выйти на новый уровень решения проблем (вводный доклад от Gene Kim). (см. также medium.com/@stevesargon/steal-like-devops-artist-1-you-dont-have-to-be-a-genius-or-googler-6e9f17c14fb5 и в целом гуглить по слову Scenius.)
• Каждый второй докладчик говорил о положительном опыте формирования платформенной команды и в целом Platform Engineering, когда «гибкая» микросервисная архитектура опирается на «платформу», предоставляющую основные инфраструктурные сервисы (DevOps Journey at Adidas III, Exploring Data in the Cloud Fernando Cornago VP, Platform Engineering, Daniel Eichten VP, Enterprise Architecture, Adidas и другие). (см. также softwareengineeringdaily.com/2020/02/13/setting-the-stage-for-platform-engineering и в целом гуглить по platform engineering и platform team). Вообще, интересно наблюдать, как методики, которые были приняты довольно давно, вводятся как новые открытия. Платформенная команда — это не только инженеры, которые создают платформу, но и консультации и советы по использованию. И команда, которая обладает видением, как платформа будет развиваться (platform advisory/community management/platform operation/platform evolution).

Каждый третий докладчик говорил про формирование DevOps Dojo. На этом стоит остановиться подробнее. Для небольших компаний и отдельных сотрудников кажется очевидной полезность митапов и воркшопов, где люди обмениваются своим опытом. Мы в таком формате создали для SRE-специалистов Uptime community, однако как быть в компании где тысячи, десятки тысяч сотрудников? Dojo — слово, пришедшее из японского и в конечном итоге означающее зал, где обучаются боевым искусствам. В DevOps-методологии практику начал использовать огромный американский ретейлер Target, организуя систематически внутри компании воркшопы, митапы, конференции, где сотрудники могут обмениваться между собой набитыми шишками и опытом, и создавая безопасное пространство, где можно заниматься практикой, не боясь ошибиться. См. youtu.be/1FMktLCYukQ

• Докладчики из Swiss Re — швейцарской страховой компании, существующей 156 лет, рассказывали об успешном переходе к DevOps-методологиям на примере их нового сервиса. Трансформацию запускали на трёх конкретных продуктах, во «внутреннем стартапе». Отношения к головной компании были как к «инвестору» — у «стартапа» был собственный CEO, руководящая команда, своя платформа и т.п. Вообще, надо отметить, что, согласно Gartner-у, 76% запущенных DevOps-трансформаций компании оценивают как «меньше, чем полпути». И к запуску таких процессов надо относиться с пониманием рисков. Во многих компаниях реалистичные сроки внедрения — около пяти лет, и к этому моменту многие практики устаревают или оказываются неактуальными. Главная проблема в том, что к самому процессу внедрения «гибкой» методологии DevOps-а большие компании приступают с водопадным подходом — и с этого начинаются проблемы. В трансформации стоит предполагать итеративность. Другим моментом, приводящим к трансформации, являлась смена визионерской технологической команды: докладчики из Hermes Germany GmbH сказали, что инициативу запустил новый CIO, при этом они как раз выступали против идеи «внутренних стартапов», поскольку такой «стартап» остаётся изолированным и головная компания не меняется.
• В почти всех успешных кейсах трансформации говорили о важности метрик, по которым определяется эффективность трансформации — см. метрики в State of Devops, книге Gene Kim Accelerate.
• Отдельно мне, как техническому гику, запомнился доклад DevOps And Modernization 2.0 (CSG) от Scott Prugh — про историю внедрения методологий DevOps на мейнфреймах. Посмотрите подробнее в детальном описании, но лучше — дождитесь появления видео, это потрясающе: миграция и ускорение деплоев кода на Cobol-е, переписывание 3,7 миллиона строк кода на IBM High Level Assembler на Java и еще очень много информации! Вывод: даже в очень сложных инфраструктурах с огромнейшим наследием трансформацию организовать возможно.

Упоминаемые книги, которые стоит прочитать:
Team Topologies in Action, Accelerate: Building and Scaling High-Performing Technology Organizations.