— Ребят, есть проблема, сервера едят очень много места
Примерно с такого сообщения в групповом чате началась айтишная сделка между двумя бизнесами. Сейчас расскажу, как мы помогли клиенту сэкономить на серверах настолько эффективно, что даже сами себе не угодили.
Предыстория, из которой станет понятно, где вообще нашёлся заказчик с таким запросом.
Я ещё в 22-м году поучаствовал в конкурсе лидеров России. Государство периодически проводит его, чтобы нахантить себе сотрудников — и я подал документы. Конкурс состоит из нескольких этапов — дальше московского мне пробиться не посчастливилось.
Зато встретил много интересных людей! В рамках конкурса меня добавили в несколько чатов, где мы все и перезнакомились (а это топы айтишных отделов крупных компаний). И вот в одном из этих чатов я увидел запрос от одного из участников.
Суть такая: компания «Россети Сибирь» хранит много данных. В основном, это фотографии (jpeg) и документы (pdf). И место на системах хранения данных (СХД) подходит к концу. Запас оставался до конца года — а дальше беда.
Потенциально можно было бы купить новые СХД — но они стоят нереально дорого, т.к. бизнес крупный — и оборудование и софт должны быть отечественными (тут правила диктуют отраслевые и государственные стандарты).
Поэтому разумнее было не увеличивать количество дисков — а сжимать данные.
У текущего подрядчика клиента не было опыта сжатия pdf и картинок, да и вообще какого-либо опыта по уменьшению объёмов хранилищ — вот и пришлось искать кого-то специально под эту задачу. Я тут же предложил нашу помощь — и дело пошло.
Но сначала пара слов обо мне. Меня зовут Михаил Телегин. Я заместитель генерального директора в компании «ОБИТ» и, в основном, занимаюсь стратегическими проектами. Кстати, именно в тот период, о котором я рассказываю, «ОБИТ» как раз активно начал заниматься интеграциями и назвался «оператором ИТ-решений». Поэтому такой проект оказался как нельзя кстати.
Общались в онлайне (да и потом всю работу тоже делали в онлайне, без поездок и личных встреч). У нас была четырёхчасовая разница в поясах — но делу это не помешало.
Сначала сделали и показали пилот
Тут всё просто — клиент прислал большую пачку данных — а мы их сжали и отправили обратно.
На пилот ушло чуть больше двух месяцев. Клиенту всё понравилось — и мы перешли к согласованию основного договора и работе уже на серверах заказчика.
Получилась система, которая после сжатия проверяла, сохраняют ли изображения и документы свою читабельность.
Объясню в двух словах, как это работало.
Для картинок — система брала исходный jpeg и сжимала его три раза с разной степенью. Затем другая система (небольшая нейросеть) анализировала, можно ли прочитать на сжатых изображениях то же, что было на несжатом. И выбирала максимально сжатый читаемый вариант.
С документами было чуть сложнее. Сначала система «разбирала» их на тексты и изображения, затем сжимала картинки и оптимизировала тексты, после чего снова собирала обратно.
В результате удалось уменьшить объём данных на ≈35% процентов. Каждый терабайт сжимался до ≈666 гигабайтов.
Дальше нам нужно было решить две больших задачи
Первая: сжать существующие данные.
Мы пошли по годам. Сжатие проводилось в несколько потоков, по времени получалось по две-три недели на один год.
Из интересного: обратили внимание на то, что некоторые файлы после сжатия не уменьшались, а увеличивались в размере. Поэтому мы допилили систему так, чтобы она автоматически помечала все подобные аномалии и отправляла нам на анализ. Так мы выяснили, что часть данных хранилась в неправильных форматах, и оптимизировали процесс сжатия и для этих случаев.
Вторая задача: сжимать все вновь поступающие данные.
Документы и картинки прилетали из системы, за которую отвечают партнёры-интеграторы компании. Поэтому нам пришлось с ними плотно поработать. Сделали так, что для конечного пользователя ничего не поменялось, всё происходило «за кадром». Сотрудники как отправляли раньше документы — так и продолжили это делать. А наша система ловила их, сжимала и возвращала обратно по той же ссылке.
Мы сделали так, чтобы процедура сжатия происходила не в реальном времени, а только после того, как накопится определённый объём данных. И дали клиенту возможность самостоятельно выбирать, в какие моменты это должно происходить.
Вместе с системой мы отправили подробную проектную документацию, поэтому разобраться можно было и без нас. Единственная рекомендация с нашей стороны была: сжатие лучше запускать по ночам, когда никто не пользуется системой, чтобы не создавать лишней нагрузки. Так что по факту мы сейчас и сами не знаем, какую настройку в итоге выбрал клиент.
В результате наше решение перешло с технического на уровень бизнес-процесса и не требует квалифицированных специалистов для работы.
В конце проекта клиент объявил нашей команде благодарность за проделанную работу как раз в том самом чатике, с которого всё и началось. Из благодарности стало понятно, что ему предлагали свои решения ещё несколько человек оттуда, но я оказался быстрее и увереннее.
В чём же мы себе не угодили? Делая задачу, рассчитывали на то, что будем оказывать техподдержку. Но сделали всё так классно, что техподдержка до сих пор не нужна. Но, кажется, это тот случай, когда оно того стоило.
Подписывайтесь на наш VC-блог и Telegram-канал, чтобы регулярно получать полезную информацию об ИТ для бизнеса.