«У нас всё работает» — эту фразу бизнес и облачный провайдер могут произносить одновременно во время одного и того же сбоя. Пока стороны ищут источник проблемы, компании теряют выручку и пользователей. Разбираемся, кто за что отвечает в облаке и как избежать таких ситуаций.
- 1. Введение
- 2. Переход в облако: ожидания и реальность
- 3. Где проходит граница ответственности
- 4. Что нужно знать при переходе в облако
- 5. Выводы
Введение
Представьте обычный вечер: люди заказывают цветы, подарки, еду. И вдруг сервис начинает сбоить. Например, каталог открывается, а оплата не проходит. Или приложение виснет, хотя сайт работает. Пока разработчики проверяют свои части системы и пытаются понять, где именно проблема, бизнес теряет заказы буквально в режиме реального времени.
В такие моменты почти всегда возникает вопрос: а кто вообще за это отвечает? Многие уверены, что если всё работает в облаке, то разбираться должен облачный провайдер. Но на практике граница ответственности проходит совсем не там, где её обычно представляют. Сегодня поговорим о том, как устроено это разделение и почему непонимание простого вопроса: кто за что отвечает — может дорого обойтись.
Рисунок 1. Участники подкаста
Чтобы разобраться, мы позвали двух экспертов, которые смотрят на эту проблему с разных сторон. Один работает на стороне облачного провайдера и каждый день видит, с какими ожиданиями и заблуждениями приходят клиенты. Второй отвечает за безопасность и инфраструктуру со стороны бизнеса и хорошо знает, как эти ожидания сталкиваются с реальностью. Вместе попробуем понять, где заканчивается зона ответственности облака и начинается ответственность самой компании.
Участники подкаста:
Иван Гузев, руководитель центра развития безопасности облачной инфраструктуры и сервисов «МегаФон ПроБизнес». Помогает компаниям выстраивать облачную безопасность и ежедневно сталкивается с ситуациями, когда бизнес не до конца понимает границы своей ответственности в облаке.
Дмитрий Шестернин, технический директор Flowwow — маркетплейса цветов и подарков с постоянно высокой нагрузкой, где любая инфраструктурная проблема напрямую превращается в потерянные деньги, заказы и ухудшение пользовательского опыта.
Ведущая и модератор эфира — Олеся Афанасьева, генеральный продюсер, специальный корреспондент «АМ Медиа».
Переход в облако: ожидания и реальность
Компании переходят в облако по вполне практическим причинам. Во-первых, это снимает необходимость обслуживать собственную инфраструктуру и держать штат специалистов для поддержки серверов. Во-вторых, облако даёт гибкость: мощности можно быстро увеличивать и уменьшать под нагрузку, особенно в периоды резких всплесков спроса вроде праздников или крупных распродаж.
Но вместе с этим меняется и восприятие рисков. На старте многие компании не слишком глубоко погружаются в вопросы надёжности и гарантий со стороны провайдера. Цена ошибки здесь невысока: даже если сервис упал, он часто быстро восстанавливается и почти не влияет на бизнес. По мере роста ситуация меняется. Когда простой начинает стоить денег и клиентов, требования к инфраструктуре становятся жёстче. Компании начинают внимательно смотреть на соглашение об уровне сервиса (Service Level Agreement, SLA), условия ответственности провайдера и собственную архитектуру.
Как меняются причины инцидентов по мере роста бизнеса
Дмитрий Шестернин поделился, что на начальном этапе работы с инфраструктурой Flowwow примерно 99 % всех инцидентов были связаны с причинами на их стороне. С точки зрения эксплуатации это ожидаемая ситуация: система ещё небольшая, архитектура проще, а команда напрямую влияет практически на все изменения. В таких условиях цена ошибки и цена простоя остаются низкими. Нет необходимости глубоко разбирать каждый инцидент: если сервис восстановился за 10–15 минут, это часто воспринимается как рабочий сценарий.
По мере роста системы картина меняется. Инфраструктура перестаёт быть набором отдельных сервисов и превращается в распределённую систему из множества компонентов. В таком контуре появляются отказы уже другого типа: не только из-за внутренних ошибок, но и из-за деградации отдельных элементов инфраструктуры, включая компоненты на стороне облачного провайдера. При этом система может продолжать работать за счёт заложенной отказоустойчивости.
Участники подкаста вспомнили один из примеров, когда примерно полтора года назад у одного из крупных облачных провайдеров произошёл отказ целого дата-центра. Инцидент привёл к недоступности значительной части сервисов, включая сервисы российских компаний, использующих данную инфраструктуру. Время недоступности составило порядка 2,5 часа.
После инцидента провайдер провёл публичный разбор ситуации с техническими деталями и ответами на вопросы клиентов. Для пострадавших компаний и технических специалистов были представлены причины отказа, а также меры, направленные на снижение вероятности повторения подобных инцидентов в будущем.
Что бизнес ждёт от облака
Облачные технологии востребованы компаниями практически любого масштаба. Разница заключается не столько в профиле бизнеса, сколько в подходе к выбору провайдера, оценке его возможностей и понимании собственной зоны ответственности за безопасность и отказоустойчивость сервисов.
Как правило, более зрелые компании и представители среднего или крупного бизнеса воспринимают облако как инфраструктурную платформу. Они ожидают от провайдера безопасность на уровне инфраструктуры и виртуализации, а остальные задачи берут на себя: выстраивают резервное копирование, разрабатывают планы восстановления после аварий, внедряют средства защиты информации и самостоятельно управляют значительной частью процессов безопасности.
Небольшие компании чаще приходят в облако с ожиданием, что необходимые функции уже включены в сервис по умолчанию. По мере накопления опыта и понимания особенностей облачной модели они начинают подключать дополнительные сервисы информационной безопасности и более осознанно подходить к вопросам защиты.
Где проходит граница ответственности
Когда возникает инцидент, причина далеко не всегда очевидна. Если речь не идёт о полном отказе сервиса, команда сначала проверяет собственную инфраструктуру, приложение и все доступные точки контроля. Лишь после того как внутренние версии исчерпаны, появляется обоснованное предположение, что проблема может находиться на стороне облачного провайдера.
В таких случаях клиент создаёт обращение и передаёт провайдеру собранные данные: описание проблемы, результаты проверок и признаки того, что источник сбоя может находиться в облачной инфраструктуре. Если ситуация выглядит критичной, к процессу дополнительно подключаются персональные менеджеры и технические специалисты со стороны провайдера.
Сам процесс расследования редко бывает простым. Иван Гузев отметил, что провайдер не видит внутреннюю инфраструктуру клиента, а клиент не имеет доступа к внутреннему устройству облачной платформы. Каждая сторона анализирует только свою часть системы. Именно поэтому поиск причины иногда затягивается: обе стороны уверены, что на их участке всё работает корректно.
Нередко клиент приходит с уверенностью, что проблема находится в облаке. Однако в процессе расследования выясняется, что причиной инцидента становится программное обеспечение, настройки или другие изменения на стороне самого клиента. По внутренней статистике провайдера, на такие случаи приходится около 80–90 % обращений.
Дмитрий Шестернин: «Я двумя руками за практику, когда провайдер подключает своих архитекторов, которые работают в связке со специалистами клиента. Она действительно работает. Архитектор уже погружён в контекст клиента и понимает, как устроена его инфраструктура, поэтому многие проблемы удаётся решить гораздо быстрее».
Дмитрий Шестернин, технический директор Flowwow
Отдельно эксперты затронули тему соответствия требованиям информационной безопасности. Среди клиентов до сих пор распространено мнение, что размещение системы на сертифицированной или аттестованной облачной платформе автоматически решает все вопросы взаимодействия с регуляторами. На практике это не так: использование такой платформы не освобождает компанию от необходимости подтверждать соответствие собственной информационной системы.
Наличие у провайдера необходимых сертификатов и аттестатов заметно упрощает эту задачу. Часть требований уже реализована и подтверждена на уровне облачной платформы, поэтому компании не приходится выстраивать все процессы с нуля. Ответственность за собственную систему сохраняется, но объём работ по подготовке и подтверждению соответствия становится меньше.
Самые частые причины инцидентов
Среди наиболее распространённых причин инцидентов эксперты выделили несколько категорий:
- Проблемы сетевой связанности. Один компонент системы не может установить соединение с другим, из-за чего нарушается работа сервиса. Такие ситуации часто воспринимаются как проблема на стороне облачного провайдера, однако в ходе расследования нередко выясняется, что причина находится в настройках или инфраструктуре самого клиента.
- Ошибки в настройке сетевой инфраструктуры. Если часть сетевых устройств находится под управлением клиента, источник сбоя может находиться именно там, даже если первоначально подозрение падает на облачного или телеком-провайдера.
- Ошибки в управлении доступом. Часто связаны с недостаточным пониманием зон ответственности и особенностей эксплуатации облачной инфраструктуры.
Главный вывод заключается в том, что по внешним признакам определить источник проблемы обычно невозможно. Одинаково похожие симптомы могут возникать как из-за ошибок на стороне клиента, так и из-за инцидентов в инфраструктуре провайдера. Поэтому для определения зоны ответственности всегда требуется технический анализ причин сбоя.
Зоны ответственности
Разговор о зонах ответственности во время подкаста затронул другой вопрос: что именно считать ответственностью. Для бизнеса последствия инцидента измеряются потерями от простоя. Если платформа недоступна, компания теряет заказы, выручку и клиентов. При этом финансовые потери бизнеса могут многократно превышать стоимость самих облачных услуг. Именно поэтому у заказчиков нередко возникает вопрос: должен ли провайдер компенсировать ущерб, если причиной сбоя стала его инфраструктура.
Провайдер выделил здесь 3 уровня ответственности:
- Технический. На этом уровне стороны заранее определяют, кто отвечает за конкретные элементы инфраструктуры: сеть, диски, виртуализацию, операционные системы, базы данных и другие компоненты. Чем подробнее зафиксированы эти зоны ответственности, тем меньше спорных ситуаций возникает во время инцидентов.
- Юридический. Даже если данные размещены в облаке, ответственность за собственную информационную систему и связанные с ней риски в большинстве случаев остаётся на стороне заказчика. Эта модель во многом определяется действующим законодательством и условиями договора.
- Соглашение об уровне сервиса (Service Level Agreement, SLA). В нём фиксируются показатели доступности сервисов и ответственность провайдера за их нарушение. При этом компенсации обычно привязаны к стоимости услуг провайдера, а не к объёму потерь бизнеса. Поэтому, если компании важно защититься от финансовых последствий простоя, речь уже идёт о дополнительных механизмах управления рисками, включая страхование.
Иван Гузев: «Взаимодействие между клиентом и провайдером не ограничивается формальными условиями договора. Если бизнес понимает свои периоды повышенной нагрузки или особые требования к доступности сервисов, такие запросы обычно обсуждаются заранее. Провайдеры готовы учитывать подобные особенности: переносить плановые работы, обеспечивать дополнительное присутствие инженеров или выстраивать отдельный порядок взаимодействия на время критически важных периодов для бизнеса».
Иван Гузев, руководитель центра развития безопасности облачной инфраструктуры и сервисов «МегаФон ПроБизнес»
По словам провайдера, ещё до начала работы важно договориться о 3 вещах. Во-первых, какие требования и обязательства закрывает провайдер со своей стороны. Во-вторых, где проходит граница ответственности, поскольку даже при размещении в облаке система остаётся частью информационной системы клиента. В-третьих, как стороны будут действовать при инцидентах: кто участвует в расследовании, как определяется причина проблемы и какая ответственность наступает в каждом конкретном случае.
Почему доверие не менее важно, чем договор
Объём обязательств, порядок взаимодействия и меры ответственности определяются в ходе переговоров между клиентом и провайдером и фиксируются в договорных документах. Но стоит помнить, что устойчивость сервиса зависит не только от технических возможностей облачной платформы, но и от того, насколько хорошо стороны понимают ожидания и ограничения друг друга. В такой модели гораздо важнее не искать виноватого, а выстраивать рабочее взаимодействие ещё до того, как произойдёт инцидент.
Несмотря на важность договоров, на практике многое зависит и от отношений между клиентом и провайдером. По словам участников подкаста, долгосрочное сотрудничество строится не только на выполнении обязательств, но и на готовности сторон идти навстречу друг другу в сложных ситуациях. Например, если у клиента ожидается период повышенной нагрузки, провайдер может перенести плановые работы по обновлениям. В отдельных случаях клиентам предоставляют дополнительные сервисы, в том числе средства защиты от распределённых атак, чтобы помочь справиться с текущими рисками.
Такой подход выгоден обеим сторонам. Для клиента это дополнительная поддержка в критический момент, а для провайдера — возможность выстраивать долгосрочные партнёрские отношения и повышать уровень доверия.
Что нужно знать при переходе в облако
Рекомендации со стороны бизнеса. Необходимо воспринимать облачного провайдера не как внешнего подрядчика, полностью снимающего все вопросы эксплуатации и безопасности, а как партнёра, от которого зависит работа критически важных сервисов.
Для эффективного взаимодействия важно не только хорошо понимать собственную зону ответственности, но и иметь общее представление о том, как устроены процессы на стороне провайдера. Такой подход помогает быстрее решать спорные ситуации, выстраивать рабочие коммуникации и формировать реалистичные ожидания от облачной инфраструктуры. Не менее важна и персональная ответственность специалистов с обеих сторон: она позволяет выстраивать эффективное взаимодействие и совместно решать возникающие проблемы.
Рекомендации со стороны провайдера. Многие проблемы возникают не из-за технологий, а из-за неверных ожиданий. Поэтому ещё на старте провайдеру важно объяснить, какие гарантии получает клиент, где проходят границы ответственности, какие задачи в области безопасности остаются на его стороне и какие риски необходимо учитывать при эксплуатации сервисов.
Что бизнес в любом случае должен контролировать сам?
Бизнес в любом случае должен оставлять за собой роль управленца. Он определяет, что и как размещается в облаке, и принимает ключевые решения при инцидентах. Даже если провайдер предоставляет инструменты мониторинга и управления, финальные действия — выключать систему или нет, открывать или ограничивать доступ — всегда остаются на стороне клиента.
Кроме того, важно понимать границы применимости технологий: облако — это не бесконечные ресурсы. У инфраструктуры есть физические ограничения, и их необходимо учитывать при проектировании системы.
На чём экономят чаще всего, и к каким последствиям это приводит на практике?
Часто экономят на безопасности. Проблема в том, что к вопросам информационной безопасности приходят слишком поздно. Когда возникает проблема, инфраструктура обычно уже сложная и неинвентаризированная, поэтому внедрить в неё полноценную систему защиты становится значительно труднее.
Типичная ошибка — ожидание, что в облаке всё автоматически защищено и резервируется. На самом деле это не так. Например, резервное копирование нужно настраивать отдельно, поскольку при его отсутствии возможны критические последствия, вплоть до полной потери данных.
Также важный момент: ответственность за доступы в большинстве случаев лежит на клиенте. Управление правами, паролями и доступом к системам остаётся зоной ответственности бизнеса, и провайдер не закрывает эти задачи полностью.
Отдельно стоит учитывать защиту от различных атак. Это базовый уровень обеспечения безопасности, а не дополнительная опция.
С какого вопроса правильно начинать знакомство с облачным провайдером?
Никакого волшебного первого вопроса к провайдеру нет. Разговор с ним начинается ещё до встречи: в переписке и первых контактах уже видно очень многое. Поэтому и подход должен быть не про один удачный вопрос, а про набор нормальных рабочих уточнений. Хороший провайдер спокойно это выдерживает: не уходит от ответов, готов объяснять, показывать, предоставлять тестовый период или проводить аудит, чтобы всё можно было проверить на практике.
Выводы
Независимо от того, где размещена инфраструктура и какие сервисы предоставляет облачный провайдер, ответственность перед клиентами и регуляторами остаётся на стороне бизнеса. Именно компания оказывает услугу конечному пользователю и отвечает за её доступность, качество и безопасность.
При этом облачная модель не отменяет ответственности провайдера перед своими заказчиками. Провайдер также остаётся бизнесом со своими обязательствами и рисками. Поэтому устойчивость сервисов во многом определяется не только договорами и технологиями, но и качеством взаимодействия между сторонами. Чем лучше выстроены коммуникации, понятнее распределены зоны ответственности и реалистичнее ожидания друг от друга, тем меньше вероятность того, что инцидент перерастёт в конфликт.
