Как перестать бояться оркестрации и полюбить k8s

Задумываетесь о нырянии с головой в бездны k8s? 28 июля стартует новый поток курса «Kubernetes Мега», где мы с коллегами разбираем k8s по полочкам и учим не просто деплоить ямлы, а рассказываем, как оно работает внутри.

➡️ «Kubernetes Мега» может быть вашим выбором, если:

🔷 Вы устали изучать тонны yaml. Курс погружает в архитектуру k8s, раскрывая внутренние механизмы работы Control Plane, kubelet и других компонентов.

🔷 Вам нужно глубокое понимание для поддержки сложных инсталляций. Качественный курс часто является отличным способом систематизировать знания и подготовиться к более сложным и интересным задачам.

🔷 В вашей команде не хватает экспертов по Kubernetes, и вы хотите поднять общий уровень. Коллективное обучение может быть отличным способом выровнять знания в команде ваших k8s инженеров.

➡️ «Kubernetes Мега» не подойдет вам, если:

🔷 Вы ожидаете, что можно просто пройти теорию и получить сертификат. Теория без практики не позволит закрепить знания. На курсе делаем много практических занятий, где можно руками пощупать разные механизмы k8s.

🔷 Вы ищете готовые рецепты и «серебряные пули». k8s — сложная платформа, и универсальных решений не существует. Курс научит вас самостоятельно выбирать подходящие решения в зависимости от контекста, а не просто копировать готовые конфиги.

🔷 У вас нет базовых знаний о контейнеризации и DevOps-практиках. k8s — это не для новичков. Перед курсом стоит изучить основы Docker, Linux и попрактиковаться с базовыми инсталляциями k8s. Для этого можно пройти k8s база.

На днях делился с вами подробным отзывом от выпускника курса Павла Елецкова, руководителя направления Kubernetes компании «СБЕР Спасибо». Дублирую ссылки для тех, кто пропустил, чтобы вы могли получить представление о курсе не только со стороны спикера, но и со стороны студента:

➡️ YouTube
➡️ VK Видео

Обучение на курсе может стать полезным вложением, если вы готовы активно учиться и применять полученные знания на практике. Старт потока уже в понедельник. Занимайте места по ссылке!

Kubernetes Мега: 3 дня до старта

Новый поток продвинутого курса по k8s стартует уже в понедельник. Осталось 3 дня, чтобы запрыгнуть в последний вагон и уже осенью добавить в резюме новые компетенции.

После курса вы сможете:

🔷 Привести «зоопарк» инструментов к управляемой экосистеме, повысить отказоустойчивость продукта и автоматизировать развёртывания

🔷 Использовать все возможности k8s при проектировании платформенных решений и уверенно переводить продукты компании на k8s

🔷 Сдать сертификацию и получить свидетельство установленного образца, которое можно прикрепить к резюме

Первым трем, кто пройдет курс на 80% и сдаст сертификацию, дарим эксклюзивную сессию 1-1 с Павлом Елецковым, Teamlead k8s в СберСпасибо и ментором курса.

На ней вы сможете:
➡️ Разобрать свой рабочий кейс и получить прикладные советы
➡️ Прокачать резюме для топовых вакансий
➡️ Пройти mock-интервью, чтобы быть готовым к реальным вызовам

Дополнительные модули для всех, кто прйдет курс на 80% и сдаст сертификацию к последней встрече:

🐈 Мониторинг и трассировка сервисов с Istio
🐈 Безопасность в Kubernetes с Istio
🐈 Canary and A/B Deployments

Узнать подробности и занять место на потоке — по ссылке. Подключайтесь, прокачать свои навыки и вырасти в должности и зарплате!

База или мега? Всё сразу, и побольше!

Замахнулись на k8s? Отлично, их есть у нас! Но не спешите, тут нужен систематический подход.

Есть два стула пути:

🔷 Для тех, кто в теме

Если вы на k8s уже собаку съели, то вам прямая дорога на «Kubernetes Мега». Поток стартует уже сегодня, и присоединиться к нему можно до конца недели. Там такое покажут, что ваши кластера сами себя настраивать будут! Разберете внутренности scheduler, научитесь строить операторы одной левой и многое другое. Готовьтесь, будет хардкор, но оно того стоит. А детальнее про то, для кого мега, я уже рассказывал в этом посте.

