Доклады

No-code и low-code инструменты помогают нашему бизнесу и суперполезны для малого бизнеса для экономии ресурсов на тестирование гипотез и поиск разработчиков для проекта. Часто именно по этим причинам разработка замедляется или проект вообще закрывается. Этого можно легко избежать на ранних стадиях, научившись создавать продукты самостоятельно.
Тестирование гипотез обходится слишком дорого. Команды не знают, как проверить гипотезы своего продукта без привлечения разработчиков. Если вам нужно создать новую функцию за 2 недели, чтобы команда могла ее протестировать, такой эксперимент обойдется в десятки тысяч рублей. При этом 90% таких экспериментов можно провести практически бесплатно. От создания MVP без привлечения дорогих разработчиков, создания веб-приложения без использования кода или онлайн-курса.

* Риски при использовании внешних зависимостей.
* Решения для анализа безопасности внешней зависимости.
* Деятельность компании.

* Новые внедрения, новые инструменты для банка со старыми продуктами.
* Процесс переезда на новое.
* Сектор не всегда быстр, но надёжен.

* DevOps: для кого подходит или не подходит.
* Что делать с безопасностью?
* Доступы.
* Архитектура.

* Использование jenkins shared lib на проекте.
* Организация единого пайплайна в jenkins с помощью shared lib.
* Использование технологии jenkins job builder.

Уйти нельзя остаться. Разбираемся с пунктуацией.

Каждый из нас точно бывал в ситуации, когда решение уволиться кажется самым привлекательным и единственным возможным.

Будем разбираться, в каких ситуациях стоит менять работу, а когда лучше остановиться, подумать и попробовать другие варианты развития событий. Я собрала несколько историй о том, как решение не уходить помогло в карьере. А уж если ухода не избежать, расскажу, как это сделать экологично и без ущерба для всех участников процесса.

Параллельно я расскажу, как компании организовать процесс exit-интервью и как правильно себя вести, чтобы потом не было мучительно стыдно.

Кстати, если у вас есть истории, которыми вы готовы поделиться и считаете, что они могут быть полезны другим, пишите razrushana в TG.

Инцидент-менеджмент: история о том, как мы падали, вставали и снова падали, но все же вставали. Ведь все, что нас не убивает, делает только сильнее, и да, о постмортемах нужно не забывать.

Поделимся своим опытом работы с инцидентами, начиная с того, как понимаем, что начался пожар, до его тушения и работы с постмортемами для недопущения повторений случившегося. Покажем свой стандартный скрипт поведения команды во время инцидента и шаблон для постмортема.

Также поговорим о том, с какими трудностями мы столкнулись, решив внедрить данные практики во всем IT, и какой успех нас ждал после внедрения.

В крупных компаниях собеседования часто состоят из разных секций, на которых проверяются разные навыки. Когда-то в Tinkoff собеседование кандидатов на SRE-позиции состояли из 4-х этапов: common engineering questions, basic programming, troubleshooting, system design.

В этом докладе я расскажу подробнее про два последних этапа — зачем нам эти секции и зачем кандидату. Я пройдусь по основным шагами внутри этих секций, сравню их между собой и объясню, почему в итоге у нас остался только этап troubleshooting.

В конце я подведу итоги и дам рекомендации, как готовится и к troubleshooting, и к system design, если вам придется их проходить.

* Написание кастомного HPA-скейлера для бэкенд-приложения в EKS при использовании динамических Istio VS и DR.
* Выведение распределения нагрузки из EKS-кластера на AWS ALB для балансировки по нодам.
* Решение проблемы TLS-шифрования напрямую в Istio SideCar от AWS ALB, минуя Istio Ingress Gateway посредством Custom envoy filter.

Всем нам хорошо известно, что одним из аспектов надёжности является тестирование. За годы разработки в индустрии сформировались практики тестирования классических детерминированных сервисов, где мы можем точно предсказать результат выполнения алгоритма/бизнес-логики.

А что делать, если ваша система — ML-сервис? Результат модели непредсказуем до тех пор, пока не передашь на вход данные и не получишь результат. Но даже зная, как себя поведёт конкретная модель на конкретном датасете, после дообучения мы попадаем вновь в начальную точку, когда мы не можем предсказать результат модели на известном наборе данных из-за изменившихся весов. Ситуация усугубляется, если у вас цепочка моделей, где результат каждой последующей зависит от предыдущей, а значит и ошибка, вносимая одной моделью, заведомо вносит ошибку в последующие модели.

Как гарантировать бизнесу высокое качество в столь неопределенной среде? Взяв в качестве примера несколько систем виртуального ассистента Салют, я расскажу, какую эволюцию мы прошли, какие новые приёмы и метрики придумали для того, чтобы гарантировать качество ML-системы.

При проектировании систем незаслуженно мало внимания уделяется важности API-first-подхода.

По своей сути этот подход является продолжением древней мудрости «месяцы кодирования берегут часы проектирования».

Появление стандартов типа OpenAPI, GraphQL или gRPC позволило соединить кодификацию знаний и предварительное продумывание системы, прежде чем кидаться что-то кодить.

На нашей практике работа со схемами (в нашем случае это OpenAPI) позволяет коллегам из разных миров (яваскрипт, руби, продавцы, продакты) общаться на том языке, который достаточно техничен, чтобы быть превращаемым в исполняемый код, но достаточно высокоуровневый, чтобы все участники общения могли смоделировать будущую систему в голове и найти нестыковки с собственной картиной мира.

Хочу рассказать про наш удивительный опыт внедрения API-first-подхода, который позволил нам:
* разгрести многолетний бардак в API;
* вслед за ним вскрыть массу проблем в дизайне ПО;
* при проектировании новой большой системы устранить массу проблем до написания первых строчек кода и сэкономить минимум год работы.

Итак, вам понадобились сервера.
Арендовать сто один в облаке или купить один свой, спланировать бюджет на год или каждый раз ходить к генеральному с чеком на оборудование?

Каждая компания сталкивается с вопросами планирования ресурсов, будь то уровень гигантов рынка или смузи-стартапа. В Авито мы начинали с аренды виртуальных машин в шведском хостинге под разворачивание самого большого монолита в Европе, а пришли к микросервисной архитектуре на собственном оборудовании в нескольких дата-центрах России, алгоритмизации заказа, стандартам конфигураций и непрерывности поставки оборудования заказчикам. Вся суть в грамотном построении процесса, а не механизма.

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

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

Наш сервис вычисляет инференс моделей машинного обучения в транзакционном режиме. Как БД для наших сервисов мы использовали Cassandra:12 нод по 10 ядер и 32 ГБ памяти.
Немного цифр: среднее число запросов 1000 RPS, в пиковых нагрузках — 1200 RPS, ежедневная загрузка данных 800 ГБ, нагрузка на базу — от 50 000 до 100 000 RPS.

В начале 2020 г. мы столкнулись с пределами масштабирования: перестало хватать кластеров, появились всплески latency (из-за garbage collection), фантомные данные, увеличилось время загрузки (11-12 часов). У нас был выбор: масштабироваться за счет железа (но с каждым разом это будет все дороже, и есть предел) или мигрировать. Мы выбрали миграцию базы с Cassandra на Scylla DB и думали, что мигрируем за пару спринтов...

