Участники конференции, задавайте вопросы спикеру в чатах залов:
⠀
🔹 Зал Конгресс-Холл
⠀
🔸 Зал Кейптаун
⠀
🔹 Зал Сингапур
⠀
🔸 Зал Уфа
⠀
🔹 Зал Дели-Калькутта
⠀
🔸 Зал Пекин
⠀
🔹 Зал Шанхай (не транслируется)
⠀
🔹 Зал Конгресс-Холл
⠀
🔸 Зал Кейптаун
⠀
🔹 Зал Сингапур
⠀
🔸 Зал Уфа
⠀
🔹 Зал Дели-Калькутта
⠀
🔸 Зал Пекин
⠀
🔹 Зал Шанхай (не транслируется)
🖐 Следующие доклады и круглый стол ждут вас в 13:30
⠀
🔸 Зал «Конгресс-холл». Алексей Федулаев и Александр Хамитов (Wildberries) «Безопасность CI/CD в условиях компрометации»
⠀
Представьте, хакер взломал ваш Гитлаб. Ребята в Wildberries озадачились этой проблемой и хотят показать на своем опыте, чего они достигли в ее решении.
⠀
🔹 Зал «Кейптаун». Владимир Утратенко (Uzum Market) «Древние свитки CI/CD: смыслы, которые мы потеряли»
⠀
Доклад для тех, кто считает, что CI/CD — это просто написать пачку YAML'ов. Это возврат к рассказу о базовых вещах — что такое и зачем нужен CI, что такое и зачем нужен CD. И да, это не просто сборка кода при создании pull request и деплой по кнопке, а много чего, кроме этого.
⠀
🔸 Зал «Сингапур». Татьяна Зуева (Точка) «Как мы платформу на существующие процессы натягивали»
⠀
Из выступления вы узнаете про путь развития внутренней платформы для разработчиков в Банке Точка. Татьяна расскажет про продуктовый подход, продажу платформы, изменения процессов, интеграцию сервисов, ролевую модель, дизайн и разработку внутреннего портала.
⠀
🔹 Зал «Уфа». Кирилл Пономарев (Райффайзен Банк) «Почему я виню no blame culture»
⠀
Докладчик анализирует ситуации, когда эта культурная практика может оказаться неэффективной и скрывать реальные проблемы. Обсуждаются возможные последствия, когда конфликты не находят своего разрешения из-за чрезмерного применения no blame culture.
⠀
⤵️⤵️
⠀
🔸 Зал «Конгресс-холл». Алексей Федулаев и Александр Хамитов (Wildberries) «Безопасность CI/CD в условиях компрометации»
⠀
Представьте, хакер взломал ваш Гитлаб. Ребята в Wildberries озадачились этой проблемой и хотят показать на своем опыте, чего они достигли в ее решении.
⠀
🔹 Зал «Кейптаун». Владимир Утратенко (Uzum Market) «Древние свитки CI/CD: смыслы, которые мы потеряли»
⠀
Доклад для тех, кто считает, что CI/CD — это просто написать пачку YAML'ов. Это возврат к рассказу о базовых вещах — что такое и зачем нужен CI, что такое и зачем нужен CD. И да, это не просто сборка кода при создании pull request и деплой по кнопке, а много чего, кроме этого.
⠀
🔸 Зал «Сингапур». Татьяна Зуева (Точка) «Как мы платформу на существующие процессы натягивали»
⠀
Из выступления вы узнаете про путь развития внутренней платформы для разработчиков в Банке Точка. Татьяна расскажет про продуктовый подход, продажу платформы, изменения процессов, интеграцию сервисов, ролевую модель, дизайн и разработку внутреннего портала.
⠀
🔹 Зал «Уфа». Кирилл Пономарев (Райффайзен Банк) «Почему я виню no blame culture»
⠀
Докладчик анализирует ситуации, когда эта культурная практика может оказаться неэффективной и скрывать реальные проблемы. Обсуждаются возможные последствия, когда конфликты не находят своего разрешения из-за чрезмерного применения no blame culture.
⠀
⤵️⤵️
🔸 Зал «Дели+Калькутта». Павел Воробьев (YADRO) «От молекул до галактики. Организация общего пространства для Ansible-контента»
⠀
Доклад поведает о том, как выстроить процесс кросс-командной разработки общих ролей Ansible. В том числе о том, как подойти к тестированию и публикации ролей.
⠀
🔹 Зал «Пекин». Игорь Захарин (Сбер) «Реализация Kerberos в Kubernetes/Istio Service mesh»
⠀
Уникальный контент — kerberos в кубере вместе с service mesh. Скорее всего, вам это не нужно, но ПК загипнотизирован сочетанием и хочет поделиться с вами.
⠀
🔸 Зал «Шанхай». Круглый стол «FinDevSecOps или безопасная разработка в финтехе: перспективы, вызовы и совместные планы»
⠀
Вместе с экспертами вы обсудите вопросы безопасной разработки и коллаборации между различными крупными игроками финансовой отрасли. Мы убедились, что у всех участников разные мнения по всем вопросам, поэтому должно быть интересно.
⠀
Доклад поведает о том, как выстроить процесс кросс-командной разработки общих ролей Ansible. В том числе о том, как подойти к тестированию и публикации ролей.
⠀
🔹 Зал «Пекин». Игорь Захарин (Сбер) «Реализация Kerberos в Kubernetes/Istio Service mesh»
⠀
Уникальный контент — kerberos в кубере вместе с service mesh. Скорее всего, вам это не нужно, но ПК загипнотизирован сочетанием и хочет поделиться с вами.
⠀
🔸 Зал «Шанхай». Круглый стол «FinDevSecOps или безопасная разработка в финтехе: перспективы, вызовы и совместные планы»
⠀
Вместе с экспертами вы обсудите вопросы безопасной разработки и коллаборации между различными крупными игроками финансовой отрасли. Мы убедились, что у всех участников разные мнения по всем вопросам, поэтому должно быть интересно.
🖐 Друзья, в 14:40 вас ждёт следующий поток докладов:
⠀
🔸 Зал «Конгресс-холл». Злата Занина (Независимый эксперт) «Руководство по внедрению практик и процессов на примере Trunk Based Development»
В докладе приводятся необходимые шаги для внедрения новых для команд(ы) практик и процессов, проблемы, с которыми можно столкнуться на каждом из этапов, и их решение на примере внедрения TBD в нескольких организациях.
⠀
🔹 Зал «Кейптаун». Евгений Коваленко (Лига Цифровой Экономики) «ГосТех Cookbook»
Из первых рук — про реальные нюансы и подводные камни новой платформы.
⠀
🔸 Зал «Сингапур». Сергей Обожин (МТС Digital) «Как мы меняли DevOps в телекоме»
Первое выступление про состояние DevOps в экосистеме МТС. Из доклада вы узнаете про развитие процессов и практик, используемые инструменты и метрики, взаимодействие с внутренним сообществом.
⠀
🔹 Зал «Уфа». Екатерина Лысенко (RoboGate) «Неизбежность, или Как приучить Devops-инженеров к проектированию»
Доклад про взгляд на DevOps и эксплуатацию с точки зрения архитектуры. Рекомендуем для всех, кто по работе, помимо технологий, занимается построением процессов работы и управлением бэклогом команды.
🔸 Зал «Дели+Калькутта». Андрей Важенин (Skyeng) «Тестовая инфраструктура "Так исторически сложилось"»
Доклад о платформе для тестирования от Skyeng. Довольно много велосипедов внутри, повторить в точности не удастся, поэтому ПК считает, что сюда можно сходить за чужим опытом развития платформы в большой компании и за идеями для развития своей платформы.
⠀
🔹 Зал «Пекин». Лев Хакимов (Wildberries) «Hardening Jenkins: как подать блюдо, чтобы оставили чаевые»
Вы должны послушать этот доклад, если у вас jenkins. Докладчик подсветит все возможные проблемы с безопасностью, и после этого доклада у вас будет чёткое понимание того, на что вам нужно обратить внимание в ваших инсталляциях.
⠀
🔸 Зал «Конгресс-холл». Злата Занина (Независимый эксперт) «Руководство по внедрению практик и процессов на примере Trunk Based Development»
В докладе приводятся необходимые шаги для внедрения новых для команд(ы) практик и процессов, проблемы, с которыми можно столкнуться на каждом из этапов, и их решение на примере внедрения TBD в нескольких организациях.
⠀
🔹 Зал «Кейптаун». Евгений Коваленко (Лига Цифровой Экономики) «ГосТех Cookbook»
Из первых рук — про реальные нюансы и подводные камни новой платформы.
⠀
🔸 Зал «Сингапур». Сергей Обожин (МТС Digital) «Как мы меняли DevOps в телекоме»
Первое выступление про состояние DevOps в экосистеме МТС. Из доклада вы узнаете про развитие процессов и практик, используемые инструменты и метрики, взаимодействие с внутренним сообществом.
⠀
🔹 Зал «Уфа». Екатерина Лысенко (RoboGate) «Неизбежность, или Как приучить Devops-инженеров к проектированию»
Доклад про взгляд на DevOps и эксплуатацию с точки зрения архитектуры. Рекомендуем для всех, кто по работе, помимо технологий, занимается построением процессов работы и управлением бэклогом команды.
🔸 Зал «Дели+Калькутта». Андрей Важенин (Skyeng) «Тестовая инфраструктура "Так исторически сложилось"»
Доклад о платформе для тестирования от Skyeng. Довольно много велосипедов внутри, повторить в точности не удастся, поэтому ПК считает, что сюда можно сходить за чужим опытом развития платформы в большой компании и за идеями для развития своей платформы.
⠀
🔹 Зал «Пекин». Лев Хакимов (Wildberries) «Hardening Jenkins: как подать блюдо, чтобы оставили чаевые»
Вы должны послушать этот доклад, если у вас jenkins. Докладчик подсветит все возможные проблемы с безопасностью, и после этого доклада у вас будет чёткое понимание того, на что вам нужно обратить внимание в ваших инсталляциях.
👍1
Forwarded from mtsepkov (Maxim Tsepkov)
#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 и вопросы - по путям пользователя.
Контекст: в авито 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 и вопросы - по путям пользователя.
Forwarded from mtsepkov (Maxim Tsepkov)
Опрос выявляет неожиданное. Первый опрос показал, что в красной зоне линтер, которым сами гордились: оказалось, что пользователи недовольны, потому что он тормозит. И они запустили проект ускорения. Но они бы никогда не поняли причину красной зоны, если бы не было окошка в конце - именно туда писали, почему не довольны. Следующий опрос, в красной доне БД, это ожидаемо, потмоу что некоторое время назад сделали 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#, которые скрыли управление памятью от разработчика. В обоих случаях оказалось, что эффект от скрытия - значителен, и хотя учитывать устройство под капотом - нужно, этим могут заниматься отдельные высококвалифицированные люди. Так будет и здесь.
Разработчик готов мириться с неудобствами, но только если они редки. Часто повторяющиеся операции должны быть безупречны. Лучше сделать проще, но понятно и предсказуемо.
Опросы - просты, можно дать навигацию, пользователи получют фичи. Недостатки: низкая конверсия и люди устают. Раз в квартал - это часто, стали делать раз в полгода. А еще helicopter view от опросов - ограничен. Надо делать follow up и custdev
А дальше они хотят Instant feedback - ловушки для негатива для ключевых customer journey. Не длинный опрос, а точечная оценка и быстрый feedback. По свежему опыту использования фичи. Но есть слабые места: есть CLI-точка входа, там 800 пользователей - там нельзя показать форму, есть долгий customer journey - когда спрашивать? И можно задолбать. Поэтому присылают запрос в mattermost - оцените CJM, и не чаще, чем раз в неделю.
В отчетах на вопросы звучала популярная тема: ваша платформа скрывает внутренность сборки от разработчиков, и они перестают понимать, как оно устроено, не учатся думать. Ответ - понятен: платформа убирает рутинную часть и это дает реальный эффект на скорости разработки, который перевешивает побочные эффекты. А я тут могу заметить, что аналогичные вопросы я слышал по другим поводам. Первый раз - когда появлялись реляционные базы данных, с которыми ты работаешь на SQL, не заботясь о хранении: как же так, разработчик не будет думать про эффективность запросов (я еще работал на dbase без sql). А второй раз - с появлением Java и C#, которые скрыли управление памятью от разработчика. В обоих случаях оказалось, что эффект от скрытия - значителен, и хотя учитывать устройство под капотом - нужно, этим могут заниматься отдельные высококвалифицированные люди. Так будет и здесь.
👍1
В 15:00 в Зале «Шанхай» вас ждёт Александр Титов (Экспресс 42) на круглый стол «Облака, вендор или делать все самому? Как строить Platform Engineering в компании»
Круглый стол для тех, кто хочет набрать мнений в поддержку своей идеи про «построить своё, взять саас или купить у вендора». В целом полезно даже для инженеров, чтобы понимать, что иногда можно не строить своё, а просто купить.
Круглый стол для тех, кто хочет набрать мнений в поддержку своей идеи про «построить своё, взять саас или купить у вендора». В целом полезно даже для инженеров, чтобы понимать, что иногда можно не строить своё, а просто купить.
🖐 Ловите анонс докладов, которые начнутся в 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-специалистов, обучить команды и переложить на них задачу работы с инструментами безопасной разработки на команды.
⠀
🔸 Зал «Конгресс-холл». Анна Гобрусева (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-специалистов, обучить команды и переложить на них задачу работы с инструментами безопасной разработки на команды.
В 16:20 приходите в Зал «Шанхай» на мастер-класс от Ирины Николаевой (Raft) «Локальные LLM: как с легкостью применять большие языковые модели в ежедневных задачах»
⠀
Искусственный интеллект ближе, чем кажется! Присоединяйтесь, чтобы узнать, как использовать открытые локальные LLM в повседневной работе на твоём обычном ПК. Откроете завесы над миром LLM-моделей и попробуете их в бою для анализа ошибок и поиска решений, соблюдая лицензии и требования к оборудованию.
⠀
✋ Обратите внимание, что на данный мастер-класс необходим свой ноутбук.
⠀
Искусственный интеллект ближе, чем кажется! Присоединяйтесь, чтобы узнать, как использовать открытые локальные LLM в повседневной работе на твоём обычном ПК. Откроете завесы над миром LLM-моделей и попробуете их в бою для анализа ошибок и поиска решений, соблюдая лицензии и требования к оборудованию.
⠀
✋ Обратите внимание, что на данный мастер-класс необходим свой ноутбук.
🔥1
✋ Друзья, если вы были на докладе Антона Алексеева и по техническим причинам у вас не получилось проголосовать за доклад, пройдите, пожалуйста, по ссылке, чтобы поставить оценку:
https://conf.ontico.ru/online/dc2024/details/5393175
https://conf.ontico.ru/online/dc2024/details/5393175
👌1