🔷 Для тех, кто начинает свой путь в мир k8s

Если k8s для вас — это что-то страшное и непонятное, не паникуйте. Есть «Kubernetes База». Поток стартует 4 августа. Там вас за ручку проведут по основам: какие абстракции есть, как все это применяется, как деплоится и раскатывается в кластер, как мониторится, и, конечно же, как начать — раскатать ваш первый кластер и заботиться о нем, как я о Маркусе, чтобы не нашкодил.

🐈 На самом деле, есть еще третий путь — для тех, кто хочет сразу на двух стульях усидеть. Это комплект из потока «Kubernetes База» и видеокурса «Kubernetes Мега». С ним вы сможете прокачать свои навыки с нуля до уровня «Бог k8s» — со скидкой 20%.

Подробности — по ссылке.

И совет напоследок: k8s — это не rocket science, но и не игра. Не бойтесь копаться в YAML, экспериментировать, ломать и чинить (только не в проде, пожалуйста). Только так можно по-настоящему понять, как все работает.

k8s база: рассказываем то, что нельзя нагуглить

«Kubernetes База» — это не просто k8s для начинающих инженеров, которые решили связать свой профессиональный путь с эксплуатацией k8s.

Это путь от базовых понятий до работающего приложения, развернутого с учетом best practices. Мы не просто крутим kubectl apply, а выстраиваем понимание концепций, а не конкретных решений, чтобы применять на своих проектах с учётом особенностей проектов.

С ней вы сможете самостоятельно выбирать более подходящие инструменты экосистемы k8s под ваши проекты и не переусложнять там, где нет на то реальной необходимости.

➡️ Вместо перечисления компонентов — погружение в то, как они взаимодействуют. Не «Node состоит из kubelet, kube-proxy, etc.», а «Почему kubelet нужен, чтобы Pod вообще запустился, и как kube-proxy разруливает трафик до этих Pod'ов, даже если их IP меняются».

➡️ Не просто «Deployment управляет Pod'ами», а «Как Deployment использует ReplicaSet для rolling updates?». Понимание StatefulSet'ов и DaemonSet'ов для специфических workload'ов.

Также обязательно рассмотрим, как раскатывать свой кластер на bare metal, и что нам это будет стоить с точки зрения дальнейшей поддержки.

Само собой, ни один production кластер не обойдется без выстроенных процессов доставки приложений и надежного мониторинга. Под эти темы выделены отдельные модули про CI/CD и про, что бы вы думали? Конечно, мониторинг.

А еще на курсе есть 5 Q&A сессий со спикерами, где вы сможете разобраться ваши кейсы от экспертов, которые крутят k8s уже много лет, и повидали всякого, о чем в приличном обществе не принято рассказывать, потому что темы строго 18+, и иногда такое увидишь, что волосы дыбом встают, как это вообще еще не сломалось. А всего лишь надо было следовать лучшим практикам и соблюдать требования, указанные в документации.

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

Поток стартует 4 августа. Занять место можно по ссылке. Присоединяйтесь, если хотите разобраться в работе k8s и получить востребованные скиллы.

Сколько зарабатывает SRE в Нидерландах?

Рассказал на интервью для пилотного выпуска спецпроекта «DevOps про деньги».

Ведущий: Всеволод Севостьянов, Staff engineer в Lokalise.

Что обсуждали:
➡️ Какие навыки нужны SRE в бигтехе?
➡️ Требования в вакансии vs реальные рабочие задачи: есть ли разница?
➡️ Главный вопрос: сколько получает SRE в Амстердаме, и за что столько платят?

Посмотреть можно тут:
🟠YouTube
🟠Rutube
🟠VK Видео

А всех, кто после просмотра захочет двигаться в направлении подобных задач (и подобных зарплат, конечно же) — приглашаю на «Kubernetes База». Старт 4 августа!

Отзывы студентов

Принес вам отзыв на курс «Kubernetes База» от сотрудника Т-Банка:

От pod'а до prod'a за 1.5 месяца

Только что закончил обучение на курсе от Slurm. Полтора месяца и я освоил навыки работы в Kubernetes и даже прошёл сертификацию. Экзамен для которой длился аж 6 часов.

Зачем мне к8s?

