🖐 Анонс докладов, которые стартуют в 12:20
⠀
🔸 Зал «Конгресс-холл». Илья Барбашов (Авито) «Developer Experience: обзор подходов и как мы их применяем»
⠀
Единственный доклад про Developer Experience на конференции. Спикер расскажет про первые шаги в измерении и улучшении DX в платформенных командах в Авито, поделится подходами и инструментами для сбора и анализа обратной связи при разработке платформ.
⠀
🔹 Зал «Кейптаун». Татьяна Кыркалова (Независимый исследователь) «Как расспрашивать экспертов, чтобы развиваться профессионально?»
⠀
В IT-сфере новые знания можно получать по-разному, и один из самых действенных способов — через общение с экспертами в своей области. Доклад поможет подготовиться к общению с экспертами и подскажет, как правильно задавать вопросы.
⠀
🔸 Зал «Сингапур». Артём Науменко (Hyperunison) «В чем польза IT-платформы? Как её лучше делать?»
⠀
Из выступления вы узнаете про опыт разработки внутренней платформы для разработчиков в Skyeng и бизнес-платформы в стартапе. Как применять продуктовый подход, какие цели ставить, за какими метриками следить, как снижать сложность, улучшать автоматизацию и опыт взаимодействия с платформой.
⠀
⤵️⤵️

🔹 Зал «Уфа». Антон Устюжанин (Точка) «Несколько реплик приложения — это отказоустойчивое решение?»
⠀
Подробный доклад о проектировании отказоустойчивых систем. Вы рассмотрите разные ситуации и научитесь определять, когда у вас все еще остается единая точка отказа, из-за которой весь проект может оказаться под угрозой. Посмотрите на стоимость обеспечения отказоустойчивости.
⠀
🔸 Зал «Дели+Калькутта». Сергей Куликов (SberAutoTech) «Всё идёт по плану. Как запускать Ansible вовремя так, чтобы все были довольны»
⠀
Доклад поднимает тему, которая ранее не была освещена — какие есть инструменты для запуска ansible-плейбуков. Рассматриваются разные возможности и предоставляется сравнение этих инструментов, так что вы будете иметь полное представление об экосистеме и сможете сделать осознанный выбор.
⠀
🔹 Зал «Пекин». Михаил Кажемский (Hilbert Team) «Secrets Management в зависимости от зрелости инфраструктуры компании: как понять, что пора переходить на новый уровень»
⠀
Существует огромное количество способов управления секретами в инфраструктуре. И если вы еще не определились с тем, какой из них наиболее оптимален для вашей компании с учетом вашего уровня зрелости, то этот доклад для вас!

#DevOpsConf Анастасия Граф. Как организовать базу знаний так, чтобы даже новичок-джун всё смог найти сам? Анастасия - из Maxim Technology, разработка для Taxi Maxim, 350 ИТ-шников распределенная команда по городам России. Доклад развивает тему доклада на #TeamleadConf-2023 (есть конспект в моем отчете), но отличается фокусировка. Тогда был рассказ о процессе и технических способах организовать документацию, а здесь фокус на результат - базу знаний с легким поиском и с соучастием разработчиков в ее поддержке. И основная задача тут - изменение культуры: переход от ситуации, когда тот к кому нужна информации, обращается в чатик или к соседу, к ситуации, когда человек сначала идет за ответом в базу знаний, и только если ответ не нашел идет его искать к соседу или в чатик, а найдя ответ - еще и дополняет базу знаний. Это именно изменение культуры. Но чтобы оно произошло должны быть предпосылки.

4 требования, они были сформулированы на слайде, а потом по каждому шел рассказ.

1) Легко делиться знаниями. Чтобы писали все, а не специально выделенный человек. Для этого надо дать возможность писать всем, в том числе джунам - у них есть вопросы, есть ответы, которые будут полезны следующему джуну. И каждому должно быть понятно, что и как написать, это обеспечивает типизация контента и шаблоны структуры с подсказками по заполнению каждого поля.

Типы страниц: термин; справочник - на каждой странице ответ на один вопрос; страница книги - ответ на сложный вопрос, собранный из простых и ссылок. Страница справочника включает историю изменений, чтобы отличать опечатки от содержательных актуализаций. В шаблон страницы книги зашит фидбэк, сразу.

2) Статья написана понятно читателю. Целевая аудитория часто шире, чем задумываешься. Есть люди, далекие от ИТ, которым тоже интересно не ходить с вопросами к ИТ. И здесь - ревью, обратная связь и легкость изменения. Перевести реакцию из "у вас непонятно" к "мне непонятно это и это".