Расскажем, как инсталлировали кластеры, делали реплики, настраивали мониторинг и где возникли проблемы, из-за которых все растянулось на 4 месяца.

• Облако сильно отличается от on-prem: вместо прогнозируемого на длительный период бюджета на инфраструктуру, которым управляют CEO, CFO и CTO, мы имеем дело с переменными расходами, которыми управляют простые инженеры.
• В облаке решения рядовых инженеров (например, выбор AMI-образа, типа узлов Kubernetes кластера и т.п.) могут влиять не только на размер чека за облако в конце месяца, но и на маржинальность бизнеса.
Бизнесу необходимы инструменты для контроля эффективности их IT-инфраструктуры.
• FinOps — это методология и основанные на ней практики и инструменты для повышения эффективности IT-инфраструктуры.
• FinOps позволяет сместить фокус с «мы тратим X тысяч/миллионов рублей в месяц на облако» в сторону «мы зарабатываем Y тысяч/миллионов рублей в месяц, тратя на облако X тысяч/миллионов рублей в месяц».
• В докладе я расскажу о том, как достигнуть FinOps-нирваны и научиться:
- контролировать облачные расходы в режиме реального времени, определяя тренды и выявляя аномалии;
- оптимизировать облачные расходы как за счет оптимизации числа используемых ресурсов, так и их стоимости;
- определять зависимость ключевых бизнес-метрик и метрик юнит-экономики от стоимости облачной инфраструктуры (например, зависимость выручки и числа Monthly Active Users (MAU) с облачным потреблением).

На Saint Higload 2021 мы рассказали о том, что такое FinOPS, зачем он нужен и как его готовить в облаках. Одним из самых частых вопросов был "Как же применять FinOPS в частном облаке".

Данный доклад расскажет, как реализовать в частном облаке ту часть, без которой FinOPS бесполезен, а именно учёт потребления. При этом основной акцент в докладе будет смещён на то, как минимизировать разработку на языках программирования для создания биллинга PAAS-сервисов и использовать YAML-девелопмент и конфигурации opensource-продуктов, чтобы создать pay as you go-биллинг с минимальным участием команд разработки.

Мы рассмотрим не только биллинг, но и что надо сделать командам разработки прикладных продуктов для его использования, а также квотирование как способ стимулирования командами эффективно потребления ресурсов частного облака.

В ходе данного доклада разберем чек-лист готовности проекта к миграции в k8s, рассмотрим не только технологии, но и процессы внутри команды, необходимые для понимания важности процесса миграции в k8s.

Для команд, которые находятся в начале пути разработки, которые разрабатывают давно свои решения или даже находятся в стадии планирования, в ходе доклада я помогу ответить на вопросы:
1) Что требуется от команды для переезда.
2) Что требуется от проекта для переезда.
3) Надо ли вам это и стоит ли вестись на хайповые слова.

В своём докладе я расскажу о том, как мы развивали нашу систему управления триггерами и нотификациями.

Первоначально все операции производились вручную через графический интерфейс, но это было неудобно и плохо масштабировалось. В какой-то момент мы приняли решение изменить подход к управлению триггерами и нотификациями на использование декларативных описаний (.yaml).

Приходите на доклад, и вы узнаете:
* как мы управляем алертингом для более чем 3000 сервисов;
* как мы управляем алертингом для всей инфраструктуры;
* как организован процесс мониторинга 24x7;
* продемонстрирую работу нашего тестового стенда в режиме реального времени;
* расскажу, как этот тестовый стенд вы можете запустить у себя буквально за две минуты.

Все продемонстрированные решения находятся в open source.

В докладе расскажу, как устроен мониторинг в Ozon в целом, и как мы организовали мониторинг CronJob в Kubernetes на базе готовых решений Prometheus-Thanos-Grafana и Kube-state-metrics при наличии давно сформированной инфраструктуры мониторинга. Нашей целью было внедрить новые инструменты с минимальным влиянием на разработчиков, но при этом получить максимум с точки зрения мониторинга.

В результате у нас получился полноценный инструмент мониторинга CronJob, который предоставляет как базовые алерты и агрегации, так и дает возможность репортить свои метрики. Значительно сократили время реагирования на инциденты, где участвуют Сronjob.

Доклад будет наиболее полезен тем, кто развивает инфраструктуру мониторинга, кто эксплуатирует большое количество CronJob в Kubernetes, кто давно мечтал собирать метрики с CronJob.

* Мониторинг в компании, которая живет духом стартапа, подвержен быстрому накоплению технического долга.
* Один инструмент мониторинга для всего не будет выполнять все функции хорошо и оставаться прозрачным и легким в поддержке. Много инструментов — точно будет зоопарк. Нужен баланс, а точнее, процесс во взаимодействии нескольких инструментов, где каждый четко выполняет свою работу.
* Мониторинг, выстроенный командой эксплуатации, только эксплуатации и будет помогать, не компании. Так не годится, нужен вклад и со стороны разработки.
* Обработка алерта не заканчивается на этапе его передачи ответственной команде. Конец тогда, когда проблема решена и, в идеале, понятна причина.
* Цель проекта "Serenity" — правильная реакция на проблемы за считанные минуты и возможность их устранения по "данным приборов".

* Почему observability — это необходимость для Банка, а не прихоть.
* Современная концепция observability — больше, чем просто метрики, трейсы и логи.
* C какими сложностями мы столкнулись при построении observability системы.
* Как мы получили видимость 500 микросервисов в 15 продуктовых командах за 1 месяц.
* Какую пользу это принесло продуктовым командам, командам разработки и сопровождения.
* Результаты внедрения observability в Банке.

Многие сталкиваются со сложными, составными алертами. Когда для принятия решения о том, что произошла ситуация, требующая вашего внимания, вам надо получить данные из разных источников — базы данных, prometheus, стороннее API и т.д. И, разумеется, хочется это автоматизировать.

Расскажу, как решать подобные проблемы с помощью инструмента Balerter.

Конфигурация, написание скриптов, которые будут автоматически выполняться. Отправка уведомлений в разные каналы — от мессенджеров до звонка на телефон. Написание тестов для контроля работоспособности скриптов.

Расскажу, почему лучше один раз СДЕЛАТЬ чем 100 раз ДЕЛАТЬ.

* Хотите свести к минимуму поддержку процессов сборки кода и деплоя?
Поговорим о том, как защитить gitlab-ci-файл от изменений разработчиком, к примеру, добавление своих переменных или дополнительных job. Создаем универсальный gitlab-ci-файл и подключаем сервис к CI/CD за 3 клика.
* Откатываемся на 100% рабочую версию.
Profit версионирования, или Как мы скрестили кодовую базу и helm-чарты.
* Решаем проблему лени и через API Gitlab.
Расскажу и покажу на примерах, как настроить репозиторий без рук.
* Как не сломать то, что уже работает.
Автопроверка пересечения путей api gateway при высоком темпе роста количества микросервисов.
* Доверяем, но проверяем.
Контролируемый деплой по кнопке в pipeline и разграничение прав на запуск job.
* С утечкой памяти пусть разработчики сами разбираются!
Как разработчику дать возможность дебажить запущенный уже в PROD-окружение сервис самостоятельно, используя только кнопку в pipleline.

Kubernetes — это хорошо, я их сам очень люблю и использую. Но будем честны друг с другом: сложно научить всех разработчиков грамотно использовать кубы.

