Облачные сервисы

Когда говорят о забытых ресурсах в облаке, обычно вспоминают старые виртуальные машины. Но сама виртуальная машина далеко не всегда представляет главную проблему. Гораздо интереснее то, что осталось вокруг нее.

Учетная запись или сервисный аккаунт никуда сами по себе не исчезают. Они могут продолжать существовать в AWS, Azure, Active Directory или другой системе. Старый SSH-ключ может оставаться доверенным на действующем сервере. API-токен, который когда-то создали для удаленного приложения, может по-прежнему давать доступ к базе данных или стороннему SaaS. При выводе сервиса из эксплуатации возникает проблема: сам сервис исчезает, а связанные с ним права — нет.

Один из наглядных сценариев связан с захватом поддомена. Представим, что компания запустила облачное приложение и привязала к нему корпоративный поддомен. Через некоторое время проект закрыли. Приложение удалили, однако CNAME-запись в DNS осталась, что для самой организации может выглядеть как остаток старой конфигурации. Для злоумышленника такая запись представляет интерес, потому что она продолжает указывать на место, где раньше находилось приложение.

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

Старые ключи, вебхуки и почта

DNS – только один из вариантов. После вывода сервиса из эксплуатации часто остаются учетные данные: сервисные аккаунты, токены, API-ключи, секреты, сертификаты и SSH-ключи.

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

Та же логика работает с вебхуками. Приложение удалили, а сторонний сервис продолжает отправлять данные на старый endpoint. Если кто-то получит возможность занять соответствующий адрес, данные начинают уходить уже туда.

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

Самые опасные «призраки» могут вообще ничего не делать

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

Активные системы регулярно обновляются, получают security-патчи и подключены к мониторингу. Старый образ виртуальной машины или бэкап трехлетней давности сохраняет конфигурацию и уязвимости того времени, когда его создали.

У забытых копий есть еще одна проблема — они часто находятся вне привычного контура наблюдения. Работающий сервер может быть подключен к SIEM, IDS, IPS и другим системам контроля. Снапшот или выгрузка базы на сетевом диске просто лежат без присмотра.

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

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

Почему автоматизация не спасает от забытых ресурсов

Почему при наличии Terraform, Ansible и другой автоматизации инфраструктура все равно постепенно превращается в «дикий запад»? Одна из главных причин в разрыве между реальным состоянием облака и кодом, который это состояние должен описывать.

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

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

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

У самой автоматизации тоже есть архитектурные ограничения. Тот же Terraform – это не око Саурона. Он работает с ресурсами, которые описаны в его state file.

Есть и динамические ресурсы, так называемые side effects, которые появляются как побочный результат работы других систем. Например, при развертывании Kubernetes-кластера автоматически создаются балансировщики, диски, PVC и другие компоненты. Kubernetes их создает, а Terraform может не знать об их существовании. При удалении кластера такие ресурсы способны остаться в облаке.

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

Главная сложность – понять, что действительно можно удалить

Когда компания начинает искать забытые ресурсы, возникает другая проблема: неактивность еще не означает ненужность. Резервная система может почти не обрабатывать пользовательский трафик и при этом быть критически важной. Например, standby-база должна получать репликацию от основного узла. Если смотреть только на пользовательский трафик, такой ресурс легко принять за заброшенный.

Поэтому нужно обратить внимание и на связи с остальной инфраструктурой. У standby-узла можно проверить входящий трафик репликации. У резервного сервера – обращения систем мониторинга, health check, логи обновлений ОС, работу агентов безопасности и резервного копирования.

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

Дальше стоит посмотреть на окружение ресурса. DNS-записи, IP-адрес, присутствие в пулах балансировщиков, GeoDNS и failover-скриптах, правила Firewall и Security Groups дают гораздо более полную картину. Если к узлу разрешен доступ только с основного сервера приложений по специфическим портам репликации, это может быть признаком disaster recovery-компонента.

Поэтому хороший вопрос при инвентаризации звучит шире, чем «используется ли ресурс сейчас?». Нужно понять, зачем его создали, с чем он связан, и кто отвечает за его существование.

Один из полезных способов смотреть на ресурс – оценивать его как потенциального «сироту». Кто его владелец? Что произошло с исходной системой? Как давно существует объект? Используют ли его другие сервисы, тестовые среды или аналитические системы?

Атакующий может увидеть компанию лучше, чем она сама себя

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

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

Атакующий смотрит на компанию иначе. Для него это единая цель.

Поддомены и IP-адреса видны в публичных источниках, DNS и логах сертификатов. Автоматизированное сканирование позволяет постоянно искать новые активы, поэтому забытый тестовый сервер может оставаться неизвестным внутренней команде и просматриваться из интернета.

Сопоставить внутреннюю картину с внешней позволяют OSINT и EASM – External Attack Surface Management. Например, история выданных сертификатов позволяет обнаружить поддомены, о которых уже забыли ответственные команды. Полученный список стоит сопоставить с внутренней документацией. Если внешний домен отсутствует во внутренней базе, это как минимум указывает на пробел в инвентаризации.

