Рубрика: Истории

Всякие байки. Мои и не только.

  • Почему ходить на собеседования нужно, даже если у вас есть работа

    Существует стереотип: если человек ищет работу, значит, у него, а иногда с ним, «что-то не так» на текущем месте. Однако для опытного специалиста (и тут не только про ИТ) собеседование — это не просьба о приеме, а полноценный инструмент профессионального развития.

    Почему? Потому-что:

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

    • Соответствует ли твоя зарплата среднему чеку по городу (или удаленке). Какие бонусы и условия сейчас считаются стандартом в индустрии.

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

    В третьих навык прохождения интервью — это тоже навык
    Собеседование — это стресс. Если ходить на них раз в 5 лет, этот навык атрофируется.

    • Учишься быстро и четко формулировать свои мысли.
    • Тренируешь умение презентовать свои кейсы.

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

    В четвертых это расширение нетворкинга
    IT-мир (особенно в рамках одного города) довольно тесен.
    Ты знакомишься с техническими директорами и лидами других компаний.
    Даже если ты откажешься от оффера сейчас, есть шанс оставить о себе положительное впечатление. В будущем это может вылиться в интересное предложение напрямую, минуя фильтры HR.

    В пятых это смена фокуса и профилактика выгорания
    Ежедневные задачи на одном месте могут замылить глаз. Общение с коллегами из других команд дает «взгляд со стороны». Иногда после интервью понимаешь, что на текущем месте всё на самом деле очень круто настроено, и это дает новый импульс работать дальше. Или наоборот — понимаешь, что пора двигаться дальше.

    Резюмирую мысль
    Собеседование — это не измена\предательство\древоточство и\или акт вероломства по отношению к текущему работодателю. Это своего рода гигиена карьеры. Хотя бы раз в год полезно «выходить в свет», чтобы держать руку на пульсе технологий и сохранять уверенность в завтрашнем дне.

    В заключении, поделюсь впечатлением после прохождения нескольких собеседований за последнее время. Как я описал в третьем пункте стоит ходит на собеседования по чаще чем раз в пять лет. у меня между собеседованиями разрыв был в 4 года. Конечно у меня были собеседования и в другое время но они были достаточно лайтовыми и проходили в кулуарах кабинетов руководителей. Но я решил встряхнуть себя и открыться миру в поисках новых возможностей. Одно из последних собеседований и сподвигнуло меня на написание этой записи. Придя на собеседование в одну довольно известную контору я подвергся полуторачасовому кросс-опросу по тех знаниям и основам с замашками на некоторую обскурщину. И я пришел к выводу что кое какую матчасть я вообще забыл, а кое чего даже и не знал, а если и знал то поверхностно. И знаешь что? После этого собеседования я вышел окрыленным. Я осознал где я проседаю и решил заняться домашкой. И это было круто. Вообще мне повезло что меня собеседовали очень “Шарящие” специалисты. Я узнал их мнение о продуктах которые мне претят и познал иную точку зрения что открыло мне новое поле для размышлений. Как раз после собеседования я крепко задумался о том что зря не пробовал себя по чаще.
    ВЫвод, на собеседованиях, а особенно качественных, ты понимаешь чего стоишь, и куда стоит расти.

  • Вскрытие покажет. Или что такое Postmortem

    После одного инцидента на работе, один из моих сотрудников задал вопрос: “Нафига мы вообще сейчас роемся во всех логах? Мы же отремонтировали все.” Его вопрос ввел меня в ступор. Мне показалось что это просто очевидная-очевидность, что “Это база! Это знать надо!”. Но оказалось со стороны взгляда джуна, мы вместо того что бы работать уже пол дня сидим и разбираем каждый лог и лезем во все щели. После того как моя оторопелость прошла, я крепко задумался над тем как же мне объяснить что мы делаем и зачем это нужно. Сейчас будут мои размышления о Postmortem в айтишке.

    Проведение Postmortem (или же Post-Incident Review) — это супер важный этап управления инцидентами, который ни что иное как возможность для улучшения системы. Если просто “потушить пожар” и забыть, есть риск столкнуться с той же проблемой снова, но уже с большими потерями.

    Почему это необходимо:

    1. Предотвращение рецидивов
      Obviously huh? Postmortem позволяет докопаться до коренной причины (Root Cause) инцидента. Часто то, что кажется причиной (например, “сервер упал”), является лишь симптомом. Настоящая причина может крыться в ошибке конфигурации, логике кода или недостатке ресурсов. Устранив корень проблемы, можно почти гарантировать, что именно этот сценарий больше не повторится.
    2. Улучшение мониторинга и снижение времени простоя
      Анализ показывает не только то, почему все сломалось, но и как мы на это отреагировали.
      MTTD (Mean Time To Detect): Как быстро мы узнали о проблеме? Если о сбое сообщили пользователи, а не мониторинг, значит, ваши аллерты настроены херово и через жопу неверно.
      MTTR (Mean Time To Recovery): Как быстро мы все починили? Postmortem помогает найти инструменты или инструкции, которых не хватало для более быстрого восстановления (А еще дает точку для давления на начальство что бы выделили бюджеты).
    3. Обмен знаниями и обучение команды
      В сложных системах один человек редко знает всё, а если он говорит что знает все то скорее всего он пизЛукавит. Инцидент часто вскрывает “серые зоны” в архитектуре. Документирование инцидента помогает передать опыт всей команде, чтобы в следующий раз любой инженер знал, куда смотреть. Это снижает зависимость от конкретных “героев”, которые единственные знают, как чинить ту или иную подсистему.
    4. Культура без вины (Blameless Culture)
      Эффективный Postmortem должен быть Blameless (без поиска виноватых!!!). Если целью разбора является наказание сотрудника, люди начнут скрывать ошибки. Если же цель — улучшить процесс, люди будут открыто говорить о том, что пошло не так (например, “я нажал кнопку, потому что инструкция была неясной”). Это позволяет чинить процессы, а не людей. В целом я активный противник идеологии “НАЙТИ И НАКАЗАТТ!”. Все мы люди, и никто не застрахован от ошибок. Скрывать свои ошибки в современном мире бессмысленно и бесполезно, а вот учится на них это единственно верное действие.
    5. Приоритизация технического долга
      Бизнес часто требует новых фич, отодвигая рефакторинг на второй план. Postmortem дает вам фактические данные (потери денег, времени, репутации), которые можно использовать как аргумент для выделения времени и бюджетов на устранение технического долга и повышение стабильности.

    Вывод
    Без Postmortem-а мы обречены наступать на одни и те же грабли. С ним — каждый сбой делает вашу инфраструктуру надежнее. Ведь что нас не убивает, делает нас нервознее сильнее!

  • Шрамы в инфраструктуре: что скрывают имена виртуальных машин

    Недавно ко мне подошёл младший коллега и спросил:

    «Почему у некоторых виртуальных машин в имени приписка _rest или _restored

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

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


    На пример:

    Однажды мы потеряли SRV-DC01 — контроллер домена, который на тот момент был PDC. Причиной стала банальная проблема — datastore переполнился, потому что старые снепшоты не удалялись корректно. В итоге машина «упала», и пришлось срочно поднимать восстановленную копию. Мы добавили суффикс _rest, чтобы сразу видеть, что это новая инстанция, и не путать с оригиналом в документации и системах мониторинга.

    Другой случай — SRV-CRM24_restored. Сервер с CRM-системой упал после неудачного обновления. В тот раз решение внедряли в спешке, и обкатку в тестовой среде посчитали «лишней тратой времени». Клиенты начали жаловаться через 10 минут после начала сбоя. DR-план сработал, но осадок остался. Суффикс — напоминание о спешке, которой могло бы не быть.

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


    Да, менять имя виртуальной машины в vCenter — не лучшая практика. Это может нарушить скрипты, автоматизацию, документацию. Но в таких случаях это осознанное решение. Это не про эстетику, а про историю инцидентов, которые нельзя забывать. Эти «шрамы» служат не только напоминанием мне, но и важным сигналом для других коллег: здесь когда-то было больно.


    Инфраструктура — не абстрактный набор серверов. Это система, которая развивается, ошибается, учится. И важно помнить, где она уже «спотыкалась». Потому что забытые уроки обычно повторяются.