В докладе я расскажу, как мы уже много лет разворачиваем для наших разработчиков инфраструктуру по деплою кода с помощью git. Кроме обзора доступных нам в 2022 году инструментов, я подробно разберу этот своеобразный "dogfooding": поддержку GitOps-инфраструктуры с помощью инструментов GitOps, покажу, как мы работаем с Cluster API и Crossplane, как можно избавиться от Terraform или Ansible при развертывании кластера для нового проекта.

Helm является стандартом для доставки приложений, он позволяет очень гибко и тонко настраивать CI для приложения. В то же время от проекта к проекту используются паттерны. Расскажу о том, как мы разработали "универсальный" чарт, почему им пользуемся, какие есть плюсы и минусы, покажу, как его применить на практике.

Когда мы делали IaC в одной из компаний, то подошли с точки зрения разработки: взяли двух человек с опытом разработки, поставили старшего разработчика в роли заказчика и начали пилить свою истинную Infrastructure as Code с помощью Ansible. В итоге мы сделали внутренний продукт “infra as code”, создали конвенции и стандартизировали разработку. Все в нашем маленьком мире работало по стандарту качества, который мы сами придумали и поддерживали.

Но на деле — мир большой, и есть различные решения. Пообщавшись с разными компаниями о подходах и использовании Ansible, проблемах и практиках, я понял, что стандартов разработки практически нигде нет, а также столкнулся с новыми испытаниями и нашел способ улучшить наш первоначальный подход. Теперь готов поделиться доработанной версией.

* Поговорим про важность проектирования систем и что происходит, если задумываться об этом мало или не думать совсем.
* Разберем 5 принципов Infra as Code, которые помогут пресечь проблемы на корню и сберегут ваше время на борьбу с последствиями.
* Обсудим, как тратить меньше времени на эксплуатацию и зачем тратить больше времени на разработку.

Как сделать из Ansible плохой инструмент? Очень легко: он дружелюбен и прощает слишком многое.
Как сделать из Ansible хороший инструмент? Тоже очень легко: выслушать и осмыслить этот доклад.

В настоящее время Ansible уже не просто зрелый инструмент, а "золотой стандарт" автоматизации. К сожалению, с широким распространением всё чаще встречаются Ansible-решения, не просто требующие, а отчаянно нуждающиеся в улучшениях.

В этом докладе хочу провести ничем не прикрытый ликбез, чтобы показать, чем именно "и так сойдёт" отличается от "нормально делай — нормально будет" (здесь представьте популярные в интернете стикеры).

Обсудим некоторые широко распространённые ошибки, а также способы их устранения:
1. Использование шаблонов со структурированными форматами данных;
2. Нарушение абстракций инструмента;
3. Использование модулей с внешними Python-зависимостями;
4. Создание множества ролей для одного компонента;
5. Управление пользователями с помощью Ansible,
6. И, конечно же, разное-всякое-другое...

Когда мы в Tarantool столкнулись с задачей настройки мониторинга для сдачи проекта заказчику, мы решили её с помощью grafonnet. Это библиотека для написания дашбордов Grafana с помощью кода на языке jsonnet, которая заметно облегчила нам жизнь.

Через призму нашего опыта я хочу осветить положительные и негативные моменты такого подхода, а также познакомить с основными принципами работы с grafonnet. Приходите, и мы вместе постараемся выяснить, есть ли место этому инструменту в вашем энтерпрайзе.

* Как настроить защищенный доступ (TLS) к Vault.
* Как предоставить доступ к Vault во внутренней сети в облаке.

* Тренды Cloud only и Cloud Native в стартап-среде.
* Темная сторона безопасности Cloud Native.
* DevSecOps: от принципов к действиям.
* Безопасный конвейер разработки.
* SSDLC: с чего и как начать выстраивать процессы и коммуникации внутри команды.
* Who is who в процессе SSDLC.

В своем докладе я расскажу о том, как мы внедряли инструмент DevSecOps в production-кластер k8s для контроля параметров ресурсов. Какие вводили политики, чем руководствовались при их создании, и о том, как написали свой инструмент для мониторинга нарушений с функцией оповещения разработчиков и сопровождения при деплое.

Разберемся в набирающей популярность теме — CI/CD Security или Pipeline Security.

Какие есть угрозы, направленные на процесс сборки и развертывания? Как небезопасно настроенный пайлпайн может скомпрометировать всю PROD-среду? Почему, если CI/CD настроен некорректно, практики DevSecOps теряют абсолютно свой смысл? Как сделать ваши CI/CD безопасными?

Для всего есть ответы, исходящие из опыта, с полезными ссылками на сторонние ресурсы.

В этом году мы узнали новый окрас открытого программного обеспечения в виде термина protestware — ситуации, когда в открытые компоненты встраивается вредоносный код или протестные лозунги.

Многие начали задумываться, как же уберечься от этого и какие существуют средства защиты, и оказалось (!), что и проблема не нова, да и большая часть средств предотвращения уязвимых пакетов давно существует.

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

Поговорим о том, какие есть проблемы безопасности в стандартном контейнерном приложении — обсудим безопасность при использовании Docker, Kubernetes и Terraform. Разберём на примерах, как можно встроить проверки в стандартный pipeline выкладки. Поднимем также ставшие актуальными проблемы новых дней.

Доклад начального уровня про процессы IT security, которые можно внедрить и поддерживать своими силами.

Основные темы, которые будут рассматриваться:
* безопасность в современных реалиях. Почему теперь это нужно и большим, и маленьким.
* CIS CSC v8 — что это такое и зачем нужно?
* Уровни цифровой гигиены контура.
* Базовые процессы ИТ-безопасности и их приоритизация.
* На пути к совершенству: расширенный набор контролей.
* Контроли для зрелых команд и компаний и когда они нужны.
* Сделал и всё? Не совсем.

Команда DevOps становится важнейшим элементом бизнеса во всех компаниях, если вы не хотите проиграть конкурентам в гонке за Time-to-Market. Итак, вы выстроили идеальный DevOps и тут приходит она... Безопасность. Кажется, она только замедляет процесс и заставляет делать лишнюю работу, не так ли?

Наличие централизованной службы безопасности с узкими компетенциями в безопасной разработке (SDLC или SDL) может быть роскошью для средних компаний, а в крупной — их точно не хватит на все проекты. Нужно ли инженерам DevOps изучать все про уязвимости, стандарты, нормативку и инструменты безопасности? Ответ — нет, по крайней мере для baseline: предоставлять максимально надежные и безопасные продукты своими силами (принцип 80/20). Если ты DevOps-инженер, разработчик, тимлид или тестировщик — этот доклад для тебя.

Мы поговорим о том, откуда вообще берутся уязвимости, с чего начать Sec в DevOps, про базовые инструменты и "грабли" Sec в DevOps, а также Истории успеха DevOps-команд благодаря Sec.

* Как перестать коммитить ключи AWS в Git.
* Как жить без Hashicorp Vault в маленькой компании или собственных проектах.
* Практические примеры использования aws-vault.
* Эмуляция AWS для локальной разработки.

Команды безопасности уже озадачены тем, как автоматически реагировать на те или иные многочисленные события безопасности в их инфраструктурах. Для этого даже придумали целый класс решений как SOAR (Security Orchestration, Automation and Response).

