Как стать автором
Обновить
74
0
Александр Титов @osminog

исследователь DevOps

Отправить сообщение

DevOps и Value of User: новая культура взаимодействия бизнеса и инженеров

Время на прочтение13 мин
Количество просмотров3K

Это экспериментальная статья про Research&Development, технологии для создания новой ценности для клиента — потому не будет ни слова про техническую часть. Будет немного про историю и культуру DevOps , а также про процессы, культурные особенности, взаимодействие внутри инженерных команд и, конечно, особенности появления R&D внутри них.

Сразу скажу, что это немного идеалистичная картина для нашего российского IT. У нас еще мало компаний, которые дейсвительно используют R&D в качестве основного зарабатывающего бизнес-юнита. В основном лишь частично внедряются практики, взаимодействие и культуру DevOps. Но это не значит, что туда не надо идти. Если у вас это вызовет отторжение: «Такого не бывает, это не работает», то предлагаю превратить это в вопрос: «Такого не бывает? Это не работает?» 

Меня зовут Александр Титов, первые DevOps-практики я начал использовать еще до того, как появилось само слово DevOps. Сейчас я управляющий партнер в компании Экспресс 42, которая помогает ставить DevOps в компаниях.

Читать далее
Всего голосов 18: ↑17 и ↓1+16
Комментарии0

Техдолг. Все говорят: «невозможно», а я говорю, что буду

Время на прочтение18 мин
Количество просмотров13K
Очень часто драматически и патетически утверждают, что техдолг лучше не плодить — потом не устранишь. Да, без него, конечно, лучше. Но последствия устранить все-таки можно, и глава Программного комитета Артем Каличкин на конференции DevOpsConf 2020 поделился своим опытом в этой области.

Можно спросить, а причем здесь техдолг, если конференция DevOps? Холиварить об этом можно, например, в рамках DevOps-фуршета, но настолько ли это широкое понятие? Мы узнали, что Артем относит к техдолгу все изменения и доработки, инфраструктурные модификации и изменения процессов, изменения структур команд, направленные на устранение гэпов — которые были допущены (осознанно или нет) в рамках запуска продуктов и фич, и которые со временем сильно мешать жить.

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


Читать дальше →
Всего голосов 50: ↑50 и ↓0+50
Комментарии8

Состояние DevOps в России 2020

Время на прочтение15 мин
Количество просмотров6.3K
Как вообще понять состояние чего-либо?

Можно положиться на свое мнение, сформированное из разных источников информации, например, публикаций на сайтах или опыта. Можно спросить у коллег, знакомых. Еще вариант — посмотреть на темы конференций: программный комитет — это активные представители индустрии, поэтому мы им доверяем в выборе актуальных тем. Отдельное направление — это исследования и отчеты. Но есть проблема. Исследования состояния DevOps ежегодно проводятся в мире, отчеты публикуются зарубежными компаниями и о российском DevOps информации там почти нет.

Но настал тот день, когда такое исследование провели, и мы сегодня расскажем про полученные результаты. Состояние DevOps в России исследовали совместно компании «Экспресс 42» и «Онтико». Компания «Экспресс 42» помогает технологическим компаниям внедрять и развивать DevOps практики и инструменты и одна из первых начала рассказывать про DevOps в России. Авторы исследования — Игорь Курочкин и Виталий Хабаров занимаются в компании «Экспресс 42» анализом и консалтингом, имея при этом технический бэкграунд из эксплуатации и опыт работы в разных компаниях. За 8 лет коллеги посмотрели десятки компаний и проектов — от стартапа до энтерпрайза — с разными проблемами, а также разной культурной и инженерной зрелостью.

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


Читать дальше →
Всего голосов 28: ↑28 и ↓0+28
Комментарии2

Трек DevSecOps — тест безопасности на DevOpsConf Live 2020

Время на прочтение4 мин
Количество просмотров1.4K

У нас 2 часа. Быстро пофиксим баг и сразу назад...


