Наш эксперт,
Игорь Курочкин, открывал профессиональную конференцию
DevOpsConf 2024 по интеграции процессов разработки, тестирования и эксплуатации. Конференция проходила в начале 2024 года и собрала более 1800 представителей индустрии.
Игорь проанализировал десятки публикаций, выступлений и книг с момента появления термина в 2009 году, чтобы понять какие проблемы получилось решить DevOps движению, а какие еще предстоит. В докладе рассмотрены:
- DevOps как профессиональное движение, которое решает проблемы взаимодействия между разработкой (Dev) и эксплуатацией (Ops). В выступлении DevOps был определен как проблема взаимодействия, а движение DevOps описано как попытка решать эту проблему через манифесты, книги, исследования, принципы, практики и инструменты. Отдельно подчеркивалось, что официального определения DevOps не существует, и это стало одной из причин появления множества трактовок;
- Модель The Way of Ways и модель The Way of DevOps для визуализации пройденного пути и созданных артефактов. Модель The Way of Ways Джона Катлера показывает как в индустрии развивается любое профессиональное движение: от появления названия, первых конференций и принципов до формирования паттернов, публикаций, практик и распространения через экспертов. Отдельно была показана "правая сторона" как описание того, как идеи превращаются в коммерческий шум: появляются "DevOps как роль", "DevOps как коробка", сертификации и обещания "купите инструмент и проблема взаимодействия решена". DevOps в этой модели был описан как движение, прошедшее этот путь примерно за 10 лет, после чего начинается следующая фаза, которая в докладе называется NextOps;
- Срез по активностям основых лидеров DevOps движения: Gene Kim, John Willis, Jez Humble, Dave Farley, Nicole Forsgren, Matthew Skelton и Manuel Pais. В докладе были разобраны примеры того, куда сместились интересы и работа ключевых лидеров: переименование и трансформация конференций, новые книги и исследования, смещение фокуса в сторону Tech Leadership, Modern software engineering, Developer productivity и Developer experience, развитие внутренних платформ и платформенных команд, а также работа с направлениями надежности и организационного дизайна. Отдельно упоминалось, что часть лидеров фактически уходит от термина DevOps, продолжая развивать практики и идеи под другими рамками и сообществами;
- Исследования команды DORA (DevOps Research and Assessment), проблемы применения и обновление модели DORA Core. Игорь отдельно остановился на том, как DORA закрепила в индустрии модель и почему на практике компании часто используют ее неправильно: берут только метрики и профили эффективности (Elite, High, Medium, Low), игнорируя культуру, практики и связи с ценностью. Также было отмечено, что DORA продолжает развиваться после ухода основателей: команда стала более открытой, публикует материалы, расширяет исследование и обновляет модель. В докладе упоминалось, что в новой версии появились дополнительные практики, культурные и организационные аспекты, анализ ведется не только на уровне организации, но и на уровне команд, а также меняется трактовка части метрик;
- Состояние Reliability Engineering и Platform Engineering. В выступлении Reliability Engineering рассматривается как отдельное направление, имеющее собственную историю, сообщество, книги и модели. Подчеркивалось, что многие компании переосмысливают роль инженера эксплуатации и переходят к более специализированным ролям и командам, включая SRE и платформенных инженеров. Platform Engineering был описан как быстро растущая область, подпитываемая опытом больших компаний, развитием облаков, экосистемой Kubernetes и появлением класса решений Internal Developer Platform (IDP). Отдельно отмечались типовые проблемы текущей волны: переусложнение, высокая стоимость, долгие циклы создания платформ и слабый фокус на пользователях, что требует продуктового подхода и работы с Developer Experience;
- CNCF, Linux Foundation и CD Foundation как примеры открытых сообществ и фондов. Игорь показал CNCF как устойчивую модель сообщества с прозрачными процессами, рабочими группами и влиянием на индустрию через стандарты, конференции и экосистемы проектов. Были упомянуты примеры, когда открытые модели и фонды становятся точкой сборки для технологических направлений, а также роль Linux Foundation как зонтичной структуры, в которую входят и CNCF, и CD Foundation. CD Foundation была упомянута как центр развития практик Continuous Delivery на уровне сообщества: Best practices, опросы и отчеты;
- Вторая волна или NextOps, которая строится вокруг нерешенных проблем и проблем, которые можно осознать и исследовать, а также новых движений, сообществ, компаний, практик и инструментов. NextOps в докладе был описан как вторая волна DevOps, но уже в условиях роста сложности и специализации: появляются новые направления инжиниринга, новые сообщества, новые компании и классы инструментов (в том числе Developer Tools 2.0). Подчеркивалось, что новые направления проходят путь развития быстрее, чем DevOps, и что индустрия одновременно расширяет набор практик и усложняет модели, пытаясь описать более широкий спектр проблем;
- Проблемы NextOps, связанные с большим числом новых направлений и рекомендации по решению с помощью R&D, специализации и продуктового подхода. В докладе был зафиксирован ключевой риск NextOps: зоопарк доменов и терминов, в котором трудно понять пересечения, приоритеты и точку входа. Как ответ были предложены три линии: специализация (один универсальный инженер не может уместить все практики и инструменты), инвестиции в более глубокий R&D (вместо поверхностного поиска и низкокачественных обзоров), а также продуктовый подход как способ проверки гипотез, приоритизации и улучшения опыта пользователей платформ и инструментов;
- Инструменты для самостоятельного анализа с помощью MECE, PESTEL, SWOT, Weighted Decision Matrix. В завершение доклада Игорь предложил набор прикладных инструментов, которые помогают структурировать NextOps и выбирать направления под свой контекст: MECE для разбиения на независимые домены, PESTEL для учета внешних факторов, SWOT для оценки сильных и слабых сторон и возможностей, а также Weighted Decision Matrix и собственные радары с критериями, чтобы осознанно принимать решения. Отдельно подчеркивалось, что универсального ответа что выбрать нет, и выбор должен зависеть от контекста компании, ее проблем, размера и инженерной зрелости.
Подробнее в записи выступления и
презентации: