Доклады

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

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

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

Как наверняка понять, что платформа вам нужна? Как (не) выстрелить себе в ногу, внедряя платформу? Что придется сломать в процессах, системах и головах людей? Где придется признать, что ломать дороже (даже в долгой перспективе), чем оставить все, как было? Какую ценность должна нести платформа, чтобы "продать" ее разработчикам? Расскажу про то, как мы за 4 года жизни платформы, искали ответы на эти вопросы, через какие тернии прошли, и где нас укусила реальность.

В докладе расскажу про TelcoCloud в части контейнеров, а именно как мы тестировали производительность сети на одном из наших проектов для телеком заказчика. Расскажу кому и зачем это нужно. Покажу методику и реузльтаты тестирования, где сравню пропусную способность оверлейной сети OVN-Kubernetes и SRIOV+DPDK. А на сладенькое - расскажу немного боли про переход с OpenShift на OKD.

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

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

Доклад представит, как эволюционировала наша система создания алертов, раскрою с какими сложностями сталкивались на каждом из этапов. Поговорим про типы алертов в Озоне. Расскажу как мы создаем единый сервис написания и деплоя алертов

Новый режим Ambient Mesh в Istio стремится решить основные проблемы Service Mesh и обещает нам мир, где больше нет sidecar-контейнеров с сетевыми прокси, а значит нет никаких дополнительных затрат ресурсов, проблем с L4 трафиком или повышенных привилегий для редиректа сетевого потока. При этом Ambient режим обещает отсутствие каких-либо компромиссов в функциональности или безопасности.

Давайте все это проверим?

В докладе я предлагаю глубоко погрузиться в архитектуру Ambient Mesh, сравнить ее с прошлой реализацией, оценить на практике все преимущества и недостатки, и конечно главное - ответить на вопрос, пора ли использовать Istio Ambient в своем продакшне?

- Что такое IT-платформа? Определение и структура платформы, цели и ключевые функции.
- Зачем нужна IT-платформа? Анализ необходимости платформы вне зависимости от существующих решений типа AWS, с акцентом на сокращение времени ожидания и уменьшение сложности задач.
- Переход к тикетов к платформе: От теории к практике — как перейти от API-описаний к полноценной автоматизации, иллюстрировано на примере Skyeng.
- Последующее развитие: автоматизация и уменьшение сложности: Как платформа помогает разработчикам в наблюдаемости и управлении IT-ресурсами.
- Будущее инженерии платформ: Роль искусственного интеллекта в мониторинге, диагностике и управлении инфраструктурой. Дополнительная польза от ИИ, в случае построения инфраструктуры как платформы

- Что такое IDP: отличие от *aaS;
- Предпосылки IDP;
- Базовая архитектура;
- Ключевые компоненты платформы: портал и kubernetes;
- Как меняется Workflow/подходы DevOps с IDP;
- Какие задачи закрывает IDP помимо энвайрментов: CMDB, отчетность, база знаний etc.
- Как стартануть разработку IDP в Enterprise-компании
(все это на основе опыта компании Почтатех)

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

В моем докладе вы узнаете:
- технологические составляющие платформы;
- экономические составляющие платформы;
- как выбрать базовую стратегию обоснования необходимости PE для своей компании;
- модели развития платформы в зависимости от инвестиций;
- проблемы при масштабировании платформы и пути их решения;
- платформа, обязательная к использованию или по желанию команд: как лучше?
- как сравнить жизнь с платформой и без нее;
- как сделать внутренних клиентов вашей опорой перед руководством;
- кейсы из опыта MOEX Group: как мы строим единую отказоустойчивую платформу для всех компаний Группы.

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

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

Это доклад, не о том, как мы внедрили HC Vault, а о том, как мы переосмыслили процесс работы с разработчиками и секретами.

