https://lolz.team/threads/1630419 и https://lolz.team/threads/1637822
проверяю, отписывая людям, ибо автор давно неактивен. Если будут результаты — сообщу.

2. Не знаете, существуют ли какие-нибудь стримы или записи на Creative LiteCloud/LastCraft? Я, конечно, нашёл несколько, но на них не то чтобы много игроков видно. Малоизвестные группы по LiteCloud:
https://vk.ru/opglix
https://vk.ru/pilesosrelogia
https://vk.ru/screenshots_in_minecraft
https://vk.ru/public145242472
https://vk.ru/qlitecloud
Жаль, что наша конфа в Discord, называющаяся вроде как LiteCloud Immortal была утеряна.

По LastCraft:
https://vk.ru/goldcompetition
https://vk.ru/olyxrp (и даже есть такое https://lastcraft.fandom.com/ru/wiki/NewRP)

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

3. Никто не знает, можно ли узнать администраторов/модераторов группы Скрины В Майнкрафт? Спрашивал людей, оставивших комментарии — это пока не дало результата.
https://vk.ru/screenshots_in_minecraft

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

Был расшифрован Z340 – один из четырёх известных шифров Зодиака, орудовавшего в конце шестидесятых годов.

С задачей справились три программиста-энтузиаста из разных стран:

• Дэвид Оранчак из США;

• Сэм Блейк из Австралии;

• Ярл Ван Эйке из Бельгии.

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

Оригинальный шифр Z340

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

До этого был расшифрован только Z408 – первое большое криптографическое послание Зодиака. Его разгадали ещё в 1969 году. В нём автор сообщал, что любит убивать людей, потому что это весело.

Мысль достаточно простая. Для её передачи потребовалось более четырёхсот символов и полвека внимания к личности автора.

Оставшиеся шифры продолжали сопротивляться анализу.

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

О расшифровке Z340 я узнал почти сразу.

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

Новость меня невероятно вдохновила.

Я подумал:

Смогли они – смогу и я.

На тот момент я только поступил в университет и учился на первом курсе направления «Информатика и вычислительная техника» в филиале МГТУ имени Баумана.

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

Возможно, самого важного из оставшихся.

Шифр Z13

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

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

Проблема заключалась именно в длине шифра.

Для сравнения: в Z340 было триста сорок символов.

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

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

Имя может быть настоящим или вымышленным, полным или сокращённым. Оно может содержать ошибку, псевдоним или дополнительный знак. Кроме того, Зодиак мог солгать.

Это предположение не требовало особенно смелой научной гипотезы.

Поэтому главная сложность состояла не в том, чтобы получить варианты расшифровки. Главная сложность – понять, что среди них есть правильный.

Я осознавал это с самого начала.

Но решил двигаться от малого: реализовать несколько возможных алгоритмов, выделить подходящие варианты и постепенно сокращать пространство поиска.

Научный проект

Весной 2021 года в университете проходила ежегодная научная конференция.

Я решил, что дешифратор Z13 станет отличной темой для проекта, пришёл на кафедру и записался.

Тема быстро стала известна среди моих однокурсников. Люди подходили, задавали вопросы, интересовались историей Зодиака и тем, каким образом я собираюсь анализировать шифр.

Я с энтузиазмом рассказывал о задумке, алгоритмах и перспективах проекта.

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

Первая программа

Для проекта я разработал две программы.

Первая выполняла полный перебор возможных вариантов расшифровки латинского текста.

Теоретически она гарантированно должна была обнаружить правильную последовательность – при условии, что эта последовательность вообще находилась внутри выбранного пространства поиска.

Проблема была лишь в количестве вариантов.

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

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

Технически это была конструкция с многократной вложенностью циклов.

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

Код первой программы

База имён и фамилий

Вторая программа была более практичной.

Она работала с базами реальных имён и фамилий.

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

Имена и фамилии хранились отдельно.

Это позволяло проверять разные комбинации:

• имя;

• фамилию;

• имя и фамилию вместе;

• сокращённые варианты;

• перестановки;

• преобразования каждой части по отдельности.

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

Значительную часть информации приходилось искать, проверять, приводить к единому формату и вручную добавлять в локальную базу.

