Всем добрый вечер!
Интенсивность запусков у нас меняется от месяца к месяцу. Не успели сентябрьские студенты закончить второй месяц курса «Devops — практики и инструменты», как у нас открывается следующий поток. Так что мы снова готовы делиться с вами полезными материалами по теме и ждём на не менее полезных открытых уроках.
Сегодня мы рассмотрим первую часть статьи о том как документация позволяет SRE-командам управлять новыми и существующими сервисами.
SRE (site reliability engineering, примерно переводится как “обеспечение надежности информационных систем”, специалисты этой сферы носят ту же аббревиатуру) — особая дисциплина, мышление и набор технических подходов, направленных на обеспечение безотказной работы веб-продуктов и сервисов. SRE находятся на стыке разработки ПО и системной инженерии, решают эксплуатационные задачи и разрабатывают масштабируемые, надежные и эффективные решения для проектирования, создания и эксплуатации крупномасштабных распределенных систем.
Основные задачи SRE:
Внимание SRE направлено на жизненный цикл сервисов: от идеи и дизайна к развертыванию, эксплуатации, улучшению работы и, в конечном итоге, выводу из эксплуатации.
Перед запуском сервиса SRE поддерживают его, осуществляя консультирование в сфере архитектуры системы, разрабатывают платформы ПО, фреймворки и планы мощностей, проводят обзор запуска.
Когда сервис уже запущен, SRE поддерживают его следующим образом:
Когда жизнь сервиса подходит к концу, SRE выводят его из эксплуатации предсказуемым образом с четким объяснением и полной документацией.
В зрелой SRE-команде всегда есть полноценная документация для каждой функции SRE. Если вы управляете SRE-командой или планируете ее организовать, эта статья поможет разобраться в типах документации, необходимых вашей команде, что позволит спланировать и расставить приоритеты в работе над документацией параллельно с другими задачами команды.
Прежде чем обсудить нюансы SRE-документации, посмотрим на день из жизни Зоуи, новоиспеченной SRE.
Идет вторая смена Зоуи в роле SRE на флагманском проекте AcmeSale в Acme Inc. Пока она только адаптируется в команде, наблюдает за работой своих коллег и делает заметки. Но теперь у нее еще есть пейджер.
Как назло, пейджер звонит в 2:30 утра. В сообщении написано “Джоб Ragnarok откинулся”, Зоуи понятия не имеет, что это значит. Она листает свои заметки и находит ссылку на страницу главного дашборда. Все выглядит ОК. Она пытается найти в интранете Acme какой-либо документ, ссылающийся на Ragnarok, и спустя несколько драгоценных минут находит устаревший документ по архитектуре сервиса, который оказывается критической зависимостью для AcmeSale.
К счастью, в диздоке есть ссылка на страницу «Ragnarok Ops», на которой нашлась ссылка на дашборд с полезными графиками. Также на странице упоминается скрипт ragtool, вероятно способный помочь с решением проблемы, но Зоуи слышит о нем впервые. Поэтому она отправляет запрос о помощи на пейджер другому SRE с многолетним опытом в этом сервисе и инструментах. К сожалению, ответа нет. Зоуи проверяет почту и видит сообщение, что ее коллега оффлайн на целый час из-за проблем со здоровьем. Взвесив все за и против, она звонит своему техлиду, но звонок уходит в голосовую почту. Все говорит о том, что придется решить эту задачу самостоятельно.
Потратив некоторое время на поиски информации о таинственном скрипте ragtool, она находит документ с кратким описанием его параметров командной строки, а также где его можно найти. Она запускает ragtool —restart и в надежде скрещивает пальцы. Ничего не меняется, трафик падает еще сильнее. Она отчаянно просматривает остальные параметры командной строки, но не уверена, что они не навредят еще больше. Наконец, она решает использовать ragtool —rebalance e—dc=atlanta, потому что по графикам понятно, что проблема заметна особенно сильно именно в дата-центре Атланты. График трафика начинает медленно ползти вверх, и Зоуи радуется победе. MTTR (mean time to repair, среднее время восстановления сервиса до рабочего состояния) составляет 45 минут.
На следующий день Зоуи проводит постмортем-обсуждение этого инцидента. Все потому, что проблема оказалась особо крупной и обернулась потерей дохода, плюс менеджер просит проводить больше постмортемов. Она спрашивает команду, как бы остальные ее участники решили эту проблему, и слышит три разных подхода. Оказывается, единого процесса устранения неполадок просто не существует. Также ее коллеги признают, что уведомление “откинулся” — не самое лучшее название, а сбой произошел из-за известного бага, который просто не был приоритетным.
Наконец, Стив, ее техлид, спрашивает: “Какую версию ragtool ты брала?”, а затем отмечает, что использованная версия ужасно старая. Новая версия вышла неделю назад вместе с совершенно новой документацией, описывающей все фичи и даже объясняющей, как решить проблему “Джоб Ragnarok откинулся”. Эта версия бы снизила MTTR до пяти минут.
Существование новой версии ragtool оказывается сюрпризом для половины команды, в то время как другая половина более-менее знает о новой версии и гайде. Последняя версия скрипта лежит в домашней директории Стива, очевидно, в папке bin/. Зоуи добавляет это в свои заметки для будущего использования, надеясь спокойно доработать остаток смены. Она размышляет, разберется ли техлид или кто-либо из команды с проблемами, которые обсуждались на постмортеме, или же всем будущим SRE придется пережить такой болезненный опыт.
Позже в этот день Зоуи участвует во встрече, где команда SRE общается с командой разработки о передаче обслуживания сервиса. Стив руководит встречей, задает несколько поставленных ранее вопросов об экусплутационных процедурах и текущей проблеме надежности сервиса, просит разработчиков внести изменения, прежде чем команда SRE сможет взять на себя ответственность за сервис. Зоуи уже была на нескольких митингах, которые проводили Стив и другие старшие SRE. Она понимает, что заданные вопросы и задачи, распределенные по разработчикам, сильно различаются, в зависимости от того, кто проводит встречу, и с какой проблемой разбиралась команда SRE на прошлой неделе.
Зоуи тайно мечтает о более последовательных стандартах и процедурах, но пока не понимает, как прийти к этой цели. Позже она слышит, как два разработчика смеются около кофемашины, что многие вопросы были слабо связаны с пейджером, и они вообще не понимают, откуда они взялись. Зоуи мечтает, чтобы разработчики поняли, что SRE не только носят с собой пейджер. Вернувшись на рабочее место, Зоуи находит несколько тикетов, которые нужно разобрать, и больше не задумывается об этом.
К счастью, все персонажи и события этой истории выдуманы. Тем не менее подумайте, а не похоже ли это на что-то, с чем вы сталкивались в реальности. Решение проблем этой выдуманной команды совсем очевидно, и в следующем разделе мы обсудим его подробнее.
На ранних этапах существования команды SRE организация сильно зависит от работы отдельных высококвалифицированных личностей внутри команды. Команда хранит важные концепции и принципы эксплуатации как крупицы “племенных знаний”, устно передающихся новым членам команды. Если эти принципы не унифицировать и не задокументировать, скорее всего, в какой-то момент придется их болезненно учить заново методом проб и ошибок. Иногда члены команды выполняют эксплуатационные процедуры как строгую последовательность шагов, определенных их предшественниками в далеком прошлом, даже не понимая причинно-следственные связи этих шагов. Если это не пресечь, процессы становятся фрагментированными и дегенерируют, стоит лишь команде начать расти для решения новых задач.
Команда SRE может предотвратить этот процесс, создав качественную документацию, которая послужит фундаментом для роста таких команд и внедрения системного подхода в управлении новыми и незнакомыми сервисами. Эти документы сохраняют племенные знания в том виде, в котором их легко находить, поддерживать и осуществлять по ним поиск. Новые члены команды проходят обучение с помощью систематизированной и продуманной программы. Это отличительные черты зрелой команды SRE.
В оставшейся части статьи описываются различные типа документов, которые SRE создают в течение жизненного цикла поддерживаемого сервиса.
THE END
В следующей части рассмотрим все эти типы в подробностях, а пока что ждём ваши комментарии и вопрос, а так же приглашаем на открытый урок.
Интенсивность запусков у нас меняется от месяца к месяцу. Не успели сентябрьские студенты закончить второй месяц курса «Devops — практики и инструменты», как у нас открывается следующий поток. Так что мы снова готовы делиться с вами полезными материалами по теме и ждём на не менее полезных открытых уроках.
Сегодня мы рассмотрим первую часть статьи о том как документация позволяет SRE-командам управлять новыми и существующими сервисами.
SRE (site reliability engineering, примерно переводится как “обеспечение надежности информационных систем”, специалисты этой сферы носят ту же аббревиатуру) — особая дисциплина, мышление и набор технических подходов, направленных на обеспечение безотказной работы веб-продуктов и сервисов. SRE находятся на стыке разработки ПО и системной инженерии, решают эксплуатационные задачи и разрабатывают масштабируемые, надежные и эффективные решения для проектирования, создания и эксплуатации крупномасштабных распределенных систем.
Основные задачи SRE:
- Мониторинг и сбор метрик — определение желаемого поведения сервиса, изучение действительного поведения сервиса и устранение различий.
- Реагирование на инциденты — обнаружение и эффективное реагирование на сбои сервиса, чтобы сохранить соответствие доступности сервиса с его SLA (service-level agreement, соглашение об уровне услуг).
- Планирование мощностей — прогнозирование будущего спроса и обеспечение нужного количества вычислительных ресурсов в соответствующих локациях для удовлетворения этого спроса.
- Масштабирование сервиса — предсказуемое развертывание и удаление вычислительных мощностей сервиса в дата-центре, часто как следствие планирования мощностей.
- Управление изменениями — изменение поведения сервиса без потери его надежности.
- Производительность — проектирование, разработка и инжиниринг, связанные с масштабированием, изоляцией, задержками, пропускной способностью и эффективностью.
Внимание SRE направлено на жизненный цикл сервисов: от идеи и дизайна к развертыванию, эксплуатации, улучшению работы и, в конечном итоге, выводу из эксплуатации.
Перед запуском сервиса SRE поддерживают его, осуществляя консультирование в сфере архитектуры системы, разрабатывают платформы ПО, фреймворки и планы мощностей, проводят обзор запуска.
Когда сервис уже запущен, SRE поддерживают его следующим образом:
- Измеряют и мониторят доступность, задержки и общее состояние системы.
- Проверяют запланированные изменения системы.
- Масштабируют устойчивость системы с помощью некоторых механизмов, например, автоматизации.
- Улучшают систему, продвигая изменения, направленные на повышение надежности и скорости.
- Проводят реагирование на инциденты и “безобвинительные” постмортемы.
Когда жизнь сервиса подходит к концу, SRE выводят его из эксплуатации предсказуемым образом с четким объяснением и полной документацией.
В зрелой SRE-команде всегда есть полноценная документация для каждой функции SRE. Если вы управляете SRE-командой или планируете ее организовать, эта статья поможет разобраться в типах документации, необходимых вашей команде, что позволит спланировать и расставить приоритеты в работе над документацией параллельно с другими задачами команды.
История SRE
Прежде чем обсудить нюансы SRE-документации, посмотрим на день из жизни Зоуи, новоиспеченной SRE.
Идет вторая смена Зоуи в роле SRE на флагманском проекте AcmeSale в Acme Inc. Пока она только адаптируется в команде, наблюдает за работой своих коллег и делает заметки. Но теперь у нее еще есть пейджер.
Как назло, пейджер звонит в 2:30 утра. В сообщении написано “Джоб Ragnarok откинулся”, Зоуи понятия не имеет, что это значит. Она листает свои заметки и находит ссылку на страницу главного дашборда. Все выглядит ОК. Она пытается найти в интранете Acme какой-либо документ, ссылающийся на Ragnarok, и спустя несколько драгоценных минут находит устаревший документ по архитектуре сервиса, который оказывается критической зависимостью для AcmeSale.
К счастью, в диздоке есть ссылка на страницу «Ragnarok Ops», на которой нашлась ссылка на дашборд с полезными графиками. Также на странице упоминается скрипт ragtool, вероятно способный помочь с решением проблемы, но Зоуи слышит о нем впервые. Поэтому она отправляет запрос о помощи на пейджер другому SRE с многолетним опытом в этом сервисе и инструментах. К сожалению, ответа нет. Зоуи проверяет почту и видит сообщение, что ее коллега оффлайн на целый час из-за проблем со здоровьем. Взвесив все за и против, она звонит своему техлиду, но звонок уходит в голосовую почту. Все говорит о том, что придется решить эту задачу самостоятельно.
Потратив некоторое время на поиски информации о таинственном скрипте ragtool, она находит документ с кратким описанием его параметров командной строки, а также где его можно найти. Она запускает ragtool —restart и в надежде скрещивает пальцы. Ничего не меняется, трафик падает еще сильнее. Она отчаянно просматривает остальные параметры командной строки, но не уверена, что они не навредят еще больше. Наконец, она решает использовать ragtool —rebalance e—dc=atlanta, потому что по графикам понятно, что проблема заметна особенно сильно именно в дата-центре Атланты. График трафика начинает медленно ползти вверх, и Зоуи радуется победе. MTTR (mean time to repair, среднее время восстановления сервиса до рабочего состояния) составляет 45 минут.
На следующий день Зоуи проводит постмортем-обсуждение этого инцидента. Все потому, что проблема оказалась особо крупной и обернулась потерей дохода, плюс менеджер просит проводить больше постмортемов. Она спрашивает команду, как бы остальные ее участники решили эту проблему, и слышит три разных подхода. Оказывается, единого процесса устранения неполадок просто не существует. Также ее коллеги признают, что уведомление “откинулся” — не самое лучшее название, а сбой произошел из-за известного бага, который просто не был приоритетным.
Наконец, Стив, ее техлид, спрашивает: “Какую версию ragtool ты брала?”, а затем отмечает, что использованная версия ужасно старая. Новая версия вышла неделю назад вместе с совершенно новой документацией, описывающей все фичи и даже объясняющей, как решить проблему “Джоб Ragnarok откинулся”. Эта версия бы снизила MTTR до пяти минут.
Существование новой версии ragtool оказывается сюрпризом для половины команды, в то время как другая половина более-менее знает о новой версии и гайде. Последняя версия скрипта лежит в домашней директории Стива, очевидно, в папке bin/. Зоуи добавляет это в свои заметки для будущего использования, надеясь спокойно доработать остаток смены. Она размышляет, разберется ли техлид или кто-либо из команды с проблемами, которые обсуждались на постмортеме, или же всем будущим SRE придется пережить такой болезненный опыт.
Позже в этот день Зоуи участвует во встрече, где команда SRE общается с командой разработки о передаче обслуживания сервиса. Стив руководит встречей, задает несколько поставленных ранее вопросов об экусплутационных процедурах и текущей проблеме надежности сервиса, просит разработчиков внести изменения, прежде чем команда SRE сможет взять на себя ответственность за сервис. Зоуи уже была на нескольких митингах, которые проводили Стив и другие старшие SRE. Она понимает, что заданные вопросы и задачи, распределенные по разработчикам, сильно различаются, в зависимости от того, кто проводит встречу, и с какой проблемой разбиралась команда SRE на прошлой неделе.
Зоуи тайно мечтает о более последовательных стандартах и процедурах, но пока не понимает, как прийти к этой цели. Позже она слышит, как два разработчика смеются около кофемашины, что многие вопросы были слабо связаны с пейджером, и они вообще не понимают, откуда они взялись. Зоуи мечтает, чтобы разработчики поняли, что SRE не только носят с собой пейджер. Вернувшись на рабочее место, Зоуи находит несколько тикетов, которые нужно разобрать, и больше не задумывается об этом.
К счастью, все персонажи и события этой истории выдуманы. Тем не менее подумайте, а не похоже ли это на что-то, с чем вы сталкивались в реальности. Решение проблем этой выдуманной команды совсем очевидно, и в следующем разделе мы обсудим его подробнее.
Важность документации
На ранних этапах существования команды SRE организация сильно зависит от работы отдельных высококвалифицированных личностей внутри команды. Команда хранит важные концепции и принципы эксплуатации как крупицы “племенных знаний”, устно передающихся новым членам команды. Если эти принципы не унифицировать и не задокументировать, скорее всего, в какой-то момент придется их болезненно учить заново методом проб и ошибок. Иногда члены команды выполняют эксплуатационные процедуры как строгую последовательность шагов, определенных их предшественниками в далеком прошлом, даже не понимая причинно-следственные связи этих шагов. Если это не пресечь, процессы становятся фрагментированными и дегенерируют, стоит лишь команде начать расти для решения новых задач.
Команда SRE может предотвратить этот процесс, создав качественную документацию, которая послужит фундаментом для роста таких команд и внедрения системного подхода в управлении новыми и незнакомыми сервисами. Эти документы сохраняют племенные знания в том виде, в котором их легко находить, поддерживать и осуществлять по ним поиск. Новые члены команды проходят обучение с помощью систематизированной и продуманной программы. Это отличительные черты зрелой команды SRE.
В оставшейся части статьи описываются различные типа документов, которые SRE создают в течение жизненного цикла поддерживаемого сервиса.
THE END
В следующей части рассмотрим все эти типы в подробностях, а пока что ждём ваши комментарии и вопрос, а так же приглашаем на открытый урок.
