Обзор конференции DevOpsDays Moscow: инсайты из 6 докладов

в 9:46, , рубрики: devops, Mail.Ru Cloud Solutions, Блог компании Mail.Ru Group, Тестирование IT-систем, управление разработкой

Обзор конференции DevOpsDays Moscow: инсайты из 6 докладов - 1

7 декабря прошла третья конференция DevOpsDays Moscow, организованная московским DevOps-сообществом при поддержке Mail.ru Cloud Solutions. Кроме докладов ведущих практиков DevOps, участники могли посетить короткие мотивирующие Lightning Talks, воркшопы и пообщаться в опенспейсах.

Мы собрали важные инсайты с шести выступлений и провели интервью с несколькими спикерами, чтобы узнать о том, что осталось за рамками докладов.

Внутри:

  1. Барух Садогурский, JFrog: «Пусть софт течет от вендора к пользователю, как жидкость»
  2. Павел Селиванов, Southbridge: «У Dev и Ops одна общая задача — делать продукт, который работает»
  3. Владимир Утратенко, X5 Retail Group: «DevOps в Enterprise — это разработка без боли и пожаров»
  4. Сергей Пузырёв, Facebook: «Production Engineer заботится о сервисе в целом: чтобы и пользователям, и разработчикам было хорошо»
  5. Михаил Чинков, AMBOSS: «По пути DevOps не может идти одно подразделение, по нему должна идти вся компания»
  6. DevOps-энтузиасты Росбанка: «1000 дней, чтобы внедрить DevOps в кровавом энтерпрайзе»

1. Барух Садогурский, JFrog: «Пусть софт течет от вендора к пользователю, как жидкость»

Фейлы при обновлении софта случаются ежечасно и у всех. Вот только одна страшная история из выступления: Knight Capital после неудачного обновления потеряли 440 млн долларов за час.

Барух рассказал про DevOps-паттерны непрерывных обновлений, которые помогут избежать провалов и ненависти пользователей:

Локальный откат — держите предыдущую версию софта на девайсе, чтобы откатиться в случае чего. Это защитит вас, если все будет так плохо, что не получится прислать патч по воздуху.

Обновления по воздуху — лучше непрерывные. Иначе будет, как с разработчиками Jaguar: из-за бага в тормозной системе, которую нельзя было обновить по воздуху, пришлось отзывать автомобили из продажи. Это было больно и дорого.

Непрерывные обновления — обновляйте софт непрерывно, как только готова новая фича. При редких обновлениях фичи группируются, критическое обновление может ждать некритические. Как в Тесла — обновление, которое должно было пофиксить случайное торможение, ждало обновления игры в шахматы.

Автоматизированный деплоймент — замените людей машинами, так как люди плохо умеют выполнять рутинные действия.

Частые обновления — помогают выработать привычку и избавиться от страха. Редкие обновления превращаются в авральное событие.

Знание состояния девайса — тестируйте обновления, а не установку с нуля. Это важно, так как обновления могут вести себя по-разному в зависимости от состояния девайса.

Канареечные релизы — выкатывайте обновления небольшому числу пользователей и наблюдайте. Это снижает ущерб, если что-то пойдет не так.

Обновления без недоступности — пусть клиенты замечают только новые фичи, а не остаются без сервиса на несколько недель, пока вы выкатите обновление.

Мы поговорили c Барухом Садогурским о том, как отличается взгляд на DevOps в российском и западном IT, скоро ли Cloud будет все делать за нас и все ли программные сервисы скатятся в схему aaS — смотрите интервью:

2. Павел Селиванов, Southbridge: «У Dev и Ops одна общая задача — делать продукт, который работает»

Внедрение Kubernetes не поможет достичь DevOps, и даже наоборот — может всё сломать. Павел рассказал, почему технологии (даже самые крутые) не могут решить все ваши проблемы:

Сложность проекта переехала за пределы кода. Раньше было сложное приложение: взаимодействие внутри проекта и сложная разработка, но простая структура — администратор развернул, всё работает. Перешли к микросервисам: каждый сервис — простое приложение, общение по стандартным протоколам и быстрая разработка, но структура проекта стала сложнее. Сложность проекта с микросервисной архитектурой никуда не делась — она переехала за пределы кода. Теперь за нее отвечает DevOps-инженер.

Разработчики не хотят изменений после внедрения DevOps. В итоге воркфлоу с Kubernetes продолжает выглядеть как перекидывание задач от Dev к Ops через стену, только уже не метафорическую — такой стеной становится Git. Разработчик туда помещает код и работает как раньше, а у админов есть Kubernetes, CI/CD и всё остальное.

Однако разработчикам надо принять изменения. Ситуация, когда разработчики не знают, что делают админы, а админы не знают, что происходит у разработчиков, создает проблемы.

Если у разработчиков ничего не поменялось, они не осознают, что работа приложения их ответственность — разные технические ухищрения работать не будут.

