Хаборовчане и гости привет!

Вкратце суть того что произошло. По сути фильм ужасов от Бегет.

В ночь с 1 на 2 ноября 2026 года на нашу инфраструктуру была совершена кибератака с получением доступа к управляющему контуру всей архитектуры и последующим запуском обнуляющих скриптов.... К сожалению, бинарные бэкапы VPS полностью утеряны. Остаётся возможность восстановления данных из файловых бэкапов.... В облачной инфраструктуре (VPS, S3 и Kubernetes) все данные были утрачены.... Настройки CDN, IP утрачены. Мы не сдаёмся и продолжаем поиск способов восстановить эти данные.
Источник https://vk.ru/begetru?w=wall-2782733_35546

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

У нас есть машзал ЦОДа, где стоят ванны с серваками. И вот что я вам скажу про жидкостное охлаждение:

— Это билет в один конец. Стоит вам один раз погрузить сервер в ванну, больше вы его рабочим не достанете.

— Это позволяет примерно в 5–6 раз повысить предел возможного относительно воздушного охлаждения, то есть ваши процессоры ждёт незабываемое приключение с разгоном за пределами всякого здравого смысла.

— Надо снять кулеры, но современные карточки очень любят ими управлять, поэтому ещё понадобится драйвер, который оверрайдит попытки потротлить, потому что кулер вращается медленно.

— С ванны (аналога стойки по размеру) можно спокойно снимать не 6–15 кВт, а 120 кВт, то есть раз в 15 больше, чем в воздушном ЦОДе, и в разы больше, чем на обычном водяном охлаждении.

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

— Это снимает гарантию, поэтому мы купаем только старое железо, уже и так сошедшее с поддержки вендора.

— Можно совать в ванну руки, током вас не коротнёт, потому что жидкость диэлектрическая. Но мы всегда делаем вид, что бьёмся в конвульсиях. Это нас очень развлекает, когда приходят новые люди.

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

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

Но начнём с того, как эта фигня вообще работает.

Копия Яндекс 360 есть, а вернуть из неё можно не всё. Настройки Трекера уровня организации назад не приходят, а закрытые страницы Вики без временного доступа в копию не попадут. Что проверить до подключения системы и о чём спросить поставщика до пилота, разобрано ниже.

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

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

Так появился особый дистрибутив для инженеров Яндекса, попавших в ад, Яnetes.

Есть Яндекс.Диск объемом ~500GB, заполненный в основном фото (RAW и JPEG) и видео, и задача сохранить все его содержимое на локальный диск.

Вроде бы ровно для этого и нужен официальный клиент - но в реальных условиях он повел себя крайне странно.

Пришлось брать дело в свои руки, а заодно плотнее познакомиться с node:streams...

У нас под постом про ЦОДы развернулась дискуссия: какой должна быть ракета, чтобы устроить дата-центру пробитие. Я почувствовал себя среди оружейных баронов и экспертов по уничтожению дата-центров.

Знаете, у нас есть некоторая экспертиза в этом. Потому что сгоревших ЦОДов мало, а вот попадавших из-за кривых рук — очень много. Поэтому мы тут решили на Хэллоуин сравнить разные технологии с тем, как бы выглядело оружие на их базе.

Кроме MongoDB без чеки из заголовка у нас есть ещё 20 не менее убойных штук.

Привет, Хабр! Это команда интернет‑газеты о сервисном бизнесе «Заявка закрыта» — проекта Okdesk, платформы для управления заявками, выездным обслуживанием и ТОиР. Мы регулярно делимся практическими материалами, которые помогают сервисным компаниям работать эффективнее и зарабатывать больше — без лишней теории и воды.

Сегодня делимся статьёй Олега Скрынника, управляющего партнёра Cleverics: он разбирает, как грамотно выстроить работу с разными видами заявок и не терять деньги из‑за хаоса в процессах.

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

Привет, я Сергей, DevOps-инженер в KTS. Перейду сразу к делу.

К отказу отдельной виртуалки вы наверняка готовы. Но не все готовы к другому классу аварии: к потере площадки, на которой находятся почти все ВМ проекта.

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

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

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

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

