⌨️ Planning poker

#Agile #PersonalExperience

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

Название метода указывает на проблему, которую он пытается решить: как с большей точностью оценить и запланировать задачу.
Сначала вводные. Бизнес или смежные отделы просят отдел DevOps решить большую задачу — скажем, развернуть в инфраструктуре новый k8s-кластер или расширить существующий. Эта большая задача оценивается приблизительно и с запасом, в формате: «Сделаем до такого-то числа, если не возникнет форс-мажоров». Так как задача большая, её необходимо разделить на несколько задач поменьше, которые уже можно оценить с той или иной точностью.
Итак, собираем новый кластер. Что надо сделать?

Декомпозируем задачу:
Заказать новые серверы у хостинговой компании.
Протестировать их (чтобы предупредить проблемы при эксплуатации).
Выполнить преинстал (новые серверы должны на базовом уровне соответствовать другим серверам парка в части ОС, установленного базового ПО, сетевых настроек, прав пользователей и так далее).
Развернуть на них кластер.
Настроить мониторинг кластера и серверов.
Подключить кластер к уже существующей реализации Argo CD (инструмент для удобства деплоя, выполняющий роль прослойки между вашим репозиторием и кластером).

Каждую задачу необходимо оценить отдельно.

Приступаем к оценке. Сразу обозначу некоторое противоречие: несмотря на то что мы будем оценивать задачу в часах, оцениваем мы скорее не время, а усилия и ресурсы, необходимые для завершения задачи с учётом неопределённости.

В оригинальной версии покера планирования это могут быть стори-пойнты (Story Points) — по сути, абстрактные единицы оценки сложности задачи. Классические статьи на эту тему предлагают пользоваться размером одежды (XS, S, M, L, XL … XXL), размером собак (от чихуахуа до волкодава) или просто числами из адаптированного ряда Фибоначчи (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 или 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100). Зачем такие сложности?

Это попытка абстрагироваться от времени как единицы измерения. Однако я предпочитаю всё-таки оценивать задачи в часах. Будем использовать следующий ряд: 2h, 4h, 8h или 1d, 2d, где h — часы, d — дни. Даже из этого не слишком длинного ряда я бы убрал 6h как оценку, нагнетающую неопределённость: рабочий день длится 8 часов, а оценить задачу в ⅔ рабочего дня не совсем понятно. Цифра 6, полагаю, предназначена для задач, которые кажутся слишком большими для 4 часов и слишком маленькими для 8. Но почему бы тогда не округлить в большую сторону?

Каждую задачу оценивает каждый член команды. Он оценивает, сколько усилий, по его мнению, требуется потратить на задачу. В случае онлайн-голосования оценки отправляются боту для голосования. В офлайне участники кладут перед собой карту рубашкой вверх, показывая, что сделали выбор. После голосования бот показывает результаты, либо карты переворачиваются. Участники, чья оценка оказалась самой высокой или низкой, обосновывают её. Обсуждение продолжается до достижения консенсуса, то есть до тех пор, пока все не согласятся с оценкой, или не будет выработана доминирующая позиция группы.
Правила могут модифицироваться: можно использовать таймер для ограничения времени обсуждения или несколько кругов голосования. Достигли консенсуса, присвоили оценку, закрепили её в вашем таск-трекере, переходим к следующей задаче.

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

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

#из_первых_рук
#рекрутинг

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

Я не сторонник идеи прекрасного мира рынка без HR и уж точно не считаю, что именно они сломали систему найма. Мы живем в мире с разделением труда, и возвращаться к чучхе, где каждый тимлид сам себе HR, мне не хочется. Кесарю — кесарево, слесарю — слесарево. В противном случае можно договориться до того, что вообще никто, кроме разработчиков, в IT не нужен.
И тем не менее, есть ситуации, когда HR может создать больше проблем, чем решить. Вот пример. Если СТО опаздывает на собеседование, то не стоит брать на себя его работу и начинать собеседовать вместо него. HR, пытаясь заполнить паузу, попросила соискателя рассказать о своём опыте. Соискатель рассказал — и, на мой взгляд, прекрасно справился: самопрезентация была отличной, технологии, задачи, трудности — всё изложено чётко и по делу. HR кивала и подбадривающе улыбалась,. А потом пришел СТО и задал тот же самый вопрос.

