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

Мы за системность. К такому подходу в 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 для доступа к ней
  

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

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

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

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