Я не просто написал алгоритм. Я своими силами формировал данные, на которых он должен был работать.

Фрагмент локальной базы имён и фамилий

Первым делом я проверял сравнительно простые варианты:

• прямую подстановку;

• шифр Цезаря с различными смещениями;

• перестановки символов;

• несколько вариантов преобразования алфавита;

• комбинации имён и фамилий;

• сопоставление структуры повторяющихся знаков.

Постепенно я объединил несколько алгоритмов в одной программе. Она брала записи из базы, преобразовывала их разными способами и сравнивала получившиеся последовательности со структурой Z13.

Совпадений я не получил.

Ни одного.

Ни по одному из реализованных алгоритмов.

Это не было расшифровкой, но тоже представляло собой результат.

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

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

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

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

В дальнейшем я планировал приобрести более крупную официальную базу имён и фамилий. Она позволила бы расширить поиск и перейти от самостоятельно собранной выборки к более серьёзному массиву данных.

Для этого требовалась поддержка университета.

Выступление на конференции

Весной на научной конференции я подробно представил свою работу.

Рассказал об истории шифров Зодиака, принципах шифрования, расшифровке Z340 и особенностях Z13.

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

Показал обе программы:

• полный перебор;

• систему анализа реальных имён и фамилий.

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

У меня не было готовой расшифровки.

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

То есть исследовательская работа.

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

Мой научный руководитель – заведующий кафедрой и одновременно один из членов жюри – посмотрел на меня с некоторым сожалением.

Результаты конференции ещё не объявили, но мне уже начали объяснять, что я учусь только на первом курсе, что впереди будет много других проектов и что расстраиваться не следует.

Обычно человека утешают после объявления результатов.

Меня это несколько озадачило.

Научная объективность

Первые три места заняли проекты, связанные с разработкой типовых телеметрических приборов.

Темы этих проектов студентам рекомендовали преподаватели кафедры. Сами приборы были нужны кафедре.

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

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

Наука иногда удивляет совпадениями.

Победившие работы опубликовали в университетском журнале. Кафедра получила необходимые ей разработки, студенты получили места, а система – ожидаемый результат.

Но не расшифровал же

Во время объявления результатов заведующий кафедрой снова отдельно упомянул мой проект.

И произнёс фразу, которую я запомнил навсегда:

Да, ты пытаешься расшифровать шифр. Но не расшифровал же.

Тогда я подумал:

Вот так да. Если бы я уже расшифровал имя Зодиака, вероятно, представлял бы результат в Гарварде.

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

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

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

Возможно.

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

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

Просто у их проектов был более прямой маршрут к результату.

Так закончилась моя история про 18 карат невезения.

Что было дальше

Свою идею я не бросил.

Я лишь отложил её и позднее периодически возвращался к проекту по мере развития искусственного интеллекта и появления новых методов обработки данных.

Технологии постепенно давали возможности, которых у меня не было весной 2021 года.

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

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

Я понял, что научная среда не всегда продвигает неизвестное. Неизвестность неудобна: она не гарантирует готового устройства, публикации и результата к установленной дате.

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

Именно поэтому она является исследовательской задачей.

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

С Зодиаком всё было проще.

Он хотя бы не притворялся, что играет честно.

---

К Z13 я ещё вернусь – уже с современными моделями, более крупными базами и методами, которых у меня не было в 2021 году.

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

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

Для СУБД важна не максимальная скорость в коротком тесте, а стабильный отклик диска под рабочей нагрузкой. Требования к I/O зависят от профиля: OLTP, аналитика и смешанные нагрузки по-разному используют чтение, запись, WAL, временные файлы и кэш. VDS для баз данных оценивают по стабильному IOPS, p99-задержке и поведению под длительной нагрузкой, а не по лучшей цифре из прайса.

Почему БД чувствительны к стабильности I/O

PostgreSQL пишет WAL, MySQL – redo log и, если включён, binlog. При скачках задержки fsync с 2 до 80 мс транзакции могут ждать диск, а очередь запросов расти даже при нормальной средней скорости. io_wait сам по себе не всегда означает проблему: его нужно смотреть вместе с latency диска, p95/p99 и временем ответа запросов.

