В преддверии DevOpsConf Виталий Хабаров взял интервью у Дмитрия Столярова (distol), технического директора и соучредителя компании «Флант». Виталий расспросил Дмитрия про то, чем занимается «Флант», про Kubernetes, развитие экосистемы, поддержку. Обсудили, зачем нужен Kubernetes и нужен ли вообще. А еще про микросервисы, Amazon AWS, подход «Мне повезет» в DevOps, будущее самого Kubernetes, почему, когда и как он захватит мир, перспективы DevOps и к чему готовиться инженерам в светлом и близком будущем с упрощением и нейросетями.

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



Здесь и далее вопросы задает Виталий Хабаров инженер из Express42.

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

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


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

Определение DevOps очень сложное, поэтому приходится каждый раз запускать дискуссию об этом заново. Только на Хабре тысяча публикаций на эту тему. Но если вы это читаете, то наверняка знаете, что такое DevOps. Потому что я — нет. Привет, меня зовут Александр Титов (@osminog), и мы просто поговорим о DevOps, и я поделюсь своим опытом.



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

Мы развивали DevOps как могли. Нас было 8 человек, и Вася был самым крутым по Windows. Внезапно Вася ушел, а у меня появилась задача вывести новый проект, который поставляет Windows-разработка. Когда я высыпал на стол весь стек Windows-разработки, то понял, что ситуация — боль…

Так начинается история Александра Синчинова на DevOpsConf. Когда из компании ушел ведущий специалист по Windows, Александр задался вопросом, что теперь делать. Переходить на Linux, конечно же! Александр расскажет, как ему удалось создать прецедент и перевести часть Windows разработки на Linux на примере реализованного проекта на 100 000 конечных пользователей.



Как легко и непринужденно доставлять проект в RPM, используя TFS, Puppet, Linux .NET core? Как поддерживать версионирование БД проекта, если разработка впервые слышит слова Postgres и Flyway, а дедлайн послезавтра? Как интегрировать с Docker? Как мотивировать .NET-разработчиков отказаться от Windows и смузи в пользу Puppet и Linux? Как решать идеологические конфликты, если обслуживать Windows в продакшн нет ни сил, ни желания, ни ресурсов? Об этом, а также о Web Deploy, тестировании, CI, о практиках использования TFS в существующих проектах, и, конечно, о сломанных костылях и работающих решениях, в расшифровке доклада Александра.

У нас было 2 анализатора кода, 4 инструмента для динамического тестирования, свои поделки и 250 скриптов. Не то, чтобы это всё было нужно в текущем процессе, но раз начал внедрять DevSecOps, то надо иди до конца.



Источник. Авторы персонажей: Джастин Ройланд и Дэн Хармон.

Что такое SecDevOps? А DevSecOps? В чем отличия? Application Security — о чём это? Почему классический подход больше не работает? На все эти вопросы знает ответ Юрий Шабалин из Swordfish Security. Юрий подробно на всё ответит и разберет проблемы перехода от классической модели Application Security к процессу DevSecOps: как правильно подойти к встраиванию процесса безопасной разработки в процесс DevOps и ничего не сломать при этом, как пройти основные этапы тестирования на безопасность, какие инструменты можно применять, чем они отличаются и как их правильно настроить, чтобы избежать подводных камней.

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

Что ж, не будем останавливаться на достигнутом — продолжим продвижение подхода интеграции процессов разработки, тестирования и эксплуатации уже в мае на РИТ++.


Поскольку DevOps в нашем понимании — это про объединение всех процессов разработки, то фестиваль конференций РИТ++, в котором участвуют и серверные и клиентские разработчики, и управленцы разных уровней, люди, выстраивающие бизнес-процессы, и многие другие специалисты IT, — самое место, чтобы говорить о DevOps.

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

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

Как раз об этом расшифровка доклада Александра Харкевича на DevOps Conf Russia. В докладе: разработка Ansible-ролей через CI, механизм разработки публичных ролей и публичных ролей с тестовыми прогонами в приватной инфраструктуре. А еще в докладе нет вывода.

Все мы пользуемся каким-либо видом пакетных менеджеров, включая уборщицу тетю Галю, у которой в кармане прямо сейчас обновляется айфон. Но общего соглашения о функциях пакетных менеджеров нет, и стандартные для ОС rpm и dpkg, и системы сборки называют пакетными менеджерами. Предлагаем поразмышлять на тему их функций — что это такое и для чего они нужны в современном мире. А потом будем копать в сторону Kubernetes и внимательно рассмотрим Helm с точки зрения этих функций.


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

Помог нам в этом Иван Глушков (gli) своим докладом на РИТ++, видео и текстовая версия этого подробного и обстоятельного выступления ниже.

Видеозаписи этого и других выступлений по DevOps на РИТ++ опубликованы и открыты для свободного просмотра на нашем youtube-канале — заходите в поисках ответов на свои рабочие вопросы.

