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

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

В ходе демонстрации я затрону работу со следующими сервисами:
- AWS Amplify CLI: quickly provision backend resources on AWS.
- [AWS Amplify JavaScript library] (https://aws-amplify.github.io/): front-end React application invokes backend resources.
- Amazon Cognito: authenticate users.
- Amazon DynamoDB: store the posts, follow relationships and timelines.
- AWS AppSync: host a managed GraphQL API.
- AWS Lambda: implement complicated business logics on server-side.
- Amazon Elasticsearch Service: implement full-text search.

В докладе рассматривается использование подхода, предполагающего автоматическое выявление значимых сигналов путем анализа отклонения значений метрик от текущей нормы и обнаружение аномалий в KPI производительности микросервисов и инфраструктуры Kubernetes. Выявление взаимосвязей микросервисов и объектов инфраструктуры, путем анализа трейсов запросов, позволяет группировать найденные аномалии для оперативной изоляции исходной проблемы. Для обнаружения значимых аномалий необходимо использовать анализ не только метрик, но и логов и трейсов – всех столпов observability.

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

Будут рассмотрены вопросы выбора и группировки значимых метрик и лейблов, представлен обзор open source инструментов для выявления аномалий в метриках Prometheus, а также рассмотрены подходы основных enterprise и open source вендоров платформ observability к выявлению baseline и аномалий в производительности приложений в микросервисной архитектуре.



Воркшоп: Observability для микросервисных приложений в Kubernetes.

Это практическая сессия для DevOps, на которой вы сможете за 1 час посмотреть вживую систему observability для микросервисных приложений, работающих в Kubernetes.

Что мы будем делать вместе:
1. Развернем в кластере демонстрационное гетерогенное микросервисное приложение (стэк - NodeJS, Java, Python, Golang, PHP, MongoDB, Redis, MySQL, RabbitMQ, Nginx, AngularJS): https://github.com/instana/robot-shop

2. Установим в кластер под с системой observability, получим контроль всего кластера и всех микросервисов, трейсинг всех запросов и видимость на уровне кода.

3. Сгенерируем нагрузку, инициируем инцидент.

4. Расследуем инцидент используя метрики Golden Signals, принципы observability и выявления аномалий в метриках.


Требования:
1. Запущенный Kubernetes кластер, настроенный kubectl и helm.
2. Регистрация в Instana для получения полнофункциональной SaaS системы observability на 14 дней: https://www.instana.com/trial/ (можно сделать в ходе воркшопа

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

Плюсы:
- экономия времени и денег;
- возможность быстро догнать бизнес конкурентов.

Минусы:
- выгорание сотрудников от изменений и нагрузки в период трансформаций;
- совсем не все готовы работать по-новому;
- вырастает нагрузка на HR.

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

Уроки, которые мы вынесли:
- не все люди готовы к подобному количеству единовременных изменений в организации и их уход из компании иногда лучше, чем их негативное влияние на коллектив;
- на фит-интервью новых сотрудников нужно проверять на вовлеченность и I/T-shape, а не только их хард- и софт-скилы;
- уделять особое внимание донесению сотрудникам всех долгосрочных плюсов от трансформаций как для компании, так и для них самих.

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

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

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

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

Расскажу, как мы в "Додо Пицца" пришли к необходимости тестировать alerting и recording rules в Prometheus.

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

Зачем стандартизировать процесс, если и так всё работает — долго, дорого, не гибко, но ведь работает же? А вы нам тут говорите о какой-то единой экосистеме CI/CD на базе atlassian, средств bug tracking и мониторинга appdynamics, splunk.

В докладе я расскажу о двух свободных проектах: Kubernetes-in-Kubernetes и Kubefarm, которые мы используем для быстрого развёртывания Kubernetes-кластеров на собственном оборудовании.

В программе дня:
• Простейший способ развернуть и поддерживать в актуальном состоянии сотни серверов on-premise.
• Легко спавнить и удалять физические ноды как виртуалки.
• Разделять кластера и властвовать.
• Cluster API? Не, не слышали...
• Деплоить Kubernetes Helm'ом, WAT?

Приходите, будет весело! ;-)

