Привет, Хабр!
21 сентября состоялось главное технологическое событие осени — масштабная конференция Сбера SmartDev 2023, организованная для инженеров, разработчиков и всего ИТ-сообщества.
48 тысяч участников и более 1 млн просмотров эфира позволяют прочувствовать размах этого события. Технологическая конференция, кажется, стала настоящим вдохновением для IT-сообщества.
Если вам интересно почитать о том, как это было, то советуем статью "От технарей — для технарей: как я заглянул в будущее на конференции SmartDev 2023".
В этой статье мы подготовили краткую выжимку трека DevOps для тех, кто пропустил конференцию: ключевые тезисы и самые горячие вопросы, которые, как нам кажется, всё ещё остаются открытыми, и которые можно продолжить обсуждать в комментариях. Приглашаем под кат.
Трек DevOps состоял из панельной дискуссии «DevOps в России: состояние и перспективы» и пяти докладов:
Создание единой среды для DevOps-процессов любой сложности в условиях постоянного масштабирования и роста количества проектов.
Clickhouse как бэкенд для Prometheus.
Каким должен быть российский веб-сервис для хостинга ИТ-проектов?
Kubernetes-платформы: причинять добро и наносить пользу.
Как разрабатывается российская Java.
И хотя по заголовкам докладов создаётся впечатление, что между ними нет практически ничего общего, а про некоторые вообще можно спросить: «И причём тут DevOps?», но на самом деле все они объединены единой темой: «С какими глобальными трендами и вызовами в сфере DevOps сейчас столкнулись ИТ-компании в России и что мы с этим будем делаем?» Эта тема была задана в начале конференции на панельной дискуссии.
Панельная дискуссия: «DevOps в России: состояние и перспективы»
В дискуссии приняли участие специалисты из компаний Axenix, Hilbert Team, Сбер, СберТех. Модератором выступил Сергей Храпов, Управляющий директор SberWorks и лидер сообщества DevOps Community (SberAcceleration).
Сергей Храпов
Управляющий директор SberWorks, лидер сообщества SberAcceleration DevOps Community, Сбер
https://t.me/khrapoff
Тимур Батыршин
Менеджер практики, Инфраструктурные облачные решения, Axenix
@erthad, timur.batyrshin@axenix.pro, https://t.me/devops_architecture/
Михаил Кажемский
Ведущий DevOps-инженер, Hilbert Team
@devops_ht, Mikhail.kazhemskiy@hilbertteam.com, https://t.me/kazhem
Сергей Артюхов
Директор дивизиона инструментов производственного процесса, СберТех
https://t.me/tw0_percent, SVlaArtyukhov@sberbank.ru
Первая тема дискуссии: тренд на импорто/вендорозамещение
По мнению всех участников, импорто/вендорозамещение затронуло каждую ИТ-компанию в России. Но что с этим делать, и появятся ли в России конкурентные продукты для разработки и DevOps в ближайшие один-два года?
Большинство участников оптимистично смотрят в будущее, потому что есть хорошая open-source-база, обвесив которую безопасностью, можно получить классные продукты, и к тому же в России крутые разработчики и не менее крутая школа дизайна.
Срок в один-два год виделся маловероятным, но нужно с чего-то начинать. И сейчас хорошие возможности для того, чтобы начинать делать классные продукты не только для маленького рынка России и СНГ, но и для глобального.
По результатам запущенного опроса, аудитория с небольшим перевесом поддержала оптимистичный настрой участников дискуссии.
Спойлер цитаты
Ситуация достаточно сложная, у нас в России только начал появляться рынок локальных продуктов, начал заполняться и проблема как раз в том, что пока полноценных продуктов нет, но они обязательно появятся на мой взгляд.
Тимур Батыршин
Я верю в людей, по своему опыту работы и особенно верю в наших разработчиков и наших инженеров - они затащат все что угодно! Российский разработчик — это бренд!
Давайте посмотрим на факты: в мире есть неплохая Open Source база, на которой, обвешивая безопасностью, добавим немного надежности, масштабируемости и т.д., ты сможешь на базе этого построить то или иное решение. Вопрос только в том, насколько оно будет конкурентоспособным и где?
Сергей Артюхов
Нам нужно ориентироваться на мировой рынок, не только Российский. В том плане, что у нас действительно классные разработчики, управленцы, дизайнеры и продукты. Но в России не настолько такой большой рынок, то есть у нас там 140 млн чел + СНГ, тем не менее это не миллиард населения. И поэтому ориентироваться только на глобальные рынки — это более правильное целеполагание.
Михаил Кажемский
Такие конференции, похожие на эту, мне кажется, могут стать площадкой, где мы хотя бы узнаем о том, что у нас есть конкурентоспособные продукты.
Скептицизм, который присутствует в результатах голосования совпадает с моих изначальным, о котором я заявлял. Но, пробрасывая мостики в следующие доклады, я бы все-таки хотел, чтобы мы уже поняли, что хватит ждать, нужно в любом месте становится конкурентоспособными и пора уже затащить!
Сергей Храпов
Вторая тема дискуссии: «AI Copilot — правда ли ИИ изменит мир, или это очередной хайп?»
Тема ИИ в этом году пронизывает красной нитью все значимые инициативы как в России, так и в мире. И дело не столько в том, что это хайп, а в том, что это меняет расстановку сил и подходы к построению DevOps в организациях, заставляет задумываться над тем, как не остаться у обочины, проповедуя старые подходы.
Пожалуй, это была самая живая часть дискуссии, в ходе которой не удалось сформировать полярные мнения. Все участники согласились, что изменения неизбежны, но вот сколько на это потребуется времени — большой вопрос.
Спойлер-цитаты
Если говорить в целом про мир, то, наверное, там что-то поменяется, но если говорить про Россию и нашу индустрию, то эти технологии особо не применишь. Потому что стандартные решения, скорее всего, отвечают потребностям. Нам нужно придумывать какую-нибудь архитектуру высокого или низкого уровня, чтобы она удовлетворяла меняющимся требованиям. И здесь, мне кажется, все эти ИИ никак не помогут.
Тимур Батыршин
Тем не менее, многие Junior-запросы ИИ может удовлетворить. Например, если говорим про DevOps, то как поднять Kubernetes, он тебе инструкцию распишет. Но встаёт вопрос, а кто проверит эту инструкцию? И здесь нам нужны Senior и Middle.
Михаил Кажемский
GitHub уже свой benchmark задаёт, который говорит о том, что в целом на 55 % увеличивается скорость разработки благодаря кодогенерации, code completion и т. д. Мы у себя в Сбере применяем GigaCode, и благодаря code completion скорость работы любого разработчика возрастает. Он делает больше фич за то же время.
Сергей Храпов
Мне кажется, что эти тектонические изменения, если сейчас в этот поезд не запрыгнуть, то может получится так, что останешься на станции.
Этими системными сдвигами, превращением DevOps не в набор конвейеров, а в какую-то платформу-как-сервис, подобную задачу по силам решать только Senior-ребятам. При этом Junior будут вымываться, потому что у нас появился Co-Pilot, GigaCode и т. д. Вопрос - когда кончатся Senior-инженеры?
Сергей Храпов
Несмотря на то, что у нас много инженеров с офигенным образованием и классным опытом, мы почему-то верим в «серебряные пули». «Вот если ИИ придёт, то он сделает всё!» Но нет! Я задал бы скорее такой вопрос: «Применим ли ИИ на 100 %?» Я думаю, что это случится через 5-10 лет. Максимум через 10, когда ИИ обретёт некоторую субъектность. Но тогда он заберёт у Junior простые задачи. И получается, что людей, которые будут в состоянии прокачаться, — у поколения Junior, — будут большие проблемы.
Получается, что ты ускоряешь процесс разработки и тестирования своих гипотез. Тебе нужно будет заниматься более системными и сложными, нестандартными задачами. И тут будет точно рост, но остаётся всё же открытым вопрос: «Как расти Junior?»
Я отвечу, где брать Junior и что с ними делать. Живых боевых задач для них будет мало, но у тебя рядом будет неспящий ИИ, который будет тебе подносить эти задачи. Его нужно будет отлаживать, чтобы ты мог расти. Мне кажется, это то самое персональное обучение, о котором нам рассказывают лет 20 уже.
Сергей Артюхов
Ниже результат опроса аудитории по теме.
Третья тема: «Данные и мониторинг»
После жаркого обсуждения предыдущей темы стало понятно, что никакого ИИ не случится, если не будет данных, на которых можно обучить необходимые модели. А плохие, некачественные данные только помешают внедрению ИИ. При этом количество данных растёт.
Спойлер-цитаты
Чем больше релизов, тем больше данных всё это хозяйство генерирует: журналы, метрики, всё что угодно. Но несмотря на то, что у меня терабайты данных, что с ними делать? Как из этого сделать ту выборку, на основе которой можно научить ИИ?
Сергей Храпов
Для предикативного реагирования нам кроме бизнесовых, продуктовых и метрик приложения нужны инфраструктурные метрики. Мы должны правильно настраивать мониторинг и насыщать этими данными нашу ИИ-систему.
Михаил Кажемский
Раньше был Oracle, Terradata, а сейчас все эти вещи нужно строить DevOps-инженерам, а разработчикам поверх всего этого писать. Это вызов для всей российской индустрии, в том числе и для DevOps-сообщества, и для разработчиков. Потому что данные нужны постоянно и в финтехе, и в ретейле, и в промышленном производстве. Я слышал, что самолет Boeing генерирует за один полёт 1 Тб телеметрии.
Тимур Батыршин
Когда появился термин BigData, был такой хайп. Но все забыли про нюанс, что данные потому и назывались большими, что они были неточными. И когда ты скармливаешь эти большие неточные данные какой-то модели, она с этим отлично справляется. Не бывает плохих или хороших данных, есть плохие вопросы, которые ты ставишь.
Сергей Артюхов
В конце дискуссии участники ответили на несколько вопросов, заданных зрителями. Вот самый интересный, который сразу поставил их в тупик:
Дайте чёткий ответ: кто такой DevOps?
Я считаю, что DevOps — это суперинженер, который и в поддержке понимает что-то, и в разработке, и самое главное: он чувствует ответственность на стыке Dev и Ops. Потому что зачастую разработчик написал код, через забор перекинул, хорошо если его поймали, отряхнули и поставили на ноги. Потом команда сопровождения всегда спрашивает: «Кто так написал, кто так делает?», и перекидывает обратно в виде Change Request. В итоге приходит DevOps, который как бы и нашим, и вашим. Поэтому для меня DevOps — это суперинженер.
Сергей Храпов
Полную версию панельной дискуссии можно посмотреть по ссылке.
Создание единой среды для DevOps-процессов любой сложности в условиях постоянного масштабирования и роста количества проектов
Или как мы закопались в построении DevOps-процессов, чтобы не закапываться в найме DevOps-инженеров.
Сергей Артюхов
Директор дивизиона инструментов производственного процесса, СберТех
https://t.me/tw0_percent, SVlaArtyukhov@sberbank.ru
Виталий Астраханцев
Владелец продукта Релизный конвейер PV Works, СберТех
VGAstrakhantsev@sberbank.ru
В начале доклада Сергей ностальгирует по былым временам, когда были независимые разработчики, которые могли самостоятельно создать весь продукт от начала и до конца. Времена Джона Маккарти и Алексея Пажитнова.
Спойлер-цитаты
Сегодня в большинстве своём мы находимся в ситуации, когда рост потребностей бизнеса и рост сложности инфраструктуры, огромное количество разных запросов приводит к тому, что разработчик больше не может сделать это всё как инди. Он вынужден сосредоточиться на каком-то узком куске своего производственного процесса.
И получается, что у нас есть разработчик и вот эта сложность, особенно в Enterprise, которая приводит к тому, что со временем у разработчика начинают отщипывать те или иные части процесса. Когда ты был один, ты сам управлял всем. Сейчас ты так не можешь просто потому, что у тебя нет компетенции. Нужно ждать постановку, дизайны, архитектуру... ждать... ждать... ждать...
Сергей Артюхов
У нас появилась мечта: мы хотим назад в прошлое. Хочется как раньше, когда инди-разработчик затаскивал всё в одно лицо. Ведь это было круто! Тогда было ощущение, что ты настоящий творец того, что ты создаёшь. Была полная ассоциация меня с тем продуктом, который я делаю.
Сейчас получается, что я как разработчик только на малом участке производственного процесса пишу только код, а какие-то другие люди должны подхватить его и что-то дальше с ним сделать.
Понятное дело, что мы не можем вернуться в прошлое, потому что появились современные технологии, облака, микросервисы и ИИ. Мы хотим создать Productivity Platform - платформу продуктивности, которая позволит разработчику почувствовать себя инди и вернуться в то самое ламповое время.
Большая часть нашей работы состоит из рутины. Эти однотипные задачи не дают нам развиваться. Productivity Platform OrchestraR должна сосредоточить внимание DevOps-инженеров на нестандартных, сложных и интересных задачах, которые помогут прокачаться. Хочется, чтобы было просто, чтобы инструмент был понятный, интуитивный, «провожал нас за руку» в процессе настройки, предугадывал какие-то наши действия.
А чего пользователь хочет?
Что-то простое и понятное
Работающее
Настроил и забыл
Меня не дергают
Что мы предлагаем:
Что-то простое и понятное
Release Automation Tool: автоматизация, оркестрация управления сборкой и развёртыванием релизов во всех сегментах сети
Все требования к процессу производства ПО соблюдаются из коробки, команда не тратит время на их внедрение
Надёжность 99,99
Один час на настройку и запуск своего Релизного конвейера и DevOps CI/CD-конвейера.
Что получается:
Разработчик сможет создать конвейер на платформе в инструменте OrchestraR с помощью мастера без привлечения DevOps.
DevOps-инженер со временем, возможно, станет централизованной функцией и будет заниматься развитием мастер-системы, а не разработкой очередного конвейера.
Если вас заинтересовала эта тема, то рекомендуем посмотреть доклад целиком, там много подробностей и нюансов, о которых можно написать отдельную статью.
Clickhouse как бэкенд для Prometheus
Михаил Кажемский
Ведущий DevOps-инженер, Hilbert Team
@devops_ht, Mikhail.kazhemskiy@hilbertteam.com, https://t.me/kazhem
На панельной дискуссии мы пришли к тому, что всем нужны данные, в том числе от систем мониторинга, чтобы использовать их в разных ИИ- и BI-системах. А как именно эти данные хранить и передавать?
Самой распространённой системой мониторинга сегодня является Prometheus — это отраслевой стандарт. С ростом количества инфраструктуры и источников метрик, мы сталкиваемся с необходимостью масштабирования Prometheus в несколько инстансов, а для систем визуализации метрик, например Grafana, чтобы не склеивать метрики из нескольких Prometheus инстансов, нам необходимо подключать Long Term Metrics Storage - долговременные хранилища.
В докладе подробно рассмотрено несколько таких продуктов: Thanos, Grafana Mimir, Victoria Metrics и другие.
Причём при хранении метрик нужно:
Минимизировать зависимость от геополитических рисков
Иметь возможность экспорта в ИИ-системы
Сохранять высокую производительность
Иметь возможность дальнейшего горизонтального масштабирования
Иметь возможность использования Managed Data Storage
Запись доклада можно посмотреть здесь.
GitVerse — новый веб-сервис для совместной разработки и хостинга IT-проектов
Матвей Ульянычев
CPO Platform V, СберТех
Арсений Голушков
Технический эксперт, СберТех
Весь мировой ИТ-рынок движется в направлении open-source, и важно, чтобы российские разработчики имели все необходимые инструменты для создания передовых технологических решений.
GitVerse — это веб-сервис от Сбера для совместной разработки и хостинга кода, который позволит разработчикам создавать проекты с открытым и закрытым кодом и привлекать новых участников к развитию своих решений.
Это полностью отечественное решение, не зависящее от иностранных вендоров и технологий. С помощью GitVerse разработчики смогут собрать проект, протестировать его, развернуть на стендах и проверить. Сервис также поможет автоматизировать разработку, хранить код, создавать и удалять репозитории, назначать задачи, добавлять комментарии.
А ещё через GitVerse можно будет подключить ИИ-помощника для разработчика — GigaCode, ускоряющего написание кода и работу с ним.
Преимущества GitVerse:
Сервис создан и размещён в России — исключены риски недоступности разработок и кода для российских пользователей
Бесплатные квоты до 2 Гб по использованию ресурсов сервиса
Плагины для всех популярных интегрированных сред разработки (IDE), упрощающие и ускоряющие разработку
Информационный портал, на котором публикуются новости и материалы по теме open-source
В будущем GitVerse будет дополняться различными инструментами для разработки open-source-проектов, доступ к которым первыми получат участники раннего тестирования.
Пока GitVerse могут использовать сотрудники Сбера, но уже в начале 2024 года он станет доступен всем. Разработчики уже сейчас могут подать заявку на участие в раннем тестировании — и первыми получить доступ.
Мы предоставим:
Функциональность Git-репозитория и code review
Плагины к IDE GigaCode
Доступ к open-source-проектам
Участие в развитии проекта GitVerse
А что там под капотом, из чего сделано и почему решение должно быть надёжным и безопасным, лучше всего рассказал Арсений Голушков, плюс там есть в конце ответы на каверзные вопросы. Кто ещё не видел, смотрите запись.
Kubernetes-платформы: причинять добро и наносить пользу
Константин Аксёнов
Руководитель разработки Deckhouse Kubernetes Platform, Флант
konstantin.aksenov@flant.com, http://github.com/konstantin-axenov
Доклад про Kubernetes-платформы и зачем они вообще нужны. Больше всего будет интересен тем, кто уже знает, что такое Kubernetes, и тем, кто сомневается, что им нужен Kuber.
В мире и в России Kubernetes распространён практически одинаково. Его преимущества:
Большая доля рынка
Создан новый опыт работы с клиентами, приносящий доход
Выросла рентабельность
Управление инфраструктурой стало эффективнее
Разработчики более продуктивны
Помогает ИТ-руководству продемонстрировать ИТ как источник дохода, а не просто затраты.
Если какие-то из этих вопросов находят в вас отклик:
Какую ОС выбрать для узлов кластера?
Как обновлять ОС?
Какую архитектуру кластера выбрать?
Etcd на отдельных узлах?
Какой CNI выбрать?
Cilium или Calico?
Containerd или Docker?
Какой ingress controller выбрать?
Nginx ingress или envoy?
Multicloud или hybrid cloud?
Мне нужен Service Mesh?
Istio или что-то другое?
и т.д
… то очень рекомендуем посмотреть доклад. Там ещё много другого полезного.
Как разрабатывается российская Java
Олег Чирухин
Директор по коммуникациям с разработчиками, Команда Axiom JDK
oleg@axiomjdk.ru, https://habr.com/ru/hubs/java/articles/, https://t.me/failoverbar
Доклад для всех, кто любит Java, про Российскую Axiom JDK, её преимущества и фишки. Олег подробно рассказывает о том, что Java всё ещё является основной платформой разработки, мощнейшим и всеобъемлющим инструментом, на основе которого можно создавать решения для любых задач.
Далее краткая выжимка из доклада.
Java сейчас один из самых популярных языков. В номинации «Самый любимый язык программирования» его опережает разве что Python. За что же так любят Java? Тут можно перечислять много, но стоит упомянуть:
Длительный срок поддержки
Понятные и предсказуемые релизы новых версий
Возможность запуска на разных платформах и архитектурах процессора, что очень важно для российских производителей
Лёгкость миграции между платформами
В последнее время стали очень популярны облака, но минус в том, что они не бесплатны. А современные базовые образы живут в оперативной памяти и занимают её очень много. Что с этим может сделать разработчик? Особо ничего. Но оказалось, что можно взять один из самых популярных образов Alpine и научить его быстрее работать с Java.
Раньше все стремились переписать всё на open-source. Но там может быть много уязвимостей и специально созданных закладок. Примеров немало. В Axiom JDK разработка ведётся в рамках Secure Development Lifecycle (SDL).
Основные инструменты:
Dependency Track — проверяет зависимости на предмет открытых уязвимостей;
SpotBug — статический анализатор кода;
Svace — крутой статический анализатор от ИСП РАН.
Axiom JDK сертифицирован ФСТЭК СЗИ УД4, это позволяет использовать его для разработки государственных информационных систем и систем критической инфраструктуры до первого класса включительно. Например, система быстрых платежей (СБП) использует Axiom JDK, и количество транзакции на начало 2022 года достигало 5 миллионов в день.
Если тема заинтересовала, то все остальные подробности в записи доклада.
Краткие итоги
Вендорозамещение: у нас действительно классные разработчики, управленцы, дизайнеры и продукты, поэтому всё возможно, мы должны «затащить», и начинать надо уже вчера.
ИИ системы, помощники, чаты и т. д.: ИИ-системы точно будут помогать с рутинными задачами, Senior-специалистам можно будет сосредоточиться на более нестандартных и сложных задачах развития DevOps-платформ, что в будущем может превратиться в новые этапы развития ИИ-систем. Junior-специалисты смогут развиваться при взаимодействии с ИИ-системами.
Мониторинг и данные: нужны всем и много, чтобы в последующем развивать ИИ-системы прогнозирования и предикативного реагирования на инфраструктурные и иные проблемы и инциденты.
Productivity Platform и DevOps-as-a-Platform: неизбежный эволюционный путь в контексте всех остальных аспектов развития технологий. Верните разработчику возможность творить свои продукты самостоятельно от начала и до конца. Дайте DevOps-специалистам развиваться на интересных и нестандартных решениях, а не закапываться в рутине обслуживания команд разработки.
GitVerse: веб-сервис от Сбера для совместной разработки и хостинга кода, который позволит разработчикам создавать проекты с открытым и закрытым кодом и привлекать новых участников к развитию своих решений с минимизацией рисков ухода вендоров с российского рынка.
Kubernetes-платформы и Platform Engineering: у Flant уже есть огромный опыт и собственные решения, чтобы не "велосипедить".
Российская Java: с ней всё хорошо, потому что есть Axiom JDK.
Благодарим всех докладчиков и коллег, кто принял участие в подготовке трека DevOps, кажется, у нас отлично получилось и желаем нам всем в будущем еще больше крутых совместных мероприятий и проведения отличных конференций.
По следам дискуссии…
Вопросы панельной дискуссии очевидно остаются открытыми для обсуждения. И нам кажется, что для обсуждения подобных проблем и вопросов нужна какая-то отдельная площадка. Площадка далеко за пределами Сбера или другой организации. Скорее некоторое кросс-организационное DevOps-сообщество. Что вы об этом думаете и какую ценность мы можем получить? Поделитесь мнением, пройдите короткий опрос.