Моей главной целью на курсе было научиться деплоить приложение в кластер, чтобы затем настроить СІ/СD pipeline, который бы сам поднимал стенд с новой версией приложения, запускал имеющиеся автотесты и принимал решение о деплойменте приложения.

Стоит ли тебе его проходить?

В курсе разобрано множество тем k8s, начиная с основных компонентов и устройства кластера, заканчивая непрерывным деплойментом приложения с помощью Gitlab-Cl и helm- чартов.

Для каждой темы курса предлагается выполнить практическое задание на реальном к8ѕ кластере (battery included), с автоматической проверкой решения, что в свою очередь помогает быстрее закрепить знания на практике. (Отмечу, что опыт решения этих задач уже пригодился мне в реальных задачах).

На курсе есть возможность обратиться в тех-поддержку slurm, если возникают сложности с решением заданий. (Мне отвечали в течение 5 минут.) Дополнительно, для потока был создан tg-канал, где куратор и ведущие курса, а иногда студенты потока помогают с решением возникших вопросов.

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

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

➡️ Если вы не знаете, как подступиться к k8s, с чего начать и как перейти на него в своих проектах — начните со структурированных знаний, которые мы даем на курсах. Так вы сможете разложить все по полочкам и начать работать с k8s с минимальным количеством трудностей.

🔷 Старт ближайшего потока «Kubernetes База» уже в понедельник. Подробности — на сайте.

*Орфография и пунктуация автора отзыва сохранены.

Kubernetes База: старт уже в понедельник!

Осталось три дня, чтобы вкатиться в новый поток стартового курса по k8s и получить востребованный скилл уже через полтора месяца.

Что внутри:

🟣 6 недель обучения, 63 часа практики и 23 часа теории
🟣 73% программы — работа со стендами для отработки практических навыков
🟣 5 Q&A-встреч со спикерами курса
🟣 Сертификация по итогу обучения, закрепляющая весь пройденный материал

Присоединяйтесь к потоку, чтобы уже в сентябре уметь работать k8s, кластерами и CI/CD.

➡️ Подробности — на странице курса.

Kubernetes База: поток стартовал!

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

Ближайшие 6 недель будем разбираться с основами работы с k8s, базовыми абстракциями кластера, запуском приложений в кластере и принципами их работы.

➡️ Сегодня еще можно присоединиться к потоку. Ссылка для опоздавших: https://to.slurm.io/4EbSIQ

А для тех, кто хочет сразу прокачать свои навыки до продвинутого уровня и получить полный контроль над своей контейнерной инфраструктурой, мы с командой подготовили комплект:

Kubernetes База (поток) + Kubernetes Мега (видеокурс) со скидкой 20%.

Подробности — на сайте.

Что будет, если k8s исчезнет?

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

Мне лично и представлять не надо, я там был. И ничего хорошего в общем случае в этом нет. Два приложения с разными версиями системных библиотек → доигрались, сломали одно из них. Обновили ОС → положили все проекты на этом сервере.

➡️ Усаживайтесь поудобнее, дед побухтит, почему виртуализация и контейнеризация в современном мире это просто must have, и почему раньше было тоже неплохо.

Раньше как было? Берёшь каталог с PHP файлами, заливаешь по FTP на сервер, и вроде работает. Но времена изменились. Бизнес требует скорости, надежности, и масштабирования. 20 лет назад почти не было IT компаний с сотнями миллионов пользователей.

Почти не было. Были google, yahoo и другие гиганты, но большинство компаний так или иначе не требовали того масштаба. Да и сейчас некоторым это не нужно. Например, представьте небольшую сеть пиццерий с доставкой с приложением на php монолите. И это будет неплохо работать, особенно если поднять пару реплик приложения и добавить auto failover для БД.

➡️ В современном мире, если продукт упал, это уже не просто «ой, извините», это вполне ощутимые финансовые потери.

Без k8s вся эта история превращается в адский ручной труд.

🔷 Развёртывание

Забудьте про GitOps и пайпланы выкатки. Придётся писать скрипты, плейбуки, или вообще руками всё настраивать на каждой виртуалке или bare metal.

🔷 Масштабирование

Нужно больше мощности? Опять ручками поднимать новые серверы, настраивать балансировку. Никакой тебе горизонтальной автомасштабируемости по CPU или памяти.

🔷 Отказоустойчивость

Сервер упал? Сидишь и молишься, чтобы бэкап сработал и чтобы всё поднялось как можно быстрее.