В рамках данного доклада мы посмотрим, а можно ли и сложно ли это сделать в Kubernetes-инфраструктурах, где все меняется и развивается очень быстро, и при этом опираясь на OpenSource-решения.

Ситуация «он и меня посчитал», описанная в сказке Альфа Прёйсена и её экранизации, связана с психологическим феноменом оценивания, стрессом, который вызывает у индивида осознание ситуации, что он стал объектом чьей-то оценки.

Команда — важнейшая составляющая любого бизнес-процесса, поэтому невозможно не оценивать эффективность ее работы. Когда вы — внешняя команда, то нужно также балансировать в реалиях постоянно меняющихся проектов, как оценить работу, чтобы избежать излишнего стресса для сотрудника, дополнительных трудозатрат на формирование метрик и при этом показать эффективность для заказчика/бизнеса. Разберем на примере одного реального кейса нашего клиента, поделимся нюансами нашего подхода в проектах, где все горит, нет SLA, а посчитать результат все равно нужно.

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

В докладе я расскажу, как этот термин понимается и применяется в Циан, чем занимается моя команда, какие зоны ответственности у смежных. В итоге подискутируем на тему, могу ли я называть себя DevOps-инженером, если не умею сетапить Kubernetes.

Обычно мы привыкли под стратегией понимать некий большой и «страшный» документ, где описан план развития компании. Но в случае с DevOps это некоторое видение, шаги и паттерны, подсказывающие нам, как компания из точки А придет в точку Б. Без этого мы получаем, как правило, эффект «слепых улучшений», когда бесконечно внедряем практики DevOps, но на что они влияют и какую ценность несут — не знаем.

В данном докладе я расскажу:
1. что такое DevOps-стратегия и почему она так же важна, как ИТ-стратегия;
2. как составить DevOps-стратегию для своей компании (особенно с высоким уровнем гетерогенности среды), на что обращать внимание и как довести до реализации;
3. про то, как создавать платформы и временные change-команды. Какие существуют модели DevOps-платформ и какую мы выбрали в MOEX;
4. какие есть подходы и модели унификации конвейеров разработки и инфраструктуры. Что такое архитектура CI/CD и причем тут фича-ориентированность и клиентоориентированность;
5. как запустить внутренние IT-сообщества с нуля практически без дополнительных ресурсов;
6. почему люди, взаимоотношения и культура очень важны для изменений и развития. Про то, как менять и улучшать инженерную культуру;
7. про опыт Московской Биржи по части трансформации в сторону DevOps.

Что такое DevOps?
Какие этапы вашему бизнесу придется пройти в условиях роста.

Расскажу про:
* закон эволюции и DevOps;
* зачем бизнесу DevOps и какие проблемы он поможет решить;
* небольшой стартап, как чаще всего протекают процессы. Какие могут быть подводные камни;
* бизнес становится успешным — начинается рост: финансовый, масштабов, разработки. Поговорим про плюсы, минусы, варианты действий и дальнейшего развития;
* рост продолжается.

В данном докладе мы поговорим о следующем:
* Введение, почему данная тема важна.
* Узнаем, как DevOps связан с культурой по Westrum и чем это полезно для нас.
* Три типа организационной культуры по Westrum.
* Как менять культуру с помощью принципов Westrum'a на примере Райфа.
* Рассмотрим преимущества и недостатки способа на опыте Райфа.
* Рекомендации и заключение.

В большинстве компаний DevOps — это люди, которым каждый день приходится писать пайплайны очередного микросервиса, настраивать мониторинг, рисовать дашборды, контейнеризировать приложения и деплоить бесконечные микросервисы.

Ещё недавно деплой микросервисов был увлекательным занятием, и мы не успели заметить, как это превратилось в рутину.

В своём докладе расскажу:
* как перестать быть эникейщиком и снова начать автоматизировать;
* как отсутствие DevOps может ускорить Time to market;
* как всего три DevOps могут справляться со 150+ разработчиками, 70+ Tarantool БД, 100+ микросервисов, при этом успевать готовить свой on-premises Kubernetes на сотнях серверов.

* Почему с ростом компании меняются инструменты и подходы к разработке / эксплуатации ПО, и когда стоит задуматься о DevOps (на примере Юлы).
* Множество «снежинок» среди серверов, зоопарк из CI, отсутствие шаблонизации, секреты в коде и другие трудности, с которыми столкнулись DevOps в Юле.
* Monitoring as Code, Vault, Ansible, Gitlab и другие инструменты, которые помогли сделать наш dev чуточку лучше.
* Почему иногда софты намного важнее хардов, и почему важно уметь друг друга слушать и понимать.
* Monitoring as a service, Terraform, CloudNative DevOps и другие планы на будущее.

С начала года ведется активное обсуждение Platform Engineering в индустрии, сформировалось сообщество и проходит первая конференция. Так что же такое Platform Engineering? Это модный термин или новая дисциплина? Придет ли на замену DevOps и SRE?

В своем докладе я отвечу на эти вопросы и раскрою следующие темы:
* Внутренние платформы;
* Платформенные команды;
* Платформенные метрики и цели;
* Developer Experience;
* Platform API.

Рассмотрим исследования и отчеты, расчеты и формулы, книги и мнения экспертов, опыт иностранных и российских компаний.

С чего начинался наш мониторинг, и почему мы пришли к принципу "мониторинг должен быть удобен для всех".

* Настройка мониторинга от helm upgrade до gitops-подхода.
* Как графана стала единым местом для наблюдения за сервисами, и как нам удалось связать воедино метрики, логи и трейсы.
* Почему Loki показался удобнее классического ELK-стека.
* Алертинг, который не мешает нам спать, и как настроить политики эскалации.

Хочется перейти от выполнения тикетов к API в инфраструктуре, но постоянно не хватает времени? Непонятно, как убедить бизнес в необходимости таких изменений?

Расскажу на опыте Skyeng, как мы перешли от тикетов к API, как повторить наш успех и что мы планируем делать дальше.

История о том, как сервис с mongos переносили в Kubernetes.

Речь пойдёт про демон, который по рекомендациям должен располагаться как можно ближе к приложению (в идеале: на том же хосте). Из-за этого возникает ряд общих проблем, которые будут рассмотрены на примере mongos'а.

В процессе миграции в Kubernets мы последовательно испробовали несколько путей разворачивания этого демона:
* DeamonSet;
* Запуск в том же Pod'е;
* Deploment + Service (как ClusterIP, так и Headless Service).

В данном докладе будет рассказано, почему были выбраны именно эти варианты и как они себя повели на практике.

Обычно мы выбираем решение исходя из наших требований и экономической эффективности, поэтому отказ от Kubernetes — это осознанное решение.

Нам было необходимо:
* создание неизменного образа приложения;
* возможность фиксации состояния системы;
* возможность отката приложений;
* изоляция ресурсов;
* безопасность;
* распределение нагрузки;
* отказоустойчивость;
* простое управление конфигурацией;
* мониторинг;
* централизованный сбор логов.

Оказалось, что все это у нас уже есть и без k8s, и лишний слой в виде Kubernetes для нас — дорогое и неэффективное решение.

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

В этом докладе мы расскажем о том, как подготовить kubernetes-кластер для мультитенантного использования, для целевого подхода namespace as a service. Расскажем о минимальном наборе необходимых компонентов для жизнедеятельности kubernetes-кластера, таких как: opa-gatekeeper, falco, cert-manager, flux, ingress-nginx, logging-operator, prometheus. Все это помогает организовать безопасный сервис (kubernetes-кластер).

