es
Feedback
DevOpsConf Channel

DevOpsConf Channel

Ir al canal en Telegram

Информационный канал профессиональной конференции по интеграции процессов разработки, тестирования и эксплуатации https://devopsconf.io Чат @DevOpsConfTalks

Mostrar más
1 973
Suscriptores
+124 horas
-37 días
-330 días
Archivo de publicaciones
🖐 Дорогие участники, в 17:00 ждём вас на последних докладах DevOpsConf 2024 ⠀ 🔸 Зал «Конгресс-холл». Кирилл Ильин и Артем П
🖐 Дорогие участники, в 17:00 ждём вас на последних докладах DevOpsConf 2024 ⠀ 🔸 Зал «Конгресс-холл». Кирилл Ильин и Артем Поддубный (СберАвто) «Все как код» Из доклада вы узнаете, как сделать архитектуру ваших сервисов в виде кода и как на это наложить техники из матрицы MITRE ATT&CK для оценки безопасности продуктов. ⠀ 🔹 Зал «Кейптаун». Алексей Шкирмановский (Vi.Tech) «Переходим на мульти-ЦОД-архитектуру» Рассказ о том, когда архитектура решения с двумя ЦОДами может не подойти и почему. И что надо учесть вашему бизнесу и вашим сервисам, если захотелось жить в трёх. ⠀ 🔸 Зал «Сингапур». Максим Бочкарев (ЕВРАЗ) «DevOps в металлургии, история про большие и сложные задачи IТ в производственной отрасли» Из доклада вы узнаете про пройденный путь и развитие DevOps в реальном секторе, опыт взаимодействия с консультантами и интеграторами, внедрение и развитие Azure DevOps, стандартизацию, автоматизацию проектов и процессов в разработке и эксплуатации. ⠀ 🔹 Зал «Уфа». Максим Нифонтов (Programming Store) «DevOps приходит в 1С» Доклад содержит разбор инструментов для построения DevOps в 1С, но культура DevOps забыта тоже не будет. Если вы работаете где-то рядом с реальным сектором и хотите помочь коллегам улучшить жизнь в 1С, то обязательно приходите! 🔸 Зал «Дели+Калькутта». Илья Лесиков (Флант) «От доработки Helm к разработке Nelm: эволюция развертывания в werf» Helm стал стандартом упаковки приложений для Kubernetes. Но так ли он хорош, как кажется на первый взгляд? Какие проблемы есть в Helm и как их решить? Nelm — движок развертывания в werf, в будущем — drop-in-замена Helm, решит многие проблемы Helm и добавит недостающие ему возможности. ⠀ 🔹 Зал «Пекин». Антон Гаврилов (Инфосистемы Джет) «Kyverno: старт без грабель» Данный доклад будет отличным началом погружения в тему PolicyEngines на примере инструмента Kyverno и его возможностей.

Mensaje de video00:19

✋ Друзья, если вы были на докладе Антона Алексеева и по техническим причинам у вас не получилось проголосовать за доклад, про
✋ Друзья, если вы были на докладе Антона Алексеева и по техническим причинам у вас не получилось проголосовать за доклад, пройдите, пожалуйста, по ссылке, чтобы поставить оценку: https://conf.ontico.ru/online/dc2024/details/5393175

В 16:20 приходите в Зал «Шанхай» на мастер-класс от Ирины Николаевой (Raft) «Локальные LLM: как с легкостью применять большие
В 16:20 приходите в Зал «Шанхай» на мастер-класс от Ирины Николаевой (Raft) «Локальные LLM: как с легкостью применять большие языковые модели в ежедневных задачах» ⠀ Искусственный интеллект ближе, чем кажется! Присоединяйтесь, чтобы узнать, как использовать открытые локальные LLM в повседневной работе на твоём обычном ПК. Откроете завесы над миром LLM-моделей и попробуете их в бою для анализа ошибок и поиска решений, соблюдая лицензии и требования к оборудованию. ⠀ ✋ Обратите внимание, что на данный мастер-класс необходим свой ноутбук.

Mensaje de video00:25

Mensaje de video00:18

