В Dropbox мы считаем, что управление инцидентами является центральным элементом нашей системы надежности.
И хотя мы также используем упреждающие методы, такие как хаос-инжиниринг, то, как мы реагируем на инциденты, оказывает существенное влияние на опыт наших пользователей.
Во время потенциального сбоя на сайте или проблемы с продуктом каждая минута на счету.
Ключевые компоненты нашего процесса управления инцидентами существуют уже несколько лет, но мы видим возможности для дальнейшего развития в этой области.
Изменения, которые мы внесли с течением времени, включают технологические, организационные и процедурные улучшения.
В этой статье мы подробно опишем несколько уроков, которые Dropbox извлек из своего опыта управления инцидентами.
Скорее всего, не каждый пункт можно найти в руководстве по структуре управления инцидентами, и не стоит думать, что эти улучшения универсальны для каждой компании.
(Полезность этих уроков зависит от вашего технологического стека, размера вашей организации и других факторов.
) Вместо этого мы надеемся, что эта статья послужит примером того, как вы можете систематически анализировать реагирование на инциденты в вашей компании и улучшать ее в соответствии с потребностями.
ваших пользователей.
1. Предварительные условия
Базовая структура управления инцидентами в Dropbox называется SEV (от SEVerity) и похожа на ту, что используется в большинстве других SaaS-компаний.(Для тех, кто не очень сведущ, рекомендуем ознакомиться с сериалом обучающие программы на эту тему).
Наличие SEV, хотя и не единственный тип критических инцидентов, полезно изучить особенно подробно.
Ни один онлайн-сервис не застрахован от подобных инцидентов, включая Dropbox. Критические инциденты доступности часто являются наиболее разрушительными для большинства пользователей — просто подумайте о любой недавней ситуации, когда один из ваших любимых сайтов или SaaS-приложений вышел из строя, — и мы считаем, что эти SEV оказывают наибольшую нагрузку на нашу скорость реагирования.
Успех означает максимальное сокращение времени ответа.
Мы не только тщательно измеряем время воздействия наших SEV, но и этот показатель имеет реальные последствия для бизнеса.
Каждая минута без нашей реакции на инцидент означает больше недовольных пользователей, увеличение оттока, уменьшение количества регистраций, а также ущерб репутации от освещения ситуации в социальных сетях и прессе.
Кроме того, в контрактах с некоторыми нашими клиентами, особенно из критически важных отраслей, Dropbox обязуется обеспечивать бесперебойный доступ к услугам.
Этот показатель определяется на основе общей доступности систем, обслуживающих клиентов, и мы официально объявляем себя «неработающими», когда доступность падает ниже определенного порога.
Чтобы оставаться в пределах 99,9 % времени безотказной работы, согласованного в соглашении об уровне обслуживания, мы ограничиваем время простоя не более 43 минутами в месяц.
Внутри мы поставили еще более высокую планку — 99,95% (а это 21 минута в месяц).
Чтобы обеспечить такую производительность, мы вложили средства в различные методы предотвращения инцидентов.
Некоторые из них — это хаос-инжиниринг, оценка рисков и проверка системных требований.
Однако как бы мы ни старались понять наши системы, SEV все равно будут происходить.
Именно здесь в игру вступает управление инцидентами.
2. Обработка SEV
Экран обработка SEV Dropbox определяет, как различные специалисты по реагированию на инциденты должны работать вместе, чтобы смягчить последствия SEV, и какие шаги следует предпринять, чтобы извлечь уроки из ситуации.Для исследования каждого SEV необходимо определить следующие вещи:
- Тип СЭВ , классифицируя направление воздействия инцидента; наиболее знакомыми нам являются Доступность, Надежность, Безопасность и Деградация Функций.
- уровень СЭВ от 0 до 3, определяя критичность.
0 является наиболее критичным.
- IMOC (менеджер по инцидентам по вызову - менеджер по инцидентам) , лицо, ответственное за оперативное устранение последствий, координацию действий специалистов СЭВ и информирование о статусе происшествия.
- TLOC (Tech Lead On Call – технический специалист), руководство расследованием инцидента и принятие технических решений.
BMOC (Бизнес-менеджер по вызову – Бизнес-менеджер) , который занимается нетехническими вопросами, обеспечивая необходимые внешние оповещения.
В зависимости от ситуации это может включать обновление страниц статуса, прямое общение с клиентами и, в редких случаях, с регулирующими органами.
В Dropbox мы создали собственный инструмент управления инцидентами: DropSEV .
Любой сотрудник может зарегистрировать SEV, что запускает распределение описанных выше ролей и создает набор каналов связи для обработки инцидентов.
К ним относятся канал Slack для совместной работы в режиме реального времени, ветка электронной почты для более общих обновлений, билет Jira для сбора артефактов и предварительно заполненный посмертный документ, который пригодится во время ретроспективы.
Вы также можете подписаться на канал Slack или рассылку новостей по электронной почте с уведомлениями о новых SEV. На картинке представлен пример создания запроса при незначительном нарушении доступности мобильного приложения.
После создания приложения DropSEV начинается процесс обработки.
- Обнаружение: время, необходимое для выявления проблемы и уведомления лиц, ответственных за ее устранение (специалистов по реагированию на инциденты)
- Диагностика: время, необходимое респондентам для выявления основной причины проблемы и/или поиска ее решения
- Восстановление: время, необходимое для решения проблемы для пользователей
Мы были вынуждены оптимизировать каждый из трех этапов, чтобы удовлетворить этому ограничению.
3. Обнаружение
время, необходимое для выявления проблемы и уведомления лиц, ответственных за ее устранение Надежная и эффективная система мониторинга В Dropbox, когда дело доходит до обнаружения проблем, наши системы мониторинга являются ключевым компонентом.За прошедшие годы мы создали и усовершенствовали несколько систем, на которые инженеры полагаются во время инцидентов.
Первым и наиболее важным является Vortex, серверная система метрик и оповещений.
Vortex гарантирует задержку данных, измеряемую секундами, частоту дискретизации 10 секунд и простой интерфейс для создания персонализированных уведомлений для конкретных сервисов.
Эти функции имеют основополагающее значение для задачи сокращения времени обнаружения проблем на производстве.
В предыдущем почта Мы поговорили об архитектуре приложения, давайте ее здесь вспомним.
В 2018 году мы модернизировали эту систему, которая стала основой нашей работы по обеспечению надежности.
Чтобы понять почему, подумайте о «правиле 21 минуты», которое мы ввели внутри компании.
Нам было важно быть уверенными, что в течение первых десяти секунд после инцидента Vortex оповестит об этом всех ответственных респондентов через PagerDuty. Если бы Vortex был ненадежным или слишком медленным, наша реакция на инцидент была бы отложена еще до того, как мы успели бы ее предпринять.
Вашей компании не обязательно использовать самодельную систему мониторинга, подобную нашей, но спросите себя: как быстро вы узнаете, что произошел инцидент, прежде чем сможете начать реагировать? Оптимизация метрик и уведомлений Vortex является лидером в быстром сообщении об авариях, но он бесполезен без четко определенных показателей для отчетности.
Во многом это сложная проблема, поскольку в каждом отдельном случае обязательно будут отдельные метрики, которые команде придется добавлять вручную.
Мы постарались снизить нагрузку на владельцев сервисов, предоставив им большое количество бесплатных метрик приложений, среды выполнения и хоста.
Эти метрики встроены в нашу структуру Courier RPC, а также в инфраструктуру уровня хоста.
В дополнение к множеству стандартных показателей Courier также обеспечивает распределенную трассировку и профилирование, что еще больше упрощает сортировку инцидентов.
Набор метрик в Courier доступен для всех языков, которые мы используем в Dropbox (Go, Python, Rust, C++, Java).
Хотя эти готовые метрики бесценны, бесконечное количество предупреждений также является распространенной проблемой, из-за которой сложно определить, где на самом деле произошло что-то плохое.
Мы предлагаем несколько средств для облегчения этой боли.
Наиболее мощной является система зависимости уведомлений, с помощью которой владельцы сервисов могут связывать свои уведомления со сторонними и отключать оповещение, если проблема связана с какой-то общей зависимостью.
Это позволяет командам не сообщать о проблемах, за которые они не отвечают, и больше сосредоточиться на реальных проблемах.
Исключение человеческого фактора из регистрации инцидентов Наши команды получают множество уведомлений в PagerDuty о статусе сервисов, но не каждое из них «достойно SEV».
Раньше это означало, что лицу, первым реагирующему на инцидент, приходилось беспокоиться не только о самом инциденте, но и о том, стоит ли заполнять SEV и начинать формальный процесс управления инцидентом.
Различия не всегда очевидны, особенно для тех, кто не имеет большого опыта работы в группе реагирования.
Чтобы облегчить принятие решения, мы переработали DropSEV (инструмент управления инцидентами, описанный выше), чтобы он отображал описания SEV непосредственно пользователям.
Например, если вы выбрали «Доступность» в качестве типа SEV в DropSEV, он выведет подобную таблицу, которая поможет вам сопоставить степень глобального влияния доступности с уровнями SEV. 
Это был шаг вперед, но мы поняли, что решать «стоит ли регистрировать СЭВ здесьЭ» продолжает замедлять работу наших респондентов.
Представьте, что вы работаете во внешнем интерфейсе Magic Pocket, нашей собственной многоэкзабайтной системы хранения данных, которая обрабатывает запросы Get и Put для блоков данных.
При получении уведомления о происшествии необходимо задать себе следующие вопросы:
- Доступность снижается?
- сколько?
- влияет ли это на глобальную доступность? (и где, черт возьми, приборная панель, чтобы это увидеть)
- сколько? как это соотносится с таблицей SEV?
Пару раз SEV просто не регистрировались, а это означало, что мы упустили возможность привлечь IMOC и BMOC, пока техническая команда работала над восстановлением доступности.
Поэтому этим летом мы начали автоматически регистрировать все SEV, связанные с доступностью.
Владелец сервиса по-прежнему будет получать системные оповещения, но DropSEV обнаружит влияние SEV на доступность и автоматически инициирует процесс реагирования на инциденты.
Владельцам сервисов больше не придется отвлекаться на заполнение форм, и мы больше уверены в том, что все роли, отвечающие за реагирование на инциденты, будут вовлечены в этот процесс.
И самое главное, мы сэкономили себе еще несколько минут на каждую доступность SEV. И где вы можете исключить принятие решений человеком в вашем собственном процессе реагирования на инциденты?
4. Диагностика
время, необходимое респондентам для выявления корня проблемы и/или определения подхода к ее устранению Общие нормы пошлины На этапе диагностики нам часто необходимо привлечь дополнительных людей для помощи людям, изначально назначенным на мероприятие.Мы добавили кнопку «Позвать на помощь» в наш внутренний каталог, чтобы человек мог при необходимости эффективно связаться с другой командой.
Это еще один способ использования PageDuty на протяжении многих лет. 
В нашем техническом каталоге есть ссылки на другие дежурные бригады и кнопки для быстрой связи с ними в случае возникновения чрезвычайной ситуации.
Однако мы обнаружили критический момент, из-за которого невозможно постоянно поддерживать время простоя менее 21 минуты: как настраивается PagerDuty для конкретной команды? С течением времени разные команды Dropbox принимали совершенно разные решения по таким вопросам, как:
- Из скольких уровней должен состоять наш? политика эскалации ?
- Сколько времени проходит между эскалациями? Сколько времени занимает весь процесс эскалации?
- Как дежурные получают уведомления от PagerDuty? Нужны ли им push-уведомления, SMS, звонки или их комбинация?
Мы создали внутренний сервис, который обращается к API PagerDuty, запускает нашу логику проверки и связывается с командой, если обнаруживает нарушения.
Мы приняли трудное решение строго проверять на соответствие всем без исключения.
Это было нелегко сделать, поскольку команды привыкли к определенной свободе и гибкости, но последовательность в ответах на приведенные выше вопросы открывала гораздо большую предсказуемость в нашем реагировании на инциденты.
После первоначальной сборки было легко добавить дополнительные проверки, а позже мы нашли способы тонкой настройки базовой настройки (позволяя использовать разные стандарты в зависимости от критичности сервиса вашей команды).
В свою очередь, ваши собственные должностные инструкции должны зависеть от бизнес-требований по реагированию на инциденты в вашей организации.
На момент написания этого поста (январь 2021 г.
) PagerDuty выпустила Отчет о готовности к дежурству (Отчет о готовности к дежурству), который позволяет выполнять некоторые аналогичные проверки на своей платформе.
Хотя охват не идентичен тому, что мы создали в Dropbox, он по-прежнему является хорошей отправной точкой, если вы хотите быстро добиться некоторой согласованности.
Панели управления сортировкой проблем Для большинства наших критически важных сервисов, таких как приложение, управляющее сайтом.
dropbox.com , мы создали серию информационных панелей, которые собирают все показатели высокого уровня и предоставляют несколько способов сузить фокус вашего расследования проблемы.
Для этих критически важных систем сокращение времени, затрачиваемого на сортировку, является главным приоритетом.
Эти панели сократили усилия, необходимые для перехода от общего уведомления о недоступности системы к обнаружению конкретной неисправности.
Готовые панели управления распространёнными причинами аварий Хотя не бывает двух одинаковых инцидентов с серверной частью, мы знаем, что определенные данные время от времени важны для респондентов.
Например:
- Частота ошибок на стороне клиента и сервера
- Задержка RPC
- Тенденции исключений
- Запросов в секунду (QPS)
- Нестандартные хосты (например, с более высокой частотой ошибок)
- Основные клиенты
С этой целью мы создали внутреннюю панель мониторинга, которая охватывает все описанные выше метрики и многие другие.
Новому владельцу сервиса не требуется прилагать никаких усилий для настройки, кроме добавления страницы в закладки.
(Мы также рекомендуем владельцам сервисов создавать более подробные информационные панели для отслеживания показателей, специфичных для их команды.
) 
Часть информационной панели Courier на базе Grafana, предоставляемая владельцам сервисов по умолчанию.
Преимущество такой общей платформы заключается в том, что со временем вы можете легко добавлять новые показатели.
Обнаружили новую структуру коренных причин инцидентов? Отлично — в общий дашборд можно добавить панель, на которой будут отображаться эти данные.
Мы также вложили средства в добавление в Grafana аннотаций, которые сопоставляют ключевые события (перемещение кода, DRT и т. д.) с метриками, чтобы помочь инженерам с корреляцией.
Каждое из этих дополнений немного сокращает время диагностики компании.
Отслеживание исключений Одним из самых мощных диагностических инструментов Dropbox является система отслеживания исключений.
Он позволяет любому сервису в Dropbox отправлять трассировки стека в центральный репозиторий вместе с полезными метаданными.
Интерфейс позволяет разработчикам легко видеть и исследовать тенденции исключений в своих сервисах.
Эта возможность детализировать данные об исключениях и анализировать тенденции особенно полезна при диагностике проблем в наших крупных приложениях Python. 
Роль менеджера по инцидентам: устранение отвлекающих факторов Во время сбоя или другого критического инцидента в процесс вовлечены многие другие заинтересованные стороны проекта, помимо команды SEV, работающей над решением проблемы.
- Команды, работающие с клиентами, которым необходимо предоставить обновленную информацию о ситуации и примерное время решения.
- Владельцы сервисов в пострадавшем регионе интересуются техническими подробностями.
- Старшие руководители, отвечающие за надежность и бизнес-цели, пытаются донести до сотрудников информацию о срочности.
- Старейшина технический Менеджеры иногда засучивают рукава и тоже присоединяются к диагностике.
Мы видели, как все вышеперечисленное происходило во время инцидентов.
И иногда было довольно сложно достичь главной цели Инцидент-менеджера: оградить команду SEV от этих отвлекающих факторов.
Благодаря пройденному обучению менеджеры по инцидентам имеют общее представление о процессе SEV, связанной с ним терминологии и инструментах, а также ожиданиях от вскрытия и анализа инцидентов.
Но они не всегда точно знали, как управлять оперативными центрами и оптимизировать эффективность реагирования СЭВ.
Мы слышали отзывы наших инженеров о том, что менеджеры по инцидентам не предоставляют им необходимой поддержки, что отвлекает внимание и замедляет процесс диагностики проблемы.
Мы поняли, что эти аспекты роли менеджера по инцидентам оставались неявными, а знание о том, «что делает хорошего менеджера по инцидентам», передавалось через фольклор и со временем утрачивалось.
Первым шагом было обновить нашу образовательную программу, подчеркнув уровень срочности, устранив отвлекающие факторы и объединив общение в одном месте.
В настоящее время мы работаем над игровыми (тренировочными) сценариями SEV, в которых менеджер по инцидентам сможет попрактиковаться в этих аспектах перед тем, как приступить к своей первой смене.
Наконец, мы планируем увеличить количество учений, привлекая больше менеджеров, чтобы группа могла оценить свою общую готовность.
Кроме того, мы создали резервную группу реагирования, состоящую из менеджеров по инцидентам и технических специалистов старшего уровня, которые могут быть задействованы в самых серьезных инцидентах.
Мы предоставили им четкий путь вперед, чтобы оценить статус инцидента и определить, с помощью нынешнего менеджера по инцидентам и технического специалиста, нужно ли им передать бразды правления.
Предоставление этим старшим игрокам четкой, хорошо известной роли сделало их ценной структурой поддержки, а не источником дополнительного шума в Slack. Ключевой урок: обратите внимание на различия между тем, как ваш процесс реагирования на инциденты выглядит на бумаге, и тем, что происходит на практике.
5. Восстановление
время, необходимое пользователю для устранения симптомов проблемы, поскольку у нас есть решение Сценарии смягчения последствий На первый взгляд может показаться трудным найти «серебряную пулю» на этапе восстановления.Как можно оптимизировать эту часть процесса, если разные инциденты требуют разных стратегий? Это требует глубокого понимания того, как работают и ведут себя ваши системы, а также четкого понимания того, какие шаги следует предпринять респондентам в наихудших (но разрешимых) случаях.
Поскольку согласно соглашению об уровне обслуживания Dropbox обещает бесперебойную работу на уровне 99,9 %, мы начали ежеквартально проводить оценку рисков надежности.
Это был процесс мозгового штурма снизу вверх для каждой из наших инфраструктурных команд и других, чьи системы, скорее всего, будут задействованы в SEV. Зная, что нам необходимо оптимизировать время восстановления, мы попросили команды сосредоточиться на простом вопросе: «Устранение каких инцидентов в ваших системах займет более 20 минутЭ» Это привело к множеству теоретических инцидентов с различной степенью вероятности возникновения.
Если что-то из этого произойдет, мы, скорее всего, не уложимся в сроки недоступности.
Поделившись оценками рисков с руководством, мы договорились, в какие из них стоит инвестировать, и определили несколько команд для работы над этими сценариями.
Несколько примеров:
- На создание нашей монолитной серверной службы ушло более двадцати минут. Владельцы сервиса оптимизировали конвейер развертывания, чтобы оно выполнялось за меньшее время, и начали проводить регулярные DRT, чтобы гарантировать, что время запуска не увеличится.
- Активация резервных реплик базы данных может занять более двадцати минут, если мы потеряем достаточное количество первичных реплик при выходе из строя всей стойки.
Наша команда метаданных увеличила распространение наших баз данных по стойкам и улучшила инструменты, используемые для активации базы данных.
- Экспериментальные изменения было трудно отследить, и основные команды не смогли бы быстро откатить их в случае чрезвычайной ситуации, поэтому вполне вероятно, что экспериментальный инцидент не будет разрешен менее чем за двадцать минут. Поэтому наша группа экспериментаторов работала над улучшением видимости изменений, обеспечивая четкого владельца каждой экспериментальной функции, а также предоставляя возможности отката и рекомендации для центральных групп реагирования.
Мы продолжаем использовать «правило 20 минут» в качестве критерия для новых сценариев и можем даже ужесточить этот порог в будущем.
Вы можете использовать аналогичную методологию в своей организации или команде.
Напишите список потенциальных инцидентов, на разрешение которых потребуется больше всего времени, расположите их в порядке убывания вероятности и улучшите процессы, которые устраняют их в первую очередь.
Затем проверьте, как на самом деле будет разворачиваться сценарий, используя DRT или упражнения для ваших респондентов.
Сократили ли улучшения время восстановления до уровня, приемлемого для вашего бизнеса? Мы держим фронт на уровне 99,9. Благодаря жесткому соглашению об уровне обслуживания у нас не так много времени, чтобы реагировать, если что-то идет не так, а наш набор технологий постоянно меняется.
Где возникнет следующий риск и на чем мы сосредоточим свои усилия? В дополнение к упомянутым выше изменениям в процессах мы создали авторитетные источники данных в двух областях, которые помогают нам не сбиться с пути:
- Единый источник достоверной информации о нашем SLA и список инцидентов, которые на него повлияли
- Панель мониторинга для отслеживания относительного влияния сервисов друг на друга на критическом пути.
Это гарантирует отсутствие путаницы в отношении того, как вклад каждой команды влияет на гарантии, предоставляемые клиентам.
Трассировка используется для определения того, что находится на критическом пути.
Мы также отслеживаем влияние сервисов на критический путь с помощью распределенной трассировки.
Инфраструктура трассировки используется для расчета веса каждого сервиса.
Этот вес является приблизительным показателем того, насколько важен сервис как часть Dropbox в целом.
Когда вес сервиса превышает порог, вводятся дополнительные требования, обеспечивающие строгость работы с ним.
Эти веса (и автоматизация вокруг них) служат двум целям.
Во-первых, это выступать в качестве еще одной точки данных в нашем процессе оценки рисков; Знание относительной важности услуг позволяет лучше понять, как сравнивать риски в разных системах.
Во-вторых, мы должны быть уверены, что нас не застанут врасплох, когда служба появится на критическом пути.
В системе размером с Dropbox очень сложно отслеживать каждую новую услугу, поэтому автоматическое отслеживание критического пути гарантирует, что мы уловим все.
Оценка воздействия на пользователя «Насколько болезненна эта SEV для наших клиентовЭ» Ответ на этот вопрос не ускорит восстановление, но позволит нам активно общаться с пользователями и быть заслуживающими доверия, что является главной ценностью нашей компании.
Опять же, во время инцидента для пользователей важна каждая минута.
Эта проблема оказалась особенно сложной в отношении SEV для специальных возможностей Dropbox. Как вы, возможно, заметили выше, наши определения уровня SEV начинаются с несколько наивного предположения, что более низкая доступность является более серьезной.
Это определение обеспечивало некоторую простоту по мере роста компании, но в конечном итоге нам не помогло.
Мы столкнулись с SEV с резким снижением доступности, но практически без влияния на пользователей; мы столкнулись с небольшими проблемами, которые даже не дошли до SEV, но мы справились dropbox.com совершенно бесполезно.
Последний случай заставил нас работать всю ночь напролёт, потому что мы рисковали серьезно подвести наших пользователей.
В качестве тактического решения мы сосредоточились на нашем веб-сайте, у которого меньше трафика, чем у настольных и мобильных приложений (это означает, что проблем с доступностью веб-сайта может быть меньше).
Мы работали с командами инженеров, чтобы определить около 20 веб-маршрутов, соответствующих ключевым страницам и компонентам.
Мы начали отслеживать доступность каждого из этих маршрутов, добавляя метрики в информационные панели, уведомления и критерии SEV. Мы обучали менеджеров по инцидентам интерпретировать эти данные, соотносить снижение доступности с конкретными последствиями и общаться с клиентами — и практиковали это на учениях.
В результате во время последующих инцидентов, затронувших веб-сайт, мы быстро определили, были ли затронуты ключевые рабочие процессы пользователей, и использовали эту информацию для связи с клиентами.
Мы считаем, что нам еще есть над чем работать в этой области.
Мы изучаем множество других способов перехода от измерения девяток к измерению пользовательского опыта и с нетерпением ждем проблем, которые это повлечет за собой:
- Можем ли мы классифицировать все маршруты на разных платформах по критичности, чтобы предоставить эту информацию группе реагирования?
- Как вы можете использовать сигналы прямого воздействия на пользователей (например, трафик на страницы статуса или поддержки, поток заявок клиентов, реакции в социальных сетях), чтобы ускорить реагирование инженеров?
- Как в нашем масштабе мы можем эффективно оценить количество уникальных пользователей, пострадавших от инцидента с доступностью, в режиме реального времени? Как получить более точные данные о группах пострадавших - по регионам, службам и т.д. - после происшествия?
- Где мы получим наибольшую выгоду от инструментов на стороне клиента для сквозного измерения пользовательского опыта?
6. Постоянное улучшение
Dropbox не идеален в управлении инцидентами — никто не идеален.Мы начали с процессов SEV, которые в то время отлично работали, но по мере роста компании, систем и числа пользователей нам приходится постоянно развиваться.
Уроки, которые мы описали в этом посте, были даны нам не просто так; Часто требовалось одно-два SEV, чтобы понять, где не хватает нашей реакции на инциденты.
Вот почему важно учиться на своих неудачах каждый раз, когда вы анализируете инцидент. Вы не сможете полностью предотвратить критические инциденты, но можете предотвратить повторение ошибок.
В Dropbox мы начали с культуры отказа от вины при рассмотрении инцидентов.
Если респондент допускает ошибку, мы не виним его.
Спрашиваем, где мы не смогли защититься от человеческого фактора, какой подготовки не хватило, чтобы отреагировать Теги: #инфраструктура #Управление продуктом #сре #ИТ-стандарты #ServiceDesk #процессы в нем #работа с инцидентами #ITSM #управление инцидентами #управление инцидентами
-
Заблуждение О Рынке Даркнета Теперь Раскрыто
19 Oct, 24 -
Новые Технологии Интеграции Crm В 3Cx V15
19 Oct, 24 -
Эффективная Технология Защиты От Спама.
19 Oct, 24 -
Влюбляясь В F#: Доза 0.1: Как Установить F#
19 Oct, 24 -
Зоопарк
19 Oct, 24 -
Качество Кода Сайта Ресо-Гарантия
19 Oct, 24
