⬆️Так AI видит куб под капотом: всё горит, вы горите, проект горит.

А как я вижу нюансы построения полноценного observability — обсудили в подкасте с коллегами из Флант.

Главный point выпуска: никому не нужно observability само по себе. Всем нужно нечто другое, что observability может решать.

А что скажете вы?

Работа в Нидерландах

А давайте поговорим про плюсы и минусы работы за границей? Возьмём конкретно Нидерланды.

Плюсы:

➡️ Множество топ-компаний: Google, конечно, не нанимает инженеров в Нидерландах, зато другие организации (FAANG и не только) держат здесь большие хабы. Много компаний с русскими корнями.

➡️ Конференции/митапы: в Амстердаме, Утрехте и других городах их огромное количество на любой вкус. Хочешь — пообщайся с инженерами gitlab, поинтересуйся, как у них устроены процессы. В другой раз — узнай у инженеров AWS, каково это — поддерживать работу самого большого облака.

➡️ Английский: голландцы отлично говорят по-английски, так что языкового барьера нет. Конечно, выучить голландский — это плюс к карме и интеграции, но для работы достаточно английского практически в любой IT-компании.

➡️ Культурное разнообразие: в Нидерландах ты встретишь людей со всего мира. Это отличная возможность узнать разные культуры, завести новые знакомства и расширить кругозор.

➡️ Транспортная доступность: слетать на выходные в Швецию, скататься на пару дней в Бельгию — easy peasy. Передвижение на велосипедах до работы — часть культуры. А расстояния такие, что поездка в другой город занимает 30 минут.

Минусы:

➡️ Жильё: найти подходящее жильё в Нидерландах, особенно в крупных городах, — это отдельный квест. Цены растут, конкуренция большая. Но всё осуществимо, просто придется вложить больше ресурсов в поиски.

➡️ Налоги: как и во многих других странах Европы — они большие, сложные и запутанные. Самостоятельно разобраться в нюансах непросто и обычно все делегируют подачу налоговой декларации бухгалтеру. Это нужно учитывать при планировании бюджета. Приблизительно уровень дохода можно рассчитать на этом сайте, если вы примерно понимаете, какие галочки нужно проставить для вашей конкретной ситуации.

➡️ Погода: часто Нидерланды представляют как очень дождливый регион — отчасти это правда, но в последние годы лето стало более жарким и можно не видеть дождей неделями.

А в какой стране вы хотели бы работать?

#работазаграницей

К слову про страны — на выходных ездил в Швецию, смотрите что нашёл⬆️

Представляю вам накопленный за годы арсенал инструментов!

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

🐈 В разные периоды мне довелось работать с разными инструментами и технологиями. Весь ли арсенал нужен мне сейчас на позиции SRE? Не всегда. Но бесценен не сам навык, а контекст, который он даёт. Та самая насмотренность, про которую многие говорят. На мой взгляд, современный инженер не может быть просто «специалистом по одному языку». Ему важно уметь оперировать разными инструментами под конкретную задачу.

Вот почему мне, например, не очень нравятся узкие тайтлы вроде «senior golang engineer». Они сразу ограничивают восприятие тебя как инженера, загоняя в узкие рамки. Компания ищет «голанг-разработчика», а получает человека, который может и базу данных оптимизировать, и выбрать правильный message broker, и оптимизировать пайплайны доставки приложения в прод, сократив время выполнения тестов и т.д. Но в рамках вакансии об этом могут даже не спросить.

🟠 В чем сила? Именно в широте кругозора. Когда ты видел проекты разного масштаба и работал с разными технологиями, ты принимаешь более взвешенные архитектурные решения. Ты не будешь тащить в проект Kafka, где хватит RabbitMQ, или настраивать сложный мониторинг на Prometheus для проекта, который отлично будет жить с Zabbix.

Вот мой «технологический зоопарк» — основа для всего, к чему я пришел:

➡️ Языки/фреймворки/библиотеки:

➡️ Backend (PHP):
- Laravel
- Symfony
- Yii2

➡️ Backend (Python):
- Django
- Django REST Framework
- Flask
- FastAPI
- Asyncio

➡️ Backend (golang)
В go нет фреймворков в привычном виде для php/python/java/etc. разработчиков, но есть уйма библиотек.

➡️ Backend (java)
- Spring boot

➡️ Frontend:
- Vue.js
- React
- Leaflet

➡️ Базы данных:

- PostgreSQL
- MySQL
- Redis (да, это вполне тоже БД в умелых руках)

➡️ Очереди:

- RabbitMQ
- Apache Kafka
- Redis (и очередь тоже, люблю redis)
- zeromq (интересная штука, рассказывал про него и про многие другие паттерны взаимодействия в микросервисных средах в докладе

➡️ Системный тулинг/linux:

- Linux (Debian/CentOS/Ubuntu)
- iptables
- OpenVPN
- tcpdump
- strace
- gdb
- Nginx/OpenResty/Traefik/HAProxy (разные балансеры L4/L7, включая логику на lua)

➡️ VoIP:

- Freeswitch/FreePBX

➡️ DevOps/SRE/Infrastructure:

- Kubernetes/Helm/ArgoCD
- Gitlab/Github Actions/Bitbucket Pipelines
- Docker/Docker-compose
- Ansible/Puppet
- Hashicorp Terraform
- Hashicorp Nomad (про него делал доклад, возможно вы даже не слышали о нем, но он имеет свою нишу и я видел проекты в проде на nomad)
- Hashicorp Vault

➡️ Мониторинг и логирование:

- Zabbix (он все еще живой, имеет свою нишу, где prometheus никому не сдался)
- Prometheus/Alertmanager
- Graphite
- Grafana/Loki/Promtail/Fluentbit

➡️ Текстовые редакторы:

- Vim (:wq всем)
Кстати, владение vim пригодится на экзамене CKA, про который рассказывал ранее, чтобы не тратить время на форматирование манифестов пробелами.

Надеюсь, вам тоже довелось поработать с разными технологиями. Предлагаю поделиться в комментариях, с чем самым интересным или необычным вы работали за деньги⬇️

Котятки, напоминаю – завтра, 27 августа, встречаемся на вебинаре с Максимом Киселевым.

Будем обсуждать, как правильно управлять секретами приложений и причём тут Kubernetes.

➡️ Начало в 19:00 мск.

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

🟣 Если не успели зарегистрироваться, ссылка
в боте.

В последние 2-3 года IT-рынок начал схлопываться.

Если раньше компании готовы были переманивать хороших инженеров, то теперь ситуация диаметрально противоположная. И речь не только про рынок junior/middle специалистов. Изменения коснулись подавляющего большинства грейдов и инженерных позиций.

🐈 Что мы наблюдаем

🟣Рынок работодателя: количество открытых вакансий снизилось. На одну позицию 500 CV — запросто.

🟣Требования повысились: «Я разворачивал pet-project в K8s» больше не считается опытом. Теперь надо показать, что ты умеешь разбираться в архитектуре, думаешь о SLA, о пользовательском опыте и умеешь видеть, как инструменты масштабируются на тысячи инстансов, десятки команд и миллионы пользователей.

🟣Акцент на эффективности: IT — это расходы, и немалые. Поэтому инженера оценивают не только по уровню владения Terraform, но и по тому, сколько денег он может сэкономить компании.

🟣Переоценка приоритетов: новые технологии ради новых технологий больше не заходят. «Давайте внедрим Rust» звучит красиво, но ответ может быть: «У нас MySQL 5.7 и оно работает, спасибо».

И это правильно в каком-то смысле. Несколько лет назад собеседовался на одну позицию, где в качестве основной БД был PostgreSQL 9.2 (релиз 2012 года), а актуальным был, кажется, 14 или 15 PostgreSQL с кучей багфиксов и улучшений производительности. Мигрировать ядро бизнеса, приносящего доход, на новые рельсы, с одной стороны, хорошо с инженерной точки зрения. А с другой стороны — много рисков.

🐈 Причём тут k8s

✅ Уже мало просто развернуть проект. Нужно уметь объяснить, почему выбран именно такой стек, чем хорош Victoria Metrics против Prometheus, и почему не нужно нагружать ноды сверх меры, а лучше взять больше инстансов.
✅ На собеседованиях всё чаще проверяют не «как ты настроишь Ingress», а «как ты спроектируешь систему, чтобы CTO спал спокойно, а счёт за AWS не превышал выручку компании».
✅ Без софт-скиллов никуда. Если ты умеешь писать Helm-чарты, но не можешь объяснить, какую пользу это принесёт бизнесу — сложно продать повышение грейда.

🐈 Что делать

🟠 Развивать T-shaped навыки — знать k8s. Но ещё понимать, как устроены облака, CI/CD, базы, очереди, и в целом экономика компании.

🟠 Прокачивать софт-скиллы: объяснять сложное простыми словами, доносить идеи и отстаивать архитектурные решения.

🟠 Менять шапки: сегодня ты эксперт по k8s, завтра — по observability, послезавтра — по «как объяснить бизнесу, что нужно потратить еще 10 миллионов евро на железо каждый месяц», а на следующей неделе — по root cause analysis инцидента, который стоил компании 100k потерянных заказов за час.

🟠 Trade offs: уметь объяснять плюсы и минусы предлагаемых решений. Например, дешёвое решение с быстрым time-to-market против более надёжного с более долгим выходом на рынок.

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

А какие тенденции на IT-рынке заметили вы?

🔥 Мы начинаем вебинар «Прячем секреты приложения. Как Kubernetes помогает защитить ваши данные?» с Максимом Киселевым.

Подключайтесь по по ссылке.

Объявляем Quizbernetes

Любите ли вы айтишные квизы так, как их люблю я? Если вам не хватает загадок на работе, или вы просто хотите испытать себя на знание k8s, концепций распределённых систем и проектирования архитектур, то…

➡️ Регистрируйтесь на Quizbernetes — игру по k8s, в которой будет много вопросов: базовых, хардкорных и с заковыркой 😏

🟣 Когда: 04 сентября 19:00 мск

🟣 Что нужно: базовые знания k8s и желание играть

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

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

➡️ Чтобы принять участие в игре, переходите в бота по этой ссылке. ⬅️

…про то, что «Kubernetes для разработчиков» стартует через неделю.

С 8 сентября новый поток студентов сядет за парты, и мы с Марселем Ибраевым и Павлом Селивановым подробно и с примерами расскажем, как:

🔷 собирать приложения под k8s;
🔷 автоматизировать деплои через CI/CD;
🔷 создавать и конфигурировать Service и Ingress для различных Deployment;
🔷 создавать и настраивать Helm-чарты для приложений,
🔷 самим дебажить проблемы в поде и многим другим полезным вещам.

Это концентрированное практическое обучение — без воды, только то, что нужно разрабу, чтобы перестать быть заложником инфраструктуры. В конце курса — сертификация.

🟠 Подробнее изучить программу и выбрать тариф можно по ссылке.

Прячем секреты приложения. Как Kubernetes помогает защитить ваши данные — запись вебинара доступна к просмотру.

На этом вебинаре мы с Максимом Киселёвым собрали воедино картину работы с секретами и обсудили:

🟠почему Kubernetes популярен;
🟠где хранить конфигурацию;
🟠как ничего не делать и чтобы всё было безопасно;
🟠кейсы и примеры использования.

Ссылки на запись для тех, кто просил:

🍿 VK
😘 youtube

Приятного просмотра!

Год назад я проходил собеседование на должность SRE в нидерландском бигтехе.

Меня бесило, что нужно было учесть миллион разных моментов, продумать, О ЧЁМ стоит говорить и КАК говорить… Я готовился к интервью больше, чем к переезду)