Кибербезопасность в наше время нужна везде, от условного пропускного режима и коммерческой тайны до PR и коммуникаций в кризисные моменты. ИТ уже очень глубоко и критично проникли в бизнес, а новые технологии все легче создать, внедрить и использовать. Новинки тяготеют к низкому порогу вхождения (ну-ка, кто помнит FreeBSD jails? А традиционный lxc? А теперь у нас раз-раз и докер). Если раньше проблемой ИБ были пользователи с низким уровнем компьютерной грамотности, сейчас условная MongoDB голыми портами в Интернет или же прод-среды со слабыми паролями и переиспользованием уязвимого кода становятся головной болью и могут привести к остановке бизнеса.

Чтобы создать приватность и не дать утечь персональным данным, должны проектироваться и разрабатываться Secure by Design системы, когда ИБ не идет на компромисс в процессе создания кода. Но как можно сделать это самое Secure, если Design делается другим подразделением на самых модных и не всегда проверенных технологиях?


Читать дальше →
Всего голосов 7: ↑7 и ↓0+7
Комментарии0

Антиформаты не-идеального DevOps Live

Время на прочтение6 мин
Количество просмотров1.8K
Обычно на конференции по DevOps приезжает выступать передовой ТОП докладчиков, которые «съели Docker и Kubernetes на завтрак» и рассказывают о своем успешном опыте при наличии почти неограниченных возможностей корпораций, в которых они работают. На DevOps Live 2020 все будет немного по-другому. 



DevOps стирает границы между разработкой и инфраструктурой, а DevOps Live 2020 размывает границы между докладчиком и слушателем. В этом году онлайн-формат позволяет отказаться от концепции докладов, в которых спикеры рассказывают как они использовали «режима Бога» в DevOps. У большинства из нас нет таких чит-кодов, а есть обычные стандартные проблемы при минимальных ресурсах. У большинства из нас DevOps не-идеальный — его мы и хотим показать. Как это будет и что нас ждет, расскажем дальше.
Читать дальше →
Всего голосов 20: ↑20 и ↓0+20
Комментарии0

Первое исследование состояния DevOps в России

Время на прочтение3 мин
Количество просмотров3.6K
В 2019 году компания DORA и и Google Cloud выпустили совместный отчет The 2019 Accelerate State of DevOps: Elite performance, productivity, and scaling, из которого мы знаем, как в мире обстоят дела с DevOps. Это часть большого исследования DevOps, которым DORA занимается с 2013 года. За это время компания опросила уже 31 000 IT-специалистов по всему миру.



Исследование DORA проходит уже шесть лет и по нему видна динамика развития практик DevOps в мире. Но по этим результатам мы не можем объективно сказать в каком состоянии DevOps в России, сколько компаний внедрили практики, какие инструменты используют и получают ли пользу. Слишком мало данных — за последние пару лет в опросах DORA поучаствовало меньше 60 человек из России. Мы хотим исправить эту ситуацию и запускаем исследование состояния DevOps в России.

Примечание. Мы запускаем русскоязычный масштабный опрос о DevOps. Можете сразу перейти, поучаствовать и внести свой вклад в развитие DevOps, а если хотите узнать подробности об исследовании и его целях — читайте дальше.
Читать дальше →
Всего голосов 28: ↑28 и ↓0+28
Комментарии0

Как (вы)жить без отдела безопасности

Время на прочтение15 мин
Количество просмотров13K
Безопасность — это защита объектов и интересов от угроз. Когда кажется, что с ней всё хорошо, в интернете появляется много интересного: списки e-mail и телефонов из незащищённой базы данных крупных магазинов, записи колл-центров некоторых операторов, логины и пароли производителей оборудования из открытого репозитория или данные миллионов кредитных карт клиентов крупных банков.



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