- Что понимать под "навыками сисадмина";
- можно ли забыть про хождение "по ssh руками";
- как при этом понимать, что происходит;
- нужно ли уметь собирать ядро в 2020.

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

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

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

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

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

Уже много было сказано про "распил монолитов". Много было дискуссий про то, переписывать или нет. Активно идут обсуждения о том, как и от чего отталкиваясь, нужно бороться с возрастающей сложностью микросервисов.

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

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

Но взять и посадить этот самолёт, у которого SLO 24/7, в ангар для исправления накопленного техдолга шансов нет никаких.

Как быть? Строить самолёт на лету! И да, это возможно. Управление техдолгом — это не сказка о розовых пони, это болезненный для техдиректора процесс, который вытягивает из него все соки, заставляет непрерывно находить компромисс, верить настраивать и вдохновлять, когда, кажется, никто не верит.

И это норм, это просто такая работа.

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

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

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

Фокусируясь на краткосрочных результатах, мы развиваем вредные привычки мозга, за которые потом дорого платим:
* например, мы полагаемся на силу воли и дисциплину, игнорируем удовольствие и приучаем мозг работать, только если его принуждают – движемся к выгоранию;
* или наоборот – приучаем его получать удовольствие от отвлечений и откладывания…

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

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

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

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

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

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

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

Крокодил спросонья бьется об корягу и занимается рефлексией, пока не вспоминает заветное словно "магнолия".

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

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

Но зачем это все? Кому это нужно? Какая в этом польза? В своем докладе я постараюсь ответить на эти вопросы.

Агенда
1. О себе.
2. ЧТО: Путь самурая и в какой момент появляется цель. (Мотивация к действиям, и как получить свой пинок).
3. ПОЧЕМУ: Зачем это нужно, и как вы своим развитием поможете коллегам, компании, сообществу и в первую очередь себе.
4. КАК: простые советы, подсказки, подходы. Бережем здоровье, не выгораем, идем спокойно. Никуда не спешим!
5. Закрытие, финальные слова, парочка напутствий, вопросы/ответы.

Что мы пытаемся починить переходом в облако, а оно не поможет.

10 years ago we had the idea to organise a conference in Gent to bridge the gap between developers and the people runing their code. It was the start of a new global movement. We never predicted that #devops would be where #devops is today. The word devops has evolved, the community has evolved.

Docker has solved all of our problems, the ones left behind were solved by Kubernetes. Everybody and their neighbour is Scrum certified now and we are all happily sipping cocktails on the beach. Or not? Why after almost 10 years of pushing culture change, teaching about Infrastructure as Code, teaching about Monitoring and Metrics … and help people to share both their pain and their learnings are most organisations still struggling with software delivery.

Over the years the word devops lost it’s meaning at least it’s original meaning. The real challenge for the next decade will be to see how we can revive those original values and ideas, if at all… Can we fix Devops? This talk will give you some Ideas about that.

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

Мы организовываем обсуждение этой темы: даём площадку, анонсируем среди участников конференции, модерируем, приглашаем экспертов.

Обсуждения открытые, каждый может высказаться.

.

Доверие является главным слагаемым эффективной команды. Больше 60% всех проблем в команде связаны с отсутствием доверия. Мы знаем, как решить эту проблему!

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

- Базовый набор тестирования на проникновение: обзор популярного инструментария для поиска недостатков в сетевых сервисах и веб-приложениях.
- Фаервол нам не помеха или техники пивотинга.
- Распространенные ошибки разработчиков и системных администраторов, которые помогают атакующим достигать цели.
- Как теперь с этим жить? Оцениваем риски и противодействуем атакам.

Способов развёртывания кластера kubernetes насчитывается не один десяток — как на bare-metal, так и на различных облачных платформах. Начинающие администраторы k8s обычно используют одну из известных утилит для сборки кластера и лишь намного позже узнают о подводных камнях того или иного решения. Каждый инсталлятор k8s содержит набор предубеждений его создателя, которые могут помешать настроить и собрать кластер так, как нужно конкретной компании. Когда приходит осознание, что дефолты инсталлятора не подходят для нужд компании, на кластере давным-давно production-нагрузки и пересобирать его уже нельзя.

Я расскажу, как неинвазивно переехать на наиболее конфигурируемый kubernetes the hard way и приведу примеры сценариев факапов и как их избежать.