Пиковая скорость vs устойчивый IOPS

На VDS с burst-профилем короткий тест может показать высокий результат, но через несколько минут упереться в лимит хоста или нагрузку соседних VM. Для OLTP важнее, чтобы 5 000 IOPS держались ровно 10–15 минут, чем разовый пик в 50 000 IOPS на старте теста.

Метрики, на которые смотреть

Смотрите не только среднюю задержку, а p95/p99, джиттер и самые медленные операции записи. Оценивать график лучше относительно SLO конкретной СУБД и приложения: p99-задержка, время ответа запросов и io_wait не должны регулярно выходить за допустимые для проекта значения при одинаковой нагрузке.

Как проверить VDS перед миграцией БД

Перед переносом запустите fio со случайным чтением и записью блоками 4K минимум на 10 минут и отдельно проверьте СУБД через pgbench или другой нагрузочный тест. fio помогает оценить диск, но не полностью повторяет поведение PostgreSQL или MySQL: важны WAL, fsync, cache hit ratio и размер рабочего набора данных. Размер тестового файла должен быть больше объёма памяти, который может использоваться под page cache, иначе результат может попасть в кэш и показать нереалистично высокую скорость. Тестируйте VDS-сервер в то же время суток, когда у проекта обычно пиковая нагрузка.

Что замерить до переноса продакшена

•  Стабильный IOPS на длительном fio-тесте

•  p99-задержка чтения и записи

•  p99-задержка fsync при типичной нагрузке вашей СУБД

•  io_wait во время pgbench или тестовой нагрузки

•  Наличие резервирования дисков, RAID-схему и поведение платформы при сбое накопителя

•  Доступный объём RAM, использование page cache и активность swap под нагрузкой

•  Поведение диска после 10–15 минут непрерывной нагрузки

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

На контейнерной схеме CPU и I/O могут делиться между всеми на хосте, а степень изоляции зависит от настроек хоста, лимитов и политики провайдера. Современные контейнерные решения могут нормально работать под нагрузкой, если ресурсы распределены корректно. Если сосед по железу активно загружает физические ядра или диск, ваш контейнер может тормозить, а без доступа к хостовой стороне причину сложнее подтвердить.

Например, два тарифа могут иметь одинаковые характеристики: 4 vCPU и 8 ГБ RAM. Один сервер будет работать стабильно под нагрузкой благодаря корректным лимитам ресурсов и контролю плотности размещения VM, а другой может показывать просадки из-за высокой конкуренции за ресурсы на хосте.

CPU steal time (%st в top и vmstat) показывает, сколько времени виртуальный процессор ждал, пока гипервизор выделит ему физическое ядро. Проще говоря, это время, когда VPS хотел получить CPU, но физический ресурс был занят другими задачами на хосте. При нормальной конфигурации хоста показатель держится близко к нулю. fio и vmstat позволяют увидеть симптомы деградации (рост latency, steal time), но не позволяют однозначно подтвердить оверселлинг.

Сценарии, где разница решает

• PostgreSQL и MySQL под нагрузкой: нужна I/O-предсказуемость и стабильный RAM.

• Low-latency API: скачки задержки в правильно написанном сервисе могут быть связаны с CPU steal, I/O или нагрузкой на сеть, а не только с кодом.

• CI/CD-раннеры и k8s-ноды: всплески нагрузки у соседей не должны валить ваши сборки и поды.

Чек-лист: как проверить изоляцию у провайдера

• Тип виртуализации: KVM/Xen или OpenVZ/LXC?

•  vCPU гарантированы или мягкий лимит с троттлингом?

• Есть ли гарантии IOPS или диск работает в shared-режиме без ограничений?

• Публикует ли провайдер политику оверселлинга?

• Можно ли измерить steal time через vmstat или встроенный мониторинг?

Перед выбором тарифа пройдитесь по этому чек-листу. Маркировка «VDS» на сайте провайдера не гарантирует аппаратной изоляции, посмотрите тип гипервизора отдельно.

У двух провайдеров могут быть одинаковые характеристики: 4 vCPU, 8 GB RAM, 100 GB SSD, гигабитный канал. При этом цена отличается на 15%, и разница неочевидна. Но через неделю нагрузочных тестов выясняется: p99-задержки у серверов расходятся в разы.

