Слёрм отзывы о курсах и обучении

Когда вы не интересуетесь окружающим миром, вам совершенно неизвестно чего вы не знаете(С) Не помню из какой книги
В предыдущем посте я писал про 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 за то, что сделали возможным почувствовать этот эффект в очередной раз и за шикарную прокачку в интересной сфере!

Слёрму полтора года. Шесть интенсивов только по базовому курсу Kubernetes, плюс Мега, DevOps, SRE и Agile — более тысячи участников.
7 апреля стартует «Вечерняя школа Слёрма: базовый курс по Kubernetes», рассчитанная на 4 месяца занятий по вечерам (бесплатные вебинары по теории и платная практика). В мае пройдет седьмой Слёрм по Kubernetes (онлайн-интенсив, «как офлайн, только онлайн»). Будет всё «по-оффлайновому»: с голосовым чатом, видеосвязью, «курилкой» в зуме, групповой работой, выделенными наставниками и техподдержкой.
Мы заявляем, что Слёрм открывает путь к проектам на Kubernetes и росту зарплаты. Так ли это на самом деле?
Мы задали этот вопрос выпускникам Слёрмов. Полтора года — достаточный срок, чтобы стали заметными изменения в карьере, зарплате, работе и сфере задач.
Что важно понимать про этот опрос? Тут есть «ошибка выжившего»: нам ответили те, кто следит за чатом своего Слёрма и готов общаться. Наверняка есть те, кому Слёрм оказался бесполезен, и они молчат об этом. Жизнь меняется: те, кто начал работать с Kubernetes год назад, были в другом положении, чем те, кто начинает сейчас. Это работает в обе стороны: стать архитектором решений сейчас куда сложнее, а найти место джуниора куда проще.
Тем не менее, ответы вполне показательны. По ним можно понять, ради чего стоит проходить Слёрмы.
Карантин — хороший повод поинтересоваться, как там дела в других бункерах на Пустошах, кто какие технологии использует вместе с Kubernetes, что собирается изучать ещё и в какую сторону двигается, не вставая с кресла. Quarantine. Quarantine Never Changes.
В каком Слёрме вы участвовали?
Откликнулись участники практически всех интенсивов по Kubernetes. Наиболее активными оказались участники четвертого Слёрма мая 2019 года и шестого Слёрма, который проходил в ноябре. Этап зрелости нашего интенсива с максимально проработанной программой и натренированными спикерами — возможно, поэтому участники наиболее активны.
Вы работали с Kubernetes до Слёрма?
K8s до сих пор остаётся новомодной технологией, которую многие компании не знают, как готовить. То хватаются за неё, хотя им в принципе это не нужно. То наоборот вовсю тормозят и отыгрывают роль консерваторов и высокоинерционных систем.
Порой бизнес-менеджмент компании не умеет оценивать долгосрочные перспективы и руководствуется крокодильей стратегией укусить здесь и сейчас — потому не понимает доводы it-специалистов, почему необходимо внедрение технологии Kubernetes именно сейчас, а не когда до неё дойдут руки и бюджеты в следующем тысячелетии.
А самому it-специалисту без чётко поставленных задач и обозначенной руководством потребности компании чаще всего трудно замотивировать себя изучать Kubernetes — тем более, что технология — не «два байта переслать» и требует внимательного изучения не только по мануалам, но и на практических примерах.
Как происходило внедрение Kubernetes? С какими трудностями столкнулись?
Мне особо было интересно, какие трудности испытали участники при внедрении K8s. На какие грабли наступили, какой именно модели и длины ручки. Kubernetes умеет удивлять — проверено на практике. И лучше всего изучать практику на чужих кейсах, а не на своих — то, что мы и обеспечиваем на Слёрмах. Меньше шишек, крепче нервы.
Некоторые участники столкнулись с бюрократией на работе и непониманием руководства. Так что и такие варианты были: «Внедрения не было», «Так и не получилось внедрить на работе», «Бюрократия», «Внедрение все еще пока в планах. Основная трудность — неготовность инфраструктуры и приложений к работе в кубере», «Отрицание всего нового. Программисты и оунеры бизнеса не нуждаются в новой штуке, которая как будто не принесет бабла в кратко-среднесрочной перспективе».
Скриншот
А проблемы с самим Kubernetes оказались на редкость разнообразными:
1. Версии ядра на устаревших системах. Сложная настройка виртуальных сетей в KVM/libvirt «снаружи» контейнеров.
2. Написание операторов ещё до Operator SDK (+ api, который пинал job-ы).
3. Инсталляторы кубера — боль, подводные камни, vendor lock и всё такое.
4. Трудность была в том, что я использовал для проекта кластер on prem. На преме отсутствует автопровиженинг для storage class. И при скалировании statefulset приходится persistent volume создавать вручную. Надо в AWS переезжать.
5. Самое основное — Persistent Storage, далее мониторинг кластера.
6. Никак поняли, что это оверкилл, и микросервисы тоже. Так что остались на монолите, с частичным переходом на сервисную структуру.
7. Когда выдали задачу на развертывание кластера, у разработчиков было нечто, что они развернули своими руками, однако как оно работало, никто не мог сказать. Все делали по гайдам, но понимания, что конкретно ты делаешь, не было. В первую очередь столкнулись с проблемами выбора сетевых плагинов, с тем, как компоненты кластера должны между собой взаимодействовать, как их настраивать, и как ускорить развертывание тестовых кластеров.
8. Использовался OpenShift. Трудности были с хранением секретов.
9. Сложности миграции старых приложений в k8s, долгий и сложный рефакторинг.
10. Было сложно с Cert-manager, Ingress.
11. Проблемы с просроченными сертификатам
С какими ожиданиями вы шли на Слёрм? Что оправдалось, что нет?
Ожидания часто обгоняют наши возможности и реальные потребности. Тем интереснее было узнать, какие ожидания оправдались у наших участников. Стоит отметить, IT — это непрерывный бег за технологиями, непрерывное обучение. Как у Кэролла в «Алисе»:
— У нас, когда долго бежишь, непременно попадаешь в другое место.
— Ну, а здесь, знаешь ли, приходится бежать со всех ног, чтобы только остаться на том же месте, а чтобы попасть в другое место, нужно бежать вдвое быстрее.
Скриншот
1. Хотелось познакомиться с Kubernetes, чтобы понять, подходит он нам или нет. Ожидания оправдались, с продуктом познакомился.
2. Изучить K8s в режиме fasttrack — скорее нет. Слёрм дал точку опоры, дальше сам. Проникнуться современной парадигмой работы — это да, очень хорошо.
3. Что смогу независимо работать с Kubernetes кластером. В большей части оправдалось. Хотелось бы еще курс на AWS (EKS) пройти.
4. Быстрый вход, все разжевали быстро и понятно, 2 дня на интенсиве = пара недель самому, меня все устроило.
Скриншот
5. Получить практический навык и best practice по k8s. Я получил и то, и то.
6. Хотелось получить базовое понимание устройства Kubernetes и потестировать базовые навыки на реальном кластере. Ожидания оправдались, было интересно.
7. Хотелось разобраться из чего состоит кластер, разобраться с day-2 задачами администрирования (т.е. что делать после того, как ты его поставил), как организовать защиту, как уместить множество команд в один большой кластер. Получить бест практис по развертыванию и сопровождению. В общем, хотелось понять, что это вообще за зверь такой. Так как фактически перед Слёрмом был развернут тестовый кластер, который жил на ладан, и прочитана документация и гайды, но референсного опыта с другими системами оркестрации не было от слова совсем. Ожидания оправдались на 146%. Это был мой первый опыт удаленного обучения, но за все время ни разу не было желания отвлечься на что-то свое. Нагрузка была сумасшедшая, но это было очень круто, особенно когда разрозненные куски знаний постепенно выстраивались в упорядоченную систему. Очень крутые ощущения.
Скриншот
8. Ожидал получить практику в работе с k8s. Ожидания оправдались на 100%.
9. На Слерм я попал случайно, пошел вместо своего коллеги. Ожиданий особо не было, но я понял, что за три дня в мой мозг положили столько инфы, что я самостоятельно не освоил бы за полгода.
10. Углубить знания — в целом все ок, какие-то вещи не освещали даже на Меге, но редкие кейсы. Паше Селиванову на Слёрм SRE сказал уже чего не хватило.
11. Научится самой простой и в тоже время сложной технологии. Не оправдалось ни разу, я узнал кейсы и понял как глубоко нырять. Кейсы хорошо вправляют мозг, но что бы их применить дальше нужно много времени и убеждений на работе. А не оправдалось, потому что до сих пор учусь учусь и учусь. Очень глубокая тема.
12. Хотелось разобраться с основными понятиями, научиться на практике разворичивать приложение в k8s. Все оправдалось.
13. Хотелось понять, как будет построен процесс после переезда на k8s. Как вписать в наше решение в него. После Слёрма стало понятно в каком направлении двигаться и какие инструменты использовать.
14. У меня было очень общее представление о кубере — и я шел немного углубиться в тему и понять, насколько он применим для наших задач. Ожидания оправдались. Ещё до я понимал, что мы пока не готовы. Но нужно было погрузиться глубже, чтобы полностью в этом убедиться. Получилось.
Из 25 ответов только один можно отнести к тому, что ожидания не совсем оправдались: «Ожидалось больше подробностей про подкапотной работе и меньше «запустите команду, которую вы скопировали, и мчим дальше». В целом, участники остались довольны, что не может не радовать.
Какие изменения произошли у вас после прохождение Слёрма? Профессиональный рост, новые задачи и функции, рост заработной платы?
Далее пришёл черёд профессиональных историй успеха и преодолений. Или же набитых шишек и полезного опыта. Приз зрительских симпатий получает честный ответ «Окончательно отказались от кубернетс».
Этот блок ответов лучше всего отвечает на вопрос «Зачем участвовать в Слёрме?»
Скриншот
1. Сменил работу, в кубе сейчас 80% всего держу, ЗП х2 (скоро буду ещё просить, проект закончу), увеличился объём перевариваемых за N часов задач, завёз Patch Management Policy, немного адекватых сетевых политик (не 100 вланов на каждую железку, а нормально), на очереди Security BP.
2. Более лучше настроили свою инфру. Карьерный рост шёл планово.
3. За этот период я неплохо «прокачался», а также сейчас взял новый проект, где буду использовать k8s в продакшене. Надеюсь все получится.
4. Это разные домены. Они не пересекаются. ) Если ты научился работать бензопилой, бригада все равно будет валить лес (чёт грустно как-то прозвучало :D).
5. Добавились новые задачи и ушёл страх перед неизвестным до Слёрма кубернетесом.
Скриншот
6. К сожалению, Слёрм оказался не очень полезен с профессиональной точки зрения, так как тогдашняя компания отказалась от внедрение Kubernetes по невнятным причинам, а потом я и вовсе уволился. На следующей работе знание Kubernetes тоже не особо пригодилось, так как пользуемся в основном ECS + Fargate. Курс по Docker был полезнее, чем Kubernetes, в этом плане.
7. Поменял компанию, выросла зарплата.
8. После прохождения интенсива разобрался с фундаментальными основами — и смог вклиниться в рабочий процесс вместе с остальной командой.
9. В первую очередь привел в порядок 7 тестовых окружений компании, настроил однотипный и предсказуемый деплоймент, автоматизировал задачи по развертыванию машин. С двухнедельного деплоя кластера ускорил развертывание до 40 минут. Получилось развернуть геораспределенный кластер на три цода с автоматической балансировкой нагрузки и failover. Очень круто было наблюдать, как при «отключении» все само восстанавливалось. Так же был наконец настроен прометеус в соответствии с новой парадигмой динамических окружений. Меня закрепили за группой разработчиков как девопс-инженера, появилось много интересных задач.
10. К сожалению проект закрыли, но тема уже захватила. И я перешел в другую компанию, в которой был развернут уже кластер Openshift. Развернут он был не ахти, но был введен в эксплуатацию, так что это был отдельный челендж по усовершенствованию оного до нормального состояния без пересоздания и длительных простоев. В конечном итоге ЗП вырасла где то на 40%, нагрузка упала и стала более интеллектуальной, стараюсь развиваться дальше как sre-инженер.
11. Новые задачи, расширение команды, новая зона ответственности и повышение ЗП.
Из 26 ответов только 4 можно отнести к всё так же, без изменений. В остальных случаях — и рост зарплаты, и профессиональный рост.
Какие задачи вы решаете с помощью Kubernetes?
Порадовал честный ответ «Никакие. Решили, что нам Кубернетес на текущий момент не подходит». На самом деле, очень важно оценить эту перспективную технологию применимо к вашей компании — бывает и такое, что она просто не подходит, потому что в ней нет реальной потребности. А умножать лишние сущности без меры — это не наш путь.
Скриншот
1. Dynamic environment, стандартизация окружений, HPA для [пре]прода, RBAC для «погромистов». Из интересного Blockchain as a Service построили, сверху пару фин.утилит и датасорсинг а-ля blockchair.com, DBaaS и нечто вроде Heroku на очереди.
2. Поднимаем сервис Tarantool (Приложение + база) на k8s.
3. Мы только начинаем)) Уж полгода прошло, а так переносить будем только инфраструктурные сервисы — прокси/графана/кибана.
4. Разворачиваем различные сервисы и строим pipeline.
5. Обычный запуск нескольких контейнеров и контроль за их жизненным циклом, с перезапуском, если что. Но, снова же, сейчас это не Kubernetes, это ECS.
6. Используем для запуска платформ и сервисов (java). Микросервисный подход.
7. В настоящий момент весь application находится в кластерах Openshift, при этом совершенно разные проекты живут совместно в multitenant кластере и не мешают друг другу. По мере возможностей переносим туда же stateful приложения (postgre, redis, rabbit). В кластере же собираются сборки. Весь мониторинг теперь строится на основе прометея, из мониторинга полностью исключили статичные таргеты. Пользователи самостоятельно настраивают метрики, которые необходимо отдавать в систему. В основном от низкоуровневых задач перешел к высокоуровневому администрированию — настройке квот и лимитов, политик безопасности, стратегиям обновлений и т.д. Начал обучать коллег и команды с целью повысить их самодостаточность при обращении к кластеру. Так же начали консультировать по архитектуре и наиболее важным моментам организации кластера коллег смежных отделов, которые хотят развернуть свое независимое окружение.
8. Поддерживаем среду разработки для 10 команд, используем в продакшене на aws и onprem решениях для наших приложений.
9. Тестирование нескольких фич одновременно. В некоторых проектах деплой через гитлаб.
10. Стейджы, тестирование, разработка. В прод мы растем, скоро поедем.
Какие технологии используете в связке с Kubernetes?
Всегда любопытно заглянуть на «внутреннюю кухню» коллег — оценить, кто и какими инструментами решает задачу. Вдруг придёт озарение, как облегчить себе работу и чего-нибудь внедрить от скуки или для пользы дела.
1. Интеграция gitlab-а (EE), helm, своих костылей пачка, OpenFAAS.
2. Gitlab, ceph, Prometheus, grafana, nexus.
3. Python, Service mesh, PostgreSQL, Helm, GitLab.
4. Мы еще не используем. Скорее всего, это будет vagrant провижен виртуалок на баре метал/ansible для деплоя/vault pki для инфраструктуры сертификатов и хранения секретов/azure application insights (наша специфика) + prometheus + zabbix (мониторинг).
Скриншот
5. Кафка, стек эластика, прометеус.
6. istio, actuator, gitlab ci.
7. ECS как полуфабрикат Kubernetes на текущем проекте. Знание абстракций Kubernetes помогло быстрее разобраться с настройкой тасков и сервисов в ECS, но это всё таки немного другой инструмент. Все «интересные» задачи по типу нетворкинга и безопасности решаются AWS-native инструментами, так что даже не знаю, релеватна ли такая экспертиза для работы с настоящим Kubernetes.
8. Kubernetes+Helm.
9. Уверенно используем postgresql, rabbit, redis. Есть инстансы с mongo, пробуем запускать kafka, zookeeper, consul. Остальное, в основном, самописное, python, juby, nodejs, golang.
10. helm, rook-ceph, prometheus, java, spring-cloud-kubernetes.
Какие технологии вы планируете изучить в ближайшем будущем?
Самый любопытный раздел опроса. Так как будущее сейчас довольно неопределённое, а времени свободного появилось с избытком, то можно спокойно подумать, какие технологии пригодятся для профессионального и финансового роста.
Скриншот
1. Swarm.
2. Ceph, CI/CD.
3. Terraform, golang.
4. OpenShift, Project Pacific (интересно, хоть и не планирую в прод его пихать в ближайшее время).
5. Tarantool, Vault, Kafka.
6. Hashicorp vault + consul.
7. Gitlab ci, python, aws.
8. Istio.
9. Технологии, связанные с BigData. Апачевский стек для бигдаты (Hadoop, Spark и вот это всё). И, возможно, деплой всего этого на кластеры (в т.ч. и Kubernetes) с автоскейлингом и всякими такими штуками. Это нужно будет на новом проекте, ну и это в любом случае востребованные и актуальные знания.
10. Kafka, helm.
11. Вероятней всего service mesh, canary/ab deployments, helm и другие, связанные с новыми фишками Openshift 4. Так же будем глубже погружаться в возможности SD-storage, gluster либо ceph.
12. Учитывая что появилось больше времени на саморазвитие, буду продолжать изучать python и golang. Так же есть желание перейти от хранения конфигураций в шифте к парадигме gitops.
13. Prometheus, clickhouse.
14. На данный момент это продукты HashiCorp. Terraform/Packer/Vault.
15. Helm, Kubespray, Ceph.
16. Технологии RedHat, HP cloud.
17. Планирую глубже капнуть k8s. Для чего иду на Слёрм Мега в мае.
А какие технологии, друзья, планируете изучить вы? Что-то зацепило из списка ответов?
Что вам больше всего запомнилось на интенсиве?
Вот тоже соглашусь с мнением, что «звук банок колы» сразу вспоминается. Спикеры попросили не аккомпанировать лекции дополнительными звуками. Все сидят сосредоточенные, тишина в зале, только шелестят клавиши. И тут кто-то коварно под столом «ш-ш-ш-ш-ш-чпок-щёлк». И следом тоже кто-то не выдерживает — и начинает скрытно копошиться под столом.
Скриншот
1. Харизматичные лекторы.
2. Отлично выстроенный процесс в гитлабе. Стабильные комфортные условия для работы: свет, перерывы, обеспечение водой/едой/колой/сетью.
3. Интерактив.
4. Выполнение практических заданий и получение удовольствия, когда все заводилось.
5. Приятная усталость в конце дня, открытые люди и невероятное количество колы. Спасибо. 😉
6. Практические задания.
7. Павел Селиванов. Очень живо и интересно рассказывает, буквально на пальцах обьясняет сложнейшие вещи. Так же понравилась практика kubespray, до интенсива никак не мог нормально его настроить и развернуть. Хотя конкретно сейчас уже что-то сложно выцепить, учитывая, что был еще и на Мегаслерме и на Слёрме по девопс, но после каждого интенсива был заряд энергии что-то сделать, поднять, развернуть, применить новые знания. Особенно учитывая, что знания эти были актуальные и востребованы в компании «еще вчера».
8. Очередь за кофе. )
9. Работа с Helm, cert-manager, докеризация приложения.
10. Павел и Сергей, ребята большие молодцы.
11. Харизматичность преподавателей и скорость, с которой тараторит Павел Сливанов. А еще быстрее он печатает у себя на маке — не успеваешь увидеть, это беда. Плюс есть очень большой недостаток, который изначально не заметен — что известно Павлу не факт, что известно остальным, он знает какие-то фундаментальные вещи, а для других надо гуглить. То есть по факту к вам приезжают те, кто заплатил и вам это плюс, но осилить материал не многие могут, так как глубина входа огромна. И Павел не может объяснить это людям, он не понимает, что люди этого не знают. Поверьте, проработав год и периодически пересматривая видео, я это понимаю. Вы учите людей, а не показываете мастер-класс скоростного набора цифр на маке и копипасты слайдов. Тот же Бондарев, он ждет когда народ въедет — и скорость выдачи материала в разы медленнее, но эффективнее. НО оба реально шикарные инженеры, большая честь учиться у них. Бондарев — просто ээээксперт с большой буквы, завораживает глубиной знаний. Селиванов тоже хорош, очень опытный сильный инженер (но молодой, горячий, это пройдет, это нормально).
12. «Разогревочный» вопрос про маршруты, который меня, как разработчика, поставил в тупик. )
13. Запомнилось почти все. Формат мероприятия очень порадовал. 2 дня работал из дома, один был очно. Что там, что там не было желания отрываться от процесса.
14. Просто понравилось. Очень плотно и по делу.
Поедете снова на Слёрм, если будет интересная программа?
Приятно, что большинство участников желают повторить опыт интенсива и снова поучаствовать в Слёрме.
Особенно сейчас, когда на улицу особо не выйдешь, игры на приставке и «большом брате» уже поднадоели, а новые сериалы заканчиваются с пугающей быстротой, туалетная бумага уже закончилась — а журавлики-оригами украшают все стены, полки, потолок и пол, кухонные эксперименты с продуктами постепенно сворачивают на путь кулинарных извращений…
Есть вариант провести время с пользой и повторить успехи участников Слёрма, которые участвовали в опросе. Для тех, кто хочет в это непростое время повысить квалификацию, первый ознакомительный вебинар «Вечерней школы Слёрма» пройдет 7 апреля в 20:00. Участие, как и во всем теоретическом цикле, бесплатное. Регистрируйтесь по ссылке и присоединяйтесь. Добро пожаловать!

