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

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

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

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

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


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


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

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

Слёрму полтора года. Шесть интенсивов только по базовому курсу 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. Так вот, я сходил и хотел бы поблагодарить организаторов за гостеприимство и рассказать о своих впечатлениях. В первый раз, когда я услышал про этот курс, мое отношение было очень скептическим - как можно за три дня, сделать из человека 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. Всегда интересно послушать умных людей и пообщаться с ними)
Жаль только, что проходят мероприятия не так часто как хотелось бы, а повторы одной тематики и того реже.

27-29 мая я очно присутствовал на обучении по Kubernetes, которое проходило в Москве. Пока свежи впечатления, хотел бы с вами поделиться полезной информацией и оставить свой отзыв о Слёрм (так называется мероприятие). В целом, мне все понравилось и курс показался полезным, но обо всем по порядку и с подробностями.


Содержание:

1 Что такое Слёрм
2 Для кого подойдет обучение Kubernetes
3 Как лучше участвовать - очно или онлайн
4 Как проходит обучение по kubernetes
5 Общее впечатление от курса
6 Стоит или нет ходить на платные курсы
7 Мои советы для участников
Что такое Слёрм
Онлайн курсы по Микротик
Для начала, что это вообще такое со странным названием. Вот сайт мероприятия - https://slurm.io Там есть вся официальная информация. По описанию трудно оценить, что же на самом деле тебя ждет и как все будет проходить. Я постараюсь подробно обо всем рассказать и оставить свой отзыв.

Слёрм организаторы назвали интенсивом по изучению kubernetes. Лично я не понимал полностью значение этого слова применительно к обучению. Что за такой интенсив, почему не просто курс или обучение. Поучаствовав, я понял, что слово интенсив тут очень уместно :)

Итак, Слерм - это обучение по Kubernetes. Начальный курс (есть и продвинутый - Мега Слерм) рассчитан на тех, кто вообще не знает что такое Kubernetes, но хочет с ним познакомиться и начать работать. Это как раз про меня. Перед обучением я не знал ничего о Кубере, кроме общих обзорных статей, с которыми сталкивался. Никакой конкретики в голове не было.

Отзыв о Слерм

Для обучения очень желательно знать docker и ansible, опционально ceph, но не обязательно, я не знаком вообще. Перед основным интенсивом вы получаете доступ к записанным онлайн урокам по этим темам. В целом, там есть все основы, которых хватит для того, чтобы пройти курс, но могу сказать, что для эффективного освоения Kubernetes, docker и ansible надо знать в объеме бОльшем, чем дается на курсе, иначе вы просто не уложите все в голове за такой короткий период времени.

Я был знаком на среднем уровне и с ansible, и с docker. Предварительные курсы помогли систематизировать знания, узнать какие-то новые вещи. Доступ к онлайн курсам выдается за 3 недели до начала основного обучения по кубернетис, при условии поступления оплаты. Я рекомендую сразу же проходить эти курсы и вникать в предложенные темы, начать пользоваться, чтобы к моменту основного обучения для вас это были привычные инструменты. Так что проконтроллируйте вопрос с оплатой, чтобы не тянуть до последнего момента.

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

Для кого подойдет обучение Kubernetes
После прохождения курса, я могу высказать свои предположения по поводу того, для кого он будет полезен. Слерм на 100% будет полезен тому, кто хочет внедрять Kubernetes, но не знает его достаточно хорошо. Если вы не знакомы с k8s, трудно оценить, что это на самом деле такое. По сути Kubernetes - это огромная технологическая платформа, которую так просто не объять, чтобы однозначно сказать, подходит он мне или нет.

Лично я читал иногда статьи по Kubernetes на хабре и у меня ложилось ошибочное мнение о нем. Приведу пример. Я считал, что Kubernetes можно использовать как распределенный кластер для обеспечения отказоустойчивости сервиса. Я думал, что его можно растянуть на 2-3 независимых ЦОДа и в случае выхода из строя одного, вы не получите простоя. Это ошибка. Так Kubernetes не используют. Для надежной и стабильной работы кластера, он должен быть собран локально в одном ЦОД, а для обеспечения отказоустойчивости сервиса в целом, надо собирать 2 разных кластера в разных цодах и деплоить приложения в оба.