Первый день:
1. Берем простой Hello world на Flask и докеризируем его.
2. Смотрим, как можно быстро локально поднять виртуалочку (vagrant), куда это будем деплоить автоматически (Ansible) в виде Docker-контейнера.
3. Рисуем простенький Helm-чарт для нашего приложения.
4. Учимся использовать авторский набор костыликов (https://github.com/maniaque/k1s) для развертывания локально кластера для быстрых тестов

Второй день:
Пункт 4 выполняем в Managed Kubernetes у Яндекс.Облака или на Bare-metal виртуалках в любом облаке.

С ростом компании инфраструктура становится сложнее, постепенно стремясь к IaaS. В докладе мы рассмотрим IaaS как внутренний продукт компании.

Ответим на вопросы:
- Почему нужно смотреть на инфраструктуру как на продукт?
- Что это требует и какой приносит профит?
- Какие практики нужно использовать из продуктовой разработки?
- Какие вызовы встают перед командой?
- Как изменятся команда и процессы внутри нее?

Мы, компания Экспресс 42, совместно с конференциями Олега Бунина (Онтико), решили провести исследование о состоянии DevOps в России. Мы давно вынашивали эту идею, так как понимали, что отчеты других компаний (DORA, Puppet, DevOps Institute) не дают ответов на вопросы, как DevOps развивается у нас.

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

Исследование будет проводиться в течение августа, а в конце сентября мы оформим результаты исследования в общедоступный текстовый отчет и расскажем про основные выводы на конференции DevOps Live 2020.

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

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

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

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

В докладе я пройдусь по истории DevOps'а и по тому, почему DevOps как методология _создания_ программных продуктов стала трендом в головах бизнеса (часто заменяя или дополняя "Agile"). Попробую объяснить инженерам, в чем разница между потребностями бизнеса и тем, что видят важным они.

1. История развития доставки программного обеспечения от дискет и компакт-дисков до контейнеров.
2. Agile-методологии, почему они появились и как они связаны с доставкой?
3. Как DevOps появился из Agile и заменил Agile и почему он так привлекателен для бизнеса?
4. Какие инженерные решения максимально совпадут с интересами бизнеса, а про какие лучше говорить в отрыве от DevOps как методологии? Соответствие бизнесовых DevOps-метрик инженерным решениям.

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

Так всё же, может или нет существовать такое понятие? Как тогда должны называться люди, выступающие проводниками философии DevOps на практике? И если DevOps-инженеры существуют, то какие они?

Все эти горячие вопросы обсудим на полях данной дискуссии!

TBD

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

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

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

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

Я работаю в компании аналитического приборостроения "Люмэкс". Мы разрабатываем, производим, продаем и обслуживаем приборы для химического анализа. Наши продукты объединяют три составляющие: железо, софт и методику работы. В докладе я расскажу, что мы делаем для того, чтобы развивать продукт, состоящий из этих разных слагаемых.

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

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

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

DevOps is often perceived to be a technology centric topic. The struggle of aligning IT and Business on a shared understanding of DevOps is real. Without this alignment many DevOps transformation initiative fail to deliver desired outcomes. A DevOps strategy brings the biz-tech alignment to life. It helps to encapsulate gory technical details into business friendly language. In this session, we will explore a structured approach to create your own DevOps strategy using the DevOps Strategy Canvas. The canvas is an innovative tool for creating a shared vision and unlocking the promise of DevOps across the enterprise.

So often, organizations working to adopt DevOps initially focus on selecting tools and manipulating their choices to automate bad practices hoping to maximize efficiency. Automation is the easy part. But without culture transformation and process optimization, an organization will never realize their true potential. Optimizing the system as a whole – a system made up of people, processes and tools - means reviewing, questioning and potentially changing how things are across the entire lifecycle. During this meetup, let’s collaborate on techniques to change culture, the value of mapping the value stream, and the automation tools available to help.

Java-архитектор и DevOps-архитектор встретятся в битве за микросервисы.

* Избыточны ли ресурсы на каждый микросервис?
* Есть ли необходимость в постоянном рефакторинге и как грамотно организовать рабочее место?
* Обсудим все вопросы, которые вы давно стеснялись обсудить!