Мона Архипова — соучредитель и COO в sudo.su (МИРЦ) и vCISO Anna Systems. Ранее работала на различных руководящих и экспертных должностях в IT и безопасности. Всё ещё играющий бизнес-тренер.
Всего голосов 24: ↑22 и ↓2+20
Комментарии12

Могут ли контейнеры быть безопасными?

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

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


О спикере: Александр Хаёров (allexx) 10 лет занимается разработкой, в основном веб-проектами, связанными с инфраструктурой, а сейчас руководит разработкой в Chainstack. В этой должности приходится примерять на себя самые разные роли и заниматься всем: от классической разработки до принятия технических решений и управления людьми. Это позволяет исследовать разные темы, в том числе ту, о которой пойдет речь в статье — далее от первого лица.
Всего голосов 25: ↑24 и ↓1+23
Комментарии2

Что мы узнали о SRE, когда обработали первые 150 тысяч продакшн-инцидентов

Время на прочтение11 мин
Количество просмотров5.3K
Абсолютной надежности приложения или сервиса нельзя достичь. Пользователи этого не заметят из-за сбоев посредников — сотовых сетей или провайдеров, но при этом останутся без новых функций, потому что все разработчики будут заняты поддержанием стабильности. Но можно достичь того уровня надежности, которого будет достаточно, чтобы были довольны клиенты, бизнес и инженеры с разработчиками. В этом помогает концепция Site Reliability Engineering, которую ввел Google в 2003 году. Основная ее задача — предотвратить «футбол» с багами между разработкой и эксплуатацией.



Концепция SRE содержит много «странных вещей». В SRE разработчики не только пишут код, но и следят за тем, как он работает в продакшне. Доступность и надежность приложений и сайтов начинается с измерения доступности в виде четких показателей и установки показателей надежности. Еще в SRE есть «право на ошибку» или Error Budget. Когда это «право» исчерпано, команда занимается повышением надежности. Если нет — работает над новыми функциями.

Обо всем этом расскажет Матвей Кукуй. SLI, SLO и Error Budget, источники инцидентов и их особенности, инструкция по наведению порядка в мониторинге — об этом под катом через кейсы из реальной жизни.

Всего голосов 12: ↑12 и ↓0+12
Комментарии0

Наследование legacy-систем и процессов или Первые 90 дней в роли CTO

Время на прочтение15 мин
Количество просмотров12K
Известно, что компетентность CTO проверяется только на второй раз исполнения этой роли. Потому что одно дело несколько лет работать в компании, вместе с ней эволюционировать и, находясь во все том же культурном контексте, постепенно получать больше ответственности. И совсем другое — прийти сразу в должность техдиректора в компанию с багажом legacy и кучей проблем, аккуратно заметенных под ковер.

В этом смысле опыт Леона Файера, которым он делился на DevOpsConf, не то чтобы прямо уникален, но помноженный на стаж и количество различных ролей, которые он за 20 лет успел на себя примерить, очень полезен. Под катом хронология событий за 90 дней и много баек, над которыми приятно посмеяться, когда они происходят с кем-то другим, но с которыми не так уж весело сталкиваться лично.

Леон очень колоритно рассказывает по-русски, поэтому если у вас есть 35-40 минут, то рекомендую смотреть видео. Текстовая версия для экономии времени ниже.

Всего голосов 41: ↑40 и ↓1+39
Комментарии4

Как правильно использовать доступный объем хранилища

Время на прочтение11 мин
Количество просмотров6.2K
Мы давно пользуемся облачными сервисами: почта, хранилища, соцсети, мессенджеры. Все они работают удаленно — отправляем сообщения и файлы, а хранятся и обрабатываются они на удаленных серверах. Также работает и облачный гейминг: пользователь подключается к сервису, выбирает игру и запускает. Для игрока это удобно, потому что игры запускаются почти мгновенно, не занимают память, и не нужен мощный игровой компьютер.



