Слёрму полтора года. Шесть интенсивов только по базовому курсу 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. Участие, как и во всем теоретическом цикле, бесплатное. Регистрируйтесь по ссылке и присоединяйтесь. Добро пожаловать!
Goron_Dekar
Хабровчане, вас не задевает такая стрёмная попытка форсить это дурацкое словечко?
Что за опус от Southbridge не читаю, ощущение, что иду как по шпалам рельсов: постоянно спотыкаюсь об эти повторы «слёрм слёрм слёрм».
Обычно в русском языке когда описывается какой-нибудь объект, то его принято называть по-разному, используя синонимы. А тут какой-то SEO.
ak394078
Черт возьми, полностью согласен! Ощущение какого-то нездорового пропихивания! Немного начинает раздражать…
nckma
Причем из статей мало понятно, что это это такое…
gatoazul
У меня только ассоциация с песней Little Big «Слёрмятся пацаны»
achekalin
Меня лично очень. Писал про это два коммента, одному поставили плюсы, в второй остался с минусами. Не знаю, видимо, чувство слова у всех разное (дажн к такому!)
Слово какое-то склизкое, что ли. Неприятное. Много раз подряд его сказать как-то не тянет. И что оно не просто так, а так же называется некое ООО, то это лишь показывает, что кому-то и такое словечко «норм».
artem_kramov
Наверное, автор этого названия фанат Футурамы — в этом мультсериале Слёрм обозначал напиток, к которому у главного героя было привыкание. :)