🖐 Ловите анонс докладов, которые начнутся в 15:50 ⠀ 🔸 Зал «Конгресс-холл». Анна Гобрусева (Ozon) «Alerts-Registry. Одно мес
🖐 Ловите анонс докладов, которые начнутся в 15:50 ⠀ 🔸 Зал «Конгресс-холл». Анна Гобрусева (Ozon) «Alerts-Registry. Одно место управления алертами» Доклад для тех, кто уже построил у себя систему алертинга и упёрся в проблемы её сопровождения. Как определять/удалять неактуальные алерты, как их версионировать, etc... ⠀ 🔹 Зал «Кейптаун». Александр Бычук (VK, VK Tech) «Open Source как часть R&D» Мы тут ждём рассказ про то, сколько на самом деле стоит свободное ПО и как принимать решение о том, покупать или брать бесплатное и допиливать. ⠀ 🔸 Зал «Сингапур». Михаил Марченко (билайн) «Путь от "хаоса" к облачной инфраструктуре» Доклад про развитие и эволюцию инфраструктуры и внутренней разработки в большом телеком-операторе, про переход к внутреннему облаку, автоматизацию и предоставление платформенных сервисов. ⠀ 🔹 Зал «Уфа». Константин Ожерельев (Ozon) «DevOps для 1C-приложений» Превосходный обзорный доклад про DevOps и 1С. Как и зачем совместить, на первый взгляд, несовместимое. Рекомендуется, если вы DevOps и хотите расширить кругозор. 🔸 Зал «Дели+Калькутта». Георгий Абрамов (АО "СберТех") «CUE — лучшая альтернатива для работы с манифестами K8s» Если вы испытываете трудности с использованием Yaml, Helm или Kustomize, то этот доклад о CUE будет вам полезен. В нем рассказывается о базовых принципах работы с CUE и о том, как начать использовать этот инструмент. ⠀ 🔹 Зал «Пекин». Сергей Губарев (Cloud.ru) «Подготовка SecChamp’ов: как обработать все проблемы и не сойти с ума» В данном докладе вы узнаете, как в Cloud.ru попытались решить проблему отсутствия большого количества AppSec-специалистов, обучить команды и переложить на них задачу работы с инструментами безопасной разработки на команды.

Mensaje de video00:19

Mensaje de video00:17

Mensaje de video00:19

В 15:00 в Зале «Шанхай» вас ждёт Александр Титов (Экспресс 42) на круглый стол «Облака, вендор или делать все самому? Как стр
В 15:00 в Зале «Шанхай» вас ждёт Александр Титов (Экспресс 42) на круглый стол «Облака, вендор или делать все самому? Как строить Platform Engineering в компании» Круглый стол для тех, кто хочет набрать мнений в поддержку своей идеи про «построить своё, взять саас или купить у вендора». В целом полезно даже для инженеров, чтобы понимать, что иногда можно не строить своё, а просто купить.

Опрос выявляет неожиданное. Первый опрос показал, что в красной зоне линтер, которым сами гордились: оказалось, что пользователи недовольны, потому что он тормозит. И они запустили проект ускорения. Но они бы никогда не поняли причину красной зоны, если бы не было окошка в конце - именно туда писали, почему не довольны. Следующий опрос, в красной доне БД, это ожидаемо, потмоу что некоторое время назад сделали zero-trust политики, стало неудобнее. Но оказалось, что только половина в zero-trust, а вторая половина - flow, если что-то не сработало - неясно как разбираться. И эту часть можно решить, сделали проект с dba. Разработчик готов мириться с неудобствами, но только если они редки. Часто повторяющиеся операции должны быть безупречны. Лучше сделать проще, но понятно и предсказуемо. Опросы - просты, можно дать навигацию, пользователи получют фичи. Недостатки: низкая конверсия и люди устают. Раз в квартал - это часто, стали делать раз в полгода. А еще helicopter view от опросов - ограничен. Надо делать follow up и custdev А дальше они хотят Instant feedback - ловушки для негатива для ключевых customer journey. Не длинный опрос, а точечная оценка и быстрый feedback. По свежему опыту использования фичи. Но есть слабые места: есть CLI-точка входа, там 800 пользователей - там нельзя показать форму, есть долгий customer journey - когда спрашивать? И можно задолбать. Поэтому присылают запрос в mattermost - оцените CJM, и не чаще, чем раз в неделю. В отчетах на вопросы звучала популярная тема: ваша платформа скрывает внутренность сборки от разработчиков, и они перестают понимать, как оно устроено, не учатся думать. Ответ - понятен: платформа убирает рутинную часть и это дает реальный эффект на скорости разработки, который перевешивает побочные эффекты. А я тут могу заметить, что аналогичные вопросы я слышал по другим поводам. Первый раз - когда появлялись реляционные базы данных, с которыми ты работаешь на SQL, не заботясь о хранении: как же так, разработчик не будет думать про эффективность запросов (я еще работал на dbase без sql). А второй раз - с появлением Java и C#, которые скрыли управление памятью от разработчика. В обоих случаях оказалось, что эффект от скрытия - значителен, и хотя учитывать устройство под капотом - нужно, этим могут заниматься отдельные высококвалифицированные люди. Так будет и здесь.