На этом этапе соискатель, осознав бессмысленность своего первого ответа, стушевался. Его повторная самопрезентация была сбивчивой: технологии, задачи, трудности — всё скомкано и неполно. Закончил он на полуслове, так что повисла неловкая пауза. Пара коротких ответов на вопросы СТО — и сразу перешли к технической части. Самопрезентация была провалена.
Есть ли в этом вина HR? Можно ли было поступить лучше? Думаю, да. Например, HR мог просто завести лёгкий разговор, чтобы разрядить обстановку и потянуть время: о погоде, интересах, чём-то нейтральном. Возможно, если бы соискатель воспринял первый вопрос как "разминку" и вложил в ответ меньше стараний, ситуация сложилась бы иначе. Или если бы HR предложил ему кратко подготовить ключевые моменты для СТО. Но сложилось как сложилось. Вывод следующий: HR не принимает решения об успешности технического интервью. Держите это в голове, оказавшись в похожей ситуации, и приберегите своё вдохновение для тех, кто действительно будет выносить вердикт.

Однако фрустрацию от проваленной самопрезентации можно превзойти. Например, вот такой обратной связью от HR:

XXX, добрый день!
Хотела бы сообщить обратную связь, как и обещала.
К сожалению, в данный момент не удалось получить положительный фидбек от лида команды. Ваш грейд был оценён на Junior+, мы же сейчас ищем Middle+/Senior. Спасибо за уделённое время и желаем вам успехов!

Спасибо за подтверждение грейда, конечно. Собеседование проходил Junior+, он претендовал на оклад Junior+, имел резюме с четко указанным Junior+ опытом. Как получилось, что джун попал на собеседование для сеньоров? Соискателя не смутило, что в вакансии указаны требования опыта, которого у него нет. Это была очень большая компания, и он рассудил: раз приглашают на техсобес, значит, его опыт устроил. HR не смутило "несеньёрское" резюме и запросы по окладу. Лид команды тоже не придал значения несоответствию уровня. Все остались довольны (нет), все с пользой (нет) провели своё время. Где же тот самый HR-фильтр, когда он так нужен?
Эти истории не выдающиеся, и даже провал HR в каждой из них не так очевиден. Главная проблема в них, конечно, пресловутое недопонимание, или, английское слово, подходящее чуть более, — miscommunication.
Тем не менее, истории правдивые, без прикрас и, возможно, даже слегка поучительные.

Всем успеть завершить дела до Нового года и провести время с пользой!

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

#PersonalExperience

Этот вопрос повис в воздухе в тот момент, когда я осознал, что для развития себя как условного DevOps-инженера, знаний, которые я получаю на работе, никогда не будет достаточно. Придётся учиться и получать знания дополнительно и, скорее всего, на протяжении длительного времени. Причин тут огромное количество, вот 6, что пришли мне в голову первыми:

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

Сертификации и собеседования. Мне на ум не приходит отрасль, где настолько требовалось подтверждение знаний и было столько вендоров, это подтверждение предоставляющих. А зачем они нужны лично тебе? Смотри пункт первый: если сертификат может удвоить твою зарплату, то почему бы его не получить? Про IT-собеседования тут даже ничего писать не буду, кто знает, тот знает. Кто не знает, у меня ещё много постов на эту тему будет.

Всем привет, пост в этот раз получился очень объёмным, поэтому я разбил его на 5 (!) частей, так что это выходит первая из пяти.

В следующей части я вкратце опишу ещё две причины и отвечу на вопросы:
Как legacy на вашей текущей работе заставит вас почувствовать отставание?
Почему автоматизация вами рутины приводит к рутине второго порядка?

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

