- PVSM.RU - https://www.pvsm.ru -
7 декабря прошла третья конференция DevOpsDays Moscow [1], организованная московским DevOps-сообществом при поддержке Mail.ru Cloud Solutions. Кроме докладов ведущих практиков DevOps, участники могли посетить короткие мотивирующие Lightning Talks, воркшопы и пообщаться в опенспейсах.
Мы собрали важные инсайты с шести выступлений и провели интервью с несколькими спикерами, чтобы узнать о том, что осталось за рамками докладов.
Внутри:
Фейлы при обновлении софта случаются ежечасно и у всех. Вот только одна страшная история из выступления: Knight Capital после неудачного обновления потеряли 440 млн долларов за час.
Барух рассказал про DevOps-паттерны непрерывных обновлений, которые помогут избежать провалов и ненависти пользователей:
Локальный откат — держите предыдущую версию софта на девайсе, чтобы откатиться в случае чего. Это защитит вас, если все будет так плохо, что не получится прислать патч по воздуху.
Обновления по воздуху — лучше непрерывные. Иначе будет, как с разработчиками Jaguar: из-за бага в тормозной системе, которую нельзя было обновить по воздуху, пришлось отзывать автомобили из продажи. Это было больно и дорого.
Непрерывные обновления — обновляйте софт непрерывно, как только готова новая фича. При редких обновлениях фичи группируются, критическое обновление может ждать некритические. Как в Тесла — обновление, которое должно было пофиксить случайное торможение, ждало обновления игры в шахматы.
Автоматизированный деплоймент — замените людей машинами, так как люди плохо умеют выполнять рутинные действия.
Частые обновления — помогают выработать привычку и избавиться от страха. Редкие обновления превращаются в авральное событие.
Знание состояния девайса — тестируйте обновления, а не установку с нуля. Это важно, так как обновления могут вести себя по-разному в зависимости от состояния девайса.
Канареечные релизы — выкатывайте обновления небольшому числу пользователей и наблюдайте. Это снижает ущерб, если что-то пойдет не так.
Обновления без недоступности — пусть клиенты замечают только новые фичи, а не остаются без сервиса на несколько недель, пока вы выкатите обновление.
Мы поговорили c Барухом Садогурским о том, как отличается взгляд на DevOps в российском и западном IT, скоро ли Cloud будет все делать за нас и все ли программные сервисы скатятся в схему aaS — смотрите интервью:
Внедрение Kubernetes не поможет достичь DevOps, и даже наоборот — может всё сломать. Павел рассказал, почему технологии (даже самые крутые) не могут решить все ваши проблемы:
Сложность проекта переехала за пределы кода. Раньше было сложное приложение: взаимодействие внутри проекта и сложная разработка, но простая структура — администратор развернул, всё работает. Перешли к микросервисам: каждый сервис — простое приложение, общение по стандартным протоколам и быстрая разработка, но структура проекта стала сложнее. Сложность проекта с микросервисной архитектурой никуда не делась — она переехала за пределы кода. Теперь за нее отвечает DevOps-инженер.
Разработчики не хотят изменений после внедрения DevOps. В итоге воркфлоу с Kubernetes продолжает выглядеть как перекидывание задач от Dev к Ops через стену, только уже не метафорическую — такой стеной становится Git. Разработчик туда помещает код и работает как раньше, а у админов есть Kubernetes, CI/CD и всё остальное.
Однако разработчикам надо принять изменения. Ситуация, когда разработчики не знают, что делают админы, а админы не знают, что происходит у разработчиков, создает проблемы.
Если у разработчиков ничего не поменялось, они не осознают, что работа приложения их ответственность — разные технические ухищрения работать не будут.
С приходом DevOps и Kubernetes в разработке многое поменяется. Dev должны быть компетентны в Ops, и наоборот. У этих специалистов свои специфические навыки, но они должны быть в курсе работы друг друга. Dev и Ops надо подружить до внедрения Kubernetes, иначе вы поломаете то, что есть.
Павел Селиванов рассказал о том, что будет с Kubernetes через 5 лет и на чем строить технологический стек современному стартапу — смотрите интервью:
Компании приходят к DevOps-трансформации, когда понимают, что разработка слишком медленная и не отвечает реалиям, у них появляется желание разрабатывать лучше и выкатывать быстрее.
Владимир рассказал, как это происходит, и в чем тут подвох:
Что же делать? Нанять временную DevOps-команду, которая поможет реализовать DevOps-трансформацию, будет нести практики, выращивать культуру разработки и технологическую культуру.
Когда бизнес вступает в игру и вкладывается в DevOps, возможны несколько вариантов развития событий: все развалится на взлете; останется как SRE/Production Engineering либо Embedded Ops; перейдет к BizOps, когда процессы опираются на бизнес-метрики.
Владимир Утратенко рассказал нам о том, насколько «кровав» DevOps в энтерпрайзе на самом деле и как внедряют практики внутри крупного ритейла — смотрите интервью:
Facebook — огромная компания, с большим количеством компонентов, серверов, людей, дата-центров. Несмотря на огромные размеры, он очень быстрый — разработчики могут выкатывать сервисы множество раз в день. Также Facebook быстро растет, и дело не только в росте количества пользователей и серверов, увеличивается также число разработчиков, что усложняет процессы.
Сергей рассказал, чем занимается Production Engineer в Facebook:
Михаил считает, что DevOps — это непрерывное развитие. Нельзя внедрить какие-то инструменты и на этом остановиться. Какие проблемы мешают компаниям стать DevOps и как внедрять практики?
Разница в понимании DevOps. Канонический девопс, как его видят евангелисты, держится на 5 столпах:
В компаниях обычно делают акцент только на автоматизации и доставке ценности юзеру. А вот культура, обмен знаниями и метрики DevOps, по которым можно отслеживать развитие, уходят на второй план.
Проблемы стандартизации DevOps. Продуктовые цели разные у всех компаний, их нельзя стандартизировать. Состояние DevOps в компании зависит от самой компании, но многие этого не понимают и считают, что достаточно нанять DevOps-инженера.
Почему мы еще не DevOps? Есть две ключевые проблемы. В Enterprise — медленное развитие организации, сложности со сменой вектора в головах тысяч сотрудников. В стартапах — отсутствие источников знаний, проблема с выделением ресурсов на трансформацию.
Стадии развития DevOps в компании:
Идеальная схема — все имеют одинаковый доступ к инфраструктуре, все инженеры получают доступ к проду и понимают, что они делают.
Закрыв все культурные и технические гештальты, DevOps-трансформация компании будет учитывать обратную связь от бизнес-метрик и метрик платформы.
Юрий Булич, Дина Мальцева, Евгений Панков из Росбанка рассказали, как они пришли к DevOps за три года. Было две цели: решить конкретные проблемы в конкретных командах и внедрить централизованные инструменты.
Вот каких результатов достигли:
Результаты для продуктовых команд: в 30 раз быстрее сборка, в 6 раз быстрее установка, до 30% экономии на полном цикле. Получили возможность по кнопке катить в продуктив
Результаты для платформенных команд: в 10 раз быстрее сборка и установка, на 87% увеличилось количество установок, 46% покрытие автотестами. Перестала быть узким местом интеграционная команда
Итак, как внедрить DevOps-практики в кровавом энтерпрайзе?
Сначала внедрить пилотный проект: выбрать команды, решить, как реализовать архитектуру и выбрать инструменты. Выбирали инструменты с открытой лицензией, с наличием инсталляции в банке и экспертизы работы с ними. В Росбанке одновременно с DevOps-платформой разворачивали приватное облако, и это помогло на старте. В облаке можно было за 15 минут получить нужные ресурсы по кнопке, ранее такой процесс мог занимать неделю.
В банках и другом энтерпрайзе нужно заранее проработать ограничения с командой информационной безопасности и найти решение, которое позволит внедрить изменения.
После пилота удачное решение надо масштабировать.
Список книг, которые стоит почитать тем, кто в DevOps, от Александра Чистякова, vdsina.ru:
Мы тоже любим DevOps. Следите за анонсами серий @DevOps [2] и @Kubernetes, а также других мероприятий Mail.ru Cloud Solutions, в нашем канале Telegram: t.me/k8s_mail [3]
Автор: schrc
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/blog-kompanii-mail-ru-group/339855
Ссылки в тексте:
[1] DevOpsDays Moscow: http://devopsdays.ru/
[2] @DevOps: https://www.youtube.com/playlist?list=PLQzTaxmOHjnsLsnE0cyPKEfDj5hn7B7AY
[3] t.me/k8s_mail: https://t.me/k8s_mail
[4] Источник: https://habr.com/ru/post/480002/?utm_campaign=480002&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.