В организации конференций есть свои «dev» и «ops»: для успеха требуется и «разработать» программу из отличных докладов, и «выкатить её на прод». И с любой новой конференцией, как с любым новым софтовым продуктом, многое может пойти не так на обоих этапах. Мы впервые провели DevOops — что там происходило, и не получился ли «упс»? На Хабре уже появился отзыв одного из участников, а теперь мы публикуем свой текст.
Среди подстерегающих сложностей есть, например, такая. При выборе площадки для конференции надо исходить из количества зрителей, но если раньше такая конференция не проводилась, как спрогнозировать это количество? Не окажется ли реальный спрос гораздо ниже или выше, так что площадка останется почти пустой или будет трещать по швам? Похоже на вечную проблему стартапов «на какие нагрузки рассчитывать». Но в итоге какого-то фатального расхождения не возникло, и конференционные возможности «Crowne Plaza» подошли собравшимся сотням человек.
Зато в ходе конференции возникла другая проблема соответствия объёмов. И церемония открытия, и следовавший за ней кейноут Кори Куинна заняли меньше времени, чем изначально предполагалось — так что, когда Кори закончил говорить, по расписанию до конца его доклада оставалось ещё приличное время. Но это не так страшно, при желании получить от спикера больше можно переместиться с ним в дискуссионную зону и продолжить общение там. И Кори на недостаток интереса в этой зоне пожаловаться не мог:
Если «ops-часть» в случае с Кори Куином дала небольшой сбой, то с «dev» всё было иначе: само выступление получило отличные отзывы, и неоднократно вызывало в зале смех. Кори саркастично критиковал ситуацию, когда крупные компании рассказывают о своей инфраструктуре как единственно верной, а остальные смотрят им в рот. По его мнению, это похоже на карго-культ, когда люди видят «у них всё хорошо работает» и имитируют внешние признаки в расчёте на такой же успех, не учитывая внутреннюю разницу:
«Я видел, как спикер из Netflix сказал со сцены “мы даём всем разработчикам доступ в прод”. Все в зале впечатлились, и человек рядом со мной сказал: “Да, надо бы у нас тоже дать разработчикам доступ в прод”. Я посмотрел на его бейдж и увидел, что он работает в банке! Слушайте, надо же учитывать контекст. Во-первых, Netflix гордятся тем, что не берут джуниоров — конечно, им легче давать доступ, когда все опытные. Во-вторых, они платят выше рынка — а все хотят “чтобы было как у Netflix”, но почему-то не горят желанием платить выше рынка. В-третьих, при всех масштабах Netflix они просто стримят фильмы. Если у вас не запустится фильм, это будет не такой масштабной проблемой, как если произойдёт сбой в банке».
После кейноута действие расходилось по разным залам, и можно было видеть, как начинаются не просто разные темы, а разные подходы к понятию «девопс-доклад». Другие наши конференции, от Joker до Heisenbug, известны своей «хардкорностью»: в докладах техническая конкретика, а не «общая болтовня». Но с DevOps, как ранее заметил в интервью участник программного комитета Барух jbaruch Садогурский, всё сложнее. В этом случае «процессы», «люди» и всё остальное, что на Java-конференции выглядело бы «soft skills», оказывается важнейшими составляющими, и нельзя свести DevOps-проблематику только к возне с Docker. Какой в таком случае делать программу? Обычно мы уделяем много внимания отзывам о докладах, лучше понимая, что дать зрителям в следующий раз, но тут отзывов ещё не было, так что в этом отношении необходимо было рисковать. В итоге на DevOops присутствовали разные варианты — а какие из них больше подойдут зрителям, окончательно понять можно было только постфактум по отзывам.
Скажем, в первом же временном слоте можно было увидеть совершенно разные доклады: пока Эдриан Коул говорил о распределённой трассировке с помощью Zipkin, тот же Барух вместе с Леонидом Игольником рассказывал о том, каким должно быть правильное дежурство.
В первом случае была именно что техническая конкретика. Эдриан начал с того, как соотносятся понятия «tracing», «logging» и «metrics» (сославшись на наглядную диаграмму из чужого блог-поста), а позже перешёл непосредственно к Zipkin, и рассказав о нём теоретически, и продемонстрировав его использование на практике. Кажется, единственным сколько-нибудь отвлечённым fun fact в его выступлении было то, почему Zipkin так называется. Оказывается, когда Twitter регулярно падал и показывал так называемого «fail whale», Zipkin создали там для борьбы с этим, и использовали турецкое слово, означающее «гарпун» (то есть он должен был «помочь убить кита»).
А вот у Баруха с Леонидом выступление было совсем другим. Хотя ценность правильных инструментов работы с логами там была упомянута, чаще речь шла о вещах вроде escalation path: кого и при каких условиях должен дёргать сотрудник, когда его собственной компетенции для решения проблемы уже не хватает. Безусловно, это не про технологии, и, безусловно, в докладе было много шуток-прибауток (с Барухом было бы странно ждать другого) — но назвать это «общей болтовнёй» тоже нельзя, конкретики там хватало. Более того, какие-то вещи были одновременно смешными и жизненными: «Почему escalation path должен доходить до CEO компании? Во-первых, практика показывает, что если через 5-6 часов придётся будить начальника, то гораздо больше проблем успевают решиться за эти 5-6 часов!»
И что, какой из двух вариантов оказался интересен зрителям? Будете смеяться: разница в средневзвешенном значении зрительских оценок у этих двух докладов составила каких-то три сотых — можно считать это статистической погрешностью. И при этом оба они попали в топ-5 докладов конференции. С таким успехом очевидно, что зрителям интересно и то, и другое.
Впрочем, при всей разнице этих двух докладов у них есть кое-что общее: они оба про то, что можно непосредственно внедрить у себя в компании, будь то хоть технологический инструмент, хоть рабочий процесс. А существуют ещё доклады вида «здесь нет прямых инструкций по изменению вашего проекта, но это полезно знать» — было ли подобное здесь? Да: например, рассказ Олега m0nstermind Анастасьева о том, как Одноклассники перешли от разделения «каждый сервер отвечает только за одну задачу» к «частному облаку», когда несколько задач могут выполняться на одном сервере одновременно. Их решение one-cloud не в опенсорсе, так что у себя его не используешь — зато, следя за чужой логикой, лучше понимаешь принципы, общие для всех. Если одни задачи требуют минимального времени отклика, другим (условно «батчевым») требуется много ресурсов, а третьи («фоновые») могут ждать своей очереди, то как правильно разделить CPU-ресурсы между ними, и какие параметры запуска Docker помогут это сделать? А что делать с трафиком, где у Docker соответствующих параметров для разделения вообще нет?
Любопытен оказался ещё круглый стол «Как “продать” DevOps коллегам, начальству и прочим равнодушным». Казалось бы, в случае с обеими «техническими» сторонами — разработке и администрации — можно упирать на конкретные метрики, показывая ускорение time to market и других показателей. Но в диалоге участники круглого стола про обе эти стороны заметили, что там встречаются опасения, связанные с job security: администраторы боятся, что они станут не нужны, и их уволят, а разработчики — что они сломают продакшен, и их уволят. При этом люди могут не высказывать подобные страхи вслух, а просто отбрыкиваться от любых технических аргументов, пока страхи не будут развеяны. И получается, что для успешного построения DevOps понимать людей действительно не менее важно, чем понимать Kubernetes.
Но понимать Kubernetes, разумеется, тоже важно — про него было сразу несколько докладов, и выше всего зрители оценили выступление Николая Рыжикова. Вот там была сплошная техническая конкретика: «Есть ещё ряд ресурсов, например, ConfigMaps и Secrets — это чисто информационный ресурс, который вы можете замаунтить в ваш контейнер и передать туда, например, пароли от Postgres. Вы можете связать это с environmental variables, которые будут инжектиться в контейнеры, когда они запускаются, можете замаунтить это в файловую систему, всё удобно».
Наконец, завершал конференцию кейноут Баруха Садогурского и Леонида Игольника, стилизованный под «греческую трагедию» (вплоть до того, что на сцене стояли вазы, а спикеры были в тогах). На практике, впрочем, это была скорее комедия: над злоключениями воображаемой компании, сталкивающейся с разными DevOps-проблемами (от истории с left-pad до истории с GitLab), регулярно ржал весь зал. Здесь таких конкретных практических выводов, как у доклада про дежурство, уже не было, но от закрывающего выступления это и не требовалось. В итоге все остались в восторге, и «трагедия» возглавила хит-парад зрительских отзывов. Как замечали в отзывах, Барух всегда харизматичен, но с Леонидом у него вообще возникает синергия — это два отлично дополняющих друг друга спикера.
Что в итоге? Первое испытание продакшном, несмотря на отдельные небольшие сложности, в целом успешно пройдено. Но любой, имеющий отношение к девопсу, знает: выпустить единичный релиз — одно дело, а ты попробуй как следует выстроить Continuous Delivery с регулярными апдейтами. Что ж, попробуем: теперь, когда первый DevOops прошёл успешно, не миновать появления второго.
Автор: phillennium