1. Что было, чем пользовались.
2. Что не устраивало.
3. Из чего выбирали.
4. Почему Seldon core?
5. Как мы его используем.
6. Какие плюсы для Ops.

HashiCorp Vault — это отличный opensource-продукт, который многие используют "как есть" для управления секретами. При этом, как это обычно бывает, при внедрении в большой инфраструктуре мы столкнулись с рядом ограничений и нехваткой функционала. Это не позволяло нам использовать Vault в полной мере в инфраструктуре Одноклассников — технологической платформе VK.

В докладе я расскажу, как мы дописали Vault для горизонтального масштабирования, свели к минимуму операционную поддержку при помощи собственного auth-бэкенда и PR в upstream, упростили жизнь себе и разработчикам.

Мы рассмотрим внутреннюю архитектуру Vault, остановимся подробнее на auth- и backend-плагинах (узнаем, что писать свои — просто и полезно) и, конечно, не обойдемся без любимой нами Cassandra :)

Про квоты в k8s знают, кажется, все. Но мало использует их полностью.

Я расскажу:
* как от "коммунизм, всем можно всё" мы дошли до "квотируем вообще всё" и стали спать спокойно;
* почему квоты нужны даже в single tennant кластере;
* что нельзя квотировать, но очень бы хотелось.

Обсудим, чем контейнеризация отличается от виртуализации, откуда она пошла и зачем нам нужна. Остановимся на трёх китах в Linux: cgroups, namespaces, layerfs. Поработаем с ними сначала вне привязки к Docker, а потом проведём эксперименты и над запущенным контейнером. Выберем, что же использовать для Python-проектов и какие могут быть подводные камни.

В этом докладе поговорим про LINSTOR — open source-хранилище от компании LINBIT (разработчика DRBD).

Начиная с девятой версии, DRBD сменил курс с «‎одно большое отказоустойчивое устройство на всех»‎ на «‎по отдельному DRBD-устройству на виртуалку»‎, стал поддерживать diskless-реплики, появились оркестратор, поддержка снапшотов, шифрования и много другого.

Тезисы:
* Почему LINSTOR — это не просто хранилище, а, скорее, оркестратор блочных устройств. В чём его схожесть с Kubernetes.
* Выделим преимущества и недостатки DRBD перед Ceph и другими кластерными файловыми системами.
* Копнём чуть глубже и посмотрим, как работает DRBD9, LINSTOR и что находится у него под капотом.
* Разберём сущности LINSTOR и как его правильно настроить.
* Как работают снапшоты, бэкапы, дедупликация, шифрование.
* Почему не рекомендуется использовать опцию allow-two-primaries и зачем, вообще, она нужна.
* Какие есть проблемы. Как устранять неполадки и чинить split-brain, если потребуется.

How to decompose monolith API into GRPC microservices.

В этом воркшопе мы делаем фокус на декомпозиции монолита приложения на GRPC-микросервисы в среде Node.js, TypeScript.

The workshop focuses on concepts, algorithms, and practices to decompose a monolithic application into GRPC microservices. It overviews architecture principles, design patterns and technologies used to build microservices. It covers the theory of the GRPC framework and protocol buffers mechanism, as well as techniques and specifics of building isolated TypeScript services in the Node.js stack. The workshop includes a live use case demo of decomposing an API application into set of microservices. It fits the best architects, tech leads, and developers who want to learn microservices patterns.

General
- 3-4 hours.
- Advanced level.
- Patterns - DDD, Microservices.
- Technologies — GRPC, protocol buffers, Node.js, TypeScript, Express.js, MongoDB.
- Example structure — lerna configuration, packages configuration, common utilities, demo application.
- Practical exercises.

Prerequisites
- Good understanding of JavaScript or TypeScript.
- Experience with Node.js and writing Backend applications.
- Preinstall Node.js, npm.
- Preinstall Protocol Buffer Compiler.
- We prefer to use VSCode for a better experience with JavaScript and TypeScript (other IDEs are also ok).

xtechnology.dev/grpc

В докладе, мы поделимся реальным опытом использования техник Chaos Engineering в различных современных и legacy проектах, расскажем о проблемах с которыми сталкивались, покажем, как их обойти и подтвердим и развеем мифы о надежности систем. Проведем слушателя от первой атаки до создания Chaos Engineering команды. Покажем на примерах реальные проблемы "которые никогда не наступят", и как с помощью Chaos Engineering можно было бы к ним подготовиться и понимать, как поведет себя ваша система в различных турбулентных сценариях от просроченных сертификатов до split-brain между кластерами.

Что же такое архитектура? Это (в том числе) информация о том, как работает система, но в каком формате должна быть эта информация, чтобы её легко было оформлять, распространять и понимать? Одним из вариантов является модель С4. Чтобы создание данной модели было близко разработчикам, которые плохо рисуют и им не приходилось использовать графический редактор Paint, расскажем об языке PlantUML, который позволит «рисовать» диаграммы в любимой среде разработки. На базе этих подходов и инструментов мы спроектируем реальную систему, в ближайшее время уезжающую на продуктив.

Общим местом современной разработки RoR является философско-практическая проблема: куда девать бизнес-логику во фреймворке, который "заточен под другое". Лёгкость прототипирования и развитый ООП-инструментарий RoR первоначально не предполагает "обмазываний абстракциями" и "академической нудятины". Вместе с тем, как только сложность проекта превышает пресловутый "бложик за 15 минут", в проекте начинает накапливаться технический долг в виде надобности рефакторинга образовавшейся в результате "гибкой инкрементной разработки" лапши из спутанного (entangled) ОО-кода, god-objects на всех уровнях MVC, бешеных репортов CodeClimate и прочих "благ цивилизации".

Во всех современных языках существует достаточно зрелый ФП-инструментарий, а комьюнити накопило достаточно знаний для его применения. Мы стали лучше самообразовываться, продвигаться в CS и теории языков. Проблемы DDD требуют уже не столько наработки, сколько деления реальным опытом ФП-архитектуры в DDD. У компании Evrone такой опыт есть.

Предлагаю мастер-класс по ФП-рефакторингу спутанного MVC-кода с применением инструментария Dry-rb, встроенных ФП-примитивов Ruby и функциональных паттернов монадного вычисления, каррирования, инъекции анонимных функций и т.п.

С использованием SAST-решений как чёрного ящика более или менее всё понятно — установили baselining, включили нужные чекеры и прочие необходимые настройки. Актуальные предупреждения правим, false positives давим.

Но что происходит "за кулисами", прежде чем анализатор выдаст предупреждение о дефекте безопасности? Работа с синтаксисом, семантикой, data-flow, taint checking — как всё это помогает искать те или иные проблемы?

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

В продуктовой разработке часто относятся к security review как к набору бумажек и лютой бюрократии. Однако, этот процесс становится очень важным на фоне множества событий о хакерских атаках на информационные системы.

Security review можно (и спойлер — нужно) делать не просто для галочки, а также можно делать без бюрократии и с адекватной оценкой рисков, которая не тормозит разработку.

Цель доклада — рассказать, как построить, в том числе и с нуля, современный и эффективный процесс security review продукта, а также поделиться опытом, как мы поддерживаем культуру ИБ в компании, которая позволяет не задерживать доставку и получать помощь команд разработки.

