⌨️ Типы баз данных

#bd #ten

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

Если бы я мог посоветовать одну вещь Dev Ops специалистам любого уровня, я бы посоветовал читать тексты посвященные постмортемам, баг-репортам и траблшутингу. У коллеги — интересный случай, я прочёл с неподдельным интересом. Как человек имевший дело с YC и Managed Kubernetes, я нашёл пост особенно увлекательным. Даже если вы не знакомы с облачным k8s всё равно будет очень интересно и, главное, полезно.

Оооочень интересный дебаг
Коллеги, всем привет! =)
После небольшое затишься, очередной, надеюсь интересный пост про то как мы дебажили историю “а почему поды не разворачиваются”
Вводная: k8s 1.31, cilium, Istio, 30-03-2025 авария в я.облаке
Все началось с классического запроса от разработчика “сервисы не деплоятся, обновления не катятся”. Хммм, подумал я и пошел дебажить.
helm upgrade - отваливается по таймауту. Последствия воскресного инцидент я.облака и возможно какая то часть инфры находится в залипшем состоянии, а мы и не вкурсе. Проверил раннеры, обновил версию helm`а (чисто на всякий случай, текущая была не сильно новой) - проблема сохраняется. Хмм подумал я второй раз и решил попробовать развернуть сервис “начисто”. У сервиса в чарте сабчартом подключен redis.
Ииии redis разворачивается, а подов сервиса нет 0_о
В events совершенно ничего интересно. Посмотрел всякое, посмотрел телеметрию - ничего сильно страшного не видно. Иииии потом я вспоминаю, что deployment сервиса, на самом деле “внтури” replicaset (вы же знаете, что весь k8s - это абстракция на абстракции). Посмотрел, что там с replicaset и увидел следующее:

Warning FailedCreate 26s replicaset-controller Error creating: Internal error occurred: failed calling webhook "object.sidecar-injector.istio.io": failed to call webhook: Post "https://istiod.istio-system.svc:443/inject?timeout=10s": dial tcp ${istio-pod-ip}:15017: connect: connection timed out

Опппа, контроллер не может отправить вебхук в истио, что бы он добавил сайдкар в наш под. Становится интересно.
Из неймспейса проверяю связность при помощи nc, curl - все хорошо. Replicaset все еще не может отправить вебхук в истио.
Перезапускаю istio контроллер (просто делаю роллаут) и на всякий случай “пинаю” mutatingwebhook istio. Результата нет. На всякий случай “собираю” отдельный деплоймент и тестирую его в отдельном неймспейсе, что бы исключить сетевые политики, после тестирую размещение на разных нодах - результат тот же.
Ооооокай, что там у нас с cilium?
Проверяю ns kube-system и вижу что там, после “воскресных приключений”, ооочень много подов istio-operator висят в статусе containerstatusunknown. Подчищаю контейнеры и делаю роллаут подов cilium. Результат все тот же. Все кому нужно “хукануть” истио, что бы произошел инжект сайдкара не могут этого сделать.
Штош, тут мои полномочия все, оформляю критикал тикет в саппорт.
Саппорт отвечает быстро, и предлагает выполнить команду

k get ciliumnodes.cilium.io

На выходе мы получаем список нод нашего кластера, которые “входят в сеть cillium”
И видим мы там ооочень интересные вещи, а именно:

NAME CILIUMINTERNALIP
master-a 1.1.1.1
master-c 1.1.1.2
master-d 1.1.1.2
k8s-master-a 1.1.1.1
k8s-master-b 1.1.1.3
k8s-master-c 1.1.1.2
k8s-master-d 1.1.1.2
#адреса конечно же не такие, следите за последним октетом

И первый же мой вопрос: “Чегооооо? Откуда у меня мастера в зоне С которую мы разорабрали 2 квартала назад? И почему мастеров так много если их должно быть 3?”
Естественно я уточнил, а какой мастер актуален для кластера на данный момент. Саппорт уточнил актуального мастера и рекомендовал, удалить старые. Старые мастера удалены, вебхуки работают, приложения деплоятся/обновляются, все счастливы.
Произойти такое могло, скорее всего из-за той мега аварии в я.облаке 30-03-2025 (но это не точно, так как старые мастера у меня были достаточно давно)
Мораль сего приключения такова - не забывайте, что в k8s много абстракций =)
Фан факт - коллеги с соседних бизнес доменом с таким сталкивались ранее и ответили мне быстрее чем саппорт =)
ЗЫ1 - как это можно обнаружить заранее - логи управляющих компонентов, там по идеи все должно быть видно =)
ЗЫ2 - весь пост написан от моего лица, но на самом деле нас было двое, Серег, спасибо большое ^_^
ЗЫ3 - коллеги, из соседнего домена, Дим, Макс, Лех, спасибо за помощь в дебаге ^_^

⌨️ Terraform. Введение

#tf

Очень старался. Исправил неточность из предыдущего поста, на которую указали в комментариях — ещё раз большое спасибо!

Правила всё те же: если пост понравился — ставь реакцию, показался полезным — добавляй в избранное.

Этот пост — совместный проект каналов @linautonet и @devopshh (подписываетесь, ставьте лайки, пишите комментарии)

Argo CD и Kubernetes: Эффективное управление приложениями в облаке ☁️

Продолжим рассматривать более детально
### Архитектура и управление 💻🔧

Архитектура Argo CD основана на нескольких ключевых компонентах. Давайте подробнее рассмотрим каждый из них, а также схему.

#### Компоненты Argo CD 🌟

1. Git-репозиторий: Основа GitOps подхода, который хранит манифесты приложений (YAML файлы), описывающие ресурсы Kubernetes.
2. Argo CD API Server: Обеспечивает взаимодействие с Argo CD и провайдером Git, управляет состоянием приложений.
3. Argo CD Repo Server: Отвечает за взаимодействие с Git-репозиторием, извлечение и компиляцию манифестов.
4. Application Controller: Следит за состоянием приложений и отвечает за синхронизацию состояния Kubernetes с Git.
5. Argo CD User Interface (UI): Веб-интерфейс, который позволяет визуализировать и управлять приложениями.

### Схема взаимодействия Argo CD и Kubernetes 🗺

Предлагаю вашему вниманию следующую схему взаимодействия компонентов Argo CD и Kubernetes:

┌────────────────────┐
│ Git Repository │
│ (YAML манифесты) │
└─────────┬──────────┘
│
│
▼
┌────────────────────┐
│ Argo CD API │
│ Server │
└─────────┬──────────┘
│
│
▼
┌────────────────────┐
│ Application │
│ Controller │
└─────────┬──────────┘
│
│
▼
┌────────────────────┐
│ Kubernetes │
│ Cluster │
└────────────────────┘

### Как это работает? 🧠

1. Создание приложения: Разработчик создает файлы манифестов в Git-репозитории. Файлы содержат описание, как развернуть приложение, включая необходимые ресурсы (под, сервисы, ingress и т.д.).

2. Синхронизация: Argo CD периодически проверяет состояние Git-репозитория на наличие изменений. При обнаружении обновлений, Argo CD автоматически синхронизирует состояние кластера Kubernetes с новыми манифестами. Если произошли расхождения, Argo CD может либо автоматически исправить их, либо уведомить команду.

3. Мониторинг: Пользователь может использовать графический интерфейс Argo CD для визуализации состояния приложений, получения уведомлений о проблемах и выполнения откатов при возникновении ошибок. Это облегчает диагностику и решение проблем.

### Преимущества использования Argo CD 🚀

Использование Argo CD в сочетании с Kubernetes предоставляет множество преимуществ:

- Прозрачность изменений: Все изменения фиксируются в Git-репозитории, что позволяет легко отслеживать историю и выполнять откаты.

- Автоматизация: Уменьшается количество ручных операций, что уменьшает вероятность ошибок и ускоряет развертывание.

- Упрощение процесса CI/CD: Argo CD легко интегрируется с CI/CD пайплайнами, обеспечивая бесшовный процесс развертывания.

- Масштабируемость: Подходит для управления большими и сложными приложениями в распределенных средах.

### Заключение 🎉

Argo CD является мощным инструментом для управления приложениями в Kubernetes, предоставляя возможность легко применять GitOps подход. С его помощью можно значительно упростить процесс управления развертыванием, улучшить качество выпусков и ускорить процесс разработки. Если вы хотите повысить эффективность своей команды и сократить риски, интеграция Argo CD в ваш рабочий процесс — это правильное решение! 🌈

Пишите в комментариях, если у вас есть вопросы или хотите узнать больше о возможностях Argo CD и Kubernetes! 🚀✍️

🤗 Наш чат для обсуждений получи футболку тут |🔝 Буст для канала

✋Поддержи канал и автора миской супа и на развитие мерча!

Интересный вводный пост про Argo CD — информативный и хорошо оформленный. Всё как мы любим, поэтому всячески призываю подписаться на канал @DevOps360, если пост вам понравился — там ещё много подобного контента!

Всем привет! Внезапно вышло разговорное видео с моим участием. Я там побил все личные рекорды по косноязычию и словам-паразитам на минуту времени — это я не выспался, волновался, и вообще, такое со мной впервые (стелю соломку). НО у нас с Владом, автором канала @automation_craft (подписывайтесь!), получилась довольно ламповая беседа о жизни и профессии. Я рассказал про свой витиеватый карьерный и жизненный путь, а ещё поделился тем, что меня реально занимает.

Посмотрите, мы старались! Я — говорить о том, что кажется мне действительно интересным, а Влад сделал всё остальное, за что ему огромное спасибо. Как обычно, ваши лайки очень приветствуются!

РОЛИК

⌨️ K8s. Deployment

#k8s

Немоного об этой сущности, а вообще:
Deployment = ReplicaSet + декларативное обновлениe + откаты + масштабирование.

⌨️ DataOps

#devops #вп

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

⌨️ K8s. Вопрос о деплое пода

#k8s

Опишите путь, который проходит Pod от момента деплоя его манифеста до статуса Running

👰‍♀️ Что писать в поле “О себе”?

#рекрутинг

Представьте: вы уже вспомнили и красочно расписали весь свой опыт работы, указали полный стек, потратили на резюме немало времени, и вот появляется оно - финальный босс, поле, в которое непонятно, что писать, но и пустой оставлять не хочется. Да, речь о графе “О себе”. Давайте разбираться, чем можно ее заполнить!

1. Самым лучшим решением будет указать телеграм для связи. У многих рекрутеров, в частности, почти во всех агентствах, не оплачена база открытия контактов в Хэдхантере. Вписав телеграм в поле “О себе”, вы будете получать больше предложений пройти интервью.

2. Можно кратко суммировать весь свой опыт. Например “DevOps-инженер с трехлетним опытом работы в интеграторе и продуктовой компании с отличным знанием Kubernetes”.

3. Описать, что вы ищете и в каком направлении хотели бы развиваться. “Рассматриваю предложения с возможностью удаленки из-за пределов РФ и зарплатой в валюте” или “Хотел бы работать в компании, продукт которой полезен людям. Букмекерские конторы и казино не рассматриваю”.

4. Информация о ваших увлечениях вне работы совершенно не обязательна. Но если хочется сделать резюме более живым и человечным - почему бы и нет 🙂

⌨️ Всем привет!

Завтра обещанный пост на тему K8s 101. Разберу популярный вопрос с собеседований:

«Опишите путь, который проходит Pod от момента деплоя его манифеста до статуса Running».

А прямо сейчас читайте пост Кати 👰‍♀️ о том, что писать в разделе «О себе» в резюме!

⌨️ Задачи (4/4)

#PersonalExperience

Добро пожаловать в пятницу. Это финальная часть поста, который задумывался как короткий этюд о трудовых буднях DevOps-инженера, но разросся чуть ли не до полноценной статьи. Вспомним, о чем я писал раньше:

Часть 1, в которой я рассказываю о типах рабочих задач и их пользе.

Часть 2, в которой я по большей части описываю различия между инфраструктурой, построенной на физических выделенных серверах, и виртуальными или облачными решениями.

Часть 3, в которой я, наконец, описываю задачу и некоторые подробности её решения.

Подведем итоги

Я решил поставленную самому себе задачу. Что получил в качестве награды?

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

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

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

Респект и уважение от команды (скорее всего).

Что получила моя команда?

Сокращение количества действий для выполнения типовой и довольно частой задачи процентов на 90-95. Теперь она оценивается минимальным количеством стори-пойнтов. Надеюсь, что я также отсрочил чьё-то выгорание.

Вывод

Задачи, повышающие собственное work quality и work quality твоих коллег, обладают невероятным потенциалом для satisfaction. Если по-русски, то очень приятно видеть пользу от своего труда. Это помогает любить своё дело и видеть в нем смысл.

Любить свою работу полезно, потому что не любить то, чему посвящаешь треть своего времени, чревато негативными последствиями — как физического, так и ментального характера. Осознаю банальность вывода, но к чему пришёл, к тому пришёл.

Поэтому всем интересных задач, а я пошёл писать серию постов на тему K8s 101 и рисовать к ним схемы. Увидимся на следующей неделе!

⌨️ Задачи (3/4)

#PersonalExperience

Днями выше рассказал вам о некоторых нюансах профессии, с которыми мне пришлось столкнуться. В рабочем процессе присутствовала неавтоматизированная лакуна — порядка 200 кликов для каждого сервера. Она включала в себя выполнение операций на хосте в аналоге live-CD режима (с операционной системой, загруженной в оперативную память) и внесение полученных результатов в таблицу. Причём по одному значению, так как вывод из консоли не был отформатирован в достаточной мере.

Но как получилось, что столь очевидная цель для автоматизации оставалась неотработанной? Дело в нестандартной конфигурации: одни и те же команды утилиты, запущенные на разном железе, показывали если и не разный вывод, то, как минимум, различное расположение ключевых значений (тех, что в итоге оказывались в таблице). Это зависело, например, от производителя. Самый простой пример такой разницы — показания температуры ядер под нагрузкой. lm-sensors, указанная в скрижалях древних, выдавала разный вывод в зависимости от того, был процессор произведён Intel или AMD. Да что там производитель — вывод отличался даже в зависимости от поколения чипа.

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

Пришлось взяться за это. Ситуация осложнялась тем, что первый рабочий прототип утилиты (а это процентов 70 всей работы) я решил написать, не ставя никого в известность, используя только то время, что было выделено под тестирование серверов. Причина банальна: я не сомневался, что автоматизация возможна, и не сомневался в своей компетенции. Я думал о другом — хватит ли мне терпения довести утилиту до состояния, в котором ею сможет пользоваться кто-то, кроме меня. Потому не хотел идти к тимлиду с пустыми руками, имея лишь идею. Хотел оставить себе пути для отступления.

Не буду подробно описывать процесс разработки. Скажу лишь, что писал на Python, взяв за основу библиотеку fabric для основной части утилиты и openpyxl для парсера. Отдельную боль доставило тестирование дисков: пришлось разрабатывать для них отдельную логику, поскольку различались как их количество, так и состояние (диски могли поставляться дата-центром как в RAID, так и без него, с файловой системой нужного формата или без неё). Скрипт должен был, без ручного вмешательства, приводить диски к целевому состоянию.

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

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

⌨️ Задачи (2/4)

#PersonalExperience

Надеюсь ваша среда была легче чем моя.

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

Автоматизация и Infrastructure as Code — основополагающие понятия в нашей профессии, и поэтому мне больно делать что-либо вручную. Повторяя одно и то же действие несколько раз, ты буквально физически чувствуешь, как тупеешь. Особенно если знаешь, как это автоматизировать.

Даже в компаниях, где инфраструктура полностью описана в коде, может существовать неавтоматизированный разрыв между предоставлением сервера под управление и его попаданием в инфраструктуру. Особенно если провайдер не имеет API или сдаёт в аренду выделенные серверы.

Физические выделенные серверы (Dedicated) имеют ряд преимуществ над виртуальными и облачными решениями:

Предсказуемая производительность без влияния "шумных соседей" (noisy neighbors)

Отсутствие оверхеда гипервизора и задержек связанных с шарингом ресурсов.

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

Недостатков тоже хватает:

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

! Гибкость — если сервер простаивает, его ресурсы нельзя оперативно перераспределить.

Физическая уязвимость — поломка HDD, RAM или другого компонента может привести к простоям.

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

⌨️ Задачи (1/4)

#PersonalExperience

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

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

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

Какие задачи интересны лично мне в первую очередь?

Два типа задач.

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

Второй тип — это задачи, которые позволяют улучшить навыки в технологиях, востребованных на рынке труда. Решив такую задачу, понимаешь, что теперь твое время как специалиста стоит дороже. Для меня сейчас это в основном DevSecOps-таски: работа с GitLab CI, Vault, Terraform, Go, K8s и различным прикладным софтом.

С этими задачами всё еще проще: по сути, работодатель оплачивает время, которое ты тратишь (по большей части) на свое развитие. Такие задачи обычно затягиваются дольше запланированного срока. Они могут потребовать дополнительных тасков: например, если ты сильно превысил срок выполнения, но не добился поставленной цели. Описываешь промежуточные результаты и заводишь вторую часть. Что еще в них ценно — чаще всего они не срочные, никто не торопит, и можно работать в своем темпе.

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

Что это за задачи и подробности об одной из них — в следующем посте, который выйдет завтра.

Дайджест#1

#дайджест

Всем привет! Наконец-то пришло время выпустить первый дайджест. Он получился объемным и включает около сорока публикаций, это почти все полноценные посты, вышедшие с момента создания канала.

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

Приятного чтения!

#рекрутинг

👰‍♀️ Как точно НЕ получить работу в айти: 5 простых шагов. Вредные советы

👰‍♀️ Так почему они вредные?

👰‍♀️ Странные вопросы на интервью

👰‍♀️ Лучший запрос самооценки, лучшая обратная связь

��‍♀️ А нужно ли сопроводительное?

👰‍♀️ Когда сопроводительное действительно нужно?

👰‍♀️Как впечатлить рекрутера своим английским?

⌨️ HR фрустрирует

👰‍♀️ Календарный цикл найма: когда лучше всего искать работу

👰‍♀️ Самая высокооплачиваемая айти-профессия

#process_management

⌨️ Из чего сделаны наши процессы?

⌨️ Внутри процесса (thread inside)

⌨️ Имя отчество (PID PPID)

⌨️ Как они размножаются? fork()/clone() exec()

⌨️ Отцы и дети (parent - child processes)

⌨️ Родился, потерпел и умер: Жизненный цикл процесса

⌨️ Биография. Вспоминаем и делимся

⌨️ STAT Жди, работай, спи

⌨️ Сигналы: 30 способов умереть или быть убитым

#PersonalExperience

👰‍♀️ О моём опыте собеса на сисадмина (начало)

👰‍♀️ О моём опыте собеса на сисадмина (продолжение)

⌨️ Planning poker

⌨️ Когда я смогу закончить учиться?
(1/5) , (2/5) , (3/5) , (4/5) , (5/5) ;

#реальные_вопросы

⌨️ Вопросы с реального собеседования #1

⌨️ Мета вопросов в технических собесах

⌨️ Меняешь права - умножаешь на 2

#мотивация

👰‍♀️ Немного мотивации и добрых слов для джунов, которые ужасно устали от поиска работы 🥹

#docker

⌨️ Меняешь права - умножаешь на 2

⌨️ Контейнеры и Zero Trust. Познаём безопасность, прокачиваем резюме

⌨️ docker.sock

#k8s

⌨️ K8s. Компоненты кластера

⌨️ K8s. Pod

#карьера

⌨️ Не быть джуном

⌨️ Об отношениях с работодателем

#собеседования

⌨️ Немного о чудовищных собеседованиях

#интересное

⌨️ SQL-инъекции: технология древних хакеров, которая до сих пор работает

👰‍♀️ Что делать после провального интервью?

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

1. Запросите у рекрутера фидбек, чего именно вам не хватило для успешного прохождения интервью. Если вас игнорируют - выдыхайте, как говорится, мусор вынес себя сам. Скорее всего, остальные процессы в компании тоже настроены плохо, и это прекрасно, что вы не будете работать в таком месте.

2. На основании фидбека, а также собственных ощущений, выпишите вопросы, на которых застопорились, и распишите красивые, максимально полные ответы на них.

3. Если у вас есть ментор - разберите эти вопросы с ним.

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

⌨️ Об отношениях с работодателем

Всем привет!

Пост не совсем по той теме, что победила в голосовании, но про админские будни и кубер я еще напишу. А сейчас немного о другом, пока есть тема и вдохновение.

Начну издалека. Есть такая старая админская максима, звучит она как: «Работает – не трогай». Я не буду объяснять, как это связано с администрированием, думаю, большинство прочитавших этот пост прекрасно её поймут. Зато объясню, как она может быть связана лично с вашей работой.

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

Да, существуют механизмы премий, индексации и performance review, но о них мы поговорим отдельно. Сегодня же я хочу лишь упомянуть контроффер.

Но сначала банальность. Если в течение прошлого года вы не получили прибавку к зарплате, вы обеднели на 10%. Примерно такую инфляцию за 2024 год посчитал ЦБ. Подрос и средний чек в продуктовых магазинах. Поэтому рост вашей зарплаты в рублях должен как минимум покрывать инфляцию – если вы хотите не расти в доходе, а просто поддерживать текущий уровень жизни. 10% в год – это стагнация, уже не рецессия, но еще не рост.

Почему стагнация? Потому что ваш опыт, а значит и ценность как специалиста, растёт. Если растёт опыт, должна расти и оплата труда.

Вы и ваш работодатель (интересы которого представляет менеджер или тимлид) – не враги и не друзья. Ваши отношения – это не отношения носителя и паразита (кто бы кем кого ни считал). Работодатель – это не Атлант, который не только делает мир лучше, но еще и содержит вас. И не эксплуататор-мироед, который ворует прибавочную стоимость, сидя на куче золота. Отношения работника и работодателя – это симбиоз. И мыслить, я думаю, стоит исходя из этого.

Если молчит работодатель, значит, его всё устраивает. Если молчите вы, значит, вас всё устраивает.

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

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

Сначала просто попросите.

Поговорите с менеджером и попросите прибавку в 15–25%, в зависимости от ситуации. Послушайте, что вам ответят.

Если отказали (или затянули процесс) – начинайте эскалацию.

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

Проверено на собственном опыте, на опыте коллег и моих менти. Работаете в офисе, а хотите удаленку? Предложат удаленку. Хотите подработку? Одобрят. Нужно больше денег? Могут предложить план роста. Есть оффер? Попробуют перебить его. А если нет – у вас уже есть куда уйти, где ваш труд ценят больше.

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

Хотите обсудить? Вы знаете, с чего начать!
Если не общались со мной вживую – переходите по ссылке, оставляйте заявку на встречу. Если уже коннектились через Getmentor и у вас есть мой контакт – пишите в личку.

👰‍♀️ Самая высокооплачиваемая айти-профессия

Девопс часто называют одной из самых высокооплачиваемых айти-профессий, и отчасти потому она настолько желанна. Согласно статистике сайта dreamjob, средняя зарплата синьора в России - 350 000 рублей.

Но что, если я скажу, что существует более прибыльное направление, специалистам-джунам которого готовы платить 4-5 тысяч долларов в месяц? Я бы сама не поверила, если бы такая вакансия не пришла мне в работу.

Речь идет о Quantitative Researcher в хэдж-фондах. Это специалисты, близкие по стеку к ML-щикам, которые создают алгоритмы для автоматизированной торговли на фиатных или криптовалютных биржах.


Главным минусом данной профессии является очень сложный отбор: у работодателей в приоритете выпускники математических направлений топ-вузов, в первую очередь МФТИ, МГУ, СПбГУ, НИУ ВШЭ, затем - главные региональные университеты. В том месте, куда нанимала я, также было тестовое задание и целых два технических этапа, на одном из которых кандидатов “прогоняли” по всей вузовской программе, начиная с первого курса.

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

Так как это сложный поиск, такие компании часто обращаются за помощью в найме к кадровым агентствам. Что это значит? Что в некоторых случаях страница на Линкедин может помочь даже джуну без опыта, но с сильным образованием, получить интересное предложение. Не забывайте о профильных социальных сетях, каким бы ни был ваш грейд!

⌨️ Всем привет

Небольшой анонс: завтра выходит публикация Кати👰‍♀️— она получилась классной и интересной. Вам тоже должно понравиться! Тема — одна из самых высокооплачиваемых специальностей в IT.

⌨️ K8s. Компоненты кластера

k8s в схемах и схемах 1

#k8s

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

В схеме, пунктирной линией с серым заполнителем обозначен сам Kubernetes кластер. Внутри — два типа объектов Control Plane и Worker node.

Control Plane

Control Plane отвечает за управление кластером и обеспечение его работы. Он состоит из нескольких компонентов, которые могут работать на одном управляющем узле (master node) или быть распределены между несколькими узлами и реплицированы для обеспечения высокой доступности.

Kubernetes API Server: с ним непосредственно взаимодействуете как пользователь, так и другие компоненты Control Plane, потому что он предоставляет доступ к API Kubernetes, а значит является основным интерфейсом для Control Plane. На схеме занимает центральную позицию, на него указывают большинство стрелок.

Scheduler, компонент, который отслеживает вновь созданные поды без назначенного узла и выбирает узел для их запуска.При принятии решений о планировании учитываются следующие факторы: требования к ресурсам (как со стороны размещаемого пода, так и воркер-ноды или всего кластера), hardware/software/policy ограничения, affinity и anti-affinity спецификации, расположение данных, влияние подов друг на друга (избежание риска конкуренции за ресурсы) и дедлайны.

Controller manager, запускает логические компоненты (контроллеры) которые отслеживают состояние кластера и управляют его объектами чтобы обеспечить их соответствие желаемой конфигурации.

etcd, распределенное хранилище данных, которое постоянно хранит конфигурацию кластера.

Nodes

Рабочие узлы (worker nodes) – это машины, на которых выполняются контейнеризированные приложения.

Kubelet, агент, который обменивается с API сервером и управляет контейнерами на своем узле.

Кube-proxy прокси Kubernetes, он балансирует нагрузку сетевого трафика между компонентами приложения и поддерживает сетевые правил для узлов.
Container runtime

Container runtime: это среда для выполнения контейнеров. Она жёстко не закреплена и может поддерживать контейнерные рантаймы, соответствующие интерфейсу CRI (Container Runtime Interface). Наиболее популярные из них — containerd и CRI-O