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

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

Что можно потерять, если не следить за инфраструктурой 3 года

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

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

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

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

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

Каким должен быть системный подход к эксплуатации ИТ-инфраструктуры компании

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

1. Превентивный мониторинг ИТ-инфраструктуры

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

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

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

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

2. Резервное копирование

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

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

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

Технические решения резервного копирования определяются на основании политики резервного копирования конкретной компании. Она включает:
Объекты резервного копирования
Определив, какие данные нуждаются в резервном копировании, а какие нет, можно выбрать стратегию, техническую реализацию и не тратить ресурсы на хранение некритичных данных.
RPO (Recovery Point Objective)
RPO (Recovery Point Objective): момент в прошлом, на который можно восстановить данные. Является основанием для выбора глубины хранения и стратегии ротации резервных копий.
RTO (Recovery Time Objective)
RTO (Recovery Time Objective): время восстановления до выбранного состояния данных. Является основанием для выбора технических решений для хранения резервных копий.
Отдельной полезной практикой является написание DR (Disaster Recovery) планов, описывающих продуманный и проверенный сценарий восстановления из резервных копий всех важных данных.

3. Обновление программного обеспечения

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

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

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

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

4. Логирование (ведение журналов)

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

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

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

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

5. Безопасность

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

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

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

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

Сравнительная таблица стоимости услуг по ежегодной системной IT-поддержке со стоимостью устранения аварии

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

Что предлагает Git in Sky

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

Не пропустите последние новости. Подписывайтесь!
Made on
Tilda