Как так получилось, что TDD и часто встречаемые подходы в разработке превратили проект в клубок пугающего кода. Как этот монстр из непонятного кода и тестов, которым нельзя доверять, пожирал наше время на мелких фичах. Как мы поняли, что нам нужен рефакторинг не только тестов, но и мышления.

На примерах я расскажу о приемах, которые помогли мне загнать себя и код в рамки при рефакторинге, а команда получила набор правил для разработки и наглядное руководство в виде кодовой базы с бизнес-логикой, понятной не только для программистов, и прагматичными тестами. Аналитики сказали спасибо :)

Мы снова поговорим про DDD, но только в этот раз речь пойдет про паттерны Domain-Driven Design и как они помогают при формировании структуры команд и взаимодействию между ними.

Рассмотрим такие понятия, как: upstream/downstream-контексты продукта, определение Context Map'ы и как команды должны разрабатывать и взаимодействовать с ними, чтобы не мешать друг другу. Ну и, конечно же, мы пробежимся и по базовым паттернам, таким как правильное определение бизнес-моделей: value, entity, agregate'ов, ответим на понятие domain-логика и ее место в коде проекта, постараемся рассмотреть все это на примерах.

Доклад будет полезен всем, кто немного знаком с DDD и хочет закрыть пробелы в своих знаниях при использовании этого инструмента в разработке.

В докладе мы поделимся реальным опытом использования техник Chaos Engineering в различных современных и legacy-проектах, расскажем о проблемах, с которыми сталкивались, покажем, как их обойти, и подтвердим и развеем мифы о надежности систем. Проведем слушателя от первой атаки до создания Chaos Engineering-команды. Покажем на примерах реальные проблемы, "которые никогда не наступят", и как с помощью Chaos Engineering можно было бы к ним подготовиться и понимать, как поведет себя ваша система в различных турбулентных сценариях от просроченных сертификатов до split-brain между кластерами.

Иногда разработка ПО похожа на прокладывание рельс перед идущим поездом. Если мы не выпустим релиз сегодня, завтра будет поздно. Но что делать с кривыми рельсами, которые остались лежать по нашему пути? Как следующие поезда будут по ним катиться?

Технический долг — это те самые кривые рельсы. Да, мы проехали по ним один раз, но следующие поезда должны идти плавнее, а значит, рельсы надо перекладывать. У меня есть подсказки, как сделать перекладывание проще.

Расскажу историю о том, как мы эволюционировали, с какими проблемами сталкивались.

Как правило, целью команды разработки, является доставка ценности клиенту/бизнесу. На сегодняшний день эта цель, культивируется и становится всё сложнее, ведь, чтобы быть конкурентоспособным, изменения должны быть частыми и быстрыми.

В этом докладе я предлагаю поговорить о том, как выкатываться и не ломаться, при этом имея легаси и прочие барьеры, которые могут оказаться неприятным сюрпризом и сыграть против вас. Обсудим, как организовать процесс работы команды и какие инженерные практики можно использовать, чтобы делать изменения, насколько это возможно, безопасно и как избежать проблем :)

Для этого рассмотрим способы релиза сервиса, как это можно делать, имея легаси-код в main-ветке и выводить несколько активных версий приложения, обсудим такие способы, как branch by abstraction, dark launch и какую модель ветвления при этом использовать.

* Что смотреть на Code review.
* Психологические аспекты.
* Проблемы и возможные решения.
* Соглашения.
* Особенности OpenSource.

В Додо Пицце на iOS мы автоматизировали 75% регресс-кейсов и последние два года пишем разные виды тестов: юнит-, скриншот-, компонентных- и UI-тестов. Общее число приближается к 4 тысячам.

За это время мы написали много разных тестов, разделили приложения на модули. Какие-то тесты не падали ни разу, какие-то ни разу не были зелеными. Самым главным вопросом всегда было «как писать полезные тесты?». Этим опытом я и поделюсь.

Расскажу:
* как писать по TDD для мобильной разработки;
* что такое тестируемая архитектура;
* зачем нужные разные уровни тестов и как не тестировать одно и то же;
* где прячутся компонентные тесты;
* как не скатиться в ад с автотестами.

Посмотрим на практике, как может выглядеть полный цикл разработки фичи через тесты, какие требования это добавляет к проекту, как тестировать на разных уровнях и почему это весело.

Про TDD слышал практически каждый инженер. Многие даже пытались применять на практике. Но всегда что-то идет не так, и возникает ощущение, что данная практика создана для каких особенных проектов или особенных людей или технологий.

Во время конференции мы даем возможность участникам поделиться своими кейсами и запросить мнение экспертов, как они решили бы проблемы внедрения и применения TDD. Целью данного формата будет вытащить из участников конференции самые сложные случаи и обсудить их с экспертами. На выходе участник получит ответы, как именно ему проделать работу над ошибками, чтобы прийти к успеху в следующий раз.

TDD на старте требует серьёзных вложений. Стоит ли инвестировать?
Мой опыт: 3 года с TDD во фронтенде.
Инсайты и сложности внедрения практики.
Влияние TDD на техническую культуру в команде.

Этот рассказ про разработку сервиса анализа и планирования Capacity на сравнительно большом количестве серверов. В рассказе будут детали:
* какие метрики нужны, как собираются и сколько их;
* как используются метрики RPS и стресс-тестов;
* куда все это собирается, как агрегируется, сколько занимает места;
* в итоге, как и чем строится прогноз нужного количества серверов.

Внедрить применение какой-то инженерной практики или технологии в одной команде чаще всего не вызывает проблем. Проблемы возникают при масштабировании. Поэтому на конференции часть докладов посвящена теме масштабирования. В завершение конференции участникам предоставляется возможность задать вопросы по масштабированию инженерных процессов экспертам. Мы хотим полностью раскрыть все аспекты успешного внедрения инженерной культуры, процессов и технологий на большие команды, компании и выяснить, как сделать так, чтобы эти практики приживались “без кнута”.

В докладе я расскажу про взаимодействие SRE-бизнес-юнитов (линий) в компании. Покажу, что SRE — это нестрашно, и в парадигме компании это про разработку и горящие идеей глаза, а не админов и бессонные ночи дежурств.

* Как мы делимся экспертизой друг с другом, как выполняем общие по компании задачи и шарим экспертизу?
* Много ли выделяем времени на поддержку инфраструктуры?
* Как работаем с надежностью сервисов в команде, и какие есть уровни коллаборации с продуктом?

На эти и другие вопросы я отвечу в своем докладе.

Всегда приятно все строить правильно и по «канону» самых последних технологий, но, к сожалению или к счастью, законы природы и бизнеса думают иначе. Сила компании — это проявление ее гибкости, способности быстро подстраиваться и изменяться, а не использовать все самое новое везде и сразу. Нет никакого смысла переписывать в одночасье монолит, который разрабатывали в течение 10 лет, но также при этом нельзя упускать конкурентные преимущества от новых технологий и процессов, которые становятся более эффективными.