Мы хотим рассказать, как при наличии в команде 40+ сервисов и 4-6 стендов мы решили сократить количество заявок на инженеров.
Для этого мы решили создать инструменты, которые упростили нам работу, не создавая при этом платформы с огромными затратами.
Сделав упор не только на автоматизацию, но и на инструкции, мы создали процесс для инженера, который включает:
- Описание списка нужных инструментов для сервиса
- Создание инструментов, позволяющих одинаково работать и с win и linux
- Генерация секретов, от созданных инструментов и доставка его до HCvault
- Внедренный сразу же процесс DevSecOps по работе с секретами, который позволяет на этапе генерации работать с любыми типами секретов в конфигурациях в HC Vault
- А шаблонизация позволяет генерировать конфигурации для решений с встроенными секретами под ключ, обращаясь в хранилище по известной структуре данных, не сохраняя их "под ногами"
Есть плюсы:
- Инженер не заводит 100500 заявок на создание инструментов
- Инженер не видит созданные секреты
- Инженер не вводит руками секреты, уменьшаем очепятки.
- Инжене……..
и многое другое, увидимся на докладе.

Пайплайн - это блюдо, которое подается в холодном виде. Привнося в свою систему такой CI/CD сервер, как Jenkins, мы не только добавляем гибкий и удобный open-source продукт с большим сообществом и безграничными возможностями по его настройке, но также размещаем большое количество "черных дыр" в нашей системе, позволяющих злоумышленникам проводить через них атаки на инфраструктуру. А ряд популярных плагинов лишь увеличивает уязвимость системы перед лицом врага. Настало время это исправить! Цель этого доклада - показать приемы усиления безопасности и выстраивания безопасной разработки с использованием Jenkins.

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

CICD системы сердце любого современного проекта, он берет на себя роль и хранения, и сборки и доставки. трудно представить масштабный проект без Gitlab или Github под капотом. Однако это создает огромную точку отказа в системе. Давайте представим, что злоумышленник каким-либо образом скомпрометировал Gitlab? Что будет в таком случае и возможно ли как-то защититься от этого?

1. Общая информация о том, что такое Admission Webhook
2. Обзор (очень краткий) наиболее известных решений - Kyverno, Gatekeeper, KubeWarden. Плюсы/минусы, почему выбор пал на Kyverno
3. Общая информация о возможностях системы, с указанием общих нюансов (например, а что будет с уже созданными ресурсами? а если сломается? а если нужна будет сетевая связность и т.д.)
4. Use case использования разных типов политик
4.1 Validation. С указанием явны примеров политик, которые можно создать и использовать в самом начале пути
4.2 Mutation. С указанием явны примеров политик, которые можно создать и использовать в самом начале пути
4.3 Image Verify. На примере связки с Cosign, в том числе добавлением аттестации по анализу образов контейнеров с использованием Trivy. Небольшой разбор in-toto attestation и как это можно использовать в связке с Validation политиками
5. Анализ результатов работы политик Kyverno:
5.1 CR в Kubernetes - работает по умолчанию, но процесс на этом не построишь
5.2 PolicyReporte - уже лучше, но все равно тяжело с точки зрения процесса
5.3 Есть мысль написать PoC Kubernetes Operator'a, который будет перенаправлять результаты работы политик в DefectDojo. Это позволит строить процесс на стороне DD
6. Выводы

Сегодня многие крупные компании используют K8s в своей собственной инфраструктуре.
Размещение и интеграция сервисов в рамках уже существующей It-архитектуры организации и обеспечение механизмов безопасности в таких инсталляциях зачастую бывают затруднены.
Расскажем как мы реализовали работу протокола Kerberos в средах K8s/Istio Service Mesh, почему это было так сложно и какие преимущества мы получили.
В процесс доклада рассмотрим несколько конкретных примеров организации работы сервисов с протоколом Kerberos в средах K8s/Istio Service Mesh под высокой нагрузкой.

Статанализ можно встроить в разные стадии пайплайна, чтобы получить дополнительный инструмент контроля кода (тезис в работе).

Трудности использования Vault по гайдам от hashicorp и боль от знакомства с ними.

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

Пара реализаций скриптов для передачи секретов (небольшой набор шаблонов). Использование известных методов работы с секретами (envconsul, consultemplate) и не совсем привычных (docker). Со своими примерами из жизни.

