Превращаем ИТ-блок в стратегический актив

Ситуация

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

Что сделали

• Проведена классификация данных и внедрена политика хранения
• Определены окна доступности данных: оперативные данные для поиска и устранения неисправностей и исторические данные для аудита
• Внедрена процедура автоматического переноса данных. Актуальные журналы остаются на быстрых дисках в пределах операционного окна. Данные старше установленного срока переносятся в архивное хранилище
• Настроено автоматическое удаление данных, срок хранения которых истёк

Результат

• Стоимость хранения журналов снижена в 3 раза за счёт переноса исторических данных из дорогого хранилища в дешёвое
• Остановлен неконтролируемый рост объёма данных на дорогой инфраструктуре
• Цикл разбора инцидентов не изменился. Актуальные журналы доступны на быстрых дисках в пределах операционного окна
• Исторические данные сохранены в архивном хранилище и доступны по запросу

Ситуация

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

Что сделали

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

Результат

• Запас производительности базы данных восстановлен без расширения серверов за счёт выноса тяжёлой нагрузки на реплику и кэш
• Деградация операций в пиковые часы устранена. Время отклика стабилизировано
• Транзакции и тяжёлые отчёты разнесены по разным базам данных, что исключило конкуренцию за ресурсы
• Оперативные данные читаются из мастер-базы данных, неоперативные – из реплики, а справочные – из кэша, что снизило общую нагрузку на кластер БД

Ситуация

История операций за 20 лет хранилась в рабочей базе данных вместе с оперативными данными. База данных росла, под неё наращивались серверные мощности и диски, резервное копирование перестало укладываться в ночное технологическое окно. В ходе аудита дополнительно выявили, что персональные данные, подпадающие под ФЗ-152, хранились бессрочно, что создавало риск штрафа по ст. 13.11 КоАП.

Что сделали

В оперативной БД внедрено партиционирование таблиц по временным периодам. Это позволяет отключать старые партиции от регулярных запросов и выполнять их массовое удаление из «горячего» хранилища. Выгруженные данные переносятся в холодное архивное хранилище, доступ к которому осуществляется по запросу. Для соблюдения ФЗ-152 настроены политики хранения: записи с персональными данными автоматически выгружаются в архив и удаляются из оперативной БД по достижении установленных законом сроков.

Результат

• Объём оперативной базы данных сокращён на 65% благодаря архивации исторических данных
• Исключён риск штрафов по ч. 6 ст. 13.11 КоАП: сроки хранения персональных данных по ФЗ-152 соблюдаются автоматически, факты удаления фиксируются в системных логах

Ситуация

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

Что сделали

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

Результат

• Снижен отток клиентов – время оформления сокращено до минимума
• Текущие мощности обслуживают в 2 раза больше заказов без дополнительных инвестиций в инфраструктуру
• Сбои во внешних сервисах больше не блокируют оформление, обработка автоматически повторяется, сохраняя стабильность системы

Ситуация

Около сорока систем обменивались данными напрямую через синхронные запросы (точка-точка). Любое изменение в одном компоненте создавало риск каскадных отказов у соседних, а сетевая задержка в одном из компонентов приводила к остановке работы всей цепочки. Каждая новая интеграция требовала написания уникального связующего кода, связанность росла, а поддержка превращалась в постоянный рефакторинг, что замедляло развитие.

Что сделали

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

Результат

• Временные сбои больше не останавливают работу всей системы. Если один сервис стал недоступен, данные сохраняются в очереди и обрабатываются автоматически после восстановления
• Подключение новых партнёров и запуск новых функций сократилось с нескольких месяцев до нескольких недель. Команды используют готовые стандарты, а не пишут связующий код с нуля
• Добавление 41-й системы требует настройки нескольких новых подписок, а не переписывания ещё сорока соединений
• Сопровождение распределённых кластеров выполняется текущей инфраструктурной командой по единому регламенту, включая плановые обновления узлов без остановки бизнес-процессов. Это исключает появление «бутылочного горлышка» в виде центральной команды архитекторов

Ситуация

Производственная система на Delphi использовалась для управления цехом, но стала бутылочным горлышком. Любое изменение в коде несло риск остановки конвейера, так как система напрямую управляла контроллерами через специфические библиотеки. Специалистов на рынке мало, их поддержка обходилась в 1,5–2 раза дороже рыночной нормы, а устаревший стек не позволял интегрировать современное оборудование. Стоимость простоя производства исчислялась миллионами в час, поэтому фактически любые доработки в системе были заморожены.

Что сделали

• По результатам аудита был спроектирован и сейчас сопровождается поэтапный процесс вывода платформы из эксплуатации без риска для производства
• Старый код на Delphi был объявлен «хрупким ядром» – любые изменения в нём требуют сложной процедуры согласования и полноценных испытаний на стенде
• Спроектирован и запущен в эксплуатацию слой трансляции данных. Он в реальном времени зеркалирует состояние цеха из старой базы данных в новую, не нарушая работу legacy-системы
• Все новые функции (аналитика, мобильные интерфейсы для мастеров, интеграция с современным оборудованием) разрабатываются на современном стеке как независимые сервисы, опираясь на данные из слоя трансляции данных
• Критическое управление приводами остаётся на Delphi до полной стабилизации новой системы, а периферийные модули переносятся на новый стек по мере плановых доработок под строгим контролем архитектурного комитета

Результат

• Производство уже получает новые цифровые сервисы (например, планшеты для мастеров) без риска остановки цеха. Скорость внедрения инноваций растёт, так как новые команды работают на современном стеке и больше не стоят в очереди к команде Delphi
• Единовременные инвестиции в миграцию довольно высоки, но они зафиксированы бюджетом проекта. Расходы на поддержку ядра на Delphi сохраняются, но больше не растут
• Критическое управление станками остаётся в проверенном временем коде. Риск аварии при внедрении новой ИТ-системы сведён к минимуму
• Совокупная стоимость владения (TCO) начнёт снижаться только после вывода критических модулей из эксплуатации. На данном этапе компания платит за поддержку обеих платформ, однако с каждым перенесённым периферийным модулем зависимость от устаревшей платформы и риски простоя уменьшаются

Ситуация

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

Что сделали

• По результатам аудита спроектирована и внедрена распределённая схема с осознанным принятием рисков
• Второй ЦОД в другом регионе введён в эксплуатацию с постоянной асинхронной репликацией базы данных. Это сохранило высокую скорость записи данных, но потребовало зафиксировать окно возможной потери данных (RPO) в несколько секунд
• Для исключения эффекта Split Brain внедрён кворум-механизм в независимом сетевом сегменте, который автоматически определяет главную площадку (master)
• Спроектирован и автоматизирован регламент переключения
• Проведены учения в технологическое окно с полной имитацией отказа: команда физически выключила основной ЦОД, замерив фактическое время восстановления

Результат

• Гарантированное время восстановления сокращено с суток до десятков минут. Это подтверждено фактическими замерами на учениях
• Бизнес застрахован от полной остановки. В случае катастрофы процессы возобновятся в течение получаса, а не нескольких дней
• Платформа больше не зависит от одного провайдера облачной инфраструктуры. Проблема единой точки отказа на уровне площадки решена