Еще пример. Я предполагал, что с помощью Kubernetes можно каким-то образом решить вопрос с размещением всего сервиса в одном месте. То есть все засунуть в кластер и управлять только им. Так тоже не получится. Как минимум, у вас будет база данных отдельно. Плюс, вопрос с файловым хранилищем тоже будет стоять особняком. Кубер это не про хранение данных. Kubernetes в основном решает вопрос удобного непрерывного деплоя приложений и масштабирования мощностей. Все вопросы он не закрывает. Большое количество сервисов не предназначены для работы в кластере (уже указанные базы данных, кластер elasticsearch и т.д.)

Внедрение Kubernetes дорогостоящая штука. Проще заплатить за обучение и убедиться, что тебе кубер не подходит, чем внедрить его и потом страдать. Плюс, я не упомянул, что сам сервис должен быть готов к размещению в кластере k8s. Он должен быть изначально написан на микросервисах и быть готов к масштабированию. К примеру, если у вас большой и нагруженный сайт на bitrix, кубернетис вам не подходит. Лучше искать другие варианты размещения - балансировщик нагрузки, отдельные сервера и репликация БД. Все эти нюансы вы сможете узнать на Слерме либо из обучения, либо посоветовавшись с ведущими.

Если вы знаете, что Kubernetes вам не подходит, но хотите просто поучиться для общего развития, думаю, что это не имеет смысла. Информации много, она насыщенная и не очень простая для восприятия. Кубер состоит из огромного числа сущностей и абстракций. После обучения, желательно сразу начинать с ним работать хотя бы на тестовом стенде. Если этого не сделать, быстро все забудется. К тому же информация быстро устаревает. Пройти курс в прок на будущее не получится. Через год часть информации устареет и надо будет снова учиться. У меня вообще сложилось впечатление после курса, что если есть желание работать с Kubernetes, то надо фокусироваться только на нем и становиться профильным специалистом. Тема обширная, по касательной ее не захватить.

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

Хорошее погружение в тему. Я не знаю, какие физические законы могут описать мои наблюдения, а они таковы. Когда участвуешь в каком-то мероприятии очно, ты погружаешься в определенную информационную среду, из которой можешь черпать информацию. Создается какой-то специфичный фон, который настраивает и помогает мыслить в нужном направлении. К примеру, я всегда хожу на конференции с блокнотом и записываю мысли по ходу выступлений. Обычно мыслей много и они полезные, приходят как-то сами в голову. Если смотрю записи, то такого эффекта не наблюдаю. То же самое с обучением. В зале ты более сконцентрирован на теме обучения, информация лучше заходит и остается в голове. В эзотерике этот эффект объясняют подключением к определенному эгрегору, который формирует группа людей, думающих об одном и том же.
При личном участии ты можешь с кем-то пообщаться, что-то спросить, с кем-то познакомиться. Получить новую полезную информацию так проще. Насчет знакомств конкретно на Слерме не уверен, что стоит сильно рассчитывать. Формат мероприятия не подразумевает какой-то совместной деятельности, да и просто свободного времени нет. Я пообщался с несколькими людьми, но не могу сказать, что мы сильно познакомились и это прям было очень полезно. Почти все время ты сидишь и занимаешься, перерывы только на поесть, в туалет сходить. Времени знакомиться и общаться почти нет. Было бы интересно организаторам продумать момент насчет совместного банкета или какого-то развлекательного мероприятия после обучения за отдельную плату для желающих. Я бы сходил. На обучении так умаялся, что нужен отдых :)
Ты видишь вообще все, что происходит на мероприятии. Иногда кто-то что-то говорит в зале без микрофона, лекторы отвечают. Что-то еще может происходить за объективами камер. Трансляция может отвалиться из-за технических проблем и т.д. Когда ты в зале, то ничего не пропускаешь и в курсе всех дел и нюансов.
В конце ты получаешь кружку с картинкой Слёрма :)


