Сколько зарабатывает 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

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

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

Все знают карьерный трек: junior ➡️ middle ➡️ senior, но что дальше? Вернее, кто? Поделился своим видением по вопросу в видео.

А какая самая высокая ступень градации инженеров в вашей компании?

Как получить CKA сертификат и выжить

Прошел экзамен на kubectl apply администратора certified kubernetes administrator, он же известен как просто CKA, и расскажу, как оно.

First things first, что это, зачем это нужно и что даёт

🟠 Что это?

CKA — это полностью практический экзамен, где тебе даётся 2 часа и строгий контроль за твоими действиями. Вышел из обзора камеры — могут не засчитать экзамен. Шепчешь себе условия задачи — могут не засчитать экзамен. И так далее.

Суть экзамена в том, что тебе нужно решить 15-20 практических задач в k8s за 2 часа. Тематика на 2025 год включает в себя storage, troubleshooting, scheduling, cluster architecture, services, networking, etc. Более подробно темы можно изучить тут.

🟠 Зачем это нужно?

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

Почему экзамен про базовые темы? Это действительно скорее «kubectl apply администратор» и ничего замысловатого на экзамене нет. Вам просто не могут дать несколько сложных задач, потому что вписать их в 2 часа нереально.

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

🟠 Что это даёт?

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

Да, сертификация есть разная. Есть экзамены, где ты просто отвечаешь на multiple choice questions на протяжении всего испытания, не подтверждая на практике, что ты реально сможешь это сделать.

А конкретно CKA (и следующий после него CKS) не дают никаких сомнений, что основы kubernetes человек освоил неплохо. С этим специалистом можно общаться дальше, если в команду нужен человек, который обязан разбираться в k8s.

Поздравить с аттестацией можно огонёчками 🔥, а задать вопросы по СКА — в комментариях, отвечу на них в следующем посте⬇️

Как готовиться к CKA?

🟣 Стоимость

На момент написания поста цена экзамена 445$. Это довольно много. Поэтому ждём распродаж – во время cyber monday и к концу года цена может оказаться в 3 раза меньше. CKA + CKS bundle вполне может стоить 250-300 долларов, но тогда придётся готовиться к сдаче уже двух экзаменов) И CKS можно проходить только при наличии сданного CKA, а это уже другая история.

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

🟣 Как подготовиться

По шагам:

➡️ Пройдите лучший доступный курс от Mumshad Mannambeth.
➡️ После покупки экзамена у вас так же будет две пробных сессии в killer.sh. Их стоит пройти ДО планирования даты, но ПОСЛЕ того, как прошли курс от Mumshad.
➡️ Также есть набор бесплатных playground с задачами, похожими на те, что будут на CKA.
➡️ Ещё обязательно изучите работу в консоли, если до этого не работали в ней.
➡️ Нужно знать, как использовать vim и grep и вообще комфортно чувствовать себя в cli.
➡️ Важно хорошо ориентироваться в https://kubernetes.io/docs/home/. На экзамене недоступен google, зато доступен поиск по документации. Экзамен не про написание манифестов с нуля, поэтому будьте готовы быстро найти, где в документации можно скопировать похожий пример и поправить под условия задачи.

🟣 Как проходит экзамен?

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

➡️

Внешним монитором пользоваться нельзя.

➡️

Проходить экзамен в офисе или в любом помещении с другими людьми нельзя.

➡️

Даже чашку чая нельзя оставить) Только воду в прозрачном стакане, иначе не дают проходить экзамен.

➡️

Выходить из обзора камеры нельзя.

➡️

Шептать себе условия задач под нос также нельзя.

Во время экзамена можно запросить 3 перерыва, но моя рекомендация — не делать этого, потому что 2 часа на 15-20 задач может быть мало. Лучше заранее сделать всё, что нужно.

Задания могут быть разного уровня и, если где-то не понимаете, что конкретно делать, лучше отметить этот вопрос (flag question) и вернуться к нему в конце. Экзамен не требует идеального решения всех задач. Главное — набрать проходной балл. Все детали можно найти на оф. странице.

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

В слайде то, как это выглядит во время экзамена⬆️
Это не 100% реплика экзамена, но очень похоже. Слева у вас задача. Справа консоль и в отдельной вкладке, внутри этого же окна, — доступ к рабочему столу, где можно запустить браузер с доступом в документацию k8s.

🟣 Выводы

Стоит ли оно того? Скорее да, чем нет:
➡️ Вы систематизируете знания.
➡️ Вы получаете хорошую ачивку в резюме. Этот сертификат котируется компаниями, но, конечно, не дает каких-то гарантий в трудоустройстве.

Посмотрим случайный пример от случайного нанимающего менеджера

Yes. This particular one is worth it. I’m a hiring manager (Sales Engineer leader) and every person on my team needs to pass it within their first 6 months of employment. Why? It teaches you the fundamentals, establishes credibility with others about K8s and its very in depth training.

Стоит ли считать мнение случайного человека в интернете значимым? Каждый решает сам.