🔷 Управление конфигурацией

Хранить конфиги, секреты, переменные окружения в разных местах, помнить, что где лежит, и постоянно синхронизировать? k8s централизованно управляет конфигурацией, упрощая жизнь и уменьшая риск ошибок.

🔷 Мониторинг и логирование

Собирать метрики и логи с кучи серверов вручную — то ещё удовольствие. В k8s можно выстроить нормальный процесс доставки логов.

А как вы делали деплои до k8s?

Как k8s scheduler помогает экономить ваши деньги

Поговорим про стратегии оптимизации расходов на ваши кластеры, и как в этом помогает scheduler. Вы наверняка знаете, что scheduler определяет, на какую ноду назначить pod. Но его также можно использовать для оптимизации затрат.

У scheduler есть много различных плагинов, нам интересен NodeResourcesFit. Он выполняет скоринг нод на основе того, сколько ресурсов на ноде доступно.

У плагина есть 3 стратегии выбора:

1. LeastAllocated (default) — в первую очередь смотрим неутилизированные ноды. Очевидное значение по умолчанию, которое подходит в большинстве случаев.
2. MostAllocated — выбираем уже нагруженные ноды. Однако всё ещё учитываются требования к ресурсам на основе заданных requests.
3. RequestedToCapacityRatio — измеряет «жирность» ноды по отношению к запрошенному количеству ресурсов. Больше ресурсов требуется поду → более «жирная» нода будет выбрана.

➡️ Зачем это нужно? Очень легко взять 30 нод в облаке и утилизировать их суммарно на 40%, при этом все ноды всё равно будут держать N-е количество подов. Никто не будет простаивать, но недоутилизация получается огромная.

Что можем сделать, да и ещё так, чтобы текущие запущенные нагрузки не пострадали?

🔷 Первое — определить кастомный шедулер

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: custom-scheduler
    pluginConfig:
      - args:
          scoringStrategy:
            resources:
              - name: cpu
                weight: 1
              - name: memory
                weight: 1
            type: MostAllocated
        name: NodeResourcesFit
    plugins:
      score:
        enabled:
          - name: NodeResourcesFit
            weight: 1

🔷 Второе — определить права доступа, deployments и так далее и задеплоить кастомный шедулер. Все детали можно найти в официальной документации либо почитать более конкретный use case оптимизации расходов на eks кластер.

🔷 Третье — при помощи kyverno/opa, или вручную, если сервисов немного, перевести все нагрузки постепенно на кастомный шедулер, мониторя распределение нагрузки по нодам. Для этого достаточно в подах указывать кастомный schedulerName

apiVersion: v1
kind: Pod
metadata:
  ...
spec:
  schedulerName: custom-scheduler
  ...

А если что-то не устроит с точки зрения распределения подов по нодам, всегда можно заменить обратно на default-scheduler.

🔷 Ну и четвертое — радуемся сэкономленным ресурсам и уменьшаем размеры кластера. Конечно же, если полученное распределение подов и нагрузка на ноды вас устраивают.

➡️ Важный нюанс: MostAllocated и RequestedToCapacityRatio могут приводить к неравномерному распределению нагрузки по нодам. Все зависит от характера вашего проекта и корректности выставленных ресурсов для подов.

Какие кейсы тюнинга настроек scheduler вы встречали на практике?

Когда 200 OK ничего не значит для liveness

Во многих проектах есть фоновые процессы, которые читают очередь и выполняют полезную работу. Добавлять http probe, которая всегда отвечает 200 OK, ничего не проверяя, бесполезно.

Приложение может застрять на обработке сообщения по разным причинам и pod никуда не денется, а очередь будет расти.

🟠 Note: здесь мы не смотрим на кейсы, когда сообщение в принципе не может быть обработано и должно улететь в dead letter queue, а скорее на возможные баги в приложениях, которые решаются рестартом pod’а.

Конечно же не только http-пробами живет народ. Есть максимально топорный подход – проверять modification time для пустого файла.

➡️ Ваш воркер после обработки каждого сообщения делает аналог touch somefile . Например, так:

with open(HEALTH_FILE, "a"):
    os.utime(HEALTH_FILE, None)

➡️ А liveness-проба делает простой exec:

livenessProbe:
  exec:
    command:
    - /bin/sh
    - -c
    - "find $HEALTH_FILE -mmin -5 | grep -q '.'"
  initialDelaySeconds: 30
  periodSeconds: 60
  failureThreshold: 1

🔷 -mmin -5 говорит нам, что liveness-проба провалится, если файл не обновлялся в течение 5+ минут. Конечно же, значение нужно выбирать с учётом характера ваших нагрузок.

Дотошные читатели скажут, что можно и http-сервер добавить в приложение, чтобы health endpoint проверял время обновления файла, и будут правы, однако это может означать лишнюю зависимость в приложении только ради liveness-пробы.

Это зависит от используемого языка, потому что в golang, например, http-сервер доступен нативно без внешних зависимостей, и в этом случае может быть проще прослушивать порт для liveness-пробы.

Time management done right

Как выходит так, что все работают 8 часов, но кто-то делает больше, а кто-то меньше? Есть ли магические способы успевать больше за то же самое время?

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

🟠 Календарь — твой бро
Выделять в календаре слоты focus time хотя бы на 2 часа в день. За 2 часа сфокусированной работы можно сделать больше, чем за 6 часов, которые перекрываются всего парой встреч. Часовая встреча может требовать подготовки к самой встрече, к формированию follow up после встречи, — и вот уже запланированный час в zoom превратился в полтора часа.

🟠 Длительность встреч
Часовая встреча не даст больше, чем 50-минутная, но позволит отдохнуть между встречами и приготовиться к следующим.

🟠 On time
Подключаться к встрече в течение 5 минут, ждать, пока все соберутся, — и так каждый раз. Этого нужно избегать и всеми силами стремиться сделать точный тайминг, чтобы не тратить время на сборы. В этом помогает сокращение часовых встреч до 50-55 минут, когда встречи накладываются.

🟠 Тайминг
Не успели все вопросы решить за выделенное время — не надо сидеть ещё полчаса. Лучше решить вопросы асинхронно либо договориться встретиться ещё раз.

🟠 Followup
Встреча без результатов — пустая трата времени и денег. Со встречи нужно выходить с задачами, с назначенными ответственными и всё закреплять в тексте.

🟠 А нужна ли встреча? 
Прежде чем отправить инвайт, задайте себе вопрос: «А можно ли это решить парой сообщений в чате?». Не все вопросы требуют созвона. Иногда достаточно тикета или короткого сообщения в Slack.

🟠 Oncall — это святое, но... 
Если ты oncall, это не значит, что ты 24/7 в Slack. Может ты занят решением инцидента. И не стесняйся эскалировать, если чувствуешь, что зашиваешься.

Весь этот набор приёмов мне помогает выстраивать процесс, где можно успеть и код пописать, и вопросы обсудить.

А как у вас с этим обстоят дела? Поделитесь своими подходами⬇️

Liveness пробы. Часть 2

Недавно рассказал про liveness probes для фоновых воркеров. Сегодня же расскажу, как делать правильно, чтобы liveness probes не стали причиной проблем для ваших приложений.

🔷 Начнём с простого, о чём и так пишут на каждом столбе.

Проверять в liveness probe доступность вашей базы данных или любых других внешних зависимостей — плохая идея. При проблемах с БД liveness скажет «fail», это приведёт к перезапуску подов — привет рост нагрузки на БД из-за установления новых соединений. Это может только ухудшить ситуацию для и без того нагруженной БД.

🔷 Перейдём к ситуации с сильно нагруженными приложениями.

Если ваше приложение многопоточное, выделите отдельный thread pool только для обработки Liveness Probe. Основная причина — избежать ситуации, когда все потоки заняты обработкой пользовательских запросов, и liveness probe просто не может выполниться вовремя. Это может привести к ложным перезапускам.

🔷 А также посмотрим на ситуацию с точки зрения безопасности.

Может быть оправдано вынесение liveness probe на отдельный порт. Представьте, что мамкин хакер может получить доступ к API endpoint, на котором висит liveness probe, а вы решили туда выводить дополнительную информацию.

Например, actuator в spring boot может отдавать не просто 200 OK, а информацию, которую не стоит светить наружу, а вы смотрите туда в случае проблем с целью быстрого анализа состояния приложения.

Выделенный порт для liveness probe позволяет случайно не раскрыть внутренние API endpoints через ingress.