С точки зрения атакующего интерес представляют публичные хранилища, забытые базы данных и снапшоты, compute-инстансы с публичными IP-адресами, старые поддомены и ресурсы с признаками заброшенности. Такими признаками могут быть имена вроде «-test», «-dev», «-old», минимальный трафик, отсутствие обращений к API или базе данных.

Дополнительные вопросы возникают к старым версиям операционных систем и TLS, просроченным сертификатами, сохраненным в конфигурациях секретам, API-ключам, паролям и избыточным правам.

Что происходит после удаления сервиса

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

Сначала проверяется сетевой контур и DNS. Связанные с сервисом DNS-записи должны быть удалены, а домен после этого не должен резолвиться в IP-адрес удаленной инфраструктуры.

Отдельно нужно убедиться, что не осталось CNAME-записи на сторонний облачный сервис. Если ресурс там уже удален, такая запись может создать возможность для захвата поддомена.

Затем проверяются сертификаты и доступы. Если для сервиса выпускался отдельный SSL/TLS-сертификат, его необходимо отозвать через удостоверяющий центр, а статус можно проверить с помощью OpenSSL s_client или SSL Labs.

То же касается SSH-ключей и API-токенов. Нужно посмотреть конфигурационные файлы, authorized_keys на серверах и системы управления доступами. Ключи, созданные специально для конкретного сервиса, после его удаления тоже должны исчезнуть.

Следующий слой – интеграции. Внешние системы не должны продолжать отправлять данные на старый endpoint. Поэтому после удаления нужно проверить вебхуки в сторонних панелях, CRM, Telegram-ботах, GitHub, Stripe и других системах.

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

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

Поверхность атаки – это история всей инфраструктуры

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

Здесь могут использоваться EASM-решения – инструменты класса External Attack Surface Management, которые непрерывно мониторят интернет и уведомляют о появлении новых активов компании.

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

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

***

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

Автор – Антон Грецкий, директор по информационной безопасности ActiveCloud

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

Это объясняет трансформацию формата managed IT (управляемые внешним подрядчиком ИТ-сервисы и инфраструктура). К 2026 году он окончательно стал отдельной моделью эксплуатации инфраструктуры, где вовне передают не только поддержку отдельных систем, как в классическом аутсорсинге, а часть ответственности за устойчивость ландшафта и работу бизнеса.

ИТ-инфраструктура стала (и продолжает становиться) слишком сложной, чтобы компании могли эффективно поддерживать ее исключительно внутренними силами. Kubernetes, гибридные среды, DevOps-практики, мультиоблако, постоянный рост требований к отказоустойчивости и информационной безопасности – все это развивается быстрее, чем бизнес успевает перестраивать собственные процессы и команды.

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

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

Больше, чем аутсорс

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

Поэтому managed IT трансформируется в модель полноценного технологического партнерства. Внешний провайдер все глубже погружается в инфраструктуру заказчика: проводит аудит, изучает особенности ландшафта, участвует в модернизации систем, выстраивает процессы эксплуатации и формирует рекомендации по развитию инфраструктуры. Фактически это продолжение внутреннего ИТ-департамента, особенно в проектах, связанных с высоконагруженными системами, гибридной инфраструктурой или сложными интеграциями, где без погружения невозможно обеспечить стабильную эксплуатацию.

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

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

Что отдать в managed IT

Рынок разделяет два четких сценария использования managed IT. В первом компании передают вовне второстепенные сервисы, чтобы не перегружать внутренний департамент рутинной эксплуатацией. Во втором – наоборот, вовне уходят наиболее сложные и высоконагруженные контуры, для которых бизнесу требуется максимально высокая инженерная экспертиза и зрелость процессов эксплуатации.

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

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

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

Отдельно растет спрос на managed IT в гибридных и мультиоблачных средах. Когда инфраструктура распределяется между несколькими площадками, а часть сервисов остается внутри собственного контура компании, поддерживать все это исключительно внутренними силами значительно сложнее.

Экономика: не только снижение затрат

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

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

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

Дополнительную роль играет и предсказуемость расходов: современные модели managed IT строятся вокруг прозрачных SLA, пакетной модели часов и детализированной отчетности. Для бизнеса это означает возможность заранее понимать объем затрат на эксплуатацию инфраструктуры и управлять ими без постоянного роста внутреннего штата.

Портрет идеального провайдера managed IT

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

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

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

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

На этом фоне облака постепенно превращаются в своеобразные «фабрики инженерных компетенций», которые полностью релевантны и применимы для внешних managed IT-сервисов.

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

Будущее формата

В ближайшие годы managed IT будет развиваться вместе с усложнением самой инфраструктуры. Искусственный интеллект, гибридные среды и мультиоблачные архитектуры не упрощают эксплуатацию ландшафта, а наоборот – делают его еще более распределенным и требовательным к качеству управления. Главный дефицит – способность эффективно управлять сложностью.

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

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

На этом фоне managed IT постепенно превращается в более высокоуровневый сервис. Бизнесу потребуется способность управлять сложной инфраструктурой как единой системой, независимо от того, где физически расположены ресурсы и сколько провайдеров участвует в архитектуре.

Для многих компаний вопрос в ближайшие годы будет звучать уже не «Нужен ли нам managed IT?», а «Сможем ли мы вообще поддерживать свой ландшафт без внешней экспертизы?».