В статье решил сравнить четыре способа запустить одно и то же приложение и разобрал случаи, когда действительно нужен Kubernetes.

Эта статья для бэкенд-разработчиков, DevOps, SRE и тимлидов. Если вы работали с виртуалками и Docker, но пока присматриваетесь к Kubernetes — велком под кат.

24 ноября приглашаем вас на вебинар, где мы на практике разберем, как эффективно работать с облачной платформой. В прямом эфире мы создадим профиль компании в личном кабинете и на реальных примерах покажем, как облако помогает решать бизнес‑задачи «здесь и сейчас».

Особенность формата:

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

Мы шаг за шагом покажем:

- Как быстро начать работу в облаке.

- Какие инструменты экономят время и деньги.

- Как разворачивать виртуальные машины.

- Как подключать любой из 45+ сервисов в несколько кликов.

- Как безопасно масштабировать бизнес.

8 октября 2026 года наш облачный провайдер потерял дата-центр, в котором работала вся наша инфраструктура. Через трое суток то же самое случилось со второй площадкой, на которую мы к тому моменту успели переехать. За неделю мы дважды поднимали платформу почти с нуля. Как говорится в меме: да, это я, и как я докатился до жизни такой…

Небольшой спойлер итога ситуации, которую я буду разбирать дальше: мы безвозвратно потеряли данные за 20 часов, прошедших с последнего резервного копирования. Сервисы переехали сначала в соседнюю зону того же облака, потом к другому провайдеру, а миграцию в Kubernetes, начатую год назад, мы закончили за двое суток. Базы данных теперь хранятся в двух копиях у разных провайдеров.

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

Развернуть кластер Kubernetes вручную — задача не столько сложная, сколько продолжительная: поднять виртуальные машины, установить компоненты Control Plane, настроить CNI, CSI, DNS, разложить сертификаты. Понять, что надо было иначе, удалить, сделать заново, и так раза три.

Развёртывание — это только первый этап жизни кластера, дальше нужно заниматься поддержанием его деятельности, и это стоит дорого. Каждая рутинная операция эксплуатации в ручном режиме — это десятки человеко-часов и постоянные дежурства.

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

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

В этой статье разберём, как устроено централизованное хранение секретов, сравним восемь инструментов и посмотрим, что стоит проверить до внедрения. Основной практический сценарий — Java/Spring Boot, Gradle.

Ваша консоль пылится без дела? Сдайте её в аренду, пусть зарабатывает! Примерно так звучит заголовок новости на VK Play: сервис ищет партнёров для облачного гейминга. Мне стало любопытно, сколько может заработать мой Xbox Series S, и я написал им в поддержку. Ответили подробно. Ниже всё, что узнал, и мой вывод в конце.

С 1 марта 2026 года действует 117-й приказ ФСТЭК России, и за полгода он стал главной темой почти любого разговора с заказчиками из госсектора. Особенно в регионах. Следом меняются требования к защите персональных данных. Проект приказа на замену 21-го уже прошел общественное обсуждение. Операторы ГИС и ИСПДн спрашивают одно и то же: насколько все страшно и с чего начинать, если нет ни денег, ни людей?

Привет, Хабр! Это команда интернет‑газеты о сервисном бизнесе «Заявка закрыта» – проекта Okdesk, платформы для управления заявками, выездным обслуживанием и ТОиР. Мы регулярно делимся практическими материалами, которые помогают сервисным компаниям работать эффективнее и зарабатывать больше – без лишней теории и воды. 

Сегодня расскажем, как компания «Мобиус» перестроила техническую поддержку корпоративных заказчиков и реализовала в Okdesk трехмерную сервисную модель с несколькими линиями поддержки, продуктовыми командами и отдельными очередями заявок. Разберём, как организовали распределение обращений между специалистами, разграничили зоны ответственности и выстроили процессы обслуживания.

Выполните curl -I https://example.com прямо сейчас. В ответе вы увидите server: cloudflare и cf-ray — домен, который мы все используем для примеров кода, работает за одним из крупнейших CDN в мире.