Облачный сервер с «бумажными» характеристиками это то, что провайдер выделил виртуально. Что происходит в железе, остаётся отдельным вопросом. Когда сосед по гипервизору кладёт что-то тяжёлое, дисковая очередь растёт или канал режут по полосе, ничего из этого в спецификации тарифа нет.

Чтобы не обнаружить проблему уже в продакшене, стоит прогнать три блока тестов до миграции: CPU steal, дисковая подсистема и сеть. Инструменты стандартные: vmstat, fio, iperf3. Интерпретировать результаты нужно в контексте нагрузки, тарифа и времени измерения.

Почему синтетических бенчмарков недостаточно

Geekbench, sysbench, UnixBench замеряют потолок: максимум, который сервер может показать в коротком тесте. Продакшен так не работает. Нагрузка нестабильна, а соседи по физическому узлу непредсказуемы.

В облаке ресурсы виртуальные, и провайдеры применяют оверкоммит: виртуальных ядер на узле выделяется больше, чем можно гарантировать физически при одновременной нагрузке. Пока суммарная нагрузка умеренная – всё в порядке. Когда несколько VM одновременно дают всплески, растёт steal time и дисковая очередь, сеть упирается в лимиты или шейпинг. Это и есть эффект «шумных соседей». Он проявляется непредсказуемо, потому что зависит от того, кто ещё размещён на вашей физической ноде прямо сейчас.

Короткие синтетические тесты не всегда это показывают: они выполняются на общей ноде, но могут не попасть в периоды конкуренции с другими VM за ресурсы. Реальное тестирование облачного сервера должно включать не только короткие синтетические тесты, но и наблюдение за поведением системы в динамике. Для первичной проверки обычно достаточно 30–60 минут нагрузки, а более длительный мониторинг в течение 24–72 часов помогает выявить периодические проблемы с конкуренцией за ресурсы.

Три вещи остаются за кадром при коротком синтетическом тесте. Первое – эффект соседей: ваша VM не одна на физической машине. Второе – нелинейность дисков: SSD ведёт себя по-разному при чистом чтении, чистой записи и их смеси. Третье – временные эффекты сети: burst-лимиты, суточные паттерны шейпинга, перестройка BGP-маршрутов при переключении аплинков.

CPU steal: как увидеть ожидание CPU на гипервизоре

CPU steal time – это процент времени, когда ваш vCPU готов к работе, но гипервизор не предоставляет ему физическое ядро. Причиной может быть высокая загрузка хоста, конкуренция с другими VM, особенности планировщика или условия конкретного тарифа. Для приложения это будет дополнительной задержкой без видимой причины – процессор загружен, а работу не выполняет.

Следить за CPU steal time удобнее всего в реальном времени. В выводе vmstat правая группа колонок – блок cpu: us – user, sy – system, id – idle, wa – ожидание диска, st – steal. Если st держится выше нуля несколько строк подряд, нужно смотреть динамику, а не разовый всплеск:

Статистику за длинный период удобно собирать через sar. Запускать стоит дважды: в покое и под нагрузкой. Разница между срезами покажет, как ведёт себя steal при конкуренции:

Можно посмотреть показатели по каждому vCPU отдельно, чтобы убедиться, нет ли концентрации steal на отдельных vCPU. Такая картина может указывать на особенности планирования или размещения VM:

Если вы используете Prometheus, node_exporter экспортирует node_cpu_seconds_total с меткой mode="steal". Так удобно смотреть изменение steal во времени, а не отдельные срезы в терминале.

Практические ориентиры по значениям steal:

Как интерпретировать steal в разных сценариях

Для CPU-bound задач (транскодирования, ML-инференса, компиляции) steal транслируется напрямую во время выполнения. Steal 5% может означать близкую по масштабу потерю доступного CPU-времени, а также нерегулярные паузы от гипервизора, которые нарушают предсказуемость.

Для latency-sensitive API – REST, gRPC, запросов к базам данных – зависимость нелинейная. Медиана может держаться в норме, а p99 растёт: в моменты роста steal запросы накапливаются в очереди. Производительность облачного сервера при steal выше 3–5% для таких сервисов стоит проверять под реальной нагрузкой, синтетический тест этого поведения не показывает.

