Отношение к конференциям в ИТ-среде неоднозначно: одни в кипящей атмосфере собраний чувствуют себя как рыба в воде, других скорее раздражает, поскольку ничего путного или нового для работы не услышишь.
И все же конференции – полезны, а участие в них позволяет обмениваться знаниями и узнавать, чем дышит и в какую сторону двигается отрасль. А если конференция проходит в другом городе или стране, это еще и прекрасный повод посмотреть мир. Главное, чтобы участие не превратилось в «академический туризм», спонсируемый работодателем.
Об истории и культуре процесса мы рассказывали в прошлых статьях, а сегодня под катом мой рассказ о том, как одна поездка может изменить мировоззрение или, по крайней мере, оставить след в душе DevOps пионера.
Будучи разработчиком приложений к моменту поездки у меня был опыт пилотного внедрения DevOps практик в проектах, и я понимал, какие процессы построены хорошо, а какие хотелось бы улучшить.
Наверняка вы спросите, почему я решился на публикацию, когда с даты поездки прошло несколько месяцев: ниже рассказ не о туристических приключения и экскурсиях в Мюнхене, а то, что получилось в сухом остатке. Для того чтобы улеглось и опробовалось, нужно время.
Аэропорт, Мюнхен, Конференция
Мюнхен – ИТ-столица Германии, это обусловлено тем, что в городе сосредоточено большое количество ИТ-компаний. Город встречал тишиной, и предстоящая конференция DevOpsCon 2017, в программе которой было заявлено более 45 докладов, внушала радостные ожидания живого общения с лидерами движения.
Первый день моего участия в конференции открыл Russel Miles с темой «Better software development systems through stress». Спич был своего рода приветствием для собравшихся инженеров, настроенных скептически, у которых преобладали мысли о том, что «Devops — это игрушки, а в реальной разработке все несколько сложнее».
Харизматичный Russel с нестандартным подходом смог завлечь скептиков, сыграв на гитаре и исполнив песню, умело преподнося информацию и вставляя в презентацию отчасти шутливые тезисы, например «Production hates you!» «Failure is EVERYWHERE!», наиболее ценным для меня были практические советы о разработке и внедрении приложений в условиях хаоса, не получая при этом неожиданных проблем и критичных ошибок. Утопично, но мне очень понравилось.
Russel Miles на одном из своих выступлений, Брейк с нетворкингом
Лавируя между залами, я задержался на выступлении Roland Huss, инженера-программиста Red Hat, работающего на fabric8, платформе микросервисов для Kubernetes и OpenShift. Тема его выступления звучала так: «Become a Cloud-native: Java development in the age of the whale». Я зацепил несколько интересных подходов, которые позволяют сделать переход от традиционной Java — разработки к микросервисной с использованием kubernetes менее болезненным или даже безболезненным. Роланд рассказывал про основные выбранные инструменты создания окружения: docker, kubernetes, fabric8, как это все между собой взаимодействует, а также как собрать мини-кластер, чтобы попрактиковаться в работе с микросервисами и созданием инфраструктуры. Выступление получилось занимательным: сначала он рассказал про основы, а потом на наших глазах написал простенькое приложение, создал docker-образ, настроил окружение и развернул написанное приложение.
Хочу привести несколько тезисов из спича Andre Neubauer и Thomas Uebel, которые выступали с темой: «Implementing DevOps strategies in DevOps averse environment». По мне эти простые, но важные положения для осознания и восприятия проблем внедрения и DevOps:
• попытка выделить или нанять человека-devops, который решит проблемы всех и вся;
• желание автоматизировать все и вся;
• желание лишь автоматизировать;
• попытка передать компетенцию operation разработке и отказаться от первых
Озвученный спикерами тезис для меня очень близок, для них DevOps — это в первую очередь отличный от привычного всем образ мышления, короткий цикл получения обратной связи благодаря малым итеративным инкремента, а также «следующий логический шаг в большом путешествии под названием „Agile“. Всё по сути.
На конференции было много стендов таких компаний, как Atlassian, Appdynamics, Cyberark и другие. Большинство из них предоставляют услуги и средства для создания платформы, организации инфраструктуры, мониторинга сети и прочие, но есть представители компаний, которые помогают при трансформации и переходе к более эффективной разработке. Больше всего меня заинтересовали ребята из Appdynamics, которые продемонстрировали собственную разработку — систему мониторинга комплекса приложений. Мы воспроизвели негативный кейс в их приложении, неучтенный разработчиками, а потом смогли отследить, по каким узлам „гулял“ наш запрос, сколько времени он обрабатывался и на какой строке кода в каком классе произошел NullPointerException. Очень полезная штука! Я в работе сталкивался с задачами обнаружения дефекта: один и тот же сценарий, набор экранных форм может разрабатываться несколькими командами. Вот тогда-то такая система мне бы очень пригодилась для мониторинга.
Коллеги из AppDynamics
Отдельно стоит остановиться на компании Atlassian, продуктами которой пользуются многие крупные клиенты во всем мире. В моей практике-Confluence и Jira, которые помогают синхронизировать работу команд. Это единое информационное поле, где хранится вся база знаний о правилах и технологиях работы, участниках и продуктах. Мы используем эту площадку для обсуждения вводимых изменений, сбора идей и публикации новостей.
В Confluence есть набор инструментов, которые являются хорошим подспорьем в DevOps – процессах:
Выступление Christian Koch „Deployment pipelines in the enterprise“ было особенно полезно тем, кто работает с большим энтерпрайзом. Christian выделил основные проблемы, с которыми сталкиваются крупные компании при попытке ускорить доставку новых фич в промышленную среду, а потом показал, как можно добиться цели. Один из основных способов — создать такое рабочее окружение, при котором будет достаточно высокий уровень автоматизации — тестов, сборок, анализа. Это позволит не тратить время на ручной труд, но при этом вовремя „снять с конвейера“ сборку с багом или нерабочую конфигурацию. Таким образом, каждой компании осталось лишь определить свой набор инструментов, который поможет обеспечить быструю доставку рабочих сборок и при этом не позволит ничего сломать.
Именно таким Christian видит абстрактный набор инструментов, который позволит ускорить частоту релизов
Ключевая ценность любой конференции – это возможности нетворкинга. Я воспользовался случаем, чтобы прояснить для себя несколько моментов, над которыми задумывался уже давно. Например, узнать, могут ли представители компаний, которые уже давно занимаются автоматизацией и работают по гибким методологиям, смело сказать, что они „в DevOps“ или „в Agile“? Как и ожидалось, ни один из моих собеседников не осмелился так сказать. Везде были некие „но“ или „если“, а некоторые сказали, что они только думают о том, как измерить, насколько они devops&agile. Весь оставшийся вечер мы говорили об оптимизации, автоматизации и прочих сторонах „применения здравого смысла к инженерии“. Именно такое сочетание я не раз услышал от собеседников, пока мы пытались выяснить, что же такое DevOps и Agile. Но особенно меня удивил инженер, который провел аналогию между девопс и брожением пива.
Как по-вашему в этих совершенно несвязанных процессах есть что-то общее?
Кстати, тема agile&devops была актуальна – ее продолжил Ovidiu Pitic- глава Agile практик в Европе в компании Cognizant в своем выступлении „Fueling Digital Transformation with DevOps“.
Признаюсь, это выступление понравилось больше остальных: импонирует, когда в компании при принятии любого серьезного решения, от мала до велика, каждый сотрудник руководствовался честными, базовыми принципами Agile. Это не выглядит, как „поклонение“ или „возвышение“ Agile, это скорее похоже на то, что они „приняли“ эти правила и принципы, и каждый для себя определил, почему он им следует.
Когда первые восторги чуть-чуть улеглись, появилась тяга к неспешному размышлению, смакованию новых идей и полученной информации. В этом плане, формат доклада Philipp Garbe на тему „is Platform Engineering is the new Ops?“ был очень удачен.
Выступление он начал с цитаты:
Philipp рассказал, как сначала отошли от разделенных команд разработки и тестирования, потом выделили DevOps инженеров, с какими проблемами столкнулись и как пришли к организации инженерных команд, полностью отвечающих как за разработку, так и за эксплуатацию приложений. Основной посыл выступления, как я для себя уяснил, — это выделение двух типов инженерных команд: platform и product. Первые обеспечивают функциональное и надежное окружение, чтобы вторые могли быстро и безопасно доставлять новые фичи до пользователей, получать структурированную обратную связь. Мне кажется, такой подход имеет смысл, особенно, если под приложением подразумевается целый комплекс ПО, а сложность системного окружения достаточно высока.
Выступление Michiel Rook, консультанта Java, PHP, Scala из Нидерландов, с докладом „Database Schema Migrations with Zero Downtime“, для меня было немного скучным. Спикер с энтузиазмом и на глазах у изумленной публики подтвердил догадки о том, что с миграциями баз данных все просто, если вы не используете базы данных. Это выступление не было колоссальным открытием, поскольку мы не используем схему обновления БД, указанную ниже.
Michiel описал ряд правил, прибегая к которым можно уменьшить время простоя при миграциях БД. Например, использование балансировщика нагрузки, чтобы была возможность отключать один из узлов, на котором установлено приложение для установки обновлений.
Также он упомянул, что для облегчения работы с базами данных и уменьшения ошибок хорошо было бы:
1) „разорвать связь“ между миграцией БД и развертыванием ПО;
2) поддерживать обратную совместимость и только расширять контракты взаимодействия;
3) отказаться от деструктивных изменений;
4) использовать feature toggle при работе с данными. Например, для удаления старых, замененных новыми полей таблиц.
Ну что ж, всегда есть, чему поучиться.
А вот выступление Tony Grout из Atlassian на тему „DevOps teams and the future backward“, было занятным. В своем выступлении он акцентировал внимание на том, как принцип „открытости“ помогает командам достигать целей, при этом не допуская ошибок и не упуская деталей. Он продемонстрировал, как команды могут принимать решения, экспериментировать, пробовать и учиться, и как такой подход повышает отдачу команд. Также мы обсудили проблемы крупных корпораций работе с командами: отсутствие возможности работать удаленно из-за ограничений безопасности, медленное развитие команд из-за отсутствия культуры сотрудничества между разными подразделениями. Тони, как мне кажется, убежден, что сегодня нет никаких ограничений для удаленной работы сотрудников и для организации межкомандного обучения, то есть создания „культуры сотрудничества“, так как есть огромное число технических утилит для эффективного взаимодействия команд.
Основные принципы подхода:
Под конец выступления Тони произнес фразу, которая меня вдохновила: „Be the change you seek“.
Изначально я считал, что DevOps — это про автоматизацию, скрипты. Достаточно распространенное заблуждение, как я потом узнал и понял, погружаясь в процесс и в среду все глубже: DevOps подразумевает не только определенный технический склад, но и психологический, он тесно связан с гибкими методологиями разработки. Участие на этой конференциии позволило мне разобраться и выстроить знания в моей голове в цельную картину.
Кейсы, инсайты и нетворкинг возбуждают пытливый ум и, возможно даже, провоцируют внутреннего философа – DevOps это образ мышления каждого участника: от бизнеса и стейкхолдеров до внедренцев. Нельзя это просто взять и привнести в компанию, наняв определенного вида инженеров, руководителей или трансформаторов. Devops идет рука об руку с Agile. Это то, что надо взращивать, прививать, долго и упорно экспериментируя. Способ мышления стоит менять не только в части разработки ПО, но и в части взаимодействия с клиентами, получения обратной связи, снятия метрик.
Конечно, без инженерной культуры далеко не продвинешься: пока одни ребята будут неустанно находить дефекты и изъяны, чинить их, другие будут плодить новую функциональность, не особо беспокоясь о том, оптимально ли написаны их методы и правильно ли они обработают негативные кейсы при прохождении тестирования, ни о каких малых итерационных циклах не может быть и речи. Не стоит забывать и про автоматизацию, высокий уровень которой позволит значительно сократить время на вывод нового функционала в продакшен, а это, наверно, одно из слабых мест многих компаний сегодня.
В замечательной книге The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win описывается подход „три пути“. Первый путь призывает акцентировать внимание на производительности цельной системы, а не отдельных ее составляющих. Следование второму пути означает выстраивание короткого цикла обратной связи, который позволит услышать и понять всех клиентов системы и верно среагировать на их отзывы. Третий путь заключается в создании культуры экспериментов и оттачивания мастерства. Когда мы будем пробовать что-то новое, это потребует принятия определенных рисков и неудач, зато позволит нам развиваться и становиться лучше, а в следующий раз, попав в неприятную ситуацию, мы точно будем знать, как из нее выйти.
Мне кажется, эти три принципа лучше всего описывают культуру DevOps, к которой мы все стремимся, однако, некоторые принципы банковской системы, текущая их организация и мировоззрение некоторых людей не позволяют в нужной мере следовать этим принципам. Я думаю, дело также в том, что DevOps — относительно молодое направление, из-за этого у людей встречается скептическое отношение, а порой, при попытке применить эту методологию, вопросов бывает больше чем ответов
Мне нравится подход компании cognizant, которые действительно „гибко“ подошли к делу, но в то же время не потеряли в „качестве“: DevOps для них — это не сама цель и даже не инструмент для решения определенных задач, скорее это некий путь, проходя по которому они смогут постоянно развиваться и предоставлять пользователям лучшие продукты.
Devops — это своеобразная практика обучения и экспериментов, где что-то новое всегда приветствуется. Без ошибок никуда, но в данном случае ошибки — это то, что движет вперёд, они не должны пугать, деморализовывать, на них стоит учиться и делать выводы. После конференции я развернул свой подход на 90 градусов, поскольку убедился, что в таких делах, как трансформация компании, будь то внедрение devops или переход на гибкие методологии разработки, требуется участие всех участников процесса: от команд разработки до высшего руководства. Тут как раз и возникает большинство проблем, поскольку людям не хочется меняться и что-то менять в работе. В команде я стал чаще прислушиваться, как другие участники отзываются о нашем процессе, как происходит их взаимодействие с другими командами и администраторами стендов. В идеале мне бы хотелось видеть некую сквозную команду, участники которой будут вместе придумывать решения проблем, делиться опытом и подкидывать друг другу идеи на регулярной основе, но это уже совсем другая история.
А как вы считаете, нужно ли вообще ездить на конференции или продуктивнее сосредоточиться в офисе на своей работе?
И все же конференции – полезны, а участие в них позволяет обмениваться знаниями и узнавать, чем дышит и в какую сторону двигается отрасль. А если конференция проходит в другом городе или стране, это еще и прекрасный повод посмотреть мир. Главное, чтобы участие не превратилось в «академический туризм», спонсируемый работодателем.
Об истории и культуре процесса мы рассказывали в прошлых статьях, а сегодня под катом мой рассказ о том, как одна поездка может изменить мировоззрение или, по крайней мере, оставить след в душе DevOps пионера.
Собираясь в дорогу
Будучи разработчиком приложений к моменту поездки у меня был опыт пилотного внедрения DevOps практик в проектах, и я понимал, какие процессы построены хорошо, а какие хотелось бы улучшить.
Наверняка вы спросите, почему я решился на публикацию, когда с даты поездки прошло несколько месяцев: ниже рассказ не о туристических приключения и экскурсиях в Мюнхене, а то, что получилось в сухом остатке. Для того чтобы улеглось и опробовалось, нужно время.
Аэропорт, Мюнхен, Конференция
Мюнхен – ИТ-столица Германии, это обусловлено тем, что в городе сосредоточено большое количество ИТ-компаний. Город встречал тишиной, и предстоящая конференция DevOpsCon 2017, в программе которой было заявлено более 45 докладов, внушала радостные ожидания живого общения с лидерами движения.
День первый
Первый день моего участия в конференции открыл Russel Miles с темой «Better software development systems through stress». Спич был своего рода приветствием для собравшихся инженеров, настроенных скептически, у которых преобладали мысли о том, что «Devops — это игрушки, а в реальной разработке все несколько сложнее».
Харизматичный Russel с нестандартным подходом смог завлечь скептиков, сыграв на гитаре и исполнив песню, умело преподнося информацию и вставляя в презентацию отчасти шутливые тезисы, например «Production hates you!» «Failure is EVERYWHERE!», наиболее ценным для меня были практические советы о разработке и внедрении приложений в условиях хаоса, не получая при этом неожиданных проблем и критичных ошибок. Утопично, но мне очень понравилось.
Russel Miles на одном из своих выступлений, Брейк с нетворкингом
Лавируя между залами, я задержался на выступлении Roland Huss, инженера-программиста Red Hat, работающего на fabric8, платформе микросервисов для Kubernetes и OpenShift. Тема его выступления звучала так: «Become a Cloud-native: Java development in the age of the whale». Я зацепил несколько интересных подходов, которые позволяют сделать переход от традиционной Java — разработки к микросервисной с использованием kubernetes менее болезненным или даже безболезненным. Роланд рассказывал про основные выбранные инструменты создания окружения: docker, kubernetes, fabric8, как это все между собой взаимодействует, а также как собрать мини-кластер, чтобы попрактиковаться в работе с микросервисами и созданием инфраструктуры. Выступление получилось занимательным: сначала он рассказал про основы, а потом на наших глазах написал простенькое приложение, создал docker-образ, настроил окружение и развернул написанное приложение.
Хочу привести несколько тезисов из спича Andre Neubauer и Thomas Uebel, которые выступали с темой: «Implementing DevOps strategies in DevOps averse environment». По мне эти простые, но важные положения для осознания и восприятия проблем внедрения и DevOps:
• попытка выделить или нанять человека-devops, который решит проблемы всех и вся;
• желание автоматизировать все и вся;
• желание лишь автоматизировать;
• попытка передать компетенцию operation разработке и отказаться от первых
Озвученный спикерами тезис для меня очень близок, для них DevOps — это в первую очередь отличный от привычного всем образ мышления, короткий цикл получения обратной связи благодаря малым итеративным инкремента, а также «следующий логический шаг в большом путешествии под названием „Agile“. Всё по сути.
На конференции было много стендов таких компаний, как Atlassian, Appdynamics, Cyberark и другие. Большинство из них предоставляют услуги и средства для создания платформы, организации инфраструктуры, мониторинга сети и прочие, но есть представители компаний, которые помогают при трансформации и переходе к более эффективной разработке. Больше всего меня заинтересовали ребята из Appdynamics, которые продемонстрировали собственную разработку — систему мониторинга комплекса приложений. Мы воспроизвели негативный кейс в их приложении, неучтенный разработчиками, а потом смогли отследить, по каким узлам „гулял“ наш запрос, сколько времени он обрабатывался и на какой строке кода в каком классе произошел NullPointerException. Очень полезная штука! Я в работе сталкивался с задачами обнаружения дефекта: один и тот же сценарий, набор экранных форм может разрабатываться несколькими командами. Вот тогда-то такая система мне бы очень пригодилась для мониторинга.
Коллеги из AppDynamics
Отдельно стоит остановиться на компании Atlassian, продуктами которой пользуются многие крупные клиенты во всем мире. В моей практике-Confluence и Jira, которые помогают синхронизировать работу команд. Это единое информационное поле, где хранится вся база знаний о правилах и технологиях работы, участниках и продуктах. Мы используем эту площадку для обсуждения вводимых изменений, сбора идей и публикации новостей.
В Confluence есть набор инструментов, которые являются хорошим подспорьем в DevOps – процессах:
- Постеры проекта, которые позволяют „видеть лес за деревьями“ или другими словами дают целостное и однозначное представление для всех глобального замысла;
- Инструменты планирования, с помощью которых возможно создать дорожную карту проекта, отслеживать статусы и сроки выполнения;
- Страницы ретроспективы и анализа инцидентов;
- Функциональности мониторинга, особенно актуальные в пилотах и экспериментах;
- Многочисленные возможности для wiki, публикации новостей и ведения блогов.
Выступление Christian Koch „Deployment pipelines in the enterprise“ было особенно полезно тем, кто работает с большим энтерпрайзом. Christian выделил основные проблемы, с которыми сталкиваются крупные компании при попытке ускорить доставку новых фич в промышленную среду, а потом показал, как можно добиться цели. Один из основных способов — создать такое рабочее окружение, при котором будет достаточно высокий уровень автоматизации — тестов, сборок, анализа. Это позволит не тратить время на ручной труд, но при этом вовремя „снять с конвейера“ сборку с багом или нерабочую конфигурацию. Таким образом, каждой компании осталось лишь определить свой набор инструментов, который поможет обеспечить быструю доставку рабочих сборок и при этом не позволит ничего сломать.
Именно таким Christian видит абстрактный набор инструментов, который позволит ускорить частоту релизов
Drinks, talks and casino
Ключевая ценность любой конференции – это возможности нетворкинга. Я воспользовался случаем, чтобы прояснить для себя несколько моментов, над которыми задумывался уже давно. Например, узнать, могут ли представители компаний, которые уже давно занимаются автоматизацией и работают по гибким методологиям, смело сказать, что они „в DevOps“ или „в Agile“? Как и ожидалось, ни один из моих собеседников не осмелился так сказать. Везде были некие „но“ или „если“, а некоторые сказали, что они только думают о том, как измерить, насколько они devops&agile. Весь оставшийся вечер мы говорили об оптимизации, автоматизации и прочих сторонах „применения здравого смысла к инженерии“. Именно такое сочетание я не раз услышал от собеседников, пока мы пытались выяснить, что же такое DevOps и Agile. Но особенно меня удивил инженер, который провел аналогию между девопс и брожением пива.
Как по-вашему в этих совершенно несвязанных процессах есть что-то общее?
Кстати, тема agile&devops была актуальна – ее продолжил Ovidiu Pitic- глава Agile практик в Европе в компании Cognizant в своем выступлении „Fueling Digital Transformation with DevOps“.
Признаюсь, это выступление понравилось больше остальных: импонирует, когда в компании при принятии любого серьезного решения, от мала до велика, каждый сотрудник руководствовался честными, базовыми принципами Agile. Это не выглядит, как „поклонение“ или „возвышение“ Agile, это скорее похоже на то, что они „приняли“ эти правила и принципы, и каждый для себя определил, почему он им следует.
День второй
Когда первые восторги чуть-чуть улеглись, появилась тяга к неспешному размышлению, смакованию новых идей и полученной информации. В этом плане, формат доклада Philipp Garbe на тему „is Platform Engineering is the new Ops?“ был очень удачен.
Выступление он начал с цитаты:
Philipp рассказал, как сначала отошли от разделенных команд разработки и тестирования, потом выделили DevOps инженеров, с какими проблемами столкнулись и как пришли к организации инженерных команд, полностью отвечающих как за разработку, так и за эксплуатацию приложений. Основной посыл выступления, как я для себя уяснил, — это выделение двух типов инженерных команд: platform и product. Первые обеспечивают функциональное и надежное окружение, чтобы вторые могли быстро и безопасно доставлять новые фичи до пользователей, получать структурированную обратную связь. Мне кажется, такой подход имеет смысл, особенно, если под приложением подразумевается целый комплекс ПО, а сложность системного окружения достаточно высока.
Выступление Michiel Rook, консультанта Java, PHP, Scala из Нидерландов, с докладом „Database Schema Migrations with Zero Downtime“, для меня было немного скучным. Спикер с энтузиазмом и на глазах у изумленной публики подтвердил догадки о том, что с миграциями баз данных все просто, если вы не используете базы данных. Это выступление не было колоссальным открытием, поскольку мы не используем схему обновления БД, указанную ниже.
Michiel описал ряд правил, прибегая к которым можно уменьшить время простоя при миграциях БД. Например, использование балансировщика нагрузки, чтобы была возможность отключать один из узлов, на котором установлено приложение для установки обновлений.
Также он упомянул, что для облегчения работы с базами данных и уменьшения ошибок хорошо было бы:
1) „разорвать связь“ между миграцией БД и развертыванием ПО;
2) поддерживать обратную совместимость и только расширять контракты взаимодействия;
3) отказаться от деструктивных изменений;
4) использовать feature toggle при работе с данными. Например, для удаления старых, замененных новыми полей таблиц.
Ну что ж, всегда есть, чему поучиться.
А вот выступление Tony Grout из Atlassian на тему „DevOps teams and the future backward“, было занятным. В своем выступлении он акцентировал внимание на том, как принцип „открытости“ помогает командам достигать целей, при этом не допуская ошибок и не упуская деталей. Он продемонстрировал, как команды могут принимать решения, экспериментировать, пробовать и учиться, и как такой подход повышает отдачу команд. Также мы обсудили проблемы крупных корпораций работе с командами: отсутствие возможности работать удаленно из-за ограничений безопасности, медленное развитие команд из-за отсутствия культуры сотрудничества между разными подразделениями. Тони, как мне кажется, убежден, что сегодня нет никаких ограничений для удаленной работы сотрудников и для организации межкомандного обучения, то есть создания „культуры сотрудничества“, так как есть огромное число технических утилит для эффективного взаимодействия команд.
Основные принципы подхода:
- экспериментируйте, тем самым улучшая качество поставляемого функционала;
- вкладывайтесь в будущее качество, максимально автоматизируйте конвейер для наибольшей пропускной способности вашей инфраструктуры;
- регулярно решайте злободневные проблемы, так вы ускорите доставку новых фич клиентам.
Под конец выступления Тони произнес фразу, которая меня вдохновила: „Be the change you seek“.
В сухом остатке
Изначально я считал, что DevOps — это про автоматизацию, скрипты. Достаточно распространенное заблуждение, как я потом узнал и понял, погружаясь в процесс и в среду все глубже: DevOps подразумевает не только определенный технический склад, но и психологический, он тесно связан с гибкими методологиями разработки. Участие на этой конференциии позволило мне разобраться и выстроить знания в моей голове в цельную картину.
Кейсы, инсайты и нетворкинг возбуждают пытливый ум и, возможно даже, провоцируют внутреннего философа – DevOps это образ мышления каждого участника: от бизнеса и стейкхолдеров до внедренцев. Нельзя это просто взять и привнести в компанию, наняв определенного вида инженеров, руководителей или трансформаторов. Devops идет рука об руку с Agile. Это то, что надо взращивать, прививать, долго и упорно экспериментируя. Способ мышления стоит менять не только в части разработки ПО, но и в части взаимодействия с клиентами, получения обратной связи, снятия метрик.
Конечно, без инженерной культуры далеко не продвинешься: пока одни ребята будут неустанно находить дефекты и изъяны, чинить их, другие будут плодить новую функциональность, не особо беспокоясь о том, оптимально ли написаны их методы и правильно ли они обработают негативные кейсы при прохождении тестирования, ни о каких малых итерационных циклах не может быть и речи. Не стоит забывать и про автоматизацию, высокий уровень которой позволит значительно сократить время на вывод нового функционала в продакшен, а это, наверно, одно из слабых мест многих компаний сегодня.
В замечательной книге The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win описывается подход „три пути“. Первый путь призывает акцентировать внимание на производительности цельной системы, а не отдельных ее составляющих. Следование второму пути означает выстраивание короткого цикла обратной связи, который позволит услышать и понять всех клиентов системы и верно среагировать на их отзывы. Третий путь заключается в создании культуры экспериментов и оттачивания мастерства. Когда мы будем пробовать что-то новое, это потребует принятия определенных рисков и неудач, зато позволит нам развиваться и становиться лучше, а в следующий раз, попав в неприятную ситуацию, мы точно будем знать, как из нее выйти.
Мне кажется, эти три принципа лучше всего описывают культуру DevOps, к которой мы все стремимся, однако, некоторые принципы банковской системы, текущая их организация и мировоззрение некоторых людей не позволяют в нужной мере следовать этим принципам. Я думаю, дело также в том, что DevOps — относительно молодое направление, из-за этого у людей встречается скептическое отношение, а порой, при попытке применить эту методологию, вопросов бывает больше чем ответов
Мне нравится подход компании cognizant, которые действительно „гибко“ подошли к делу, но в то же время не потеряли в „качестве“: DevOps для них — это не сама цель и даже не инструмент для решения определенных задач, скорее это некий путь, проходя по которому они смогут постоянно развиваться и предоставлять пользователям лучшие продукты.
Devops — это своеобразная практика обучения и экспериментов, где что-то новое всегда приветствуется. Без ошибок никуда, но в данном случае ошибки — это то, что движет вперёд, они не должны пугать, деморализовывать, на них стоит учиться и делать выводы. После конференции я развернул свой подход на 90 градусов, поскольку убедился, что в таких делах, как трансформация компании, будь то внедрение devops или переход на гибкие методологии разработки, требуется участие всех участников процесса: от команд разработки до высшего руководства. Тут как раз и возникает большинство проблем, поскольку людям не хочется меняться и что-то менять в работе. В команде я стал чаще прислушиваться, как другие участники отзываются о нашем процессе, как происходит их взаимодействие с другими командами и администраторами стендов. В идеале мне бы хотелось видеть некую сквозную команду, участники которой будут вместе придумывать решения проблем, делиться опытом и подкидывать друг другу идеи на регулярной основе, но это уже совсем другая история.
А как вы считаете, нужно ли вообще ездить на конференции или продуктивнее сосредоточиться в офисе на своей работе?