Но так было не всегда. В 2002 году example.com отдавался с Apache 1.3.22 на Red Hat Linux, а в 2013-м переехал на EdgeCast CDN. За последние 25 лет домен сменил несколько инфраструктурных провайдеров и пережил множество оптимизаций.

Давайте посмотрим, как менялась архитектура example.com и какие технические решения стоят за этими изменениями.

Расшифровки созвонов уже давно стали обыденностью для гиков, организаций из IT и диджитала. Так и на наших созвонах с волонтерами и партнерами SPB Founders уже регулярно появляется дополнительный участник — бот‑notetaker. После онлайн‑встречи остаются расшифровка, краткое содержание и задачи, поэтому привычка вести параллельно заметки у меня постепенно отпала (примерно с 2023 года, если честно — отсутствие записи считаю теперь признаком просто дружеской онлайн‑вечеринки или страшно секретных переговоров). С одним из авторов сервисов транскрибации до бума ИИшных сервисов мы даже долгое время делали митапы SPB Founders как с большим профи в звуке и видеотрансляциях, но после его переезда за пределы России и выхода кучи ИИ‑альтернатив только изредка пользуемся его решением.

Как оказалось, выгрузку аудио или видео на расшифровку или формат «бот из приглашения в календаре сам заходит в Zoom и всё записывает даже без меня» уже далеко не единственный: встречу можно писать прямо с компьютера с захватом аудиоканала или вообще использовать ИИ‑транскрибатора, встроенного в саму ВКС. Стало интересно посмотреть, насколько эти подходы сейчас отличаются, и в каких случаях каждый удобнее. Для сравнения взял только то, где появлялся сам и активировал расшифровку за осень 2026 го: Zoom, mymeet.ai, Speech2Text.ru, МТС Линк, Контур.Толк и Яндекс Телемост. К счастью, делать саммари после встречи умеют уже все — поэтому этот критерий не вошел в таблицу.

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

В какой бы автоматизированный и удобный сервис вы ни зашли, вам все равно придется настраивать много конфигураций руками. А для этого нужно понимать, что как устроено и какие функции (и в каком объеме) могут закрыть ваши задачи. Разве что внедрить в сервис толкового ИИ-ассистента, который все объяснит, да еще и в режиме агента сделает работу за вас.

Я давно мечтал, чтобы в MWS Tables появилось нечто подобное. Хочется, чтобы ИИ-машина оперировала существующими данными, создавала таблицы и связи между ними, писала формулы, собирала представления и отвечала на вопросы по содержимому пространства. 

Так вот, в обычный рабочий день я зашел в MWS Tables и внизу интерфейса обнаружил волшебную кнопку со звездочками. И это могло значить только одно: вы читаете новый обзор на свежую функцию.

Проверим же, насколько она полезна.

Привет, Хабр! В связи с последними событиями бизнес крепко задумался — где безопасно разворачивать ИТ‑системы, чтобы они стабильно работали? Популярность набирают самые разные идеи, от подземных ЦОДов до полного и окончательного on‑premise. А что если бэкапиться в облаке, но вынести данные далеко‑далеко, за тридевять земель — за границу… Законно ли это? И как все обустроить?

Мы собрали пять вопросов, которые чаще всего задают про резервирование за рубежом, и попросили ответить наших экспертов: ИТ‑директора OXYGEN Александра Будкина и эксперта по работе с госорганами Филиппа Новикова. Какие данные можно отправить за рубеж уже сейчас, что делать с ПДн, сколько времени займет бэкап данных в условный Узбекистан? Разбираемся!

30 сентября 2026 года облачный сервис Structurizr прекратил работу. Для команд, которые хранили там C4-модели, это не просто закрытие ещё одного SaaS: вместе с хостингом исчез привычный способ публиковать архитектуру, раздавать доступ коллегам и встраивать диаграммы в другие системы.

Это статья о том как мы делали модуль автономного выполнения целей в корпоративном ИИ-ассистенте KW-7 AI.

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

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

В этом материале рассмотрим, как Uncloud обновляет сервисы и проверяет новые контейнеры, доставляет Docker-образы, управляет размещением workload, что происходит со stateful-приложениями, как передаются чувствительные данные и как мы можем отслеживать состояние кластера. Также разберём ограничения этой модели —  в большей степени они определяют, для каких задач Uncloud действительно подходит, а где уже стоит смотреть в сторону иных решений.

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