Если вы помните, пару недель назад я публиковал пост, где написал, что мне предоставили возможность сходить на курсе Slurm по SRE. Так вот, я сходил и хотел бы поблагодарить организаторов за гостеприимство и рассказать о своих впечатлениях. В первый раз, когда я услышал про этот курс, мое отношение было очень скептическим – как можно за три дня, сделать из человека SRE? Позже, я подумал что в целом, опытному опсу или разработчику вполне можно за это время рассказать основные принципы – в конечном итоге, SRE book вполне читается за день-два и тогда я решил что ребята просто перескажут книжку за определенную сумму денег, что вполне себе тоже вариант для занятых людей, в дальнейшем, когда я пообщался с организаторами, я понял что они основной упор собираются давать на практику и мне стало интересно. Собственно, на курс я ехал с небольшим скепсисом (сам то я SRE book прочел достаточно давно), но забегая вперед скажу что получилось достаточно неплохо, особенно учитывая что я был на первом потоке, а про первый блин мы с вами прекрасно знаем. Теперь о курсе: во-первых, slurm взяли работающих инженеров из Booking и даже Google, что я считаю, действительно круто и избавило их от претензий касательно компетентности преподавателей, во-вторых: организация курса вполне удачная – всех участников разбили по командам из пяти человек, стараясь чтобы в одну команду не попали коллеги из одной компании, у каждой команды был ментор и отдельный чат с поддержкой для решения тех проблем, которые не то чтобы были критичны, но возникали. Теперь, что касательно, содержательной части – всех участников, делят на команды, читают теоретическую часть, которой обычно немного, и дают задание – некий инцидент, команды должны разобраться и починить, получая баллы за решения. Сами задания выбраны вполне удачно и на мой взгляд приближенный к тому что делают SRE – не буду раскрывать подробности, но некоторые из них вполне заставили попотеть. Работать приходится с вполне модным сейчас стеком – KubernetesPrometheusGitlabGrafana с проектом, который выглядит как живой и даже имеют документацию. Заданий очень много, времени впритык да и организаторы вводят дополнительные игровые элементы стресса, так что скучать не придется. Темп курса вполне себе интенсивный – к третьему дню я понял, что даже успел подустать. Что понравилось – вполне релевантные задачи и достаточно реалистичные условия, теория без отсебятины и повторяет то что есть в книге, да и вообще в общем доступе. Не было ощущения снежного кома, когда у тебя не выходило справиться с заданиями – давались подсказки, затем, по истечению времени, давались решения и дополнительное время на то чтобы их выкатить. Очень весело работать именно командой – мне с ребятами вполне повезло, мы легко нашли общий язык и работали вполне слаженно, хоть и не сразу. Что не понравилось: все таки темп великоват, как мне кажется, но это конечно субъективно. Так же были шероховатости касательно заданий и времени на них отведенных, подсчета баллов, но это явно проблемы первого потока и в дальнейшем это решат, я уверен. Подведу итог: если вы, как я писал выше, опытный системный администратор, который не боится кодить, бекендер, который хочет расширить свой scope или devops (AKA человек-методология) – приходите, вам точно понравится. Если вы не знаете технологий, которые используются в стеке курса или никогда не программировали, вам будет сложно. Точно не стоит на курс идти тем, кто в индустрии совсем недавно, курс совсем не для новичков – скорее всего вы будете балластом в команде и кроме сумбурной мешанины в голове у вас ничего не останется. Не подойдет он уже и тем кто сейчас уже работает SRE – курс рассчитан на ознакомление с практиками и есть риск что все происходящее вам очень напомнит работу 😉 В целом впечатления остались положительные, пообщался с тиммейтами, среди них есть ребята из регионов – они тоже довольны и считают курс более чем полезным, собираются теперь нести SRE на местах #sre #slurm