Для облачного сервиса все иначе — у него возникают проблемы хранения данных. Каждая игра может весить десятки или сотни гигабайт, например, «Ведьмак 3» занимает 50 Гбайт, а «Call of Duty: Black Ops III» — 113. При этом игроки не будут пользоваться сервисом с 2-3 играми, как минимум нужно несколько десятков. Кроме хранения сотен игр, сервису нужно решать, какой объем хранилища выделять на одного игрока, и масштабироваться, когда их будут тысячи.

Хранить ли все это на своих серверах: сколько их нужно, где ставить дата-центры, как «на лету» синхронизировать данные между несколькими дата-центрами? Покупать «облака»? Использовать виртуальные машины? Можно ли хранить данные пользователей со сжатием в 5 раз и предоставлять их в real-time? Как исключить любое влияние пользователей друг на друга при последовательном использовании одной и той же виртуальной машины?

Все эти задачи успешно удалось решить в Playkey.net — облачной игровой платформе. Владимир Рябов (Graymansama) — руководитель отдела системного администрирования — подробно расскажет о технологии ZFS для FreeBSD, которая в этом помогла, и ее свежем форке ZOL (ZFS on Linux).
Всего голосов 20: ↑20 и ↓0+20
Комментарии3

Основы DevOps. Вхождение в проект с нуля

Время на прочтение16 мин
Количество просмотров29K
В ноябре 2018 года в ЛитРес создали отдел информационного обеспечения и пригласили руководить Андрея Юмашева. Последний год отдел помогает компании работать и развиваться и держит под контролем всю инфраструктуру. Но так было не всегда. Перед тем, как наладить работу, Андрей столкнулся с руинами: полуживой Nagios, условно живой Cacti и коматозный Puppet, мертвая Вики на 120 страниц, несвязные таблицы с задачами и списком железа, устаревшая архитектура, 340 бездействующих ядер, 2 Тбайта оперативной памяти и 17 Тбайт дискового пространства, которые почему-то не были записаны в инвентарных таблицах. Планы, которые не работают, сроки, которые срываются, рабочее окружение и инструменты, которых нет — все это ждало Андрея в новом проекте.



На DevOpsConf 2019 Андрей выступил с докладом, в котором на живых примерах показал, что стоит, а что не стоит делать, когда входишь в проект, которого еще не видел или плохо знаешь. Под катом дополненная версия рассказа — как правильно анализировать спектр проблем и выстроить план деятельности, как правильно рассчитать KPI и когда следует вовремя остановиться.
Всего голосов 55: ↑47 и ↓8+39
Комментарии15

Логи не нужны?

Время на прочтение10 мин
Количество просмотров36K
Разработка сильно изменилась за последние годы. Вместо монолитных приложений пришли микросервисы и функции. Базы данных из универсальных промышленных монстров переродились в узконаправленные. Docker изменил взгляд на деплой. Но изменилось ли наше представление о логах?

Одна из больших проблем в Яндекс.Вертикалях были логи — 18 ТБ в день и 250 000 логов в секунду, все пишется в файлы. Логи разнородные, потому что много языков: Scala, Java, Python, Go. Потом их собирает Fluent Bit, пишет в Kafka, на одной железной машине работают обработчики, собирают из Kafka и пишут всё на диск. При этом это уже вторая версия логов.



Как следствие, возникает проблема долгого поиска. По этим логам поиск идет с помощью grep. На некоторых сервисах grep может достигать часов. Если у вас есть проблемы в продакшн, вы не будете часами искать свои логи. Чтобы решить проблему, в Яндекс решили написать свой велосипед доставки логов для поиска. Что из этого получилось, расскажет Алексей Данилов (danevge) — разработчик команды инфраструктуры в Яндекс.Вертикалях. Разрабатывает, пишет и поддерживает проекты auto.ru и Яндекс.Недвижимость.

Дисклеймер. Статья рассказывает о современной разработке и подходит для микросервисной архитектуры. Здесь представлены различные продукты — это инструменты, которые используют в Яндекс.Вертикалях. Под другие условия возможны аналоги удачнее, но они выполняют практически те же функции.
Читать дальше →
Всего голосов 53: ↑43 и ↓10+33
Комментарии36