Отдельный случай – кратковременные всплески steal до 15–20% на несколько секунд при нормальных фоновых показателях. Так бывает при «пробуждении» нагруженной VM на соседнем слоте. Для realtime-сервисов такие пики особенно опасны: даже 3-секундный скачок latency может спровоцировать каскадные таймауты ниже по стеку.

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

Сравните значения st в разные промежутки. При устойчивом росте в пиковые часы стоит обратиться в поддержку и проверить, связана ли проблема с конкретной нодой, тарифом или инфраструктурой провайдера.

Диск: IOPS, latency и поведение под смешанной нагрузкой

нагрузкой

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

В выводе iostat важны два параметра. await – среднее время выполнения запроса к диску в миллисекундах, включая ожидание в очереди. avgqu-sz – средняя глубина очереди: когда она растёт, await растёт следом. В новых версиях sysstat await разделён на r_await и w_await – лучше смотреть оба.

Мониторинг дисковой подсистемы запускайте параллельно с нагрузочным тестом:

Для нагрузочного теста используется fio. Крайне важен флаг --direct=1: без него тест уходит в страничный кеш Linux и не отражает поведение диска. Параметры numjobs и iodepth задают глубину очереди: в примере с numjobs=4 и iodepth=32 суммарная глубина очереди равна 128, что перекрывает большинство всплесков при конкуренции потоков. В выводе смотрите на iops и clat p99: этот показатель помогает оценить вклад диска в хвостовые задержки запросов. В примерах ниже используется ioengine=libaio, но для современных Linux-конфигураций также можно рассматривать io_uring, если он поддерживается системой и версией fio.

Случайное чтение 4K – типичная OLTP-нагрузка:

Последовательная запись 1 MB – журналы, бэкапы, дамп БД:

Смешанная нагрузка 70/30 – реалистичная модель для большинства веб-приложений:

Ориентиры для БД и веб-приложений

Нет единого числа IOPS, которое подходит всем: зависит от характера нагрузки, размера рабочего набора и активности кеша. Примерные ориентиры для тестирования облачного сервера под разные типы нагрузок:

• PostgreSQL / MySQL, средняя — 4K rand IOPS: ≥5 000; await: <2 мс; %util: <70%

• PostgreSQL / MySQL, высокая — 4K rand IOPS: ≥20 000; await: <1 мс; %util: <70%

• Redis (с AOF) — 4K rand IOPS: ≥10 000; await: <1 мс; %util: <60%

• Nginx / файловый сервис — 4K rand IOPS: ≥1 000; await: <5 мс; %util: <80%

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

Если avgqu-sz устойчиво держится выше 8–10 под OLTP-нагрузкой, это первый признак насыщения: запросы встают в очередь, потому что диск не успевает. %util близко к 100% само по себе не катастрофа для SSD, но если при этом растёт await – диск работает на пределе.

Для облачных блочных устройств с гарантированными IOPS пороги обычно срабатывают раньше, чем %util достигнет 100%: провайдер режет I/O на установленном лимите, и очередь начинает расти задолго до насыщения железа. Именно await покажет это первым.

Тестировать стоит с той же глубиной очереди, что предполагается в продакшене: для PostgreSQL это обычно 8–32, для Redis – ниже.

Сеть: полоса, PPS, latency и потери

Настройка облачных серверов под продакшен без проверки сети – частая ошибка. Заявленный гигабит или 10 Gbps – это верхний предел, а не гарантированная полоса. Под длительной нагрузкой провайдеры нередко применяют шейпинг или rate limiting, и в документации это обычно не указано.

Базовый тест полосы между двумя нодами в одном датацентре (нужен iperf3-сервер на второй машине):

В строке receiver смотреть на Bandwidth. Ключ -P 4 запускает 4 параллельных TCP-потока – один поток не всегда показывает реальный потолок канала: результат зависит от RTT, настроек TCP и доступного размера окна передачи. Параметр -t 60 задаёт длительность 60 секунд – этого достаточно, чтобы обнаружить burst-лимиты, если они есть.

