7 декабря прошла третья конференция DevOpsDays Moscow, организованная московским DevOps-сообществом при поддержке Mail.ru Cloud Solutions. Кроме докладов ведущих практиков DevOps, участники могли посетить короткие мотивирующие Lightning Talks, воркшопы и пообщаться в опенспейсах.
Мы собрали важные инсайты с шести выступлений и провели интервью с несколькими спикерами, чтобы узнать о том, что осталось за рамками докладов.
Внутри:
- Барух Садогурский, JFrog: «Пусть софт течет от вендора к пользователю, как жидкость»
- Павел Селиванов, Southbridge: «У Dev и Ops одна общая задача — делать продукт, который работает»
- Владимир Утратенко, X5 Retail Group: «DevOps в Enterprise — это разработка без боли и пожаров»
- Сергей Пузырёв, Facebook: «Production Engineer заботится о сервисе в целом: чтобы и пользователям, и разработчикам было хорошо»
- Михаил Чинков, AMBOSS: «По пути DevOps не может идти одно подразделение, по нему должна идти вся компания»
- 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-трансформации, когда понимают, что разработка слишком медленная и не отвечает реалиям, у них появляется желание разрабатывать лучше и выкатывать быстрее.
Владимир рассказал, как это происходит, и в чем тут подвох:
- Сначала компании нанимают DevOps-инженера. Это Senior System Administrator, он занимается развертыванием релиза в производство, стандартизацией окружения разработки, настройкой инфраструктуры, обнаружением и фиксом различных проблем, автоматизацией процессов и другими техническими задачами.
- Потом одного DevOps-инженера уже не хватает, и компания нанимает DevOps-команду. Это центр компетенций, который организует усилия разрозненных инженеров, позволяет сосредоточить их в одном направлении.
- На самом деле, 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:
- Production Engineer много кодит, у него должны быть системные знания: операционных систем, файловых систем, баз данных, сетей и того подобного. Должен быть опыт работы с распределенными системами и Reliability Engineering, то есть в поддержке надежности работы продукта. Он обязан быть on-call, то есть доступным для вызова в любое время.
- Production Engineer отличается от Software Engineer продвинутыми скиллами в эксплуатации, но, по сути, является подвидом Software Engineer. Software Engineer больше кодят, у них могут быть дополнительные скиллы, связанные, например, с обработкой данных. В Facebook такие специалисты тоже должны быть on-call, что для многих становится неприятным сюрпризом.
- Пирамида потребностей 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 минут получить нужные ресурсы по кнопке, ранее такой процесс мог занимать неделю.
В банках и другом энтерпрайзе нужно заранее проработать ограничения с командой информационной безопасности и найти решение, которое позволит внедрить изменения.
После пилота удачное решение надо масштабировать.
- Важно максимально «распрямить» конвейер, исключив из него лишние звенья, выделить поставщиков ценности, а остальные компоненты убрать. Промежуточные звенья — это антипаттерны. Например, в Росбанке в ряде команд не сложилась внутренняя разработка, осталась только внешняя. Это привело к появлению выделенной DevOps-команды, которая обеспечивала передачу кода от внешних разработчиков к внутренним. Проблему решили, встроив внешнюю разработку в CI/СD, чтобы они не просто передавали код от себя в банк, но и отвечали за его успех.
- В модель зрелости включили элементы DevOps-практик, перечислили инструменты, учли особенности работы с внешними поставщиками — в дальнейшем это помогло быстро нарезать бэклог задач при внедрении в новых командах.
- Нужен Governance в виде мягкого контроля и рекомендаций. Хорошо работает DevOps Handbook — это набор организационных и инструментальных характеристик, которые помогают командам правильно использовать платформу.
- Стоит сразу уделять внимание культуре, тогда многие изменения пройдут быстрее и проще. Растите внутреннее комьюнити, проводите митапы, технические воркшопы, тренинги, fun-активности. Это дает плоды: люди делятся практиками, смотрят, кто и что сделал, знают, куда обратиться, есть хайп и здоровая конкуренция внутри компании.
- Нет смысла работать с теми, кто не вовлечен в процесс, с командами, которые не дозрели, лучше вкладываться в заинтересованные команды и лояльных людей.
- Выбранное решение должно быть удобным для тех инженеров, которые им пользуются.
- Внешняя разработка — это не блокер, там тоже можно внедрять практики, главное, чтобы было желание у самой команды.
Еще чуть-чуть пользы
Список книг, которые стоит почитать тем, кто в DevOps, от Александра Чистякова, vdsina.ru:
- Ирина Якутенко «Воля и самоконтроль».
- Daniel Kahneman «Thinking, Fast and Slow».
- Barbara Oakley «A Mind for Numbers».
- Максим Дорофеев «Джедайские техники».
- Viktor Frankl «Man's Search for Meaning».
Stay tuned
Мы тоже любим DevOps. Следите за анонсами серий @DevOps и @Kubernetes, а также других мероприятий Mail.ru Cloud Solutions, в нашем канале Telegram: t.me/k8s_mail
Автор: schrc
