Вижу, что бОльшая часть моих подписчиков уже проводит технические собеседования

Это отлично, значит, будем и дальше развивать тему «Как надо и как НЕ надо проводить собеседования» 🔥

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

Напишите в комментариях, с какими сложностями вы сталкиваетесь, когда проводите собеседования? Что хотелось бы обсудить или разобрать?

Ну что, котятки, соскучились по Кириллу Борисову?

Теперь он ведет канал «Путь SRE», в котором:

➡️ публикует полезные материалы для инженеров;
➡️ делится практическими кейсами, инструментами и лайфхаками;
➡️ рассказывает про факапы;
➡️ проводит прямые эфиры, общается с аудиторией и отвечает на вопросы.

Сегодня в 19:00 на канале пройдет прямой эфир, который поможет разобраться — кто, зачем и как спасает продукт от катастроф.

Специальный гость: Вячеслав Федосеев, TeamLead DevOps в «Честном знаке» и автор канала «DevOps Bootcamp». Да будет файт между DevOps и SRE!

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

🟣 Путь SRE

Ну что, продолжим про собеседования?

Посмотрел комментарии и сообщения в чате, видел упоминания ChatGPT. На самом деле, поймать кандидата, который ничего не понимает, довольно просто, особенно когда речь идет о коде. В кружке объяснил, почему.

В следующей части лонгрида рассказываю про довольно странных кандидатов, которые встречались мне в процессе собеседований ⬇️

Странные кандидаты

А теперь — минутка баек из склепа! Если вы помните, что это, проверьте срок годности таблеток :)

➡️ Преподаватель Go, который забыл Go.

Искали мы однажды сеньора на позицию golang-разработчика. Пришел кандидат, который преподает Go в одной онлайн-школе. Но на достаточно простые вопросы по языку (типа «порядок обхода map» или порядок «горутины и WaitGroup») ответить не смог.

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

Вы же не захотите водить кандидата по коду, объясняя как работают WaitGroup?

➡️ PHP-разработчик.

Другой кандидат, без камеры, не смог даже с поиском ответить на простые вопросы по Symfony. Зато было слышно, как он ищет ответы. Серьезно, после каждого вопроса был слышен стук клавиш.

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

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

Как составлять резюме

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

🟠 Краткость важна, потому что если вам повезло и вы дошли до HR, человек должен сразу увидеть достаточный уровень компетенции и соответствия должности, не тратя время на вчитывание в N страниц текста.

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

🟠 Если вы написали, что «5 лет работал с Redis», будьте готовы рассказать не только про GET и SET, но и про тонкости работы со streams (если использовали) и как оптимизировать работу на больших RPS (pipelining, если работали с ним).

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

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

Не страшно говорить, что с чем-то не работали. Честность ценится, а научиться всегда можно.

На что лично я обращаю внимание на собеседованиях

➡️ Насмотренность и кругозор. Если кандидат не знает/не помнит нюансов использования конкретного инструмента, но может в правильном направлении рассуждать относительно своего опыта, то есть большая вероятность, что за пару запросов в google/ChatGPT он сможет найти ответ, что он и сделает в реальном проекте. Бизнесу важно решать проблемы и получать прибыль, а не нанимать тех, кто может по памяти вспомнить все сложности настройки очередной вундервафли.

В заключение: Собеседование — это двусторонний процесс. Не только компания выбирает кандидата, но и кандидат выбирает компанию (на самом деле кандидат скорее команду выбирает, если речь о больших компаниях). Будьте честны, объективны (на самом деле мы скорее всегда субъективны) и, главное, помните: все мы люди, все мы ошибаемся. Даже при деплое в production. Удачи!

Как связаны k8s и National Security Agency: часть 1
#полезный_материал

➡️ Посмотрим на примере audit policy и seccomp profiles, как можно повысить безопасность кластера.

Второе видео — завтра. Не переключайтесь!

А пока жду ваших вопросов в комментариях ⬇️

Как связаны k8s и National Security Agency: часть 2
#полезный_материал

Вчера разобрались с audit policy, а сегодня рассмотрим seccomp profiles.

➡️ Подробности и большой чек-лист по k8s hardening — в гайде от NSA.

Инфраструктурные ошибки в работе с k8s

🐈 Один k8s для всего

Когда вы только переезжаете на k8s, то кажется, что можно все объединить под крылом одного кластера, включая dev-среду. Вроде бы проще управлять, да и ресурсы (а значит и деньги) экономим [про деньги за инфру рассказывал тут].

