k8s 1.33

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

➡️ Читать — по ссылке.

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

Вспомните, что windows часто рекомендовали обновлять только с выходом service pack 2, а с sp1 или вообще без service pack были достаточно багованые релизы.

Kubernetes Мега стартовал! 🔥

Для кого этот курс:

➡️ Для DevOps-инженеров, которые хотят:
- Перевести продукты компании на K8s;
- Использовать managed K8s для деплоя openstack;
- Повысить компетенции с точки зрения развертывания и сопровождения кластеров K8s;
- Разработать планы миграции АС с OpenShift на K8s;
- Углубиться в работу Kubernetes и применять методики на практике.

➡️ Для SRE-инженеров, которые хотят уверенно создавать отказоустойчивые кластеры.

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

➡️ Для архитекторов, которые хотят использовать все возможности k8s при проектировании платформенных решений.

Нашли себя в списке? Тогда присоединяйтесь к потоку — сделать это можно до конца недели.

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

Как развёртывать кластеры в условиях отсутствия интернета?

Принес вам статью моего коллеги, Георга Гаала из AEnix. Внутри — подробный ответ на популярный вопрос «можно ли запустить систему в air-gapped режиме?»

Всё, как вы любите — со ссылками, скринами и фрагментами кода.

➡️ ЧИТАТЬ НА ХАБРЕ

Собесы с алгоритмами — это лишь входной фильтр!
В BigTech рулят совсем другие навыки (и это не код).

Вы устали от бесконечных собесов, где трясут за знание алгоритмов, а потом на проекте выясняется, что человек элементарно не может внятно объяснить, что он вообще делает? Cегодня я хочу поговорить о вещах, которые в большом и серьезном бигтехе ценятся гораздо выше, чем умение вертеть бинарные деревья.

➡️ А именно: системное мышление, ownership и, да-да, коммуникация.

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

🐈 Хардскиллы — это, конечно, хорошо… Но недостаточно

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

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

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

Завтра мы подробнее поговорим про скиллы, необходимые, чтобы выжить в бигтехе. Stay tuned!

Собесы с алгоритмами — это лишь входной фильтр!
Часть 2

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

Поэтому здесь ценятся инженеры, которые умеют видеть картину в целом, анализировать риски и принимать взвешенные решения. То есть, те, кто обладает следующими навыками:

➡️ 1. Системное мышление: видеть что происходит вокруг твоего пузыря

Системное мышление — это не просто умение разбираться в коде. Это умение видеть, как этот код влияет на другие системы, как он масштабируется, как он влияет на performance, security, reliability, scalability, maintainability, observability и прочие ***bility.

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

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

➡️ 2. Ownership: твоя система — твоя ответственность

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

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

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

➡️ 3. Навыки коммуникации: донести свои идеи крайне важно

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

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

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

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

🐈 Вывод

Конечно, хардскиллы важны. Но если вы хотите добиться успеха в бигтехе, вам нужно развивать и свои софтскиллы. Системное мышление, ownership и коммуникация – это то, что отличает хорошего инженера от отличного. И то, что делает вашу работу не просто созданием коммитов в git.

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

Техдолг на уровне инфраструктуры — опасная вещь.

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

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

➡️ Читать — по ссылке ⬅️

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