С приходом DevOps и Kubernetes в разработке многое поменяется. Dev должны быть компетентны в Ops, и наоборот. У этих специалистов свои специфические навыки, но они должны быть в курсе работы друг друга. Dev и Ops надо подружить до внедрения Kubernetes, иначе вы поломаете то, что есть.

Павел Селиванов рассказал о том, что будет с Kubernetes через 5 лет и на чем строить технологический стек современному стартапу — смотрите интервью:

3. Владимир Утратенко, X5 Retail Group: «DevOps в Enterprise — это разработка без боли и пожаров»

Компании приходят к DevOps-трансформации, когда понимают, что разработка слишком медленная и не отвечает реалиям, у них появляется желание разрабатывать лучше и выкатывать быстрее.

Владимир рассказал, как это происходит, и в чем тут подвох:

  1. Сначала компании нанимают DevOps-инженера. Это Senior System Administrator, он занимается развертыванием релиза в производство, стандартизацией окружения разработки, настройкой инфраструктуры, обнаружением и фиксом различных проблем, автоматизацией процессов и другими техническими задачами.
  2. Потом одного DevOps-инженера уже не хватает, и компания нанимает DevOps-команду. Это центр компетенций, который организует усилия разрозненных инженеров, позволяет сосредоточить их в одном направлении.
  3. На самом деле, DevOps-инженер и DevOps-команды — это антипаттерны DevOps-трансформации. Так как DevOps — это про практики и культуру, кроме того, существуют имплементации DevOps в технологических компаниях (SRE, Production Engineering).

Что же делать? Нанять временную DevOps-команду, которая поможет реализовать DevOps-трансформацию, будет нести практики, выращивать культуру разработки и технологическую культуру.

Когда бизнес вступает в игру и вкладывается в DevOps, возможны несколько вариантов развития событий: все развалится на взлете; останется как SRE/Production Engineering либо Embedded Ops; перейдет к BizOps, когда процессы опираются на бизнес-метрики.

Владимир Утратенко рассказал нам о том, насколько «кровав» DevOps в энтерпрайзе на самом деле и как внедряют практики внутри крупного ритейла — смотрите интервью:

4. Сергей Пузырёв, Facebook: «Production Engineer заботится о сервисе в целом: чтобы и пользователям, и разработчикам было хорошо»

Facebook — огромная компания, с большим количеством компонентов, серверов, людей, дата-центров. Несмотря на огромные размеры, он очень быстрый — разработчики могут выкатывать сервисы множество раз в день. Также Facebook быстро растет, и дело не только в росте количества пользователей и серверов, увеличивается также число разработчиков, что усложняет процессы.

Сергей рассказал, чем занимается Production Engineer в Facebook:

  1. Production Engineer много кодит, у него должны быть системные знания: операционных систем, файловых систем, баз данных, сетей и того подобного. Должен быть опыт работы с распределенными системами и Reliability Engineering, то есть в поддержке надежности работы продукта. Он обязан быть on-call, то есть доступным для вызова в любое время.
  2. Production Engineer отличается от Software Engineer продвинутыми скиллами в эксплуатации, но, по сути, является подвидом Software Engineer. Software Engineer больше кодят, у них могут быть дополнительные скиллы, связанные, например, с обработкой данных. В Facebook такие специалисты тоже должны быть on-call, что для многих становится неприятным сюрпризом.
  3. Пирамида потребностей Production Engineer в компании начинается с мониторинга серверов и их жизненного цикла, то есть получение нового железа, его настройка, ввод в эксплуатацию. Следующий уровень — то же самое на уровне сервисов: мониторинг сервисов и их жизненного цикла. Затем идет бесшовное масштабирование и расширенный мониторинг. К автоскейлингу переходят после того, как жизненный цикл сервиса автоматизирован. И в конце надо заниматься тюнингом, чтобы масштабирование было эффективным, компания экономила деньги и ресурсы.

5. Михаил Чинков, AMBOSS: «По пути DevOps не может идти одно подразделение, по нему должна идти вся компания»

Михаил считает, что DevOps — это непрерывное развитие. Нельзя внедрить какие-то инструменты и на этом остановиться. Какие проблемы мешают компаниям стать DevOps и как внедрять практики?

Разница в понимании DevOps. Канонический девопс, как его видят евангелисты, держится на 5 столпах:

  • культура — фокус на людях и коллаборация;
  • автоматизация — делегирование рутины в workflow;
  • lean — акцент на доставке ценности юзеру;
  • sharing — непрерывный обмен знаниями;
  • метрики и получение обратной связи с их помощью.

В компаниях обычно делают акцент только на автоматизации и доставке ценности юзеру. А вот культура, обмен знаниями и метрики DevOps, по которым можно отслеживать развитие, уходят на второй план.

Проблемы стандартизации DevOps. Продуктовые цели разные у всех компаний, их нельзя стандартизировать. Состояние DevOps в компании зависит от самой компании, но многие этого не понимают и считают, что достаточно нанять DevOps-инженера.

