За последний год Amixr провели несколько десятков интервью со своими пользователями и дежурными инженерами из таких компаний, как Google, Facebook, Dropbox, SoundCloud, чтобы получить инсайты о том, что же такое эффективный инцидент-менеджмент. Кроме того, через инфраструктуру Amixr проходят более трехсот тысяч инцидентов ежемесячно.
Всю эту информацию и собственный опыт Amixr и Proto собрали в едином вебинаре в эту среду, 09 декабря в 16:00. Для участия достаточно пройти быструю регистрацию.
Данный вопрос не имеет простого решения — ведь для выбора правильной стратегии по защите бизнеса необходимо провести детальный анализ, уточнить цели и выбрать правильный подход для их достижения. Как правило, наиболее оптимальным подходом для средних и крупных компаний будет поэтапное внедрение системы безопасности: начав с защиты наиболее критичных активов, постепенно расширять область, включая менее приоритетные. Большие дела начинаются с малого, и чтобы получить гарантию того, что система безопасности будет развиваться в правильном направлении и достигнет требуемого уровня зрелости к определенному сроку, необходимо уделить особое внимание самим процессам, призванным защищать компанию. Такими процессами являются управление инцидентами, рисками, управление непрерывностью, управление доступом, контроль изменений и многие другие. Если компания уделяет достаточно внимания правильности исполнения таких процессов, то проект по построению системы безопасности практически обречен на успех.
Еще одна компактная статься Стюарта Рейнса про то, чем измерять результативность процессов.
Оригинал Defining Metrics for Incident Management By Stuart Rance
Опубликовано September 23, 2014
Достоинства - хорошая иллюстрация декомпозита цели-показатели-метрики, качественный пример показателей, настойчивое напоминание о подходе “адаптируй и применяй”
Недостатки - очень компактно написано, хочется чуть больше примеров и пояснений к ним.
Сложность материала - базовая.
Оценка - 8/10.
Здесь и ниже курсовом комментарии переводчика.
Мы в Dropbox считаем, что управление инцидентами — это центральный элемент нашей системы по обеспечению надёжности. И хотя мы также используем проактивные методы, такие как хаос-инжиниринг (сhaos engineering), то, как мы реагируем на инциденты существенное влияет на опыт наших пользователей. Во время потенциального сбоя сайта или проблемы с продуктом на счету каждая минута.
Ключевые компоненты нашего процесса управления инцидентами существуют уже несколько лет, но мы видим возможности для постоянного развития в этой области. Изменения, которые мы внесли с течением времени, включают в себя как технологические, так и организационные, и процедурные улучшения.
В этом посте мы расскажем подробно о нескольких уроках, которые Dropbox вынесли из опыта управления инцидентами. Вероятнее всего, не каждый из пунктов можно найти в методичке по структуре управления инцидентами, и не стоит думать, что эти улучшения универсальны для любой компании. (Полезность этих уроков зависит от вашего технологического стека, размеров организации и других факторов). Вместо этого мы надеемся, что эта статья послужит примером, как вы можете систематически анализировать реакцию на инциденты в вашей компании и улучшать её так, чтобы удовлетворить потребности ваших пользователей.
Повышение осведомленности работников в области информационной безопасности и поиск способов оперативного сбора информации об инцидентах (или иных подозрительных событиях) прямо от работников может завести безопасника к созданию бота.
Бота можно сделать для Telegram, Whatsapp, написать свой сайтик, написать приложение для VK, написать приложение для иного часто используемого приложения работниками. В данном примере рассмотрим бота созданного через Microsoft Power virtual agents для Microsoft Teams.
Привет Хабр! Не так давно общался с SRE в нашей команде и он рассказал мне о базовых принципах процесса управления инцидентами, теперь я поделюсь этим с вами, быть может кому‑то поможет.
Управление инцидентами включает в себя мониторинг, анализ, планирование и выполнение. SRE работают с операционными группами, экспертами по техническим вопросам, разработчиками, инженерами DevOPs, владельцами приложений и другими.
При оценке инцидентов SRE обращают внимание на такие критерии, как импакт и частота повторения — для того, чтобы определить, какие инциденты требуют дальнейшего анализа.