#рекрутинг

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

Календарный цикл найма айти-специалистов в России условно делится на 5 сезонов.

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

Февраль-апрель: пик активности. Салаты доедены, проекты стартуют.


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

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


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

Желаю счастливого нового года и, если планируете менять работу, дотянуть до следующего пика найма на нынешнем месте!

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

#PersonalExperience

В предыдущей серии: жадность и специфика отрасли как вечные драйверы вашей учёбы в нерабочее время.

Legacy. Всегда в положении догоняющего. Например, в 95% случаев практики эксплуатации вашей инфраструктуры отстают минимум года на три (а то на 5–10) от современных отраслевых стандартов. Действительно, нам бы успевать поддерживать актуальные версии утилит, какие там инфраструктурные инновации? Если в саму концепцию вашей инфры не заложена гибкость (а она, скорее всего, не заложена), то хоть сколько-нибудь значимый пересмотр и изменение практик будет стоить вам столько головной боли, человеко-часов и согласований со смежными отделами, что высказывание «работает — не трогай» покажется вам непреложной истиной. И даже если вам удастся согласовать инновации, то компетенций и опыта для их внедрения, скорее всего, не окажется, придётся зарываться в документацию и набивать шишки, что в целом не такой уж и плохой путь: он удовлетворяет двум критериям — вам за это платят и ваша компетенция растёт. Но опять же это не учеба, это боевые знания, которые хоть и ценятся выше, всё же несколько ограничены реальными условиями, выделенными под задачи временем и вечной необходимостью технических компромиссов (читай костылей, то там, то тут).

Рутина. Эх, если бы хотя бы каждый второй рабочий час шёл на улучшение ваших навыков, но нет: затыки, тушение пожаров и рутина — вечные спутники инженеров нашей направленности. И даже избавляя себя и свой отдел от рутины путём автоматизации того, что раньше делалось руками, bash-скриптами или бог ещё знает чем, вы просто выходите на новый уровень рутины. Теперь вам предстоит поддерживать ваше решение до собственного ухода из компании, а всё потому что вы просто автоматизировали рутину, не изменив саму практику.

В следующей части я вкратце опишу ещё две причины и отвечу на вопросы:
- Какой процесс сильно ускорило широкое распространение нейросетей?
- Почему в большинстве случаев переходить на новую работу выгоднее, чем просить повышения на старой?

Пишите в комментариях, почему лично вы не можете сейчас взять и перестать учиться, может быть наберем материал на ещё один пост. ⬇️

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

#PersonalExperience

Первая часть
Вторая часть

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

Сфера меняется. Вы можете поверить в то, что 8 лет назад крутым админом делало умение писать bash-скрипты, которые могли в цикле пробежаться по списку сервисов и выполнить там ту или иную команду? А что 5 лет назад человек, который мог превратить ваш doc-файл с инструкцией по подготовке сервера, установке и настройке утилиты в Ansible-роль, был самым ценным сотрудником в отделе? Вот и я нет, а это было. Абсолютно непонятно, что быстрее девальвируется: наши навыки или наша зарплата. И это происходило ещё до того, как в нашу жизнь ворвался генеративный AI. С какой скоростью сейчас наши навыки станут обесцениваться — страшно представить.

Рынок растёт быстрее, чем зарплата. Сидеть на одном месте абсолютно невыгодно. Новички, приходящие в вашу компанию, стандартно будут получать больше. А вы, требующий повышения или хотя бы индексации, будете получать крохи, и в конце концов решите, что сменить работодателя, получив x2 к окладу, всё же слегка продуктивнее, чем выпрашивать по 10–20 процентов в год. А чтобы сменить работу, требуются знания, адекватные рынку.

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

Пишите в комментариях, почему лично вы не можете сейчас взять и перестать учиться. Может быть, наберём материал на ещё один небольшой пост. ⬇️

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

#PersonalExperience

Первая часть
Вторая часть
Третья часть

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

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

