Отзывы о компании Слёрм

Не буду писать про устаревшие местами курсы и тп. По опыту везде этого хватает.
Слёрм же извращается по-своему. На условный материал на 3-24 часа в зависимости от вашего усвоения ребята предоставляют свои стенды для практики и ответов на задания. На каждый этап дано 2 попытки по 6 часов доступа. А если вы не успели - пишите в поддержку (которая работает 10-19 в будни).
Какой взрослый человек в здравом уме будет занимать у вас 6 часов этого стенда? Пришел с работы, с перерывами на ужин позанимался 2-4 часа. Не успел? Пиши в поддержку. Ах да, суббота, мы вам в понедельник (может быть) ответим. Итого, если вы хотите пройти курсы, то имейте ввиду, что вы должны будете делать две попытки, одну в субботу, другую - в воскресенье, иначе рискуете застрять на очередном легаси задании, которое уже невозможно пройти из-за обновлений использумеого ПО vs ожидаемого ответа, и просрать стенд.

Вернулся с двух курсов - DevOps и SRE от Slurm - и хочу поделиться впечатлениями. Если коротко: оба насыщены практикой, и это главное. Без неё курсы были бы бессмысленны - информация реально усваивается только когда сам пытаешься воспроизвести то, о чём рассказывают.

DevOps-курс начинается с того, что каждому слушателю с первого же дня дают живое приложение, которое надо поддерживать, масштабировать и обновлять. Работа ведётся на виртуалках в облаке: Terraform, Packer, Consul, Ansible, CI/CD через GitLab - всё это проходишь не в слайдах, а руками. Есть логика прокачки сложности: сначала разворачиваешь одну ВМ, потом нагрузка растёт, нужно масштабироваться, потом автоматизировать, потом тестировать, потом мониторить через Prometheus+Grafana и ELK. В конце - ChatOps через Hubot со Slack и Telegram. Узнал несколько вещей, которые реально упростили бы мне жизнь раньше, если бы знал их.

DevOps-курс в первую очередь разложил по полочкам то, что я уже примерно понимал, но не мог систематизировать. SRE показал как делать правильно и познакомил с задачами, которые решает эта роль. После обоих курсов я понимаю, с чего начать внедрение CI/CD у себя, что именно мониторить - и без страха могу вписать это в резюме.

На обоих курсах аншлаг, свободных мест нет - это говорит само за себя.

Небольшой контекст: до Слёрма с DevOps-методологией я пересекался только теоретически. Gitlab, Ansible, Terraform - понимал, что это такое, но как всё это работает в связке - не видел. Попробовать хотел давно, но всё "потом". В итоге сами организаторы написали мне и предложили поучаствовать и поделиться впечатлениями. Участвовал очно, поэтому буду говорить только за этот формат - удалёнка могла бы ощущаться иначе.

По соотношению практики и теории: на лендинге заявлено 50/50, по факту вышло ближе к 75/25 в пользу практики. Каждый спикер давал презентацию с обзором инструмента и кейсами из опыта, а потом - практическая часть, которая занимала большую часть времени. Для администраторов и разработчиков это нормально. Но насколько полезно техническому руководителю несколько часов работать в консоли - вопрос открытый.

По пререквизитам: на сайте написано, что достаточно базового Linux плюс понимание Docker и Ansible. На деле информации "зачем и почему мы это делаем" было маловато. Мы шли по заранее подготовленным сценариям, спикеры объясняли, но не всегда этого хватало. Если бы я заранее посмотрел структуру конфигов Ansible и Terraform, разобрался как устроен Gitlab - усвоилось бы лучше. Организаторам, кстати, стоило бы расписать пререквизиты подробнее и честнее.

Что реально зашло: во время отладки развёртывания инфраструктуры через Terraform понял, какой объём автоматизации за этим стоит и насколько это сложнее и дольше делать руками. А когда вместе с кодом разворачивали экспортеры Prometheus - дошло, что разработчики сами могут решать, что мониторить, без лишней коммуникации. Это ценно.

