20.10.2017 я посетил конференцию DevOps в Питере и описал свои впечатления. Не рассчитывайте на хардкор, реальные примеры в духе «как внедрить DevOps в компании за 5 дней» или бесконечные осанны Docker, под катом их нет.
Организация была на высшем уровне: кофе-печенек хватило всем. Никаких очередей на регистрацию, указатели на видных местах. Нас обеспечили всем необходимым, даже попкорном. Доклады были распределены по трем залам, только первый и последний проходили в одном (первом) зале. Это важный момент, в первом акте станет ясно, почему я обратил на это внимание, пока просто запомните.
Сама конференция началась с доклада Corey Quinn про Netflix, Google и AWS. Доклад был на английском и по реакции зала на шутки было видно, что добрая половина людей вообще не понимает, про что речь. Это одна из немногих ошибок организаторов, не стоило делать первый доклад на английском без перевода. Сам доклад получился интересным, хотя в нем не было технических деталей, Кори объяснял общий подход.
Если кратко резюмировать, то Netflix это компания с классический DevOps, в ней разработчики имеют root на продакшен. Да, да, такие компании есть, и они благополучно работают. Тут нет никакой магии, просто денег у них столько, что они могу позволить себе нанимать на работу только лучших из лучших. У них в принципе нет junior.
Кори рассказал важную историю из ранних дней своей карьеры. Он был джуниором (а значит, работал не в Netflix), и в один прекрасный день допустил серьезную ошибку (факап — мне запретили использовать в статье). На следующий день, когда последствия устранили, его вызвал руководитель и у них состоялся диалог:
— Ты вчера сломал продакшен.
— Да, сломал, это моя ошибка. Я удалил очень важные данные.
— Ты понял, в чем была ошибка? Что сделано, чтобы подобного не повторялось?
— Да, ошибка была в… Сделано…
— Ок, иди работай.
Кори очень удивился, что его не уволили и даже не наказали. Для многих руководителей, по крайней мере в России, такая линия поведения выглядит странной. Они всегда ищут виноватого и наказывают его, хотя логичнее искать причины проблемы (факапа — мне запретили использовать в статье) и их устранять. Показательный пример — история с databaseremoval specialist и gitlab. Уволив виновного, вы потеряете специалиста, который только что получил ценнейший опыт, как делать не надо, и повысите текучку кадров. А проблема решена не будет, и рано или поздно повторится.
Еще одна важная мысль, которую высказал Кори, а потом повторили многие докладчики: «Docker, Docker, Docker». Сейчас есть «универсальное» решение любой проблемы, и это Docker. Его пихают везде, все на него переходят. Сама по себе технология хорошая, но хайп сделал ей антирекламу. Ее начали пихать во все дыры, а стоило бы сперва ответить на простой вопрос: «А нужен ли нам Docker?» Тут важно понимать, что нет плохих технологий, есть их неуместное использование. В современных IT это большая проблема.
Второй доклад я выбирал между k8s, How to properly blame things for causing latency и рассказом про организацию работы и дежурство. Без долгих раздумий я пошел на дежурства. Во-первых, эта тема близка нашей компании. Во-вторых, все коллеги пошли на первые два доклада. В третьих, материалов про технологии полно в сети.
Тут много написать не получится, надо смотреть доклад. У Баруха и Игольника мощная харизма и отличный стиль преподнесения информации. На примере дежурного джуниора Васи был рассмотрен пример обработки одного ночного инцидента. Все в лучших традициях, и логи в почту в вордовском файле, и паника, и отсутствие доступа к нужным серверам, и недовольный клиент. Классика. В реальности это большая проблема многих компаний, причем вместо решения вечно ищут виноватых.
Хотя зал был на половину пустой, и многие в процессе ушли, поднятая тема очень важна. К счастью, откровений не было, большая часть предложенного у нас уже реализована или на стадии внедрения.
Я выбирал был между «SmartMonitoring — мониторинг бизнес-логики в Одноклассниках», «Расширяем k8s» и «Managing multiple clouds FTW». Выбор пал на первый доклад, так среди направлений, которые я развиваю, есть мониторинг.
Выступал Сергей Шарапов. Его доклад мог бы стать hardcore, но… оставил неоднозначные впечатления.
В докладе шла речь про мониторинг в Однокласниках. Они написали свою систему, она умеет строить граф и выделять сервера, которые задел сбой. Она умеет искать аномалии, анализируя предыдущие данные. Все круто, но не хватило технических деталей. Еще не могу не отметить вопрос из зала:
— Почему вы сделали свой продукт, а не взяли за основу уже готовые?
— Потому что можем.
Акт пятый: Continuously delivering infrastructure to the cloud, круглый стол «Как „продать“ DevOps», Continuous Delivery в Windows среде.
Куда идти, было ясно сразу: конференция про Devops, значит, иду на круглый стол.
Было интересно. Несколько выводов:
1. Devops подход не освободит нас от работы, ее не станет меньше, а как бы наоборот. Но задачи выйдут на качественно иной уровень, станут сложнее и интереснее.
2. На данный момент все более четко прослеживается разделение Devops на два подхода, подход google, netflix, когда root в продакшене есть у dev. И все остальные. Второй подход — это не один человек, который может все, это повышение квалификации сотрудников, когда появляются dev с пониманием ops и ops с пониманием разработки. Это тесное взаимодействие и понимание общих проблем и запросов.
3. Сейчас бизнес развивается так стремительно, что единственный путь — это DevOps. Но у каждого этот путь свой, его всегда надо рассматривать в контексте.
Акт шестой: Troubleshooting & debugging production applications in Kubernetes, «История успеха или „Dev+DevOps+Ops“», «One-cloud: ОС уровня дата-центра в Одноклассниках».
Выбор пал на Troubleshooting & debugging, надо было хоть один доклад послушать про Kubernetes. Докладчики: Барух Садогурский, Ray Тsang.
Доклад был про JFrog и google cloud. Был рассмотрен пример неудачного релиза и hot fix на лету для JavaScript. Что-то выделить сложно, было просто любопытно.
Вели ее Барух Садогурский, Леонид Игольник. Ну что сказать, круто. Началось с докладчиков в греческих тогах и пивом. Преподнесено все было в свойственной им манере, с юмором, отличными картинками и gif-ками. Рассказывали они про развитие стартапа от трех человек до крупной компании. Про проблемы с которыми приходилось сталкиваться компании на каждом этапе развития.
Это доклад, по моему мнению, подвел логическую черту. Он показал, что важно, выбирать правильные технологии в каждый момент развития. Что нет плохих технологий, что есть их неуместное использование. Что DevOps — это не набор определенных правил, которые можно применить, и все станет круто. Что это определенный подход, нам надо изменить свой подход к работе, вот тогда станет круто.
Конференция DevOps удалась. Мне хочется сюда вернуться.
PS: В перерывах многие участники жаловались, что мало hardcore и реальных кейсов. На мой взгляд, их там и не должно было быть. Это конференция не про то. Она про подход к работе, к разработке продуктов и про то, что Devops — это не волшебная пилюля, а набор технологий и методологий, которые при правильном использовании позволят бизнесу соответствовать современным требованиям. Многие к этому не готовы, они стремятся использовать новые технологии, не поняв, надо ли им это. Не важно, ты junior или senior, конференция была полезна для всех. Ведь даже junior может прийти к руководству с предложением по улучшению работы компании, и если у него есть хорошее обоснование, к нему прислушаются. А если вас даже не выслушали, то бегите из такой компании, в ней никогда не будет DevOps, ее потолок — это Docker :)
PSS: Как вы заметили, в тексте часто встречается Docker. Просто Барух сказал, что это ход с козыря, чем больше упоминаний Docker, тем круче статья.
UPD: тут можно почитать «как это было» с точки зрения организаторов: habrahabr.ru/post/341020
Спасибо организаторам, докладчикам и всем причастным!
Организация была на высшем уровне: кофе-печенек хватило всем. Никаких очередей на регистрацию, указатели на видных местах. Нас обеспечили всем необходимым, даже попкорном. Доклады были распределены по трем залам, только первый и последний проходили в одном (первом) зале. Это важный момент, в первом акте станет ясно, почему я обратил на это внимание, пока просто запомните.
Акт первый: Corey Quinn, Docker и root в продакшен
Сама конференция началась с доклада Corey Quinn про Netflix, Google и AWS. Доклад был на английском и по реакции зала на шутки было видно, что добрая половина людей вообще не понимает, про что речь. Это одна из немногих ошибок организаторов, не стоило делать первый доклад на английском без перевода. Сам доклад получился интересным, хотя в нем не было технических деталей, Кори объяснял общий подход.
Если кратко резюмировать, то Netflix это компания с классический DevOps, в ней разработчики имеют root на продакшен. Да, да, такие компании есть, и они благополучно работают. Тут нет никакой магии, просто денег у них столько, что они могу позволить себе нанимать на работу только лучших из лучших. У них в принципе нет junior.
Кори рассказал важную историю из ранних дней своей карьеры. Он был джуниором (а значит, работал не в Netflix), и в один прекрасный день допустил серьезную ошибку (факап — мне запретили использовать в статье). На следующий день, когда последствия устранили, его вызвал руководитель и у них состоялся диалог:
— Ты вчера сломал продакшен.
— Да, сломал, это моя ошибка. Я удалил очень важные данные.
— Ты понял, в чем была ошибка? Что сделано, чтобы подобного не повторялось?
— Да, ошибка была в… Сделано…
— Ок, иди работай.
Кори очень удивился, что его не уволили и даже не наказали. Для многих руководителей, по крайней мере в России, такая линия поведения выглядит странной. Они всегда ищут виноватого и наказывают его, хотя логичнее искать причины проблемы (факапа — мне запретили использовать в статье) и их устранять. Показательный пример — история с databaseremoval specialist и gitlab. Уволив виновного, вы потеряете специалиста, который только что получил ценнейший опыт, как делать не надо, и повысите текучку кадров. А проблема решена не будет, и рано или поздно повторится.
Еще одна важная мысль, которую высказал Кори, а потом повторили многие докладчики: «Docker, Docker, Docker». Сейчас есть «универсальное» решение любой проблемы, и это Docker. Его пихают везде, все на него переходят. Сама по себе технология хорошая, но хайп сделал ей антирекламу. Ее начали пихать во все дыры, а стоило бы сперва ответить на простой вопрос: «А нужен ли нам Docker?» Тут важно понимать, что нет плохих технологий, есть их неуместное использование. В современных IT это большая проблема.
Акт второй: Барух Садогурский, Леонид Игольник и дежурный Вася
Второй доклад я выбирал между k8s, How to properly blame things for causing latency и рассказом про организацию работы и дежурство. Без долгих раздумий я пошел на дежурства. Во-первых, эта тема близка нашей компании. Во-вторых, все коллеги пошли на первые два доклада. В третьих, материалов про технологии полно в сети.
Тут много написать не получится, надо смотреть доклад. У Баруха и Игольника мощная харизма и отличный стиль преподнесения информации. На примере дежурного джуниора Васи был рассмотрен пример обработки одного ночного инцидента. Все в лучших традициях, и логи в почту в вордовском файле, и паника, и отсутствие доступа к нужным серверам, и недовольный клиент. Классика. В реальности это большая проблема многих компаний, причем вместо решения вечно ищут виноватых.
Хотя зал был на половину пустой, и многие в процессе ушли, поднятая тема очень важна. К счастью, откровений не было, большая часть предложенного у нас уже реализована или на стадии внедрения.
Акт третий: мониторинг
Я выбирал был между «SmartMonitoring — мониторинг бизнес-логики в Одноклассниках», «Расширяем k8s» и «Managing multiple clouds FTW». Выбор пал на первый доклад, так среди направлений, которые я развиваю, есть мониторинг.
Выступал Сергей Шарапов. Его доклад мог бы стать hardcore, но… оставил неоднозначные впечатления.
В докладе шла речь про мониторинг в Однокласниках. Они написали свою систему, она умеет строить граф и выделять сервера, которые задел сбой. Она умеет искать аномалии, анализируя предыдущие данные. Все круто, но не хватило технических деталей. Еще не могу не отметить вопрос из зала:
— Почему вы сделали свой продукт, а не взяли за основу уже готовые?
— Потому что можем.
Акт четвертый ничем не запомнился, поэтому его опустим.
Акт пятый: Continuously delivering infrastructure to the cloud, круглый стол «Как „продать“ DevOps», Continuous Delivery в Windows среде.
Куда идти, было ясно сразу: конференция про Devops, значит, иду на круглый стол.
Было интересно. Несколько выводов:
1. Devops подход не освободит нас от работы, ее не станет меньше, а как бы наоборот. Но задачи выйдут на качественно иной уровень, станут сложнее и интереснее.
2. На данный момент все более четко прослеживается разделение Devops на два подхода, подход google, netflix, когда root в продакшене есть у dev. И все остальные. Второй подход — это не один человек, который может все, это повышение квалификации сотрудников, когда появляются dev с пониманием ops и ops с пониманием разработки. Это тесное взаимодействие и понимание общих проблем и запросов.
3. Сейчас бизнес развивается так стремительно, что единственный путь — это DevOps. Но у каждого этот путь свой, его всегда надо рассматривать в контексте.
Акт шестой: Troubleshooting & debugging production applications in Kubernetes, «История успеха или „Dev+DevOps+Ops“», «One-cloud: ОС уровня дата-центра в Одноклассниках».
Выбор пал на Troubleshooting & debugging, надо было хоть один доклад послушать про Kubernetes. Докладчики: Барух Садогурский, Ray Тsang.
Доклад был про JFrog и google cloud. Был рассмотрен пример неудачного релиза и hot fix на лету для JavaScript. Что-то выделить сложно, было просто любопытно.
Кульминацией был «DevOps в масштабе: греческая трагедия в трёх актах».
Вели ее Барух Садогурский, Леонид Игольник. Ну что сказать, круто. Началось с докладчиков в греческих тогах и пивом. Преподнесено все было в свойственной им манере, с юмором, отличными картинками и gif-ками. Рассказывали они про развитие стартапа от трех человек до крупной компании. Про проблемы с которыми приходилось сталкиваться компании на каждом этапе развития.
Это доклад, по моему мнению, подвел логическую черту. Он показал, что важно, выбирать правильные технологии в каждый момент развития. Что нет плохих технологий, что есть их неуместное использование. Что DevOps — это не набор определенных правил, которые можно применить, и все станет круто. Что это определенный подход, нам надо изменить свой подход к работе, вот тогда станет круто.
Эпилог
Конференция DevOps удалась. Мне хочется сюда вернуться.
PS: В перерывах многие участники жаловались, что мало hardcore и реальных кейсов. На мой взгляд, их там и не должно было быть. Это конференция не про то. Она про подход к работе, к разработке продуктов и про то, что Devops — это не волшебная пилюля, а набор технологий и методологий, которые при правильном использовании позволят бизнесу соответствовать современным требованиям. Многие к этому не готовы, они стремятся использовать новые технологии, не поняв, надо ли им это. Не важно, ты junior или senior, конференция была полезна для всех. Ведь даже junior может прийти к руководству с предложением по улучшению работы компании, и если у него есть хорошее обоснование, к нему прислушаются. А если вас даже не выслушали, то бегите из такой компании, в ней никогда не будет DevOps, ее потолок — это Docker :)
PSS: Как вы заметили, в тексте часто встречается Docker. Просто Барух сказал, что это ход с козыря, чем больше упоминаний Docker, тем круче статья.
UPD: тут можно почитать «как это было» с точки зрения организаторов: habrahabr.ru/post/341020
Спасибо организаторам, докладчикам и всем причастным!