Минус очного обучения на Слерме:

У меня походный ноутбук небольшого размера с экраном 12,5 дюймов. За ним откровенно неудобно полноценно работать. Плюс, не хватает второго монитора. А в идеале для комфортного обучения надо 3 монитора - лектор, консоль, инструкция или чат.
Надо ехать и тратить время на дорогу. Для кого-то это привычно, но я тружусь обычно удаленно, мне не нравится ездить на метро. Я приезжал к 9.30, обучение заканчивалось где-то в 19.30-20.00 Плюс дорога. Можете сами прикинуть, как вам это подходит.
В зале постоянно что-то отвлекает - кто-то болтает, шуршит, открывает алюминиевую банку газировки и т.д. Удаленно легче концентрироваться на учебном материале.
Описал субъективные впечатления от разных форм обучения. Я бы лично так поступал. Если живешь в Москве - можно ехать и участвовать очно. Если в другом городе - подойдет и онлайн обучение. Как мне кажется, для восприятия информации одинаково подходят оба формата. Я смотрел записи трансляций. Они выполнены на хорошем уровне. С учетом того, что зал большой, участников много, где-то 2/3 из участников в зале сами сидят и смотрят на лектора в трансляцию, которая идет через проекторы и экраны на стенах.

Конечно, если вы едете за счет работодателя, то можно и приехать из другого города, но будьте готовы к тому, что Москвы вы не увидите. У вас не будет для этого времени, либо надо закладывать лишний день. В общем случае, у вас будет так - приехал в Москву, пошел на обучение, вернулся в гостиницу, лег спать. Второй день встал, пошел на занятие, вернулся, лег спать. Третий день отучился, ухал на вокзал, сел в поезд. Обучение интенсивное (не зря же интенсив называется :), занимает все время.



Как проходит обучение по kubernetes
Слёрм проходит в интересном формате. Тут я удивился грамотному и удобному подходу. Каждому участнику Слерма выдается свой логин и пароль, с помощью которого он получает доступ к:

Предварительным курсам по ansible, docker и ceph;
Git репозиторию со всей текстовой информацией, презентациями и практическими заданиями;
Общему серверу с уже настроенным и работающим кластером Kubernetes;
Кластеру с несколькими виртуальными машинами, где вы будете настраивать свой кластер.
Доступ ко всем указанным ресурсам удаленный, можно в любой момент подключиться из дома после занятий. Плюс, какое-то время все или частично доступно до курса и после.

Вы приходите в зал для обучения, там есть интернет по wifi. В первый день он немного подглючивал до обеда, но потом все нормализовалось. Подключаетесь по ssh к серверам и выполняете команды на них. Обучение идет в таком формате - сначала лектор немного рассказывает, потом идет в свою консоль, вы за ним в свою и начинаете выполнять различные команды. Сначала за лектором повторяете, в конце обычно небольшое практическое задание, которое нужно выполнить самостоятельно, не простым копипастом, а немного подумав и изменив конфиги.

Обучение по kubernetes

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

Лично у меня не возникало сложностей с заданиями. Выполнял их достаточно легко и в срок. Из наблюдений, не получалось в основном у тех, кто либо не внимательно слушал, либо ошибался в синтаксисе команд, либо просто не хотел соображать от усталости :) Плюс, я все новые команды сразу записывал себе в текстовый файл и потом в них не путался, а копировал из него. Это существенно ускоряло процесс и способствовало запоминанию. Видел, как окружающие либо набирали команды, глядя на консоль лектора, а с нее не скопируешь, либо пытались найти эти команды в чате, куда их иногда постили, либо в материалах обучения. Все это отнимает время и внимание. Свои замечания по поводу того, как улучшить этот момент, отправил организаторам.

В процессе обучения kubernetes случались перерывы. Их было достаточно много:

