Close

Управление инцидентами для высокоскоростных команд

Руководство по улучшению дежурств для менеджера

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

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

В условиях изменения рекомендаций и роста компаний самые гибкие и скоростные команды внедряют новые подходы (и делают это вполне успешно).

Кто создал, тот и поддерживает

Еще десять лет назад операционные команды в основном занимались реагированием на ИТ-инциденты. Обычно команды в организации имели многоуровневую структуру. Она включала уровни 1–3, причем более высоким уровням соответствовала более высокая квалификация и оплата.

Такая структура помогала сократить эксплуатационные расходы. Обычно на 1-м уровне находились начинающие сотрудники. Если сотрудники 1-го уровня не могли решить проблему, ее передавали на 2-й уровень, состоящий из старших (а значит, более высокооплачиваемых) сотрудников. И этот процесс продолжался до тех пор, пока проблема не была решена.

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

В результате такого изменения технологического ландшафта потребовались изменения в структуре команд реагирования. Появилось движение DevOps и принцип «кто создал, тот и поддерживает».

Идея проста: разработчик, лучше всех знающий код, может быстрее и эффективнее других решить связанные с ним проблемы. Благодаря DevOps и этой идее теперь на дежурства обычно назначают разработчиков. Они обеспечивают работоспособность кода и снижение значений MTTA и MTTR в контексте инцидентов.

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

Создание рекомендаций по дежурствам, которые понравятся командам

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

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

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

Будьте открытыми со своими командами

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

  • Дежурят ли инженеры в ночное время?
  • Можно ли работать из дома на следующий день после ночного дежурства? Может ли дежурный сотрудник на следующий день начать работу позже, если ему необходимо выспаться?
  • Должны ли разработчики заниматься созданием ПО во время дежурства?
  • Сколько раз в месяц дежурит разработчик? Каково максимальное число дежурств для одного сотрудника?
  • Как сотрудникам компенсируют дежурство?

Проводите надлежащее обучение

Рекомендации по обучению дежурных команд включают следующее.

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

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

Разделяйте обязанности дежурного и разработчика

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

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

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

Выполняйте тонкую настройку процесса дежурства

Работоспособная система дежурств может существовать только в условиях постоянного улучшения путем тонкой настройки процессов и систем. Добейтесь эффективной обработки оповещений, настроив графики дежурств, правила маршрутизации и политики эскалации с помощью решения для управления инцидентами, такого как Jira Service Management. Мы рекомендуем следующее.

  • Настраивать системы с учетом оценки приоритета и срочности оповещений. Несрочные оповещения подождут до утра, а за это время дежурные сотрудники смогут выспаться.
  • Сокращать количество ложных срабатываний путем классификации оповещений по таким факторам, как основная причина, система-источник, сообщение, пороговые значения и т. д. Это помогает выделить оповещения, требующие принятия мер.
  • Устранять дублирование связанных оповещений, чтобы избежать усталости.
  • Создавать информативные оповещения, которые четко описывают проблему, а также позволяют дежурным инженерам принимать эффективные решения и использовать сведения из перечней процедур.
  • Предоставлять дежурным командам отчеты об оповещениях и показатели, чтобы они могли выявлять и устранять слабые места в системах. Не позволяйте дежурным командам увязнуть в одних и тех же проблемах!

Просматривайте отчеты о дежурствах и вносите необходимые корректировки

Чтобы поддерживать справедливость и предотвратить выгорание сотрудников, попросите менеджеров просматривать отчеты о дежурствах и быть в курсе следующих сведений.

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

Прислушивайтесь к мнению сотрудников

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

Связанные с дежурствами системы, инструменты, процессы, сотрудники, документация и обучение могут меняться. Их нельзя определить раз и навсегда. С развитием компании команды набираются опыта и сменяются, а также происходят постепенные изменения в инцидентах. Поэтому руководителям требуется постоянно пересматривать и улучшать программы дежурств.

Дежурные инженеры лучше всего могут рассказать о том, что работает, а что нет. Прислушивайтесь к ним. Вносите изменения. Также очень важно понимать, что руководители не должны принимать решения самостоятельно, когда речь идет об организации дежурства или протоколе. Чем больше возможностей получит команда для улучшения собственных процессов и методик, тем лучше она будет относиться к дежурству.

Развивайте благоприятную культуру дежурств

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

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

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

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

Ознакомьтесь с Jira Service Management — решением, поддерживающим позитивную культуру дежурств, — и создайте систему с расширенными возможностями коммуникации, централизованным оповещением, гибкой автоматизацией и продвинутой системой отчетов, чтобы вывести на новый уровень реакцию на инциденты.