В целом Слёрм DevOps подойдёт тем, кто хочет систематизировать знания, познакомиться с инструментами или разобраться в конкретных вопросах. Но если приходишь с нуля по теме - готовься подтянуть базу самостоятельно заранее.

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

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

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

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

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


В целом — лично я все что хотел узнать — узнал. На все вопросы услышал ответы.
Вот честное слово — давно такого продуктивного мероприятия для меня не было (посещаю все значимые митапы/конференции). Спасибо большое.


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

Я, как онлайн участник, отвечу что все было достаточно хорошо. Да были траблы с микрофонами и музыкой, терпимо. Задание реально выполнить за два дня, спокойно прослушивая и мотая онлайн (у меня так и получилось, приходилось отлучаться, потом досматривал и доделывал). Разъяснили для меня не очевидные вещи, которые до этого не понимал. По Лекторам: Павел рассказывает живо, с шутками и как то бодро интересно и активно.Сергей — напомнил мне старого лектора по Высшей математике, порою чуть не засыпал под него, немного поживее ему надо. Правда когда работал не лектором -менялся, был активней. Евгений — начинал хорошо, но чувствовалась какая то не уверенность, да и на вопросы из зала как то вяло отвечал, порою не понимая вопроса. По практике тут 5 с+, за документацию это раз и интересные и полные задачи это два. Развитие курса шло поэтапно, хотя лекторам порой приходилось забегать на темы которые еще не разъяснялись вперед. В целом я полностью доволен и если получится рвану на МегаСлерм оффлайн.

Пробовал смотреть 3 их курса на YouTube — очень тяжело: докладчикам не интересно, то что они там делали, и результат их абсолютно не интересовал. Больше двух видео не выдерживал

Слёрму полтора года. Шесть интенсивов только по базовому курсу 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/a\b 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 как это было

Не могу не поделиться впечатлениями от трёхдневного интенсива «SLURM SRE», который мы с моим коллегой Сергеем Поповым недавно прошли. Мероприятие занимало все три дня полностью, с 10 до 18 с перерывом на обед, плюс небольшие перерывы по ходу дела, так что это был действительно «интенсив» во всех смыслах.
Для участия требовались базовые знания и навыки kubernates и helm, было бы полезно знать язык запросов к prometeus и некоторые другие вещи, но основная ценность заключалась, конечно не в тренировке навыков быстро разворачивать/откатывать приложения в kubernates, а совсем другое. SRE = «Site Reliability Engineering», то есть техники решения проблем сетевых приложений. Большинство людей по моим наблюдениям под решением таких проблем понимают исключительно «как хорошо я знаю потроха приложения и поэтому могу быстро найти и устранить проблему» и это само по себе проблема (IMHO). Здесь же нам рассказали «как надо» решать подобные проблемы на опыте таких гигантов как Google и Booking.com, и сразу закрепили теорию суровой практикой.
Понятия и методы, которые используются в SRE разумны сами по себе и понятны даже без курса, но его ценность в том, что все это приведено в стройную систему с готовыми рецептами, начинать внедрять можно прямо хоть завтра. Так что большое спасибо организаторам и спикерам за то, что они упорядочили знания в голове и привели их в стройную систему!
К вопросу о суровой практике — это было действительно нечто и за это организаторам отдельный респект! Нас разбили на команды по 5 человек и поставили в ситуацию очень близкую к боевой — реальный сайт (из интернета был доступен, всё честно), каждая команда обслуживает свой backend (frontend один для всех). Несколько связанных сервисов, ключевой сервис с исходными кодами на локальном gitlab-е и почти настроенном CI/CD. Всё здорово и красиво. И, как говорится, никогда такого не было и вот опять — начинаются проблемы. Команды — вперёд, искать, чинить, поднимать!
Приходится работать и решать задачи с людьми, которых ты видишь впервые. Это дополнительный тренинг по налаживанию коммуникаций. Обратная сторона этого метода в том, что в команде люди разных компетенций, есть те, который уже длительное время работали с инструментами, используемыми в заданиях, есть и те, который имеют о них поверхностные знания без практической работы. Получается так, что в команде появляются лидеры определенных направлений.
Наверное, было бы полезно перед началом интенсива выложить список типичных заданий, чтоб во время самих заданий не тратить время на изменения настроек используемых приложений, а сосредоточиться на сути заданий. Возможно, это также выровняло бы базовый уровень участников.