Интеграция с gitlab и описание своего кейса, безопасный просмотр секретов и diff их изменений перед раскаткой на серверы, и зачем мне это нужно. Использование секретов с PHPи Go и подгрузка их как env.

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

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

Container Attack Simulation Framework - попытка создать фреймворк для симуляции атак с архитектурой, которая позволяет закрыть все тактики и техники по популярным классификациям атак на контейнеры.

Аббревиатура CI/CD стала банальностью за последние несколько лет. Тема, казалось бы, настолько изъезжена и тривиальна, что не достойна внимания. Но дьявол кроется в деталях. В докладе расскажу об идеях CI/CD, которые часто остаются за бортом, превращая ценный набор практик в карго-культ.

Наши системы могут состоять из нескольких сотен микросервисов. Релизов на самые востребованные системы до несколько десятков в день. Из-за организационных особенностей в релизе могут участвовать несколько сервисов разрабатываемых разными командами. В докладе будет рассказано как организовать релизный цикл от dev до prod через парадигму GitOps с использованием одного стека инструментов и не сломаться. Используемый тех. стек: ArgoCD, GitLabCI, kubernetes, Jenkins. В докладе подниму и разберу в деталях вопросы, касающиеся CD:
a. Сложность развертывания нескольких сотен сервисов от dev до prod и поддержание в актуальном виде их окружений
b. Решение проблемы переиспользования кода и переменных
c. Отчуждаемость и сходимость окружений от вносимых измений
d. Познакомимся с custom plugins для ArgoCD и интеграцией с vault
e. Рассказываем про автоматизацию для этого процесса
f. Мониторинг и алертинг
Прослушав доклад, слушатели поймут и разберутся в подробностях, как можно использовать парадигму GitOps на больших проектах. В дополнение расскажу про подводные камни, и как мы их обходим.

- Что такое телеметрия и какую проблему решает
- Какие компоненты нужны для сбора телеметрии
- Доступные инструменты
- Особенности планирования архитектуры сбора телеметрии
- С какими ошибками можно столкнуться и как их избежать

В докладе поделюсь опытом исправления критической ошибки в Ansible playbook, из-за которой происходил 'сброс' кластеров Kubernetes.
- Рассказ как использовать идею тестирования кода применимо к IaC
- Примеры как можно разрушить критические элементы инфраструктуры и что может последовать.
- Как идентифицировали и устранили эту ошибку, и какие шаги предприняли для предотвращения подобных проблем в будущем.
- Насколько важно тестировать Ansible playbooks, особенно в контексте их взаимодействия с другими инструментами с примерами.
- Практические советы по обеспечению надёжности инфраструктурного кода.

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

Мы выпустили уже больше 35 релизов на протяжении 7 лет. Прошли путь от сборки на компьютере разработчика до почти полной автоматизации с помощью TeamCity.
В своём докладе расскажу с какими трудностями столкнулись, как их преодолевали, что так и не удалось победить.
Заглянем под капот нашего пайплайна разработки, расскажу про наши оптимизации.

В докладе обсудим, почему практика noblame culture не всегда хороша. Как мы пересекаем ту черту, когда она перестает работать и скрывает плохие конфликты. Обсудим, когда конфликты хорошо, а когда плохо, и что можно вынести из хороших конфликтов.
Как практика влияет на культуру команды, а культура - на эффективность команды. Покажем в цифрах влияние культуры на производительность.
Немного попробуем поговорить о noblame culture и бирюзовых кампаниях, а еще, почему бирюза не такая классная, как думается

Ansible — де-факто один из самых популярных инструментов IaC, но все ли умеют его готовить?

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

В рамках доклада затронем темы:
- Организации структуры проекта
- Переиспользования ролей
- Тестирования ролей
- Идемпотентности и ловушках, которые могут привести к fatality на production
- Абстракциях Ansible, а в частности интерпретацию переменных
- И многое другое

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