#DevOpsConf Илья Барбашов из Авито. Developer Experience: обзор подходов и как мы их применяем. Доклад был четко из двух частей: теории о метриках продуктивности разработки и практика повышения этой продуктивности на основе общих механизмов продуктового подхода, примененного к разработке платформы. Связь первого и второго - сильно пунктиром. И тут отдельный вопрос - насколько эти теории все-таки помогают, что делают лучше? Контекст: в авито 2500 инженеров, 1800 микросервисов. Платформа покрывает все от создания и разработки сервиса до выкатки и эксплуатации, содержит реестр сервисов и библиотек, связей, решение типовых задач в микросервисной архитектуре. Платформа 5 лет в разработке, очевидные задачи - решены. При этом не известно, насколько мы хороши, есть много идей фич, но профит от них их - неясен, а хочется понимать заранее. И нет product manager - эту роль выполняет сама команда, тимлиды. Итого: непонятно в какую сторону работать. А хотелось бы иметь ориентиры, например, метрика. Поискали метрики в индустрии. * DORA 4 метрики: как часто катите, как быстро докатываете до прода, как часто падаете, как быстро восстанавливаете. И у них есть квалификация low - medium - high - elite. У них платформа позволяет работать на уровне elite, улучшения лежат уже в русле команд. А там идет работа по team maturity model компании * SPACE: Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency and flow - всеобъемлющий, но применение неясно * Три изменения DevEx: Flow state, cognitive load, feedback loop. Более практичен, и это не CAP-теорема, можно все три улучшать. Flow State: если инженера прерыват встречи, срочные задачи и блокеры, автономность выбора инженером задачи, понятные цели и задачи проекта - чтобы выбирать, интересные задачи. Не решается техническими средствами, это организация. В avito есть playbook, он это как-то решает. Cognitive load: насколько надо напрячь мозг, чтобы эту задачу сделать. Непонятный фреймворк или технология, новый бизнес-домен и так далее. Делится на два типа: полезная, которая бьет в решение задачи, и паразитная - нечеткие требования и дополнительные знания, например, кубовые манифесты. Платформа снижает типовые задачи, чтобы разработчик не думал о кубернетисе, о том, что интеграция сломается - есть проверки, можно посмотреть любой сервис и так далее. Feedback Loops: все действия, которые надо делать разработчику пока решает задачу. Компиляция, циклы запуска тестов и так далее. И pull request при итеративном code review. CI. Итеративные согласования, например, с безопасниками. Количество циклов, вероятно, убрать не сможем, а скорость повысить - да. Они здесь работают через стандартизацию - стандартизирвоанный CI/CD, линтинг, среда разработки с автоматической настройкой зависимости. Среда может поднять для тестов все зависимости, шины данных, базы данных - если нужно для тестов. Но дальше вопрос: как эту историю мерить? Фреймворк рекомендует три метрики: ощущаемая легкость разработки, ощущаемая удовлетворенность разработчиков, ощущаемая продуктивность. Это все - субъективно. И на этом часть про теорию заканчивается, и начинается история про практику. Которая начинается с CustDev, при котором понимаешь реальное использование платформы пользователем и их проблемы. Он эффективен, но дорог. Поэтому дополняем его опросом пользователей. Google-форма с фичами, по каждой оценки: не использую, если использую - удовлетворенность от очень недоволен до очень доволен. И обязательно поле для свободного фидбэка, по опыту половина людей пишут содержательно. Где взять список вопросов? Плохая мысль - попросить это сделать команды разработки платформы, потому что у них представление по устройству платформы, а пользователь использует иным образом. Поэтому берем CustDev и вопросы - по путям пользователя.