/metrics для prometheus тоже стоит вешать на отдельный порт — именно для избежания случайного раскрытия информации.

Напоследок, базовые советы, как не устроить рестарт приложения на ровном месте.

➡️ Слишком короткий initialDelaySeconds.
Не все приложения стартуют мгновенно и иногда лучше дать время на прогрев.

➡️ Агрессивный failureThreshold.
Не нужно перезапускать под после первой же неудачи. Дайте ему ещё один шанс.

➡️ Редкий periodSeconds.
Если проверять приложение раз в 10 секунд с failureThreshold=3 , то может потребоваться минимум 30 секунд на то, чтобы kubelet заметил проблему.

Самые жесткие факапы в моей карьере

Поделюсь с вами историей, как я почти уронил production.

🐈 Действующие лица: я, пачка нод с PostgreSQL и ни одного контейнера.

🐈 Контекст: проект выглядел как набор сервисов на php/symfony, где для каждого клиента выделялся отдельный инстанс PostgreSQL. Конечно же, это требовалось только для «жирных» клиентов, а небольшие вполне прекрасно уживались на N коммунальных нодах с PostgreSQL. Никаких k8s или docker, времена были тёмные. Все деплоилось поверх AWS EC2 инстансов.

🐈 Задача: реализовать возможность поиска по геоточкам для специфического юзкейса. Для этого был создан функциональный индекс, покрывающий это конкретное требование.

Выглядело это приблизительно так:

CREATE INDEX myindex ON mytable USING GIST (column::geometry);

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

➡️ И вот фича почти готова, запрос оттестирован, и тут выясняется, что какая-то специфичная функция, которая лучше подходит для этой задачи в postgis, требует тип данных не geometry, а point.

В итоге, строка в коде, которая была проверена и выглядела изначально так:

WHERE mycolumn::geometry ...

превратилась в:

WHERE mycolumn::point

Запрос, конечно, был гораздо сложнее.

К чему привело?

Конечно же, к незадействованному индексу, а на dev окружении этого не отследить, там данных мало и все API, вызывающие под капотом этот запрос, отвечают быстро.

Выкатка в прод:
1. Накатили миграцию через скрипт, создали индекс во всех БД
2. Накатили код с изменениями
3. Получили жесточайшую просадку по latency. 0.1 s → 100 s для понимания масштаба.

А код откатить? Ну да, возможно, но процесс выкатки тоже небыстрый. Так что клиенты начали жаловаться, минут за 10-20 всё пофиксили, перенакатили индексы и всё заработало.

Как можно было бы решить?

➡️ Внятное code review, которое позволит найти такие кейсы.
➡️ В 2025 — AI ревью, которое сможет найти такие кейсы.

Поделитесь, какие самые жесткие факапы вы допускали в своей карьере?

Есть кто соскучился по лайвам? 🐈

Предлагаю встретиться завтра)
Будем обсуждать AI adoption вместе с Павлом Герасимовым, Senior Engineering Manager, который отвечает за Growth Unit в компании Wrike.

На встрече:
⚫️ Разберём, что AI действительно ускоряет и почему без нужных скиллов можно ускориться в кирпичную стену.
⚫️ Поговорим о судьбе сеньоров, джуниоров и техлидов в новой реальности: кто выгорит, кто расцветёт и как изменятся роли.
⚫️Обсудим фреймворки внедрения AI (Utilization + Impact + Cost) и реальные кейсы — от AI-портала и автоматизированного код-ревью до собственного MCP-сервера.
⚫️ Обсудим гипотезу о новом буме IT-зарплат через роль Product Builder, где один человек может давать бизнесу импакт на сотни тысяч ARR.

➡️ Когда: в четверг, 14 августа в 19:00 мск

Регистрация не нужна. Просто проверьте, чтобы уведомления были включены, чтобы не пропустить начало трансляции.

Прямой эфир через 3 часа

🐈 В силу обстоятельств непреодолимой силы лайв проведём здесь.

С Павлом Герасимовым обсудим AI adoption и как к нему подойти. Разберём, что именно ускоряет AI, дилемму, что случится с сеньорами, джунами и техлидами, а также возможный новый бум IT-зарплат.

С вас — зайти по ссылке в 19:00 по Мск, регистрироваться не нужно. Запись планируем👌

Мы стартуем лайв по AI adoption

➡️А вы подключайтесь по ссылке⬅️