Когда микросервисов слишком много, становится сложно с ними жить и запускать новые. Чтобы запустить новый сервис, нужно создать репозиторий, настроить CI/CD pipeline и интеграции. А если что-то в инфраструктуре меняется или добавляется? Как централизованно внести изменения в сотни репозиториев?
В своем докладе я расскажу, как мы стандартизировали разработку, сделали общий CI/CD pipeline и общий app-chart для всех backend сервисов. Покажу, как мы обновляем pipeline, app-chart и куда движемся дальше.

Тезисы:
-Пререквизиты для общего helm app-chart и CI/CD pipeline.
-Тестирование и дебаг helm app-chart и CI/CD pipeline.
-Разработка и обновление helm app-chart и CI/CD pipeline в рамках большой организации с большим количество backend сервисов.
-Культура Innersource и ее внедрение.
-Интеграция новой функциональности в helm app-chart и CI/CD pipeline.

На докладе "Все еще не можешь разобраться в DevOps? Приходи, помогу!" мы обсудим проблемы DevOps движения и области, которые остаются не раскрытыми, поговорим о том, какие бывают DevOps практики , поднимем вопросы о том, что такое организационные Capabilities и их взаимосвязь с DevOps. Обсудим что считать "хорошей практикой" и почему, поговорим про то как измерять и управлять большими данными которые измеряют DevOps практики. Рассмотрим разработанную нами модель, которая не является "еще одной моделью", а делает перерождение для индустрии и открывает новые возможности вбирая в себя лучшие практики и стандарты в мире разработки и эксплуатации. Все это мы обсудим сквозь призму практического опыта в Райффайзен Банке и индустрии в целом.

GitOps очень популярный подход. Он выглядит действительно очень привлекательно, если рассматривать только его. "Stop scripting and start shipping" звучит многообещающе.
Но, когда мы возвращаемся в реальный мир, мы видим что GitOps - всего лишь шаг деплоя в сложном CI/CD пайплайне со сборкой, тестами кода и безопасности и многим другим.
И чтобы принести сюда GitOps, мы должны хорошенько поскриптить... Мы должны переписать шаг деплоя в нашем пайплайне с (для примера) "helm upgrade" на "git push" и установить тяжелый тулинг (вроде Flux или ArgoCD).
И этот тулинг зачастую не так хорошо вписывается в ваши процессы, потому что имеет свои требования и ограничения.
Хорошо. Если вы должны писать скрипты в любом случае, может быть, стоит написать свою реализацию GitOps с минимальными затратами?
Давайте обсудим суть паттерна GitOps, его преимущества и недостатки и сделаем свою реализацию GitOps с нуля.

пока черновые тезисы:

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

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

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

- Автоматический деплой feature ветки через ApplicationSet с SCM Provider Generator
- Конфигурация приложений через Consul и Vault
- Организация репозиториев и CI при GitOps подходе
- Жизненный цикл feature ветки и ресурсов относящихся к этой ветке

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

DevOps как движение появилось 15 лет назад, самое время подвести итоги и посмотреть что будет дальше. В докладе я расскажу что будет после DevOps, будет ли вторая волна или появятся новые лидеры и движения. Обсудим тренды и проблемы в разработке и эксплуатации, новые подходы и инструменты. Разберем исследования, публикации и отчеты, книги и конференции, компании и экспертов. Рассмотрим такие направления, как Platform Engineering, Developer Experience, Internal Developer Platforms, DevTools 2.0, ClickOps, AIOps, Productivity Engineering, Cloud Native, Reliability Engineering, Resilience Engineering, Team Topologies.

Расскажу про то, как мы в Эвокарго пытались внедрить систему для сборки C++ проектов - conan. Как потратили на это много ресурсов и ничего в итоге не получили. Хотя, на самом деле, не совсем ничего - и об этом доклад!
Я расскажу о проблемах, которые мы сами себе создали, внедряя новые технологии сборки, и какие выводы сделали.
Доклад будет про DevOps-философию и про то, почему важно разработчикам применять её в своей работе.