Выяснилась классическая вещь: до 40% запросов от пользователей или внутренних сервисов — это чистой воды дубли. Люди по десять раз переспрашивают у модели схожие аналитические промты, а фронтенд-модули тоннами гоняют идентичные запросы к гео-кодерам. Первая мысль — давайте закроемся кэшем. Но тут мы упёрлись в архитектурный тупик.

Почему Nginx и классические прокси здесь не помощники

Обычно для кэширования трафика берут Nginx, Varnish или HAProxy. Но все они создавались для классического веба, где правит бал GET-запрос, а уникальным ключом кэширования выступает URL.

Современные ИИ-модели и гео-сервисы работают строго через POST. Внутри тела (payload) лежит тяжелый JSON. И этот JSON постоянно мутирует:

Как передать приложению настройки и пароли, не пересобирая Docker-образ? Разбираем ConfigMap и Secret на примере shop-api: переменные окружения, файлы внутри контейнера, обновление конфигурации и почему Base64 — не шифрование.

19 октября в пяти уже выпущенных релизах официального CLI OVHcloud полтора часа лежал стилер вместо настоящих бинарников. Хеши на странице релиза подменили вместе с архивами, install.sh их не проверяет вовсе. Поймал атаку клиент, у которого в CI был жёстко прописан SHA-256, а пользователей Homebrew защитил хеш в cask. Я прошёл по следам сам: аккаунт, через который залили файлы, угнали ещё в марте, загрузчик в его репозиториях спрятан в 9123 невидимых символах Unicode, а адрес следующей стадии он берёт из memo в блокчейне Solana. Там же нашлась чужая запись «I know you» — и уязвимость самого тайника.

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

Привет, Хабр! Это команда интернет‑газеты о сервисном бизнесе «Заявка закрыта» – проекта Okdesk, платформы для управления заявками, выездным обслуживанием и ТОиР. Мы регулярно делимся практическими материалами, которые помогают сервисным компаниям работать эффективнее и зарабатывать больше – без лишней теории и воды. Если вы уже знакомы с нами, то наверняка знаете, как мы относимся к ведению учёта заявок на поддержку, ТО и ремонт в Excel, почте и мессенджерах (спойлер: плохо).

Разговор с вендором, который приносит на маркетплейс ИИ-агента, почти всегда начинается с цены за миллион токенов. Вендор знает ее наизусть, он сравнивал ее с конкурентами и выбрал модель на 30% дешевле. Потом я задаю один вопрос: сколько стоит один решенный тикет вашего агента? И в разговоре нависает пауза.

Я могу ее объяснить. Цена токена остается единственным числом, которое написано в прайсе. Все остальное приходится считать самому, а считать неприятно, потому что результат обычно не похож на слайд.

Ниже я разбираю модельный кейс с полной арифметикой: из чего складывается цена одного полезного ответа, почему токены в ней занимают 5% и что это меняет для тех, кто продает ИИ-сервис, а не только покупает его.

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

В октябре беспилотники за четыре дня выбили три дата-центра Яндекса. Через пять дней после первого удара наш прод уже жил на собственной платформе: три зоны у разных провайдеров, контрольный узел в Амстердаме (чтобы было) и ни одного managed-сервиса.

Всем привет, меня зовут Вадим Лазук, я разработчик в команде VPC облака MWS Cloud. Пару месяцев назад мы запустили в Preview сервис Network Load Balancer, а в этой статье решили рассказать о нём подробнее. Сегодня рассмотрим, как устроен балансировщик в нашем облаке, на какой архитектуре он базируется и какие технологии использует под капотом.

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

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

В редакции МТС мы недавно разбирали проблему нейрослопа. Теперь на этом примере посмотрим, что за новая опция плейлистов появилась в MWS TeamStream и чем она отличается от привычных папок и пространств.