2 перерыва по 10 минут на туалет, курение.
2 перерыва по 15 минут на кофе-брейк, где можно было перекусить сэндвичами и попить чай, кофе, морс.
1 перерыв 60 минут на обед.
Отдельно хочу рассказать про воду, питание. Ехал на курс в первый день, думал, надо бы водички купить, что-то перекусить взять. На всякий случай зашел перед занятиями в кафе, перекусил, чтобы не отвлекаться на голод. Думал, мало ли, как там и чем покормят. Опасения были напрасны. Этот вопрос хорошо проработан. В зале для всех была вода и кола в неограниченном количестве. В кофе-брейки было много сэндвичей и печенья, плюс напитки. Все с избытком, хватало всем и было вкусно. Обед тоже вкусный и сытный, много блюд на выбор (шведский стол). То есть вопрос с питанием проработан полностью, можно не переживать и не думать об этом. Брать с собой ничего не надо, воды-еды хватило всем с запасом. Кормили в гостиничном ресторане.

В конце обучения по kubernetes у меня был настроен свой кластер с возможностью CI/CD через gitlab. Последнее мне было интереснее всего, так как просто не знал, как это полностью выглядит на практике, от тестов до деплоя. До этого что-то сам колхозил по своим представлениям. Увидел всю цепочку, как после коммита разраба в репозитории, выкатывается приложение в кластер. Задал несколько вопросов по ходу и как мне кажется, в голове сложилась полная картина того, как все должно быть устроено. Получается, что не зная Kubernetes до этого, на Слерме я научился поднимать кластер и деплоить в него приложение.

В последний день, сразу после курса, пришел домой и попробовал собрать кластер на своем железе. Сидел до трех ночи, пока виртуалки подготовил, пока все настроил. Не получилось сходу, но в процессе начал разбираться, открыл лекцию и запись занятия, понял в чем ошибка. Буду пробовать еще раз, как время появится. Надо окружение заново поднимать. То есть общее представление появилось и с этим уже можно двигаться дальше. Думаю, что в будущем напишу статьи по Kubernetes, если зайдет нормально. Применить в проде есть где, но надо сначала на тестах посидеть и освоиться.

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

После участия, стала понятна цена. На мой взгляд, она абсолютно оправдана. Могу это сказать, посмотрев на весь процесс. Возьмем просто 3 дня обучения по 8 часов = 24 часа. Сюда добавляем аренду зала, оборудование, еда, куча сотрудников, которые все это организовывают, железо для тестовых стендов и многое другое. Сравните это с полностью онлайн обучением в пересчете на часы. Я прикинул и оказалось, что Слёрм дешевле, хотя сначала так не кажется. Речь идет именно о Слёрм. Есть еще Мега Слёрм, но я там не был. Это для тех, кто уже админит Kubernetes.

Теперь отдельно о формате обучения. Оно действительно интенсивное. Обязательно необходимо отложить все дела на эти 3 дня и ни о чем не думать. Все внимание на Слерм. Я сделал именно так. В первый день меня немного отвлекли дела и я сразу стал выпадать из процесса. Удалось порешать все моменты в обед и больше не отвлекался. Это важно. Информация новая и насыщенная. Нужна полная концентрация и внимание.

Курс по kubernetes

Лично мне было учиться сложнее, чем работать. Я приезжал домой очень уставшим и не хотел больше ничем заниматься. Я ужинал, немного тупил со смартфоном и ложился спать. Семья была на даче, так что никто не отвлекал. После второго дня мне ночью приснился мой кластер. Понял, что материал зашел в подсознание :) То есть обучение в таком формате это тяжелый труд, надо быть к этому готовым. Не знаю, может возраст уже сказывается, труднее осваивать новое (мне 35), но у меня было так. Я отнесся серьезно и искренне хотел освоить то, чему учился, поэтому старался. В итоге остался доволен и удовлетворен результатом.

