Добрый вечер всем! Интенсивность наших запусков меняется от месяца к месяцу.
Сентябрьские студенты не успели закончить второй месяц курса «Девопс – практики и инструменты» , когда мы открываем следующий поток.
Так что мы снова готовы поделиться с вами полезными материалами по теме и ждем не менее полезных.
Сегодня мы рассмотрим первую часть статьи о том, как документация позволяет командам SRE управлять новыми и существующими сервисами.
SRE (site надежность инжиниринга, грубо переводится как «обеспечение надежности информационных систем», такую же аббревиатуру носят специалисты в этой области) — это особая дисциплина, мышление и совокупность технических подходов, направленных на обеспечение безаварийной работы веб-продуктов и услуги.
SRE находятся на стыке разработки программного обеспечения и системной инженерии, решая операционные проблемы и разрабатывая масштабируемые, надежные и эффективные решения для проектирования, построения и эксплуатации крупномасштабных распределенных систем.
Основные задачи СР?: 
- Мониторинг и сбор метрик — определение желаемого поведения сервиса, изучение фактического поведения сервиса и устранение различий.
- Реагирование на инциденты - обнаружение и эффективное реагирование на сбои обслуживания для поддержания соответствия доступности обслуживания его SLA (соглашению об уровне обслуживания).
- Планирование мощностей — прогнозирование будущего спроса и предоставление необходимого количества вычислительных ресурсов в соответствующих местах для удовлетворения этого спроса.
- Масштабирование сервиса — предсказуемое развертывание и удаление сервисных вычислительных мощностей в центре обработки данных, часто в результате планирования мощности.
- Управление изменениями — изменение поведения сервиса без потери его надежности.
- Производительность — проектирование, разработка и проектирование, связанные с масштабированием, изоляцией, задержкой, пропускной способностью и эффективностью.
Перед запуском услуги SRE поддерживают ее, предоставляя консультации по архитектуре системы, разрабатывая программные платформы, структуры и планы мощности, а также проводя проверку запуска.
После запуска службы SRE поддерживают ее следующим образом:
- Измеряйте и отслеживайте доступность, задержку и общее состояние системы.
- Проверьте запланированные изменения системы.
- Они масштабируют стабильность системы с помощью некоторых механизмов, например автоматизации.
- Улучшайте систему, продвигая изменения для повышения надежности и скорости.
- Проводит реагирование на инциденты и «необвинительные» вскрытия.
Зрелая команда SRE всегда имеет исчерпывающую документацию по каждой функции SRE. Если вы управляете командой SRE или планируете создать ее, эта статья поможет вам понять, какие типы документации нужны вашей команде, чтобы вы могли планировать и расставлять приоритеты в работе с документацией наряду с другими командными задачами.
История СРЕ
Прежде чем мы обсудим нюансы документации SRE, давайте взглянем на один день из жизни Зои, недавно созданной SRE. Это вторая смена Зои в должности SRE на флагманском проекте AcmeSale в Acme Inc. Пока она просто адаптируется к команде, наблюдает за работой коллег и делает заметки.Но теперь у нее все еще есть пейджер.
По счастливой случайности пейджер звонит в 2:30 ночи.
В сообщении говорится: «Рагнарок, работа спокойно», Зои понятия не имеет, что это значит. Она просматривает свои заметки и находит ссылку на главную страницу панели управления.
Все выглядит нормально.
Она пытается найти во внутренней сети Acme любой документ, в котором упоминается Ragnarok, и через несколько драгоценных минут находит устаревший документ об архитектуре сервиса, который оказывается критически важным для AcmeSale. К счастью, в проектной документации есть ссылка на страницу Ragnarok Ops, на которой есть ссылка на панель мониторинга с полезными графиками.
На странице также упоминается скрипт ragtool, который, возможно, поможет решить проблему, но Зоя впервые о нем слышит. Поэтому она отправляет запрос на помощь другому SRE, имеющему многолетний опыт работы с сервисом и инструментами.
К сожалению, ответа нет. Зои проверяет электронную почту и видит сообщение о том, что ее коллега на час не в сети из-за проблем со здоровьем.
Взвесив все за и против, она звонит своему техническому руководителю, но звонок переходит на голосовую почту.
Все говорит о том, что эту проблему вам придется решать самостоятельно.
Потратив некоторое время на поиск информации о загадочном скрипте ragtool, она находит документ с кратким описанием его параметров командной строки и местами его поиска.
Она запускает ragtool --restart и скрещивает пальцы.
Ничего не меняется, трафик падает еще больше.
Она лихорадочно просматривает остальные параметры командной строки, но не уверена, что они не принесут большего вреда.
Наконец, она решает использовать ragtool —rebalance e—dc=atlanta, поскольку графики показывают, что проблема особенно заметна в дата-центре Атланты.
График трафика начинает медленно ползти вверх, и Зои радуется своей победе.
MTTR (среднее время ремонта, среднее время восстановления сервиса до рабочего состояния) составляет 45 минут. На следующий день Зои проводит вскрытие инцидента.
Это связано с тем, что проблема оказалась особенно масштабной и привела к потере дохода, плюс менеджер просит провести дополнительные вскрытия.
Она спрашивает команду, как остальные члены команды решили бы проблему, и слышит три разных подхода.
Оказывается, единого процесса устранения неполадок просто не существует. Ее коллеги также признают, что уведомление «проскочило» — не самое лучшее название, а сбой произошел из-за известной ошибки, которая просто не была приоритетной.
Наконец Стив, ее технический руководитель, спрашивает: «Какую версию ragtool вы использовалиЭ» а затем отмечает, что используемая версия ужасно старая.
Новая версия вышла неделю назад вместе с совершенно новой документацией, описывающей все функции и даже объясняющей, как решить проблему «Рагнарёк откидывается».
Эта версия сократила бы MTTR до пяти минут. Существование новой версии ragtool становится неожиданностью для половины команды, тогда как другая половина более или менее осведомлена о новой версии и руководстве.
Последняя версия сценария находится в домашнем каталоге Стива, по-видимому, в папке bin/.
Зоя добавляет это к своим заметкам на будущее, надеясь спокойно пережить остаток смены.
Она задается вопросом, сможет ли технический руководитель или кто-либо из команды разобраться в проблемах, обсуждаемых при вскрытии, или всем будущим SRE придется пройти через такой болезненный опыт. Позже в тот же день Зоя присутствует на встрече, на которой команда SRE обсуждает с командой разработчиков вопрос о передаче услуги.
Стив ведет встречу, задает некоторые из поднятых ранее вопросов об операционных процедурах и текущей проблеме надежности сервиса и просит разработчиков внести изменения, прежде чем команда SRE сможет взять на себя ответственность за сервис.
Зои уже побывала на нескольких митингах, проводимых Стивом и другими высокопоставленными SRE. Она понимает, что задаваемые вопросы и задачи, поставленные перед разработчиками, сильно различаются в зависимости от того, кто проводит встречу и какой проблемой занималась команда SRE на прошлой неделе.
Зоя втайне мечтает о более последовательных стандартах и процедурах, но пока не понимает, как этого добиться.
Позже она слышит, как возле кофемашины смеются двое разработчиков о том, что многие вопросы были слабо связаны с пейджером и они вообще понятия не имеют, откуда они взялись.
Зоя желает, чтобы разработчики поняли, что SRE — это не просто пейджер.
Вернувшись за свой стол, Зои находит несколько билетов, которые нужно разобрать, и больше об этом не думает. К счастью, все персонажи и события в этой истории вымышлены.
Однако подумайте, похоже ли это на то, с чем вы столкнулись в реальности.
Решение проблем этой вымышленной команды совершенно очевидно, и мы обсудим его более подробно в следующем разделе.
Важность документации
На ранних стадиях работы команды SRE организация сильно зависит от работы отдельных высококвалифицированных специалистов внутри команды.Команда хранит важные концепции и принципы работы как крупицы «племенных знаний», которые передаются устно новым членам команды.
Если эти принципы не будут унифицированы и задокументированы, то, скорее всего, в какой-то момент их придется мучительно переучивать методом проб и ошибок.
Иногда члены команды выполняют оперативные процедуры как строгую последовательность шагов, определенную их предшественниками в далеком прошлом, даже не понимая причинно-следственных связей этих шагов.
Если это не остановить, процессы фрагментируются и вырождаются, как только команда начинает расти для решения новых задач.
Команда SRE может предотвратить этот процесс, создав качественную документацию, которая послужит основой для роста таких команд и внедрения систематического подхода к управлению новыми и незнакомыми сервисами.
Эти документы сохраняют племенные знания таким образом, чтобы их было легко найти, поддерживать и искать.
Новые члены команды проходят обучение по систематической и продуманной программе.
Это отличительные черты зрелой команды SRE. В оставшейся части статьи описываются различные типы документов, которые SRE создают в течение жизненного цикла поддерживаемой службы.
КОНЕЦ В следующая часть Давайте рассмотрим все эти виды подробно, а пока ждем ваших комментариев и вопросов, а также приглашаем вас в открытый урок .
Теги: #DevOps #sre
-
Думаете О Дешевом Тиражировании Cd И Dvd?
19 Oct, 24 -
Как Продать Недвижимость Через Интернет
19 Oct, 24 -
Резервное Правило 3-2-1. Часть 1
19 Oct, 24 -
Практика Ведения Крупных Проектов От Oracle
19 Oct, 24 -
Сайтspark
19 Oct, 24 -
Redis В Производстве
19 Oct, 24 -
Google Рассказывает О Своей Формуле Поиска
19 Oct, 24