Автор – Алексей Макаркин, директор по продукту DataSpace Cloud

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

Почему бизнесу не подходит «личная» логика

Популярные платформы для облачного хранения данных принято считать «облаком для личного». Но когда речь заходит о бизнесе, те же самые технологии превращаются в сложную, многослойную инфраструктуру. Для частного пользователя хранение данных в облаке – это способ поделиться фотографиями с поездки или не потерять важные документы. Для бизнеса такая логика «снял телефон – залил фото – забыл» не работает. У компании совершенно другие вопросы. Сколько это будет стоить через год, когда данных станет в два раза больше? Как быстро получить доступ к архиву трехлетней давности, если придет налоговая? И главное – как разграничить данные: что хранить в высокодоступном облаке, без чего работа встанет, а что просто должно лежать «на всякий случай»?

По данным аналитики за 2025 год, средняя российская компания ежегодно генерирует около 500 Тбайт данных. Часть из них экономически целесообразно хранить в облаке – это часто дешевле, чем собственная инфраструктура, но безопасность и эффективность напрямую зависят от выбранной модели (публичное, частное или гибридное облако) и политик доступа.

Объекты, блоки и папки – три кита, на которых все держится

Чтобы разобраться, какие облачные хранилища бывают, нужно обратить внимание на два ключевых параметра: как осуществляется доступ к хранилищу и по какой модели оно развернуто. По архитектуре доступа существуют объектные хранилища (например, S3), блочные хранилища и файловые хранилища (такие как NAS).

Объектные хранилища хранят данные в виде «объектов» – это файл, снабженный метаданными и уникальным идентификатором, без привычной файлово-иерархической структуры (то есть не как папки и подпапки, а скорее как таблица с записями, датами создания, редактирования и так далее). Такие хранилища (например, S3) используют для больших объемов неструктурированных данных: медиафайлов, логов, бэкапов, архивов, а также фрагментов кода.

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

Файловые хранилища работают по протоколам NFS, CIFS или SMB и выглядят для пользователя как сетевые папки с иерархией каталогов. Один из самых распространенных примеров – FTP-хранилище, где есть общая файловая папка со структурой и иерархией. Данный тип хранилища удобен для совместной работы с файлами, общих сетевых дисков и резервных копий, когда нужны привычные «обычные» сетевые папки.

Свое, чужое или «все сразу»

Существует еще один подход к классификации облачных хранилищ – по модели развертывания, по среде, в которой это хранилище работает. Здесь обычно выделяют три основных типа: публичное облако, частное облако и гибридную инфраструктуру.

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

Хранилище в частном (приватном) облаке, напротив, полностью контролируется ИТ-персоналом самого заказчика. Такое выделенное облачное хранилище может находиться либо в собственном ЦОДе компании, либо быть частью инфраструктуры облачного провайдера, но изолированной и настроенной индивидуально под заказчика. Для данных под 152-ФЗ и требований ФСТЭК часто требуется именно частное облако с сертифицированным ПО.

Гибридная и мультиоблачная инфраструктура сочетает публичные и частные среды. Например, часть данных компания держит в своем дата-центре, часть загружает в объектное хранилище типа S3, а для совместной работы использует облачную NAS-папку от внешнего провайдера. Такой подход позволяет балансировать между стоимостью, производительностью и требованиями к безопасности данных.

«Горячее», «холодное» и «ледяное» – почему дешевый гигабайт может разорить

Еще один поход к классификации облачных хранилищ связан с уровнем «холодности» данных – то есть с тем, как часто необходимо обращаться к этим данным. Многие облачные провайдеры также делят хранилища по частоте обращения к данным в хранилище.

«Горячее» (standard) хранилище предполагает высокую доступность и частые операции чтения и записи. Именно такие хранилища – самые дорогие в линейке, потому что они рассчитаны на постоянную работу с данными.

«Холодное» (cold) хранилище подходит для хранения данных, к которым нужен редкий доступ. Цена за гигабайт здесь заметно ниже, но провайдер может взимать дополнительную плату за трафик и за количество операций чтения или записи. Именно поэтому дешевый на первый взгляд гигабайт способен разорить компанию, если не учитывать эти скрытые расходы. «Холодное» хранилище идеально подходит для бэкапов.

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

Как не заблудиться в этих трех соснах

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

Первый вопрос – как часто предполагается обращаться к данным? Если каждый день, подойдет только «горячее» хранилище и только блочная архитектура. Если доступ нужен примерно раз в месяц – стоит смотреть в сторону «холодного» и объектного. Если данные требуются «на всякий случай» и лежать будут годами – «ледяное».

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

Третий вопрос – каков бюджет на непредвиденные операции чтения? Многие компании считают только стоимость хранения за гигабайт, забывая про трафик, количество запросов и плату за восстановление данных. Например, «ледяное» хранилище остается дешевым ровно до тех пор, пока из него ничего не достается.

Четвертый и самый важный вопрос – что произойдет, если эти данные исчезнут или станут недоступны на сутки? Ответ на него сразу отсекает половину вариантов. Если исчезновение данных приведет к остановке производства, нельзя экономить ни на классе хранения, ни на модели развертывания. Если же пропажа данных вызовет лишь легкое сожаление – можно смело отправлять их в «ледяное» хранилище.

