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

Мы рассмотрим те подходы, которые сработали и нет, например, такие как:
* infrastructure as a bash history;
* SOLID для Ansible;
* пирамида тестирования инфраструктуры;
* парное администрирование.

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

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

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

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

Доклад содержит реальные примеры использования различных инструментов и технические детали CI/CD-процесса.

За три последних года в Контуре произошло примерно 1000 факапов разной степени эпичности. Среди них, например, 36% были вызваны выкатыванием некачественного релиза в продакшн, а 14% — работами по обслуживанию железа в дата-центре.

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

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

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

За последние три года мы, компания «Флант», проделали огромный путь в борьбе за удобный и качественный деплой в Kubernetes. Это стало возможным благодаря постоянно растущему опыту обслуживания большого числа и разнообразия приложений, мигрированных и/или уже работающих в K8s.

В докладе мы подробно расскажем о тех проблемах и вызовах, с которыми сталкивается каждый при деплое в Kubernetes, а также о нюансах, которые могут быть заметны не сразу. Разбирая их, мы не только покажем возможные пути решения, но и продемонстрируем, как это реализовано в werf – нашем Open Source-инструменте для DevOps-инженеров, обслуживающих CI/CD в Kubernetes.

Пускай разработчики думают только о бизнесс-фичах, а разработкой процессов займётся DevOps-инженер. Я расскажу про внутренний продукт, который я разработал, чтобы дать возможность разработчику довести свой код до продакшна без чьей-либо помощи. Немного магии на golang, groovy и ansible при участии Jenkins.

В декабре 2018 года в Айри.рф для SSD-дисков с кэшем под нагрузкой выявили большие задержки на отдачу файлов. В ходе профилирования задержек и точечных мер для их оптимизации удалось сократить число задержек на 2 порядка (с 1/1000 запросов до 1/100000 запросов).

Что мы сделали
* Внедрили метрики для отслеживания задержек по дискам. Несколько уровней метрик, включая ioping, prometheus, i/o wait, connect time.
* Выдвинули гипотезы, как улучшить производительность дисков. Снижение задержек тесно связано с утилизацией дисков.
* Пересобрали дисковые массивы, настроили файловую систему, поработали с логами, вынесли хранение в оперативную память, включили trim, изменили логику работы приложения и записи в кэш.

DevOps culture is one of the most important aspects in Amazon – it helps to quickly build, develop, test and maintain services and products which are then delivered to millions users around the world. It’s about removing barriers and improving the whole processes of delivering products. In this talk we will see how and why Amazon moved from building monolithic applications to building microservices with help of DevOps, we will see what kind of tools and procedures are being used to maintain the speed of building new services and how to keep being agile when you need to do deployment every second throughout the whole year.

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

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

Вы узнаете об эволюции и новых возможностях сервиса. Мы в деталях разберем все пять основных его компонентов и сделаем упор на Azure Pipelines - гибкую систему CI/CD c неограниченными возможностями собирать что угодно и деплоить куда угодно.

Многие компании начали разрабатывать свои программные продукты 3-5 и больше лет назад и сегодня оказываются в непростой ситуации. Выбранные ими когда-то подходы к архитектуре и процессам разработки теряют свою актуальность и уже не позволяют поддерживать прежний темп развития и скорость выпуска новых версий, необходимую бизнесу. Список технических долгов можно долго скролить (если его, вообще, есть где посмотреть!), а инфраструктура за годы эксплуатации превратилась в зоопарк, некоторые уголки которого настолько заброшены, что неизвестны никому из работающих ныне над проектом инженеров. Перед каждым очередным релизом нужно зажмуриваться, и с вероятностью близкой к 100% возникают ошибки, причём часто отваливается совершенно не в том месте, где что-то меняли.

Но развиваться надо. И перед руководителями таких проектов встаёт вопрос: как провести трансформацию, перенести проект на современные рельсы, навести порядок в инфраструктуре, сделать человеческое разделение на среды, построить новые удобные технологические процессы разработки и настроить деплой «по кнопке»?