Считаю, что школа Слёрм очень сильно выросла за последнее время. Откуда я это знаю? Дело в том, что я присутствовал на самом первом их открытом вебинаре. То есть мне есть с чем сравнить, так как видел все их факапы, а их было множество! Сейчас это абсолютно другая платформа, с ее старой версией у них общее только название. Сейчас я могу с уверенностью заявить – у Southbridge получилось создать действительно качественный продукт. И прошу заметить это точно не лесть, критик я суровый.
Я отметил хорошо отлаженные процессы, все практические задания были тщательно проработаны самими преподавателями. То есть все рассчитано на получение максимальной пользы от дистанционного обучения. У ребят появилась и оперативно работает техподдержка, и их количество куда больше 2 человек))) У меня пару раз возникали технические проблемы и решить их быстро помогали. Качество онлайн-трансляции на высоте. Хвали и желаю только расти и развиваться!

Я участвовал сначала в бесплатном вводном вебинаре от платформы Слёрм. Далее уже записался на полный курс и вот мои наблюдения:
Цена абсолютно адекватная. Мы учились 3 дня по 8 часов, то есть компания арендовала зал, оборудование, технику. При этом в перерывах предоставлялась еда и напитки. То есть все сделано для общего комфорта и настроя на поглощение информации.
Формат обучения, заявлен как интенсивный и это действительно так. Можно сразу забыть о другой жизни вне рамок стен, так как на нее попросту нет времени. Я сделал именно так и нисколечко не жалею об этом.
Для тех кто любит более спокойный и размеренный темп лучше присмотреться к другим платформам.
Обучение качественное, информация подобрана идеально. Здесь вы не увидите пустую болтовню и тонны ненужной воды. Слышал, что есть еще Мега Слёрм, но это уже больше для продвинутых. До такого уровня я еще не дорос. Но школу однозначно буду рекомендовать всем, очень круто постарались!