Подготовьтесь и пройдите сертификацию в зависимости от вашего профессионального профиля. Работаете с облаками, которые располагаются вне РФ, пройдите сертификацию одного из провайдеров большой тройки: Azure (Microsoft), если собираетесь работать на европейскую компанию, AWS, если на американскую, Google Cloud, если вам нравится Google Cloud. Если работаете напрямую с Linux, сдайте вендор-агностик CompTIA Linux+ или LPIC, или специфическую типа Red Hat (они, кстати, сертифицируют и по Ansible тоже). Работаете с кубером — пройдите одну из соответствующих сертификаций от Linux Foundation. Там ещё HashiCorp сертифицирует IaC, круто cloud-агностик-скиллы, куда же без них) и GitLab удостоверяет ваши знания по автоматизации…

Получили? Не забудьте сменить работу (переоценка ваших новых и подтверждённых знаний на старом рабочем месте будет проходить оооооочень медленно). Готово, вы великолепны, можно не учиться года два-три, пока не придётся обновлять сертификат, но вспоминать же всё равно легче, правда? Там ещё какая-нибудь must-have технология появится на горизонте.

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

⌨️ Когда я смогу закончить учиться? (5/5)

Первая часть
Вторая часть
Третья часть
Четвертая часть

В предыдущей серии:
Сертификации и смена работы, очень обнадеживающе (нет).

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

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

Но что-то мне подсказывает, что если вы тут, то цель у вас несколько другая. Может быть, найти новую работу и увеличить свой доход в два раза? Релоцироваться в Европу? Или найти валютную удалёнку? Work-life-study balance мы тоже обязательно найдём, но сначала придётся хорошенько поработать. Когда я смогу закончить учиться? Когда почувствуете сытость, когда вам станет абсолютно комфортно с финансовой и карьерной точки зрения.

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

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

⌨️ K8s. Pod

#k8s

Емкое слово pod, означающее в английском то ли стручок бобового растения (см. «шапку поста»), то ли группу (стаю) морских млекопитающих, вроде дельфинов или китов (см. лого Docker), в некоторых плохих переводах неплохих тематических книг обозначается как МОДУЛЬ. Скажите мне, зачем переводить на русский язык технические термины?

Но это тема для отдельного поста.

Нас же интересует, что за сущность такая в Kubernetes pod и какую задачу она решает. Почему вообще оркестратор контейнеров работает не с контейнерами как таковыми, а с pod’ами, которые в свою очередь эти контейнеры содержат?

Неправильный ответ на вопрос, что такое pod, мог бы звучать как-то так:

Под в Kubernetes — это особый контейнер, который может содержать несколько других контейнеров, но обычно содержит только один. Фактически это всё тот же контейнер, только с дополнительной k8s спецификой.

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

Аналогия, объясняющая pod как «logical host» для приложения, мне нравится. Идея в том, что контейнер предназначен для запуска только одного процесса: каждому процессу — свой контейнер. А значит, для группировки и связывания контейнеров нам необходима конструкция более высокого уровня.

У нас есть несколько родственных процессов, которые требуется обеспечить (почти) одинаковой средой выполнения и одним и тем же контекстом. Вместо того чтобы запускать все процессы в одном контейнере, мы разделяем их на независимые, но тесно связанные, контейнеры и помещаем внутрь pod. Так достигается комбинация изоляции — с одной стороны — и удобной интеграции — с другой.

В следующих постах попытаемся расширить тему. В частности, попробуем понять, каким контейнерам удобно подобное «внутриподовое» соседство, поговорим о pod lifecycle, о pod статусах и о многом другом, а потом пойдём вверх по иерархии и поймём, что управляет самими pod’ами.

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

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

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

#рекрутинг

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

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

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


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

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

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

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

#карьера

Всем привет!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#рекрутинг

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

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

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

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

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

Дайджест#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/4)

#PersonalExperience

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

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

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

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

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

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

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

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

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

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

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

#PersonalExperience

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#PersonalExperience

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

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

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

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

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

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

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