🖐 Друзья, в 14:40 вас ждёт следующий поток докладов: ⠀ 🔸 Зал «Конгресс-холл». Злата Занина (Независимый эксперт) «Руководст
🖐 Друзья, в 14:40 вас ждёт следующий поток докладов: ⠀ 🔸 Зал «Конгресс-холл». Злата Занина (Независимый эксперт) «Руководство по внедрению практик и процессов на примере Trunk Based Development» В докладе приводятся необходимые шаги для внедрения новых для команд(ы) практик и процессов, проблемы, с которыми можно столкнуться на каждом из этапов, и их решение на примере внедрения TBD в нескольких организациях. ⠀ 🔹 Зал «Кейптаун». Евгений Коваленко (Лига Цифровой Экономики) «ГосТех Cookbook» Из первых рук — про реальные нюансы и подводные камни новой платформы. ⠀ 🔸 Зал «Сингапур». Сергей Обожин (МТС Digital) «Как мы меняли DevOps в телекоме» Первое выступление про состояние DevOps в экосистеме МТС. Из доклада вы узнаете про развитие процессов и практик, используемые инструменты и метрики, взаимодействие с внутренним сообществом. ⠀ 🔹 Зал «Уфа». Екатерина Лысенко (RoboGate) «Неизбежность, или Как приучить Devops-инженеров к проектированию» Доклад про взгляд на DevOps и эксплуатацию с точки зрения архитектуры. Рекомендуем для всех, кто по работе, помимо технологий, занимается построением процессов работы и управлением бэклогом команды. 🔸 Зал «Дели+Калькутта». Андрей Важенин (Skyeng) «Тестовая инфраструктура "Так исторически сложилось"» Доклад о платформе для тестирования от Skyeng. Довольно много велосипедов внутри, повторить в точности не удастся, поэтому ПК считает, что сюда можно сходить за чужим опытом развития платформы в большой компании и за идеями для развития своей платформы. ⠀ 🔹 Зал «Пекин». Лев Хакимов (Wildberries) «Hardening Jenkins: как подать блюдо, чтобы оставили чаевые» Вы должны послушать этот доклад, если у вас jenkins. Докладчик подсветит все возможные проблемы с безопасностью, и после этого доклада у вас будет чёткое понимание того, на что вам нужно обратить внимание в ваших инсталляциях.

Mensaje de video00:41

Mensaje de video00:16

Mensaje de video00:40

Mensaje de video00:16

🔸 Зал «Дели+Калькутта». Павел Воробьев (YADRO) «От молекул до галактики. Организация общего пространства для Ansible-контента» ⠀ Доклад поведает о том, как выстроить процесс кросс-командной разработки общих ролей Ansible. В том числе о том, как подойти к тестированию и публикации ролей. ⠀ 🔹 Зал «Пекин». Игорь Захарин (Сбер) «Реализация Kerberos в Kubernetes/Istio Service mesh» ⠀ Уникальный контент — kerberos в кубере вместе с service mesh. Скорее всего, вам это не нужно, но ПК загипнотизирован сочетанием и хочет поделиться с вами. ⠀ 🔸 Зал «Шанхай». Круглый стол «FinDevSecOps или безопасная разработка в финтехе: перспективы, вызовы и совместные планы» ⠀ Вместе с экспертами вы обсудите вопросы безопасной разработки и коллаборации между различными крупными игроками финансовой отрасли. Мы убедились, что у всех участников разные мнения по всем вопросам, поэтому должно быть интересно.

🖐 Следующие доклады и круглый стол ждут вас в 13:30 ⠀ 🔸 Зал «Конгресс-холл». Алексей Федулаев и Александр Хамитов (Wildberr
🖐 Следующие доклады и круглый стол ждут вас в 13:30 ⠀ 🔸 Зал «Конгресс-холл». Алексей Федулаев и Александр Хамитов (Wildberries) «Безопасность CI/CD в условиях компрометации» ⠀ Представьте, хакер взломал ваш Гитлаб. Ребята в Wildberries озадачились этой проблемой и хотят показать на своем опыте, чего они достигли в ее решении. ⠀ 🔹 Зал «Кейптаун». Владимир Утратенко (Uzum Market) «Древние свитки CI/CD: смыслы, которые мы потеряли» ⠀ Доклад для тех, кто считает, что CI/CD — это просто написать пачку YAML'ов. Это возврат к рассказу о базовых вещах — что такое и зачем нужен CI, что такое и зачем нужен CD. И да, это не просто сборка кода при создании pull request и деплой по кнопке, а много чего, кроме этого. ⠀ 🔸 Зал «Сингапур». Татьяна Зуева (Точка) «Как мы платформу на существующие процессы натягивали» ⠀ Из выступления вы узнаете про путь развития внутренней платформы для разработчиков в Банке Точка. Татьяна расскажет про продуктовый подход, продажу платформы, изменения процессов, интеграцию сервисов, ролевую модель, дизайн и разработку внутреннего портала. ⠀ 🔹 Зал «Уфа». Кирилл Пономарев (Райффайзен Банк) «Почему я виню no blame culture» ⠀ Докладчик анализирует ситуации, когда эта культурная практика может оказаться неэффективной и скрывать реальные проблемы. Обсуждаются возможные последствия, когда конфликты не находят своего разрешения из-за чрезмерного применения no blame culture. ⠀ ⤵️⤵️