Как не допустить лавинообразного отказа информационных сервисов облачной ИТ инфраструктуры?

Мы за системность. К такому подходу в Git in Sky пришли через ошибки заказчиков и свои. Оказалось, что выработать системный подход к поддержке инфраструктуры довольно просто, а вот результатом пренебрежения им часто становятся лавинообразные отказы информационных сервисов, потеря данных и миллионные убытки. Расскажем о системности, как способе обеспечения стабильности IT-среды в компании, но вначале — типовой кейс.

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

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

• отсутствовала система сквозного мониторинга (информация о состоянии инфраструктуры собиралась из десятков консолей и веб-интерфейсов);
• не производилось обновление встроенного программного обеспечения аппаратных компонентов облака;
• документация об архитектуре SAN и LAN сетей не содержалась в актуальном состоянии и была, фактически, неточной;
• в отсутствии актуальной документации неизбежно накапливались ошибки в конфигурировании оборудования, сетей и системы виртуализации.

При этом интенсивность использования информационных сервисов и объемы обрабатываемой информации постоянно увеличивались. Отсутствие системности в поддержании инфраструктуры и накопленные ошибки конфигурации привели к тому, что совпадение некоторых условий приводило к зависанию аппаратных компонентов инфраструктуры облака, в результате чего прерывалась работа от 10 до 90% информационных сервисов заказчика. К моменту обращения компании в Git in Sky, внутренняя IT-служба заказчика безуспешно пыталась решить проблему отказов инфраструктуры около двух месяцев.

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

В рамках решения поставленной задачи было выполнено следующее:

Работы были выполнены в течение двух месяцев. В результате была стабилизирована работа всех систем виртуализации и как следствие всей инфраструктуры. Однако из-за постоянных сбоев произошло логическое повреждение данных в одной из больших БД, и сохранить эту БД не удалось. Из-за нестабильности резервные копии этой БД также оказались повреждены. Восстановление Б Д выполнялось вручную силами заказчика, стоимость ручного восстановления данных составила примерно 680 000 рублей. Системная ежегодная техническая поддержка как услуга, предотвращающая подобные инциденты, стоила бы заказчику около 24 000 рублей в год.

Ниже мы сформулировали тезисы, на которые опираемся при проектировании и поддержке инфраструктур наших клиентов. Это основные процессы системного подхода:

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

Расскажем, на что важно обращать внимание в каждом из этих процессов.

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

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

Важно следить за бизнес-метриками. При наличии SLA сервиса необходимо автоматически следить за его исполнением. Наглядное отображение показателей SLA в системе мониторинга снижает вероятность возникновения негатива со стороны клиента.

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

Резервное копирование — это процесс создания копии данных, предназначенной для их восстановления в случае повреждения или утери основного набора данных.

Стратегия резервного копирования выбирается, исходя из конкретных бизнес-требований и возможностей конкретного заказчика. В отсутствии специальных требований, мы рекомендуем действовать по простой и надежной стратегии 3−2-1: необходимо иметь три копии данных на минимум двух разных типах носителей, при этом одна из копий должна находиться за пределами компании.

Резервные копии в облаке — хорошая современная практика, но для хранения резервных копий стоит использовать не то же самое облако, в котором размещен основной набор защищаемых данных.

Технические решения резервного копирования определяются на основании политики резервного копирования конкретной компании. Она включает:

Отдельной полезной практикой является написание DR (Disaster Recovery) планов, описывающих продуманный и проверенный сценарий восстановления из резервных копий всех важных данных.

Своевременное обновление программного обеспечения решает две серьезные проблемы:

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

Примеры из практики

Уязвимости. 12 мая 2017 г. в мире началась эпидемия вируса-вымогателя WannaCry. Патч от компании Microsoft, закрывающий уязвимость в протоколе SMB v1, которую эксплуатировал вирус, был доступен уже 17 мая 2017 года. Но так как многие частные пользователи и компании не управляют установкой обновлений безопасности на свои устройства, компьютеры с зашифрованными вирусом дисками мы встречаем до сих пор.

Обновления. В одном из наших проектов клиенту было необходимо обновить почтовую систему на базе MS Exchange до актуальной версии, чтобы иметь возможность получать обновления безопасности. Так как регулярной установкой обновлений и новых версий ПО компания не занималась несколько лет, сложилась ситуация, когда для проведения простой операции нужно было в сжатые сроки обновить сервера Exchange с версии 2007 на 2013, затем поднять версии MS Office на нескольких тысячах рабочих мест пользователей и только потом обновить почтовую систему до MS Exchange 2019, которая находится на поддержке вендора.

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

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

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

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

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

Технические средства обеспечения безопасности крайне разнообразны. Масштаб и сложность решений зависят от объекта защиты, его ценности и состава.

Мы разработали общие решения, которые применяются по умолчанию и в большинстве случаев достаточны. Вот они:

• использование актуальных версий операционных систем и сервисов, регулярная установка обновлений
• автоматизированное управление пакетными фильтрами, минимизация доступов (открыто только то, что нужно)
• автоматизация управления доступами сотрудников к инфраструктуре
• мониторинг событий ИБ (подозрительная активность, попытки подбора паролей)
• при любой возможности стараемся уводить взаимодействие между элементами инфраструктуры в приватную сеть и использовать VPN для доступа к ней

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

Самые уязвимые места инфраструктуры — участки, реализованные по принципу «пусть пока так, потом переделаем нормально».

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

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