home.social

#инцидент — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #инцидент, aggregated by home.social.

  1. Если инцидент закрыт, это не значит, что проблема решена

    Пятница, 23:40, прод лежит. Дежурный поднимает сервис за сорок минут: перезапустил контейнер, всё заработало. Инцидент закрыт, MTTR красивый, все спать. Через десять дней то же самое: тот же сервис, та же ошибка в логах. Снова подняли и снова закрыли.

    habr.com/ru/companies/simpleon

    #ITSM #SDLC #инцидент #баг #Service_Desk #DevOps #MTTR #управление_инцидентами

  2. Если инцидент закрыт, это не значит, что проблема решена

    Пятница, 23:40, прод лежит. Дежурный поднимает сервис за сорок минут: перезапустил контейнер, всё заработало. Инцидент закрыт, MTTR красивый, все спать. Через десять дней то же самое: тот же сервис, та же ошибка в логах. Снова подняли и снова закрыли.

    habr.com/ru/companies/simpleon

    #ITSM #SDLC #инцидент #баг #Service_Desk #DevOps #MTTR #управление_инцидентами

  3. Если инцидент закрыт, это не значит, что проблема решена

    Пятница, 23:40, прод лежит. Дежурный поднимает сервис за сорок минут: перезапустил контейнер, всё заработало. Инцидент закрыт, MTTR красивый, все спать. Через десять дней то же самое: тот же сервис, та же ошибка в логах. Снова подняли и снова закрыли.

    habr.com/ru/companies/simpleon

    #ITSM #SDLC #инцидент #баг #Service_Desk #DevOps #MTTR #управление_инцидентами

  4. Если инцидент закрыт, это не значит, что проблема решена

    Пятница, 23:40, прод лежит. Дежурный поднимает сервис за сорок минут: перезапустил контейнер, всё заработало. Инцидент закрыт, MTTR красивый, все спать. Через десять дней то же самое: тот же сервис, та же ошибка в логах. Снова подняли и снова закрыли.

    habr.com/ru/companies/simpleon

    #ITSM #SDLC #инцидент #баг #Service_Desk #DevOps #MTTR #управление_инцидентами

  5. ML/AI в системе мониторинга: прогнозирование и предотвращение инцидентов

    Привет, Хабр! Меня зовут Павел Степуро, я исполнительный директор ДИТа «Занять и Сберегать» в Сбере. Вы по-прежнему работаете в ИТ, сопровождаете автоматизированные системы и уже ознакомились с моей первой статьёй про путь от создания базовой системы мониторинга к системе автоматизации и принятия решений Именно поэтому вы находитесь здесь… И это продолжение пути. Итак, вы создали систему мониторинга мечты! У вас уже есть посекундный сбор критичных метрик: инфраструктурных, прикладных и бизнес-метрик, и вы думаете о дальнейшем развитии. В этот момент вы понимаете, что после создания системы, которая обнаруживает инциденты в моменте, вам нужно решение, которое будет их предотвращать, своевременно предсказывать сбои и устранять их причины до того, как они повлияют на клиентов и пользователей. И сделать это можно с помощью ML predict-модели, которая будет предсказывать поведение метрик на 15 минут вперёд.

    habr.com/ru/companies/sberbank

    #мониторинг #MLpredict #predictions #алертинг #автоматизация #система_мониторинга #data_scientist_data_analyst #ml #ai #инцидент

  6. Когда стойка умирает, а 5xx остаётся нулевым. Разбор скрытой деградации PostgreSQL

    09:12 — db-replica-02 connection timeout HTTP 5xx = 0.2% HAProxy зелёный p50 = 38-42ms Replica в другой стойке недоступна Отказоустойчивость потеряна Инцидент не объявлен Читать разбор

    habr.com/ru/articles/1002056/

    #PostgreSQL #отказоустойчивость #деградация #retry #HAProxy #PgBouncer #ToR #инцидент #latency #SRE

  7. Когда стойка умирает, а 5xx остаётся нулевым. Разбор скрытой деградации PostgreSQL

    09:12 — db-replica-02 connection timeout HTTP 5xx = 0.2% HAProxy зелёный p50 = 38-42ms Replica в другой стойке недоступна Отказоустойчивость потеряна Инцидент не объявлен Читать разбор

    habr.com/ru/articles/1002056/

    #PostgreSQL #отказоустойчивость #деградация #retry #HAProxy #PgBouncer #ToR #инцидент #latency #SRE

  8. Когда стойка умирает, а 5xx остаётся нулевым. Разбор скрытой деградации PostgreSQL

    09:12 — db-replica-02 connection timeout HTTP 5xx = 0.2% HAProxy зелёный p50 = 38-42ms Replica в другой стойке недоступна Отказоустойчивость потеряна Инцидент не объявлен Читать разбор

    habr.com/ru/articles/1002056/

    #PostgreSQL #отказоустойчивость #деградация #retry #HAProxy #PgBouncer #ToR #инцидент #latency #SRE

  9. Когда стойка умирает, а 5xx остаётся нулевым. Разбор скрытой деградации PostgreSQL

    09:12 — db-replica-02 connection timeout HTTP 5xx = 0.2% HAProxy зелёный p50 = 38-42ms Replica в другой стойке недоступна Отказоустойчивость потеряна Инцидент не объявлен Читать разбор

    habr.com/ru/articles/1002056/

    #PostgreSQL #отказоустойчивость #деградация #retry #HAProxy #PgBouncer #ToR #инцидент #latency #SRE

  10. Здесь и сейчас: как Solar Dozor оперативно обнаруживает угрозы со стороны инсайдеров

    Идеальная модель инсайдерской угрозы формируется при совпадении трех ключевых факторов: доступ к критически важной информации, отсутствие эффективного контроля за её использованием и личная заинтересованность сотрудника. История, которой поделился Виталий Петросян, эксперт группы анализа и методологии защиты данных ГК «Солар», – это наглядная иллюстрация такого «идеального шторма» в одной из фармацевтических компаний. Кейс актуален для бизнеса любой отрасли и любого масштаба. Здесь вы найдете не просто отчёт об инциденте, а детальный разбор того, как уязвимости в процессах (от найма до контроля) превращают бизнес в лёгкую добычу для внутренних нарушителей. Главный вывод по итогам этого расследования касается в первую очередь не технологий, а корпоративной культуры управления рисками. В юридической практике понятия «инсайдерская информация» и «инсайдер» обычно понимаются гораздо шире, чем это определено в Федеральном законе от 27.07.2010 № 224-ФЗ «О противодействии неправомерному использованию инсайдерской информации и манипулированию рынком и о внесении изменений в отдельные законодательные акты Российской Федерации». Они относятся к компаниям любых форм собственности и отраслей. В современной экономике «инсайдерская информация» – это любая точная и конкретная информация, которая не была распространена или вовсе не подлежит распространению (например, коммерческая или банковская тайна, персональные данные клиента и др). «Инсайдер» – физическое лицо, имеющее доступ к инсайдерской информации на основании трудовых и (или) гражданско-правовых договоров.

    habr.com/ru/companies/solarsec

    #солар #информационная_безопасность #кейс #утечка_данных #утечка_информации #инцидент

  11. Здесь и сейчас: как Solar Dozor оперативно обнаруживает угрозы со стороны инсайдеров

    Идеальная модель инсайдерской угрозы формируется при совпадении трех ключевых факторов: доступ к критически важной информации, отсутствие эффективного контроля за её использованием и личная заинтересованность сотрудника. История, которой поделился Виталий Петросян, эксперт группы анализа и методологии защиты данных ГК «Солар», – это наглядная иллюстрация такого «идеального шторма» в одной из фармацевтических компаний. Кейс актуален для бизнеса любой отрасли и любого масштаба. Здесь вы найдете не просто отчёт об инциденте, а детальный разбор того, как уязвимости в процессах (от найма до контроля) превращают бизнес в лёгкую добычу для внутренних нарушителей. Главный вывод по итогам этого расследования касается в первую очередь не технологий, а корпоративной культуры управления рисками. В юридической практике понятия «инсайдерская информация» и «инсайдер» обычно понимаются гораздо шире, чем это определено в Федеральном законе от 27.07.2010 № 224-ФЗ «О противодействии неправомерному использованию инсайдерской информации и манипулированию рынком и о внесении изменений в отдельные законодательные акты Российской Федерации». Они относятся к компаниям любых форм собственности и отраслей. В современной экономике «инсайдерская информация» – это любая точная и конкретная информация, которая не была распространена или вовсе не подлежит распространению (например, коммерческая или банковская тайна, персональные данные клиента и др). «Инсайдер» – физическое лицо, имеющее доступ к инсайдерской информации на основании трудовых и (или) гражданско-правовых договоров.

    habr.com/ru/companies/solarsec

    #солар #информационная_безопасность #кейс #утечка_данных #утечка_информации #инцидент

  12. Здесь и сейчас: как Solar Dozor оперативно обнаруживает угрозы со стороны инсайдеров

    Идеальная модель инсайдерской угрозы формируется при совпадении трех ключевых факторов: доступ к критически важной информации, отсутствие эффективного контроля за её использованием и личная заинтересованность сотрудника. История, которой поделился Виталий Петросян, эксперт группы анализа и методологии защиты данных ГК «Солар», – это наглядная иллюстрация такого «идеального шторма» в одной из фармацевтических компаний. Кейс актуален для бизнеса любой отрасли и любого масштаба. Здесь вы найдете не просто отчёт об инциденте, а детальный разбор того, как уязвимости в процессах (от найма до контроля) превращают бизнес в лёгкую добычу для внутренних нарушителей. Главный вывод по итогам этого расследования касается в первую очередь не технологий, а корпоративной культуры управления рисками. В юридической практике понятия «инсайдерская информация» и «инсайдер» обычно понимаются гораздо шире, чем это определено в Федеральном законе от 27.07.2010 № 224-ФЗ «О противодействии неправомерному использованию инсайдерской информации и манипулированию рынком и о внесении изменений в отдельные законодательные акты Российской Федерации». Они относятся к компаниям любых форм собственности и отраслей. В современной экономике «инсайдерская информация» – это любая точная и конкретная информация, которая не была распространена или вовсе не подлежит распространению (например, коммерческая или банковская тайна, персональные данные клиента и др). «Инсайдер» – физическое лицо, имеющее доступ к инсайдерской информации на основании трудовых и (или) гражданско-правовых договоров.

    habr.com/ru/companies/solarsec

    #солар #информационная_безопасность #кейс #утечка_данных #утечка_информации #инцидент

  13. Здесь и сейчас: как Solar Dozor оперативно обнаруживает угрозы со стороны инсайдеров

    Идеальная модель инсайдерской угрозы формируется при совпадении трех ключевых факторов: доступ к критически важной информации, отсутствие эффективного контроля за её использованием и личная заинтересованность сотрудника. История, которой поделился Виталий Петросян, эксперт группы анализа и методологии защиты данных ГК «Солар», – это наглядная иллюстрация такого «идеального шторма» в одной из фармацевтических компаний. Кейс актуален для бизнеса любой отрасли и любого масштаба. Здесь вы найдете не просто отчёт об инциденте, а детальный разбор того, как уязвимости в процессах (от найма до контроля) превращают бизнес в лёгкую добычу для внутренних нарушителей. Главный вывод по итогам этого расследования касается в первую очередь не технологий, а корпоративной культуры управления рисками. В юридической практике понятия «инсайдерская информация» и «инсайдер» обычно понимаются гораздо шире, чем это определено в Федеральном законе от 27.07.2010 № 224-ФЗ «О противодействии неправомерному использованию инсайдерской информации и манипулированию рынком и о внесении изменений в отдельные законодательные акты Российской Федерации». Они относятся к компаниям любых форм собственности и отраслей. В современной экономике «инсайдерская информация» – это любая точная и конкретная информация, которая не была распространена или вовсе не подлежит распространению (например, коммерческая или банковская тайна, персональные данные клиента и др). «Инсайдер» – физическое лицо, имеющее доступ к инсайдерской информации на основании трудовых и (или) гражданско-правовых договоров.

    habr.com/ru/companies/solarsec

    #солар #информационная_безопасность #кейс #утечка_данных #утечка_информации #инцидент

  14. Инцидент-менеджмент с нуля: практический гайд для растущих команд

    3 часа ночи. Звонок от незнакомого номера. ”Пользователи не могут залогиниться, п****ц”. Вы лихорадочно листаете Slack. Непонятно, где проблема и кого будить. Подняли тестеров — они тоже гадают. Бэкенд? Инфра? Идёте во флудилку в телеге, ищете похожий ник тимлида. Не отвечает. Кто замещает - никто не знает. Начинается массовый обзвон. Через 40 минут находится человек. Смотрит код. “Не моё. Это к Сане — он, кажется, редирект криво поменял в гугл клауд консоли”. Ещё 20 минут — поиск Сани, доступы только у него. Утром все разбитые. CTO вопрошает. И становится ясно: баг простой. Проблема не в коде. Проблема в бардаке. Знакомо? Я тоже через это прошел. И после такой ночи решил: хватит. Нужна система.

    habr.com/ru/articles/982172/

    #инцидентменеджмент #инцидент #sre #постмортем #devops #проектное_управление #duty #oncall

  15. Не рейт-лимитером единым: как управлять нагрузкой в микросервисах

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

    habr.com/ru/companies/yandex/a

    #инцидент #факап #высокие_нагрузки #инженерные_практики #highload++ #highload #микросервисы #микросервисная_архитектура #best_practice #deadline_propagation

  16. Зачем я решил научить Statuser следить за DNS — и что из этого вышло

    Мы привыкли считать, что если сервер доступен и SSL в порядке — значит, всё под контролем. Но иногда сбой происходит раньше , ещё до того, как запрос дошёл до сервера. Меня зовут Михаил Шпаков, я создаю и развиваю сервис мониторинга Statuser. Недавно я общался с руководителем IT-отдела одной компании, которая использует Statuser для мониторинга своих сервисов. Он поделился интересным кейсом: несколько часов подряд у них перестала отправляться почта с корпоративного домена . Сайт работал, сервер был доступен, SSL-сертификат в порядке — всё зелёное, а письма не уходят. Проблема выглядела случайной: часть писем доставлялась, часть возвращалась с ошибкой, а из-за этого срывались заказы и возникали прямые убытки. Когда их команда начала разбираться, выяснилось, что недавно один из сотрудников сменил почтового провайдера и добавил новые MX-записи в DNS, но старые при этом не удалил. В результате часть писем уходила на старый сервер, который уже не принимал почту, а часть — на новый. Снаружи всё выглядело исправно, но на деле домен был «раздвоен» между двумя почтовыми системами . После этого разговора я понял, что в Statuser не хватает отдельного типа мониторинга — контроля DNS-записей . HTTP, SSL и Ping могут быть зелёными, но если в DNS остались старые MX, сервис уже фактически неисправен . Так в Statuser появился новый тип мониторинга — проверки DNS , который помогает замечать изменения, подмены и ошибки в зонах ещё до того, как они превращаются в простои и убытки.

    habr.com/ru/companies/timeweb/

    #statuser #мониторинг #аптайм #инфраструктура #инцидент #уведомления #dns #домен #ssl #timeweb_статьи

  17. Postmortem без обвинений: Миф или реальность?

    Человеческий мозг эволюционировал для выживания в саванне, а не для анализа распределенных систем. Когда что-то идет не так, наш древний мозг кричит: "Найди угрозу! Накажи виновного! Защити племя!" Эта реакция спасала наших предков от саблезубых тигров, но разрушает современные инженерные команды. Статистика, которая отрезвляет:

    habr.com/ru/articles/958042/

    #sre #sreинженер #postmortem #инцидентменеджмент #инцидент

  18. Как принимать решения при сбоях в IT-системах: методы поддержки принятия решений

    Представьте ситуацию: вечер, срабатывает тревога - ваш интернет-магазин лежит в самый разгар распродажи. В логах куча ошибок, но явной причины не видно. Знакомо? Вот тут-то и начинается самое интересное. Я 3 года проработал в отделе сопровождения информационных систем и накопил десятки подобных случаев. Расскажу, как принимать решения, когда стандартные "перезагрузи и проверь" не работают. Понимаю, что кому-то мой опыт может показаться небольшим, а с некоторыми предложенными методами вы не будете согласны - предлагаю всё обсудить в комментариях. Расскажите о том, как это делается у вас в системах, а также поделитесь своим мнением.

    habr.com/ru/articles/899266/

    #itil #itsm #сбой #инцидент #инцидентменеджмент #поддержка #администрирование

  19. (Не) безопасный дайджест: хакерско-инсайдерские комбо, DeepSeek нараспашку, милостивый Apple

    Февраль – все, значит пришла пора узнать, что интересного произошло за последнее время в мире ИБ. Как обычно, выбрали новости на свой вкус: и те, что все обсуждали (подсобрали деталей и нашли мораль), и те, о которых вы могли ничего не слышать (зато свежо и весело). Под катом – о том, где грань между виновником и жертвой инцидента, как человек подставил ИИ и почему расхожий в IT принцип «работает – не трогай» может привести к мировому скандалу.

    habr.com/ru/companies/searchin

    #утечки_информации #apple #илон_маск #deepseek #инсайдер #хакер #мошенничество #инцидент #информационная_безопасность #сёрчинформ

  20. Detection is easy. Устанавливаем OPNSense и настраиваем NetFlow

    Продолжаем серию статей. - Detection is easy , посвященных Detection engineering (DE), о чем я пишу в одноименном Telegram-канале . Сегодня мы рассмотрим установку OPNSense на Proxmox и настройку отправки NetFlow на коллектор ElastiFlow, который мы настроили в прошлой статье . Для начала подключимся к Proxmox VE и создадим виртуальную машину с двумя интерфейсами.

    habr.com/ru/articles/873382/

    #информационная_безопасность #мониторинг #мониторинг_сети #инцидент_кибербезопасности #инциденты_иб #инциденты_безопасности #инцидент #инциденты #обнаружение_атак #обнаружение_аномалий

  21. Detection is easy. Устанавливаем Elastiflow для поиска угроз в сети

    Начнем серию статей под названием Detection is easy , посвященных Detection engineering (DE), о чем я пишу в одноименном Telegram-канале . Один из этапов DE - определение источников событий и организация их сбора. В этой статье мы рассмотрим установку Elastiflow — это мощное решение для обработки и визуализации сетевых данных, построенное на основе стека ELK (Elasticsearch, Logstash, Kibana). Elastiflow предоставляет возможность собирать, обрабатывать и анализировать данные из различных сетевых протоколов, таких как NetFlow, sFlow и IPFIX. Основное преимущество Elastiflow по сравнению с классическим ELK-стеком заключается в оптимизированном агенте сбора сетевой телеметрии, а также в наличии готовых дашбордов и визуализаций, которые упрощают анализ сетевого трафика. Изначально проект развивался на GitHub , однако разработчики перешли к коммерческому решению — flow-collector , который демонстрирует значительно более высокую производительность по сравнению с версией, доступной на GitHub. Более подробную информацию о различиях можно найти в документации . Политика лицензирования позволяет бесплатно использовать продукт, но если ты зарегистрируешься, то будет доступно порядка 480 полей и использование одного инстанса (4000 записей в секунду, без регистрации 500).

    habr.com/ru/articles/871898/

    #netflow #elastic #elastiflow #инцидент #обнаружение_атак #обнаружение_аномалий #компьютерная_безопасность #компьютерная_криминалистика #компьютерные_сети

  22. [Перевод] Гражданский суд против Big Farma. Законы Австралии, FDA и псевдоэфедрин

    Все началось с того, как FDA предложили изъять из продажи в США некоторые безрецептурные препараты от простуды и гриппа. Дескать: «эти препараты неэффективны». В этот же момент австралийская юридическая фирма подала коллективный иск против фармацевтического гиганта Johnson & Johnson, утверждая, что компания на протяжении многих лет сознательно продвигала и продавала неэффективные противоотечные средства. А камнем преткновения стал псевдоэфедрин.

    habr.com/ru/articles/870932/

    #Big_Farma #FDA #правовой_статус #инцидент #австралия #псевдоэфедрин #johnson_johnson

  23. Одна опция TCP-стека спасет приложение от даунтайма

    Всем привет, меня зовут Вадим Макеров, я работаю в iSpring бэкенд-разработчиком. Однажды у нас в продукте был инцидент, который привел к даунтайму LMS и происходил несколько раз, в течении нескольких дней. Причина оказалась нетривиальной и находилась на уровне сетевых настроек подключений между сервисами. Узнать что за опция спасает от даунтайма

    habr.com/ru/companies/ispring/

    #tcp #go #сеть #микросервисы #распределенные_системы #service_mesh #инцидент #kubernetes

  24. Одна опция TCP-стека спасет приложение от даунтайма

    Всем привет, меня зовут Вадим Макеров, я работаю в iSpring бэкенд-разработчиком. Однажды у нас в продукте был инцидент, который привел к даунтайму LMS и происходил несколько раз, в течении нескольких дней. Причина оказалась нетривиальной и находилась на уровне сетевых настроек подключений между сервисами. Узнать что за опция спасает от даунтайма

    habr.com/ru/companies/ispring/

    #tcp #go #сеть #микросервисы #распределенные_системы #service_mesh #инцидент #kubernetes

  25. Одна опция TCP-стека спасет приложение от даунтайма

    Всем привет, меня зовут Вадим Макеров, я работаю в iSpring бэкенд-разработчиком. Однажды у нас в продукте был инцидент, который привел к даунтайму LMS и происходил несколько раз, в течении нескольких дней. Причина оказалась нетривиальной и находилась на уровне сетевых настроек подключений между сервисами. Узнать что за опция спасает от даунтайма

    habr.com/ru/companies/ispring/

    #tcp #go #сеть #микросервисы #распределенные_системы #service_mesh #инцидент #kubernetes

  26. Одна опция TCP-стека спасет приложение от даунтайма

    Всем привет, меня зовут Вадим Макеров, я работаю в iSpring бэкенд-разработчиком. Однажды у нас в продукте был инцидент, который привел к даунтайму LMS и происходил несколько раз, в течении нескольких дней. Причина оказалась нетривиальной и находилась на уровне сетевых настроек подключений между сервисами. Узнать что за опция спасает от даунтайма

    habr.com/ru/companies/ispring/

    #tcp #go #сеть #микросервисы #распределенные_системы #service_mesh #инцидент #kubernetes

  27. Современный on-call менеджмент: 5 основных шагов от мониторинга до постмортема

    Управление инцидентами - это порой ночной кошмар любого ИТ-директора. Поднимите руку те, у кого не было ночных сообщений, что упал критический сервис! Почему так мало рук? Да потому что этот самый процесс в большинстве компаний устроен криво. Каждый раз его придумывают заново, проходя путь от ручного режима, далее общей почты или телеграмм группы до самописной системы управления инцидентами. И чем позже мы приходим в компанию выправлять процесс, тем больше сопротивления и непонимания “А что так можно было?”. Помню, как 8 лет назад я руководил сервисной службой в компании, которая предоставляла услуги поддержки важной внутренней системы крупного клиента. Однажды ночью, примерно в три часа, мой телефон разрывается от звонка. На экране — заказчик. Не успеваю сказать "алло", как слышу: "Вы там спите что ли? У нас АСУ ПОБСУ лежит! Вы в курсе почему? (Я молчу) Мы больше не будем с вами работать!" — и бросает трубку.

    habr.com/ru/companies/monq/art

    #мониторинг_логов #мониторинг #инцидентменеджмент #инцидент #алерты #алертинг #oncall #lowcode #low_code #nocode

  28. Современный on-call менеджмент: 5 основных шагов от мониторинга до постмортема

    Управление инцидентами - это порой ночной кошмар любого ИТ-директора. Поднимите руку те, у кого не было ночных сообщений, что упал критический сервис! Почему так мало рук? Да потому что этот самый процесс в большинстве компаний устроен криво. Каждый раз его придумывают заново, проходя путь от ручного режима, далее общей почты или телеграмм группы до самописной системы управления инцидентами. И чем позже мы приходим в компанию выправлять процесс, тем больше сопротивления и непонимания “А что так можно было?”. Помню, как 8 лет назад я руководил сервисной службой в компании, которая предоставляла услуги поддержки важной внутренней системы крупного клиента. Однажды ночью, примерно в три часа, мой телефон разрывается от звонка. На экране — заказчик. Не успеваю сказать "алло", как слышу: "Вы там спите что ли? У нас АСУ ПОБСУ лежит! Вы в курсе почему? (Я молчу) Мы больше не будем с вами работать!" — и бросает трубку.

    habr.com/ru/companies/monq/art

    #мониторинг_логов #мониторинг #инцидентменеджмент #инцидент #алерты #алертинг #oncall #lowcode #low_code #nocode

  29. Современный on-call менеджмент: 5 основных шагов от мониторинга до постмортема

    Управление инцидентами - это порой ночной кошмар любого ИТ-директора. Поднимите руку те, у кого не было ночных сообщений, что упал критический сервис! Почему так мало рук? Да потому что этот самый процесс в большинстве компаний устроен криво. Каждый раз его придумывают заново, проходя путь от ручного режима, далее общей почты или телеграмм группы до самописной системы управления инцидентами. И чем позже мы приходим в компанию выправлять процесс, тем больше сопротивления и непонимания “А что так можно было?”. Помню, как 8 лет назад я руководил сервисной службой в компании, которая предоставляла услуги поддержки важной внутренней системы крупного клиента. Однажды ночью, примерно в три часа, мой телефон разрывается от звонка. На экране — заказчик. Не успеваю сказать "алло", как слышу: "Вы там спите что ли? У нас АСУ ПОБСУ лежит! Вы в курсе почему? (Я молчу) Мы больше не будем с вами работать!" — и бросает трубку.

    habr.com/ru/companies/monq/art

    #мониторинг_логов #мониторинг #инцидентменеджмент #инцидент #алерты #алертинг #oncall #lowcode #low_code #nocode

  30. Современный on-call менеджмент: 5 основных шагов от мониторинга до постмортема

    Управление инцидентами - это порой ночной кошмар любого ИТ-директора. Поднимите руку те, у кого не было ночных сообщений, что упал критический сервис! Почему так мало рук? Да потому что этот самый процесс в большинстве компаний устроен криво. Каждый раз его придумывают заново, проходя путь от ручного режима, далее общей почты или телеграмм группы до самописной системы управления инцидентами. И чем позже мы приходим в компанию выправлять процесс, тем больше сопротивления и непонимания “А что так можно было?”. Помню, как 8 лет назад я руководил сервисной службой в компании, которая предоставляла услуги поддержки важной внутренней системы крупного клиента. Однажды ночью, примерно в три часа, мой телефон разрывается от звонка. На экране — заказчик. Не успеваю сказать "алло", как слышу: "Вы там спите что ли? У нас АСУ ПОБСУ лежит! Вы в курсе почему? (Я молчу) Мы больше не будем с вами работать!" — и бросает трубку.

    habr.com/ru/companies/monq/art

    #мониторинг_логов #мониторинг #инцидентменеджмент #инцидент #алерты #алертинг #oncall #lowcode #low_code #nocode

  31. Selectel Network Meetup: регуляторика, защита сетей, инцидент-менеджмент, сети Clos

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

    habr.com/ru/companies/selectel

    #selectel #network #clos #сети #защита_сети #инцидент

  32. Доверяй, но проверяй: история расследования инцидента на основе OSINT

    Меня зовут Анастасия Гаранжа, я аналитик центра мониторинга и реагирования на инциденты МТС RED SOC. Недавно мы столкнулись с любопытной атакой, которая ещё раз показала, что оперативность выявления инцидентов кибербезопасности почти всегда зависит от экспертности и скорости реакции аналитиков. А вот автоматизация и даже OSINT иногда бессильны, а такой случай может оказаться критическим. Под катом — история расследования инцидента.

    habr.com/ru/companies/ru_mts/a

    #информационная_безопасность #исследования_в_it #инцидент

  33. Респонс по DaVinci: как мы перевернули систему работы Security-аналитика и что из этого вышло

    Как обычно происходит стандартное реагирование в SOC? Получил аналитик оповещение об инциденте от какой-то системы безопасности, посмотрел логи SIEM, чтобы собрать дополнительные данные, уведомил заказчика и составил для него короткий отчет о произошедшем. А что дальше? А дальше — переключился на новый инцидент или ожидает его появления. В крайних случаях — участие в расследовании инцидентов и разработка новых сценариев выявления атак. Такова «хрестоматийная», стандартная схема работы аналитика в коммерческом SOC. Это и не хорошо, и не плохо — это, как правило, просто данность. Однако формат действий security-аналитика можно сделать кардинально иным, и за счет этого помочь амбициозному специалисту расти быстрее и шире, а компании-заказчику — дополнительно укрепить свою безопасность. Я, Никита Чистяков, тимлид команды security-аналитиков в «Лаборатории Касперского». Под катом я расскажу, как и зачем в Kaspersky помогаю выстраивать новые условия работы для security-аналитиков и как эти условия помогают им стать эдакими витрувианскими ИБшниками эпохи Возрождения. Если вы сами аналитик или в целом работаете в инфобезе, хотите узнать, какой скрытый потенциал есть у профессии и как его раскрыть, эта статья — для вас.

    habr.com/ru/companies/kaspersk

    #лаборатория_касперского #респонс #soc #incident_responce #incident #инцидент #securityаналитик #security_analyst #разработка #r&d #Threat_Intelligence #Threat_Hunting #GReAT #AMR #anti_malware_research #форензика #IoC #ИБ #hr #сотрудники #управление_командой #управление_людьми #карьера #управление_персоналом #карьера_в_itиндустрии #карьера_в_it #карьера_итспециалиста #работа #информационная_безопасность #кибербезопасность #безопасность #уязвимости #кибератаки #пентест #исследование #аналитика #рынок_труда #рынок_труда_в_ит #найм_персонала #тенденции #хедхантеры