что происходит, когда вы просите инженера-программиста разработать операционную функцию

Вдохновение для написания этой статьи пришло после недавних дебатов с одним из моих друзей о том, «каково настоящее значение термина« Разработка надежности сайтов »(SRE)» в мире облачных вычислений. Цель этой статьи - развенчать основные концепции SRE.

Я изо всех сил старался давать ссылки и ссылки на первоисточники и авторов.

Что такое SRE?

По сути, что происходит, когда вы просите инженера-программиста разработать операционную функцию - Бен Трейнор, вице-президент по разработке Google

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

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

Команда SRE

Команда SRE отвечает за задержки, производительность, эффективность, управление изменениями, мониторинг, реагирование на чрезвычайные ситуации и планирование емкости

Обычно сочетание 50–50 человек, имеющих больше опыта в области программного обеспечения, и людей, имеющих больше опыта в системах, будет действительно хорошим сочетанием для команды SRE.

Мифы и недоразумения

  • Бюджет ошибок Целевой показатель 100% надежности практически для всего
  • Перейти от 5 9 к 100% надежности непросто. Это незаметно для большинства пользователей и требует огромных усилий.
  • SRE позаботится обо всех аспектах надежности приложения. Установите цель, которая признает компромисс и оставляет ошибку в бюджете
  • Целью команды SRE не является «нулевое отключение» - SRE и разработчики продуктов заинтересованы в том, чтобы тратить бюджет на ошибки, чтобы получить максимальную скорость работы функций.
  • Мониторинг никогда не должен требовать, чтобы человек интерпретировал какую-либо часть области оповещения; тем не менее, Предупреждение: человек должен действовать немедленно, а Тикет: человек должен принять меры в конечном итоге.

19-факторный стандарт для SRE

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

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

  • Управление изменениями: 70% простоев из-за изменений в действующей системе.
  • Принятие риска. Если пользователь использует смартфон с надежностью 99%, он не может определить разницу между надежностью 99,99% и 99,999%.
  • Цели уровня обслуживания: разные классы услуг должны иметь разные показатели.
  • Избавление от тяжелого труда: если оператору нужно прикоснуться к вашей системе во время нормальной работы, у вас есть ошибка.
  • Мониторинг распределенных систем: правила, которые генерируют предупреждения для людей, должны быть простыми для понимания и отражать явный сбой.
  • Эволюция автоматизации. Автоматизация - это умножитель сил, а не лекарство
  • Разработка версий: инженеры по выпуску работают с SWE и SRE, чтобы определить, как будет выпущено программное обеспечение.
  • Простота ( стабильность или гибкость) : мы не можем сказать, что произошло, если мы выпустили 100 изменений вместе.
  • Изменение данных временного ряда: общий формат данных для регистрации.
  • Дежурство по вызову. Иногда люди несколько раз подряд дежурят по вызову очень грубо, и в течение года они случайным образом уравновешиваются.
  • Учения по реагированию на чрезвычайные ситуации: экстренная ситуация, вызванная испытаниями
  • Эффективное устранение неполадок. В журналах следящей системы время восстановления увеличивается. Нужен правильный набор инструментов для эффективного устранения неполадок
  • Посмертная культура: безупречное вскрытие и извлечение уроков из неудач
  • Балансировка нагрузки в центре обработки данных: простой контроль потока для нездоровых задач.
  • Устранение каскадных сбоев. Не выполняйте работу, если были пропущены крайние сроки (распространенная тема для каскадных сбоев). Использование крайних сроков вместо тайм-аутов - это здорово
  • Целостность данных: 99,99% хороших байтов в файле размером 2 ГБ означает повреждение 200 КБ. Наверное, не подходит для большинства приложений
  • Глубокая защита: если хакер получает доступ к системе, эта функция сводит к минимуму негативное воздействие и дает инженерам время для развертывания обновленных контрмер, чтобы предотвратить повторение.
  • Проверка надежности. Стабильность измерения во времени.
  • Интеграция через точки подключения: безопасное соединение с партнерами, клиентами и несколькими облаками с помощью точек подключения.

В следующих статьях мы рассмотрим именно это: практические шаги для перехода к SRE и роль 19-факторных стандартов для SRE. Будьте на связи.

Ссылка:

Разработка надежности сайта - как Google управляет производственными системами

Архитектура, ориентированная на межсоединения

-Венкат

«Я сотрудник Equinix. Мнения, выраженные здесь, являются моими собственными и не обязательно отражают мнение Equinix »