3 стратегии для минимизации времени простоя

3 ноября, 2017 12:05 пп 2 434 views | Комментариев нет

, | | Комментировать запись

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

Веб-сайт, API или другой недоступный сервис могут принести компании значительные денежные затраты, связанные с потерями продаж. Кроме того, время простоя может стать причиной:

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

Область знаний, предназначенная для решения этих проблем, называется Site Reliability Engineering, или SRE. SRE разрабатывается компанией Google с 2003 года. Разработанные стратегии собраны в одноименную книгу, которая поможет вам изучить методы и популярные практики для минимизации простоев.

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

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

1: Мониторинг и отправка оповещений

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

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

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

Сегодня популярными системами мониторинга являются:

  • Prometheus может извлекать данные с помощью различных официальных и поддерживаемых сообществом клиентов (так называемых экспортеров). Эта система обладает высокой масштабируемостью, имеет встроенную систему оповещений и предлагает клиентские библиотеки для большинства языков программирования.
  • Graphite – это тпопулярный API, который поддерживается десятками приложений и языков программирования. Метрики переносятся с нод на центральный экземпляр Graphite, где они хранятся и отображаются.

Также рекомендуется пересылать на центральный сервер лог-файлы и анализировать их показатели. Стек Elastic (Elasticsearch, Logstash, Kibana) и Graylog – это программное обеспечение, которое может облегчить анализ и централизованное хранение логов.

Какие метрики нужно отслеживать?

Итак, какие метрики нужно собирать и анализировать, чтобы повысить производительность и снизить время простоя сайта?

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

  • Задержка: сколько времени требуется на обработку запроса (например, время ответа сервера на HTTP-запросы).
  • Трафик: насколько востребована ваша система. Это может быть скорость запроса веб-сервера, сетевого ввода-вывода или транзакций базы данных в секунду.
  • Ошибки: частота отказов транзакций или запросов. Имейте в виду, что не все ошибки так же понятны, как ошибка HTTP 500. Например, если вы настроили политику, при которой клиенты должны получать ответы в течение 500 мс, все ответы с более высокой задержкой будут отображаться как ошибка.
  • Насыщение: насколько заполнен сервис. Это может быть измерение свободного места на жестком диске, пропускной способности сети или даже доступного объема CPU.

Визуализация метрик

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

Настройка оповещений

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

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

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

При настройке оповещений следует учитывать такие принципы:

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

Если полученное оповещение не соответствует этим критериям, лучше всего понизить его приоритет, отправить в лог или полностью удалить его.

Читайте также:

2: Развертывание программного обеспечения

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

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

Непрерывная интеграция и поставка

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

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

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

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

Развертывание blue-green

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

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

Весь трафик получает только одна среда. Процесс релиза новой версии выглядит так:

  • Загрузка сборки в неактивную среду.
  • Тестирование сборки в этой среде.
  • Если тест прошел успешно, трафик перенаправляется в среду с новой версией путем обновления настроек балансировщика или присвоения плавающего IP-адреса.

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

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

Читайте также:

3: Высокая доступность

Одной из стратегий минимизации простоев является применение высокой доступности в инфраструктуре. Термин «высокая доступность» включает в себя принципы проектирования избыточных и устойчивых систем. Эти системы обычно нацелены на:

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

Балансировка нагрузки

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

Повышение устойчивости баз данных

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

Примечание: Современные базы данных, такие как CockroachDB, строятся с учетом функций избыточности данных и репликации, что позволяет создать БД с высокой доступностью на нескольких компьютерах в нескольких центрах обработки данных «из коробки».

Плавающие IP-адреса и серверы горячей замены

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

Многие облачные провайдеры предоставляют специальные IP-адреса, которые можно быстро передать другому серверу или балансировщику нагрузки, используя API. Горячая замена – это резервный сервер, который всегда готов к работе, но не получает трафик, пока работает первичный сервер. Когда этот сервер становится неисправным и не проходит проверку состояния, плавающий IP переназначается серверу горячей замены, и трафик идет на другой сервер. Для реализации такой архитектуры необходимо установить и настроить дополнительное программное обеспечение, такое как keepalived или heartbeat.

Читайте также:

Заключение

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

Tags: , , ,

Добавить комментарий