В своем докладе хочу рассказать, как менялось наше мировоззрение, технологии и процессы. Когда мы стали расти, у нас не было четкого плана, у нас были цели и мы пытались адаптироваться к новым реалиям. На своем опыте могу сказать, что инструменты меняются во много раз быстрее, чем сознание людей, и эта разница очень частно начинает портить всю картину. Сегодня я расскажу про эволюцию нашего стека и процессов сопровождения, релизов (CI/CD) и безопасности. Итого нам пришлось построить несколько параллельных процессов, где есть ветвления: где-то процессы эволюционируют, а где-то это разные ветки и никогда не пересекутся межу собой.

Из доклада вы сможете узнать основные этапы эволюции нашей команды, нашего стека и вакцины, с помощью которых нам удавалось перейти на новый уровень и при этом сохранить свой разум и спокойный сон.

В многокомандной разработке узким местом часто становится координация команд, которые работают на одной кодовой базе.
* Каких стандартов придерживаться?
* Как выстроить процесс релиза?
* Как придерживаться архитектурных гайдов?

Хочу подробно остановиться на одной из самых интересных техник координации — Community Of Practice (Сообществе Практиков). Этот тот самый горизонтальный клей самоорганизации, который помогает быстрому распространению знаний в продукте, организации и за её пределами.

Легаси случается со всеми, сначала это незаметно, потом неприятно, а потом больно и приходится что-то с этим делать. С чего начать, как сделать план и оценить его — все это хочется рассказать и показать путь "второго рождения" или окончательной смерти приложения на синтетических примерах, собранных из реальных систем.

Domain-Driven Design предлагает важную пользу, но не рассказывает с порога кое о чём важном.

Однажды ваш продукт и компания в своём росте и развитии достигают момента, когда вам нужно серьёзно заняться архитектурой. Когда по-старому дальше никак.

Тут вам на помощь может прийти Domain-Driven Design. Звучит он хорошо: предметные области, модели, единый язык; наконец-то ИТ и бизнес договорятся.

Вот только есть загвоздка: среди препятствий в использовании DDD у вас будет не только сложность предметной области и ограничения стека, но кое-что неочевидное — ценности.

О ценностях ок слышать от CEO или эйчаров, но в инженерной команде отношение к самой этой теме, по моему опыту, — нейтрально-скептическое.

И даже если (вдруг) мы почему-то решили заняться ценностями с инженерным умыслом, выясняется, что тут легко скатиться в развешивание плакатов на стенах кухни в офисе и бесполезные встречи с набившими оскомину заклинаниями. На деле выясняется, что настоящие ценности живут “в курилке”, но как с этим быть, как на что-либо влиять — вообще непонятно.

Давайте поговорим о прикладной стороне ценностей. Почему без общих ценностей у вас будут проблемы с архитектурой. Как продуктовый подход помогает в работе с ценностями. И как работать с ценностями без нудного морализаторства и гуманитарного шаманства.

Надеюсь, доклад будет интересен для С-level и руководителей, в чью зону ответственности входят вопросы архитектуры. А ещё для инженеров, кто не стесняется задавать руководству неудобные вопросы и интересуется архитектурой.

Возможность совмещать технологические стеки считается одним из преимуществ микросервисов. Но это только в теории. А на практике вас ждет боль. Приходите на доклад и узнаете почему.

Какими принципами руководствоваться при проектировании микросервисной архитектуры? Как увязать возвышенную теорию с реалиями практики? Обсудим примеры из жизни и сравним разные стратегии проектирования — от минимонолитов до наносервисов :)

По следам реальных проектов сформулируем плюсы, минусы и подводные камни каждого подхода. Попробуем выделить золотую середину и сформировать чек-лист — на что обращать внимание при выборе конкретно вашей стратегии для вашего проекта.

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

Мне кажется, что причина подобных результатов — в самом начале думать о деталях реализации и о том, как решить задачу, вместо того, что бы разобраться, что нужно сделать и какие ограничения должны быть у новой системы. Это приводит к повышению киплинга системы, так как элементы и их коммуникации друг с другом анализируются по ходу реализации или партицируются по технической реализации, а не по бизнесу.

В докладе хочу рассказать о способе перехода на события в системе. Основную идею можно описать в пяти шагах:
* разбор требований и поиск характеристик необходимых системе;
* моделирование поведения системы от бизнеса;
* моделирование основных данных, необходимых для работы системы;
* анализ необходимых доменов, сервисов и коммуникаций;
* дизайн системы, основанной на шагах выше, и последующая имплементация решения.

На примерах трех систем из своего опыта (биллинг/аккаунтинг, система финансового анализа и полного переписывания школы для подготовки детей к ЕГЭ/ОГЭ) покажу каждый из шагов, а также расскажу, какие подводные камни встретились по ходу работы. Еще поговорим о том, почему необходимо использовать разные виды событий, как избежать проблем со схемой событий во время добавления новой логики, и что делать в случае возможных потерь или проблем с ордерингом.

Есть расхожая фраза: "Кто не рискует, тот не пьет шампанское!". Но вот в чем вопрос — где проходит та тонкая грань, за которой оправданный риск переходит в навязчивую идею, сметающую все на своем пути? Весной 2021 года моя команда столкнулась с вызовом — уйти от старого процессинга во имя нового, который будет отвечать вызовам бизнеса — выше стабильность — SLA 99,99%, рост нагрузки в 5-10 раз, масштабируемость под новые бизнесы. Конечно же, был выбор между рефакторить старое vs писать новое. А дальше: мы были молоды — верили в правило 80/20 и не учитывали, что просадка конверсии на 0,5% — блокер к переключению с одного компонента на другой.

Я хочу провести вместе с вами ретроспективный анализ и найти ответы на вопросы:
* Зачем, вообще, переписывать старое? Есть ли объективные причины?
* Как аккуратно подменить такой крупный, требовательный к доступности и нагруженный кусок системы как процессинг?
* Насколько можно недооценить ресурсы на такой проект, и какие проблемы он может принести в соседние команды разработки?

Цель моего доклада — не призыв к переписыванию и даже не демонстрация опыта, я хочу показать путь — цели и нюансы, которые могут вас сопровождать на маршруте: "Все сжечь и написать заново". Продемонстрировать на конкретном примере, почему "быстрый старт" != "быстрое внедрение". Доклад будет полезен всем, кто стоит на распутье по выбору технической стратегии развития архитектуры нагруженных и/или высокодоступных систем, а также тем, кто будет эти стратегии воплощать в жизнь.

* Что такое качество в целом и качественные ИТ-решения? Что такое архитектура ИТ-решения?
* Качественная архитектура — архитектура, полностью покрывающая требования: бизнес-требования и системные требования (функциональные и нефункциональные).
* Бизнес-требования и архитектура компании — бизнес-архитектура. На что следует обратить внимание в первую очередь и почему это важно.
* Системные требования: функциональные и нефункциональные. На что следует обратить внимание в первую очередь и почему это важно.
* Как TOGAF и ArchiMate могут помочь техлиду в формализации требований к ИТ-решению и в понимании целей бизнес-заказчика.
* Как всё это поможет техлиду разработать качественную архитектуру: на примерах разберемся с бизнес-целями, требованиями, схемами и другими артефактами про архитектуру.

Такое бывает: бизнесу нужно больше, чем может дать нынешняя ИТ-архитектура продукта. Быстрее; надёжнее; чтобы лучше масштабировалось.

Так было у нас в Самокате.