Но обо всём по порядку. Мой пайплайн интервью состоял из следующих этапов:

➡️ HR-скрининг: стандартная процедура — говорили о мотивации, опыте и зарплатных ожиданиях.

🟣 Я понимал, что здесь очень важно чётко и структурировано излагать свои мысли, а также демонстрировать понимание ценностей компании. Поэтому заранее прокачивал английский язык и готовил ответы. Никто не поймёт, какой ты молодец, если ты не сможешь это объяснить на неродном языке. Причём нередко людям, для которых английский тоже является вторым языком 🙂

➡️ Техническое интервью: проверка того самого литкода. Тут всё стандартно, на эту тему есть тонны статей и видео.

➡️ System Design. Задача этого этапа — проверить насмотренность и умение мыслить, а также протестировать навыки общения. Это идеальный момент, чтобы блеснуть знаниями деталей и нюансов построения больших систем по максимуму. Но при этом донести ход своих мыслей до интервьюера нужно всего за час!

🟣 Какую систему можно построить за это время? Только гипотетическую. Я и построил.

➡️ Culture Fit: испытание на общую адекватность и соответствие культуре компании. Обсуждали командную работу, конфликты, подходы к решению проблем.

🟣 Правила игры я изучил заранее, поэтому успел подготовиться и к этому этапу. Взял на вооружение метод STAR и был готов предоставить кейсы из практики по этому методу.

Что я хочу сказать по итогу. Твои скиллы — это только полдела. Вторая половина — это умение продать их по правилам игры, которые устанавливает компания.

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

А какие моменты раздражают вас при прохождении интервью?

🟠 Встречаемся на Quizbernetes завтра, в 19:00 по мск.
Кто не успел зарегистрироваться, вот ➡️ ссылка ⬅️

Та-да-дамммм!

Трубите фанфары, стучите барабаны — мы начинаем Quizbernetes!

Что вас ждёт:
🟣 простые и каверзные вопросы про k8s и не только;
🟣 шутки от Всеволода Севостьянова;
🟣 подарки для победителей — футболка в стиле нашего канала для лучших в Kubernetes🔥

5 минут вам на сборы и встречаемся в 19:00 мск.

➡️ Ссылка для входа тут.

Поздравляю победителей Quizbernetes 🥳

🟠rachiy
🟠Test user
🟠mrg1790
🟠EgorkiN

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