Может показаться, что курс слишком интенсивен и уместить его в 3 дня не очень удачная идея. Я подумал над этим и все же понял, что нет, такой формат то, что надо. С одной стороны, информации много и ее трудно усвоить в голове за такой короткий срок. Но если растянуть на 4-5 дней, то участие будет более затруднительное. По моим наблюдениям, основной контингент это люди 27-40 лет. А в этом возрасте трудно выделить неделю только на обучение, есть семья и работа. Лично мне пришлось очень серьезно перекроить свой график, чтобы выделить эти 3 дня. Наверное, 4 дня я бы смог еще как-то выкроить, но это было бы слишком трудно. Неделю я бы не выделил точно и на обучение не пошел.

Еще несколько коротких наблюдений в отзыв по участию в Слёрме:

Понравились ведущие - Павел Селиванов и Сергей Бондарев. Очень харизматичные и такие разные люди. Лично мне слушать их было приятно и интересно, получился отличный дуэт. Умение интересно рассказывать это особый талант. У Сергея отличное чувство юмора :)
Мне было очень интересно посмотреть на ноуты админов и на их рабочее окружение. Был сильно удивлен вот чем - очень много ноутов с ios и linux. Мне показалось, что разделение было примерно равно между windows/linux/ios.
Те, кто были с ноутами apple в основном не пользовались мышкой, из чего сделал вывод, что там очень удобное управление через тачпад. Среди ноутов много моделей Thinkpad. У меня тоже такой, реально удобная техника.
Еще обратил внимание на большое разрешение экранов, при не очень больших размерах. У меня 1366x768 при 12.5 дюймах и это мне кажется оптимальным для такого размера. У большинства разрешение выше и все очень мелкое. Мне показалось это неудобным.
В середине первого дня организатор обратился к ученикам и предложил вернуть деньги тому, кому не заходит обучение и он хочет покинуть мероприятие.
В целом, понравилась атмосфера. На занятия хотелось идти, а сейчас, когда в наш чат по ошибке попадают сообщения из Мега Слёрм, который проходит сразу после Слёрма и идет в данный момент, захотелось снова туда приехать :)

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

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

Конкретно по Kubernetes я вообще не знал, с чего начинать. Информация чаще всего общего характера. Каких-то подробных how to для новичков я вообще не видел. Теперь понимаю, почему. Прежде чем начать что-то делать, нужно разобраться с теорией. Кубер это не nginx, где взял пример конфига и пошел пробовать. Его чтобы просто собрать, надо потрудиться, очень много компонентов и связей между ними.

Мои советы для участников
Онлайн курсы по Микротик
Подытоживая все сказанное в отзыве, краткая выжимка советов для тех, кто будет участвовать в Слерме для изучения kubernetes:

Заранее пройдите подготовительные курсы по docker и ansible. Поработайте с ними хоть немного, чтобы получше ориентироваться.
Настройтесь на рабочий лад и освободите голову от всех проблем и задач на время обучения.
Организуйте хороший сон, чтобы быть к началу обучения бодрым и готовым к труду.
Отключите на мобильнике интернет и звук во время обучения.
Подготовьте ноут к занятиям - запишите все доступы к ресурсам, ссылки на материалы, настройте ssh подключение, чтобы потом не тратить время в процессе. Темп занятий высокий.
Подготовьте личный тестовый стенд или подумайте об его подготовке, чтобы после занятий сразу начать практиковаться.
Вот в общем-то и все, что хотел написать по поводу своего участия в Слерме. В целом, мне реально понравилось и если есть желание изучать kubernetes, то я могу порекомендовать Слерм для этого. Думаю, у меня будет возможность поучаствовать в онлайн обучении по куберу в формате двух часовых занятий 2 раза в неделю от другой организации. Попробую договориться с организаторами и сравнить эти два разных формата. Потом поделюсь мнением.

Следующий Слёрм будет в Питере с 9 по 11 сентября, причем в конференц зале Selectel. Информация об этом уже есть на странице мероприятия - https://slurm.io Если есть желание участвовать и изучать kubernetes, планируйте заранее. Судя по тому, сколько людей было на этом Cлерме, подозреваю, что мест всем желающим не хватит. Их сейчас заявлено только 100 для очной формы.

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

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

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

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

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

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/) за этот тренинг!

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

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