UDP-тест для оценки потерь и jitter под заданной скоростью:

Latency и jitter:

Параметры виртуального интерфейса – если драйвер отдаёт данные (имя может отличаться: eth0, ens3 и т.п.):

В выводе mtr обращайте внимание на колонки Loss% и Last. Потери только на одном промежуточном хопе при нормальном трафике дальше – скорее всего, роутер деприоритизирует ICMP TTL-exceeded. Устойчивые потери на нескольких хопах подряд – другое дело.

Примерные ориентиры для внутрисетевого трафика в одном датацентре: RTT < 1 мс, потери = 0%, jitter < 0.5 мс. Реальные значения зависят от сети провайдера, маршрута и требований приложения. Устойчивые потери до конечного узла могут стать поводом разбираться.

Частые проблемы сети в облаке

Rate limiting и шейпинг. Если iperf3 даёт полную полосу первые 10–15 секунд, а затем резко снижает результат – провайдер применяет burst-лимиты. Реальная устойчивая полоса в таком случае ниже заявленной, и это нужно учитывать при выборе тарифа.

MTU в overlay-сетях. VXLAN и Geneve добавляют заголовок к каждому пакету, снижая эффективный MTU ниже стандартных 1500 байт – обычно до 1450. Пакеты с DF-флагом при этом дропаются без уведомления приложения.

Проверка MTU для IPv4 при стандартном MTU 1500:

Ответ «Frag needed» или «Message too long» означает, что пакет такого размера не проходит без фрагментации. Для IPv6, туннелей и нестандартных MTU значения будут другими. Нужно снижать TCP MSS или настраивать PMTUD на стороне приложения, иначе соединения будут зависать или деградировать непредсказуемо.

Нестабильный роутинг. Если mtr показывает устойчивые потери до конечного узла или аномальный рост RTT по маршруту – запустите повторно через 5–10 минут. Если ситуация не меняется – возможны BGP-флап, перегрузка маршрута или внутренний сбой у провайдера. В таком случае настройка облачных серверов внутри одного VPC не поможет – проблема на уровне сети провайдера или внешних аплинков.

Чек-лист проверки облачного сервера перед production

Последовательность шагов для оценки нового сервера перед миграцией:

1. Базовый срез в покое. Сразу после деплоя, до всякой нагрузки: vmstat 1 60, iostat -xz 1 60, ping к соседней машине в той же зоне. Запишите исходные значения st, await, avgqu-sz – это точка отсчёта для сравнения.

2. CPU steal под нагрузкой. Создайте реальную или приближенную к продакшену нагрузку (например, через stress-ng или аналог), параллельно мониторя vmstat 1. Сам по себе синтетический тест не гарантирует конкуренцию ресурсов на стороне гипервизора, поэтому важна динамика steal под фактической нагрузкой. Steal выше 3–5% под умеренной нагрузкой – повод проверить динамику, сопоставить её с p95/p99 и обратиться в поддержку. Причина может быть в ноде, тарифе или инфраструктуре провайдера.

3. Дисковый тест. fio с профилем нагрузки, близким к продакшену: 4K randread для OLTP, 1 MB sequential write для стриминга. Зафиксировать IOPS, await, avgqu-sz. В соседнем терминале – iostat -xz 1.

4. Сетевой тест. iperf3 минимум 60 секунд, ping с 1000 пакетами, mtr до ключевых endpoint’ов. Отдельно – проверка MTU: для стандартного MTU 1500 в IPv4 с ICMP можно использовать ping -M do -s 1472. Для IPv6, туннелей и нестандартных MTU значения будут другими.

5. Мониторинг 24–72 часа. Вывод в продакшен без наблюдения за суточным паттерном – ещё одна частая ошибка. sar с записью в файл или любой агент метрик (node_exporter, collectd) покажут поведение steal и await в разное время суток и помогут поймать пиковую конкуренцию на ноде.

6. Анализ p95/p99. Если есть возможность запустить реальное приложение или нагрузочную копию – собрать гистограмму latency за несколько часов. p95 и p99 в контексте всей системы точнее любого синтетического теста и позволяют напрямую сверить результат с SLO.

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

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