Вывод

Выбор облачного хранилища для 500 Тбайт – это не вопрос «где дешевле за гигабайт», а баланс трех измерений: архитектуры (объектная, блочная или файловая), модели развертывания (публичное, частное или гибрид) и температурного класса (горячее, холодное или ледяное). Главный риск – забыть про скрытые расходы: трафик, операции чтения и плата за восстановление данных способны превратить дешевый тариф в дорогой. Четыре вопроса (частота доступа, кто и откуда подключается, бюджет на непредвиденные операции, цена простоя) отсекают неподходящие варианты и экономят не только деньги, но и ночной сон администратора.

Автор — Полина Абаимова, менеджер продукта Отдела развития облачных продуктов компании ГК Softline («Софтлайн Решения»)

ИИ и облака

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

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

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

Геополитика. Эпоха «простых и доступных больших облаков», где главные американские гиганты вроде Amazon, Google и Microsoft без особых проблем предоставляли свои сервисы по всему миру, постепенно уходит в прошлое. Европейский бизнес все острее осознает угрозу неконтролируемого роста стоимости, а также опасность ограничения доступа к собственным данным, которые по факту им не контролируется. В результате многие компании начинают консолидироваться вокруг местных поставщиков, пытаясь выстраивать инфраструктуру, меньше зависящую от глобальных гиперскейлеров.

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

На фоне этих факторов формируется сразу несколько отчетливых тенденций:

1. Растущая неуверенность в том, как именно будет развиваться рынок и какие новые барьеры могут появиться.
2. Активные поиски новых решений, а также переход к разработкам, которые обходят продукты гиперскейлеров.
3. Укрепление идеи цифрового суверенитета: страны и компании пытаются взять инфраструктуру и хранение данных под собственный контроль, стремясь избежать внешних рисков и политических ограничений.

Локализация против глобализации

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

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

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

Нынешняя политическая турбулентность, включая действия нового руководства США и прочие резонансные события, продолжает кардинально менять правила игры. Показательно, что, по словам большинства докладчиков, если бы CloudFest проходил всего парой месяцев ранее, фабулы докладов выглядели бы совсем иначе.

Логистика и серверы

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

Кроме того, крупные игроки вроде Intel и AMD представили новые сверхмощные процессоры, в которых насчитывается до 288 физических ядер, при этом энергопотребление составляет всего 500 Вт. Такая эффективность открывает перед облачными провайдерами и крупными центрами обработки данных серьезные возможности для оптимизации: теперь можно разместить то же количество вычислительных ресурсов в половине одного стандартного шкафа вместо, например, четырех. Для экологии это означает меньшее энергопотребление, а для бизнеса — более высокую плотность размещения серверов и экономию на счетах от дата-центров.

Выводы

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

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

Автор — Руслан Райкевич, СТО ActiveCloud (ГК Softline)

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

Основные причины перехода в облака

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

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

Другой тип пользователей облаков – когда бизнес еще нельзя назвать зрелым, но компания готова двигаться в этом направлении и расти. Таким компаниям также подойдут модели публичных и гибридных облаков, где можно гибко использовать ресурсы.

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

Внимание на риски

При построении облака нужно обратить внимание на несколько рисков.

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

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

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

Некоторые облачные операторы предоставляют комбинированные услуги по работе приложений и их защите – включающие компенсацию недостатка людей с нужными компетенциями по выстраиванию процессов: менеджеров SOC или vCISO, продвинутые услуги резервного копирования. Про это нужно своевременно узнать и пользоваться такими опциями.

Если облако обладает набором аттестаций и соответствует требованиям регулятора, препятствий для работы в нем, как правило, нет. В нашей стране наработан опыт размещения в облаках даже государственных информационных систем.

Некоторые российские интеграторы и провайдеры облегчают клиентам задачу перехода в облако, предлагая решения «под ключ» и избавляя заказчиков от необходимости собирать облачную инфраструктуру из доступных на рынке составляющих.

Как спланировать максимально безопасный переход в облако

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

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

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

От чего зависит бюджет на облачную инфраструктуру

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

Сложение потребностей по разным бизнес-продуктам дает прогноз по объемам бюджета на инфраструктуру на краткосрочную и среднесрочную перспективу. Иногда при планировании бюджета закладываются возможности «на вырост», и тут важно понять, какого роста ждать суммарно, и не запланировать излишков.

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

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

Переход в облака работает на имидж

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

Автор – Руслан Иванов, CTO компании ITKey

Трансформация инфраструктуры данных стала для сети «Бургер Кинг» стратегическим вектором развития, открывающим дорогу к принятию решений на основе данных. Переход на Arenadata DB в облаке VK Cloud позволил оптимизировать работу бизнес-систем и сделал возможными решение многих аналитических задач. О реализации проекта и его первых результатах рассказывает Александр Кулиев, директор офиса по данным «Бургер Кинг» и номинант на премию Data Award.

- Что привело «Бургер Кинг» к реализации проекта перестройки инфраструктуры данных?