3) Легко найти нужный материал. Тут есть проблема со сленгом - надо писать понятные названия. А еще работать с метками. У них документацию ведут сами команды, и они образуют дерево статей так как им удобно, в своей логике и ориентируются в своем пространстве. Которая отличается от логике соседней команды. А поиск нужен по всей документации, и метки помогают определить нужный набор страниц. И они помогают делать тематические подборки, на которых собирается вся необходимая информация.

4) Все материалы достоверны и актуальны на текущую дату. Самое сложно реализуемое. Что не надо перепроверять, а если нашел неверное - то заинтересован исправить. Реализуется за счет статусной модели для страниц, и за счет активного применения сборных страниц, которое позволяет править в одном месте. Статус - метка на странице: В работе, Ревью, Опубликована, На корректировку.

Итого, что нужно сделать:
* Дать возможность писать всем, включая джунов. Потому что у него есть что написать, ответить вопросы.
* Типизация контента. Шаблоны для каждого типа. Структуры с подсказками.
* Круг энтузиастов, которые пишут, либо встройка наполнения базы знаний включено в процесс.
* Порядок верификации и обновления. Нужен триггер обновления - когда и по какому алгоритму проверять, и алгоритм поиска устаревших страниц - через различные отчеты.

На этом - все. А мне во время доклада пришла мысль посмотреть на изменение культуры документирования как на процесс уборки и поддержания порядка: (1) есть пространства, где ты при необходимости убираешься сам, (2) есть - где активно сигнализируешь о беспорядке, (3) есть - где лишь жалуешься и страдаешь, а (4) есть - где игнорируешь. И задача - чтобы расширить пространства 1 и 2 каждого членов команды, обеспечив перекрыте всего пространства активистами. Это может дать другой взгляд.

Участники конференции, задавайте вопросы спикеру в чатах залов:
⠀
🔹 Зал Конгресс-Холл
⠀
🔸 Зал Кейптаун
⠀
🔹 Зал Сингапур
⠀
🔸 Зал Уфа
⠀
🔹 Зал Дели-Калькутта
⠀
🔸 Зал Пекин
⠀
🔹 Зал Шанхай (не транслируется)

🖐 Следующие доклады и круглый стол ждут вас в 13:30
⠀
🔸 Зал «Конгресс-холл». Алексей Федулаев и Александр Хамитов (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 или безопасная разработка в финтехе: перспективы, вызовы и совместные планы»
⠀
Вместе с экспертами вы обсудите вопросы безопасной разработки и коллаборации между различными крупными игроками финансовой отрасли. Мы убедились, что у всех участников разные мнения по всем вопросам, поэтому должно быть интересно.

🖐 Друзья, в 14:40 вас ждёт следующий поток докладов:
⠀
🔸 Зал «Конгресс-холл». Злата Занина (Независимый эксперт) «Руководство по внедрению практик и процессов на примере Trunk Based Development»

В докладе приводятся необходимые шаги для внедрения новых для команд(ы) практик и процессов, проблемы, с которыми можно столкнуться на каждом из этапов, и их решение на примере внедрения TBD в нескольких организациях.
⠀
🔹 Зал «Кейптаун». Евгений Коваленко (Лига Цифровой Экономики) «ГосТех Cookbook»

Из первых рук — про реальные нюансы и подводные камни новой платформы.
⠀
🔸 Зал «Сингапур». Сергей Обожин (МТС Digital) «Как мы меняли DevOps в телекоме»

Первое выступление про состояние DevOps в экосистеме МТС. Из доклада вы узнаете про развитие процессов и практик, используемые инструменты и метрики, взаимодействие с внутренним сообществом.
⠀
🔹 Зал «Уфа». Екатерина Лысенко (RoboGate) «Неизбежность, или Как приучить Devops-инженеров к проектированию»

Доклад про взгляд на DevOps и эксплуатацию с точки зрения архитектуры. Рекомендуем для всех, кто по работе, помимо технологий, занимается построением процессов работы и управлением бэклогом команды.

🔸 Зал «Дели+Калькутта». Андрей Важенин (Skyeng) «Тестовая инфраструктура "Так исторически сложилось"»

Доклад о платформе для тестирования от Skyeng. Довольно много велосипедов внутри, повторить в точности не удастся, поэтому ПК считает, что сюда можно сходить за чужим опытом развития платформы в большой компании и за идеями для развития своей платформы.
⠀
🔹 Зал «Пекин». Лев Хакимов (Wildberries) «Hardening Jenkins: как подать блюдо, чтобы оставили чаевые»

Вы должны послушать этот доклад, если у вас jenkins. Докладчик подсветит все возможные проблемы с безопасностью, и после этого доклада у вас будет чёткое понимание того, на что вам нужно обратить внимание в ваших инсталляциях.

#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 и вопросы - по путям пользователя.