Представьте, что вам отдают в один день всю тестовую инфраструктуру, которую делали порядка 5-7 лет и говорят, что она работает плохо. А надо, чтобы хорошо. Прошел год, мы сделали хорошо.
Поговорим:
- о метриках. Какие собирали, как собирали, к чему пришли.
- об архитектуре. Какая была, как ее строили, как перестраивать и как эволюционно готовиться к техническим реформам.
- о процессах вокруг тестовой инфраструктуры. Хороших практиках в процессах и не очень.
- о людях, которые участвуют в метриках, архитектуре и процессах.

DevOps инженеры легко становятся заложниками одной из двух моделей восприятия:
1) Задача DevOps автоматизировать процессы, чтобы быстрее поставлять ценность конечному потребителю (при сохранении или росте качества) – а значит DevOps отвечать должны и за то, какую ценность несет поставка. То есть думать о бизнесе, стратегии и поддержке процессов разработки!
2) Задача DevOps закрыть на уровне инфраструктуры все проблемы, которые можно снять с плеч разработки и бизнеса, чтобы те сосредоточились на «действительно важном». То есть решать проблемы, не задавать вопросы, подставлять «инфраструктурные костыли».
Но, я предлагаю рассмотреть DevOps инженера, как одного из «проектировщиков» компании – обязательного участника архитектурных комитетов, ответственного за полноту представляемых решений и экспертизу.
В докладе я хочу показать каким супер-зрением должен обладать человек, занимающийся проектированием. Разобрать кейсы, в которых «губительными» могут стать решения «латать инфрой и руками DevOps» имеющиеся проблемы.
Мы рассмотрим 5 видов зрения, которыми должен обладать проектировщик: бизнес, системное, интеграционное, инфраструктурное и управленческое видения. Разберем, на примерах, как связаны эти вижины между собой и с какими задачами помогают справиться. А также обсудим, как откалибровать зрение с помощью метрик.
Поделюсь опытом включения DevOps инженеров в практики архитектурных решений (включая участие в формировании артефактов ADR и ADL – продемонстрирую шаблоны), инцидент-менеджмента (включая контроль PIR – поделюсь шаблоном), формирования корпоративной библиотеки инструментов.

В своем докладе я сделаю фокус на управлении и масштабировании команды:
— Как мы переходили аутсорса к управлению внутренними ресурсами, улучшив при этом коммуникацию и процессы.
— Как выстроили системы метрик с нуля и интегрировали в рабочие процессы.
— Стратегии набора и управления ростом команды инженеров.
— Поделюсь нашим подходом к расчету SLA и других ключевых метрик, что критично для поддержания высокого качества сервисов.

Приходя в компанию, ты всегда начинаем изучать - какие процессы, культура и технологии в ней используются. Ты смотришь на допустимые уровни трансформации и готовность команд к изменениям на пользу компании, параллельно с её ростом.
Отловив насущные проблемы, потушив самые пламенные пожары и внедрив, хоть и со скрежетом, процессы представления "DevOps as a Service", начинаешь размышлять о следующих шагах развития данной модели.

Совместив знания и опыт itsm, dasa devops, maturity matrix, devops governance, westrum, kanban, картинка дальнейших шагов начинает складываться ясней. А те решения, которые могли показаться спорными или не оптимальными, остаются в прошлом или претерпевают трансформацию.

Повествование пойдёт о том, как на примере компании Bimeister поэтапно случилось внедрение DaaS. Какие тяжести ждали на этом пути, какие решения были изначально верными, а какие спорными, к чему это привело и какие мысли о будущем посещают сейчас.

Заполню позже

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

Создавая продукты, работу которых нужно гарантировать в закрытых контурах клиента, забывать об мониторинге никак нельзя. При слой observability должен быть как можно компактней. А может быть компактной вся инфраструктура observability? А если она достаточно компактная, значит не очень дорого сделать её распределенной.
В своем докладе я буду концентрироваться на вопросах:
- Как и, главное зачем, связкой "Vector > ClickHouse < Grafana" переизобретать инфраструктуру Observability?
- Как структурировать и сколько хранить телеметрию?
- Как SQL-ем работать с телеметрией разного формата и назначения?
- Насколько Vector готов к бою, а ClickHouse к телеметрии?

