Как мониторить сложные пайплайны

Думаю, вы встречались с задачей: надо получить алерт, когда сервис начнет 500-тить. Или когда latency вырастет за пределы 500 мс.

А вот с фоновыми джобами всё хитрее. Никакое API не ждёт ответа, но вот время прохождения данных через весь пайплайн — важная метрика. А ещё пайплайн обработки может состоять из десятков джоб, которые пишутся разными командами, да и процесс может занимать не секунды, а часы. А то, как они связаны друг с другом и кто от кого зависит — любимое развлечение на вечер, если готовы раскопать, кто начал генерировать мусор. Но это уже тема отдельного разговора.

Вернёмся к тому, как следить за сложными пайплайнами.

➡️ Простое решение — алерты на длину очереди. Работает в простых ситуациях, но фиксированный threshold — неудобно и может алертить даже тогда, когда проблем нет.

➡️ А что лучше?
Мониторить то, что действительно важно — сколько времени данные проводят в пайплайне. Сравниваешь метку времени инджеста пачки данных в начало и когда они вышли в конце — вот и время обработки. Если данные идут непрерывным потоком, этого достаточно. Если же бывают паузы, добавляешь heartbeat сообщения, чтобы заполнить очередь (код пайплайнов должен уметь правильно обработать, а это ой как нетривиально добавить, если заранее об этом не подумать). Ещё это можно назвать синтетическим тестом, который проверяет, что вся инфраструктура пайплайна в целом как-то работает.

А что если процессинг реально долгий? Был тормоз на входе — алерт прилетит сильно позже, когда сообщение доедет до конца пайплайна. И тут возвращаемся уже к загруженности очередей. Но не просто к больше чем 100500 сообщений в очереди, а в условиях, если она растёт! В PromQL это что-то типа deriv(my_awesome_kafka_queue_size[30m]) > 0 — то есть производная от скорости роста длины очереди.

🐈 Чувак, а где же здесь про кубер?
😏 А ничо тот факт, что сейчас пайплайны крутятся в кубере?) Да ещё и с автоскейлингом, как мы любим, чтобы экономить средства, изображая finops.

#kubнапальцах

Сколько реально нужно времени, чтобы найти нормальное место работы?

И закинул старик невод в море и стал ждать…
Мне вот интересно, сколько вы искали своё место работы? В последние годы рынок изменился, давайте пройдёмся по самому длинному ожиданию в период, скажем, после 2023г⬇️

Мой рекорд — 3 месяца с момента первого контакта с рекрутером. Да, добиться общения с живым человеком не так просто. А дальше — оффер, документы, релокация, но это уже другая история.

В целом, считаю норм в текущих условиях. Но любимый мем на эту тему у меня успел появиться⬆️

А что из relatable мемов про IT есть у вас? Кидайте в комментарии ⬇️

Признайтесь, вы тоже приукрашиваете своё резюме?

За свою карьеру я провёл больше сотни собеседований. Бэкендеры, фронтендеры, девопсы — чего я только не видел. И знаете, что меня всегда удивляет?

Нет, не когда человек не знает какой-то алгоритм с LeetCode. Это как раз норма. Удивляет, когда резюме выглядит как мечта, а в реальности — просто набор слов, который мало соотносится с соискателем.

Помню, как-то собеседовал кандидата. У него в резюме — 4 года опыта с PostgreSQL. Я не спрашиваю про индексы B-tree, не пытаю про тонкости MVCC. Я просто спрашиваю: «А когда PostgreSQL ломается?». И тут наступает неловкое молчание. Лицо собеседника меняется, а у меня в голове: «4 года и ни разу ничего не пошло не так?». Извини, но не верю.

И дело не в том, что кандидат должен быть энциклопедистом. Понятно, что для CRUD-приложения это некритично. Но разработчик, который реально работал с инструментом, знает его больные места. Он знает, когда стоит использовать Postgres, а когда лучше взять что-то другое. Он видит его ограничения.

➡️ В этом вся суть. Чем больше твоя насмотренность, чем глубже ты понимаешь, как работают инструменты, тем меньше шансов, что твой продакшн когда-нибудь свалится, а ты не будешь знать почему. И тем меньше шансов, что ты выберешь неправильный инструмент, который перестанет вывозить нагрузку или масштабироваться через год.

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

🐈 Котятки, давайте как на духу — ваше резюме на 100% честное? Или пара пунктов всё же выглядит более внушительно, чем есть на самом деле?

Самый сложный проект в моей практике

Вчера отвечал на вопросы для рубрики телеграм-канала «Слёрм» и один из вопросов меня зацепил. Звучит он так:

🟣 Какой был самый сложный проект в твоей практике и почему?

И мне кажется, здесь не всё просто. Потому что смотря что понимать под сложными проектами. Сложно, например, когда:

▶️ есть много внешних зависимостей
Ты разбираешь инцидент и понимаешь, что снаружи, даже не в твоей компании, от чего-то зависишь, и нужно сначала добиться от них признания, что проблема на их стороне. Потом, чтобы они починили проблему. И ты не можешь ничего сделать сам, потому что даже не имеешь доступ, просто ходишь по APIшке.

▶️ случается инцидент в большой сложной инфраструктуре, которую целиком не понимает вообще никто, потому что невозможно уложить в голове такое количество всех инструментов и технологий. И начинается поиск, где инцидент возник, где корневая причина, и кого из сотен команд пингануть, чтобы помогли в решении. Вполне может быть такое, что ты потратишь 1-2 часа на поиск нужных людей. И в этом как раз сложность работы в больших компаниях.

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

Всё 3 кейса встречал за свою карьеру. Некоторые — более 1 раза. Наверное, это как раз самое сложное в проектах для меня.

Какой самый сложный кейс (не обязательно технический) вам приходилось решать ?

Вы уверены, что ваш Pod — это готовый сервис? Именно эта мысль часто отделяет джуна от миддла

27-28 сентября состоится воркшоп «С нуля в прод за 2 дня». Забудьте про сухую теорию. Здесь вы за два дня прокачаетесь от «поднял контейнер» до «запустил отказоустойчивый сервис в продакшене»

Вас ждёт не скучная лекция, а полный цикл на реальном стеке (Next.js + Go):
➡️ Спроектируете инфраструктуру, которая не развалится после первого деплоя
➡️ Настроите CI/CD-пайплайн, который не стыдно показать коллегам
➡️ Перейдёте от мышления контейнерами к мышлению сервисами и их взаимодействием

🔥 Ведущий — Павел Минкин, DevOps-инженер в FinTech, который знает, как строить системы, не падающие под нагрузкой.

Если вы готовы за два дня пройти путь, который обычно занимает месяцы проб и ошибок — вам сюда.

Всё по делу, без воды. Регистрируйтесь в боте и прокачайте свой скилл до уровня миддла.

Знаю, в канале есть люди, которым не хватает базы по куберу.

Рад сообщить, что появилась возможность наконец-то разобраться с k8s и уложить всё в голове!

🔥 Совсем скоро открываются продажи на курс «Kubernetes:База», где вы получите всё самое необходимое для старта в кубах🔥

Помню свой первый момент, когда всё вдруг сложилось в голове. Было ощущение, что в темноте щёлкнул выключатель — и лампочка загорелась. Всё встало на свои места, исчезла каша из терминов, а вместо недоумения появилось понимание. Это тот самый мэджик, ради которого мы и затеваем курс.

🔷 Так и построен курс «Kubernetes: База». Мы не закидываем теорией, а создаём условия, чтобы такая лампочка зажглась у каждого. Чтобы вы разобрались и реально смогли работать с k8s.

Новый поток стартует 15 октября. И в этом потоке мы приготовили для вас кое-что особенное. Расскажу об этом на днях.

👍, если ещё ждёте, когда загорится лампочка
❤️, если уже привыкли к электричеству)
😁, если выключатель вам не нужен

Kubernetes — новый кислород IT-инфраструктуры

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

Почему? Я вижу несколько причин:

➡️ Простая бизнес-логика
Компании готовы платить за сокращение издержек и скорость, а Kubernetes как раз про это. Он позволяет запускать больше сервисов на том же железе и быстрее их обновлять. Поэтому его и adoptят все, кому важно масштабироваться. Соответственно, и специалисты, умеющие это делать, становятся очень нужны.

➡️ Стандартизация и контроль
Когда в проекте десятки команд и сотни сервисов, начинается хаос: у каждого свои версии, конфиги и способы деплоя. Кубер вводит единые правила игры для всех. Для бизнеса это — управляемость и предсказуемость. Для инженера — один мощный инструмент вместо зоопарка скриптов.

➡️ Карьерный лифт
Умение работать с Kubernetes из узкоспециального навыка превратилось в обязательную грамотность. Это теперь общий язык, на котором говорят разработчики, эксплуатация и менеджеры. Не знать его — значит сознательно ограничивать свои возможности для роста в крупных и интересных проектах.

А что на сей счёт думаете вы? Нужен кубер проектам или всё это хайп?

⌨️ Вебинар про DevSecOps через 5 минут!

Мои коллеги из Лаборатории Касперского и Positive Technologies поделятся опытом, кто всё-таки отвечает за безопасность в проекте, и нужен ли подход DevSecOps именно вам.

Ждём вас в 19:00 мск на вебинаре «Зачем бизнесу и командам DevSecOps».

➡️ Ссылка для подключения — в боте.

Всё и правда печально. Потому что когда вариантов слишком много, разобраться, где качество, а где просто громкие обещания, сложно.

Обсуждали вчера в чате, где учиться Kubernetes-у и прилетело такое сообщение ⬆️
Если бы я выбирал курс сегодня, я бы смотрел на такие вещи:

▶️ Структура
Материал должен быть не набором статей, а выверенным роадмапом: от простого к сложному, с чёткой логикой. Спикеры, которые дают материал, должны быть, во-первых, практиками — чтобы давать только актуальную информацию, а во-вторых, иметь опыт преподавания и понимать, как донести главные мысли студентам, чтобы они усвоили.

▶️ Руки
Практики должно быть сильно больше, чем теории, и она должна быть осмысленной. Важно, чтобы студенты доходили до каких-то решений самостоятельно, а не бездумно копировали команды. Классно, если при этом им не предоставляется техническая возможность выполнить эту практику, например стенды.

▶️ Поддержка
Когда мы спрашиваем студентов, что вам важнее всего на курсе, большая часть говорит про фидбек. Я абсолютно согласен с ними — нужно, чтобы во время обучения был кто-то, кто ответит не только «что делать», но и «почему так не работает». Поэтому обратная связь по заданиям и в чате очень полезна.

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

🛡 Когда создавался «Kubernetes: База» в Слёрме, мы как раз исходили из этих критериев. Курс построен как лестница: каждая тема — новая ступенька. 73% учёбы — практика на наших виртуальных стендах. А чат с кураторами и живые встречи со спикерами — это место, где можно спросить даже о самых базовых вещах без стеснения.

Слёрм как платформа мне нравится именно за этот системный подход. Здесь не бросают учеников одних, а ведут до результата. За 7 лет Слёрм обучил более 81 000 студентов. По моему, цифра говорит сама за себя. Говорю вам как человек, который выступает спикером и экспертом на 5 курсах Слёрма и знает изнанку обучения в этом центре.

Надеюсь, ответил на вопрос.

🐈 А на что вы в первую очередь смотрите при выборе курса?

Привет. На связи Маркус.

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

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

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

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

Мой человек уже рассказывал тут и тут, как проходил собеседования. Я всё это время в него верил и собирал документы для переезда. Шучу) Паковал миски.

Какое-то время ему было сложно. Он получал отказы, переживал, копался, что сделал что-то не так. Я старательно мурлыкал, чтобы подбодрить. Человек не сдавался, методично шёл к цели и однажды её достиг.

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

Всем мяу!

Вот ради таких моментов и стал спикером!

Всего полтора месяца — и человек не просто освоил Kubernetes, а уже прошёл сложную сертификацию и применяет знания в Т-банке. Это высший пилотаж!

Быть причастным к тому, что люди достигают своих целей — очень приятно 😌

💬 Как я смогу выйти на международный рынок в IT, если не знаю английский?

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

🟣 Давайте сразу договоримся, что английский в IT — это не язык Шекспира. Я слышу, как говорят другие члены моей команды из множества стран — поверьте, там никто не использует Present Perfect Continious. Там царит своя, особая грамматика, которую понимают все. Язык здесь — это инструмент. Им не нужно виртуозно владеть, им нужно решать рабочие задачи.

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

Что делал, чтобы улучшить технику речи:
▶️ Постоянно занимался с преподавателем, чтобы прокачивать уровень говорения и в целом улучшать опыт беглой речи. Будь ты хоть крутым стэндапером на русском, без хорошего уровня английского никто это не узнает.

▶️ Читал документацию на английском. Да, это техничка, а не разговорный язык, но она хорошо помогает быстро понимать проблемы и находить решения.

▶️ Переключил всё вокруг на английский. Телефон, ноутбук — всё, что смог, чтобы английский стал для меня естественным не только по работе.

▶️ Смотрел фильмы и сериалы без перевода. С их помощью начал разбираться в некоторых нюансах.

▶️ Ещё до переезда начал сотрудничать с зарубежными заказчиками.

Через какое-то время понял: моего английского хватает, чтобы обсуждать архитектуру, алерты и дедлайны. А это 90% рабочего общения.

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

🐈 Как оцените свой уровень английского? Вам хватает его для работы или нужно больше?

Неспокойно синее море…

➡️ Если ваше неспокойное море — это Kubernetes, позовите золотую рыбку, которая усмирит любые бури. Я говорю сейчас про GitOps.

Готовлю вебинар «Распробуйте GitOps и забудете про kubectl apply», где вместе с Кириллом Борисовым расскажу и покажу самое интересное про подход GitOps.

Мы:
🟠 разберём эволюцию деплоя в k8s: от простого kubectl apply до helm и kustomize;
🟠 поговорим о плюсах, минусах и подводных камнях каждого подхода, включая сценарии с канареечными деплоями;
🟠 покажем, как GitOps выводит процессы на новый уровень: автоматизация, прозрачная история изменений и решение проблемы configuration drift.

Время встречи: 2 октября в 19:00 мск

Приходите, будет практично и технично.

🛡 Ссылки на подключение придут в бота.

P.s. на видео пирс Схевенинген на побережье Северного моря.