Конференция закончилась всего несколько часов назад, поэтому в голове еще небольшой сумбур от количества и качества полученной информации. Надеюсь, написав этот пост у меня получиться разобраться в собственных мыслях. Сначала будут общие впечатления, затем кратко пробегусь по докладам и закончу мыслями на тему того, о чем говорили на конференции, благо таких мыслей накопилось по ходу прилично. Хотите узнать, о чем сейчас говорят в мире DevOps? Тогда вам под кат. И да, пост будет длинным, но в конце будет бонус-сюрприз).
О чем хочется сказать сразу — это была конференция, которую сделали инженеры, для инженеров и выступали на ней тоже только инженеры. Даже среди представителей вендорских тулов, как например OpsCode или PuppetLabs, не было зануд из маркетинга и отделов продаж. Именно поэтому к ним было адекватное отношение, с ними много и плотно общались, а не как обычно. По этой же причине не было расскрашенных бодиартом девочек и hr`ов в миниюбках. Все это создало действительно классную атмосферу тепловой ламповой конференции. К слову, на ней было около 300 человек, но это не мешало общаться с кем захочешь. Сплошной позитив в общем.
Отдельного хотелось бы рассказать про формат конференции: 1 зал, 4 доклада, 6 iginite talks по 10-15 минут и потом open-space. Из-за подобного формата все было очень динамично, все успели на все доклады, а самое главное — была возможность пообщаться по тем темам, которые на данный момент тебя действительно волнуют, а не слушать очередной доклад из разряда «какие мы молодцы», Таких, кстати, не было ни одного.
Так же хочется отметить действительно важную вещь — на инженерной конференции их 20 докладов и ignite talks всего 2 было посвящены инструментам. Во всех остальных речь шла про процессы, культуру, практики и людей. Приятная моему уху вещь — за два дня никто не назвал людей ресурсами. У нас бы так же!
Теперь собственно пробежимся по докладам. Программа доступна по этой ссылке, а доклады и видео через некоторое время будут выложены центролизовано, Но вернемся к докладам.
Начал конференцию Jesse Robbins - бывший пожарник, а по совместимости сооснователь компании Opscode. Джесси рассказывал про достаточно простую, но к сожалению не для всех очевидную вещь — переход к devops, это бизнес необходимость, а не желание инженеров получить приставку к своей должности. И если дело обстоит не так, вас ждут проблемы. В общем, Джесси рассказывал про трансформацию enterprise компаний с использованием ценностей agile и devops. И ключевая мысль его доклада о том, как крупные компании пытаются трансформироваться в современные и высокопроизводительные организации. Представим, что компания это слон, а цель трансформации — научиться летать. Так вот, многие компании пытаются начать махать своими слоновьими ушами, чтобы взлететь. Результат можно представить. Чтобы научиться летать нужны крылья, нужная энергия и место для взлета. Поэтому трансформация таких компаний в действительно что-то стоящее это долгий и сложный процесс в рамках которого нужно и крылья отрастить и лишнюю массу сбросить. Для меня этот доклад был ключевым во всей конференции, потому что отражал настоящую суть devops.
После Джесси слово перешло к Jeff Sussna, который рассказывал о том, о чем мало кто говорит — где же роль QA в devops. Если говорить в двух словах, то задача QA — вытащить голову, извините, из задницы и начать смотреть, а главное говорить всем, что они видят в приложении с точки зрения реального мира и реальных пользователей, работы приложения в боевой системе, а так же в работе бизнеса. По большому счету, все то же самое должен делать правильный QA и в Agile, в devops же ему еще положено разбираться в инфраструктуре и думать об автоматизации поставки, а не только своего уголка пионера, точнее функциональных тестов, В общем, от меня Джефу большой плюс в карму, потому что это еще один человек, который пытается разбудить спящих тестировщиков.
После перерыва микрофон в свои руки взял J.Paul Reed, который рассказал про организацию, которая делает 120 тыс поставок в день. Этой организацией является FAA - Federal Aviation Administration, Федеральное управление гражданской авиации, которая в день успешно завершает те самые 120 тыс перелетов внутри америки. Пол провел шикарную параллель между тем, что делает FAA и тем, как должен быть построен процесс разработки. При этом разработчики становятся пилотами, а operations — диспетчерами. Добавляем ряд практик, как например такую — если в системе наступает звездец, мы это честно признаем и разгребаем его, независимо от того, какие правила мы установили. И это общая задача всех членов команды. А чтобы звездец не объявляли слишком часто, мы делаем post-mortem. В докладе у Пола была классная визуализация того, как диспетчеры FedEx обработали ситуацию, когда всю Америку накрывал шторм, и как в этом время вели себя самолеты. Наглядность впечатляет. Ждем слайдов.
Четвертый доклад я в начале воспринял как маркетинговый буллшит, потому что в нем говорили про то, какую классную штуку придумали для того, чтобы девушки могли влиться в IT. Проект называется http://www.hackbrightacademy.com и он действительно крутой, но слушать об этом как то особо не хотелось, до тех пор пока не подняли такую тему как менторство и найм персонал в целом. И это была действительно классная тема и вот почему. Во многих компаниях остро стоит вопрос найма персонала, но при этом слабо задумываются о том, как людей встроить в имеющий процесс, а самое главное передать им тот же набор ценностей, который есть в команде. Так вот, решением данной проблемы является менторство, причем не формально — я ментор, окаааай, а полноценное, на которое выделяется время сотрудника. И важной составляющей является не просто обучение практикам, но так же и передача ценностей, настройка на нужный mindset. Таким образом люди действительно встраиваются в команды. И еще: «Speak to the „why“ of what your Jr. Engineers are doing so they know how to apply it in the future.» В общем, многим компаниям на заметку.
Про ignite talks я не буду подробно расписывать — дождитесь видео и посмотрите, там было реально крутые доклады. Мозг взрывался)
Второй день докладов начался с одного из организаторов = Damon Edwards, который рассказывал про то как вообще построить devops культуру в компании. Вся презентация очень классная, но я бы хотел выделить одну главную мысль. Хотите стать компанией, которая умеет грамотно поставлять продукт - сделайте так, чтобы вся команда понимала, как компания разрабатывает и зарабатывает. А так же теряет, факапит и прочее. Для этого вам в руки два полезных инструмента: Value Stream Map (в рамках которого нужно делать и timeline analysis, и waste analysis) и metrics toolchain (построение цепочки метрик от бизнеса до каждого конечного человека в компании). В конечном итоге, каждый должен понимать свою роль в том, как компания живет на рынке и зарабатывает прибыль. Эти вещи я каждый раз пытаюсь доносить, когда рассказываю про devops, в том числе и на тренинге по #devops. И каждый раз я точно слышу фразу, что «время наших программистов слишком дорогое, чтобы тратить на такие встречи — они должны писать код», «программист/тестировщик/админ не должен про это знать, нему не положено» и конечно же фраза про людей-ресурсов. Если вы относитесь к последней группе, то у меня для вас картинка.
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/771/327/125/7713271257424146c7a063d8cffd4354.jpg)
После Дэймона пришла очередь Toufic Boubez, который затронул такую важную вещь, как мониторинг и почему долгое время так активно использовался тег #monitoringsucks. Итак, вы поставили себе инструмент для мониторинга, взяли гайд и по нему все настроили. Появился ли у вас мониторинг? Хренушки! У вас появилась система, которая жрет кучу ресурсов и заставляет всех нервничать. Так вот, очень простая мысль доклада — если какая-то из метрик никогда не анализируется, ее нужно отправить в топку. Чтобы этого не происходило, все метрики надо привязывать в событиям в системе — деплоям, реконфигам, релизам новых фич и так далее. Не будете так делать — ваш мониторинг sucks! Вторая простая мысль — вместо того, чтобы слепо идти гайдлайнам, настройте в самом начале 1-2 метрики на то, что в системе болит — JVM, CPU, disc I/O и так далее. И будет вам счастье.
Потом последовал доклад товарищей из многоуважаемой мной компании Thoughtworks, от Scott Turnquest, который рассказал, что если ваш процесс разработки тупит и тормозит, то только его участники и могут его улучшить. Для этого они должны поднять свои задние точки, построить Value Stream Map, диаграмму Ишикавы или хотя бы 5 Whys, чтобы найти решения корневых проблем, которые, решения, потом надо просто взять и воплотить. Звучит как обычно просто, но по своем опыту знаю, что многие программисты трясутся от одной мысли, что они не будут кодить, а пойдут на митинг. Картинка в тему.
![](http://gold-blog.ru/wp-content/uploads/2012/09/motivation-artlebedev.jpg)
И последний из докладов от Antoni Batchelli, говорил о том, что мы, собственно живем в сложном мире. Но это нас не останавливает, и мы еще и делаем сложное (complex) ПО, ставим еще в более сложную инфраструктуру, а потом долго ноем, как со всем этим жить. То, о чем хотел в итоге сказать Энтони — антонимом complex является не easy, а simple. Что, конечно, выглядит как непереводимая игра слов. Простым языком все можно выразить так — прежде чем что-то сделать, что гарантированно будет complex, подумай о братьях меньших, а именно о тех, кто после тебя будет с этим работать и сделай так, чтобы это тем не менее было simple to use and understand. На самом деле, хочется еще разок переслушать/пересмотреть, потому что доклад был сложный, а во второй день информации и так было получено более чем прилично.
Теперь попробую резюмировать то, что витало в голове. Текущая ситуация в IT такова, что либо ты начинаешь поставлять нужный софт, который востребован клиентами, прикладывая для этого все усилия, либо тебя задушат конкуренты, причем не особо напрягаясь. Мысль от капитана очевидность, но вся суть в словосочетании «прикладывая для этого все усилия». Попробую раскрыть, что я имел под этим ввиду — недостаточно найти классную идею, умных разработчиков, пронырливого маркетолога и богатого инвестора. Это добра сейчас навалом. Ключевая идея в том, что все, точнее даже так, ВСЕ БЛЕ*ТЬ, должны работать прозрачно друг для друга и понимать, зачем они друг другу нужны. Далее. Как уже отметил Энтони, мы живем в удивительно сложном мире, в котором чтобы выжить нужно прикладывать немаленькие умственные усилия, а вот для этого нужно время, которое мы часто тратим на всякий bullshit как формальные процессы, бюрократию, войну между командами и так далее. Так вот, пора завязывать с этой ересью, иначе фирме капец, а вам нужно обновлять резюме. Отсюда на самом деле вытекает известная фраза — «В любой непонятной ситуации — эволюционируй». А именно: учи новые праткики, автоматизируй процессы, меняй культуру и так далее. Лень это делать — давай досвидания, тебя скоро попросят с этого рынка. Все это я бы хотел обсудить в коментах.
Для разрядки атмосферы — немного самых ярких твитов.
@jesserobbins
Don't fight stupid. Do more awesome. <- Word.#devopsdays #cloudops
@adrianco
Elephants cannot fly by flapping their ears harder -@jesserobbins #devopsdays
@jonathan_thorpe
«Value co-creation is a journey». Couldn't agree more. All aspects of a service no matter how insignificant it seems counts#devopsdays
@dberkholz
The new role of QA: thinking about overall user experience beyond the product. It's about providing a service. -@jeffsussna #devopsdays
@wickett
servers are like farm animals, it is just harder if you let the kids name them#devopsdays
@kylesj<
there is no other «why?» than the «Why?» of the business.#damonedwards #devopsdays . yup. cool stuff != delivering for the business
@writerferret
Never underestimate the power of a pen and paper. You dont always need fancy tech#DevOpsDays
@jondecamp
«When people do the things computers can do, all the computers get together late at night and laugh at us.»#devopsdays
@benzobot
«Don't be afraid to restructure or redesign when complexity gets in the way.» Wise words!#devopsdays
@vmwarecloudops
«We need to solve problems by looking at where they are less complex and build layers of abstraction.»#DevOpsDays
А теперь время обещанного бонуса — в сентября этого года в Москве (или Питере, до конца еще не решено) пройдет конференция DevOpsDays Russia. Ее организатором буду выступать, так что stay tuned!
О чем хочется сказать сразу — это была конференция, которую сделали инженеры, для инженеров и выступали на ней тоже только инженеры. Даже среди представителей вендорских тулов, как например OpsCode или PuppetLabs, не было зануд из маркетинга и отделов продаж. Именно поэтому к ним было адекватное отношение, с ними много и плотно общались, а не как обычно. По этой же причине не было расскрашенных бодиартом девочек и hr`ов в миниюбках. Все это создало действительно классную атмосферу тепловой ламповой конференции. К слову, на ней было около 300 человек, но это не мешало общаться с кем захочешь. Сплошной позитив в общем.
Отдельного хотелось бы рассказать про формат конференции: 1 зал, 4 доклада, 6 iginite talks по 10-15 минут и потом open-space. Из-за подобного формата все было очень динамично, все успели на все доклады, а самое главное — была возможность пообщаться по тем темам, которые на данный момент тебя действительно волнуют, а не слушать очередной доклад из разряда «какие мы молодцы», Таких, кстати, не было ни одного.
Так же хочется отметить действительно важную вещь — на инженерной конференции их 20 докладов и ignite talks всего 2 было посвящены инструментам. Во всех остальных речь шла про процессы, культуру, практики и людей. Приятная моему уху вещь — за два дня никто не назвал людей ресурсами. У нас бы так же!
Теперь собственно пробежимся по докладам. Программа доступна по этой ссылке, а доклады и видео через некоторое время будут выложены центролизовано, Но вернемся к докладам.
Начал конференцию Jesse Robbins - бывший пожарник, а по совместимости сооснователь компании Opscode. Джесси рассказывал про достаточно простую, но к сожалению не для всех очевидную вещь — переход к devops, это бизнес необходимость, а не желание инженеров получить приставку к своей должности. И если дело обстоит не так, вас ждут проблемы. В общем, Джесси рассказывал про трансформацию enterprise компаний с использованием ценностей agile и devops. И ключевая мысль его доклада о том, как крупные компании пытаются трансформироваться в современные и высокопроизводительные организации. Представим, что компания это слон, а цель трансформации — научиться летать. Так вот, многие компании пытаются начать махать своими слоновьими ушами, чтобы взлететь. Результат можно представить. Чтобы научиться летать нужны крылья, нужная энергия и место для взлета. Поэтому трансформация таких компаний в действительно что-то стоящее это долгий и сложный процесс в рамках которого нужно и крылья отрастить и лишнюю массу сбросить. Для меня этот доклад был ключевым во всей конференции, потому что отражал настоящую суть devops.
После Джесси слово перешло к Jeff Sussna, который рассказывал о том, о чем мало кто говорит — где же роль QA в devops. Если говорить в двух словах, то задача QA — вытащить голову, извините, из задницы и начать смотреть, а главное говорить всем, что они видят в приложении с точки зрения реального мира и реальных пользователей, работы приложения в боевой системе, а так же в работе бизнеса. По большому счету, все то же самое должен делать правильный QA и в Agile, в devops же ему еще положено разбираться в инфраструктуре и думать об автоматизации поставки, а не только своего уголка пионера, точнее функциональных тестов, В общем, от меня Джефу большой плюс в карму, потому что это еще один человек, который пытается разбудить спящих тестировщиков.
После перерыва микрофон в свои руки взял J.Paul Reed, который рассказал про организацию, которая делает 120 тыс поставок в день. Этой организацией является FAA - Federal Aviation Administration, Федеральное управление гражданской авиации, которая в день успешно завершает те самые 120 тыс перелетов внутри америки. Пол провел шикарную параллель между тем, что делает FAA и тем, как должен быть построен процесс разработки. При этом разработчики становятся пилотами, а operations — диспетчерами. Добавляем ряд практик, как например такую — если в системе наступает звездец, мы это честно признаем и разгребаем его, независимо от того, какие правила мы установили. И это общая задача всех членов команды. А чтобы звездец не объявляли слишком часто, мы делаем post-mortem. В докладе у Пола была классная визуализация того, как диспетчеры FedEx обработали ситуацию, когда всю Америку накрывал шторм, и как в этом время вели себя самолеты. Наглядность впечатляет. Ждем слайдов.
Четвертый доклад я в начале воспринял как маркетинговый буллшит, потому что в нем говорили про то, какую классную штуку придумали для того, чтобы девушки могли влиться в IT. Проект называется http://www.hackbrightacademy.com и он действительно крутой, но слушать об этом как то особо не хотелось, до тех пор пока не подняли такую тему как менторство и найм персонал в целом. И это была действительно классная тема и вот почему. Во многих компаниях остро стоит вопрос найма персонала, но при этом слабо задумываются о том, как людей встроить в имеющий процесс, а самое главное передать им тот же набор ценностей, который есть в команде. Так вот, решением данной проблемы является менторство, причем не формально — я ментор, окаааай, а полноценное, на которое выделяется время сотрудника. И важной составляющей является не просто обучение практикам, но так же и передача ценностей, настройка на нужный mindset. Таким образом люди действительно встраиваются в команды. И еще: «Speak to the „why“ of what your Jr. Engineers are doing so they know how to apply it in the future.» В общем, многим компаниям на заметку.
Про ignite talks я не буду подробно расписывать — дождитесь видео и посмотрите, там было реально крутые доклады. Мозг взрывался)
Второй день докладов начался с одного из организаторов = Damon Edwards, который рассказывал про то как вообще построить devops культуру в компании. Вся презентация очень классная, но я бы хотел выделить одну главную мысль. Хотите стать компанией, которая умеет грамотно поставлять продукт - сделайте так, чтобы вся команда понимала, как компания разрабатывает и зарабатывает. А так же теряет, факапит и прочее. Для этого вам в руки два полезных инструмента: Value Stream Map (в рамках которого нужно делать и timeline analysis, и waste analysis) и metrics toolchain (построение цепочки метрик от бизнеса до каждого конечного человека в компании). В конечном итоге, каждый должен понимать свою роль в том, как компания живет на рынке и зарабатывает прибыль. Эти вещи я каждый раз пытаюсь доносить, когда рассказываю про devops, в том числе и на тренинге по #devops. И каждый раз я точно слышу фразу, что «время наших программистов слишком дорогое, чтобы тратить на такие встречи — они должны писать код», «программист/тестировщик/админ не должен про это знать, нему не положено» и конечно же фраза про людей-ресурсов. Если вы относитесь к последней группе, то у меня для вас картинка.
![](https://habrastorage.org/getpro/habr/post_images/771/327/125/7713271257424146c7a063d8cffd4354.jpg)
После Дэймона пришла очередь Toufic Boubez, который затронул такую важную вещь, как мониторинг и почему долгое время так активно использовался тег #monitoringsucks. Итак, вы поставили себе инструмент для мониторинга, взяли гайд и по нему все настроили. Появился ли у вас мониторинг? Хренушки! У вас появилась система, которая жрет кучу ресурсов и заставляет всех нервничать. Так вот, очень простая мысль доклада — если какая-то из метрик никогда не анализируется, ее нужно отправить в топку. Чтобы этого не происходило, все метрики надо привязывать в событиям в системе — деплоям, реконфигам, релизам новых фич и так далее. Не будете так делать — ваш мониторинг sucks! Вторая простая мысль — вместо того, чтобы слепо идти гайдлайнам, настройте в самом начале 1-2 метрики на то, что в системе болит — JVM, CPU, disc I/O и так далее. И будет вам счастье.
Потом последовал доклад товарищей из многоуважаемой мной компании Thoughtworks, от Scott Turnquest, который рассказал, что если ваш процесс разработки тупит и тормозит, то только его участники и могут его улучшить. Для этого они должны поднять свои задние точки, построить Value Stream Map, диаграмму Ишикавы или хотя бы 5 Whys, чтобы найти решения корневых проблем, которые, решения, потом надо просто взять и воплотить. Звучит как обычно просто, но по своем опыту знаю, что многие программисты трясутся от одной мысли, что они не будут кодить, а пойдут на митинг. Картинка в тему.
![](http://gold-blog.ru/wp-content/uploads/2012/09/motivation-artlebedev.jpg)
И последний из докладов от Antoni Batchelli, говорил о том, что мы, собственно живем в сложном мире. Но это нас не останавливает, и мы еще и делаем сложное (complex) ПО, ставим еще в более сложную инфраструктуру, а потом долго ноем, как со всем этим жить. То, о чем хотел в итоге сказать Энтони — антонимом complex является не easy, а simple. Что, конечно, выглядит как непереводимая игра слов. Простым языком все можно выразить так — прежде чем что-то сделать, что гарантированно будет complex, подумай о братьях меньших, а именно о тех, кто после тебя будет с этим работать и сделай так, чтобы это тем не менее было simple to use and understand. На самом деле, хочется еще разок переслушать/пересмотреть, потому что доклад был сложный, а во второй день информации и так было получено более чем прилично.
Теперь попробую резюмировать то, что витало в голове. Текущая ситуация в IT такова, что либо ты начинаешь поставлять нужный софт, который востребован клиентами, прикладывая для этого все усилия, либо тебя задушат конкуренты, причем не особо напрягаясь. Мысль от капитана очевидность, но вся суть в словосочетании «прикладывая для этого все усилия». Попробую раскрыть, что я имел под этим ввиду — недостаточно найти классную идею, умных разработчиков, пронырливого маркетолога и богатого инвестора. Это добра сейчас навалом. Ключевая идея в том, что все, точнее даже так, ВСЕ БЛЕ*ТЬ, должны работать прозрачно друг для друга и понимать, зачем они друг другу нужны. Далее. Как уже отметил Энтони, мы живем в удивительно сложном мире, в котором чтобы выжить нужно прикладывать немаленькие умственные усилия, а вот для этого нужно время, которое мы часто тратим на всякий bullshit как формальные процессы, бюрократию, войну между командами и так далее. Так вот, пора завязывать с этой ересью, иначе фирме капец, а вам нужно обновлять резюме. Отсюда на самом деле вытекает известная фраза — «В любой непонятной ситуации — эволюционируй». А именно: учи новые праткики, автоматизируй процессы, меняй культуру и так далее. Лень это делать — давай досвидания, тебя скоро попросят с этого рынка. Все это я бы хотел обсудить в коментах.
Для разрядки атмосферы — немного самых ярких твитов.
Don't fight stupid. Do more awesome. <- Word.
Elephants cannot fly by flapping their ears harder -
«Value co-creation is a journey». Couldn't agree more. All aspects of a service no matter how insignificant it seems counts
The new role of QA: thinking about overall user experience beyond the product. It's about providing a service. -
servers are like farm animals, it is just harder if you let the kids name them
there is no other «why?» than the «Why?» of the business.
Never underestimate the power of a pen and paper. You dont always need fancy tech
«When people do the things computers can do, all the computers get together late at night and laugh at us.»
«Don't be afraid to restructure or redesign when complexity gets in the way.» Wise words!
«We need to solve problems by looking at where they are less complex and build layers of abstraction.»
А теперь время обещанного бонуса — в сентября этого года в Москве (или Питере, до конца еще не решено) пройдет конференция DevOpsDays Russia. Ее организатором буду выступать, так что stay tuned!