Заявки на доклады

Поиск по тегам:
Показать только принятые доклады

SRE-практики

В этом докладе мы разберём две популярные утилиты: ArgoCD и FluxCD

- Что такое GitOps и какие проблемы он решает
- Установка FluxCD, ArgoCD и паттерны их использования
- Плюсы и минусы обоих решений
- Практики организации Git-репозитория и разработки приложений
- Настройка прав доступа и кастомных плагинов в ArgoCD
- Опыт использования ArgoCD для развёртывания Kubernetes-кластеров и управления приложениями в Bare Metal среде.

Программный комитет ещё не принял решения по этому докладу

С точки зрения процессов и практик, все, что описано в SRE => детально описано и специфицировано уже 20 лет как в ITIL (первую редакцию не принимаю в расчет).

При этом SRE — слава и почет в нашей с вами милой тусовочке. А ITIL всячески поливается лучами ненависти.
Значит, отличия все же есть? Да, конечно, и не только культурные.

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

15+ лет в Operations — интересно все это вспоминать в ретроспективе.

Доклад принят в программу конференции

Инфраструктура как код

* Контейнеры и оркестры нового поколения. Изучаем вопрос, общаемся по проблемам.
* Как изменится мир контейнеров после отказа от сборщика docker в оркестранте k8s?
* Как изменится openshift при переходе на cri-o и CoreOS?
* Обсуждаем VmWare Project Pacific и Nutanix на примере пилотов и решения поставленных задач.
CI/CD по кнопке — миф или реальность?

Программный комитет ещё не принял решения по этому докладу

- State файл и методы и боли его хранения
- Логическое разделение terraform проектов внутри репозитория
- Как сделать CI чтобы ничего не сломать по дороге к продакшену
- Шаги по ревью и аппруву изменений
- Чиним если сломали, и откат state файлов

Программный комитет ещё не принял решения по этому докладу

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

Доклад принят в программу конференции

Разработчики любят запускать на своих машинах одноразовые задачи: миграции, очистки сессий, прогрев кэша, импорт данных. А потом они приходят и хотят сделать то же самое на стейджинге и проде. А у нас Kubernetes. И мы не хотим, чтобы кто-то ходил в поды ручками и что-то там делал. Мы хотим кнопку, ревью кода, логи и чтобы это все пережило следующий релиз.

В докладе я расскажу про все те способы, которые перепробовал: Helm-чарты, операторы, Jenkins, GitLab и даже AirFlow. Так получилось, что Kubernetes не очень хорошо умеет в jobs. Он все-таки оркестратор, а не scheduler. Поэтому, если хотим сделать хорошо, то приходится делать самим!

Доклад принят в программу конференции

Инфраструктурная платформа

Здравствуйте, меня зовут Виталий, и так получилось, что я упоролся по Ceph и SDS в целом. До такой степени, что в итоге реализовал собственную систему — Vitastor — быструю, простую, при этом имеющую аналогичную Ceph-архитектуру и, в принципе, потенциал для развития в его полную замену. В отличие от многих других «убийц цефа». :)

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

Для начала и для тех, кто менее погружён в тему, я расскажу о том, что вообще такое SDS (программные СХД) и зачем их вообще используют — а используют их многие «облачные» провайдеры — Amazon, Google, Yandex, mail.ru… Кратко остановлюсь на том, почему Ceph и внутренние SDS в облаках на самом деле не очень-то быстрые, а многие другие — вообще непригодны для production (консистентность — не пустой звук).

После этого перейду к рассказу о Vitastor. На данный момент система разрабатывается мной в 1 лицо примерно год в расслабленном темпе в свободное время (идеи до этого вынашивались ещё год-два) и насчитывает примерно 25000 строк кода — пожалуй, можно сказать «всего лишь 25000 строк кода» — и при этом поддерживает базовый функционал распределённой программной СХД без единой точки отказа. Я расскажу о выбранной архитектуре, о том, чем она схожа с Ceph и чем она от него отличается, почему я считаю такой путь правильным и какие у него могут быть недостатки и преимущества.

Покажу тесты производительности и сравнение с Ceph, расскажу о планах и потенциале дальнейшего развития. Конечно, система только недавно «родилась», многих функций в ней на данный момент ещё нет. Но в планах и реализация снапшотов, и контрольных сумм, и оптимизаций для SSD+HDD, и удобного Web-интерфейса, и даже, возможно, ФС. При должном запале всё это сделать вполне реально.

В общем, я выполнил совет — хватит ругать Ceph в чатах — возьми и сделай сам лучше! Взял, сделал. Осталось довести до production.

Программный комитет ещё не принял решения по этому докладу

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

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

Поделимся опытом и некоторыми кейсами, связанными с решением задачи построения платформы.

Доклад принят в программу конференции

Основные практики поставки интеграционных решений в облачной инфраструктуре

Программный комитет ещё не принял решения по этому докладу

Архитектура в DevOps, DevOps для CTO

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

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

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

Программный комитет ещё не принял решения по этому докладу

Оптимизация процессов, повышение качества контроля метрик, распределённая параллельная разработка

Программный комитет ещё не принял решения по этому докладу

DevOps-трансформация

Devops отдел - суровое будущее больших компаний и не только
Кризисы и их решение благодаря проектному подходу к автоматизации
Роли в Devops отделе и подбор персонала для этих ролей.
Документация - необходимое зло или "один бокал хайпа bus-фактора за соседний столик"
Кто победит: "девопс в команде" или "девопс в команде в отделе в команде"

Программный комитет ещё не принял решения по этому докладу

Если:
- у вас в компании есть DevOps-отдел;
- вы задумываетесь о том, чтобы объединить всех девопсов в один отдел;
- кто-то в компании раскатал кластер кубера, и теперь мы их зовем DevOps-отдел;
то у меня для вас плохие новости...

Доклад принят в программу конференции

Больше 10 лет прошло с момента первой легендарной конференции DevOps Days в Генте. За это время в мире появилось с несколько дюжин различных коллабораций с Ops-спецами, начиная с класических DevSecOps-ов, заканчивая диковинными HugOps-ами.
Для того, чтобы понять куда всё катится, послушаем истории из жизни различных компаний, которые стали причиной появления новых течений и проанализируем направления, куда ещё можно развиться DevOps специалисту.

Программный комитет ещё не принял решения по этому докладу

Трейсинг распределенных запросов - один из столпов observability микросервисной архитектуры. Мы рассмотрим как технически реализуется трейсинг, какие преимущества дает трейсинг для диагностики проблем производительности, необходимые усилия для внедрения трейсинга своими силами, стандарты в этой области и как им следуют производители APM решений и opensource инструменты.

Программный комитет ещё не принял решения по этому докладу