Ceph — это object storage, призванный помочь построить отказоустойчивый кластер. И все-таки отказы случаются. Все, кто работает с Ceph, знают легенду о CloudMouse или Росреестре. К сожалению, делиться отрицательным опытом у нас не принято, причины провалов чаще всего замалчивают, и не дают будущим поколениям научиться на чужих ошибках.

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


Далее вы найдете видео и текстовую версию одного из лучших докладов DevOpsConf Russia 2018.

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

• Каково главное преимущество DevOps подхода, на твой взгляд?
• Что больше всего может помешать компании в DevOps трансформации?
  
• Как интегрировать специалистов по безопасности в процесс поставки ПО?
  
• Как относишься к поднимающемуся хайпу вокруг SRE?
• Какие инструменты сегодня непременно есть там, где говорят о DevOps?
• Что отличает хорошего инженера от плохого с точки зрения DevOps?
  
• Как логичнее всего попасть в профессию?
  
• Как учиться и что читать? Где ты чаще всего сам читаешь новости отрасли?

Ответы получились очень любопытными и заодно позволяют составить некоторое впечатление о тех, кто вложил много усилий и немножко души в расписание нашей конференции. Например, ответ на первый вопрос шире, чем сокращение time-to-market. Мнения по поводу SRE разошлись, зато все практически единодушно советуют читать «The DevOps Handbook», но и еще надавали кучу рекомендаций — за ними под кат.

Чтобы разобраться, как связана Вселенная, рыба и DevOps, нужно изучить расписание DevOpsConf Russia. Тем более конференция уже через неделю, 1–2 октября, и так и так надо планировать, какие из выступлений удастся послушать. Постараюсь в этом помочь — все-таки я приложил не мало усилий, чтобы программа получилась такой насыщенной.

Открывать конференцию буду я сам темой «Что такое DevOps». Расскажу, как к нему идти, и что вообще он из себя представляет, надеюсь это даст повод для споров и разговоров на всю конференцию. Затрону и процессы, и инженерные и инфраструктурные вопросы, то есть все кирпичики, составляющие DevOps, которые легли в основу программы. А уже после этого примемся за инструменты: Kubernetes, Ansible, Docker, Prometheus, Ceph, Hashicorp Vault, Istio, KVM, CoreOS.



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

Накануне DevOps Conf Russia 2018 мы поговорили с техническим директором «Учи.ру» Алексеем Ваховым об этапах развития платформы, о том, какие инструменты они используют и насколько там все DevOps-ово.

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

С июля мы работаем над DevOpsConf Russia, профессиональной конференцией по интеграции процессов разработки, тестирования и эксплуатации, которая выросла из RootConf и пройдет 1 и 2 октября в Москве, в Инфопространстве.

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

Сегодняшняя тема — надежность World of Tanks Server — достаточно скользкая. Надежность игры — это trade off, потому в разработке игр все нужно делать быстро и быстро изменяться. Нагрузка на серверы большая, а пользователи склонны что-нибудь поломать просто из интереса. Левон Авакян на РИТ++ рассказал, что в Wargaming делают для обеспечения надежности.

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

О спикере: Левон Авакян работает в компании Wargaming в должности Head of WoT Game Services and Reliability и занимается проблемами надежности танкового сервера.

Перед тем, как ответить на вопрос «Как измерить успех?», надо понять, что значит «успех» именно для вас. Для Dev и Ops определение успеха отличается. Для Dev успешный проект полностью проходит тестирование. Для эксплуатации — мониторинг. Тестирование и мониторинг нужны, но тесты никогда не дают 100% покрытия проблемы, а ответа 200 от HTTP недостаточно, чтобы быть уверенным в том, что система хорошо работает. Leon Fayer на РИТ++ отстаивал точку зрения, что DevOps платят не за то, чтобы все метрики в мониторинге были в зеленой зоне. Платят за то, чтобы пользователи были довольны. Если недовольны — бизнес теряет деньги, и никого не волнует, что все зеленое.

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

О спикере: Leon Fayer родился в когда-то дружественной республике, но вырос в США. Начал заниматься программированием очень много лет назад, и за это время работал программистом, менеджером — кем только не работал. Участвовал в стартапах — некоторые были более удачные, а некоторые не очень.

Много лет Леон работает в OmniTI. Эта компания специализируется на разработке масштабируемых систем, поэтому Леон имеет уникальную возможность проектировать и строить системы для самых посещаемых сайтов в мире — Wikipedia, National Geographic, White House, MTV и т.д.

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

DevOpsConf Russia состоится 1 и 2 октября в Москве, соберет 500 специалистов и будет логически продолжать серию RootConf. Мы шли к этому перевоплощению несколько лет, и наконец готовы все рассказать.

В 2015 году в рамках фестиваля РИТ++ мы возродили конференцию RootConf, чтобы привлечь интерес к современным инструментам эксплуатации и подходам DevOps.