В докладе поделюсь опытом перехода от системы EFK (Elasticsearch + Fluentd + Kibana) к более эффективной системе с использованием Vector.dev (0.26). Расскажу, почему Elastic оказался неподходящим и какие преимущества принёс Vector.dev в плане производительности и экономии ресурсов.

Еще:
— Как мы автоматизировали преобразования логов в метрики, и как адаптировали систему логирования под растущее количество сервисов.
— Обсудим, как мы определили стандарт логов и создали универсальную модель хранения в Clickhouse, значительно сократив код трансформов и упростив анализ логов для разработчиков и команд DevOps/SRE.
— Поделюсь нашими планами на будущее для дальнейшего усовершенствования системы, включая наблюдение за лимитами логов и тротлинг логов при их превышении

История о том, как мы в компании столкнулись с классической дилеммой: как объяснить бизнесу ценность SLI/SLO, когда всё, что им нужно — одна цифра, показывающая, всё ли хорошо.

Начиная с классики, на самом старте мы внедряли SRE-методологии от Google. Но собрать данные со всех endpoints и покрыть их метриками — это только полдела. Когда метрик стало слишком много, начался настоящий хаос...

У каждого специалиста есть так называемый "цифровой портрет", который состоит не только из резюме на job-сайте или профиля в Linkedin. Помимо стандартных площадок его формируют GitHub, Хабр, StackOverflow, Codeforces, сайты конференций, личные страницы, VK, FB, X, YouTube и куча других ресурсов.

Современные инструменты подбора (напр. программы которые автоматически интерпретируют GitHub профили) сейчас позволяют рекрутеру быстро собрать сведения о кандидате со всех площадок, составить свое мнение о "реальном опыте" и на основании этого предложить ту или иную вакансию.

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

"Цифровой портрет" - это гигиенический минимум для того, чтобы самостоятельно формировать свой карьерный трек, а не просто откликаться на предложения.

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

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

Сегодня многие крупные компании разворачивают K8s в своей собственной инфраструктуре.
Использование стандартного "облачного" подхода к автоскейлингу в таких инсталляциях затруднено.
Расскажем как мы сформировали требования к работе автоскейлера в фиксированных ресурсных квотах, как реализовали прототип на KEDA и каким в результате получился наш собственный автоскейлер.
Поговорим о вариантах экономии ресурсов за счет использования автоскейлинга в on-premise инсталляциях K8s.

Сколько стоит жить в облаке?
Почему облако может оказаться гораздо дороже, чем купить 20-30 серверов и строить свою инфраструктуру.
Что ест ресурсы при работе с облаком (и не только).
Реструктуризация расходы на облачное CICD
Как можно сбалансировать расходы на облака.
Практические рецепты по оптимизации расходов на примерах.

Облака предоставляют огромное количество плюсов по сравнению с собственной инфраструктурой. Они позволяют быстрее выводить новые продукты на рынок, брать почти неограниченное количество ресурсов в любой момент времени, сокращать TTM. Но за все хорошее приходится чем-то платить. Обратной стороной облаков является существенно большая стоимость ресурсов ядра/памяти, чем на собственной инфре.
Этот доклад о том, как получать максимум от облачных решений и остаться в рамках разумного бюджета с помощью подходов FinOps. Ценный опыт и инсайты прилагаются.

В докладе расскажу про вызовы и решения с которыми мы столкнулись, когда переходили на 3 active ЦОДа.
- В чем была проблема старой схемы active-passive
- Как внедрили мастер-мастер репликации с режимом чтения для одного ЦОДа.
- Сложности перехода монолитов на схему мультицодов, когда архитектура сервиса к этому не приспособлена: базы, кэши, балансировка, деплой, кроны, очереди, ...
- Как разработали автоматизированную систему для управления переключением ЦОДов.
- И сделали автоматическое переключение на уровне балансировщиков на основе кодов ответа или времени ответа.

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