Какое-то время назад мы предоставляли пользователям одну главную понятную возможность: за 15 минут получить продукты, которые тебе нужны. Обеспечивающие этот сценарий ИТ-продукты, схема их взаимодействия, архитектура — были выстроены вокруг этого сценария.

Но бизнес не стоял на месте: сейчас с помощью Самоката, кроме продуктов, можно заказать косметику, лекарства и впереди ещё много всего интересного. Для продуктов есть не только сценарий “хочу этот айтем, заказываю его скорее”, но становится всё больше “заходил сюда без мысли об этом айтеме, но теперь вижу, что он мне нужен”.

У нас появились целые команды, которым нужно дополнительное усилие со стороны пользователя, чтобы понять, что ему что-то нужно.

И тут мы натолкнулись на ограничения архитектуры с монолитом центральной витрины приложения.

В какой момент менять архитектуру под возможность дальнейшего масштабирования для бизнеса? Как правильно вынести свои данные из других сервисов? Как это организовать с точки зрения технологического стека? Как изменить процессы разработки под изменения архитектуры? Расскажу об этом в докладе.

Было у вас такое?

Вы увеличиваете штат разработчиков, а объем проделанной работы остается на том же уровне. А иногда от увеличения команды скорость разработки даже уменьшается.

Парадокс? Почему так происходит?

В докладе я расскажу про наш опыт:
* Как мы создали высокоэффективную команду.
* Как ускорить разработку через архитектурные решения. Microfrontend, Monorepo, Lerna.
* Про внедрение процессуальных решений. Gitflow, audit вместо review.
* Поговорим об изолированности, какие плюсы она даёт? Как бороться с минусами.

Актуально ли составлять резюме? Вокруг говорят про нехватку ИТ-специалистов и что "программисты нарасхват". Кажется, что в такой ситуации резюме избыточно и "лучше всего программиста характеризует его код на Github". Но что делать, если вы уже senior или team lead? Или, вообще, ушли в техменеджмент.

В этом докладе мы по полочкам разберем процесс найма, обсудим разные его артефакты (резюме, собеседования, офферы) и посмотрим на ситуацию с разных сторон: со стороны кандидата и со стороны работодателя. Будет много субъективных мнений, анонимных исследований и оценочных суждений. Но будет интересно.

База данных. Хочу быструю, как Redis. Реляционную, как Postgres. Документную, как Mongo. И чтобы поддержка на русском. А что, так можно было?

При выборе СУБД надо принять несколько решений. Распределённость или целостность? Надёжность или скорость? Отказоустойчивость или консистентность? Инструмент, идеальный для одного сценария, совсем не подойдёт под другие задачи. Мы все это знаем, но всё же хочется найти в меру универсальный кубик для построения data-centric систем.

Тарантул позволяет сесть на два стула. Производительность в 1 000 000 RPS с одного ядра без потерь данных. Репликация с околонулевой задержкой, синхронная или асинхронная на выбор. Строгая сериализация транзакций без конфликтов. Шардирование и Key-Value-подход со вторичными индексами. Возможность реализовать сложную логику с помощью SQL и Lua.

Я расскажу, почему считаю Tarantool универсальным инструментом под две трети задач по работе с данными. Покажу, как его сильные стороны отвечают большинству требований систем, где нужны СУБД или очередь.

И честно расскажу про оставшуюся треть, когда Tarantool брать не надо. Потому что серебряной пули не существует.

В области Data Science, Machine Learning и даже Data Engineering нет таких устойчивых традиций разработки, как в других областях. При этом, конечно же, есть свои сложности и проблемы. Новички приходят в эту область, быстро понимают, что всё совсем не так, как они себе представляли, а те, кто пока к ней приглядывается, часто имеют довольно искажённое представление о том, как выстраивается типичный цикл разработки и какие там есть неожиданные неприятности. В ситуации, когда ты приходишь в аналитическую команду инженером или работаешь с соседней командой дата-сайентистов, это взаимодействие часто приводит к склокам и недопониманию.

В докладе мы обсудим возможные причины, почему такое может происходить и что можно сделать, чтобы этого не было. Я поделюсь соображениями о том, как можно сделать так, чтобы дата-сайентисты и дата-инженеры выполняли свои задачи без ощущения, что это их убивает.

Многие зарубежные компании заблокировали свои онлайн-услуги на территории РФ. Под санкции попали даже сервисы, которые используются в процессе разработки.

Возникает много вопросов для техлида — что ещё перестанет работать? Как обезопасить свои команды? Во сколько это обойдется для бизнеса? Одно из решений — разработать своё.

Григорий Зарипов расскажет о том, как команда Яндекс.Толоки разработала opensource-решение для быстрой доставки Frontend до конечного пользователя и для ускорения тестирования.

Многие говорят "Нужна автоматизация", "Нужны быстрые релизы и без автотестов это невозможно", "Ручные тесты — это прошлый век". Действительно ли это так? Как все знают, "правда — посередине", поэтому пора расставить точки над "ё" и разобраться, откуда появилась категоричность

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

Самое важное в этой философии — помнить, что не существует серебряных пуль. Именно поэтому всё организовано в виде cookbook, где каждый сможет найти тот самый рецепт, ту самую основу, которую можно будет попробовать.

Bon appetit!

Тестирование много лет развивалось эволюционно, однако давление тренда тотальной автоматизации добралось и до нас — скоро все изменится кардинально!

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

В докладе Артем расскажет о каждом из этапов, через которые придется провести тестирование: поговорим о метриках, инструментах, целях, сложностях перехода и коммуникаций на каждом из них.

А в конце вы получите таблицу-гайд, которая поможет вам определить, где вы находитесь и в какую сторону направить усилия.

Автоматизация 15 лет назад и сегодня — совершенно разные истории. Разнообразие инструментария радикально изменило масштабы, процессы и задачи автоматизации.

Важно отметить, что все изменилось не сразу. Сначала популярны стали инструменты, разработанные тестерами для тестеров: Selenium, Appium, REST Assures*.* А в последние годы все популярнее становятся инструменты тестирования от разработчиков, двигающиеся в другой парадигме: Playwright, Kaspresso и другие.

В этом докладе мы по-честному сравним инструменты и подходы лоб-в-лоб, чтобы найти преимущества нового поколения инструментов, понять сложности перехода на них и попробовать решить, стоит ли оно того.

Расскажу про опыт тестирования сервиса нашей команды. О том, как мы пришли к тому, что релизы выкатываются без нашего участия, какие тесты мы для этого пишем, как реализуем CI/CD, как реагируем на проблемные релизы.

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

Нагрузочное тестирование (НТ) — неотъемлемая часть процесса обеспечения качества любой системы с большим числом пользователей. Для проведения НТ существует множество инструментов, но многие из них решают относительно узкие задачи, а более сложные комплексы — платные и проприетарные, и это накладывает свои ограничения.

В своём докладе я расскажу о развитии наших в Miro инструментов от ручного запуска скриптов через относительно простой консольный скрипт для кластерного запуска тестов с поддержкой нескольких инструментов НТ до целого комплекса из сторонних и собственных компонентов и интеграцией в CI/CD. С процессной точки зрения таким образом произошёл переход от просто НТ к QA со стороны производительности, что включает в себя намного большее. Этот процесс шёл рядом с переездом с монолита на микросервисы, и это создало дополнительные вызовы. Кроме этого, будут освещены организационные вопросы, которые были решены в ходе внедрения описанного процесса.