Заявки на доклады
Безопасность, DevSecOps
Данный доклад представляет собой взгляд специалиста по информационной безопасности на возможности, которые предоставляют контейнеры и система оркестрации контейнеров Kubernetes для обеспечения непрерывной безопасности приложений на всех стадиях их жизненного цикла.
В докладе рассматриваются проблемы защищенности внешних библиотек, используемых разработчиками:
* почему опасно использовать одновременно внутренние и внешние репозитории зависимостей;
* какие угрозы связаны с использованием внешних компонент;
* какие технические средства есть у DevOps, чтобы снизить риски при использовании внешних компонентов.
При разработке и эксплуатации сервисов у нас остро стояла проблема хранения и доставки актуальных секретов к сервисам.
За многолетний опыт компании мы использовали множество инструментов. Большинство из них не подходят для использования в Kubernetes. Мы выбрали Vault и Sidecar Injector, и я расскажу, почему. Как мы решали возникающие трудности (unseal, ENV, cronjobs). Что мы храним в коде (spoiler: все).
Сейчас секреты могут быть доставлены во множество сервисов в различные нэймспэйсы.
В результате мы получили надежное, отказоустойчивое и масштабируемое решение.
Исходный код сервисов полностью избавлен от каких-либо секретов.
Данное решение можно легко развернуть в своем Kubernetes-кластере уже сейчас.
Обсудим особо чувствительные места проектов как с точки зрения информационной безопасности, так и с функциональной, а именно:
- процессы ИБ и те подпроцессы, которые запускаются в рамках проектной деятельности;
- где ИБ активатор и драйвер, какие аргументы используются?
- где ИБ тормоз и раздражитель, какие контраргументы могут помочь?
- базовые инструменты для понимания направленности ИБ в вашей компании.
Обучение и управление знаниями
Как бы ни хотелось, но профессия девопса состоит не только из разработки архитектур. Чаще всего это сервисная работа по сопровождению инфраструктуры разработки, инфраструктуры проекта.
Сервисная работа предполагает, что ты выполняешь "запросы пользователей" — сиюминутные задачи от других участников команды. Случается, что несколько человек просят что-то одновременно, что человек ждёт чего-то невыполнимого и требует результат поскорее.
Во многих ситуациях люди остаются недовольны работой девопса и воспринимают ее как само собой разумеющееся. Как с этим жить, как организовать время, как организовать работу с руководством, как организовать свой рабочий процесс так, чтобы он не превратился в бесконечное затыкание дыр, и что сделать, если он уже превратился в него?
Порой на вашу команду или команды ложится непосильная задача совмещения кучи разных активностей в рамках работы и одной простой фразой "лучше расставляйте приоритеты" не отделаться. Для примера, вы можете активно разрабатывать новый продукт, дорабатывать и развивать существующий продукт, осуществлять функцию третьей линии поддержки, исправлять дефекты, совершенствовать подход к разработке, рефакторить старье и т.п. и надо делать все, и надо как-то на все порваться.
Мой доклад будет о том, как можно справляться с подобного плана задачами. Я расскажу теорию, поясню на примерах, как это делается на практике, поделюсь лайфхаками и наблюдениями.
Нет плохих и хороших компаний.
Нет плохих и хороших кандидатов.
Есть просто более подходящие и менее подходящие друг другу.
1. Гадаем по профилю.
Кандидаты узнают, почему резюме недостаточно, с чего начать поиск работы и на что обращать внимание при выборе вакансий и компаний.
А нанимающие лиды поймут, как составить портрет кандидата, как определить задачи, каких типичных ошибок можно избежать.
2. Первое свидание (то есть собеседование, конечно).
Кандидаты станут еще лучше готовиться к собеседованию, определят, какие вопросы задавать компании, как реагировать на токсичные вопросы, как самому не быть токсичным.
Компании узнают, как построить адекватный процесс найма, чего можно избежать, как токсичные вопросы превратить в вопросы, ответы на которые действительно важны.
3. А сколько ты зарабатываешь?
Поговорим с кандидатами о том, как задавать вопросы о потенциальной зарплате, как и зачем "торговаться".
Нанимающие лиды смогут определить зарплатную вилку и сумму в оффере для конкретного кандидата, не сравнивая людей внутри компании.
4. Принятие решение по офферу.
Как выбрать оффер кандидату и как правильно завершать работу на текущем месте.
Нанимающие лиды поймут, как готовиться к выходу нового человека в команде.
5. Испытательный срок и серьезные отношения. Пройти нельзя уйти.
Почему 3 месяца, зачем нужен, что проверить.
SRE-практики
Поговорим о том, как и зачем команда разработчиков Kubernetes тестирует свои релизы. Какой опыт можно из этого извлечь и чем это может помочь администраторам кластеров, разработчикам и архитекторам.
Расскажу, как сделать очень большой кластер недорого и какие инструменты для этого использовать.
Соберем свой большой кластер и проверим, как Kubernetes переносит масштабирование, когда количество нод переваливает за 5 тысяч. Рассмотрим, как это влияет на мастер-компоненты и попытаемся побить некоторые рекорды масштабирования.
Найдем отличия реального кластера от симулированного, а также сравним основные показатели производительности основных компонентов.
Сделаем нагрузочное тестирование и узнаем, что будет, если в нашем кластере поселился ворклоад. Посмотрим, как чувствует себя мастер с большим количеством создаваемых и удаляемых ресурсов.
Обсудим наш опыт и коллекцию собранных граблей, а также, на что стоит обратить внимание при создании и тестировании кластеров для будущего продакшна.
* FAANG SRE vs текущие реалии.
* Мы написали свой оркестратор — у нас теперь SRE?
* Как живут без SRE? На примере энтерпрайза.
* Кого ищут под словом SRE?
* SRE — антипаттерн DevOps.
* Кому нужен SRE по книге?
В этом докладе мы:
• Разберёмся в терминах Continuous Integration, Continuous Delivery и Continuous Deployment.
• Выясним наконец, что такое GitOps и какие проблемы он решает.
• Рассмотрим популярные утилиты: ArgoCD, FluxCD и паттерны их использования.
• Разберём практики организации Git-репозитория и настройки пайплайнов.
• А также копнём чуть глубже и детально рассмотрим настройку прав доступа и кастомных плагинов в ArgoCD.
Наконец я расскажу про наш опыт использования ArgoCD для развёртывания Kubernetes-кластеров и управления приложениями в Bare Metal-среде.
С точки зрения процессов и практик, все, что описано в SRE => детально описано и специфицировано уже 20 лет как в ITIL (первую редакцию не принимаю в расчет).
При этом SRE — слава и почет в нашей с вами милой тусовочке. А ITIL всячески поливается лучами ненависти.
Значит, отличия все же есть? Да, конечно, и не только культурные.
Какой единый фундамент заложен в SRE и ITIL и почему его обязательно важно знать и понимать всем, кто занимается Operations. Какие отличия между этими двумя подходами вызывают такое противоположное отношение, не только культурологические, хотя и они тоже.
Обсудим точки зрения на сходства и различия подходов в рамках бушующего круглого стола!
Инфраструктура как код
Подход immutable infrastructure известен многим, но при этом количество организаций, активно использующих этот подход, не так уже и велико.
В этом докладе мы разберемся в том, что такое immutable infrastructure, зачем его применять и в каких случаях этот подход является наиболее выигрышным. А также рассмотрим основные проблемы, с которыми сталкиваются организации при внедрении этого подхода, и практические методы решения этих проблем, основанные на реальном опыте внедрения подхода в разных организациях.
- Когда вам нужно внедрять тестирование терраформ-кода на безопасность?
- Инструменты для линтинга.
- Инструменты для тестирования кода на безопасность.
- Проблема кастомизации инструментов для тестирования безопасности.
- Интегрирование инструментов тестирования в CI.
- Куда и как отправлять репорты, чтобы их заметили и не игнорировали.
Разработчики любят запускать на своих машинах одноразовые задачи: миграции, очистки сессий, прогрев кэша, импорт данных. А потом они приходят и хотят сделать то же самое на стейджинге и проде. А у нас Kubernetes. И мы не хотим, чтобы кто-то ходил в поды ручками и что-то там делал. Мы хотим кнопку, ревью кода, логи и чтобы это все пережило следующий релиз.
В докладе я расскажу про все те способы, которые перепробовал: Helm-чарты, операторы, Jenkins, GitLab и даже AirFlow. Так получилось, что Kubernetes не очень хорошо умеет в jobs. Он все-таки оркестратор, а не scheduler. Поэтому, если хотим сделать хорошо, то приходится делать самим!
Вы разрабатываете servrless-приложения и хотите выстроить для них правильные CI/CD-пайплайны?
В рамках доклада я расскажу, какие инструменты предлагает AWS для реализации таких пайплайнов. Мы рассмотрим новые возможности по упаковке AWS Lambda в контейнеры и как это может упростить переиспользование уже существующих подходов. Рассмотрим такие инструменты, как AWS Serverless Application Model, AWS CodeBuild, AWS CodePipeline и AWS CodeDeploy.
Думаю, что многим не хотелось бы переплачивать лишнее, тем более, если речь идет об облачной инфраструктуре. Кто-то только слышал, а кто-то уже и использует Spot Instance. Но что происходит с затратами, почему они переменные, почему в конце месяца счет за споты получился вдвое выше?
* Краткая предыстория *
У нас было два монолита, полтора десятка сервисов и полсотни окружений dev-qa-prod. Мы хотели бы остановиться, но, раз нырнув в SOA, приходится барахтаться.
Что болело: всё это никак не лезло в docker, постоянно требовало рефакторинга и сложно поддерживалось.
Решили, что нужно всё переделать, и в качестве целевой системы выбрали Ansible (плюсы каждый подставит сам). Нас ограничивали бизнес, чувство самосохранения и обязательства перед командой: без даунтаймов и остановки разработки.
...
Прошло 3 года.
— Ну? когда уже откажемся от Puppet'а?
— Скоро, — грустно отвечаем мы, выгребая баги после теста нового стейджинга.
* Финал *
За 4 года мы выросли втрое по ИТ (и в 6 раз по выручке) и торжественно останавливаем Puppet-сервер!
* Эпилог *
Сидя с рюмочкой шампанского у себя в квартале, легко фантазировать: "Вот была бы у нас машина времени, что я бы сам себе сказал за 45 минут лет пять назад?":
- Куда смотреть?
- Что считать?
- Сколько людей было, а сколько нужно? И, главное, как это посчитать?
- Какой план составлять на эту работу? И какие сроки обозначить?
- Как, когда и по каким точкам контролировать?
- Как это можно "продать бизнесу"?
- Когда менять план и как это объяснить?
Облачная аналитическая платформа дома на коленке:
- конфигурация k8s-кластера;
- описание задач;
- план аварийного восстановления.
* Что это такое и как она поможет эволюционировать из "DevOps как сервис" в "DevOps как платформа"
* Какое ПО, попадающее под определение гиперконвергенции есть на рынке?
* IaC
* CI/CD по кнопке — миф или реальность?
Вам знакомы такие проблемы, как:
- долгое создание тестовых окружений и стендов для разработки;
- как поменять одну или несколько переменных на 5 стендах, на 10 или на 100;
- непонимание того, что происходит на стендах, какой они версии, какие на них инфраструктурные компоненты?
В своем докладе я хочу рассказать о нашем опыте внедрения GitOps на примере ArgoCD. Рассказать об инструментах, методах и организации репозиториев для GitOps-подхода.
Расскажу, как мы сократили издержки при создании новых стендов с нескольких дней до нескольких десятков минут. Как смогли вносить изменения в множество стендов одним push. Как упростили систему деплоя, повысили безопасность, в несколько раз сократили код CD-части, бонусом получили крутую визуализацию приложений.
Инфраструктурная платформа
Доклад основан на собственном опыте и некоторых интересных и полезных выводах, которые не всегда очевидны.
Часто случается, что крупные компании (кровавый энтерпрайз), в составе которых много продуктовых команд, живущих в собственных болотцах и дублирующих используемую инфраструктуру и сервисы для себя, не задумываются о том, что можно объединиться с соседями и уменьшить количество накладных расходов на многих этапах построения конвейеров непрерывной поставки и интеграции.
Поделимся опытом и некоторыми кейсами, связанными с решением задачи построения платформы.
MLOps — новое слово для многих инженеров (и даже для DevOps-ов). Пришло время расставить все точки над i, ведь компании разрабатывают все больше AI/ML продуктов и нуждаются в экспертизе DevOps в приложении к машинному обучению.
Соответственно, в рамках этого доклада я затрону следующие темы:
- Есть ли DevOps в MLOps, или это совершенно новая и уникальная сфера?
- MLOps 101: Все, что вы должны знать для старта
- Кто такой MLOps? — Дата-сатанист? МЛ-инженер? Или кто-то еще?
- Пайплайны, везде CI/CD-пайплайны, и MLOps не исключение
- Как MLOps интегрируется в другие процессы разработки ПО?
- Какие метрики есть в ML-процессе? Как их замеряют и используют?
- Что делать с моделью после обучения? Как заставить ее работать?
Вы узнаете, что в MLOps гораздо больше DevOps, чем кажется, но, в то же время, не весь MLOps — это DevOps. MLOps сложен, но не невозможен — осталось только разобраться в деталях.
Споты позволяют работать с неиспользуемыми мощностями EC2 для создания своих виртуальных машин. При их использовании есть вероятность прерывания с двухминутным предупреждением, но в обмен вы получаете существенную скидку в цене.
На воркшопе мы посмотрим, как можно использовать споты в AWS для ваших CI/CD-пайплайнов: подключим их к установленному GitLab в качестве раннеров, соберём несложное приложение в виде Docker-образа, а затем развернём получившийся контейнер на кластере Kubernetes, также построенном на спотах. В конце кратко обсудим переход к бессерверной (serverless) модели в качестве возможного следующего шага.
Каждому участнику будет выделен временный AWS-аккаунт для воркшопа (необходимо будет ввести свой e-mail для получения одноразового пароля), но вы также можете использовать свой личный аккаунт.
Меня зовут Виталий, и так получилось, что я упоролся по Ceph и SDS в целом. До такой степени, что в итоге реализовал собственную систему — Vitastor — быструю, простую, при этом имеющую аналогичную Ceph-архитектуру и, в принципе, потенциал для развития в его полную замену. В отличие от многих других «убийц цефа». :)
В докладе я хочу рассказать о том, зачем я это сделал, в каком состоянии разработка сейчас и что я планирую делать дальше.
Для начала и для тех, кто менее погружён в тему, я расскажу о том, что такое SDS (программные СХД) и зачем их вообще используют — а используют их многие «облачные» провайдеры — Amazon, Google, Yandex, mail.ru… Кратко остановлюсь на том, почему Ceph и внутренние SDS в облаках на самом деле не очень-то быстрые, а многие другие — вообще непригодны для production (консистентность — не пустой звук).
После этого перейду к рассказу о Vitastor. На данный момент система разрабатывается мной в 1 лицо примерно год в расслабленном темпе в свободное время (идеи до этого вынашивались ещё год-два) и насчитывает примерно 25000 строк кода — пожалуй, можно сказать «всего лишь 25000 строк кода» — и при этом поддерживает базовый функционал распределённой программной СХД без единой точки отказа. Я расскажу о выбранной архитектуре, о том, чем она схожа с Ceph и чем она от него отличается, почему я считаю такой путь правильным и какие у него могут быть недостатки и преимущества.
Покажу тесты производительности и сравнение с Ceph, расскажу о планах и потенциале дальнейшего развития. Конечно, система только недавно «родилась», многих функций в ней на данный момент ещё нет. Но в планах и реализация снапшотов, и контрольных сумм, и оптимизаций для SSD+HDD, и удобного Web-интерфейса, и даже, возможно, ФС. При должном запале всё это сделать вполне реально.
В общем, я выполнил совет — хватит ругать Ceph в чатах — возьми и сделай сам лучше! Взял, сделал. Осталось довести до production.
Очень много докладов и статей посвящено тому, как запускать и обслуживать приложения в облаках. В своем докладе я расскажу о том, как развёртывать и обслуживать саму облачную инфраструктуру, что нужно сделать, чтобы превратить голое железо в распределённый кластер, позволяющий запускать пользовательскую нагрузку.
Мы поговорим о внутренней архитектуре инфраструктурных сервисов, о том, как можно запускать виртуальные машины, обеспечивающие работу облака, в самом облаке. Какие это создаёт вызовы, и как мы их решаем. Основная часть рассказа будет посвящена инструментам обновления и обслуживания облачной инфраструктуры, их текущему состоянию и как мы их развиваем параллельно с ростом размера и количества инсталляций наших облаков.
Архитектура по-настоящему устойчивых к сбоям облаков предусматривает несколько вложенных доменов отказа – географический регион, зона доступности и другие.
В этом докладе мы расскажем о том, как мы перевели наше облако на базе OpenStack с базовой архитектуры “один кластер хранилища на все зоны доступности” в отказоустойчивый вариант, не потеряв в удобстве работы с виртуальными машинами, дисками и образами.
Доклад очерчивает следующие проблемы и предлагает решение:
1. Проблемы с k8s: если на рынке есть одна альтернатива, то альтернативы нет. Или есть?
2. Проблемы с docker: более половины образов содержат уязвимости. Что делать?
3. Как быстро организовать альтернативу облаку k8s с аптаймом в год и поддержкой силами SRE-джуниоров?
4. Как при этом выводить приложения в пром одной командой из консоли?
Kubernetes — мейнстрим, стандарт де-факто. Все его или уже используют, или собираются. Ничего другого (сопоставимого по масштабу) просто не будет.
Но как быть с «темной стороной» Kubernetes? Сколько он стоит? И что он реально дает?
Ведь выясняется, что для поддержки Kubernetes-инфраструктуры нужно нанимать одного или даже нескольких инженеров на full-time — и это только для того, чтобы «стоять на месте». Выясняется, что есть множество вариантов ошибиться и нарваться на серьезные проблемы. Выясняется, что этот комбайн — супердорогой, да и вообще не радует…
В докладе расскажу:
* что нужно сделать, чтобы получить готовый Kubernetes;
* сколько это будет стоить на начальном этапе и сколько на постоянной основе;
* что нужно (и что не нужно) делать, чтобы избежать большинства проблем;
* почему нам всем все-таки не обойтись без Kubernetes;
* наконец, что ждет Kubernetes в будущем и как к этому правильно подготовиться.
Мы активно используем Jaeger как инструмент распределенной трассировки, и при росте нагрузки встал вопрос эффективности хранения и обработки данных.
В докладе мы расскажем, как выбирали базу для хранения трейсов Jaeger и про дальнейший опыт эксплуатации Jaeger и Yandex Database в Auto.ru и Yandex.Cloud. Решение стало популярным внутри Яндекса, и мы выпустили Jaeger-драйвер для Yandex Database в Open Source. Появление Yandex Database Serverless дало пользователям возможность сэкономит, и мы хотим поделиться результатами тестов Jaeger с Yandex Database Serverless.
1. Так что там с сетью в Kubernetes?
Как, вообще, можно строить сети для контейнеров и что такое veth? Почему нам нужен иногда двойной NAT, чтобы делать вид, что у нас нет NAT? Зачем нам нужно столько правил iptables и почему это порой так не просто? Зачем нужно хранить это все в etcd? Почему в Kubernetes какие-то плагины реализуют сеть?
2. Почему так сложно, можно просто Flannel?
Мы же можем создать один бридж и просто покидать туда все veth? Может быть у нас может быть больше 255 подов на одном хосте? У нас же может быть простая таблица маршрутизации, да?
3. Мы поняли — бриджи плохо, давайте Calico?
Секундочку, это что, /32 маршрут на каждый под? Но ведь можно как-то элегантнее? А они говорят, что там поддерживаются какие-то правила фаервола? А они что, не везде?
4. Ответ на вопрос жизни, вселенной и всего такого про сеть.
Какой плагин сети в итоге (не) брать. О чем думать в процессе планирования сети. Почему адресация важна.
Архитектура в DevOps, DevOps для CTO
Доклад посвящен практическому взгляду на то, что же такое DevOps в организации и на что следует обратить внимание в первую очередь.
- В двух словах — в чём роль внедрения DevOps-практик в организации?
- Сколько инженеров нужно, чтобы описать инфраструктуру предприятия?
- Какая квалификация инженеров действительно важна?
- Какие вопросы необходимо задать самому себе, чтобы понять, что всё действительно в порядке?
- Архитектура идеального предприятия со стороны инфраструктуры — какая она?
- Метрики везде, что смотрим в первую очередь?
- Пару слов о безопасности, всё ли решает DevSecOps?
- Выше только SRE?
Kubernetes Operator Pattern был создан для автоматизации роли человека-оператора, который управляет приложениями, имея глубокие знания о том, как их правильно готовить. Это как раз то, что необходимо для управления базами данных! А в этой презентации я расскажу о том, как Kubernetes Operator для управления базой данных может быть устроен внутри, и чему мы научились, создавая операторы для MySQL и MongoDB.
DevOps-трансформация
Фраза "это к DevOps'ам" порой ставит в ступор как разработчиков, так и админов.
На докладе рассмотрим воркфлоу работы на примере крупной аварии в ритейле и разберемся, к какому DevOps-инженеру идти, когда сервер упал, а к какому — когда пайплайн красный.
Как известно, долг платежом красен! Но технический долг — это особый вид долга. Занимаем мы у самих себя, себя будущих, да и никто в действительности не знает, как рассчитать реальный размер этого долга. Поэтому зачастую получается, что по таким счетам стараются не платить или максимально оттягивают момент расплаты. А как только речь заходит о том, что у нас есть долги и неплохо бы начать их отдавать… никто не удивится решению в стиле: «С понедельника мы обязательно начнем разгребать наш техдолг! Но пока давайте сосредоточимся на бизнес-задачах».
В современном мире непрерывного деплоя и прочих удобств ситуация стала только хуже: скорость разработки увеличилась до космической, а вместе с ней и размер технического долга растет пропорционально. Более того, при постоянном игнорировании вопроса накапливаются еще и «проценты» по обслуживанию технического долга.
В докладе я расскажу о причинах, по которым мы так неохотно выделяем время на техдолг, и — главное — о том, как избежать «банкротства». Поделюсь инструментами и подходами, с помощью которых можно «продать» технический долг команде и/или бизнесу. Доклад построен с точки зрения инженера эксплуатации и снабжен большим количеством примеров из реальной жизни.
В этом докладе я расскажу, как мы подходили к созданию сообщества практики по автоматизации DevOps CI/CD в Сбере. Предпосылки, ключевые проблемы и мировые best practice, которые мы использовали.
Моё выступление попробует найти ответы на вопросы:
* зачем в металлургии нужен DevOps?
* что делает Agile в шахте ?
* как ML увеличивает уровень майнинга ?
Краткая история про то, как мы оцифровываем процессы, которые уже устоялись 50 лет назад...
Как меняется ИТ от организации к организации, чем отличается ИТ в производственной компании, сервисной компании и условном Убере?
Интуитивно понятно, что отличается, но чем? Давайте разберемся вместе и поймем, при чем тут DevOps, практики и совершенно другая культура.
Автор в докладе разберет:
- В каких компаниях DevOps-практики приживаются лучше всего.
- В чем основная ценность DevOps для бизнеса.
- Как ценности DevOps задают культуру DevOps и организацию инженерии в компании.
Больше 10 лет прошло с момента первой легендарной конференции DevOps Days в Генте. За это время в мире появилось с несколько дюжин различных коллабораций с Ops-спецами, начиная с классических DevSecOps'ов, заканчивая диковинными HugOps'ами.
Рассмотрим боли и причины появления таких движений, возьмём их лучшие практики и проанализируем направления, куда можно развиваться DevOps-специалисту.
Путь Ак Барс Цифровые Технологии (Ак Барс Банк) от создания продуктовых команд с общим владением системами к появлению платформенных команд с ответственностью по системам.
Нужны ли платформенные команды, что это такое у нас, какие роли и зоны ответственности у такой команды, преимущества и недостатки модели «Продуктовые и платформенные команды», где место SRE в такой модели, баланс между гибкостью решений и целостностью систем — все это проходим на собственном опыте, чем и поделюсь в своем докладе.
На воркшопе по командным топологиям мы попробуем применить подход Team Topologies на практике.
Team topologies (https://teamtopologies.com) - это пошаговая и адаптивная модель организационного дизайна, основанная на четырех фундаментальных типах команд и трех способах взаимодействия. Team Topologies уже 2 года, все больше компаний начинают применять и делятся своим опытом. В воркшопе я собрал подробный материал по Team Topologies - шаблоны, инфографику, приведу кейсы использования в разных компаниях. На основе этого материала попробуем построить текущую (as-is) и будущую (to-be) топологию для ваших команд или компании. Интересно, хватит ли 4 типов команд и 3 способов взаимодействия, чтобы описать топологию вашей компании?
Воркшоп будет проходить на доске в Miro, работа индивидуальная.
Слово DevOps появилось в 2009 г. и оно означало вполне конкретную вещь: набор практик, чтобы совместить разработку и эксплуатацию. Это звучит очень красиво, но работает ли оно в современных условиях?
В докладе мы попробуем разобрать идеи DevOps применительно к современной действительности — актуальны ли они и в каком виде.
Трейсинг распределенных запросов — один из столпов observability микросервисной архитектуры. Мы рассмотрим, как технически реализуется трейсинг, какие преимущества дает трейсинг для диагностики проблем производительности, необходимые усилия для внедрения трейсинга своими силами, стандарты в этой области и как им следуют производители APM-решений и opensource-инструменты.
Если:
- у вас в компании есть DevOps-отдел;
- вы задумываетесь о том, чтобы объединить всех девопсов в один отдел;
- кто-то в компании раскатал кластер кубера, и теперь мы их зовем DevOps-отдел;
то у меня для вас плохие новости...
Мы ненавидим отвлекаться от нашей текущей работы. Ненавидим копаться в тикетнице и искать переписки с клиентами. Нас беспокоят пропущенные алерты и недоступные логи. Мы в облаке прошли большой путь облегчения работы всей команды от delivery manager до дежурного, отвечающего за конкретный сервис.
Сильнейшее влияние на нашу практическую деятельность оказали чат-боты. И большая часть наших систем имеет интеграцию с ними. Эти решения написаны с помощью Serverless-подхода. В докладе я расскажу о том, что команде разработчиков стоит взять на вооружение и как это приближает вашу DevOps-трансформацию. Сразу после доклада вы сможете взять готовые примеры и попробовать адаптировать их к своим процессам разработки и поддержки ваших сервисов.
Тезисный план доклада:
- Для чего профессиональные сообщества необходимы крупным организациям?
- Какова цель DevOps Community в Райффайзенбанке?
- Какие проблемы решает DevOps Community?
- Какие инструменты используются в решении проблем?
- Как сообщество влияет на развитие DevOps-практики в банке?
- Какие планы DevOps Community преследует в этом году?