Конференция закончилась всего несколько часов назад, поэтому в голове еще небольшой сумбур от количества и качества полученной информации. Надеюсь, написав этот пост у меня получиться разобраться в собственных мыслях. Сначала будут общие впечатления, затем кратко пробегусь по докладам и закончу мыслями на тему того, о чем говорили на конференции, благо таких мыслей накопилось по ходу прилично. Хотите узнать, о чем сейчас говорят в мире 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. И каждый раз я точно слышу фразу, что «время наших программистов слишком дорогое, чтобы тратить на такие встречи — они должны писать код», «программист/тестировщик/админ не должен про это знать, нему не положено» и конечно же фраза про людей-ресурсов. Если вы относитесь к последней группе, то у меня для вас картинка.
После Дэймона пришла очередь Toufic Boubez, который затронул такую важную вещь, как мониторинг и почему долгое время так активно использовался тег #monitoringsucks. Итак, вы поставили себе инструмент для мониторинга, взяли гайд и по нему все настроили. Появился ли у вас мониторинг? Хренушки! У вас появилась система, которая жрет кучу ресурсов и заставляет всех нервничать. Так вот, очень простая мысль доклада — если какая-то из метрик никогда не анализируется, ее нужно отправить в топку. Чтобы этого не происходило, все метрики надо привязывать в событиям в системе — деплоям, реконфигам, релизам новых фич и так далее. Не будете так делать — ваш мониторинг sucks! Вторая простая мысль — вместо того, чтобы слепо идти гайдлайнам, настройте в самом начале 1-2 метрики на то, что в системе болит — JVM, CPU, disc I/O и так далее. И будет вам счастье.
Потом последовал доклад товарищей из многоуважаемой мной компании Thoughtworks, от Scott Turnquest, который рассказал, что если ваш процесс разработки тупит и тормозит, то только его участники и могут его улучшить. Для этого они должны поднять свои задние точки, построить Value Stream Map, диаграмму Ишикавы или хотя бы 5 Whys, чтобы найти решения корневых проблем, которые, решения, потом надо просто взять и воплотить. Звучит как обычно просто, но по своем опыту знаю, что многие программисты трясутся от одной мысли, что они не будут кодить, а пойдут на митинг. Картинка в тему.
И последний из докладов от 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!
Автор: mythmaker