Всё было в реальном времени, все задачи максимально практические и реальные. И с соревновательным моментом — за многие детали решения команды получали оценки и три лидера — призы.
Это не значит, что три дня напролёт мы только искали проблемы и чинили — примерно треть времени была посвящена выступлениям спикеров, которые рассказывали об концепциях SRE с реальными примерами из личного опыта. А все они были из везущих больших компаний (Google, Booking) из-за рубежа, кто-то из США, кто-то из Нидерландов, хотя и все русскоговорящие. Было интересно услышать и их ответы на каверзные, но насущные вопросы из зала по поводу разных ситуаций.
Отдельно могу отметить качество созданных проблемных ситуаций — из огромного числа участников (было 16 команд по 5 участников) с реальным опытом найти реальную причину сразу не мог практически никто, а уж исправить — тем более, поэтому было невероятно интересно. Не всегда в команде все могли вносить полноценный вклад, по моим ощущениям в каждой команде было 1-3 «ведущих» участника, остальные — в большей степени наблюдатели, но даже в роли наблюдателя это был невероятный опыт. Всего за три дня мы решили почти десяток различных задач. Парочка «проблем», увы, не удалась — видимо подсознательно сказался SRE-опыт и организаторам не удалось сломать собственную систему, тем не менее все эти ситуации мы разобрали и труды не пропали даром.
Командная работа, кстати, в этом интенсиве отрабатывалась отдельно и, опять же, очень удачно на мой взгляд. Организаторы намеренно делили участников так, чтобы сотрудники из одной компании попадали в разные команды. И как оказалось это очень правильно — за несколько часов незнакомые люди реально становились работающей командой, каждый пытался внести свой вклад по возможности.
Интересным был опыт, когда созданные команды вначале сидели за одним столом и могли общаться между собой голосом. Но в последний день нас рассадили по разным местам в зале, и в качестве коммуникации осталось возможность только сетевого общения. Этот опыт прекрасно подходит для случаев удаленной работы, когда не все участники локализованы в одном офисе.
Многие возмущались тем, что приложение было на малознакомой большинству технологии, но мне это показалось скорее плюсом (хотя я-то эту технологию знал) — это позволяло не скатиться в поиск ошибок программистов (часто это был тупиковый путь), а с учётом того, что всем желающим были готовы предоставить программиста по требованию и внести нужные правки — это позволяло сконцентрироваться на главном. Вообще, хочу отметить, что стек технологий, который использовался был в значительной степени декорацией для основного действия, любой компонент программного стека мог быть успешно заменён на что-то иное: kubernates на terraform, openstack, что-то ещё, gitlabCI — на jenkins или любой из аналогов, Grafana на... ну, её я бы не менял но можно и на kibana/всякое-такое и т. д. Отрабатывалась сама суть подхода к организации работы, процессу предупреждения(!), обнаружения, поиска и исправления проблем, а также тому, что делать потом (а ведь это тоже крайне важно во избежание бесконечного хождения по граблям). И даже общение с менеджером входило в программу и отдельно оценивалось! Всё как в реальной жизни...
Возможно, имеет смысл сделать варианты такого курса базирующихся на различных популярных стеках приложений. Тогда аудитория была бы лучше знакома с программным окружением и ситуации были бы более близки к повседневным задачам. Тогда понимание пользы внедрения SRE становится еще более очевидной.
При позиционировании курса стоит конкретней определить, что кроме обучения техническим методам SRE необходима готовность начальства к организационным переменам, так как это комплексное решение затрагивающее стиль работы многих отделов и налаживающее коммуникации между ними.
В итоге — считаю этот курс необычайно ценным, хотя мы и не занимаемся поддержкой HighLoad-приложений, у нас немного иная тематика, но практически всё, что было на курсе прямо применимо и к нашей работе (ещё бы пару человек в SRE-команду, ух!), а уж для тех, кто реально делает и использует web-приложения в коммерческих компаниях это просто обязательно. Такие техники нужно не просто знать, а действительно уметь — организовывать, планировать, быстро (а где-то размеренно и вдумчиво) применять. На собственном опыте быстро осознаёшь, что грамотное их применение экономит кучу средств и времени. Ещё раз ОГРОМНОЕ спасибо ребятам из команды SLURM (https://slurm.io/) за этот тренинг!

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

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

В конце мая три дня провел на очном обучении по Kubernetes в Москве. До этого с кубером не работал вообще - только пара обзорных статей на хабре, никакой конкретики. Зато docker и ansible знал на среднем уровне, что в итоге помогло.

До основного интенсива дают доступ к записанным урокам по docker, ansible и смежным темам - открывают за 3 недели до старта, после подтверждения оплаты. Я их прошел заранее и не пожалел: систематизировал то, что знал, узнал кое-что новое. В чате большинство участников, судя по всему, спохватились в последние дни перед началом - это реальная ошибка. На самом интенсиве информации столько, что голова уже не успевает переваривать, так что лучше разгрузить ее заранее.

По содержанию: курс рассчитан на вход с нуля, но docker и ansible желательно знать глубже, чем дается в предварительных материалах - иначе за такой короткий срок просто не успеваешь все уложить. Для тех, кто хочет внедрять Kubernetes и еще не знает его изнутри - формат попадает в точку. Мне лично помог разрушить несколько устойчивых заблуждений о том, как k8s вообще работает и для чего он.

В целом доволен - курс полезный, подача интенсивная (название оправдывает себя буквально). Главный совет: не тяните с оплатой и сразу начинайте предварительные уроки, не оставляйте на последний момент.

DevOps-инженеры в N1.RU приняли участие в онлайн-интенсиве Слёрм Мега @slurm_io. Интенсив направлен на углубленное изучение Kubernetes - управление контейнеризированными приложениями.
⠀
Мы хотели совместить наш многолетний опыт работы с низкоуровневыми инструментами, которые легли в основу Kubernetes и познакомиться более подробно с новым инструментом, который стал очень популярен в мире управления приложениями и микросервисами.⠀
⠀
3 дня Слёрм Мега это:⠀
⠀
〽️Спланированная приостановка текущих задач DevOps-инженеров, чтобы погрузиться в обучение;⠀
〽️Плотный график теория и практика с 14-00 до 24-00; ⠀
〽️Новая терминология, новые инструменты, новый опыт;⠀
〽️Объемный материал, продуманная лаборатория для выполнения практики и качественная техподдержка.⠀
⠀
Мы сделали для себя выводы как по формату обучения, так и по представленному материалу➡️

Если на питерском Слёрме в феврале были в основном новички, то на московском Слёрме люди в массе уже пробовали в Кубернетес. Было много продвинутых вопросов, которые заставляли задуматься.

Если в Питере спрашивали, когда мы выложим свой форк kubespray, то в Москве уже спрашивали, почему мы предлагаем использовать наш форк, а не берем оригинальный kubespray. Это уже критическое мышление миддлов-сеньоров.

Практика была сложной, люди делали много ошибок, и это прекрасно: набивать шишки надо во время учебы, а не в бою. Мы регулярно сталкивались с лимитами на получение сертификатов, лимитами на скачивание с Github и т.д. Это жизнь — мы одномоментно развернули в облаке Selectel около 200 кластеров. Никто свои ресурсы и лимиты к такому не готовит.