Первые шаги на сервере: что быстрее освоить — консоль или ispmanager
У новичка на сервере обычно два пути: открыть панель управления в браузере или подключиться по SSH и разбираться с командами. Панель дает готовые формы под типовые операции, консоль — прямой доступ к системе. Освоить панель получится быстрее, но Linux под ней никуда не денется.
В статье сравнили оба подхода по сильным и слабым сторонам, разобрали сценарии для разработчика, владельца сайта и системного администратора и собрали минимум знаний Linux, который понадобится даже при работе через панель.
Представлен открытый проект pdf-inspector на Rust от команды Firecrawl. Это PDF-парсер, который умеет быстро обрабатывать страницы документов. Проект преобразует содержимое в Markdown, но при этом сохраняет структуру документа и таблицы. Решение работает без ограничений, код опубликован под лицензией MIT.
Антипаттерн при работе с VPS: почему не стоит постоянно работать под root? Работать под root на VPS удобно: перед командами не нужно вводить sudo. Но ошибка может затронуть весь сервер, а безопасность VPS требует разделять обычные и административные действия.
Почему работа под root удобна и опасна? В Unix доступ к файлам и управление процессами зависят от пользователя и его групп. Root может изменять системные файлы, управлять службами, пакетами и сетью. При постоянной работе под root ошибка в команде способна затронуть системные файлы и службы. Опечатка в пути команды удаления или ошибка в скрипте, запущенном от root, может стереть системные файлы, изменить права на каталоги и остановить сервисы. При запуске от обычного пользователя ущерб чаще ограничен его правами. Украденный ключ, разрешающий вход под root, или пароль этой учётной записи сразу дают административные права. Ключ обычного пользователя даёт доступ только с его правами. Получение root-прав зависит от настроек sudo, пароля, уязвимостей и ошибок конфигурации.
Как правильно: отдельный пользователь и sudo.
В Ubuntu или Debian создайте пользователя и добавьте его в группу sudo:
adduser operator
usermod -aG sudo operator
Добавьте публичный ключ в файл .ssh/authorized_keys в домашнем каталоге нового пользователя и проверьте вход по SSH. Затем задайте параметр в
/etc/ssh/sshd_config:
PermitRootLogin no
Проверьте конфигурацию и примените изменения без разрыва текущих подключений:
sshd -t && systemctl reload ssh
Мини-чек-лист безопасного старта на VPS
• Отдельный пользователь создан, команды запускаются через sudo.
«Bad Apple!! Но это же traceroute! В продолжение моего поста о том, как заставить инструменты traceroute отображать произвольное содержимое, и вдохновлённый выходом на днях ещё одной кавер‑версии Bad Apple, я просто не мог не сделать это», — пояснил Йонас Шефер.
Используя функцию numgen из библиотеки nftables, мы можем изменять количество переходов каждый раз при генерации пакета ICMPv6. Функция numgen возвращает либо случайные числа, либо монотонный счетчик. С помощью счётчика мы можем легко настроить каждый переход так, чтобы он возвращал разный IPv6-адрес при генерации ответного пакета.
Для этого потребовалось ещё две вещи. Во-первых, необходимо отключить ограничение скорости ядра (по умолчанию 1/с) для исходящего трафика ICMPv6 с помощью команды sysctl net.ipv6.icmp.ratelimit=0, иначе всё закончится очень быстро. Вторая проблема заключается в том, что mtr обычно показывает несколько адресов для каждого узла, поскольку это указывает на использование нескольких разных путей для пакета, и это обычно полезная информация.
После всего этого я использовал ffmpeg для передискретизации видео до 8 кадров в секунду (что соответствует интервалу в 125 мс между кадрами) и экспорта уменьшенных (до 30x11 пикселей) отдельных кадров в файлы PNG. Затем я написал скрипт на Python для чтения файлов изображений и преобразования их в набор правил nftables для генерации соответствующих ответов ICMPv6. В результате получается чуть более мегабайта правил nftables, но это определённо того стоит.
Почему дешёвый VPS-сервер может обойтись дорого в продакшене? Тариф в 3–5 долларов в месяц за VPS кажется приятной экономией на старте. Но если тариф выбран только по цене, счёт за простой, срочную миграцию и потерянных клиентов может прийти позже и оказаться выше, чем сэкономленная разница в ценнике.
Что скрывается за низким ценником? За низкой ценой могут стоять оверселлинг, общий диск, ограниченная поддержка и слабые гарантии по SLA. У части провайдеров низкая цена достигается за счёт плотного размещения клиентов на одной ноде: продаётся больше vCPU и RAM, чем физически доступно, в расчёте на то, что нагрузки не совпадут. В результате могут появляться CPU steal time, просадки I/O от соседей по железу и нестабильная производительность общего хранилища. SLA на бюджетном VPS-сервере может отсутствовать или ограничиваться формальным обещанием без понятной компенсации.
Реальные риски в продакшене. Под нагрузкой проблемы проявляются внезапно: API начинает отвечать с задержками, база данных упирается в I/O, сервис падает в самый неподходящий момент. Потеря данных из-за отсутствия бэкапов или срочная миграция перед дедлайном – реальные риски для проектов, которые выбирают инфраструктуру только по цене.
Как считать полную стоимость VPS? Реальная цена – это не только тариф, а TCO: тариф + стоимость инцидентов. Один час простоя интернет-магазина в пиковый сезон легко перекрывает годовую разницу между дешёвым и надёжным VPS. Добавьте часы на диагностику и миграцию, потери из-за недовольных клиентов – и экономия быстро испаряется.
Чек-лист: признаки надёжного VPS:
• SLA не ниже 99,9%
• NVMe-хранилище со стабильной производительностью или понятными IOPS-лимитами
• Современная аппаратная виртуализация, например KVM, и понятная политика изоляции ресурсов
• Автоматические бэкапы с проверенным восстановлением
• Поддержка 24/7 с заявленным временем ответа
• Гарантированная пропускная способность сети
Прежде чем продлевать текущий тариф, проверьте свой VPS по этому чек-листу. Если несколько пунктов вызывают сомнения – стоит пересмотреть выбор сервера для продакшена до первого серьёзного инцидента.
Что прокачать системному администратору для профессионально роста
31 июля — День системного администратора, поздравляем с профессиональным праздником всех причастных! И это хороший повод ненадолго отложить чужие заявки и подумать о собственном развитии.
Профессия давно вышла за пределы настройки серверов и учетных записей. Современному админу приходится работать с контейнерами, автоматизацией, наблюдаемостью и безопасностью. Здесь собрали несколько бесплатных уроков для тех, кто хочет увереннее решать текущие задачи или двигаться в сторону DevOps, SRE и DevSecOps.
↓ Заглянуть под капот Linux Когда проблема находится ниже уровня сервисов и конфигов, полезно понимать, что происходит внутри системы.
«Что такое модуль ядра. Как его написать, собрать, запустить» 3 августа в 20:00 За один вечер можно пройти путь от исходного кода до загрузки собственного модуля и перестать воспринимать ядро Linux как полностью закрытый черный ящик. Записаться
↓ Быстрее находить причины сбоев Обычный мониторинг сообщает, что сервису плохо. Наблюдаемость помогает понять, где именно все пошло не так.
«OpenTelemetry — наблюдаемость на блюдечке» 4 августа в 20:00 Метрики, логи и трассировки пригодятся, когда один запрос проходит через несколько сервисов, а источник задержки или ошибки не лежит на поверхности. Записаться
↓ Сделать деплой предсказуемым Если выпуск новой версии зависит от набора ручных команд и памяти конкретного сотрудника, процесс пора автоматизировать.
«Kubernetes + CI/CD + GitOps — делаем стабильный деплой без выхода из кластера» 10 августа в 20:00 Полезно тем, кто хочет хранить состояние инфраструктуры в Git, контролировать изменения и откатываться без ночной археологии в терминале. Записаться
↓ Перестать искать логи по серверам вручную Чем больше машин и контейнеров, тем меньше хочется подключаться к каждому из них ради одной строки.
«Системы логирования: ELK, EFK или Graylog?» 17 августа в 20:00 Возможность сопоставить популярные стеки и понять, какой из них лучше подходит под конкретную инфраструктуру, объем данных и доступные ресурсы. Записаться
↓ Подготовиться к сбою до сбоя Единственная точка отказа обычно не беспокоит ровно до того момента, пока не откажет.
«Готовим инфраструктуру к сбоям: отказоустойчивый кластер на базе VRRP и HAProxy» 18 августа в 19:00
Практика для тех, кому нужно автоматическое переключение между узлами, балансировка нагрузки и меньше ручных действий во время аварии. Записаться
Почему аптайм зависит не только от VPS-провайдера?
Провайдер может обещать 99,9% аптайма VPS, но аптайм продукта и аптайм инфраструктурного узла остаются разными показателями. Когда сервис падает, причина часто находится за пределами зоны ответственности провайдера: в приложении, деплое, базе данных, DNS или внешних API.
Что именно гарантирует VPS-провайдер? SLA VPS-провайдера покрывает доступность физического узла, сетевого канала и питания. Если оборудование работает и сеть доступна, инфраструктурная часть SLA может считаться выполненной. Код, конфигурации, база данных и внешние зависимости остаются в вашей зоне ответственности.
Где на самом деле ломается аптайм? На практике многие простои возникают не из-за сбоев инфраструктуры, а из-за ошибок в коде и операционных процессах. Неудачный деплой, утечка памяти, переполненный диск, истёкший SSL-сертификат, недоступный DNS или упавший сторонний API гасят сервис независимо от стабильности хостинга.
Ошибки на стороне команды. Релиз без стейджинга и механизма отката, отсутствие проверок состояния, ручные правки конфигурации в продакшене: всё это классические источники простоев. Мониторинг, добавленный «потом», не предупреждает о проблеме до того, как её замечают пользователи.
Как повысить реальный аптайм сервиса? Стабильность сервиса на VPS складывается из нескольких пунктов. Автоматические бэкапы и снапшоты упрощают восстановление после сбоя. Проверки состояния и алерты сокращают время обнаружения инцидента. CI/CD-пайплайн с проверками и понятным откатом снижает риск ошибок при деплое.
Чек-лист надёжности:
Бэкапы и снапшоты настроены и проверены
DNS TTL снижен перед плановыми миграциями
SSL-сертификаты обновляются автоматически
Есть процедура отката для каждого релиза
Мониторинг и алерты подключены до деплоя
Аптайм сервиса на VPS-сервере зависит от инфраструктуры, архитектуры и операционных процессов одновременно. Пересмотрите собственные процессы: деплой, мониторинг, бэкапы и восстановление после сбоев. Если нужен взгляд со стороны, можно начать с аудита инфраструктуры и точек отказа.
Как разрешить пользователю реплики удаленно подключаться к Master-серверу PostgreSQL?
Вы настраиваете отказоустойчивый кластер баз данных. При попытке синхронизировать реплику с мастер-сервером соединение обрывается с ошибками сетевого доступа. В каком конфигурационном файле и как именно нужно прописать доступы, чтобы Master принял входящее подключение?
По умолчанию PostgreSQL придерживается строгой политики безопасности и блокирует любые удаленные попытки подключения, если они не разрешены в подсистеме авторизации.
Чтобы решить эту проблему, необходимо отредактировать конфигурационный файл клиентской аутентификации pg_hba.conf на стороне Master-сервера и явно разрешить репликацию для IP-адреса вашей реплики.
Для доступа к реплицируемым данным у пользователя replicator должна быть привилегия replication:
ALTER ROLE replicator WITH REPLICATION;
Предварительно ознакомьтесь с порядком применения правил в pg_hba.conf в официальной документации.
Чтобы PostgreSQL применил изменения в конфигурации авторизации, выполните reload службы в терминале:
systemctl reload postgresql
В качестве альтернативы можно отправить сигнал процессу postmaster с помощью pg_ctl reload, вызовом SQL-функции pg_reload_conf() или используя kill -HUP.
После применения изменений Master-сервер начнет принимать входящие пакеты от указанного IP-адреса, и процесс репликации сможет успешно инициализироваться.
На первый взгляд, настройка репликации в PostgreSQL кажется простой задачей: достаточно открыть доступ в pg_hba.conf и подключить standby-сервер.
Но в production-инфраструктуре за этой «простой настройкой» скрывается целый стек инженерных задач: необходимо следить за консистентностью WAL-журнала, контролировать лаг между репликами, обеспечивать безопасную сетевую доступность между узлами, настраивать резервное копирование, регулярно тестировать сценарии аварийного переключения и быть готовым вручную восстанавливать кластер в случае деградации одного из серверов.
Поэтому в ряде сценариев современные команды переходят от self-managed PostgreSQL к PaaS-решениям вроде Managed Databases, где отказоустойчивость, репликация и обслуживание кластера уже реализованы на уровне платформы.
Это позволяет сократить операционные расходы на сопровождение инфраструктуры и снизить риск простоев критичных сервисов.
Пост призван показать, насколько инструменты тестирования и автоматизации на самом деле привязаны к конкретной реализации браузера. Если вы пришли за технической информацией, то TL;DR: если хотите автоматизировать скачивание файлов через браузер - используйте Chromium-based
Первая версия утилиты работала очень топорно и работала на playwright+chromium(это важно)
Когда Google в очередной раз добавили какой-то всратый шаг в свой визард авторизации, я понял, что надо переводить скрипт на стейт-машину. Так можно гораздо быстрее управлять переходами по экранам. И раз уж рефакторинг назрел, то хотелось избавиться от ручных антибот-настроек, перейдя на одно из промышленных решений.
Самое популярное такое решение работает на Firefox. Ну заменить один браузер на другой - что может пойти не так (спойлер: почти всё)
Сначала всё шло хорошо - кастомный FF удалось запустить на playwright с возможностью удаленного исполнения скипта автоматизации как раньше. Сценарий уверенно запустился и дошел до скачивания файлов. Скрипт нажимал ссылку, браузер начинал и успешно завершал загрузку, но скрипт так и висел, ожидая файла
Оказывается, FF в playwright не поддерживает события загрузки файлов, которых ждет. Совсем. Тут и случилось самое страшное. Что за вендорлок, почему я должен использовать именно chromium??? - подумал я..
* месяц хобби-разработки
Решение как заставить FF делать то, что нужно - нашлось быстро. Нужно просто использовать Selenium Grid
Событий загрузки там нет, но зато есть API доступа к скачанным файлам, на котором можно построить цикл ожидания загрузки. Кроме того, в него же удачно вписывалось шифрование кредов, которое раньше реализовывалось через отдельный сервис+контейнер
Первое же тестирование показало новую проблему. Playwright позволяет сохранить все cookies, вообще все и загрузить их в контекст СЕССИИ до загрузки какой-либо страницы. Selenium так не работает: он загружает/проставляет cookies только в контексте СТРАНИЦЫ. Это делает перенос данных авторизации гораздо мучительнее, ведь Google активно сопротивляется сбору cookies авторизации, редиректит с accounts.google.com на myaccount.google.com и т.д.
Чтобы добыть вообще все cookies нужен BiDi, но вроде как в Grid его еще не завезли по умолчанию. Поэтому надо в плагине писать прокси, которое позволяет по стандартной ручке достать все cookies..
После решения проблем с cookies файлы в скрипте наконец-то стали загружаться.. но только маленькие🤠
Как только загружался 2ГБ архив - скрипт наглухо OOM-ился. Стандартный API загрузки файла передает его целиком, заэнкоженым в base64. Естественно, целиком загнать в base64 2ГБ - жестоко, и столько памяти скрипту бэкапа никто выделять не собирается.
Снова пишем плагин, который рядом с grid выставляет нормальные стриминговые ручки, которые позволяют читать файл кусочками
И вот на этом месте - ура, все работает как надо! Но не проще ли было месяц назад ПРОСТО ВЗЯТЬ Chromium..🤔
CPU steal time: как измерить, как доказать и когда он ни при чём. В логах пусто, загрузка процессора умеренная, а приложение отвечает вдвое медленнее обычного. Один из кандидатов на объяснение — steal time: время, когда виртуальная машина была готова считать, но не получила физическое ядро.
Метрика простая на вид и очень легко используется неправильно. Ниже — как она устроена, как снять её так, чтобы результат что-то значил, и почему высокий steal сам по себе ещё не диагноз.
Как steal вообще появляется Гипервизор раздаёт физические ядра между виртуальными машинами. Когда планировщик гостевого ядра ставит задачу на vCPU, а гипервизор в этот момент отдал физическое ядро другой машине, гостевое ядро видит, что время прошло, а работа не выполнялась. Эта разница и учитывается как steal.
Отсюда важное следствие: steal измеряется изнутри гостя и всегда является косвенной оценкой. Гость не знает, почему ему не дали ядро. Причин минимум четыре:
конкуренция с соседними VM на ноде;
ограничение по CPU на уровне тарифа (квота), которое гипервизор применяет к вам;
накладные расходы самого планировщика гипервизора;
Где steal не виден вообще? Если у вас контейнерная виртуализация (lxc, openvz), steal time не появится никогда — механизма для него нет, ядро общее с хостом. Проверить:
systemd-detect-virt
Аналог steal для контейнеров — троттлинг по cgroup:
Растущий nr_throttled означает, что вы выбираете свою квоту. Это не соседи и не оверселлинг — это ваш лимит, и решается он либо оптимизацией, либо тарифом.
Какие значения считать нормой. Универсальной нормы нет — она зависит от платформы виртуализации, политики провайдера и тарифа. Практические ориентиры, которые у меня обычно работают:
0–1% — фон, встречается почти везде, игнорируем.
3–5% — повод посмотреть динамику и сопоставить с задержками приложения. Само по себе не проблема.
выше 10% устойчиво — заметно влияет на латентно-чувствительные сервисы: API, realtime, базы под нагрузкой. Пакетную обработку может почти не задевать.
Ключевое слово — устойчиво. Смотрите значение за 10–15 минут, а не пиковый выброс. Разовый скачок до 30% на две секунды не значит ничего.
Как отличить соседей от собственной квоты. Единственный надёжный способ — сопоставить steal с вашей нагрузкой.
Постройте два ряда за сутки: steal и ваш собственный CPU usage (us + sy). Дальше:
Steal растёт вместе с вашей нагрузкой и падает вместе с ней — почти наверняка вы упираетесь в квоту тарифа. Провайдер тут ни при чём.
Steal приходит независимо от вашей активности, в том числе ночью при простое, — это внешняя конкуренция.
Без исторических данных этот анализ невозможен, поэтому sysstat стоит поставить заранее, а не в момент инцидента.
Что передавать в поддержку? Обращение вида «у меня высокий steal» почти всегда возвращается с просьбой уточнить. Работает такой набор:
вывод sar -u 1 600 или график за несколько часов;
mpstat -P ALL 1 за минуту — с разбивкой по ядрам;
ваша собственная загрузка CPU за тот же период, чтобы показать отсутствие корреляции;
конкретные временные метки, когда приложение деградировало;
systemd-detect-virt и параметры тарифа.
Что не поможет
Оптимизация кода. Если ядро вам не выдают, эффективность вашего кода на steal не влияет.
Добавление vCPU. Иногда даже ухудшает: больше vCPU — больше конкуренции за планирование, особенно на переподписанной ноде.
Перезагрузка. Помогает только если приводит к переезду на другую ноду, и это лотерея.
Чек-лист
systemd-detect-virt # есть ли steal в принципе
vmstat 1 # характер: плато или выбросы
mpstat -P ALL 1 # распределение по ядрам
sar -u 1 600 # устойчивость за 10 минут
grep throttled /sys/fs/cgroup/cpu.stat # для контейн
Сходил на DayOff от Selectel и понял, что все эти годы смотрел на процесс найма только со стороны соискателя. Отправил резюме, сижу, жду.
Одной из тем был современный найм. После доклада Киры Кузьменко и разговоров с ней после выступления (видно, когда человек по-настоящему увлечён своей работой), и общения с HR из Selectel я впервые посмотрел на процесс глазами тех, кто нанимает.
Стало понятнее.
На одну вакансию сегодня могут приходить тысячи откликов. Заметная часть из них - массовая автоматическая рассылка. Провести интервью со всеми невозможно физически, поэтому компании фильтруют этот поток как могут.
Резюме стоит адаптировать под конкретную вакансию. Потому что и автоматические фильтры, и люди ищут в тексте совпадения с требованиями. Если релевантный опыт есть - важно сделать так, чтобы его было легко увидеть.
Сопроводительное письмо. Я никогда толком не понимал, что туда писать. Оказывается надо писать не о себе вообще, а о том, какую пользу ты, со своим опытом, можешь принести компании именно на этой позиции.
Чем менее массовый канал, тем больше у отклика шансов быть прочитанным. Например: за неделю приходит около тысячи откликов с hh, несколько десятков через сайт компании и пара сообщений напрямую от кандидатов, которые изучили вакансию и объяснили, почему подходят именно на неё. У последних шансов заметно больше просто потому, что их физически можно прочитать за пять минут.
Лучший вариант из всех это личная рекомендация. Когда сотрудник компании говорит: "я знаю этого человека, он хороший специалист, с которым комфортно работать".
Спасибо Selectel за DayOff - за взгляд со стороны нанимающего, и за экскурсию по Эрарте.
И если ваши отклики остаются без ответа, то, возможно, дело не в вас - просто очередь не дошла.
Где ломается инфраструктура: 13 открытых уроков для системных администраторов
Когда инфраструктура работает стабильно, кажется, что всё под контролем. Но один сбой быстро показывает слабые места: сеть уходит в шторм, кластер не выдерживает отказа, журналы не помогают найти причину, а автоматизация только добавляет ручной работы.
На этих открытых уроках разберём, как диагностировать такие проблемы, настраивать Linux, сети, наблюдаемость и отказоустойчивость, чтобы быстрее находить источник сбоя и выстраивать инфраструктуру, которая предсказуемо работает под нагрузкой.
Сети, хранение данных и отказоустойчивость
30 июля в 20:00. «Восстанавливаем RAID5 в Linux». Записаться
3 августа в 20:00. «MPLS для корпоративных сетей: мифы, реальность и практика». Записаться
18 августа в 19:00. «Готовим инфраструктуру к сбоям: отказоустойчивый кластер на базе VRRP и HAProxy». Записаться
24 августа в 20:00. «Защита от петель L2: что выбрать, если STP уже не устраивает». Записаться
Linux и системное программирование
3 августа в 20:00. «Что такое модуль ядра. Как его написать, собрать, запустить». Записаться
10 августа в 20:00. «Вход в ядро: системные вызовы и граница между user space и kernel space». Записаться
20 августа в 20:00. «Средства защиты в ядре Linux». Записаться
Kubernetes и автоматизация инфраструктуры
10 августа в 20:00. «Kubernetes + CI/CD + GitOps — делаем стабильный деплой без выхода из кластера». Записаться
13 августа в 20:00. «Принцип DRY в GitLab CI: как избавиться от дублирования и навести порядок в пайплайнах». Записаться
Наблюдаемость и логирование
4 августа в 20:00. «OpenTelemetry — наблюдаемость на блюдечке». Записаться
17 августа в 20:00. «Системы логирования: ELK, EFK или Graylog?». Записаться
Безопасность инфраструктуры
3 августа в 20:00. «Какие результаты должен давать DevSecOps-проект бизнесу и команде». Записаться
18 августа в 20:00. «Безопасный релиз на практике: SAST, SCA, контейнеры и security gates». Записаться
Все занятия бесплатные. Можно задать вопросы преподавателю, сверить настройки и понять, какой инфраструктурный пробел стоит закрыть следующим.
«Ищем петли и шторма в L2-сети» Практический материал о поиске сетевых петель, MAC flapping, диагностике проблемного порта и защите сети от повторного коллапса.
JSON или XML: сравнение популярных форматов обмена данными
Выбор между JSON и XML редко стоит как «что лучше» — это два инструмента с разной философией. JSON оптимизирован под компактность и скорость парсинга, XML — под строгую структуру, валидацию и сложные документы со смешанным содержимым.
В статье разобрали оба формата на одинаковых примерах, прошлись по истории и причинам, по которым JSON вытеснил XML в вебе. Сравнили по ключевым параметрам: синтаксис, объем, скорость обработки, поддержка типов данных, комментарии, пространства имен, валидация через JSON Schema и XSD. И отдельно написали про области применения.
Как Купер перенес 100% инфраструктуры в облако, снизил количество инцидентов и сократил время на их устранение
🏭 Что за компания Купер — онлайн-сервис доставки продуктов, товаров и готовой еды из магазинов и ресторанов. Сервис работает в 360 городах России, ежедневно обрабатывая десятки тысяч запросов в секунду. Ранее Купер уже перенес 40 ТБ аналитических данных в облако и остался доволен результатом, поэтому было принято решение продолжить процесс миграции.
⚡ Задача Купер нуждался в бесшовном переносе всей продакшен-инфраструктуры в облако без остановки работы высоконагруженной платформы. Требовалось повысить производительность, отказоустойчивость и упростить эксплуатацию сервиса, который должен стабильно работать даже в периоды максимальных нагрузок.
☁️ Что сделали Команды провайдера и заказчика синхронизировали требования к инфраструктуре и сетевой архитектуре для плавного переезда. Провайдер помог сформировать команду миграции из 12 специалистов, чей онбординг занял две недели. За 10 месяцев Купер и Cloud.ru перенесли 100% ИТ-инфраструктуры в облако, завершив миграцию в конце апреля 2026 года.
Архитектуру разделили на три логически изолированных слоя — внешний периметр (DMZ) с балансировщиком и веб-серверами, демилитаризованную зону для проверки трафика и закрытый контур бэкенда с базами данных и системами обработки заказов. Дополнительно команда провайдера доработала PaaS-сервисы под задачи Купера, внеся более 30 изменений и взяв на себя их дальнейшее сопровождение — обновления, контроль совместимости и проверку работоспособности.
🦾 Что получили в итоге Число инцидентов, связанных с облачной инфраструктурой, сократилось на 23%, доступность облачных ресурсов выросла, а средняя длительность инцидентов снизилась на 18%. Затраты на устранение технических сбоев уменьшились в 4 раза, а благодаря FinOps-инструментам Cloud.ru Купер получил прозрачный контроль бюджета и автоматические рекомендации по оптимизации расходов. В итоге онлайн-сервис получил масштабируемую платформу, способную стабильно обрабатывать данные любых объемов и выдерживать пиковые нагрузки без сбоев.
Проект nosubscription.org содержит библиотеку с 1000+ альтернативами платным программам, включая открытые и бесплатные проекты. Есть удобный поиск и разбивка по категориям.
Представлен открытый архитектурный инструмент Pascal Editor (3D building editor built with React Three Fiber and WebGPU), который работает прямо в браузере. Рисуем стены, перекрытия и крыши, ставим двери, окна и мебель, собираем несколько этажей и переключаемся между 2D‑планом и 3D. Готовый дом можно разобрать по этажам, пройтись по нему от первого лица и выгрузить в другие редакторы. Также к проекту можно подключить Codex и Claude Code и попросить ИИ создавать элементы здания.
Представлен открытый SSH‑менеджер Termix, который работает без подписок или рекламы. Проект включает в себя как стандартные функции, так и расширенные:
2FA для защиты доступа к серверам;
удобный интерфейс, разработанный на React и Tailwind CSS;
терминал SSH с разделением экрана, управлением SSH‑туннелями;
удалённый редактор файлов с подсветкой синтаксиса;
Приглашаем на пятилетие «Тантор Лабс». 10 сентября - Tantor JAM 2026
Первый юбилей Tantor — пять лет с момента основания компании. За это время мы прошли путь от стартапа до технологического лидера, одного из ведущих российских разработчиков в области управления и хранения данных, создали собственную экосистему продуктов и собрали вокруг себя сообщество, которое сегодня во многом определяет развитие российского рынка СУБД.
Программу скоро представим. Среди главных премьер:
Новое поколение Платформы Tantor, основанное на AI-first подходе. Представим ИИ-администратора БД с целым роем специализированных ИИ-агентов, которые возьмут на себя рутинные операции по работе с СУБД.
Результаты испытаний МБД Tantor XData Gen3 на различных профилях нагрузки. Покажем, как enterprise-технологии, ранее доступные только в зарубежных решениях, — независимое масштабирование Compute и Storage, RDMA, распределенная файловая система и полноценный HTAP — становятся доступны в российском ПАКе.
Подробнее расскажем о Tantor Polar — новой распределенной СУБД, открывающей следующий этап развития российских PostgreSQL-технологий с полным сохранением совместимости с экосистемой Postgres.
Вас ждут выступления руководителей разработки, общение с инженерами, архитекторами, заказчиками и партнерами, а также праздничная программа в честь пятилетия компании.
Выберите, что прокачать: открытые уроки для IT-специалистов на неделю
Новая неделя — хороший повод закрыть конкретный пробел в знаниях, разобраться с рабочей задачей или попробовать направление, к которому давно присматривались.
Собрали открытые уроки по категориям, чтобы вы могли быстро найти подходящую тему.
Инфраструктура, DevOps и безопасность
27 июля в 20:00 — «K8S + Vault — как получать секреты?». Записаться
27 июля в 20:00 — «Использование GitLab CI для работы с Ansible». Записаться
30 июля в 20:00 — «Восстанавливаем RAID5 в Linux». Записаться
3 августа в 20:00 — «Что такое модуль ядра. Как его написать, собрать, запустить». Записаться
3 августа в 20:00 — «MPLS для корпоративных сетей: мифы, реальность и практика». Записаться
3 августа в 20:00 — «Какие результаты должен давать DevSecOps-проект бизнесу и команде». Записаться
Разработка
27 июля в 20:00 — «Разработка Embedded-устройств для IoT». Записаться
28 июля в 20:00 — «Что Golang даёт индустрии и что он может дать вам». Записаться
29 июля в 20:00 — «Собери себя сам: пишем трекер привычек на чистом JavaScript». Записаться
3 августа в 20:00 — «Оживляем код: первые шаги в ООП на Python». Записаться
3 августа в 20:00 — «Go: управляем памятью как профи. Массивы, слайсы и мапы». Записаться
AI и мультимодальные технологии
28 июля в 20:00 — «Стирание границ: нативная интеграция ASR, TTS и NLP в эпоху мультимодальных LLM». Записаться
Тестирование и развитие карьеры
30 июля в 20:00 — «API- и UI-тестирование с Playwright на Python». Записаться
30 июля в 20:00 — «Прохождение собеседования на нагрузочного тестировщика. Что интересует работодателя?». Записаться
Архитектура, корпоративные системы и интеграции
30 июля в 20:00 — «Функциональный архитектор 1С: как перестать быть „переводчиком требований“ и начать управлять системой». Записаться
3 августа в 20:00 — «Кастомизация компонентов в Битрикс24». Записаться
3 августа в 20:00 — «Использование брокера сообщений Apache Kafka в распределённых очередях». Записаться
Когда рабочая задача упирается в нехватку конкретных знаний, можно выбрать бесплатный урок по нужной теме, задать вопросы преподавателю-практику и проверить свой подход.
Это поможет точечно закрыть пробел и увереннее применять новые знания в работе.