В 2022 году инфраструктура для работы с данными в «Бургер Кинг» состояла из большого количества разрозненных источников данных и BI-системы, которая, помимо задач визуализации и формирования отчетов, иногда выполняла функции обработки и хранения данных. При этом в компании не было общей методологии сбора, обработки и хранения данных. Данные хранились в разных местах, а их выгрузка для формирования отчетности зачастую занимала много времени и могла негативно сказываться на производительности бизнес-систем.

Перед дата-командой «Бургер Кинг» встала задача – спроектировать и запустить централизованное корпоративное хранилище данных (DWH), которое должно решить существующие на тот момент проблемы и обеспечить потенциал для дальнейшего развития собственной платформы данных и data-driven подхода в целом.

- Какой подход был выбран?

В качестве основного решения для запуска DWH была выбрана Arenadata DB – СУБД на основе Greenplum. Однако ситуацию осложняло то, что у нас не хватало необходимых компетенций для реализации данных задач. При этом хранилище предстояло строить «с нуля», да еще и переводить в новое решение более 800 существующих приложений и множество источников данных. Это повлекло за собой некоторые трудности на старте проекта.

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

Именно поэтому мы изначально рассматривали только облачное решение. В качестве партнера по инфраструктуре выбрали VK Cloud, так как на платформе были все необходимые инструменты для построения и развития решения, в том числе ADB как Managed-решение.

- Что еще было сделано в рамках проекта?

Запуск ADB в облаке значительно сократил время и трудозатраты на запуск решения, и команда смогла сосредоточиться на методологической части и бизнес-логике работы хранилища. Команда провела рефакторинг текущих процессов, чтобы обеспечить плавный переход компании на новые рельсы. Была проведена структуризация данных, сформулирована единая методология работы с данными, объединены справочники и собраны требования со всех контрагентов в компании.

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

- Какие еще решения использовались при построении платформы?

Помимо хранилища данных Arenadata DB в облаке VK Cloud, в качестве витрины данных используется ClickHouse.

- Какие трудности возникали в ходе проекта? Как их решали?

Само по себе отсутствие единого подхода влечет за собой ряд проблем, не только технических, но и процессуальных. В частности, высок риск создания «бутылочных горлышек». Когда данные и аналитические инструменты не интегрированы, процесс принятия решений становится затруднительным и медленным. Решения зависят от ограниченного числа людей, что увеличивает риск создания узких мест в процессах. Чтобы решить эту проблему, на первом этапе проекта мы проработали единую методологию сбора, обработки и хранения данных, и только после этого начали перенос источников данных на новое технологическое решение.

Еще один важный момент – это соответствие нормативным требованиям. Неоднородные данные и процессы затрудняют контроль за соответствием законодательству и стандартам, особенно в отношении защиты данных и конфиденциальности. В нашем случае этот вопрос удалось стандартизировать и упростить путем проработки единой методологии и переносом данных в облако VK Cloud, которое соответствует 152-ФЗ и размещено в ЦОДах Tier III.

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

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

- Каких результатов уже достигли?

После запуска хранилища данных удалось значительно ускорить в ресторанах WFM-систему, которая прогнозирует оптимальное количество сотрудников ресторана на смене. Время просчета оптимального количества сотрудников сократилось радикально – с двух недель до трех часов. Помимо этого, система помогает грамотно сформировать запасы на складах ресторанов.

Также запуск DWH позволил оптимизировать рекомендательные системы для гостей ресторанов, которые рекомендуют клиентам наиболее релевантные позиции в соответствии с их профилем потребления,

Один из самых заметных финансовых эффектов от внедрения достигнут за счет того, что компании удалось убрать нагрузку по обработке данных с систем-источников. Это обеспечило большую производительность, отказоустойчивость и непрерывность бизнес-процессов. Раньше, чтобы получить отчетность по некоторым категориям, приходилось ограничивать доступ к BI на время формирования отчета. Это было весьма критично, с учетом того, что на подобные операции могло уходить до нескольких дней. Теперь система доступна для внутренних пользователей всегда, при этом удалось значительно сократить время получения отчетности.

- Повлияло ли повышение доступности аналитической системы на восприятие аналитики (и работы с данными в целом) пользователями?

С начала 2024 года, сразу после запуска, наш проект уже заметно отразился на бизнес-показателях компании. Мы добились роста эффективности CRM на 3% благодаря персонализации и повышения эффективности бизнес-процессов, а в ресторанной части – на 5%. Это вполне конкретный, понятный бизнесу эффект. Поэтому краткий ответ – да, повлияло.

Однако как я говорил ранее, изменение культуры – это не разовая акция, а постоянный процесс, к которому мы последовательно движемся.

- В чем роль проекта для бизнеса компании?

Роль проекта трансформации инфраструктуры корпоративных данных для компании «Бургер Кинг» – стратегическая. Это значимый этап на пути развития компании, который открывает дорогу к принятию решений на основе данных, а также имеет большое влияние на эффективность бизнеса.

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

- Каковы пути дальнейшего развития проекта?

