За кулисами DevOps: вышел новый Sravni Podcast

Подробно о содержании подкаста и ссылки на него — под катом.

Посмотреть или послушать подкаст можно здесь:

• YouTube

• RUTUBE

• Яндекс Музыка

Ниже — основные тезисы для быстрого ознакомления с содержанием.

О госте выпуска

Кирилл Карелин — лидер DevOps-команды в Сравни. Команда развивает и поддерживает облачную инфраструктуру компании.

В роли технического лидера Кирилл занимается в основном архитектурными решениями. Вместе с тем, как «играющий тренер», выполняет те же регулярные задачи, что и остальные участники команды — в рамках дежурств, оперативных исправлений поломок и так далее.

О DevOps-команде Сравни

От компании к компании роль DevOpsа меняется, но в первую очередь это все-таки инженерная специальность. DevOps — лишь методология, по которой работает инженер.

В последнее время многие компании стали использовать cloud-технологии, то есть отходить от прямого использования железных серверов: это теперь на стороне вендора. И DevOps-команды обслуживают именно инфраструктуру «на стороне». В Сравни команда так и называется — Cloud Infrastructure Team. Её задача: обеспечивать окружение, которое стабильно работает с точки зрения инфраструктуры, при этом удовлетворяет всем потребностям пользователей.

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

О горячих временах

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

Самое страшное при переезде — взорвать продакшн. С Dev-окружением всё плюс-минус понятно: его можно сломать, и за этого особо ничего не будет. Но у DevOps в Сравни есть договорённость с командами, что Dev у нас — тоже стабильное окружение. Нам важно, чтобы разработчики могли постоянно релизить, выкатывать и тестировать что-то новое. Так что Dev мы тоже поддерживаем.

При переезде, к счастью, в итоге ничего не «упало». Отловили все на DevCluster: создали чек-лист и отрабатывали его, пока не получилось избежать даунтайма. Далее по этому чек-листу наладили сервисы в остальных кластерах.

Как DevOps упрощает жизнь разработчику

Для разработчика окружение — вся та машина, которая катает и собирает релизы, это некий black box. Разбираться в нём стоит, только если сам этого хочешь. Наша основная задача: чтобы человек мог прийти в компанию, почитать инструкции, послушать об устройстве процессов — и совершенно спокойно пользоваться теми инструментами, которые у нас есть, не заморачиваясь о принципах их устройства.

Чуть иначе обстоит дело с распределением ресурсов на сервисы. У нас есть ограничения по использованию ресурсов, но они весьма гибкие. Мы хотим, чтобы вопросами ресурсов занимались непосредственно тимлиды команд: понимали, сколько потребляют, сколько это стоит и как отражается на экономике команды. У нас есть аналитика, которая позволяет подумать над целесообразностью тех или иных расходов. На основе данных мы можем что-то посоветовать — и если выгода от конкретного решения очевидна, то команды, как правило, к этому прислушиваются.

О запасе ресурсов и отказоустойчивости

Золотой стандарт по запасу ресурсов, по мнению Кирилла, — 20−25% относительно нормального потребления. На основе данных мониторинга должна быть описана пиковая нагрузка, и нужно быть уверенным, что сервис выдерживает нагрузку прайм-тайма. Если вдруг прилетит внезапный DOS или случится что-то ещё, запас как раз пригодится.

Из соображений отказоустойчивости важно и зональное распределение сервисов — в каждой зоне должен быть свой запас ресурсов. На случай аварийных ситуаций: если одна зона “отрубится”, нагрузка переедет на оставшиеся.

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

Что касается железных серверов, они все еще важны, когда речь идет, например, о хранении холодных копий и бэкапов. То есть при наличии критически важных узлов инфраструктуры, которые ни в коем случае нельзя потерять. Даже при наличии регулярных клауд-бэкапов и, например, резервирования в S3, хорошо иметь бэкапы, грубо говоря, как на флешке: на всякий случай.

Точки входа в DevOps

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

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

Приходят в девопсы и из админов. Сперва у у тебя мало базовых знаний: умеешь расшивать патч-панели, обжимать провода, менять диски в корзинах, накатывать Linux. Дальше начинаешь углубляться; при разворачивании машины копаешься в настройках.

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

О собеседованиях и скиллах

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

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

Насчет хардов: это, конечно, определяющий фактор при трудоустройстве. Смотрим на соответствие имеющихся компетенций грейду, на который человек приходит.

Если специалист в команду нужен остро, то «софтами» можно пренебречь. Если команда развивается, естественно, человека подбираешь под имеющийся состав. Не только анализируешь, насколько тебе с ним комфортно работать, но думаешь, насколько успешно он будет взаимодействовать с ребятами внутри и за пределами команды.

Специфика работы DevOps в мультипродуктовой компании

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

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

Куда дальше идти девопсу

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

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

Как разработчик может стать девопсом, так и девопс — перейти в разработку: по «технике» команды стоят довольно рядом. Если умеешь в языки программирования и нравится писать код, почему нет? Особенно классно, если ты разработчик, который пришел из девопсов; себе великий инженер: сам написал, сам задеплоил, сам пришел и сказал: вот здесь не работает, почините, пожалуйста.

В теории девопс может пойти и в CTO, хотя есть очевидный зазор между специальностями. СТО должен понимать продуктовые команды на уровне кода, их потребности. Так что девопсам для перехода в CTO нужно плотно погрузиться в цикл разработки, понять потребности этого цикла, многие другие вещи.

О мотивации и метриках

У девопсов в Сравни есть ряд показателей, за которыми мы следим, и от них зависит мотивирование сотрудника. Например, упреждение доунтайма: всё, что касается доунтайма по вине инфраструктуры, засчитывается нам в минус. Еще используем метрику time-to-market, метрику упреждения неработоспособности сервисов — когда мы обновляем наши инструменты или привносим что-то новое.

Это командная история. Все действия направлены на то, чтобы все работало стабильно, отказоустойчиво.

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

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

Получается, есть условно фиксированная часть, которую сотрудники стабильно получают. Но они всегда знают, что если будут вносить улучшения в процессы, то в зависимости от уровня вклада в общее дело получат ещё премию.

Могут и депремировать за плохую работу. Но на моей памяти такого не было ни разу.

О полезной литературе

Про технологии есть книжку Эви Немет, называется «Руководство системного администратора Linux», по-моему, шестое или седьмое издание — с кораблем на обложке. Это прямо настольная книга, всегда помогает, очень крутая штука. А книжка, которая поможет быстро влететь в девопс, называется Kubernetes in Action — тоже крайне советую!