DevOpsConf: информация к размышлению
В начале лета я участвовал в конференции DevOpsConf. Мероприятие оказалось очень полезным и ценным. И дело не только в том, что DevOpsConf дала возможность узнать что-то новое из технологий или опыта. Конференция натолкнула на несколько принципиальных выводов.
Этот пост — не про итоги DevOpsConf и даже не про содержание докладов. Зачем их пересказывать? Проще воспользоваться записью и послушать самостоятельно. Я же хочу поделиться мыслями о DevOps, которые пришли в голову, пока я слушал доклады коллег.
DevOps: человек или машина?
Несколько лет назад многие компании искали DevOps-инженеров и не очень четко себе представляли, чем они занимаются. Не верите? Посмотрите архивные посты на Хабре: среди них можно найти такие темы как «Кто такой DevOps-инженер и чем он занимается?». Так было пять лет назад, четыре года, три… В одном объявлении о поиске такого специалиста в необходимые навыки умудрились запихнуть все, что можно, начиная и знания git и заканчивая непонятным требованием «понимания практики DevOps».
На самом деле, у каждого DevOps есть своя специализация. Одни хорошо шарят в облаках, другие разбираются в том, как строить отказоустойчивые системы, третьи могут быть гуру микросервисов. Объединить все эти роли и сделать DevOps-инженера многоруком Шивой просто невозможно.
Во-первых, это размывает границы ответственности такого специалиста, а во-вторых, выгореть с таким набором обязанностей можно буквально за неделю. И с таким отношением к DevOps-инженерам нужно что-то делать. Пора определяться не в профессии, а с самой профессией.
Минутка терминологии
Я сразу коснусь моментов, которые будут важны дальше и позволю себе потратить еще немного букв на описание терминологии.
Начнем с ITIL. Раньше эта аббревиатура описывала специальную библиотеку книг, в которых собирались лучшие практики на тему инфраструктуры информационных технологий. Сегодня под ITIL понимают сложную методологию практик, которая покрывает весь процесс разработки софта. Ее ненавидят из-за этого буквально все, потому что прочитать все книги, входящие в библиотеку, могли только те, кто на внедрении ITIL зарабатывает.
Еще одна нужная нам аббревиатура — SRE. В Википедии говорится, что это (Site Reliability Engineering) «набор методов, показателей и предписывающих способов обеспечения показателей систем (именно в таком значении здесь используется слово site, в вовсе не для обозначения веб-сайта). На самом деле SRE — практики, которые придумали инженеры Google для других инженеров, чтобы разрабатывать и поддерживать отказоустойчивые системы.
SRE vs ITIL
На конференции прошла интересная дискуссия между сторонниками SRE и ITIL. Они рассматривали эти подходы с разных сторон. И были высказаны очень интересные суждения.
Если рассматривать SRE и ITIL как два разных подхода к автоматизации, то оказывается, что ITIL требует автоматизировать рутину, а SRE считает, что нужно автоматизировать вообще все. Поспорить можно с обеими точками зрения. ITIL: при автоматизации рутинных операций все равно останутся некоторые неавтоматизированные функции, и в них очень велик риск ошибок, связанных с ручной работой. SRE: при такой автоматизации стоимость разработки и поддержки систем станет неподъемной.
Второй пункт, в котором видны различия в подходах — подготовка к авариям. SRE говорит о том, что у нас есть Chaos Engineering, где, если утрировать, мы рандомно отключаем сервера из сети в production, отслеживаем реакцию систем на отключения и анализируем, как изменить систему таким образом, чтобы она выдерживала подобные отказы.
ITIL же считает, что на все случаи жизни есть Disaster Recovery Plan, в котором описываются все необходимые действия при возникновении аварии. В случае Chaos Engineering не всякий бизнес согласует разрушение прода, пусть и контролируемое. Работает — не трожь. А при DevOps и быстрых поставках релизы у нас выкатываются гораздо чаще, чем обновляется Disaster Recovery Plan, что делает его неактуальным.
Третий момент — разность в подходах к работе комитета по изменениям. ITIL требует, чтобы все изменения согласовывали в специальном комитете с учетом мнений всех заинтересованных сторон. По моему опыту такая работа очень сильно усложняет жизнь: приходится ждать всех согласований, которые могут занимать недели, а в сам комитет зачастую попадают люди, которые толком не разбираются, что и как мы хотим изменить. Хотя, процесс согласования можно и упростить. Например — при выкатывании отдельных изменений, не приводящих к даунтайму, просто уведомлять о них. И это — уже SRE-подход.
Мораль: в чистом виде использовать методологию ITIL или методологию SRE не получится. Нужно искать золотую середину, потому что и у того, и у другого подхода масса проблемных мест, которые не описывают все возможные ситуации. В отдельных случаях хорошо работает ITIL, в других — SRE.
DevSecOps
Еще одна сторона работы DevOps — согласование изменений с безопасниками. Это может стать очень серьезной головной болью. Сначала они тратят время на проверку уже готового релиза, присылают pdf на 500 страниц со списком уязвимостей, а потом вся команда разработки дружно занимается внесением исправлений в архитектуру и код. Так происходит, если безопасники и разработчики живут в разных мирах.
Мы нашли способ избежать проблем: в нашей команде работает security champion с опытом в ИБ, который непосредственно участвует в разработке и на ранних этапах определяет риски и уязвимости. Например, он внедрил инструмент, который еще на этапе разработки сканирует облака и дает рекомендации по оптимизации. В каждый спринт он добавляет пару задач на устранение наиболее критичных уязвимостей, и мы их ликвидируем.
Читайте книжки!
Десять лет назад DevOps-инженеры учились интуитивно: просто «добирали» в разных источниках знания, которых не хватало на практике. Если не работал один подход, можно было попробовать другой. Это, конечно, интересно, но такое обучение требует не только времени, но и других ресурсов.
Многое, как известно, придумали до нас. И даже описали это в умных книжках. И именно их можно порекомендовать.
Первая из них — «Руководство по DevOps». Здесь описано как выстроить команду и управлять ею, как обучать сотрудников и находит на это время. Эта книжка — про процессы. На бумаге она, кстати, закончилась, но можно почитать электронную версию.
Вторая книжка — «Site Reliability Engineering», тот самый набор практик от Google с конкретными рекомендациями, вплоть до организации дежурств. Она есть в открытом варианте на английском, но есть и в русском переводе на бумаге.
Многие (я про нее слышал на многих конференциях в разных банках) советуют книгу «Accelerate». Купить ее можно на Amazon или на Ozon, если вы предпочитаете читать на русском. Я рекомендациям верю, поэтому тоже эту книгу упомяну.
Наши разработчики немножко знакомы с инфраструктурой, знают базовые возможности Kubernetes и многое другое. Но такой подход должен работать и в обратную сторону. Если ты SRE, то учись кодить, чтобы в случае аварии на проде самостоятельно ее ликвидировать или помогать разработчикам оптимизировать софт под нагрузку.
Мелочи, но тоже очень важные
И еще несколько полезных советов, которые я услышал на конференции. Они прозвучали в разных докладах, и формируют достаточно четкую картинку правильных подходов к DevOps.
Технический директор «Флант» Дмитрий Столяров рассказывал о том, почему нужно не делать Kubernetes, а использовать его. Эта история — про нас. В моей предыдущей компании мы поддерживали свой кубер со всеми вытекающими, в МВидео же используем готовые облачные решения, и всей сопутствующей работой занимается провайдер. И это перекликается с одним из тезисов Дмитрия: если нужно сделать систему надежной, то из нее скорее нужно что-то убрать, нежели добавить. Системы нужно делать проще.
Open Source не всегда хуже коробочного решения. Это — отсылка к докладу коллег из Х5 Retail Group. Они рассказывали о том, как внедряли систему трейсинга, стремились сделать проект быстро и сравнивали разные инструменты. Они в итоге выбрали платное решение. У нас похожий опыт, но мы выбрали опенсорсную платформу, и получилось у нас не менее надежно и не менее быстро. Поэтому, прежде покупать что-то коробочное, стоит посмотреть на Open Source.
Внутри компании нужно развивать комьюнити, и DevOps, и Java — самые разные сообщества по интересам. Когда в компанию, особенно крупную, приходит новый человек, он сталкивается со множеством систем, не понимает, кто за что отвечает, не ориентируется в документации. Все это делает очень высоким «порог входа». Упрощает проблему онбординга новичков комьюнити: митапы, общие тематические чаты, вики и т. п.
И последнее. Многие считают, что участвовать в таких конференциях — напрасно тратить время. Не согласен. Я не только узнал много полезного для себя. Доклады и обсуждения, которые я прослушал, очень помогли решить очень важную задачу: я убедился в том, что мы движемся в правильном направлении. Добиться такого понимания можно и без конференции, но обойдется оно в этом случае дорого. Потому что опыт может оказаться и отрицательным.
P.S. В нашей команде есть вакансии. Приходите, будет интересно.
