Блог

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

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

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

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

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

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

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

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

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

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

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

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

  • Снапшоты (снимки состояния) — гениальное изобретение. Делаешь рискованный апдейт, ставишь сомнительный или по просту не знакомый софт, ломаешь систему, а потом за секунды откатываешься назад, как будто ничего и не было. Из-за этого возникает соблазн оставить снапшот «на всякий случай» подольше ведь надо же и потестить решение… А потом еще один. И еще…
    В итоге виртуальная машина начинает работать на снапшотах постоянно. Это совсем не хорошо и вот почему:

    Как вообще работают снапшоты?
    Чтобы понять корень зла, нужно заглянуть под капот гипервизора. Когда ты нажимаешь кнопку «Take Snapshot», система не делает полную копию твоего виртуального диска (это был бы бэкап, а снапшот — это не бэкап. Obviously huh?).
    Происходит следующее:
    Базовый виртуальный диск (VMDK, VHDX и т.п) переводится в режим «только чтение».
    Рядом создается новый пустой файл — дельта-диск (разностный диск).
    С этого момента все новые данные, которые операционная система пытается записать, летят именно в этот дельта-диск.
    Чем дольше ВМ-ка живет на снапшоте, тем больше разрастается дельта-диск. В худшем сценарии он может вырасти до размеров оригинального диска, и твоя ВМ-ка займет на хранилище в два раза больше места.

    Снапшот на снапшоте снапшотом погоняет: строим карточный домик
    Самая большая ошибка — создавать цепочки снапшотов. Допустим, ты сделал снимок перед обновлением базы данных, через неделю — перед обновлением ОС, а потом еще один перед правкой конфигов.
    Формируется дерево зависимости: Базовый диск -> Снапшот 1 -> Снапшот 2 -> Снапшот 3.
    Почему это катастрофа:
    Ужасающее падение производительности в долгой. Когда системе нужно прочитать файл, гипервизор сначала ищет блок данных в самом свежем снапшоте. Если его там нет, он спускается на уровень ниже, потом еще ниже, пока не дойдет до базового диска. Чем длиннее цепочка, тем сильнее задыхается дисковая подсистема. Нагрузка на чтение (IOPS) возрастает кратно.
    Риск потери всего. Цепочка снапшотов невероятно хрупкая. Если хотя бы один промежуточный дельта-файл повредится (например, из-за сбоя на СХД), вся цепочка данных после него превратится в тыкву. Ты потеряешь все изменения.
    Сложное удаление. Когда ты наконец решишь удалить старые снапшоты, гипервизору придется объединить (консолидировать) все эти гигабайты изменений обратно в базовый диск. Этот процесс сильно грузит систему, занимает уйму времени, а ВМ-ка может зависнуть («stun») в самый неподходящий момент.

    Снапшоты с сохранением ОЗУ и без: в чем подвох?
    При создании снимка гипервизор обычно спрашивает, нужно ли сохранять состояние оперативной памяти (Snapshot the virtual machine’s memory). У каждого подхода есть своя специфика.
    Без сохранения памяти (Crash-consistent)
    Записывается только состояние диска. Для гостевой ОС откат к такому снапшоту выглядит так, как будто серверу внезапно выдернули кабель питания, а потом включили снова.
    Плюсы: Создается очень быстро, не требует дополнительного места для ОЗУ.
    Минусы: Транзакции в базах данных, которые висели в памяти и не успели сброситься на диск, будут потеряны.
    С сохранением памяти (Application-consistent / Memory state)
    Гипервизор делает точный слепок не только диска, но и всего, что было в оперативной памяти (создается отдельный файл дампа памяти, равный объему выделенной ОЗУ виртуалки). При откате система оживает в ту же секунду, с открытыми окнами и незавершенными процессами.
    Скрытая угроза: В момент создания такого снапшота ВМ-ка буквально «замораживается» на доли секунды или даже секунды, чтобы безопасно сбросить содержимое ОЗУ на диск. В высоконагруженных системах (базы данных, почтовые серверы) эта пауза рвет сетевые соединения. Клиенты отваливаются, кластеры думают, что нода умерла, и начинают перестроение. Работать с такими снапшотами в продакшене нужно максимально осторожно.

    А когда это вредно?
    Есть отдельная каста машин, для которых снапшоты это либо гарантированная авария либо тупо бесполезно.
    Контроллеры домена Active Directory при откате ломают счетчики репликации и изолируются от остальной сети. Кластерные системы (Windows Failover Cluster, SQL Always On) невероятно чувствительны к микро-фризам: когда гипервизор (тот же ESXi) на долю секунды «станит» машину для создания или консолидации снимка, кластер теряет хартбиты и запускает ложный failover с разрывом пользовательских сессий. In-Memory базы (Redis, Memcached) вообще бессмысленно снимаить: без сохранения ОЗУ получишь пустую оболочку, а дамп памяти на диск может наглухо повесить сервис. Сюда же относятся тяжелые транзакционные БД и реал-тайм сервисы (телефония, NTP), где паузы на сброс кэша убивают производительность хранилища штормом IOPS и рвут сетевые соединения. Правило одно: если внутри крутится репликация, кластеризация или жесткая привязка ко времени — забываем про снапшоты и делаем нормальные бэкапы профильным софтом.

    Итог: правила гигиены
    Снапшот — это пластырь (а иногда тупо подорожниковый листик), а не гипс. Правила выживания здесь просты:
    Держи снапшот максимум 24-72 часа. Сделал работу, убедился, что все ок — удаляй (консолидируй).
    Не строй цепочки больше 2-3 снимков.
    Для долгосрочного хранения используй полноценные системы резервного копирования (бэкапы).
    Если о чем то забыл написать, дай знать в комментах или в ЛС. Всем тихой пятницы!

    P.S
    Само собой я не являюсь истиной в последней инстанции или цифровым миссией. А по сему мое мнение или же видение может не соответсвтовать твоему. В целом если мои статьи имеют пользу, это уже хорошо. А если нет, то на нет и суда нет.

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

  • Дано: Новенький кластер HPE. Физические хосты с сетевыми картами 25 Гбит/с. Виртуальные машины с адаптерами VMXNET3, подключенные через Distributed Switch (vDS).
    Проблема: При проверке скорости между ВМ утилита iperf3 показывает унылые 900 Мбит/с(??).
    Задача: Понять, куда делись остальные 24 гигабита, и почему скорость ниже, чем на домашнем роутере.

    Задача выглядела нетривиально, так как на соседнем кластере (Cisco HX) всё летало «из коробки». В следствии проверок мы прошли все стадии принятия и не малое количество процедур от проверки драйверов до глобальной перестройки сети, и вот как это было.

    Этап 1: Проверка базовой гигиены на уровне железяк (ОС и Драйверы).
    Первым делом исключил классику: старые драйверы и однопоточность
    Проверка адаптера: На ВМ установлен корректный VMXNET3, VMware Tools свежие..
    Многопоточный тест: Запустили iperf в 8 потоков, чтобы исключить упор в одно ядро CPU.

    iperf3.exe -c 10.10.10.111 -P 8
    

    Результат:
    – Sender: ~2.5 Гбит/с
    – Receiver: ~80 Мбит/с (!!!)

    Катастрофическая разница. Приемник буквально “захлебывался” пакетами. Появилось подозрение на RSS (Receive Side Scaling) — технологию, которая паралелит обработку трафика по ядрам проца.

    Проверили RSS в PowerShell:

    Get-NetAdapterRss
    

    Получил стандартный вывод: RSS включен, очереди распределены по ядрам. Настройки ОС в норме.

    Этап 2: Танцы с бубном (RSC и Interrupt Moderation)
    В Windows Server (2019/2022) есть функция RSC (Receive Segment Coalescing). На быстрых картах она часто конфликтует с драйверами VMware, вызывая дропы пакетов.

    Отключил RSC:

    Disable-NetAdapterRsc -Name "Ethernet*" #Тут имя вашего адаптера
    

    Скорость на приеме выровнялась с отправкой, но общий потолок остался на уровне ~2–2.5 Гбит/с. Провалы исчезли, но скорости нет.

    Тогда попробовал отключить модерацию прерываний (Interrupt Moderation) в свойствах сетевой карты. Это заставляет CPU обрабатывать каждый пакет мгновенно.
    Эффект: Стабильность повысилась, но скорость не выросла.

    Этап 3: Момент хуистины (UDP тест)
    Чтобы понять, виноват ли протокол TCP (окна, задержки) или сама «труба» (сеть), запустил UDP-тест. UDP — протокол “глупый

    iperf3.exe -c 10.10.10.111 -u -b 5G
    

    Ровная полка в 1 Гбит/с. И это как раз тот момент когда начинаю что то понимать, ведь, если даже UDP упирается в гигабит, значит, где-то стоит жесткое ограничение.

    Го искать? Го!:

    Network I/O Control (NIOC) на vDS: Лимитов нет (Unlimited), Shares High.Traffic Shaping: Выключен.

    Локальный vSwitch: Создал отдельный стандартный свитч, чтобы исключить баги Distributed Switch. Результат тот же.

    Этап 4: Нахожу слона в комнате виновника (MTU)
    Сравнил проблемный кластер HPE с работающим Cisco HX. Главное отличие: на Cisco используются кастомные карты с мощным Hardware Offload, а на HPE — стандартные адаптеры.

    При стандартном размере пакета MTU 1500 байт, чтобы прокачать 10 Гбит/с, процессору нужно обработать около 800 000 пакетов в секунду. В виртуальной среде накладные расходы слишком велики, и сеть просто упиралась в производительность CPU на обработку прерываний.

    Проверка гипотезы: Попытался пропинговать соседнюю ВМ большим пакетом с запретом фрагментации:

    ping -f -l 8972 10.10.10.111
    

    Ответ: Packet needs to be fragmented.

    Сеть физически не пропускала большие пакеты. Тупо уперлись в “софтовый потолок” ~3 Гбит/с для стандартного фрейма.

    Решение: Переход на Jumbo Frames (MTU 9000)
    Чтобы получить скорость, нужно уменьшить количество пакетов, увеличив их размер. Реализовал план Swing-миграции, чтобы не уронить прод (изменение MTU на vDS “на живую” может положить сеть):

    Подготовка: Вывел один физический аплинк из старого vDS.

    Физика: Сетевые инженеры перенастроили порт свитча на MTU 9000.

    Новый vDS: Создали новый Distributed Switch сразу с MTU 9000 и добавили туда освобожденный аплинк.

    ВМ: Переключил тестовые машины в новый vDS и включил Jumbo Packet: 9000 в свойствах адаптера VMXNET3 внутри Windows.

    Контрольный выстрел:

    ping -f -l 8900 10.10.10.111
    Reply from 10.10.10.111: bytes=8900 time=1ms…
    

    Пинг прошел! Путь чист.

    Финал: Замер скорости
    Запускаю iperf на новой конфигурации:

    iperf3.exe -c 10.10.10.111 -w 4M -P 8 -b 10G
    


    Результат:

    [SUM] 0.00-10.00 sec 7.64 GBytes 6.56 Gbits/sec sender
    [SUM] 0.00-10.00 sec 7.56 GBytes 6.50 Gbits/sec receiver
    

    Итог: Получаем рост производительности более чем в 2.5 раза (с 2.5 до 6.5+ Гбит/с) и абсолютно стабильный поток данных.

    Выводы
    MTU 1500 — это узкое горлышко для сетей 10/25 Гбит/с в виртуальной среде. Процессор просто не успевает обрабатывать заголовки.

    TCP лжет: Если скорость скачет или падает в ноль, проверяйте UDP. Если там «полка» — ищите лимиты в конфигурации.

    Swing-миграция — лучший способ внедрять изменения в сети без простоя. Строим новый «мост» рядом, переводим трафик, сносим старый. Но все же не забываем правило: Read-Only Friday.

  • «Дайте интернет, но чтобы безопасно и что бы было вчера готово!»
    В любой компании наступает момент, когда безопасность говорит: «Хватит». Хватит пускать пользователей в интернет с их рабочих станций, где лежит бухгалтерия, документы и доступы к базам.
    Задача прилетела мега-классическая: нужно обеспечить доступ к внешним веб-ресурсам для 200 сотрудников, но изолировать этот процесс от внутренней сети. Вариантов было немного:

    • Поставить каждому второй ПК (дорого, супер-тупо, стол как и бюджет, не резиновый).
    • VDI (VDI на 200 персон ради браузера? Оверкилл).
    • Обскурные решения которыми заполнены просторы интернетов.
    • Terminal Server (RDS) + RemoteApp. Наш выбор.

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

    Архитектура: Строим “загон” для Хрома. Мы не стали изобретать велосипед и развернули классическую ферму на базе Windows Server 2022.
    Connection Broker: Мозг операции, балансирует нагрузку.
    Session Hosts: Рабочие лошадки, где, собственно, и крутится Chrome.
    СХД: Профили пользователей (об этом ниже).

    Спойлер

    @Тут я хотел бы вставить скриншот из диспетчера серверов со списком хостов но ИБ строго сказала “А-та-та так делать!”.@

    Битва за ресурсы: Chrome vs RAM Главный враг терминального сервера — это современный веб. Один открытый YouTube в 4K может положить сессию целого отдела. Что мы сделали, чтобы сервер не умер в первый же день:
    GPO для Chrome — наше всё. Мы использовали официальные ADMX-шаблоны от Google.
    Отключение аппаратного ускорения. В виртуалке без vGPU оно только мешает, создавая лишнюю нагрузку на CPU.
    Блокировщик рекламы (uBlock Origin). Это не вопрос комфорта, это вопрос выживания. Баннеры и трекеры жрут трафик и ресурсы процессора. Мы внедрили расширение принудительно через политики.
    Управление вкладками. Расширения типа The Great Suspender помогают выгружать неактивные вкладки из памяти.
    Боль с кэшем. Хранить профили локально на хостах в ферме нельзя — юзера каждый раз может кинуть на новый сервер. Roaming Profiles — медленно. Мы остановились FSLogix.

    Тут же первая проблема: Кэш Хрома растет бесконечно. За месяц профиль может раздуться до 5–10 ГБ.
    Быстрофикс который стал постоянным решением: Настроили политику очистки кэша при выходе или перенаправили папку кэша в temp, который чистится. «Интернет по талонам» не предполагает хранения истории мемов за пять лет.

    Безопасность: RemoteApp создает иллюзию, что приложение работает локально. Но мы-то знаем, что юзверь находится внутри сервера. Чтобы любопытные пользователи не начали изучать файловую систему сервера через «Сохранить как…»:

    Скрытие дисков: Через GPO скрыли диски C: и D: сервера.
    AppLocker: Разрешен запуск только chrome.exe. Даже если они умудрятся скачать “super_game.exe”, запустить они его не смогут.
    Буфер обмена: Ограничили копирование файлов между сессией и локальным ПК, чтобы исключить утечку документов.

    Факапы и выводы Конечно, без приключений не обошлось.

    В первый день забыли настроить таймауты, и «висячие» сессии съели все лицензии. Настроили – радуемся.

    Кто-то нашел сайт, который майнит крипту в браузере, и один хост ушел в 100% CPU. настроили аллертинг и заодно обновили black-list.

    Итог: Ферма живет, 200 пользователей ходят в интернет, внутренняя сеть в безопасности. Нагрузка на техподдержку снизилась: если у юзера «глючит интернет», мы просто сбрасываем его сессию, а не чистим всякое на его компьютере. Хотя все же мне кажется что наиболее лучшим решением мог быть дополнительный слой защиты в виде разнообразные NGFW, HP Wolf Security, RBI и иже с ними, но это уже совсем другая история…