Реализация облачного DWH и переход на «новые рельсы» позволили заложить фундамент для внедрения новых инструментов. Мы уже сейчас видим огромный потенциал для повышения прибыльности за счет data-driven подхода и планируем развиваться в этом направлении. Следующие шаги – построение озера данных объемом более 500 Тбайт для хранения и обработки сырых и неструктурированных данных, организации песочниц для проведения экспериментов и тестирования бизнес-гипотез, а также для развития и автоматизации проектов Data Science. Параллельно ведутся работы по развертыванию единой ML-платформы для разработки и инференса моделей машинного обучения, а также создания промышленных процессов применения искусственного интеллекта.

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

Ключевые риски, которым подверглись компании в области ИТ-инфраструктуры, и практические подходы по их снижению обсудили в ходе дискуссии «Модернизация инфраструктуры: срочно, качественно, недорого. Чему сегодня отдать приоритет?». Мероприятие состоялось в рамках форума «Цифровая инфраструктура — 2022», организованного издательством «Открытые системы» (см. также статью ««Цифровая инфраструктура 2022»: под флагом импортозамещения».)

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

«Никто не заставляет выбирать два из трех. Всегда речь идет о компромиссах, приемлемых для компании», — отметил Дмитрий Кузеванов, технический директор «Азбуки вкуса». Миграция в облака помогла ретейлеру сократить расходы на 20%, получить устраивающий SLA и ускорить реализацию проектов.

Не «замораживать» инфраструктуру

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

Дмитрий Кузеванов: «Главный риск любого ретейлера — остановка сервисов, и компании уже несколько раз приходилось ‘переобуваться в воздухе’, чтобы поддержать работу бизнеса»

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

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

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

Сергей Зинкевич: «В долгосрочной перспективе работа на неподдерживаемых платформах не приведет к успеху»

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

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

«Железо» с вражескими сервисами

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

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

Сергей Члек: «Вы даже не представляете, насколько сильно продвинулись российские производители серверов на Intel и AMD. Они выкорчевывают весь вражеский сервис вроде платформы удаленного управления и администрирования Intel vPro и оставляют процессорам лишь их профильные задачи»

«Вы даже не представляете, насколько сильно продвинулись российские производители серверов на Intel и AMD. Они выкорчевывают весь вражеский сервис вроде платформы удаленного управления и администрирования Intel vPro и оставляют процессорам лишь их профильные задачи», — подчеркнул Члек. Это позволяет существенно снизить риски.

«’Железо’ в стране есть. Его привозят различными путями, существует много каналов доставки. Исключение составляет разве что нишевое оборудование класса Hi-End», — рассказал Зинкевич. Конечно, к изменениям приходится адаптироваться, но такие проблемы не блокируют работу бизнеса. Другое дело, что вместо движения вперед, которого всем хочется, приходится решать задачи технического долга — реализовывать внутренние проекты, направленные на стабилизацию работы компании.

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

«Помимо оборудования, доступны все виды инфраструктурного ПО: у проприетарных решений всегда были аналоги open source, и сейчас их популярность резко выросла», — отметил Зинкевич. Например, все, кто планировал проекты на Oracle, сейчас без проблем запускают их на PostgreSQL — компетенций на рынке вполне хватает.

Денис Сосновцев, директор по технологическим альянсам Arenadata, напомнил, что, помимо рисков, связанных с оборудованием, существует масса проблем, «спрятанных» внутри решений open source. Не все из них одинаково полезны, широко известны истории о различных закладках в них. «Некоторые из используемых нами продуктов в этом году занялись откровенным вредительством. Пришлось заняться чисткой собственного репозитория», — сообщил Сосновцев.

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

Возможность проявить себя

«Пока мы не начнем целенаправленно заниматься разработкой собственных решений, мы не придем к удовлетворительному результату. Будущее рынка во многом зависит от пользователей. Нужно активно готовить замену импортным решениям, ставить перед производителями задачи и давать возможность проявить себя», — призвал Сосновцев. Он напомнил, что в 2014 году на прилавках магазинов практически не осталось импортных сыров. За несколько лет ассортимент удалось восполнить своими силами, и теперь можно констатировать, что качество российской продукции заметно выросло. Сейчас в ИТ сложилась аналогичная ситуация: огромное количество конкурентов ушло, освободив рынок. Это отличная возможность для наших производителей занять на нем достойное место.

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

Члек признал важнейшую роль реестра отечественного ПО в становлении «нового ИТ-рынка». В реестре есть продукты разной степени импортозамещенности, но все же он стал фильтром, позволяющим использовать не «дикий» open source, а продукты определенной степени очистки.

«Не стоит упрекать регулятора в бездействии. К ‘Росплатформе’ уже два раза предъявляли жесткие требования скорректировать определенные вещи», — заявил Члек. В этом году, впервые за шесть лет существования реестра, регулятор ощутимо «взялся» за дело: подтягивает качество продуктов, гораздо строже относится к их включению в реестр. Кроме того, нужно учитывать отзывы покупателей, сами по себе формирующие рейтинг продукта, и работу интеграторов, которые несут определенную ответственность за внедренные решения. Для компаний созданы все возможности не наткнуться на плохое решение: можно заранее получить о продукте необходимую информацию и протестировать его.

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

