Сервер числится сразу за несколькими отделами. Каждый уверен, что у него всё в порядке. А когда железка ломается, выясняется, что она ничья. Опросили сотню компаний — картина одинаковая. Показываем, что с этим делать.
Это вторая статья цикла. В первой части мы разбирали, как начать FinOps с точки ноль: посадить финансы и инженеров за один стол, договориться об общей картине затрат и собрать первые данные для прозрачности. Теперь переходим к следующему шагу: пилоту, ручной разметке ресурсов, поиску оптимизационного потенциала и правилам, которые не дают экономии расползтись обратно.
Хочу рассказать вам историю об одной хронической проблеме у каждого хостинга.
Заходит к вам пользователь, создаёт сервер. И дальше 10 секунд его держит, потом отпускает и создаёт новый сервер. И так тысячи раз. Делается это ради одной-единственной цели: при пересоздании сервера выдаётся новый IPv4-адрес.
Задача этих людей — найти в нашем пуле тот самый адрес, который их устраивает. Красивость адреса определяется по тому, где, кем и как он блокируется. Например, с какого-то в 1998 году рассылали спам, и письма с него доходят чуть хуже. С какого-то парсили Нетфликс или Пикабу, и они в чёрных списках этих ресурсов (им показывают бесконечную капчу). Кто-то болезненно засветился в Cloudflare, кто-то заблокирован в конкретном островном государстве за отзыв на местную кафешку и так далее.
Интернет настолько старый и настолько фрагментированный, что почти не осталось IPv4-адресов без истории. А учитывая, что у них ещё есть и прошлая известная геопринадлежность, международные санкции и блокировки могут быть очень запутанными.
Мы, разумеется, очищаем все свои IPv4 при закупке (а покупаем мы оптом, сразу подсетями), но мы уведомляем только основные базы вроде Спамхауса. А известных баз сотни и тысячи, и ещё есть блокировки конкретных сайтов, госструктур и плавающие показатели репутации айпишника и т. п.
Так вот, есть люди, которые перебирают адреса. Казалось бы, проблемы нет: при посекундной тарификации сколько потребил, столько и заплатил. Но они блокируют эти адреса для нормальных клиентов хостинга и потом их ещё и портят.
Бороться с этим было сложно, и 3 года мы это откладывали как могли.
Архитектура — это не список функций. Это набор инженерных решений, которые определяют, где система выиграет, где проиграет и почему.
Большинство распределенных хранилищ при заполнении примерно на 95% начинают работать в 2-3 раза медленнее. В наших тестах производительность упала всего на 4–9%. Причина в архитектуре MIND uStor. В этой статье разберем, как устроена модель хранения данных, как организован ввод-вывод и за счет чего система сохраняет производительность даже при высокой утилизации дискового пространства.
В первой статье мы рассмотрели типичные проблемы программно-определяемых хранилищ (SDS): падение производительности по мере заполнения, дополнительные затраты на отказоустойчивость и сложность эксплуатации. Эти ограничения характерны для большинства систем такого класса, поэтому при разработке uStor нам пришлось искать баланс между производительностью, надежностью, эффективностью использования дискового пространства и сложностью реализации.
Здесь разберем, как устроено размещение данных, каким образом кластер сохраняет производительность при заполнении свыше 90%, как работают RF- и EC-пулы, а также почему iSCSI-таргет реализован в пространстве пользователя. Отдельно остановимся на компромиссах, которых потребовала реализация этих решений.
Мы в mClouds продолжаем серию тестов производительности 1С:Предприятие на разных аппаратных платформах. Ранее мы тестировали высокочастотные AMD EPYC 9374F и они показал отличные результаты . Затем тестировали одну и ту же платформу на трех ОС: Ubuntu, Windows и AlmaLinux — и увидели заметную разницу в производительности уже внутри ОС.
Теперь у нас новый объект для изучения: серверы на базе AMD EPYC 9555 — 64-х ядерного процессора архитектуры Zen 5 с высокой тактовой частотой до 4,2 ГГц. Мы провели серию синтетических тестов: тест Гилёва, Fragster и HammerDB. В этой статье покажем цифры и выводы по новому процессору.
Высокий приоритет пода в Kubernetes должен повышать устойчивость сервиса, но при ошибочной настройке ресурсов может запустить противоположный сценарий: вытеснения, каскадные перезапуски и бесконтрольное масштабирование кластера.
Разберём, как возникает инверсия приоритетов, почему PriorityClass не гарантирует защиту и какие настройки помогают удержать критичные нагрузки под контролем.
В учёте три ноутбука, и все записаны по-разному: «леново», «Lenovo Inc.», «ThinkPad». Для отчёта это три разные железки, а по деньгам — разброс в сотни тысяч на балансе. Показываем, как навести порядок в справочниках, чтобы наконец знать, чем ты вообще владеешь.
Стандартным методом установки софта в Linux сегодня является использование бинарных пакетов. В некоторых средах используются готовые образы контейнеров. Однако, умение собирать Angie из исходных кодов открывает широкие дополнительные возможности. Погрузимся в этот непростой процесс и обсудим, зачем может пригодиться сборка из исходников.
Если демо и обучение проходят регулярно, рано или поздно все начинает упираться в стенды. Их почти всегда просят «как можно быстрее», но на практике подготовка легко растягивается из-за ручных действий, разъехавшихся конфигураций и зависимости от конкретного специалиста.
В WMS (Workshop Management System) мы как раз убирали это трение и выстраивали процесс так, чтобы стенд Astra Automation запускался быстро, предсказуемо и без лишней суеты. В итоге получился понятный сценарий: около 10–15 минут на запуск, после чего система уже сама доводит жизненный цикл стенда до завершения.
Пишу свой путь разработки self-hosted сервера с полностью автоматизированным развертыванием с полным циклом состоящим из около 15 DevOps технологий, а также 7 сервисов, которые будут полезны каждому!
Всё началось с того, что меня перестал устраивать мой подход к развертыванию личных сервисов. Я решил переписать всё с нуля. К тому же это был отличный повод получить новые навыки и попробовать инструменты, до которых давно не доходили руки.
Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.
Пайплайны редко тормозят из‑за одной большой проблемы — чаще минуты незаметно съедают неработающий кэш, тяжёлые образы, очереди и лишние зависимости между джобами.
Разберём шесть типичных ошибок в настройке GitLab Runner и посмотрим, как найти узкое место до того, как команда привыкнет ждать сборку по двадцать минут.
Remedy у вас работает, но вендор ушёл: ни патчей, ни поддержки, ни людей, кто в этом разберётся. Разбираем, как переезжать — тащить старый кастом с собой или начинать заново.
В этой статье мы вспомним, почему Vista была не такая плохая как кажется, разберём её сервис-паки, историю и какие глобальные изменения ввела имено Vista
У обычной ноды Kubernetes жёсткий потолок в 110 подов (формально настраиваемый kubelet-флаг --max-pods, но поднимать его руками не рекомендуется даже апстримом: упирается в размер Pod CIDR на ноду, и выше 110 Kubernetes просто не валидируют, так что на практике это потолок дефакто), плюс налог на каждый контейнер: containerd или CRI-O (справедливости ради, у CRI-O ~20 МБ, но на хост, и около 1 МБ на под), ~20 МБ containerd-shim на каждый контейнер, а сам CRI добавляет заметный delay в операциях. На мощном железе это заставляет выбирать между недоутилизацией и гипервизорным слоем (KubeVirt, Kata) с его собственным налогом на microVM. На слабых VPS стандартный стек тяжёл ещё даже до первого workload: kubelet + containerd + kube-proxy + CNI — это уже 300-600+ МБ RSS прежде, чем в кластере появится хоть один рабочий под.
У меня была мечта: Kubernetes + systemd. Я начал свой путь не зная куда это приведет, проект за время разработки сменил 7 разных направлений, думаю я нашел главную цель: освобождение Kubernetes.
Результат на двух моих машинах (Xeon E5-2690 v4 + Intel N150): 1772 пода, 33 ноды, 2.5 миллиона запросов под нагрузкой с нулём ошибок и медианой 257 мкс. RSS демона — 365 МБ (замер от 04.04.26, сейчас уже ниже) на 1660 подов (~225 КБ на под).
Дальше расскажу, что такое Periapsis, как у меня появилась эта идея и что уже работает.
Год назад я уже делал обзор на девайс TerraMaster F8 Pro, если интересно то эта статья есть в моем профиле. Это довольно необычный NAS, полностью построенный вокруг NVMe-накопителей. Устройство получилось действительно быстрым, но после публикации обзора многие читатели задали вполне закономерный вопрос:
«СХД для ИИ» - маркетинг. На деле у склада три потребителя с конфликтующими требованиями: обучение (полоса и p99 потока), инференс/RAG (хвосты латентности) и чекпоинты (burst-запись). На примере реальной HA-пары NVMe-oF/TCP и арифметики тракта данных ответим на главный вопрос.
Почему RDMA и Gen5 часто не дают эффекта?
Где микросекунды протокола реально съедают SLA?
В каком порядке апгрейдить: сначала ворота фронта, потом плазму, и только потом реликвии бэкенда?
Стройку видно не по чертежам, а по бетону. У энергоцентра в Марфино появилось то, с чего начинается любая стройка, — фундамент.
Я использую Supabase в self-hosted режиме: сервисы работают в Docker Compose, включая Postgres, Kong, GoTrue, PostgREST, Storage, Realtime, Edge Functions, Logflare и Vector. Перед Kong стоит Nginx, который завершает TLS и проксирует публичное API.
Мне нужно было закрыть две задачи
В предыдущих статьях мы разобрались, c Linux и Bash.
Следующая ступенька — Git.
На первый взгляд может показаться, что Git нужен только программистам. Ведь именно разработчики постоянно пишут код, исправляют ошибки и добавляют новые функции.
На самом деле сегодня Git используют практически все инженеры, работающие с инфраструктурой. В Git хранят не только исходный код приложений, но и Dockerfile, Kubernetes-манифесты, Terraform-конфигурации, Ansible Playbook, Bash-скрипты и CI/CD-конвейеры.
Фактически Git стал центральной точкой любого современного проекта.
Но чтобы понять, почему он настолько важен, сначала стоит разобраться, какие проблемы он решает.
Современная инфраструктура во многом держится на решениях для обеспечения качества обслуживания (QoS). Один из таких инструментов — PCEF, давно стал рабочей лошадкой сетевых операторов. В материале расскажем о том, как зародилась концепция QoS, и как она воплотилась в жизнь: начиная с первых телефонных линий на заре XX века и заканчивая выяснением вопроса, а что же считать «качеством обслуживания», над решением которого бились ученые 1970-х и 1980-х.