В данном докладе я обобщу наш опыт в работе над такими проектами и приведу несколько наиболее полезных советов:
* Как выбрать подходящую для проекта архитектуру?
* Как избавиться от зоопарка?
* Какие инструменты использовать и как это делать?
* Какие подводные камни могут встретиться по пути и как их обойти?
* Что делать дальше?

Мы долго жили с самописным подсчётом метрик на местах. «Гибкость» этого подхода приводила нас в уныние. А потом мы попробовали ClickHouse и подсели. Так у нас появились те самые графики о работе:
* нашего CDN — от стандартных rps и трафика до выявления аномалий;
* транспорта статистики — вплоть до поиска потерь и дубликатов.

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

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

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

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

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

Helm - самый популярный пакетный менеджер для Kubernetes. Из-за новизны и отсутствия устоявшейся практики эксплуатация кластера с установленным Helm-сервисом может стать одной большой черной дырой или "root ssh" к вашей инфраструктуре.

В докладе будет подробно рассмотрена архитектура Helm и даны практические рекомендации, как сделать систему максимально безопасной. Остановимся подробно на взаимодействии с репозиторием чартов, серверной части - Tiller, настройке RBAC и service accout, а также переходу на использование K8s secrets для хранения релизной информации. Рассмотрим целесообразность tillerless-дизайна и его практическую применимость, а также поддержку нескольких профилей безопасности. Сделаем Helm полностью безопасным вместе!

Смена технических решений — это всегда больно. Ещё больнее, когда это решение является краеугольным камнем вашей архитектуры, на который завязано если и не всё, то многое. В какой-то момент мы столкнулись с тем, что испытываем неудобства, нам не хватает фич при использовании связки Mesos-Marathon-Chronos и у нас возникло желание перейти на другое решение, которым был выбран Kubernetes.

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

В компании Adalisk (подрядчик крупнейшей в США компании по зубному протезированию Glidewell Dental) мы занимаемся автоматизацией производства зубных протезов – коронок, мостов, имплантов и т.д. Вся автоматизация производства находится в облаке и представляет собой микросервисную архитектуру.

С самого начала у нас были сложности с развёртыванием новых сервисов в продакшне. Предварительное тестирование в QA-окружении не позволяет выявить все ошибки, т.к. реальные станки есть только в PROD. Поэтому приходилось деплоить редко, большими порциями, по воскресеньям, останавливая всё производство и прогоняя тестовые заказы. Это затягивалось на целый день (а это выходной) и иногда заканчивалось откатом деплоймента (что занимало ещё несколько часов).

Мы решили проблемы деплойментов с помощью самописного прокси-сервера, который позволяет делать честное АБ-тестирование в продакшне. В докладе – все подробности об этом и о том, почему другие решения нам не подошли.

I will give a short overview of RRDtools functionality and then go into some of the newer features. In the second part of the talk, I will present some other open source tools from my GitHub repo and tell the stories that lead to their creation.

Расскажу о нашем пути в построении и внедрении Service mesh-решения. Посмотрим, какие проблемы такие решения позволяют устранить. Пройдемся по пути от внедрения Istio до написания собственного решения netramesh.

Современная разработка сильно изменилась за последние годы. Вместо монолитных приложений пришли микросервисы и функции. За ними базы данных из универсальных промышленных монстров стали более узконаправленными. Docker изменил взгляд на деплой. А изменилось ли наше представление о логах?

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

Задавали вы себе вопрос, сколько стоит ваша инфраструктура (сервера, зарплаты, внешние сервисы и тому подобное)?

* Можно ли рассматривать инфраструктуру как продукт?
* Можно и нужно ли считать ROI для инфраструктуры?
* Какие ключевые метрики выбрать для подсчета?
* Как работать над улучшением выбранных метрик?

Как мы строим инфраструктуру в Skyeng, и как это влияет на работу бизнеса. Реальный кейс из практики нашей команды.