Год-два спустя вы оказываетесь в следующей ситуации: больше команд, микросервисов, баз данных. И вот уже любое изменение в кластере потенциально прикладывает прод.

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

🐈 Namespaces и resource quotas — изоляция не нужна (на самом деле нужна)

Просто подняли кластера, просто задеплоили приложения. Вроде и так всё работает. А потом оказывается, что сервисы начинают конкурировать за ресурсы CPU и RAM. Один разработчик случайно опечатывается, и вот у вас вместо 10 реплик приложения уже их 100.

О контроле ресурсов можно забыть. А если еще и автоскейлинг worker nodes есть, то от облака придет очень «приятный» счет в следующем месяце. Исправлять это, конечно, можно, но придется довести до всех, что теперь есть лимиты на ресурсы и нельзя просто так запросить себе еще 50 CPU и 200 GB RAM, потому что оптимизировать сервис долго, и проще закидать железом.

🐈 Network policies, или мы можем делать все

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

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

Исправить это постфактум, когда данные уже утекли, задача не из приятных.
Знаете что еще менее приятно? Разгребать последствия. Представьте гипотетическую ситуацию, когда злоумышленник смог разослать клиентам сообщения с нелицеприятным содержанием, когда смог поменять цены на товары, когда смог инициировать вывод денег со счета на сотни левых карт, просто проэксплуатировав внутренние API.

Важно только одно. Безопасность и удобство никогда не идут рядом. Чем безопаснее система, тем менее удобно разрабатывать любые интеграции. Вам нужно заранее запросить у безопасников разрешение на интеграцию сервиса X с сервисом Y. Да еще и указать, какие методы сервиса будут вызываться. И все это для того, чтобы сократить вектор атаки.

🐈 Всегда виноват DNS

Когда вы только начинаете работать с k8s, кажется, что CoreDNS просто работает. k8s писали умные люди, google фигни не сделает.

Спокойно работаете и получаете сообщение в чате: прод лежит 🔥🔥🔥

Представьте себе: вы радостно скейлите сервис, добавляя больше реплик, потому что нужно подготовиться к росту нагрузки перед распродажей, например. Но внезапно видите, что он сыпет ошибками про dns resolve.

Мы набиваем в k8s кластер все больше и больше сервисов, и каждый сервис делает кучу DNS-запросов. А CoreDNS как поставили, так он и работал. Ресурсов стало мало и k8s начал его троттлить по CPU 🙁

Что делать? Тюнить ресурсы (CPU и RAM), мой юный кубарист!

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

И конечно node local DNS — просто must have для снижения нагрузки.

И последнее: мониторинг! И алерты! Что толку от дашбордов, где можно увидеть проблему, только зайдя в дашборд. Алерты хотя бы напомнят об их существовании.

— У вас дыра в безопасности!
— Ну, хоть что-то у нас в безопасности.

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

А какие аспекты ИБ вызывают у вас эмоциональное напряжение и внутренний дискомфорт? Комментарии — это безопасное пространство, где можно поделиться наболевшим ⬇️

Дайджест материалов за февраль

Месяц получился продуктивным, собрал в одном посте все полезные материалы. Забирайте, кто что-то пропустил ⬇️

🔷 План онбординга в компанию
→ Часть 1
→ Часть 2
→ Часть 3

🔷 Как строить надежные приложения?

🔷 Работа с долгоживущими подключениями

🔷 Лучшие практики написания Java и Go приложений под k8s — вебинар
→ YouTube
→ VK Видео

🔷 Как строить отказоустойчивые системы?

🔷 Как надо (и как не надо) проводить собеседования
→ Часть 1
→ Часть 2

🔷 Как связаны k8s и National Security Agency
→ Часть 1
→ Часть 2

🔷 Инфраструктурные ошибки в работе с k8s

Дальше — больше. Stay tuned! 🐈

P.S. В комментариях можно написать, какие темы вы хотели бы разобрать в марте ⬇️

Ну что, котятки, есть среди вас разработчики, которые так и не добрались до кубов?

Новость для вас — сегодня стартовал курс «Kubernetes для разработчиков» 🔷

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

➡️ самостоятельно разворачивать локальную среду для разработки своих приложений;
➡️ дебажить приложения в кубе так же легко, как в докере — смотреть логи, собирать метрики, писать Helm-чарты, CI/CD;
➡️ самостоятельно вносить изменения в манифесты, не дожидаясь DevOps-команды;
➡️ оптимально, эффективно и правильно использовать k8s в проекте.

Жду всех, кто еще не успел присоединиться — набор открыт до 10 марта.

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