Когда вы не интересуетесь окружающим миром, вам совершенно неизвестно чего вы не знаете(С) Не помню из какой книги
В предыдущем посте я писал про DevOps и какую пользу он может принести “обычному” админу. Сегодня я вернулся с курсов Slurm DevOps и SRE и хочу рассказать что я там узнал
TL; DR
Spoiler:
Оба курса наполнены практикой. Вообще, без практики курсы бесполезны, т.к. информация лучше всего усваивается, когда пытаешься воспроизвести описанное сам.
Первый курс разложил по полочкам информацию в моей голове, а второй показал как делать правильно и познакомил с задачами SRE. Теперь я знаю с чего начать внедрение CI/CD у себя и что именно мониторить. А так же не боюсь вписать в резюме пару строчек.
В части про DevOps я описал как проходил сам курс. Если вы пришли сюда за моими отзывами или мыслями — листайте на часть SRE
DevOps
Цель курса DevOps: научить слушателей поддерживать работу современных веб-приложений. В первый же день курса слушателям дают экземпляр приложения, который каждый будет поддерживать, скейлить и обновлять.
Все работы проводятся на виртуальных машинах в облаке. Сначала нужно научиться разворачивать виртуальную машину с приложением на ресурсах облачного провайдера. Делается это с помощью Terraform и скриптов. Вся работа фиксируется в GitLab. Узнал несколько классных ключей, которые сильно бы упростили мою жизнь, знай я их раньше.
Затем наш сервис набирает популярность и нагрузка растет. Нужно масштабироваться. Голый Terraform решает эту задачу, но медленнее, чем нам хотелось бы. В дело вступает Packer, который позвляет не собирать каждую ВМ отдельно, а использовать один образ для всех экземпляров.
В этот момент мы получаем много ручной работы по указанию адресов в конфигах. Масштабирование возможно, но увеличивается вероятность человеческой ошибки и уменьшается скорость роста. Для автоматического обнаружения сервисов начинаем использовать Service Discovery инструменты, а именно Consul.
Для сравнения инструментов повторяем те же задачи с помощью Ansible. Пишем плэйбуки в связке с Terraform и Consul.
Теперь все классно работает и масштабируется. Но вероятность ошибки в плэйбуках всё ещё есть, а значит есть риск и для продакшена. Нужно тестировать всё, что мы делаем. Рассмотрели фреймворки для тестирования, позапускали их вручную. Поняли, что это неудобно. И тут врывается CI/CD. Написали пайплайн для тестирования плэйбуков и вывода изменений в прод. Теперь при коммите в инфраструктурный код автоматически проводится тестирование и создается мерж реквест. При принятии мерж реквеста обновленная версия катится в прод.
Следующая задача — следить за состоянием приложения и иметь ретроспективу для расследования инцидентов. Разворачиваем 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, если не пишешь комменты в своем коде. Современный мир ИТ не любит одиночек. Даже если ты мегакрутой спец в какой-то технологии, то без команды, обладающей компетенциями в смежных областях, ты не сможешь сделать действительно крутой продукт (да, везде есть исключения. Но, в большинстве случаев, одиночки бессильны).
Нужно развивать практики правильной работы, процессы в команде, социальные взаимодействия, умение быстро учиться. Современный инженер вовсе не обязан знать все параметры kubernetes’a, а вот способность читать документацию или делать бэкапы перед важными изменениями или задавать сложные пароли должны конвертироваться в инстинкты.
Тут очень подходит поговорка “Старый конь борозды не испортит”. Ведь даже без знания хайповых технологий опытный человек владеет принципами “правильной” работы, а досконально изучить новый продукт — дело нескольких месяцев
По большому счету весь курс SRE — это пересказ одноименной книги. Но не торопитесь плеваться — пересказывали её очень опытные ребята с примерами из собственной практики. А ещё всё это было смачно приправлено интересными лабами.
Что было на курсе
Аналогично курсу DevOps вам дают приложение. На этот раз оно работает в kubernetes. Тут работа идет в командах по 5 человек. К слову, было 18 команд и полный зал людей. Организаторы сообщают, что все места забиты и многим желающим пришлось отказать.
Итак, первая тема — SLI, SLO, SLA. Какие метрики использовать для измерения? Какие показатели считаются нормой? Разрабатываем метрики, устанавливаем Prometheus, пилим дашборды и алерты. Не успели мы это сделать, как прилетает первый алерт — SLO ниже 99,9%. Что-то сломалось.
И тут для меня начался ад. Я никогда не работал на позиции DevOps или SRE и понятия не имею как диагностировать проблему. Но в нашей команде оказался классный специалист (привет, Вася!), который собаку съел на онлайн-сервисах и направлял всю команду в нужное русло. Благодаря этому мы могли распределить задачи и искать баги, Святая Корова!, в коде приложения. Да, этот курс именно про работу на границе разработки и админства и инфраструктурных проблем в лабах почти нет. Все задачи на поиск недоработок в коде приложения и их устранение или установку костылей.
Если в предыдущем курсе практика была продолжением теоретической части, то здесь сначала кажется, что практика с теорией идут вразрез. Но цель курса — поставить правильную работу команды, а не научить решать технические проблемы.
Так, по ходу курса нам дают теорию, а потом час-полтора лабораторок, с теорией напрямую не связанных. Но задачи курса при этом выполняются на ура. Улучшение алертов, добавление новых данных в мониторинг, работа с инцидентами, вечно отвлекающий генеральный (для каждой команды выделен организатор, исполняющий роль менеджера), написание постмортемов, исправление багов в коде.
Я был на самом первом Слёрме и видел все его факапы. Так что могу ответственно заявить: “Southbridge создали отличную обучающую команду “. Видно, что процессы теперь отлажены, лабы выполнены перед курсом самими преподавателями. Есть команда техподдержки (не из двух инженеров на 70 слушателей), которая умеет быстро реагировать и помогать решать типичные проблемы. Отличная трансляция.
Конечно, не обошлось без проблем. Например, на курсе SRE организаторы планировали сломать приложение особым способом, чтобы получить из этой неполадки пару новых лаб. Но не учли особенностей языка. Команда быстро вышла из неловкого положения и на следующий день участники могли ознакомиться с постмортемом произошедшего. Курс ведь про SRE, вот и преподаватели показали на своем примере, что честность в работе — важная составляющая
К сожалению, почти не затронули тему Chaos Engineering. Я очень хотел узнать про противодействие DDoS и услышать как строятся приложения для работы в микросервисной среде. В комментариях на хабре жалуются на “нереальные лабы”. Я не могу прокомментировать их реальность, но решать и наблюдать за решениями было очень интересно и познавательно.
Когда вы не интересуетесь окружающим миром, вам совершенно неизвестно чего вы не знаете
После шести дней, проведенных на курсах только укрепилось понимание того, что необходимо не только изучать фундаментальные основы ИТ, но и понимать работу современных систем, принципов работы, Best Practice. Вообще всегда после курсов ко мне приходит эффект Даннинга-Крюгера и хочется жадно поглощать новую информацию. Поэтому я всем рекомендую ходить на курсы и конференции. Там можно не только укрепить знания в конкретной технологии, но и открыть для себя много нового. Отдельно стоит упомянуть, что важны не только спикеры, но и другие студенты, которые могут поведать много итересного. Самая интересная информация всегда ждет нас возле кофе-машины или в курилке.
Спасибо Southbridge и команде Slurm за то, что сделали возможным почувствовать этот эффект в очередной раз и за шикарную прокачку в интересной сфере!