Сперва напомню, что такое MWS TeamStream. Это видеоплатформа для бизнеса с ИИ: вместо бесконечных созвонов вы записываете видео с экрана (при необходимости с собой в кадре) и комментируете происходящее. Сервис делает ИИ-расшифровку, интерактивные субтитры с таймкодами, саммари и много прочих удобных фич. Подробный обзор сервиса я уже делал. Если вы с TeamStream не знакомы, вам туда.

8-11 октября после атак беспилотников пострадали три дата-центра Яндекса: Сасово, Калуга и Владимир. 11 октября Яндекс отключил в веб-версии Диска скачивание папок, альбомов и нескольких файлов сразу. У меня на Диске 1,8 TB файлов и еще около 160 GB фото в безлимите. Терять это не хочется, так что я сел делать бэкап.

План был простой: rclone, VPS в Нидерландах, Google Drive на 2 TB. На деле почти каждый шаг уперся в какую-то особенность Яндекса. Ниже по порядку: что сломалось, какие цифры получились и как обошел. Скрипты и инструкции выложил на GitHub, ссылка в конце.

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

С ростом объемов данных каждый пользователь рано или поздно приходит к мысли о необходимости домашнего сервера. Посмотрев на цены готовых Synology, я решил собирать систему сам на базе XPenology. Первую итерацию собрал из старого ПК, пылившегося в кладовке. Установил операционную систему, и опыт её использования превзошел все мои ожидания. Система оказалась очень удобной, функциональной, а главное — совершенно не требовательной к ресурсам. На древнем железе: сокете LGA1156 с процессором Celeron G6950 и 4 ГБ оперативной памяти всё просто летало, а ресурсы процессора в штатных задачах использовались всего на 10–20%. Лежавшие без дела 4 HDD по 1 Тб обрели новую жизнь, а объединение их в RAID 5 и использование контроллера на 2,5 Гбит/с позволило добиться стабильных скоростей чтения и записи более 280 Мбайт/с.

Но главной болью стал огромный корпус, ровесник железу. Собранный NAS занимал слишком много места, его было невозможно лаконично вписать в интерьер, спрятать в шкаф или поставить на полку. Вторая проблема заключалась в том, что подобрать компактный вариант корпуса под 4–5 дисков практически невозможно, недорогие китайские компьютерные коробки из фольги превращают массив из 4–5 жестких дисков в адский оркестр, который гудит на всю квартиру. Сделать качественную виброизоляцию для дисков в готовом ПК‑корпусе удается редко. В итоге постоянные вибрации плохо сказываются как на долговечности самих HDD, так и на акустическом комфорте. Покупка готового фабричного кастомного корпуса под сервер стоит как крыло самолета. Но даже за высокую стоимость найти компактный вариант с продуманной виброизоляцией дисков — это большая проблема.

Disclaimer: статья проверена по документации и репозиторию Uncloud для стабильной версии v0.20.0. Проект активно развивается, поэтому отдельные CLI-команды и Compose-возможности могут меняться между релизами.

Как всегда, всё начинается со специфического запроса от Заказчика: «Мы хотим забыть Kubernetes как страшный сон и вернуться к Docker Compose!».

На этом месте, наверное, многие DevOps-инженеры с пониманием улыбнутся. 

Но после ещё было: «Только, пожалуйста, сделайте так, чтобы было возможно масштабирование. И ещё бесшовное обновление приложений! Но чтобы остался Docker Compose».

В этот момент становится понятно, что задача перестает быть тривиальной.

А если оставить Docker Compose, но добавить к нему часть возможностей, ради которых в подобных сценариях начинают рассматривать Kubernetes? Оказывается, можно. Есть целый класс промежуточных решений: Docker Swarm, Nomad, Kamal, различные PaaS-инструменты, собственные deployment-скрипты. И еще — Uncloud.

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

Сегодня я проверю, можно ли с помощью MWS Tables полностью синхронизировать форму заявок, таблицу их хранения/контроля и таск-трекер в едином сервисе (спойлер: можно). 

«Три зоны доступности» внутри одного облака не спасают, когда отказывает само облако. Собираем S3, который переживает отказ провайдера: один endpoint для приложения, за ним несколько облаков, переезд без простоя и без правок в коде. Всё на rclone — union, combine и serve s3. Два режима: старое облако работает или после аварии отдаёт данные только на чтение.