Как мы попробовали Canonical MaaS и почему мы от него отказались
Архитектура системы через призму безопасности
Гибкость и отчуждаемость - как сделать систему настраиваемой, но не привязать её к конкретному проекту
API для тестов - простота и удобство
Эволюция развёртывания ОС: с 40 до 2 минут на сервер
Особенности железа, про которые никто не говорит

1. Что такое Реестр отечественного ПО и кому он может быть полезен?
С 2023 г. компании, которые относятся к критической инфраструктуре обязаны прекратить использование иностранных программ и перейти на использование отечественного софта. Отечественный софт — софт, который включен в Реестр российского ПО, поэтому в скором времени весь софт, используемый компаниями, должен быть из Реестра российского ПО.

2. Какие есть плюсы у Реестра?
При помощи Реестра можно легализовать использование иностранного опенсорса.
Для компании также дает много бонусов: коммерциализация внутренних разработок, экономия на налогах, IТ-аккредитация, отсрочки от армии и льготные ипотеки.

3. Что важно учесть в разработке для включения в Реестр? Можно ли использовать иностранный опенсорс в разработке?
Для включения в Реестр есть требования к техстеку: не все опенсорс-продукты можно использовать в программе. В докладе расскажем, какие компоненты использовать можно, а какие точно нельзя.

4. Какие еще есть требования к программам? Отдельно рассказываем про требования для Средств обеспечения информационной безопасности и Офисного ПО.
Есть требования к месту хранения кода, сайту компании и другие. Подробно разбираем каждое.
Отдельно рассказываем про требования для Средств обеспечения информационной безопасности и Офисного ПО.

5. Разбираем примеры тех, кто смог.
Покажем примеры программ, которые можно зарегистрировать: обучающих мультимедийных курсов, тренажеры-имитаторы, системы управления процессами, простые библиотеки, встроенное ПО для «железа» и много чего еще

6. Немного о ПАК.
С недавнего времени в Реестре стало возможным зарегистрировать программно-аппаратные комплексы, поэтому все больше программ будет включаться в Реестр.

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

Банк ВТБ перешел на импортозамещенный стек DevOps

На сегодняшний день микросервисная архитектура находится в самой активной стадии своего развития. При масштабировании увеличивается и число манифестов, с которыми необходимо работать инженерам. Но как структурировать такой объем конфигураций?
Расскажем, как упростить работу с k8s манифестами с помощью инструмента CUE, о его основных преимуществах и сравним с уже активно используемыми Helm, Kustomize. Рассмотрим особенности данного подхода на демо-примере.
Для кого: разработчики, DevOps-инженеры

В подразделении билайн бизнес 12 продуктовых команд. Команды работают над широкой линейкой продуктов с использованием машинного обучения для B2B клиентов. Часть продуктов относится к компьютерному зрению и аудиоаналитике, где используются нейронные сети на отдельном GPU кластере. Другая часть продуктов использует неперсонализированную информацию об абонентах и основана в основном на классическом ML с вычислениями на Hadoop кластере.
В билайне используется концепция Data Mesh распределенного управления данными. Доменными единицами являются продуктовые команды, которые строят необходимые им витрины данных и занимаются их менеджментом. Некоторые команды собирают таблицы, которые могут насчитывать около 10 тысяч фичей. Большой популярностью для построения различных моделей пользуются, например, ГЕО фичи или графовые фичи. Фичи могут обновляться на ежедневной/еженедельной/ежемесячной основе.
В билайн бизнес на проде крутится порядка 100 ml-моделей с различным расписанием их использования: от ежедневного до ежемесячного. Каждая модель запускается на разном количестве абонентов (строк): от 10 млн до 200 млн. Итого в пике ежедневная нагрузка по Spark джобам на кластере доходит до обработки 1млрд. строк. В среднем же в сутки обрабатывается около 50 млн. строк.
Большой парк моделей и фичей требует внимательного тестирования и построения прозрачных связей между ними. В докладе прозвучит бриф нашего MLOps пайплайна. Акценты будут расставлены на том, как мы организовали процесс тестирования в MlOps цикле и построили эффективный lineage между моделями и фичами. Расскажем влияние появившихся технологий на процесс разработки и деплоя моделей. Подсветим положительные эффекты, которые мы получили.

