Слёрм

Когда вы не интересуетесь окружающим миром, вам совершенно неизвестно чего вы не знаете(С) Не помню из какой книги
В предыдущем посте я писал про DevOps и какую пользу он может принести “обычному” админу. Сегодня я вернулся с курсов Slurm DevOps и SRE и хочу рассказать что я там узнал
TL; DR
Spoiler:
Оба курса наполнены практикой. Вообще, без практики курсы бесполезны, т.к. информация лучше всего усваивается, когда пытаешься воспроизвести описанное сам.
Первый курс разложил по полочкам информацию в моей голове, а второй показал как делать правильно и познакомил с задачами SRE. Теперь я знаю с чего начать внедрение CI/CD у себя и что именно мониторить. А так же не боюсь вписать в резюме пару строчек.
В части про DevOps я описал как проходил сам курс. Если вы пришли сюда за моими отзывами или мыслями — листайте на часть SRE
Image for post
Разобраться в этом под силу только Инженеру
DevOps
Цель курса DevOps: научить слушателей поддерживать работу современных веб-приложений. В первый же день курса слушателям дают экземпляр приложения, который каждый будет поддерживать, скейлить и обновлять.
Все работы проводятся на виртуальных машинах в облаке. Сначала нужно научиться разворачивать виртуальную машину с приложением на ресурсах облачного провайдера. Делается это с помощью Terraform и скриптов. Вся работа фиксируется в GitLab. Узнал несколько классных ключей, которые сильно бы упростили мою жизнь, знай я их раньше.
Затем наш сервис набирает популярность и нагрузка растет. Нужно масштабироваться. Голый Terraform решает эту задачу, но медленнее, чем нам хотелось бы. В дело вступает Packer, который позвляет не собирать каждую ВМ отдельно, а использовать один образ для всех экземпляров.
В этот момент мы получаем много ручной работы по указанию адресов в конфигах. Масштабирование возможно, но увеличивается вероятность человеческой ошибки и уменьшается скорость роста. Для автоматического обнаружения сервисов начинаем использовать Service Discovery инструменты, а именно Consul.
Для сравнения инструментов повторяем те же задачи с помощью Ansible. Пишем плэйбуки в связке с Terraform и Consul.
Теперь все классно работает и масштабируется. Но вероятность ошибки в плэйбуках всё ещё есть, а значит есть риск и для продакшена. Нужно тестировать всё, что мы делаем. Рассмотрели фреймворки для тестирования, позапускали их вручную. Поняли, что это неудобно. И тут врывается CI/CD. Написали пайплайн для тестирования плэйбуков и вывода изменений в прод. Теперь при коммите в инфраструктурный код автоматически проводится тестирование и создается мерж реквест. При принятии мерж реквеста обновленная версия катится в прод.
Image for post
На обоих курсах аншлаг — свободных мест нет
Следующая задача — следить за состоянием приложения и иметь ретроспективу для расследования инцидентов. Разворачиваем Prometheus+Grafana, ELK. Строим дашборды, вешаем алерты. Теперь о неполадках узнаем из мессенджера.
“Мы можем узнавать о проблемах из графиков, звонков разъяренных пользователей, но самое плохое — узнавать об этом из новостей. Поэтому давайте настроим алерты”
Когда мы уже можем наблюдать за работой приложения с помощью удобного интерфейса, можно заняться автоматизацией обновления. В этом нам помогает Envoy. С помощью CI/CD автоматизируем деплой новой версии так, чтобы пользователи не замечали процесс перехода: сначала выкатывается новая версия, envoy переносит туда часть пользователей, если через некоторое время системы мониторинга и логирования не ругаются, то заменяем все ВМ со старой версией на новые.
И последняя часть — то, чего я ждал больше всего — ChatOps. Алерты от мониторинга мы принимали в Slack. Теперь хотим управлять инфраструктурой оттуда же. Есть уже готовые боты для этого, мы использовали Hubot. Он же имеет коннектор к Telegram и другим мессенджерам. На первый взгляд ничего нового тут нет — ещё в нулевых мы умели управлять серверами через ICQ. Удобство чатопса в том, что можно создать простые кнопки для разных рутинных задач. Допустим, шеф хочет узнать доступность БД за последний месяц — один клик и график из Grafana вместе с другими данными у него в телефоне. Или разработчики хотят протестировать новую версию софта. Для этого им нужно развернуть тестовую среду, провести на ней тесты. Всё это можно сделать без доступов в основные системы — бот позволяет гибко управлять правами. Но самое классное в чатопс — все видят всё просходящее. Если после выката новой версии софта мониторинг шлет алерты, то можно за секунды узнать об изменениях в чате, а не бегать по чатам, email’ам и кабинетам в поисках источника проблем.
ChatOps это не столько про удобный универсальный доступ, сколько про взаимодействия в команде и отражение происходящего в системе.
SRE
Этот интенсив для меня оказался сложней, чем предыдущий. Но обо всём по порядку.
Курс SRE - он про людей. Не про kubernetes, prometheus и nginx, а про работу команды.
В самом начале курса Павел Селиванов озвучил мысли, давно летающие в моей голове: “Нам нужны ИНЖЕНЕРЫ!”. Я давно об этом думаю и вот настал момент описать свои мысли в тексте.
В современном ИТ не так важны знания технологий, как умение правильно организовать свою работу и следовать здравому смыслу. Неважно сколько инструментов CI/CD ты знаешь, если не можешь общаться с командой. Неважно, что ты пользовался всеми существующими системами Configuration Management’a, если не пишешь комменты в своем коде. Современный мир ИТ не любит одиночек. Даже если ты мегакрутой спец в какой-то технологии, то без команды, обладающей компетенциями в смежных областях, ты не сможешь сделать действительно крутой продукт (да, везде есть исключения. Но, в большинстве случаев, одиночки бессильны).
Image for post
Нужно развивать практики правильной работы, процессы в команде, социальные взаимодействия, умение быстро учиться. Современный инженер вовсе не обязан знать все параметры kubernetes’a, а вот способность читать документацию или делать бэкапы перед важными изменениями или задавать сложные пароли должны конвертироваться в инстинкты.
Тут очень подходит поговорка “Старый конь борозды не испортит”. Ведь даже без знания хайповых технологий опытный человек владеет принципами “правильной” работы, а досконально изучить новый продукт — дело нескольких месяцев
По большому счету весь курс SRE — это пересказ одноименной книги. Но не торопитесь плеваться — пересказывали её очень опытные ребята с примерами из собственной практики. А ещё всё это было смачно приправлено интересными лабами.
Что было на курсе
Аналогично курсу DevOps вам дают приложение. На этот раз оно работает в kubernetes. Тут работа идет в командах по 5 человек. К слову, было 18 команд и полный зал людей. Организаторы сообщают, что все места забиты и многим желающим пришлось отказать.
Итак, первая тема — SLI, SLO, SLA. Какие метрики использовать для измерения? Какие показатели считаются нормой? Разрабатываем метрики, устанавливаем Prometheus, пилим дашборды и алерты. Не успели мы это сделать, как прилетает первый алерт — SLO ниже 99,9%. Что-то сломалось.
Image for post
SLO не выдержан
И тут для меня начался ад. Я никогда не работал на позиции DevOps или SRE и понятия не имею как диагностировать проблему. Но в нашей команде оказался классный специалист (привет, Вася!), который собаку съел на онлайн-сервисах и направлял всю команду в нужное русло. Благодаря этому мы могли распределить задачи и искать баги, Святая Корова!, в коде приложения. Да, этот курс именно про работу на границе разработки и админства и инфраструктурных проблем в лабах почти нет. Все задачи на поиск недоработок в коде приложения и их устранение или установку костылей.
Если в предыдущем курсе практика была продолжением теоретической части, то здесь сначала кажется, что практика с теорией идут вразрез. Но цель курса — поставить правильную работу команды, а не научить решать технические проблемы.
Так, по ходу курса нам дают теорию, а потом час-полтора лабораторок, с теорией напрямую не связанных. Но задачи курса при этом выполняются на ура. Улучшение алертов, добавление новых данных в мониторинг, работа с инцидентами, вечно отвлекающий генеральный (для каждой команды выделен организатор, исполняющий роль менеджера), написание постмортемов, исправление багов в коде.
Я был на самом первом Слёрме и видел все его факапы. Так что могу ответственно заявить: “Southbridge создали отличную обучающую команду “. Видно, что процессы теперь отлажены, лабы выполнены перед курсом самими преподавателями. Есть команда техподдержки (не из двух инженеров на 70 слушателей), которая умеет быстро реагировать и помогать решать типичные проблемы. Отличная трансляция.
Конечно, не обошлось без проблем. Например, на курсе SRE организаторы планировали сломать приложение особым способом, чтобы получить из этой неполадки пару новых лаб. Но не учли особенностей языка. Команда быстро вышла из неловкого положения и на следующий день участники могли ознакомиться с постмортемом произошедшего. Курс ведь про SRE, вот и преподаватели показали на своем примере, что честность в работе — важная составляющая
К сожалению, почти не затронули тему Chaos Engineering. Я очень хотел узнать про противодействие DDoS и услышать как строятся приложения для работы в микросервисной среде. В комментариях на хабре жалуются на “нереальные лабы”. Я не могу прокомментировать их реальность, но решать и наблюдать за решениями было очень интересно и познавательно.
Когда вы не интересуетесь окружающим миром, вам совершенно неизвестно чего вы не знаете
После шести дней, проведенных на курсах только укрепилось понимание того, что необходимо не только изучать фундаментальные основы ИТ, но и понимать работу современных систем, принципов работы, Best Practice. Вообще всегда после курсов ко мне приходит эффект Даннинга-Крюгера и хочется жадно поглощать новую информацию. Поэтому я всем рекомендую ходить на курсы и конференции. Там можно не только укрепить знания в конкретной технологии, но и открыть для себя много нового. Отдельно стоит упомянуть, что важны не только спикеры, но и другие студенты, которые могут поведать много итересного. Самая интересная информация всегда ждет нас возле кофе-машины или в курилке.
Спасибо Southbridge и команде Slurm за то, что сделали возможным почувствовать этот эффект в очередной раз и за шикарную прокачку в интересной сфере!

