В прошлом году часть нашей команды, обеспечивающая безопасность платформы Spotify для художников (S4A) провели исследование ряда инцидентов, произошедших с S4A в 2021 году.
Мы выдвинули несколько гипотез, а затем начали анализировать каждую из них, чтобы разработать набор количественных и качественных метрик.
И мы кое-что узнали, и теперь хотим поделиться этим с вами.
Мы обмениваем сегодняшние результаты на будущие.
Каждый раз, когда что-то идет не по плану, есть как издержки, так и выгоды.
Чаще всего мы думаем об отрицательных издержках, которые нам придется понести, когда дело касается пользователей, но есть и другая цена — производительность.
Мы обнаружили, что большинство инцидентов оказывали умеренное или сильное влияние на производительность.
Это означает, что когда происходит инцидент, по крайней мере один ответчик тратит большую часть дня на устранение проблемы.
На самом деле в 23% случаев сотрудник тратит еще больше времени.
Теперь вы можете сказать: «Ух ты, решение проблем требует много времени!» Но, как говорилось ранее, если все сделано правильно, эти затраты принесут пользу.
Проводя анализ инцидентов (раньше мы называли его post-mortem), мы имеем возможность изучить ситуацию и понять, как и где система дала сбой.
Хотя мы можем читать код и документацию и строить гипотезы о том, откуда возникла проблема, анализ сбоев помогает нам лучше понять и разобраться в проблеме.
Таким образом, повышая квалификацию наших инженеров, можно добиться лучших результатов.
Так мы покупаем продуктивность для будущего, жертвуя частью сегодня.
Большинство инцидентов (технически) можно предотвратить.
Для каждого инцидента мы искали признаки того, что его можно предотвратить.
Мы оценивали инциденты по шкале от 1 до 5, где 1 — «практически невозможно предотвратить», а 5 — «мы знали, что инцидент произойдет, и позволили ему произойти».
К счастью, ни в одном происшествии не было 5-й оценки! 
Судя по рейтингу, инциденты с рейтингом 2 и 1, как правило, находятся вне нашего контроля и поэтому не могут считаться предотвратимыми.
Инциденты с рейтингом 3 и выше представляют собой локальные сбои, которые можно предотвратить и/или смягчить путем применения хорошо известных и хорошо изученных превентивных мер.
Это не означает, что профилактика бесплатна или легка.
Когда мы определяем целевой уровень обслуживания (SLO), мы учитываем ошибки — если мы можем оставаться в рамках бюджета, не принимая превентивных мер, мы должны это сделать.
Это означает, что мы можем потратить время на улучшение пользовательского опыта и в конечном итоге сосредоточиться на основной задаче.
Никто не любит бумажную работу
За последние несколько лет DevOps Research and Assessment, или ДОРА , выпускает ежегодный отчет о состоянии DevOps. Эксперты компании опрашивают тысячи специалистов из разных областей и определяют, от чего зависит производительность труда.Согласно результатам исследования, ключевыми метриками являются «Среднее время восстановления» и «Изменение интенсивности отказов».
Эти показатели могут иметь разное значение для разных компаний.
Однако их следует считать не панацеей, а скорее картой, которая помогает нам понять, где мы находимся и куда хотим идти.
В ходе расследования инцидентов, произошедших в 2021 году, мы тщательно изучили хронологию каждого инцидента в том виде, в каком он был зафиксирован, а затем проанализировали имеющиеся доказательства, чтобы получить четкое представление о времени восстановления (TTR) после каждого инцидента.
Мы обнаружили, что примерно в 50% случаев время начала и окончания восстановления не фиксировалось.
В ситуациях, когда время было записано, примерно в 81% случаев нам приходилось корректировать введенное время более чем на 5 минут, чтобы получить фактическое число.
Это не ошибка оператора, а системная ошибка.
Мы просили их заполнить документацию, но их никак не поощряли, и они, как и ожидалось, предпочитали тратить свое время на более важные дела.
Синтетическое тестирование сокращает время восстановления.
После этой работы мы получили данные о времени восстановления (TTR).
Мы обнаружили, что время восстановления действительно сложно соотнести с каким-либо аспектом наших систем.
Однако мы попали в цель.
Одна из самых интересных вещей, которые мы узнали в ходе нашего исследования, заключалась в том, что синтетическое тестирование работает. Мы потратили много времени на оценку того, действительно ли тестирование может выявить сбои, а затем сравнили TTR после инцидентов, которые уже были обнаружены синтетическим тестированием, и инцидентов, которые не были обнаружены, поскольку не были охвачены тестированием.
Результаты оказались еще более шокирующими, чем мы ожидали.
Мы обнаружили, что время восстановления после инцидентов, связанных с функциями, в которых выполнялись синтетические тесты, было в 10 раз меньше.
Нет, правда, перечитайте это еще раз! Это может показаться очевидным, но мы не можем недооценивать влияние данных на принятие решений.
Это не просто любопытство.
Мы скорректировали наши приоритеты, чтобы уделять больше внимания тестированию, поскольку считаем, что важно как можно быстрее восстановить работу.
Так что помните.
Я надеюсь, что из этой статьи вы узнали, что сила инцидентов — это возможность для дальнейшего обучения.
Независимо от того, изучаете ли вы инциденты как совокупность, как мы, или тратите время на их изучение в своем собственном контексте, этот источник данных просто невозможно заменить.
Прерывать рабочий процесс для расследования сбоя может показаться утомительным.
Однако мы считаем, что это жизненно важно, если вы хотите развивать и поддерживать свой сервис.
Приглашаю тимлидов и всех, кому интересна тема технического менеджмента, на мой телеграм-канал.
Пишу заметки и делюсь интересными материалами на тему управления командой.
Теги: #Управление разработкой #Управление проектами #ИТ-инфраструктура #Тестирование #Тестирование ИТ-систем #мониторинг #обучение #инциденты #производительность #документация
-
Как Добиться Успеха, Проходя Платные Опросы
19 Oct, 24 -
Система Учета Рабочего Времени
19 Oct, 24 -
Техника Проекционного Моделирования
19 Oct, 24 -
Установка Intensedebate В Drupal
19 Oct, 24 -
На Лифте В Космос - 2009. Итоги
19 Oct, 24 -
Жизнь После Жизни
19 Oct, 24
