SYSADMIN.KG

Блог

  • Хроники HPE Alletra MP: Как обновить ось, добавить NVMe-полку и не поехать кукухой

    Семь лет плотной работы с IT-инфраструктурой приучили меня к одному простому правилу: если энтерпрайз-вендор заявляет, что новая фича работает по принципу «Plug-and-Play», значит, впереди бессонная ночь, чтение CLI-референсов и ковыряние в неочевидных логах.

    Задача стояла тривиальная: есть головное устройство HPE Alletra Storage MP B10100. Нужно на горячую подцепить к нему дополнительную JBOF-корзину с NVMe-дисками по 100Gbit оптике. Спойлер: всё завелось и полетело, но количество неочевидных граблей, разбросанных HPE на этом пути, просто outrages.

    Казалось бы, что может пойти не так при штатном обслуживании энтерпрайз-хранилки за много денег? Вендоры давно обещают бесшовные апгрейды, non-disruptive операции, plug-and-play и прочий маркетинговый булшит.

    На практике же работа с железом такого уровня — это хождение по минному полю в ботинках 49-го размера. Ниже — хронология двух увлекательных ночей с массивом HPE Alletra Storage MP B10100, которые заставили вспомнить архитектуру сетей, проклясть корпоративные VPN, откопать в коробках невиданные кабели и применить древнюю сисадминскую магию.

    Часть I: Апгрейд операционки и исчезнувшая нода

    Задача стояла тривиальная: обновить СХД с версии OS 10.4.5 до 10.4.20.

    Акт 1. Исчезнувший Upgrade Tool и битые подписи

    Запускаем pre-update checks. Массив радостно сообщает: чтобы накатить новую ось, тебе нужен HPE Storage Software Upgrade Tool версии 79. Сейчас стоит 74-я. Логично? Логично. Иду на портал HPE Support Center. Ищу 79-ю версию. А ее там тупо нет. Вендор решил, что промежуточные сборки — это мусор, скрыл их в архивах и оставил только свежие — 83 и 85.

    Качаю 85-ю (мы же любим up-to-date), пытаюсь скормить ее массиву и получаю с ноги в лицо: Signature validation failed... Retval 512 and Status 2.

    Оказывается, между 74-й и 85-й версиями HPE успели сменить криптографические ключи подписи. Старая система смотрит на новый сертификат как баран на новые ворота и шлет пакет нахер. Решение: Скачиваем версию 83 (она оказалась достаточно старой, чтобы ее подписи еще валидировались, но достаточно новой, чтобы обновить ключи). Скармливаем нераспакованный .iso — утилита обновляется. Едем дальше.

    Акт 2. Мастер ушел за хлебом

    Запускаем обновление самой ОС. Демон апгрейда корректно переводит ноду 1 (slave) в сервисный режим, шьет, ребутает, возвращает в кластер. Продуктовая нагрузка жива, полет нормальный.

    Дальше демон отправляет в ребут мастер-ноду с индексом 0. И тут наступает звенящая тишина.

    Проходит 10 минут, 20, 40… В активных тасках UI висит Restarting the management server на издевательском 1-м проценте. Сыпятся алерты:

    • Cluster Link Port 1:5:1 Node 1: Down
    • Cage I/O Module 2 is Noncritical

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

    Акт 3. Квест «Где мой iLO, чумба?»

    Чтобы понять, какого х-я происходит с нулевой нодой, нужно попасть в iLO. Проблема в том, что IP-адреса менеджмента никто не то что не документировал, их вообще не настраивали при первой инициализации, можно а зачем? Сетевики клянутся, что линки на портах горят, но там абсолютное зеро — ни мак-адресов, ни пакетов, тупо мертвая тишина на коммутаторе.

    Тут дотумкал, что мак-адреса, напечатанные на “ушках” (ручках) самой СХД, прилеплены туда не для красоты. Берем эти маки, конвертируем их в форматы IPv4 и IPv6. Адреса бьются. Пытаемся зайти — болт. Тайм-аут соединения.

    Разгадка оказалась банальной но от того не менее эпичной. У нас было активно подключение к банку через Cisco AnyConnect. И этот бл*дский VPN-клиент молча заворачивал локальные роуты и IPv6-трафик в свой туннель. Стоило разорвать соединение с Cisco, как прямая адресация заработала, и веб-морда iLO милостиво пустила нас внутрь.

    Акт 4. Root Cause и великая Втыкайка-Вытыкайка

    Заходим в iLO нулевой ноды. Сервер находится в полностью выключенном состоянии (Standby). Открываем IML логи и видим картину маслом: нода не смогла пройти POST из-за аппаратной ошибки чтения первой плашки ОЗУ.

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

    Питание подается, контакты восстанавливаются, нода успешно проходит POST и одупляется.

    Акт 5. Добиваем кувалдой через CLI

    Поскольку нода валялась в коме больше часа, автоматический таск в UI давно сдох по тайм-ауту. Пришлось брать управление в свои руки. Заходим по SSH на менеджмент-интерфейс и расчехляем скрытую уличную магию команд upgradesys:

    • upgradesys -status -d — чекаем, где именно завис процесс.
    • upgradesys -continue — пинаем демона, чтобы он продолжил работу с прерванного места.
    • upgradesys -auto — возвращаем процесс на автоматические рельсы.
    • upgradesys -postupgrade — коммитим новую версию и вычищаем мусор. Параллельно мониторим весь этот цирк через showtask -d $task_ID. Апгрейд ОС завершен.

    Часть II: Экспансия и кабельная шизофрения

    Думаете, на этом приключения закончились? Хер там плавал. Настало время прицепить к массиву на горячую дополнительную JBOF-корзину с NVMe-дисками по 100Gbit оптике.

    Акт 1. Не в ту дырку

    Через менеджмент DSCC инсталлируем новые 100Gbit HBA-адаптеры. Устанавливаем полку, кидаем линки, подаем питание. На картах радостно загораются зеленые светодиоды. Запускаем мастер Add Drive Enclosure в локальном UI. Мастер пишет Waiting for 1 drive enclosure to be added… и виснет наглухо. Диски на полке горят, но не моргают.

    Лезем в консоль делать showport. Карты видятся в системе, но их тип — free, а протокол — IP. Контроллер считает, что в него воткнули обычные Ethernet-линки, и даже не пытается искать на том конце NVMe-корзину. Кнопки Port Personalization в локальном UI не существует.

    Разгадка: Оказалось, что мы воткнули HBA-адаптеры в 4-й слот. В архитектуре Alletra MP 4-й слот хардкодно зарезервирован под Ethernet-трафик (iSCSI, репликации и бэкапы). Для подключения backend-полок по NVMe-oF карты должны стоять строго во 2-м и 1-м слоте. Вытаскиваем, перетыкаем во 2-й слот — магия! Контроллер мгновенно увидел NQN-адреса IOM-модулей.

    Акт 2. Зависание на 25%

    Запускаем задачу снова. Прогресс-бар бодро ползет и встает колом на 25%. Смотрим статусы:

    • showcage показывает, что полка добавилась, но висит в статусе degraded.
    • showpd показывает все 24 диска со статусом new, но емкость в систему не отдается.

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

    1. На головном устройстве (HBA во 2-м слоте) кабель должен торчать в ПРАВОМ порту.
    2. На дисковой корзине кабель должен входить в ЛЕВЫЙ порт IOM-модуля.

    UI массива тихо сходил с ума, потому что ждал NQN-адреса на правых портах, не видел их там, зажигал алерты о потере путей и переводил полку в аварию. Перекинули кабели на горячую по схеме — degraded сменился на normal, диски заморгали, сырые терабайты упали в пул.

    Акт 3. Пасхалка с OCuLink

    Отдельная боль — подключение сети управления для новой корзины. На задней панели есть узкий сервисный модуль CDM (Chassis Discovery Module). Но воткнуть туда обычный RJ-45 нельзя. Разъем там — OCuLink. Чтобы подключить эту приблуду к свитчу, нужно откопать в коробке с аксессуарами всратый переходник-хвостик OCuLink-to-Ethernet, вставить его до щелчка, и уже в него втыкать витую пару. В официальных мануалах об этом пишут самым мелким шрифтом а без этого переходника он отказывает в инициализации полки!

    Акт 4. Звенящая тишина даунгрейда

    Железо работает, емкость доступна, но в дашборде висит раздражающий алерт: IO Module firmware: Unknown. Лечится командой upgradecage cage41. Консоль выдает: Upgrading cage cage41 from rev 0798 to revision 0656... и замолкает на 56 минут.

    Массив выполняет даунгрейд прошивки новой корзины, чтобы она жестко соответствовала версии ядра СХД. В этот момент нельзя паниковать и бить по клавиатуре. В фоне массив льет образ по 100Gbit линкам, ребутает первый IOM, ждет поднятия и повторяет процедуру для второго. Когда консоль отвисла, алерт ушел, а система перешла в кристально чистый статус Health: OK.

    Мораль (Высечь в камне)

    1. Не верь порталам. Если нужной версии софта нет, это не значит, что подойдет последняя.
    2. Отключай VPN. Если сеть ведет себя странно при доступе к management-портам — в 9 случаях из 10 виноват AnyConnect или любой другой всратый клиент VPN, заворачивающий локальный трафик.
    3. Физика бессердечна. Какой бы крутой ни была архитектура, микровибрация на контакте DIMM-модуля положит энтерпрайзный кластер в самый ответственный момент.
    4. Слот решает всё. Backend NVMe HBA ставятся строго во 2-й слот. 4-й слот — только под сеть и iSCSI, да и просто – повнимательнее что ли читать мануалы надо-бы.
    5. Cabling Tool — закон. Кроссируйте порты строго по асимметричной схеме, иначе получите degraded и зависший UI или по той схеме который предложит сам Cabling Tool.
    6. Знание CLI спасает. Когда красивые дашборды ложатся по тайм-ауту, только хардкорные команды вроде upgradesys вытащат массив из комы. Только консоль! Только хардкор! GUI для самокатчиков!.

    Апгрейд завершен. Пойду посплю.

  • Как автоматизировать Cisco AnyConnect и забыть про ручное переключение VPN

    Проблема: рутина при смене сетей

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

    Хотелось получить простое решение: чтобы ноут сам понимал, где он сейчас находится — внутри доверенной корпоративной сети (где VPN не нужен) или снаружи, и автоматически поднимал туннель без моего участия.

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

    Правильнее ловить ивенты самой операционной системы. Когда Windows успешно подключается к любой сети (неважно, Wi-Fi это или патч-корд), служба NetworkProfile генерирует в системном журнале событие с ID 10000. Мы просто вешаем запуск нашего PowerShell-скрипта на этот триггер через Task Scheduler. В итоге скрипт спит и «дергается» только в момент реальной смены сети.

    Как общаться с vpncli.exe У AnyConnect есть консольная утилита vpncli.exe. Сложность в том, что она интерактивная. При попытке подключения она начинает сыпать вопросами в консоль: просит подтвердить недоверенный сертификат, выбрать группу доступа, ввести логин и пароль.

    Чтобы автоматизировать это, мы формируем в скрипте одну строку со всеми ответами по порядку, разделяя их переносом строки (символ `n). Затем просто скармливаем эту матрицу ответов утилите через конвейер, используя ключ -s для чтения стандартного ввода.

    Безопасность: как не засветить пароль Хранить пароль от VPN в открытом текстовом файле или внутри самого скрипта нельзя. Заюзаем встроенный механизм Windows — DPAPI.

    Мы один раз вводим пароль руками, скрипт превращает его в SecureString и сохраняет в файл. Фишка в том, что винда шифрует эту строку ключом вашей текущей учетной записи. Этот файл физически невозможно расшифровать, если скопировать его на другой комп или попытаться прочитать из-под другого пользователя. Основной скрипт будет на лету читать этот файл, расшифровывать пароль в оперативную память на долю секунды, передавать в AnyConnect и тут же затирать переменные. Само собой это тоже не супер защищенный момент но щито поделать-десу.

    Пошаговая настройка и финальный скрипт

    Шаг 1. Создаем файл с зашифрованным паролем Откройте PowerShell (с теми правами, под которыми вы работаете) и выполните эту команду. Она запросит пароль и сложит зашифрованный хеш в текстовик:

    Тык
    $cred = Read-Host -Prompt "Введите пароль от VPN" -AsSecureString
$cred | ConvertFrom-SecureString | Set-Content -Path "C:\Scripts\vpn_pass.txt" -Force

    Шаг 2. Основной скрипт Создаём файл C:\Scripts\AutoVPN.ps1 и контрол-вэшним в него этот код. Главное не забыть вписать свои названия банковских сетей в массив $bankNetworks что бы исключить их их этого цирка.

    Тык
    
# Массив имен доверенных сетей (SSID или домены)
$bankNetworks = @("Bank_WiFi_1", "Bank_WiFi_2", "Corp_LAN_Domain") 

$vpncli = "C:\Program Files (x86)\Cisco\Cisco AnyConnect Secure Mobility Client\vpncli.exe"
$vpnProfile = "11.22.33.44:1234"
$username = "username"
$encryptedPassPath = "C:\Scripts\vpn_pass.txt"

$currentNetworks = Get-NetConnectionProfile | Select-Object -ExpandProperty Name

$isBankNetwork = $false
foreach ($net in $currentNetworks) {
    if ($bankNetworks -contains $net) {
        $isBankNetwork = $true
        break
    }
}

# Если активно подключение к одной из сетей банка - прерываем выполнение
if ($isBankNetwork) {
    Exit
}


$vpnState = & $vpncli state

# Если туннель уже поднят - прерываем выполнение (защита от зацикливания)
if ($vpnState -match "state: Connected") {
    Exit
}

# Читаем файл как единую строку и отсекаем возможные невидимые символы
$encryptedString = (Get-Content $encryptedPassPath -Raw).Trim()

$secureString = ConvertTo-SecureString $encryptedString
$bstr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($secureString)
$plainPassword = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($bstr)
[System.Runtime.InteropServices.Marshal]::ZeroFreeBSTR($bstr) # Очистка памяти BSTR

$vpnInput = "y`n1`n$username`n$plainPassword"

# Передача матрицы в стандартный ввод vpncli
$vpnInput | & $vpncli -s connect $vpnProfile

$plainPassword = $null
$vpnInput = $null

    Шаг 3. Настройка Планировщика задач (Task Scheduler)

    Ну, тут все по классике, единственное что посоветую, делать delay на секунд 15 на случай если получение IP от маршрутизатора затянется.

    В целом полезно. Спасибо за внимание!

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

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

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

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

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

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

    В третьих навык прохождения интервью — это тоже навык
    Собеседование — это стресс. Если ходить на них раз в 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 в айтишке.

    Проведение 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-а мы обречены наступать на одни и те же грабли. С ним — каждый сбой делает вашу инфраструктуру надежнее. Ведь что нас не убивает, делает нас нервознее сильнее!