Абсолютно всех участников благодарю за игру, было здорово! Поделитесь обратной связью, что понравилось, что нет, какой вопрос зацепил?

APF

Вчера на Quizbernetes подняли вопрос, что APF — тема, в которую если и влезаешь, то раз в год, когда под нагрузкой API-сервер начинает либо отклонять запросы, либо обрабатывать дольше обычного. У вас же есть метрики и алерты на API-сервер?🙃

➡️ Вот пример инцидента, которого могло бы не быть, или импакт которого был бы сильно ниже, будь APF правильно настроен. Да, ChatGPT лежал несколько часов, потому что ноды заддосили API-сервер. Хоть постмортем и не упоминает явно APF, по описанию ясно, что API-сервер был перегружен запросами, связанными с телеметрией.

🟣Проблема

Через API-сервер проходят все запросы в кластере. В нагруженных кластерах он может стать узким местом. Все компоненты общаются друг с другом строго через API-сервер.

🟣Разберём, что такое APF и зачем он нужен?

APF (API Priority and Fairness) — это механизм, который позволяет k8s управлять приоритетами API-запросов от разных компонентов и гарантировать больше любви более критичным компонентам. А остальные как-нибудь переживут 😌

🟣 APF особенно полезен:

➡️ В кластерах с большим количеством узлов и подов.

➡️ Если нагрузка на кластер сильно колеблется, например, в зависимости от времени суток. APF помогает сохранять стабильность без необходимости скейлинга control plane под пиковые нагрузки, которые могут возникать пару раз за сутки.

➡️ Если ресурсы API-сервера ограничены и не хочется тратить $ на скейлинг. APF помогает более эффективно их использовать за счёт отклонения/откладывания части запросов.

➡️ Разнородные workloads – если в кластере работают приложения с разными требованиями к API k8s. APF позволяет приоритизировать более важные запросы.

🟣 На что это похоже?

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

🟣 Нужно ли лезть в APF для маленьких кластеров?

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

В следующий раз расскажу, когда нужно лезть в APF и как его настроить, а вы поделитесь, сталкивались ли с APF в работе?

#кубнапальцах

Как ИИ меняет работу уже сейчас

Делимся сочными инсайтами из нашего эфира по AI-adoption с Павлом, Senior Engineering Manager, который отвечает за Growth Unit в компании Wrike — одной из крупнейших платформ для управления проектами.

Полная запись здесь: YouTube | VK | Rutube

А для тех, кто любит читать — выжимка главного⬇️

🟣В командах Павла ИИ используют по двум фронтам:

Для разработчиков (в процессе работы):

🟠 Почти все инженеры используют AI-ассистенты для написания кода, например, Cursor и GitHub Copilot.
🟠 AI-powered код-ревью: перед тем как отдать код на проверку живому человеку, его прогоняют через ИИ.
🟠Внутренний AI-портал: это чат-бот, подключенный ко всей документации компании. Если разработчик не знает, как работает какая-то часть продукта, он может быстро спросить у бота.

А в продукте для клиентов есть:

🟠 ИИ-ассистент помогает создавать задачи и проекты. Можно в свободной форме написать, что нужно сделать, а он сам создаст структуру.
🟠 Внутренний "Copilot", которому можно написать: "Дай мне статус по всем моим проектам" или "Суммируй апдейты по моим последним задачам".

➡️ИИ не заменяет разработчиков, а усиливает их навыки.

Для опытных инженеров это мощный инструмент. Он помогает быстро решать рутинные или сложные задачи, например, искать неочевидные баги. Один из примеров: баг, где дни недели считались от 0 до 6 вместо 1 до 7, был найден за несколько минут с помощью ИИ, хотя раньше на это ушли бы дни.

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

▶️Нужно заранее знать, что ты хочешь получить от ИИ, и четко формулировать запрос. Просто сказать "сделай мне хорошо" не сработает.

Что будет с инженерами разных грейдов?

Роль сеньоров меняется. С одной стороны, они могут избавиться от рутины и сфокусироваться на сложных задачах, вернув удовольствие от работы. С другой — есть риск погрязнуть в ревью тонн кода, сгенерированного джунами с помощью ИИ.

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

Главная проблема с ИИ — безопасность🛡

Большой барьер, особенно для B2B-компаний, — это юридические вопросы и безопасность данных. Клиенты не хотят, чтобы их данные передавались для обработки внешним вендорам вроде OpenAI.

Возможное решение: хостить open-source модели у себя (in-house). Это снимает проблему с данными, но создает новую — это очень дорого с точки зрения железа (GPU).

Больше деталей и крутых примеров — в полной записи эфира.

↘️А как у вас? Используете ИИ в работе? Что он ускорил, а где создал проблемы? Делитесь в комментариях!