Infinite Scale - это облачная микросервисная архитектура и серверные приложения последнего поколения. Она не зависит от внешних программных пакетов, таких как PHP или базы данных, что устраняет все сложности, связанные с их использованием. Благодаря своей современной архитектуре, Infinite Scale предоставляет все модели развертывания для облачной инфраструктуры и оптимизированные настройки масштабирования для достижения наилучших результатов при минимальных затратах. Концепция единого бинарного файла значительно упрощает управление сервером по сравнению с любыми другими методами развертывания.

Infinite Scale поддерживает следующие клиенты ownCloud:
- веб
- Android
- iOS
- Рабочий стол

Для синхронизации и совместного использования файловых пространств с масштабируемой серверной частью на базе Reva с использованием открытых и хорошо определенных API, таких как WebDAV и CS3.

Infinite Scale ориентирован на простоту установки и эксплуатации и поставляется в виде единого исполняемого файла или контейнера, позволяющего масштабировать систему от Raspberry Pi до кластера Kubernetes путем изменения конфигурации и запуска нескольких сервисов по мере необходимости. Мультисервисная архитектура позволяет адаптировать функциональность под ваши потребности и повторно использовать уже существующие сервисы, например, при использовании Keycloak.

Основные возможности:
- Создание снапшотов PVC по расписанию (cron).
- Поддержка нескольких расписаний для одного PVC.
- Возможность настройки политики хранения (retention policy).
- Не требует изменений в приложении или манифестах PVC.

Как это работает:
Вы создаете ресурс SnapshotSchedule, в котором указываете:
- Селектор PVC.
- Cron-расписание.
- Максимальное количество снапшотов для хранения.
Контроллер следит за расписанием и создает VolumeSnapshot объекты автоматически.

Такой манифест будет создавать снапшоты каждые 6 часов для всех PVC с лейблом snapshot=true, и хранить максимум 5 последних.

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

Когда 20 ноября 2025 года из-за ошибки в конфигурации одного коммутатора отказала дисковая подсистема всей платформы, пятьдесят наших клиентов одновременно открыли тикеты. В этот момент выяснилось главное: техническая проблема была одна, а коммуникационных — десятки. Инцидент в инфраструктуре можно устранить за часы; инцидент доверия, если им не управлять, длится гораздо дольше. Именно поэтому зрелая поддержка — это не инженер за терминалом, а параллельно работающая система: одни чинят, другие в этот момент разговаривают с бизнесом клиента.

Я рад объявить о реализации улучшенной формулы конвертации из CPU shares cgroup v1 в CPU weight cgroup v2. Это улучшение решает критические проблемы с распределением приоритетов CPU для рабочих нагрузок Kubernetes при запуске на системах с cgroup v2.