Автостопом по DevOps с Экспресс 42

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

Все началось в 2015-м году, когда мы, Экспресс 42, совместно с Онтико воссоздали конференцию RootConf. Формально направление конференции значилось как «Профессиональная конференция по эксплуатации и DevOps», но фактически на докладах в основном обсуждали задачи системного администрирования.

В 2018-м стало понятно, что в мире, где Dev и Ops живут в одном общем процессе, конференция только про системное администрирование уже неактуальна. Тогда мы начали постепенно менять формат конференции. Теперь наша конференция обо всем, что касается DevOps — от Kubernetes, до обсуждения изменения процессов и эффективного обмена знаниями.



Сейчас мы совместно с Программным комитетом взяли курс на все, что связано с превращением аналоговых бизнес-процессов в цифру. В программе DevOpsConf этого года упор на то, как все превращается в код и управляется в виде кода. Сообщество созрело и я уже предвкушаю, какая сильная получится конференция. Но сегодня речь о пройденном пути, о планах поговорим в другой раз.
Узнать, что еще значит 42, и получить видео
Всего голосов 23: ↑20 и ↓3+17
Комментарии1

Путеводитель по галактике DevOpsConf 2019

Время на прочтение10 мин
Количество просмотров2.2K
Представляю вашему вниманию путеводитель по DevOpsConf — конференции, которая в этом году имеет галактический масштаб. В том смысле, что нам удалось собрать такую мощную и сбалансированную программу, что путешествие по ней понравится самым разным специалистам: разработчикам, системным администраторам, инженерам инфраструктуры, QA, тимлидам, СТО и вообще всем, кто вовлечен в технологический процесс разработки.

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



Если хотите, то короткая выжимка нашего гида по DevOpsConf:

  • 30 сентября, в первый день конференции в первом зале рассмотрим 8 бизнес-кейсов.
  • Во втором зале в первый день разберем более узкоспециализированные инструментальные решения. В каждом докладе там много классного практического опыта, который однако подходит не всем компаниям.
  • 1 октября в первом зале наоборот говорим больше о технологиях, но уже более широко.
  • Во втором зале в второй день обсуждаем специфические задачи, возникающие не во всех проектах, например, в энтерпрайзе.
Читать дальше →
Всего голосов 23: ↑22 и ↓1+21
Комментарии4

Инфраструктура компании как продукт

Время на прочтение11 мин
Количество просмотров8.6K
Инфраструктура — это то, от чего зависит работа и прибыль IT-бизнеса. Все процессы, которые происходят с кодом от компьютера разработчика и до продакшена, зависят от бесперебойной работы серверов, ПО, внешних сервисов. Если инфраструктура не работает как надо, бизнес теряет прибыль.

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

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


Знаете ли вы сколько стоит ваша инфраструктура: серверы, ПО, внешние сервисы? Как вы считаете затраты на нее, по каким метрикам? Сколько вы потеряете, если что-то упадет или не будет бэкапа? Ответы на эти вопросы знает Артём Науменко (@entsu) из Skyeng. Он работал как в компаниях с двумя разработчиками в штате, так и в корпорациях с тысячей сотрудников. Сейчас руководит инфраструктурой в Skyeng и, одновременно, СТО детского обучения Skyeng. Артем расскажет как в компании строят инфраструктуру, как зарабатывают на ней деньги и какие ошибки не стоит допускать.
Всего голосов 39: ↑34 и ↓5+29
Комментарии5

Безопасность Helm

Время на прочтение15 мин
Количество просмотров6.6K
Суть рассказа о самом популярном пакетном менеджере для Kubernetes можно было бы изобразить с помощью эмоджи:

  • коробка — это Helm (это самое подходящее, что есть в последнем релизе Emoji);
  • замок — безопасность;
  • человечек — решение проблемы.



