Добрый вечер всем! Спешим поделиться новостью о том, что в феврале мы запускаем новый поток по курсу «Девопс – практики и инструменты» , а это значит, что пришло время закончить начатое и опубликовать третью часть статьи: «Почему важна документация SRE» .
Идти! Документы для управления командами SRE Для эффективной работы командам SRE необходима надежная и доступная документация.
Сайт команды Примечание.
Вместо веб-сайта вы можете использовать отдельное пространство или раздел в Confluence/Wiki. Сайт группы важен, поскольку он обеспечивает координацию информации и документации, относящейся к команде SRE и ее проектам.
Например, в Google многие команды SRE используют g3doc (внутреннюю платформу документации Google, где документы хранятся в исходном коде вместе со связанным кодом), а некоторые команды используют g3doc и Google Sites: в этом случае страницы g3doc тесно связаны с кодом/ детали реализации.
Устав команды 
Команды SRE должны иметь опубликованный устав, в котором описывается мотивация работы и документируется постоянное взаимодействие.
Устав необходим для установления идентичности, основных целей и значения команды внутри всей компании.
Устав обычно содержит следующие элементы:
- Высокоуровневое описание зоны ответственности команды.
Включая тип сервисов, поддерживаемых командой (и каким образом), связанные системы и примеры.
- Краткое описание пары наиболее важных сервисов, поддерживаемых командой.
В этом разделе также освещаются ключевые технологии и проблемы их использования, преимущества участия SRE, а также их обязанности.
- Ключевые принципы и ценности команды.
- Ссылки на сайт команды и документацию.
Документация по интеграции новых SRE Инвестиции в инструменты и материалы обучения для новых сотрудников положительно влияют на то, как быстро сотрудники интегрируются в рабочие процессы.
Командам SRE выгодно как можно быстрее обучить новых сотрудников всем необходимым навыкам сменной работы.
История Зои иллюстрирует, как отсутствие должного обучения нового сотрудника может превратить незначительный инцидент в серьезную неудачу.
Многие команды SRE готовят новых сотрудников к сменам, используя контрольные списки.
Контрольный список смены обычно охватывает области высокого уровня (разделенные на подразделы), которые должны понимать члены команды.
Примеры таких областей включают концепции производства, интерфейсную и серверную части, автоматизацию и контрольно-измерительные приборы, мониторинг и регистрацию.
Контрольный список может также включать инструкции по подготовке к смене и задания, выполняемые в течение смены.
SRE также используют ролевые упражнения (Google называет их «Колесо неудач») для обучения новых членов команды.
В этом упражнении представлен сценарий отказа с конкретным набором данных и сигналами, которые гипотетически понадобятся SRE для решения проблемы во время смены.
Члены команды по очереди играют роль дежурного инженера, чтобы отточить свои навыки устранения неполадок и отладки системы.
Колесо несчастий заботится о том, чтобы каждый член команды знал, где найти документацию, необходимую для устранения проблемы, и как бороться с возникшим сбоем.
Управление хранилищем Вся информация команды SRE может быть разбросана по нескольким сайтам, локальному репозиторию и папкам Google Диска, что значительно усложняет поиск того, что вам нужно.
Как это произошло в ранее описанном примере, важнейший оперативный инструмент и инструкции по его использованию были недоступны Зое (дежурному SRE), поскольку они были спрятаны в личном каталоге ее технического руководителя, а невозможность их найти значительно увеличивала продолжительность сбой в обслуживании.
Чтобы избавиться от подобных проблем, необходимо структурировать всю информацию и убедиться, что члены команды знают, где ее найти, хранить и как поддерживать.
Проработанная структура поможет команде быстрее находить информацию.
Новые члены команды будут быстрее входить в курс дела, а дежурные инженеры смогут быстрее решать проблемы.
Вот несколько рекомендаций по созданию и поддержанию хранилища документации:
- Определите ключевых заинтересованных сторон и проведите краткие интервью для выявления всех потребностей.
- Найдите как можно больше документации и проанализируйте пробелы в ее содержании.
- Фундаментально структурируйте свой сайт, чтобы создавать новую документацию в нужных местах.
- Переместите существующую документацию в новое место.
- Архивируйте и утилизируйте старую документацию.
- Проводить регулярные проверки для обеспечения качества/последовательности поддерживаемой документации.
- Убедитесь, что стандартные поисковые запросы возвращают нужные вам документы вверху списка результатов поиска.
- Используйте такие сигналы, как Google Analytics, для измерения стандартных практик.
Должно быть видно имя владельца и дату последней проверки — эта информация помогает убедиться в подлинности выбранного документа.
Зоя по сюжету смогла найти лишь устаревшую документацию на критически важный инструмент, тем самым потеряв возможность быстрого решения вопроса.
Ненадежная и устаревшая документация делает SRE менее эффективными, что негативно влияет на надежность управляемых сервисов.
Доступность репозитория Команды SRE должны гарантировать, что документация останется доступной, даже если стандартный репозиторий выйдет из строя и будет недоступен.
Каждый SRE в Google имеет собственную копию важной документации.
Эта копия доступна на зашифрованном компактном запоминающем устройстве или каком-либо аналогичном съемном, но защищенном физическом носителе, имеющемся у каждого дежурного SRE. Документация по выводу услуги из эксплуатации Когда служба достигает конца своего жизненного цикла, SRE прекращает ее использование предсказуемым образом.
В этом разделе представлены рекомендации по документации по выводу службы из эксплуатации.
Важно заранее объявить пользователям о прекращении использования услуги и указать сроки и основные этапы.
В вашем объявлении должно быть указано, когда закончится регистрация новых пользователей, как будут обрабатываться существующие и будущие ошибки и когда служба окончательно перестанет работать.
Четко обозначайте все важные даты и процесс деэскалации SRE и отправляйте промежуточные объявления по мере достижения прогресса.
Простой рассылки по электронной почте недостаточно — вам необходимо обновить главную страницу документации, плейбуки и кодовые лаборатории.
Также, если возможно, закомментируйте файлы заголовков.
Опишите детали объявления в документе (помимо письма), на который пользователи смогут ссылаться.
Письмо должно быть максимально коротким, но в то же время информативным, отражающим все основные моменты.
Опишите дополнительные подробности: бизнес-мотивацию закрытия сервиса, какие инструменты пользователи могут использовать для перехода на другой сервис, какая поддержка доступна во время миграции.
Также стоит создать страницу FAQ, со временем наполняя ее новой информацией по вопросам, которые задают пользователи.
Роль редакторов технической документации Технические редакторы (или технические писатели) предоставляют услуги, которые делают SRE более эффективным и продуктивным.
Спектр задач не ограничивается написанием отдельных документов по требованиям, заданным командой SRE. Вот несколько практических советов техническим редакторам по работе с командами SRE.
- Технические редакторы сотрудничают с SRE для создания эксплуатационной документации для запуска сервисов и производственной документации для продуктов и инструментов SRE.
- Они создают и обновляют репозитории документации, структурируют и реорганизуют их в соответствии с потребностями пользователей, а также улучшают отдельные документы в рамках общего управления репозиторием.
- Редакторы помогают выявить улучшения, необходимые в документации и управлении информацией.
Это включает в себя оценку документации для сбора требований, улучшение документов и сайтов, созданных инженерами, консультирование команд по правилам создания, организации, редизайна, поиска и обслуживания документации.
- Редакторы должны оценивать и совершенствовать инструменты документации, чтобы предлагать лучшие решения SRE.
- Упростите создание документации, предоставив инженерам четкую структуру для создания новых документов.
- Добавляют разделы всех необходимых документов для полного оформления документации.
- Помогите читателю быстро понять тему документа, тип информации и то, как она организована.
В этом разделе мы предоставим еще несколько примеров, показывающих, как шаблоны обеспечивают структуру и рекомендации для инженеров по наполнению контентом.
Обзор услуг Обзор Что это? Что он делает? Опишите на высоком уровне функциональность, предоставляемую клиентам (конечному пользователю, компонентам и т. д.).
Архитектура Объясните, как работает архитектура.
Опишите, как данные перемещаются между компонентами.
Рассмотрите возможность добавления системной диаграммы с критическими зависимостями, а также потоками запросов и данных.
Клиенты и зависимости Перечислите всех клиентов (принадлежащих другим командам), которые зависят от него, и всех сервисов (принадлежащих другим командам), от которых он зависит. (Это также можно продемонстрировать в виде системной диаграммы.
) Код и конфигурация Расскажите о структуре производства.
Где он запущен? Перечислите двоичные файлы, задания, центры обработки данных и настройки файлов конфигурации или укажите, где они все расположены.
Также укажите расположение кода и, если необходимо, информацию о сборке.
Перечислите и опишите файлы конфигурации, изменения и порты, необходимые для работы этого продукта или услуги.
Опишите следующее: Какие файлы конфигурации были изменены для этого продукта или услуги? Как происходит настройка? Процессы Опишите следующее: Какие демоны и другие процессы должны быть запущены для работы службы? Какие управляющие скрипты были созданы для управления сервисом? Выход Перечислите и опишите файлы журналов, созданные компонентом, и какие наблюдения были сделаны.
Опишите следующее: Какие журналы генерируются этим компонентом? Что содержит каждый файл? Какие рекомендации по изучению этих файлов? Какие аспекты компонента необходимо отслеживать, чтобы служба работала надежно? Панели мониторинга и инструменты Вставьте ссылки на соответствующие информационные панели и инструменты.
Власть Укажите емкость одного экземпляра; Центры обработки данных по всему миру: значения QPS, пропускной способности и задержки.
Соглашение об уровне обслуживания Укажите цели доступности.
Стандартные процедуры Добавьте ссылки на процедуры, включая нагрузочное тестирование, обновления/отправки/состояния флагов и т. д. Добавьте ссылки на документацию по оповещениям в сборник предупреждений.
Рекомендации Добавьте ссылки на проектную документацию для компонента или связанных компонентов, обычно написанную командой разработчиков, а также другую соответствующую информацию.
Пособие Имя В заголовке укажите имя оповещения (например, NormalAlert_AlertVeryNormal).
Обзор Опишите следующее: Что означает это предупреждение? Оно приходит на пейджер или только по электронной почте? Какие факторы вызывают тревогу? Какие части службы затронуты? Какие оповещения с ним связаны? Кого необходимо уведомить? Уровень оповещения Обоснуйте серьезность предупреждения и влияние затронутых частей на общее состояние службы.
Подтверждение Предоставьте четкие инструкции по проверке и подтверждению актуальности статуса.
Поиск неисправностей Перечислите и опишите методы отладки и соответствующие источники информации.
Не забывайте о ссылках на соответствующие дашборды.
Включите предупреждения.
Опишите следующее: Что будет отображаться в журналах при срабатывании оповещения? Какие обработчики отладки существуют? Есть ли полезные скрипты и команды? Какой результат они генерируют? Существуют ли дополнительные задачи, которые необходимо решить после устранения предупреждения? Решение Опишите и перечислите все возможные решения проблемы, вызывающей предупреждение.
Опишите следующее: Как решить проблему и устранить предупреждение? Какие команды мне следует выполнить для перезагрузки? Кого следует уведомить, если оповещение сработало из-за действий пользователя? Есть ли у кого-нибудь опыт устранения подобной проблемы? масштабирование Перечислите и опишите пути эскалации.
Укажите человека или команду, кого необходимо уведомить и когда это нужно сделать.
Если эскалация не нужна, напишите об этом.
Ссылки по теме Предоставьте ссылки на соответствующие оповещения, процедуры, обзорную документацию.
Ежеквартальный отчет по обслуживанию Введение Опишите услугу, за которую отвечает команда.
Планирование мощностей Включая:
- Фактический спрос на услугу за последние 6–8 кварталов, выраженный в наиболее релевантных для услуги метриках (например, QPS или DAU).
- Прогноз спроса на следующие 8 кварталов.
- План мощностей, который соответствует прогнозируемому спросу на необходимом уровне резервирования, позволяет уточнить нехватку и/или риски планирования мощности.
Соблюдение соглашения об уровне обслуживания/доступность Все услуги, поддерживаемые SRE, должны иметь письменное соглашение об уровне обслуживания, по которому ежеквартально оценивается производительность.
Раздел SLA должен содержать параметры основных компонентов сервиса для измерения квартальной реализуемости условий SLA, а также ссылку на письменный SLA команды.
Связанные инциденты (необязательно) Перечислите 3–5 крупнейших инцидентов или сбоев за квартал.
Достижения (необязательно) Перечислите свои основные достижения за квартал.
Изменения SLA (желательно) Последние изменения в SLA. Подробности услуги (желательно) В разделе может быть указана статистика роста, задержек и т. д. Информация о команде (необязательно) Может включать информацию о составе команды, статусах, проектах, статистике смен.
Источники данных (обязательно) Опишите источники, используемые для получения значений доступности, методы расчета и предоставьте ссылки на соответствующие информационные панели.
Устав команды Кто мы В одном предложении (~ 1 строка) опишите технологическую среду, предложения клиентов и команд, а также степень участия SRE и конкретный опыт. Поддерживаемые услуги Чтобы дополнительно уточнить объем работ, опишите сервисы (или группу сервисов), которые поддерживает команда.
Как мы распределяем время Определение объема работы помогает составить дорожную карту, а также достичь и поддерживать цели в долгосрочной перспективе.
Ценности команды Четко выражайте свои ценности.
Это влияет на то, как члены команды взаимодействуют друг с другом и как вашу команду воспринимают другие.
Заключение Независимо от того, являетесь ли вы SRE, менеджером SRE или техническим редактором, теперь вы понимаете решающую важность документации в жизни эффективной команды SRE. Хорошая документация позволяет команде SRE расти и поддерживать четкую методологию управления новыми и существующими сервисами.
Итак, мы опубликовали заключительную часть этой статьи, первый И второй части можно прочитать, перейдя по гиперссылкам, а еще больше полезной информации вы сможете получить на нашем открытый урок , который состоится 19 февраля.
Ждем всех! Теги: #DevOps #sre
-
.Net И Navision 5.0 — Дружба Навсегда
19 Oct, 24 -
Минибар Из Старого Телевизора
19 Oct, 24 -
Iphone В Северной Европе – В Этом Году
19 Oct, 24