Перед тем как рассказать насколько сильно мне оказался полезен или бесполезен Слёрм DevOps, небольшое предисловие.
До участия в Слёрме с методологией DevOps так близко пересекаться не случалось. Да, было понимание о чём вообще эти Gitlab, Ansible, Terraform и прочие хайповые штуки, но как это всё работает вместе не видел. Было желание посмотреть на это всё поближе из серии «при первой же возможности, когда появится время». Этот момент всё не приходил и вот мне в личку написали организаторы Слёрма, предложили посмотреть как он устроен и потом об этом рассказать в своём телеграм-канале. Что ж, сами напросились. Да и кто ж от такой возможности отказывается?
Этот пост будет построен в виде блоков ожидания→действительность. Я участвовал очно, ощущения от удалённого участия могли бы быть другими.
Для кого и о чём Слёрм
Ожидание: практика + теория в соотношении 50/50
Инфа на лендинге Слёрма о целевой аудитории:
Курс рассчитан на технических руководителей, администраторов и разработчиков, желающих преобразовать работу своей команды и стать инженером DevOps.
Согласимся, что карьерный путь из технических руководителей к инженеру DevOps не самый популярный среди айтишников. Курс действительно больше про технику и инструменты. У каждого спикера была презентация и практическая часть. Во время презентации рассказывали про инструментарий, зачем он нужен и кейсы из опыта. Практическая часть занимала подавляющую часть времени. Администраторам и разработчикам попрактиковаться и узнать про новые инструменты и правда ок, а вот насколько руководителям интересно поработать в консоли — вопрос. Руководитель, синк эбаут ит.
Если вы пришли узнать нужен ли в вашей компании DevOps, то, наверное, это понимание придёт само собой во время курса. Я понял, что DevOps в принципе здравая идея, когда дебажил проблему с ошибкой разворачивания инфраструктуры через Terraform после выполнения одного из практических заданий. Тогда стал понятен объём автоматизации и насколько это сложнее и дольше выполнить вручную: действие за действием.
Следующее осознание ценности методики пришло когда вместе с кодом разворачивали экспортеры Prometheus. Разработчики сами могут решать, что им нужно мониторить. Снижает избыточный уровень коммуникаций. Ну и мониторинг, в принципе, моя тема.
Действительность: практика + теория в соотношении 75/25.
Технические пререквизиты
Ожидание: знаний по Linux будет достаточно, остальное узнаю на курсе.
Инфа на лендинге Слёрма о необходимых знаниях для прохождения курса:
Знание Linux на базовом уровне:
— умение работать с systemd, sudo, ip, ifconfig;
— знание, как работает сеть, основные протоколы;
— знание bash на уровне чтения скриптов;
— умение работать с консолью (автокомплит, хистори и т.д.);
— знание основных утилит в линукс (ps, grep, cat, free и т.д.).
Программа Слёрма DevOps рассчитана на базовое владение Docker и Ansible.
Курс был построен так, что мы выполняли заранее подготовленные сценарии для каждого инструмента автоматизации. Да, спикеры в меру возможностей рассказывали что и зачем мы делали, но не всегда этой информации было достаточно. Если бы я знал, что про «зачем и почему» будет так мало информации, то несколько глубже бы предварительно посмотрел как работают те самые инструменты, о которых рассказывали. Например, посмотрел структуру конфигурационных файлов Ansible и Terraform, разобрался из чего состоит Gitlab, узнал как устроен Docker и т.д. Приходилось логически домысливать на ходу.
Наверное, тем, кто просто слышал про инструменты, но не работал с ними, стоит выполнить предварительную подготовку и почитать как этой устроено и работает. Так повысится усвояемость материала. А организаторам можно подробнее раскрыть вопрос подготовки к Слёрму и написать об этом в пререквизитах на лендинге.
Действительность: мало информации о «зачем и почему» мы делаем этот шаг.
Общие впечатления
Слёрм подойдёт если нужно систематизировать знания, получить ответы на конкретные вопросы, узнать о новых инструментах или подходах к использованию старых. Что я и сделал. В перерывах спикеры доступны для вопросов и общения.
И немного о деньгах. Слёрм, кстати, платный. Иногда про платное обучение пишут «ну, камон, зачем платить, документация и статьи помогут освоить что угодно». Я думаю, что такой подход нужно применять избирательно. При изучении конкретных вещей типа Ansible или языка Python гугление — это ок. Но когда количество одновременно изучаемых инструментов превышает три и они ещё работают друг с другом по какой-то логике, а времени мало, можно подумать про заплатить денег ради экономии времени. Тут скорее вопрос соотношения ценности потраченных времени и денег. Можно и бесплатно, если факультативно и спешить некуда.
В конце всех своих статей на Медиуме я обычно публикую ссылки на похожие статьи, но т.к. статей по DevOps у меня нет, вот перевод главы о мониторинге из гугловой книги SRE (который, поговаривают, является частным случаем DevOps):
Мониторинг распределённых систем — опыт Google

Kubernetes точно не для малого и среднего бизнеса. Я сам в основном с ним работаю и вижу, что применять его негде. Это чисто под большие веб приложения инструмент. Запихнуть в него какие-нибудь wordpress или bitrix, а это скорее всего у малого и среднего бизнеса, не получится. Сам уже провернул в голове все варианты и не нашел применения.

Это инструмент больших распределенных команд. Я лично в одно лицо даже не хочу администрировать кластер. Нужна команда админов, чтобы подхватывать проблемы, когда ты не на связи. Так что тут надо четко понимать, зачем тебе kubernetes и обучение по нему. Если ты один админ в обычной не ИТ компании без большого web проекта, kubernetes тебе точно не нужен.

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

Тоже был в онлайне — все было здорово.
Только жаль не было доп.заданий, которые можно было бы поделать после практики.