На самом же деле, все будет немножечко сложнее, и рассказ полон технических подробностей о том, как сделать Helm безопасным.

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

Все в этой статье относится к Helm 2. Эта версия сейчас находится в продакшене и, скорее всего, именно его вы сейчас используете, и именно в нем есть угрозы безопасности.
Всего голосов 35: ↑32 и ↓3+29
Комментарии0

Аварии помогают учиться

Время на прочтение14 мин
Количество просмотров13K
За 3 последних года в Контуре случилось больше тысячи инцидентов разной степени эпичности. Причины разные: например, 36% вызвано некачественным релизом, а 14% — работами по обслуживанию железа в дата-центре. Откуда статистика? После каждого инцидента пишется отчёт — постмортем. Их пишут дежурные инженеры, которые отреагировали на уведомление об аварии и первыми начали разбираться в ее причинах. Постмортемы анализируются, выявляются и устраняются причины инцидентов, чтобы в дальнейшем подобные инциденты не возникали. Но так было не всегда.

Алексей Кирпичников (BeeVee) с 2008 года программировал в Яндекс. Пробки, работал над спортивными спецпроектами, был тимлидом команды бэкенда Яндекс.Такси. С 2014 года занимается DevOps и инфраструктурой в Контуре — разрабатывает инструменты, которые облегчают жизнь разработчиков из продуктовых команд. Идея писать и анализировать постмортемы появилась пять лет назад, и за это время постмортемы обросли шаблонами, глоссарием, памятками, скриншотами и аналитикой. Но не это самое сложное — труднее было преодолеть инертность, страхи и непонимание смысла отчетов об инцидентах среди инженеров. Что в итоге получилось и какую непоправимую пользу может нанести «диванная аналитика» — в расшифровке доклада Алексея.


Обратите внимание — под ножки стола разной длины подложены книжки «Метрики», «Тесты» и «Деплой».
Всего голосов 40: ↑37 и ↓3+34
Комментарии3

Как переехать с ESXi на KVM/LXD и не сойти с ума

Время на прочтение14 мин
Количество просмотров31K
В компании «Макснет Системы» в качестве гипервизора долгое время использовалась бесплатная версия VMware — ESXi, начиная с версии 5.0. Платная версия vSphere отпугивала моделью лицензирования, а у бесплатной был ряд недостатков, которые отсутствовали в платной, но с ними можно было смириться. Но когда в новых версиях ESXi новый веб-интерфейс отказался работать со старым, а мониторинг RAID-массивов перестал подавать признаки жизни, компания решила искать более универсальное и открытое решение. В компании уже был неплохой опыт и приятное впечатление от LXC — Linux Containers. Поэтому стало очевидно, что гипервизор мечты будет гибридным и сочетать для разных нагрузок KVM и LXD — эволюционное продолжение LXC. В поисках информации относительно KVM, компания сталкивалась с заблуждениями, граблями и вредными практиками, но тесты и время расставили все по местам.



О том, как справиться с переездом с ESXi на KVM и не проколоть колеса на граблях, расскажет Лев Николаев (maniaque) — администратор и разработчик высоконагруженных систем, тренер по информационным технологиям. Поговорим о Сети, хранилищах, контейнерах, KVM, LXD, LXC, provisioning и удобных виртуалках.
Всего голосов 46: ↑40 и ↓6+34
Комментарии28

Конференция для фанатов DevOps-подхода

Время на прочтение7 мин
Количество просмотров4.9K
Речь, конечно, о DevOpsConf. Если не вдаваться в детали, то 30 сентября и 1 октября мы проведем конференцию об объединении процессов разработки, тестирования и эксплуатации, а если вдаваться — прошу под кат.

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

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


Всего голосов 28: ↑27 и ↓1+26
Комментарии0
1

Информация

В рейтинге
Не участвует
Откуда
Зеленоград, Москва и Московская обл., Россия
Работает в
Дата рождения
Зарегистрирован
Активность