Что ж совсем недавно завершился мой интенсив от образовательной платформы Слёрм и она лучшая из тех, с кем мне приходилось сталкиваться. Скажу сразу, решите все свои дела до его начала, так как времени катастрофически не будет хватать. Максимум поесть, принять душ и выспаться. Интенсив платный, но считаю такой шаг вполне оправданным. Соотношение теории и практики 50/50. В перерывах спикеры открыты к общению, поэтому можно задать все интересующие вопросы и обговорить спорные моменты за чашечкой кофе.
Также курс подойдет не только абсолютным новичкам, но и опытным пользователям. Так как он помогает:
структурировать уже имеющиеся знания;
получить ответы;
расширить кругозор в отношении новых инструментов в разработке или узнать основные подходы применения знакомых.
Я пришел именно за этим! Спикеры тут действующие практики из мировых развивающихся компаний (Google, Booking) и это очень круто. Ни разу не пожалел о своем решении купить этот интенсив, ребята выложились на все 200%.

Перед тем как рассказать насколько сильно мне оказался полезен или бесполезен Слёрм 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 тебе точно не нужен.
Но само обучение понравилось. Я реально все усвоил и способен начать работать с кластером, что я и сделал на тестовом стенде. Надеюсь получится написать несколько обзорных статей просто по азам и теории, без боевой практики.

Друзья, посетил на прошлой неделе мероприятие #slurm.io/DevOps, которое организовывают знакомые ребята из компании Southbridge.io.
Впечатлений масса и все самые положительные. Мой опыт участия в интенсивах и конференциях насчитывает несколько десятков штук, так что сравнить есть с чем.
Уровень подготовки материала, его подачи и поведения докладчиков очень высокий. Сразу видно, что работа по подготовке проведена масштабная.
Уверен, что даже выступление репетируют многократно каждый докладчик. Ну или они на столько круты сами по себе, что могут выступать без подготовки 🙂
Большой плюс так же в том, что дается не только теория, но и возможность на практике пощупать руками то, о чем рассказывают.
Если у кого-то что-то пошло не так, есть команда техподдержки, которая помогает выполнять практически задачи.
И хоть в ИТ-среде это уже норма, однако все ребята из #slurm.io всегда открыты к общению и готовы отвечать на вопросы и вне самого мероприятия.
По-возможности, буду и дальше принимать участие в #slurm.io. Всегда интересно послушать умных людей и пообщаться с ними)
Жаль только, что проходят мероприятия не так часто как хотелось бы, а повторы одной тематики и того реже.