Почему мы еще не DevOps? Есть две ключевые проблемы. В Enterprise — медленное развитие организации, сложности со сменой вектора в головах тысяч сотрудников. В стартапах — отсутствие источников знаний, проблема с выделением ресурсов на трансформацию.

Стадии развития DevOps в компании:

  • первая — инфраструктура в облаке, но никто не знает, как она работает, кроме одного-двух админов;
  • вторая — инфраструктура прозрачна и понятна всем инженерам, но процессы не поставлены на поток;
  • третья — инженеры самостоятельно запускают и чинят live-сервисы;
  • четвертая — инженеры по желанию контрибьютят в core инфраструктуры, прозрачный код в облаке, деплой по кнопке.

Идеальная схема — все имеют одинаковый доступ к инфраструктуре, все инженеры получают доступ к проду и понимают, что они делают.

Закрыв все культурные и технические гештальты, DevOps-трансформация компании будет учитывать обратную связь от бизнес-метрик и метрик платформы.

6. DevOps-энтузиасты Росбанка: «1000 дней, чтобы внедрить DevOps в кровавом энтерпрайзе»

Юрий Булич, Дина Мальцева, Евгений Панков из Росбанка рассказали, как они пришли к DevOps за три года. Было две цели: решить конкретные проблемы в конкретных командах и внедрить централизованные инструменты.

Вот каких результатов достигли:

Результаты для продуктовых команд: в 30 раз быстрее сборка, в 6 раз быстрее установка, до 30% экономии на полном цикле. Получили возможность по кнопке катить в продуктив

Результаты для платформенных команд: в 10 раз быстрее сборка и установка, на 87% увеличилось количество установок, 46% покрытие автотестами. Перестала быть узким местом интеграционная команда

Итак, как внедрить DevOps-практики в кровавом энтерпрайзе?

Сначала внедрить пилотный проект: выбрать команды, решить, как реализовать архитектуру и выбрать инструменты. Выбирали инструменты с открытой лицензией, с наличием инсталляции в банке и экспертизы работы с ними. В Росбанке одновременно с DevOps-платформой разворачивали приватное облако, и это помогло на старте. В облаке можно было за 15 минут получить нужные ресурсы по кнопке, ранее такой процесс мог занимать неделю.

В банках и другом энтерпрайзе нужно заранее проработать ограничения с командой информационной безопасности и найти решение, которое позволит внедрить изменения.

После пилота удачное решение надо масштабировать.

  1. Важно максимально «распрямить» конвейер, исключив из него лишние звенья, выделить поставщиков ценности, а остальные компоненты убрать. Промежуточные звенья — это антипаттерны. Например, в Росбанке в ряде команд не сложилась внутренняя разработка, осталась только внешняя. Это привело к появлению выделенной DevOps-команды, которая обеспечивала передачу кода от внешних разработчиков к внутренним. Проблему решили, встроив внешнюю разработку в CI/СD, чтобы они не просто передавали код от себя в банк, но и отвечали за его успех.
  2. В модель зрелости включили элементы DevOps-практик, перечислили инструменты, учли особенности работы с внешними поставщиками — в дальнейшем это помогло быстро нарезать бэклог задач при внедрении в новых командах.
  3. Нужен Governance в виде мягкого контроля и рекомендаций. Хорошо работает DevOps Handbook — это набор организационных и инструментальных характеристик, которые помогают командам правильно использовать платформу.
  4. Стоит сразу уделять внимание культуре, тогда многие изменения пройдут быстрее и проще. Растите внутреннее комьюнити, проводите митапы, технические воркшопы, тренинги, fun-активности. Это дает плоды: люди делятся практиками, смотрят, кто и что сделал, знают, куда обратиться, есть хайп и здоровая конкуренция внутри компании.
  5. Нет смысла работать с теми, кто не вовлечен в процесс, с командами, которые не дозрели, лучше вкладываться в заинтересованные команды и лояльных людей.
  6. Выбранное решение должно быть удобным для тех инженеров, которые им пользуются.
  7. Внешняя разработка — это не блокер, там тоже можно внедрять практики, главное, чтобы было желание у самой команды.

Еще чуть-чуть пользы

Список книг, которые стоит почитать тем, кто в DevOps, от Александра Чистякова, vdsina.ru:

  1. Ирина Якутенко «Воля и самоконтроль».
  2. Daniel Kahneman «Thinking, Fast and Slow».
  3. Barbara Oakley «A Mind for Numbers».
  4. Максим Дорофеев «Джедайские техники».
  5. Viktor Frankl «Man's Search for Meaning».

Stay tuned

Мы тоже любим DevOps. Следите за анонсами серий @DevOps и @Kubernetes, а также других мероприятий Mail.ru Cloud Solutions, в нашем канале Telegram: t.me/k8s_mail

Автор: schrc

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js