Доля отдельных отключений, приводящих к убыткам на сумму свыше 100 тыс. долл., в 2021 году увеличилась до 47% по сравнению с 40%, о которых шла речь годом ранее. Хотя среднюю стоимость одного отключения в Uptime Institute не рассчитывают, общие тенденции указывают на то, что затраты на преодоление последствий такого отключения продолжают расти.

Каждое пятое предприятие сообщило по крайней мере об одном «серьезном» сбое за последние три года. Речь идет об отключениях, которые привели к существенным финансовым потерям, телесным повреждениям, репутационному ущербу или нарушениям требований законодательства. 80% участников опроса сообщили о возникновении у них сбоев в последние три года (без конкретизации уровня их серьезности), что находится на верхней границе нормы.

В отчете отмечается, что наибольшая доля отключений в целом была вызвана проблемами, которые связаны с сетью и могут быть результатом крупномасштабного перехода на облачные технологии, технологии программно-конфигурируемых сетей (software defined networking, SDN) и другие новые сетевые архитектуры.

Но наиболее ощутимые неприятности, как правило, связаны со сбоями в электроснабжении. На них приходится 43% «серьезных» отключений за последние три года.

Согласно отчету, наибольшее количество перебоев в обслуживании в рассматриваемый период наблюдалось у независимых поставщиков услуг. На долю облачных провайдеров, поставщиков услуг хостинга, связи и телекоммуникационных компаний приходится почти две трети всех отключений общедоступных сервисов, которые Uptime Institute отслеживал на протяжении последних семи лет. К 2021 году эти показатели увеличились на 70%.

Многие сбои, независимо от того, на какую часть инфраструктуры они повлияли, стали результатом человеческой ошибки. В последние три года почти 40% предприятий столкнулись с серьезными перебоями в работе, вызванными человеческим фактором. В большинстве случаев они были связаны с неоптимальностью процессов и процедур или их несоблюдением.

По словам основателя и исполнительного директора Uptime Institute Энди Лоуренса, виновата в высоком уровне сбоев (как прямо, так и косвенно) все более сложная архитектура современных ИТ.

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

Отчет Uptime Institute опирается на несколько видов источников — от публичных отчетов о крупных сбоях и результатов специальных опросов до баз данных об аномальных инцидентах, которые ведет компания.

Вступив в цифровые 20-е годы XXI века, предприятия все чаще рассматривают возможность внедрения нового поколения совместно используемых и компонуемых облачных технологий ERP (enterprise resource planning). Это подкрепляется нескончаемой пандемией, ненадежными цепочками поставок, кочующей рабочей силой и другими факторами.

Опрос 1675 руководителей ИТ-служб, организованный Boomi, показал, что подавляющее большинство организаций (94%) используют стратегию ERP нового поколения, которая предусматривает преодоление ограничений унаследованных приложений и модернизацию бизнеса за счет перехода на облачные платформы и профессиональную аналитику, включающую элементы искусственного интеллекта.

По прогнозам Gartner, к 2023 году 65% организаций уже внедрят у себя ERP-приложения, имеющие один или несколько из так называемых «отличительных признаков четвертой эры» информационных систем. К ним относятся искусственный интеллект, архитектура, ориентированная на данные, системы, которые можно использовать в готовом виде, функции, дополняющие решения, средства поддержки разработчиков и технологии, ориентированные на клиента.

«Проблемы последних двух лет склоняют чашу весов в сторону более быстрого внедрения ERP-систем следующего поколения, – отмечается в отчете Boston Consulting Group. – Использовать традиционную систему ERP для управления ожидаемым ростом электронной коммерции и удовлетворения потребностей в гибкости и быстроте будет практически невозможно. Наметилась тенденция к поддержке финансовых, снабженческих и кадровых функций передовыми средствами автоматизации, в которых ставка делается на сокращение числа сотрудников с одновременным повышением уровня их квалификации и на использование работников, решающих возложенные на них задачи из дома».

Перечислим три области, в которых традиционные ERP-системы сегодня терпят неудачу, а также потребности, испытываемые современными предприятиями.

Гибридная рабочая сила

Если какие-то сомнения в отношении перехода на облачную ERP-систему ранее и возникали, то с началом кризиса COVID они были отброшены, и корпоративные рабочие места распределились по бесчисленным домашним офисам. Локальная ERP оказалась не такой масштабируемой, как все думали. И сегодня наблюдается переход к облачным системам, с помощью которых сотрудники решают кадровые, финансовые и бухгалтерские задачи в удаленном режиме.

Недавний опрос Pew Research Center показал, что каждые шесть из десяти работников в США, утверждающих, что их задачи в основном можно решать из дома, трудятся на дому постоянно или большую часть своего времени. По сравнению с 23% «удаленщиков», которые мы наблюдали до пандемии, перемены видны невооруженным глазом.

Согласно опросу Upwork, доля тех, кто занимается фрилансом на постоянной основе, находится на рекордно высоком уровне и составляет 36% от общей численности работников. Большинство из них (53%) предоставляют квалифицированные услуги разработки ПО, маркетинга, ИТ- и бизнес-консалтинга. Годом ранее их доля составляла 50%. Кадровый компонент ERP-систем должен учитывать быстроту найма, непредсказуемость рабочего графика и текучесть кадров. Все больше организаций ищут персонал за рубежом, что наряду с другими факторами заставляет гибко реагировать на новые правила обязательной отчетности, налогообложения и льгот.

