DevOps и системы управления конфигурацией. SECON 2015Ivan Evtukhovich
Что такое DevOps, зачем он нужен, что включается в это понятие. Что такое Continuous Delivery, системы управления конфигурацией, сравнение Chef и Ansible.
Прошло время, когда DevOps не был еще модным, началось время карго-культов и безбашенных внедрений. В докладе я расскажу про основные ошибки перехода компании к DevOps из моей практики, покажу как не надо использовать инструменты и как не надо организовывать команды, а также многое другое.
DevOps в Agile среде. Как, почему и когда инструменты помогают.Alexander Titov
Модное слово DevOps уже успело стать заезженным базвордом. Сотни компаний ищут DevOps инженеров, потому что искать системного администратора уже не модно. Я расскажу вам про свое понимание DevOps, как технические инструменты помогают делать Agile еще более гибким.
Мы разберем основные принципы DevOps через призму донесения смысла без потерь:
- Особая культура
- Автоматизация
- Изменения через измерения
- Распространение знаний и практик
Я поделюсь своим 5ти летним опытом в обеспечении повторяемости, мониторинге, логировании с примерами из реальной жизни.
Александр Титов - управляющий партнер в компании "Экспресс 42", мы внедряем DevOps практики и инструменты, помогаем эксплуатировать интернет-проекты.
В 2009, 2010 годах был техническим директором первого облачного хостинга в России Скалакси.
В 2010 - 2012 прошел увлекательный путь поглощений вместе с компанией Qik - путь из эксплуатации быстрорастущего стартапа к эксплуатации в крупной международной компании Microsoft.
SECON'2016 Евтухович Иван, Эксплуатация завтрашнего дня: от DevOps к NoOpsSECON
За последние годы у ИТ-сообщества накопился опыт использования систем управления конфигурацией и работой в организации по методологии DevOps. Но растущие вызовы показывают, что и этот подход имеет свои недостатки. Доклад расскажет о том, какие контейнеры бывают и почему они победят, что придет на смену облакам, и какие практики стоит начать внедрять сегодня, чтобы завтра не остаться без работы.
«DevOps — это о передаче смысла» — Александр Титов, Express 42DevDay
Текущим определением DevOps является аббревиатура CAMS:
— культура;
— автоматизация;
— измерения;
— распространение знаний.
Для меня это недостаточно понятно, я дополнил эти пункты тем, что DevOps это впервую очередь о передаче смысла без искажений. Я расскажу, как эти мысли соотносятся с методиками прошлого (ITIL, etc), как, используя такой подход, создать набор правил для работы и почему автоматизация — это не всегда хорошо.
Мы посмотрим как инструменты автоматизации помогают передавать смысл изменений между окружениями на примере реальных компонентов и кукбуков и рассмотрим на практике почему bash скрипты более слабый инструмент, чем Opscode Chef.
Совместно разберемся к требованиям к системе мониторинга. Что в системах мониторинга вредит передаче смысла, а что, наоборот, помогает. Какую систему мониторинга выбрать для вашего проекта?
Важность честности и открытости в команде для передачи смысла. Честные публичные пост-мортемы — это не проявление слабости, а проявление уважения к своим пользователям. Как научится делиться информацией друг с другом и не скрывать важного.
Доклад на конференции Youcon в октябре 2016 года. http://youcon.ru/
В последнее время только ленивый не пишет о микросервисной архитектуре. Но почему вдруг этот достаточно очевидный способ организации ИТ-проектов стал так популярен?
В докладе пойдет речь о том, что такое микросервисная архитектуры, об ее принципах и устройстве и преимуществах, которые она предоставляет, будет рассказано об основных компонентах, которые она включает в себя. Также будет дан краткий экскурс в контейнеры и Docker в разрезе их использования в микросервисной архитектуре.
Но любые преимущества не бывают бесплатными, также в докладе пойдет речь о том, какие недостатки несет в себе данный подход.
DevOps и системы управления конфигурацией. SECON 2015Ivan Evtukhovich
Что такое DevOps, зачем он нужен, что включается в это понятие. Что такое Continuous Delivery, системы управления конфигурацией, сравнение Chef и Ansible.
Прошло время, когда DevOps не был еще модным, началось время карго-культов и безбашенных внедрений. В докладе я расскажу про основные ошибки перехода компании к DevOps из моей практики, покажу как не надо использовать инструменты и как не надо организовывать команды, а также многое другое.
DevOps в Agile среде. Как, почему и когда инструменты помогают.Alexander Titov
Модное слово DevOps уже успело стать заезженным базвордом. Сотни компаний ищут DevOps инженеров, потому что искать системного администратора уже не модно. Я расскажу вам про свое понимание DevOps, как технические инструменты помогают делать Agile еще более гибким.
Мы разберем основные принципы DevOps через призму донесения смысла без потерь:
- Особая культура
- Автоматизация
- Изменения через измерения
- Распространение знаний и практик
Я поделюсь своим 5ти летним опытом в обеспечении повторяемости, мониторинге, логировании с примерами из реальной жизни.
Александр Титов - управляющий партнер в компании "Экспресс 42", мы внедряем DevOps практики и инструменты, помогаем эксплуатировать интернет-проекты.
В 2009, 2010 годах был техническим директором первого облачного хостинга в России Скалакси.
В 2010 - 2012 прошел увлекательный путь поглощений вместе с компанией Qik - путь из эксплуатации быстрорастущего стартапа к эксплуатации в крупной международной компании Microsoft.
SECON'2016 Евтухович Иван, Эксплуатация завтрашнего дня: от DevOps к NoOpsSECON
За последние годы у ИТ-сообщества накопился опыт использования систем управления конфигурацией и работой в организации по методологии DevOps. Но растущие вызовы показывают, что и этот подход имеет свои недостатки. Доклад расскажет о том, какие контейнеры бывают и почему они победят, что придет на смену облакам, и какие практики стоит начать внедрять сегодня, чтобы завтра не остаться без работы.
«DevOps — это о передаче смысла» — Александр Титов, Express 42DevDay
Текущим определением DevOps является аббревиатура CAMS:
— культура;
— автоматизация;
— измерения;
— распространение знаний.
Для меня это недостаточно понятно, я дополнил эти пункты тем, что DevOps это впервую очередь о передаче смысла без искажений. Я расскажу, как эти мысли соотносятся с методиками прошлого (ITIL, etc), как, используя такой подход, создать набор правил для работы и почему автоматизация — это не всегда хорошо.
Мы посмотрим как инструменты автоматизации помогают передавать смысл изменений между окружениями на примере реальных компонентов и кукбуков и рассмотрим на практике почему bash скрипты более слабый инструмент, чем Opscode Chef.
Совместно разберемся к требованиям к системе мониторинга. Что в системах мониторинга вредит передаче смысла, а что, наоборот, помогает. Какую систему мониторинга выбрать для вашего проекта?
Важность честности и открытости в команде для передачи смысла. Честные публичные пост-мортемы — это не проявление слабости, а проявление уважения к своим пользователям. Как научится делиться информацией друг с другом и не скрывать важного.
Доклад на конференции Youcon в октябре 2016 года. http://youcon.ru/
В последнее время только ленивый не пишет о микросервисной архитектуре. Но почему вдруг этот достаточно очевидный способ организации ИТ-проектов стал так популярен?
В докладе пойдет речь о том, что такое микросервисная архитектуры, об ее принципах и устройстве и преимуществах, которые она предоставляет, будет рассказано об основных компонентах, которые она включает в себя. Также будет дан краткий экскурс в контейнеры и Docker в разрезе их использования в микросервисной архитектуре.
Но любые преимущества не бывают бесплатными, также в докладе пойдет речь о том, какие недостатки несет в себе данный подход.
Обновленный и дополненный доклад о микросервисах, специально для конференции DevOpsPro.ru
http://www.devopspro.ru/ivan-evtukhovich/?lang=ru
Углубил и расширил тему оргдизайна согласно закону Конвея, рассказал про смерть "аналоговых" компаний, и про платформы и DCOS-ы.
Поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.
Рассмотрим следующие темы и поищем ответы на вопросы:
1) Что такое фреймворк, и зачем их пишут.
2) Почему для некоторых языков их десятки, а для некоторых — единицы.
3) В чём плюсы и минусы применения.
4) Наиболее распространённые мифы.
5) Использовать или нет — примеры из жизни.
6) Как выбрать из множества доступных вариантов, на что стоит обратить внимание.
NoSQL — это слово громко "жужжит".
К сожалению, оно при этом ничего не означает. Это не продукт, не технология, и даже не концепция. Это даже не подход к проектированию. Это, скорее, декларация отказа от некоторых паттернов проектирования, господствовавших в разработке клиент-серверных систем долгие годы.
На этом доклад можно было бы и закончить. Если бы мы не знали достоверно, что на свете есть люди, которые умудряются извлекать прибыль, используя NoSQL в своих проектах. Ну или сокращать убытки, по крайней мере.
Попробуем еще раз.
NoSQL — это именно декларация отказа от некоторых паттернов.
- От чего именно придется отказаться? Упомянутые паттерны так живучи совсем не случайно.
- Как это ударит по проекту? Не сомневайтесь, оно ударит, в этом мире нет ни серебряных пуль, ни бесплатного сыра.
- Какими свойствами должен обладать проект, чтобы внедрение NoSQL СУБД принесло ему пользу? Избегать NoSQL — это не трусость, это осторожность.
- Каковы сильные стороны NoSQL СУБД, и в чем профит? Выбор NoSQL — это всегда выбор в пользу меньшего зла.
- Как выбрать NoSQL СУБД под свою задачу? На http://nosql-database.org/ есть список LIST OF NOSQL DATABASES [currently >225], и даже просто прочесть его — тяжелая работа.
- Почему реальный выбор NoSQL СУБД — это выбор между Aerospike и Cassandra? Да, это провокационный вопрос, но на него есть not-so-provocative ответ.
- С какими проблемами сталкиваются разработчики и администраторы при эксплуатации "тяжелой" NoSQL базы? К сожалению, большая часть этих проблем создается именно присутствием NoSQL.
- Что можно делать с NoSQL СУБД и чего нельзя? На какие параметры производительности и отказоустойчивости можно рассчитывать? В чем особенности выбора "железа" для NoSQL?
- И в чем, все-таки, profit?
На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.
DevOps Fest 2020. Барух Садогурский и Леонид Игольник. Устраиваем DevOps без ...DevOps_Fest
Казалось бы, доклад про устроение DevOps должен быть про настройку Дженкинса, но нет! Этот доклад для тех, кто понимает, что DevOps — это история про культуру, коллаборацию и общение, но не очень представляет, как будучи скромным исполнителем или тимлидом, повлиять на целый энтерпрайз, и сдвинуть организацию в сторону DevOps. Барух расскажет какими методами можно воспользоваться для влияния на stake–holder-ов, что кому говорить, как мотивировать, и как работать с возражениями. Пожалуй, за исключением парапсихологических практик и гипноза (которые не стоит раскрывать неокрепшим умам), на этом докладе будут обозрены все способы влиять, не имея полномочий на благо наступления повсеместного DevOps в индустрии.
Как FB, Apple и Google разрушают традиции в компьютерном бизнесе, и почему эт...Ontico
HighLoad - новый взгляд на инфраструктуру центра обработки данных для современных нужд и приложений. Эволюция инфраструктуры датацентра. Как Facebook совершил “открытие” в железной инфраструктуре.
- Тенденции и принципы развития открытых платформ
Как крупный заказчик может заставить работать производителей железа в своих интересах и полностью уйти от зависимости от производителя;
- “Проблема импортозамещения” – видение и решения
Как уйти от порочной зависимости от производителя оборудования? Переработать, переосмыслить, открыть и заставить мировых производителей IТ-оборудования работать на себя на конкурсной основе.
- Открытые системы сегодня и завтра
Это заставило потребителей, производителей оборудования и разработчиков программного обеспечения совместно переосмыслить все аспекты эксплуатации и производства оборудования.
Примеры открытых систем, преимущества и недостатки:
- Facebook OCP. Проблемы, которые стояли перед Facebook и не решались эффективно известными компаниями лидерами IT-нфраструктуры:
-- Виртуальная программно-определяемая инфраструктура;
-- Максимальная унификация;
-- Сверхпреемственность и защита инвестиций;
-- Энергопотребление и тепловыделение;
-- Компактность и плотность платформ;
-- Обслуживание и ремонтопригодность;
-- Минимизация сервисных затрат.
- Почему мы выбрали .NET Core качестве основной платформы для нашего продукта
- команда мечты от разработчиков Java, которая начала писать на .NET Core;
- мониторинг системы, поиск запросов и другие диагностические задачи.
Software craftsmanship фиксит проблемы AgilePavel Veinik
На 6м митапе мы подойдем к проблеме говна со стороны команды и процессов, а не со стороны технологий и архитектуры, и рассмотрим поближе, чем и как нам могут помочь принципы Software Craftsmanship. Мы увидим, что суть всех процессов - это коммуникации, а суть коммуникации - это настроенные каналы передачи информации. Мы рассмотрим, как настраивать эти каналы передачи информации, и увидим, что процессы - это отношения между людьми, прописанные на бумаге.
Мир меняется очень быстро. То, что казалось нормальным еще несколько лет назад, перестало быть таковым. Например, наши родители не считают, что работа должна приносить удовольствие. Они уверены, что работа должна приносить деньги.
Все поменялось. Теперь все уверены, что работа должна нравится. Если это не так, нужно немедленно эту работу сменить на другую, более развлекающую.
С этим можно спорить и несоглашаться, но победить это уже нельзя. Вопрос в том, можем ли мы это использовать и как это сделать?
Мы поговорим о геймификации, одном из способов этого добиться. Геймификация — это использование игровых подходов вне игрового контекста.
Вот и мы с вами посмотрим, как практики гейм дизайна использовать для улучшения процесса разработки ПО.
Константин Назаров – Распараллеливание сборки Parallels Desktop для Mac404fest
Идея доклада — рассказать об использовании Jenkins как не типичного инструмента для построения распределенной сборки продукта, зарабатывающего миллионы долларов. Мы поделимся секретами его адаптации под сборку билдов сложных систем/продуктов с многими компонентами и ускорения в разы этой задачи.
Наша проблема: линейная сборка продукта занимает 8 часов. А Jenkins «из коробки» не умеет собирать сложные иерархии. При этом писать код самостоятельно не хочется. В итоге мы придумали, как использовать существующий инструмент, пройдясь по нему напильником.
Кому будет интересно: Эти знания могут помочь людям, которые хотят построить эффективный CI, но не хотят тратить много времени на исследования.
Мы выложим наш код и материалы на GitHub. Это будет довольно практично.
Лайфхаки:
Используем Build Flow + Groovy скрипты чтобы оркестрировать сложную иерархию с параллельными ветвями и собирать результаты
Правильное использование префиксов в названиях job-ов помогают автоматизировать группировку по бранчам
Переиспользуем окружения сборки много раз, не удаляя их
Предыдущий пункт в итоге оставляет за собой кучу мусора, которую мы периодически очищаем при помощи системных Groovy скриптов по job префиксу
Группировка большого количества job-ов в проекты и бранчи с использованием Nested View
Дамп и разворачивание job-ов из системы контроля версий по шаблону
Ну и взгляд в будущее: автоматический анализ билд проблем.
http://2014.404fest.ru/reports/jenkins/
Обновленный и дополненный доклад о микросервисах, специально для конференции DevOpsPro.ru
http://www.devopspro.ru/ivan-evtukhovich/?lang=ru
Углубил и расширил тему оргдизайна согласно закону Конвея, рассказал про смерть "аналоговых" компаний, и про платформы и DCOS-ы.
Поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.
Рассмотрим следующие темы и поищем ответы на вопросы:
1) Что такое фреймворк, и зачем их пишут.
2) Почему для некоторых языков их десятки, а для некоторых — единицы.
3) В чём плюсы и минусы применения.
4) Наиболее распространённые мифы.
5) Использовать или нет — примеры из жизни.
6) Как выбрать из множества доступных вариантов, на что стоит обратить внимание.
NoSQL — это слово громко "жужжит".
К сожалению, оно при этом ничего не означает. Это не продукт, не технология, и даже не концепция. Это даже не подход к проектированию. Это, скорее, декларация отказа от некоторых паттернов проектирования, господствовавших в разработке клиент-серверных систем долгие годы.
На этом доклад можно было бы и закончить. Если бы мы не знали достоверно, что на свете есть люди, которые умудряются извлекать прибыль, используя NoSQL в своих проектах. Ну или сокращать убытки, по крайней мере.
Попробуем еще раз.
NoSQL — это именно декларация отказа от некоторых паттернов.
- От чего именно придется отказаться? Упомянутые паттерны так живучи совсем не случайно.
- Как это ударит по проекту? Не сомневайтесь, оно ударит, в этом мире нет ни серебряных пуль, ни бесплатного сыра.
- Какими свойствами должен обладать проект, чтобы внедрение NoSQL СУБД принесло ему пользу? Избегать NoSQL — это не трусость, это осторожность.
- Каковы сильные стороны NoSQL СУБД, и в чем профит? Выбор NoSQL — это всегда выбор в пользу меньшего зла.
- Как выбрать NoSQL СУБД под свою задачу? На http://nosql-database.org/ есть список LIST OF NOSQL DATABASES [currently >225], и даже просто прочесть его — тяжелая работа.
- Почему реальный выбор NoSQL СУБД — это выбор между Aerospike и Cassandra? Да, это провокационный вопрос, но на него есть not-so-provocative ответ.
- С какими проблемами сталкиваются разработчики и администраторы при эксплуатации "тяжелой" NoSQL базы? К сожалению, большая часть этих проблем создается именно присутствием NoSQL.
- Что можно делать с NoSQL СУБД и чего нельзя? На какие параметры производительности и отказоустойчивости можно рассчитывать? В чем особенности выбора "железа" для NoSQL?
- И в чем, все-таки, profit?
На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.
DevOps Fest 2020. Барух Садогурский и Леонид Игольник. Устраиваем DevOps без ...DevOps_Fest
Казалось бы, доклад про устроение DevOps должен быть про настройку Дженкинса, но нет! Этот доклад для тех, кто понимает, что DevOps — это история про культуру, коллаборацию и общение, но не очень представляет, как будучи скромным исполнителем или тимлидом, повлиять на целый энтерпрайз, и сдвинуть организацию в сторону DevOps. Барух расскажет какими методами можно воспользоваться для влияния на stake–holder-ов, что кому говорить, как мотивировать, и как работать с возражениями. Пожалуй, за исключением парапсихологических практик и гипноза (которые не стоит раскрывать неокрепшим умам), на этом докладе будут обозрены все способы влиять, не имея полномочий на благо наступления повсеместного DevOps в индустрии.
Как FB, Apple и Google разрушают традиции в компьютерном бизнесе, и почему эт...Ontico
HighLoad - новый взгляд на инфраструктуру центра обработки данных для современных нужд и приложений. Эволюция инфраструктуры датацентра. Как Facebook совершил “открытие” в железной инфраструктуре.
- Тенденции и принципы развития открытых платформ
Как крупный заказчик может заставить работать производителей железа в своих интересах и полностью уйти от зависимости от производителя;
- “Проблема импортозамещения” – видение и решения
Как уйти от порочной зависимости от производителя оборудования? Переработать, переосмыслить, открыть и заставить мировых производителей IТ-оборудования работать на себя на конкурсной основе.
- Открытые системы сегодня и завтра
Это заставило потребителей, производителей оборудования и разработчиков программного обеспечения совместно переосмыслить все аспекты эксплуатации и производства оборудования.
Примеры открытых систем, преимущества и недостатки:
- Facebook OCP. Проблемы, которые стояли перед Facebook и не решались эффективно известными компаниями лидерами IT-нфраструктуры:
-- Виртуальная программно-определяемая инфраструктура;
-- Максимальная унификация;
-- Сверхпреемственность и защита инвестиций;
-- Энергопотребление и тепловыделение;
-- Компактность и плотность платформ;
-- Обслуживание и ремонтопригодность;
-- Минимизация сервисных затрат.
- Почему мы выбрали .NET Core качестве основной платформы для нашего продукта
- команда мечты от разработчиков Java, которая начала писать на .NET Core;
- мониторинг системы, поиск запросов и другие диагностические задачи.
Software craftsmanship фиксит проблемы AgilePavel Veinik
На 6м митапе мы подойдем к проблеме говна со стороны команды и процессов, а не со стороны технологий и архитектуры, и рассмотрим поближе, чем и как нам могут помочь принципы Software Craftsmanship. Мы увидим, что суть всех процессов - это коммуникации, а суть коммуникации - это настроенные каналы передачи информации. Мы рассмотрим, как настраивать эти каналы передачи информации, и увидим, что процессы - это отношения между людьми, прописанные на бумаге.
Мир меняется очень быстро. То, что казалось нормальным еще несколько лет назад, перестало быть таковым. Например, наши родители не считают, что работа должна приносить удовольствие. Они уверены, что работа должна приносить деньги.
Все поменялось. Теперь все уверены, что работа должна нравится. Если это не так, нужно немедленно эту работу сменить на другую, более развлекающую.
С этим можно спорить и несоглашаться, но победить это уже нельзя. Вопрос в том, можем ли мы это использовать и как это сделать?
Мы поговорим о геймификации, одном из способов этого добиться. Геймификация — это использование игровых подходов вне игрового контекста.
Вот и мы с вами посмотрим, как практики гейм дизайна использовать для улучшения процесса разработки ПО.
Константин Назаров – Распараллеливание сборки Parallels Desktop для Mac404fest
Идея доклада — рассказать об использовании Jenkins как не типичного инструмента для построения распределенной сборки продукта, зарабатывающего миллионы долларов. Мы поделимся секретами его адаптации под сборку билдов сложных систем/продуктов с многими компонентами и ускорения в разы этой задачи.
Наша проблема: линейная сборка продукта занимает 8 часов. А Jenkins «из коробки» не умеет собирать сложные иерархии. При этом писать код самостоятельно не хочется. В итоге мы придумали, как использовать существующий инструмент, пройдясь по нему напильником.
Кому будет интересно: Эти знания могут помочь людям, которые хотят построить эффективный CI, но не хотят тратить много времени на исследования.
Мы выложим наш код и материалы на GitHub. Это будет довольно практично.
Лайфхаки:
Используем Build Flow + Groovy скрипты чтобы оркестрировать сложную иерархию с параллельными ветвями и собирать результаты
Правильное использование префиксов в названиях job-ов помогают автоматизировать группировку по бранчам
Переиспользуем окружения сборки много раз, не удаляя их
Предыдущий пункт в итоге оставляет за собой кучу мусора, которую мы периодически очищаем при помощи системных Groovy скриптов по job префиксу
Группировка большого количества job-ов в проекты и бранчи с использованием Nested View
Дамп и разворачивание job-ов из системы контроля версий по шаблону
Ну и взгляд в будущее: автоматический анализ билд проблем.
http://2014.404fest.ru/reports/jenkins/
Распространенные ошибки применения баз данныхSergey Xek
Распространенные ошибки применения баз данных. Сергей Аверин, Badoo.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются раз- работчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, ко- торые потом в реальной жизни никогда не понадобится.
• Или проектируется архитектура, которая якобы дает отказоустойчи- вость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологиче- ская» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки собы- тий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и неболь- ших команд, техническим руководителям.
Безопасность - это не только конфиденциальностьAnton Zhbankov
Безопасность - это не только конфиденциальность, но так же целостность и доступность.
К чему приводит фокус только на первом пункте и что с этим делать?
Highload++2013: TopGun - архитектура терабитной платформы DPILeonid Yuriev
Презентация с конференции HighLoad-2013 об архитектуре новой DPI платформы Петер-Сервис.
http://www.highload.ru/2013/abstracts/1178.html
Представлен обзор архитектуры многоцелевой DPI-платформы, на основе которой могут строиться как "шпионские" приложения класса СОРМ/PRISM, так и коммерческие системы PCEF/TDF (Traffic Shaping), безопасного Интернета (интеллектуальная фильтрация содержимого), таргетирования рекламы и т. д. К особенностям рассматриваемого решения можно отнести мультитерабитное масштабирование, способ балансировки, обработку "роем" (Swarm Intelligence) и аварийного восстановления (failover) посредством репликации конечных автоматов.
Roadmap:
- offtopic: кому и зачем нужен DPI?
- offtopic: законность и морально-этические вопросы.
- на какую "луну" нужно сесть, что мы хотим сделать?
- распределение трафика за счет использования коммутаторов и MAC rewrite.
- роевой интеллект (Swarm Intellegence) для управления балансировкой и обработкой данных.
- репликация конечных автоматов (виртуальных микромашин).
- распределенное "Табло" как оперативное хранилище с элементами key-value и eventual consistency, lockfree в shared memory.
- транспортный фасад, унифицирующий DPDK, netmap, Infiniband (RDMA), 0mq и zerocopy и lockfree обмен через shared memory.
Эффективное решение насущных задач с помощью внешнего датацентраКРОК
IV Форум «Центры Обработки Данных 2009».
Подробнее о мероприятии http://www.croc.ru/action/partners/detail/2485/
Презентация Руслана Заединова, заместителя генерального директора, руководителя направления ЦОД компании КРОК
Не все базы данных одинаково полезны. Сергей Аверин, Badoo.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются раз- работчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, ко- торые потом в реальной жизни никогда не понадобится.
• Или проектируется архитектура, которая якобы дает отказоустойчи- вость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологиче- ская» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки собы- тий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и неболь- ших команд, техническим руководителям.
Не все базы данных одинаково полезны. Сергей Аверин, Badoo.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются разработчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
О компании:
Badoo — не только самая большая, но и одна из самых инновационных и высокотехнологичных компаний в сфере социальных сетей, входящий в топ-100 крупнейших мировых проектов. Она насчитывает 139 миллионов пользователей, и еще более чем 100,000 новых пользователей присоединяются к ней каждый день.
Badoo — это глобальная социальная онлайн-система, которая дает возможность знакомиться с новыми людьми, живущими пососедству и по всему миру. Мы предлагаем многочисленные технические возможности социальных сетей, делая акцент на играх и сервисах, позволяющих расширить социальный круг. Мы продолжаем расширять географию своего пребывания и использовать самые последние технологии в сетевом общении, позволяющие нашим пользователям знакомиться друг с другом и изменять реальность вокруг себя.
Видеоприглашение на конференцию:
http://www.youtube.com/watch?v=2mRGcz0UODY
Развитие DevOps/NoOps инструментов. Что было, что есть, что будет.Ivan Evtukhovich
Доклад для конференции SQADays 20, обзорно рассказывает про DevOps, переход к NoOps и микросервисной архитектуре, а также почему ручное тестирование умрет.
Повторяемость для котиков: библиотекарь и книжная полкаIvan Evtukhovich
Поговорим о проблемах командного изменения конфигурации, а также управления версиями и зависимостями сторонних библиотек (в терминах Chef — кукбуков):
• где хранить сторонние кукбуки;
• как сделать, чтобы у всех инженеров был одинаковый «срез» конфигурации;
• как обновлять свои и сторонние кукбуки с учетом их зависимостей.
В докладе описаны два современных инструмента для решения этих проблем: librarian-chef и Berkshelf. Мы сравним их, разберем сильные и слабые стороны, особенности интеграции с системой создания окружений Vagrant. Также посмотрим на практики использования этих инструментов, выработанные в компании «Экспресс 42».
Видео есть здесь: http://tech.yandex.ru/events/yagosti/devops/talks/1597/
4. Надежные решения для сложной инфраструктуры
Почему я решился
• Продавать пик компетенции
• Зарабатывать МНОГО денег
• Быть свободным
• 30 лет
5. Надежные решения для сложной инфраструктуры
Начало
• 22 февраля 2012 — дата регистрации ООО
• май 2012 — начало работы над первым клиентом
tulp.ru
• сайт и городской телефон
6. Надежные решения для сложной инфраструктуры
Успех
• июнь 2012 — очень богатый клиент
• август 2012 — первый неудачный клиент
• октябрь 2012 — kupikupon
7. Надежные решения для сложной инфраструктуры
Кассовый разрыв
• 1 января 2013 — нас 6 человек
• апрель 2013 — кончаются деньги
• “продуктовый” отдел
• “продажник”
10. Надежные решения для сложной инфраструктуры
Партнеры
• Умеет ли технический специалист вести бизнес?
• Умеет ли технический специалист продавать?
11. Надежные решения для сложной инфраструктуры
Фокус
• Сервисная компания
• Продуктовая компания
12. Надежные решения для сложной инфраструктуры
Чудо
• апрель 2013 — два новых клиента
• август 2013 — новый “продажник”
• начинаем читать книги по продажам и ведению
переговоров
• закрываем “продуктовый” отдел
13. Надежные решения для сложной инфраструктуры
Итоги 2014
• апрель 2014 — взяли продажника
• нас 8 человек
• мы практически удвоили оборот за год
• мы все еще учимся продавать
14. Надежные решения для сложной инфраструктуры
Продажи
• Кому продавать? (Целевая аудитория)
• Что продавать? (Как упаковывать услугу)
• Как продавать? (Какие каналы поиска клиентов)
15. Надежные решения для сложной инфраструктуры
Как продавать
• Выступления на конференциях (0 продаж)
• Мастер-Классы (2 обращения, 0 продаж)
• Сарафан — практически все продажи
• IT отделы настроены против
• Бизнес не совсем понимает, о чем говорят
16. Надежные решения для сложной инфраструктуры
Что продавать
• Катастрофоустойчивость
• Отказоустойчивость
• Управление конфигурацией
• Оптимизация производительности
17. Надежные решения для сложной инфраструктуры
Что продавать
• DevOps
• Непрерывную поставку ПО
• Частые релизы
18. Надежные решения для сложной инфраструктуры
Незнание
• Может мы не то продаем?
• Может мы не так продаем?
• Может мы не тем продаем?
• Крайне сложно проверить гипотезу
19. Надежные решения для сложной инфраструктуры
Крушение идеалов
• Никому не нужен пик компетенции
• Денег стал зарабатывать меньше
• Работать лучше всего в офисе
• Профессиональный рост тормозится
20. Надежные решения для сложной инфраструктуры
Опыт: техника
• “Все будут комитить в Chef”
• Chef сложен (Ansible тоже)
• Chef-server не является Service Discovery
• Повторяемость есть, но она сомнительна
21. Надежные решения для сложной инфраструктуры
Опыт: люди
• Знания тяжело отчуждаются
• Успешность использования мало зависит от нас
• Люди — самый жесткий материал
22. Надежные решения для сложной инфраструктуры
Светлое будущее
• Управление конфигурацией никуда не денется
• Chef/Ansible/Puppet/Salt/DSC миновали свой пик
• Углубление “разделения труда”:
• хранение данных (БД, файлы, очереди и т.д.)
• аналитика
• логирование
• мониторинг и т.д.
23. Надежные решения для сложной инфраструктуры
Микросервисы
• Контейнеры
• перезапуск/балансировка/service discovery
• управление ограничениями
• Workflow работы с контейнерами
• Mesos Marathon/Kubernetes
24. Надежные решения для сложной инфраструктуры
Дисциплина и
технология
• 30 лет против 5 лет
• http://www.postgresql.org/support/versioning/
• The PostgreSQL project aims to fully support a
major release for five years.
• http://php.net/supported-versions.php
• 2 years + 1 year security bugfix
25. Надежные решения для сложной инфраструктуры
Развитие и
совершенствование
• Где баланс?
• Когда переходить на новую технологию?
• Как это делать?
26. Надежные решения для сложной инфраструктуры
Тренды
• Смерть нераспределенных хранилищ
• Смерть ОС общего назначения
• Смерть “хостов” (а также SSH, Zabbix и т.д.)
• Конец очарования технологиями
• Смерть open-source
27. Надежные решения для сложной инфраструктуры
Наш вклад
• Мастер-классы по DevOps/Chef
• Выступления на конференциях
• DevOps Moscow meetup (900+ человек)
• Конференция RootConf (http://rootconf.ru/)
28. Надежные решения для сложной инфраструктуры
DevOps сообщество
• devopsru.com
• http://www.meetup.com/DevOps-Moscow-in-
Russian
• https://groups.google.com/forum/#!forum/devopsru
• http://hangops.ru
• http://devopsdeflope.ru
31. Надежные решения для сложной инфраструктуры
Книги
• Непрерывное развертывание ПО. Автоматизация
процессов сборки, тестирования и внедрения
новых версий программ. Джез Хамбл, Давид
Фарли
• Проект “Феникс”. Роман о том, как DevOps
меняет бизнес к лучшему. Джин Ким и др.
32.
33. Надежные решения для сложной инфраструктуры
http://express42.com
+7 499 918 67 34
@evtuhovich
evtuhovich@gmail.com