Яндекс Go это система из 800 микросервисов на бэкенде. Полтора года назад перед нами встала задача сильно вырастить аптайм. В докладе я расскажу как мы этого добивались, где ошибались, а где принимали правильные решения. Доклад носит обзорный характер: я расскажу о десятках сделанных аптайм-проектов без глубокого погружения в каждый из них. Предоставлю ссылки на статьи и доклады для углубленного изучения связанных тем, например, metastable failure state.

В докладе рассмотрим, с какими сложностями сталкивается команда развития и эксплуатации АС, работая с централизованной моделью мониторинга в зрелой компании корпоративного сегмента. Если коротко, то мы решали проблему оперативного редактирования прикладных метрик при соблюдении требований информационной безопасности. В итоге удалось сократить время изменений по метрикам с нескольких дней до минут. Мы разберем виды метрик: инфраструктурные, системные, прикладные, - обсудим требования к актуальности и динамическую природу прикладных метрик. Расскажем о гибридном решении, которое позволяет сохранить достоинства централизованной модели и гибкие настройки прикладных метрик. Покажем соответствие практикам DevOps по скорости реакции на изменения, самодокументирования и деплоя. Доклад может быть интересен всем, кто анализирует поведение АС путем мониторинга: команда эксплуатации (вторая и/или третья линия поддержки), команда развития, devops инженеры, администраторы баз данных, техлиды, тимлиды, ИТ-менеджер уровня АС, владельцы и менеджеры продукта.

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

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

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

- Перед нами встала задача обеспечения автоматического фейловера 100+ баз в нашем продукте VK WorkMail для обеспечения бесперебойной работы нашего решения (Почты, Облака и Календаря).
- Для решения этой задачи мы разработали средство автоматического фейловера Overlord.
- Overlord написан на языке Go, работает в связке с ETCD и Envoy и не требует кворума для своей работы.

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

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

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

* Сравнение производительности - как кубер, который вроде бы также жонглирует контейнерами, держит нагрузку лучше в два раза
* Подводные камни, с которыми столкнулись - проблемы с DNS и прочие
* Кишки решения - ansible скрипты, пайплайны и прочее
* Плюсы и .. минусов почти нет, но тем не менее, описания впечатлений у команд
* Как и почему мы пришли к такой жизни

Подавали от Ассоциации финтех

Ты сидишь и в очередной раз размышляешь о смене работы. Друг зовёт к себе в классный стартап, который "вот-вот станет убийцей Икс и вернет былой твиттер", бывший лид рефералит в крупнейший корпорат, в котором "наша команда и продукт вообще отдельно от основной компании, у нас тут всё иначе, вот увидишь!", а рекрутер неумолимо манит оффером в крупный аутсорс "с самыми адекватными клиентами и командами".

Дилемма..

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

А что если..?

В рамках https://techleadconf.ru/2023/abstracts/11348 я рассказываю про риски и упоминаю метод Risk Storming
Мой куратор предложил отличную идею - провести небольшой воркшоп по методу.

Использование Helm-чартов для упрощения упаковки, настройки и развертывания приложений и сервисов в кластерах Kubernetes уже стало индустриальным стандартом. Чарты позволяют использовать один шаблон под разные сервисы и в разы сэкономить время. Но есть ли способ еще больше упростить процесс?

В своем докладе я рассмотрю преимущества и недостатки двух подходов: создание супер-чарта и создание отдельных стартеров.

Супер-чарт (или монстр-чарт) представляет собой большой универсальный чарт и содержит множество различных чартов, объединенных в одну структуру. Он удобен как единая точка изменений, но при этом может быть сложен в управлении и поддержке.

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

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

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