Аналитика

Недавние события выявили относительно слабые возможности традиционных систем ERP в части составления отчетов. Предприятия хотят постоянно иметь данные под рукой и принимать решения очень быстро; готовые отчеты ERP-систем многим не подходят. И теперь они прорабатывают функции отчетов, информационных панелей и ключевых показателей эффективности (KPI) в самом начале, на этапе проектирования и выстраивания системы, вместо того чтобы наращивать соответствующие возможности с течением времени.

По словам аналитиков Boston Consulting Group, ERP-платформы следующего поколения обеспечивают компаниям прозрачность в реальном времени в части продаж, запасов, производства и финансовых показателей. Мощная аналитика, основанная на данных, позволяет принимать более гибкие решения, корректируя параметры цепочек поставок для повышения устойчивости. Надежные средства электронной коммерции помогают компаниям лучше взаимодействовать с онлайн-клиентами как при подготовке продаж, так и после их совершения. А минималистичное ядро ERP и облачный подход помогают ускорить развертывание.

Цепочки поставок

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

Опрос, проведенный FiveTran и Dimensional Data, показал, что 86% руководителей хотят обращаться к данным через свои системы ERP в режиме реального времени. Но только 23% респондентов заявили, что их нынешние ERP-системы поддерживают такую возможность, а 99% не могут получить доступ к необходимой им информации.

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

Возможно, этот вопрос покажется странным, но он действительно важен. Наряду с изменением характера использования приложений, облако изменило и типы затрат на их эксплуатацию.

Разные цвета денег

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

Капитальные затраты

Под капитальными затратами (Capital Expenditure, CapEx) обычно понимается покупка физического актива, который, как ожидается, будет использоваться в течение по крайней мере одного года.

Для производственной компании это может быть производственное оборудование. Для других – компьютерное или сетевое оборудование. Сюда можно отнести покупку транспортных средств, зданий или недвижимости.

Для капитальных затрат характерен ряд особенностей.

— Актив стоит относительно дорого. Обычно это одноразовая закупка (но одноразовая закупка может быть сделана в рассрочку).

— Приобретенный актив будет использоваться в течение длительного срока, как правило, несколько лет.

— Такие закупки обычно происходят нерегулярно, зачастую их трудно спланировать, а следовательно, и заложить в бюджет.

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

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

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

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

Постоянные затраты

Постоянные затраты (fixed-cost expenditure) – это покупка товара или услуги, которые потребляются предприятием за короткий период времени, не превышающий одного года. Постоянные затраты предусматривают короткий период использования или приобретение каких-то расходных материалов.

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

Другим примером являются приобретаемые услуги, в том числе услуги по уборке офиса. Коммунальные услуги – электроэнергия и вывоз мусора – также относятся к таким затратам. В области программного обеспечения это применимо к оплате за SaaS-сервисы.

Постоянные затраты обычно не зависят от объемов производства и продаж. Сумма, потраченная на постоянные расходы в течение месяца, как правило, не меняется в зависимости от планируемых или реальных продаж. В то время как постоянные расходы могут стимулировать продажи (например, затраты на целевую рекламную кампанию), сами продажи напрямую не влияют на постоянные затраты. Совершив продажу, вы не покупаете что-либо в рамках постоянных затрат. Обычно постоянные расходы тратятся на выполнение чего-то, что, согласно ожиданиям, приведет к последующим продажам (например, на размещение рекламы).

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

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

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

Себестоимость реализованной продукции

Последним типом затрат являются затраты на себестоимость проданной продукции (cost of goods sold, COGS). Себестоимость может быть непосредственно связана с покупкой товаров или услуг.

Показатели COGS растут при увеличении продаж и снижаются, когда продажи падают. Если ваша компания создает какой-то продукт, стоимость материалов и труда, затраченного на его изготовление, относится именно к COGS.

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

Расходы на себестоимость обычно находятся в прямой зависимости от объема получаемой выручки.

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

Главное, что нужно контролировать – это отношение себестоимости к выручке. Разница между выручкой и себестоимостью становится основным источником получаемой компании прибыли или тех денег, которые она может заработать. Таким образом, цель заключается в том, чтобы поддерживать минимальное соотношение себестоимости к выручке, а общая сумма затрат на себестоимость уже не столь важна.

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

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

ЦОДы и облака

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

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

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

При большом объеме трафика вы выделяете в облаке серверы для его обработки. При снижении трафика серверы освобождаются. То же самое относится к средствам хранения и сетевым ресурсам. Когда вы их используете, вы платите за них. Если они вам не нужны, вы за них не платите.

Затраты на облако непосредственно связаны с выделяемыми вам ресурсами, а следовательно, с вещами, которые генерируют доход – трафик, данные, сетевые компоненты. При росте продаж затраты растут, по мере снижения продаж снижаются и затраты.

Большая часть затрат на строительство облачного ЦОДа считается переменными расходами, которые относятся к категории COGS.

***

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

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

Цвет денег, которые вы тратите, очень важен для вашего облачного опыта.