Хабрахабр

[Перевод] Почему важна SRE-документация. Ч.1

Всем добрый вечер!

Не успели сентябрьские студенты закончить второй месяц курса «Devops — практики и инструменты», как у нас открывается следующий поток. Интенсивность запусков у нас меняется от месяца к месяцу. Так что мы снова готовы делиться с вами полезными материалами по теме и ждём на не менее полезных открытых уроках.

Сегодня мы рассмотрим первую часть статьи о том как документация позволяет SRE-командам управлять новыми и существующими сервисами.

SRE находятся на стыке разработки ПО и системной инженерии, решают эксплуатационные задачи и разрабатывают масштабируемые, надежные и эффективные решения для проектирования, создания и эксплуатации крупномасштабных распределенных систем. SRE (site reliability engineering, примерно переводится как “обеспечение надежности информационных систем”, специалисты этой сферы носят ту же аббревиатуру) — особая дисциплина, мышление и набор технических подходов, направленных на обеспечение безотказной работы веб-продуктов и сервисов.

Основные задачи SRE:

  • Мониторинг и сбор метрик — определение желаемого поведения сервиса, изучение действительного поведения сервиса и устранение различий.
  • Реагирование на инциденты — обнаружение и эффективное реагирование на сбои сервиса, чтобы сохранить соответствие доступности сервиса с его SLA (service-level agreement, соглашение об уровне услуг).
  • Планирование мощностей — прогнозирование будущего спроса и обеспечение нужного количества вычислительных ресурсов в соответствующих локациях для удовлетворения этого спроса.
  • Масштабирование сервиса — предсказуемое развертывание и удаление вычислительных мощностей сервиса в дата-центре, часто как следствие планирования мощностей.
  • Управление изменениями — изменение поведения сервиса без потери его надежности.
  • Производительность — проектирование, разработка и инжиниринг, связанные с масштабированием, изоляцией, задержками, пропускной способностью и эффективностью.

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

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

Когда сервис уже запущен, SRE поддерживают его следующим образом:

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

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

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

История SRE

Прежде чем обсудить нюансы SRE-документации, посмотрим на день из жизни Зоуи, новоиспеченной SRE.

Пока она только адаптируется в команде, наблюдает за работой своих коллег и делает заметки. Идет вторая смена Зоуи в роле SRE на флагманском проекте AcmeSale в Acme Inc. Но теперь у нее еще есть пейджер.

В сообщении написано “Джоб Ragnarok откинулся”, Зоуи понятия не имеет, что это значит. Как назло, пейджер звонит в 2:30 утра. Все выглядит ОК. Она листает свои заметки и находит ссылку на страницу главного дашборда. Она пытается найти в интранете Acme какой-либо документ, ссылающийся на Ragnarok, и спустя несколько драгоценных минут находит устаревший документ по архитектуре сервиса, который оказывается критической зависимостью для AcmeSale.

Также на странице упоминается скрипт ragtool, вероятно способный помочь с решением проблемы, но Зоуи слышит о нем впервые. К счастью, в диздоке есть ссылка на страницу «Ragnarok Ops», на которой нашлась ссылка на дашборд с полезными графиками. К сожалению, ответа нет. Поэтому она отправляет запрос о помощи на пейджер другому SRE с многолетним опытом в этом сервисе и инструментах. Взвесив все за и против, она звонит своему техлиду, но звонок уходит в голосовую почту. Зоуи проверяет почту и видит сообщение, что ее коллега оффлайн на целый час из-за проблем со здоровьем. Все говорит о том, что придется решить эту задачу самостоятельно.

Она запускает ragtool —restart и в надежде скрещивает пальцы. Потратив некоторое время на поиски информации о таинственном скрипте ragtool, она находит документ с кратким описанием его параметров командной строки, а также где его можно найти. Она отчаянно просматривает остальные параметры командной строки, но не уверена, что они не навредят еще больше. Ничего не меняется, трафик падает еще сильнее. График трафика начинает медленно ползти вверх, и Зоуи радуется победе. Наконец, она решает использовать ragtool —rebalance e—dc=atlanta, потому что по графикам понятно, что проблема заметна особенно сильно именно в дата-центре Атланты. MTTR (mean time to repair, среднее время восстановления сервиса до рабочего состояния) составляет 45 минут.

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

Новая версия вышла неделю назад вместе с совершенно новой документацией, описывающей все фичи и даже объясняющей, как решить проблему “Джоб Ragnarok откинулся”. Наконец, Стив, ее техлид, спрашивает: “Какую версию ragtool ты брала?”, а затем отмечает, что использованная версия ужасно старая. Эта версия бы снизила MTTR до пяти минут.

Последняя версия скрипта лежит в домашней директории Стива, очевидно, в папке bin/. Существование новой версии ragtool оказывается сюрпризом для половины команды, в то время как другая половина более-менее знает о новой версии и гайде. Она размышляет, разберется ли техлид или кто-либо из команды с проблемами, которые обсуждались на постмортеме, или же всем будущим SRE придется пережить такой болезненный опыт.
Позже в этот день Зоуи участвует во встрече, где команда SRE общается с командой разработки о передаче обслуживания сервиса. Зоуи добавляет это в свои заметки для будущего использования, надеясь спокойно доработать остаток смены. Зоуи уже была на нескольких митингах, которые проводили Стив и другие старшие SRE. Стив руководит встречей, задает несколько поставленных ранее вопросов об экусплутационных процедурах и текущей проблеме надежности сервиса, просит разработчиков внести изменения, прежде чем команда SRE сможет взять на себя ответственность за сервис. Она понимает, что заданные вопросы и задачи, распределенные по разработчикам, сильно различаются, в зависимости от того, кто проводит встречу, и с какой проблемой разбиралась команда SRE на прошлой неделе.

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

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

Важность документации

На ранних этапах существования команды SRE организация сильно зависит от работы отдельных высококвалифицированных личностей внутри команды. Команда хранит важные концепции и принципы эксплуатации как крупицы “племенных знаний”, устно передающихся новым членам команды. Если эти принципы не унифицировать и не задокументировать, скорее всего, в какой-то момент придется их болезненно учить заново методом проб и ошибок. Иногда члены команды выполняют эксплуатационные процедуры как строгую последовательность шагов, определенных их предшественниками в далеком прошлом, даже не понимая причинно-следственные связи этих шагов. Если это не пресечь, процессы становятся фрагментированными и дегенерируют, стоит лишь команде начать расти для решения новых задач.

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

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

THE END

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

Теги
Показать больше

Похожие статьи

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть