home.social

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

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

fetched live
  1. ИИ-помощник PT Naira в MaxPatrol SIEM: почему аналитик перестал искать и начал спрашивать

    Аналитики SOC — неважно, работают ли они в большой команде или в маленькой — регулярно говорят мне, что видят все срабатывания корреляционных правил, но не успевают в них ра не значит, что они плохо работают. SOC в крупной организации фиксирует более 10 000 срабатываний в день, и физически невозможно для каждого из них вручную поднять контекст, свериться с базой знаний и принять решких условиях нерасследованными остаются почти две трети срабатываний, в большинстве своем — те, которым присвоены невысокие уровни значимости. Это позволяет злоумышленнику «замаскироваться под фон». Когда мы в Positive Technologies моделировали поведение инсайдера в корпоративной инфраструктуре, традиционная система, построенная на сигнатурах и корреляционных правилах, выдала лишь три алерта с уровнями значимости medium и low. Чтобы в подобных ситуациях не упускать важные события и корректно присваивать им уровни риска, в MaxPatrol SIEM встроен модуль поведенческого анализа MaxPatrol BAD. Но сам факт того, что событие не затерялось в потоке, ещё не снимает с аналитика необходимость разобраться в нём. Вот в этой точке — между «система что-то нашла» и «специалист понял, что перед ним» — и лежит разрыв, который мы решили закрывать с помощью ИИ.

    habr.com/ru/companies/pt/artic

    #soc #ai #кибератаки #cybersecurity #инциденты #aiассистент

  2. Фатал на проде. Разбор без поиска виноватого

    Я руковожу отделом разработки в видеосервисе. Расскажу про инцидент, который мы пытались разобрать как ошибку конкретного человека, а в итоге нашли дыру в процессе. История банальная ровно настолько, чтобы случиться у многих. Что произошло Задача: изменить стоимость тарифа подписки. Тестировщик проверил основные сценарии: активация подписки, автопродление, отключение, обработка платежей. Все прошло, задача уехала в прод. Через несколько недель начали приходить жалобы. Выяснилось: у пользователей, у которых есть история платежей, но подписка на текущий момент не активна, при обращении к разделу подписки падает фатальная ошибка. Сценарий звучит экзотично ровно до момента, когда понимаешь, сколько у сервиса таких пользователей. Любой, кто когда-то оформлял подписку и потом отписался, попадает в эту категорию.

    habr.com/ru/articles/1096826/

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

  3. Хронология инцидентов с ИИ-агентами: два разных класса и чек-лист изоляции для своего агента

    За три месяца OpenAI, Anthropic, Google и Meta раскрыли серию случаев, когда агенты вышли за рамки теста или задачи. Агентство AP собрало их в одну хронологию, но в ней смешаны два разных типа происшествий с разными причинами. Ниже разбор, чем они отличаются, и список из восьми проверок, который можно применить к своему агенту.

    habr.com/ru/companies/syntx_ai

    #изоляция #gemini #песочница #инциденты #openai #anthropic #hugging_face #безопасность_ии #ииагенты

  4. Дежурный бот вырос еще раз: отдел логистики, алерты, постмортемы

    Дежурный бот в MAX перестал быть «рассыльщиком в три канала». Мы добавили отдельный канал для логистики с P85 вместо SLA, статус-карточки /status, postmortem-чаты после закрытия сбоя, web UI и первый заход Alerta → LifePOS. Рассказываю, как закрывали дыры жизненного цикла инцидента - от сигнала до разбора - и что ответила команда логистики.

    habr.com/ru/companies/petrovic

    #бот #max #sre #itsm #инциденты #мониторинг #postmortem #alerta #автоматизация #fastapi

  5. [Перевод] Когда избыточность не спасает: как один сервер сделал объектное хранилище недоступным

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

    habr.com/ru/companies/otus/art

    #отказоустойчивость #постмортем #мониторинг #инфраструктура #инциденты #DevOps #sre #Kubernetes #высокая_доступность

  6. Как проверить postmortem, подготовленный LLM. Разбираем инцидент Cloudflare

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

    habr.com/ru/companies/otus/art

    #postmortem #LLM #инциденты #SRE #DevOps #надёжность_систем #отказоустойчивость #мониторинг #production #ретроспектива

  7. LLM не должен читать логи без ограничений: безопасный MCP-шлюз для разбора сбоев

    Как дать LLM разбирать сбои в пайплайнах, не открывая ей доступ к сырым логам и произвольным SQL-запросам

    habr.com/ru/articles/1083486/

    #MCP #LLM #безопасность #инженерия_данных #пайплайны #инциденты #SQL #python #агентская_разработка #data_engineering

  8. Как построить наблюдаемость, когда нет ни CMDB, ни oncall

    Привет! Это Скутин Антон. Я работаю в «Петрович-Тех» руководителем отдела обеспечения доступности ИТ-сервисов. Моя предыдущая статья была про ITIL . В этот раз я решил рассказать о том, как построить наблюдаемость, когда нет ни CMDB, ни oncall. Эту тему я рассказывал на Observability Conf, коллеги завалили вопросами, поэтому решил поделиться здесь, подключайтесь в комментарии — обсудим!

    habr.com/ru/companies/petrovic

    #sre #devops #observability #мониторинг #инцидентменеджмент #наблюдаемость #itsm #zabbix #prometheus #Инциденты

  9. 200 OK от гейтвея ничего не значит

    Обычная HTTP-проверка может показывать, что ИИ-сервис работает, хотя его пользователи уже не получают ответы. Эндпоинт доступен, гейтвей на месте, но до самой модели проверка не доходит. Привет, Хабр! Меня зовут Михаил Шпаков, я развиваю

    habr.com/ru/companies/timeweb/

    #мониторинг #LLM #API #OpenAI #Anthropic #DevOps #инциденты #Statuser #uptime #timeweb_статьи

  10. Каскад из одной аварии: как схлопнуть шторм алертов в одну карточку инцидента

    Падает один шлюз - и дежурному прилетает пачка уведомлений: молчат хосты за ним, гаснет uptime-монитор, срабатывают метрические пороги, горит SLO. Событие одно, уведомлений десятки. Разбираю, как собрать такой каскад в одну карточку инцидента и почему наивная реализация ломается: почему группировать надо по верхнему упавшему предку, а не по прямому родителю; что делать, когда события приходят в обратном порядке; почему “молчит, потому что за него сказал корень” и “не эскалируется, потому что родитель лежит” - это два разных состояния, которые нельзя склеивать; и где в такой системе обязательно выбирать шум вместо тишины. С кодом обхода графа, схемой таблиц и списком граблей.

    habr.com/ru/articles/1074588/

    #мониторинг #алертинг #инциденты #observability #эскалация #selfhosted #golang #postgresql #sre

  11. 11 минут у Backblaze, и неделя бездействия у reg.ru: как компании обрубают инфраструктуру трояна в России и за рубежом

    Привет, хабр. Если вы состоите в более-менее крупных ТГ сообществах, то наверняка замечали, как время от времени в чатах мелькают боты с предложением установить сомнительный APK. Обычно их мгновенно банит антиспам или админ, и на этом всё заканчивается. Правда, пока сообщение ещё висит, взгляд успевает за него зацепиться, и в голове проскакивает "это очевидно скам, но как оно работает?". У меня эта мысль проскочила в дождливый вечер прошлой пятницы, и вот, неделю спустя, я всё ещё смотрю на четыре домена, куда уходят перехваченные банковские коды, и ожидаю хоть каких-до действий от уполномоченных компаний, которые были уведомлены об атаке почти неделю назад. В этой статье я хочу пробежаться по инциденту: как вирус распространяется, что у него под капотом, и как различные компании и организации реагируют на сообщения о том, что их инфраструктура используется для взлома.

    habr.com/ru/articles/1076024/

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

  12. Тимлид и subnet-полукровка: как одна строчка в YAML стоила $50 000 и двенадцати часов прода

    Однажды, морозным ноябрьским утром 2024 года, я, как новоиспечённый тимлид не такой уж и маленькой команды, поверил в себя и в то, что спустя полгода изучения проекта и передачи дел от предшественника я полностью понимаю, как там всё устроено. Судьба обычно наказывает за самоуверенность. Не стал исключением и мой случай. Для понимания контекста добавлю, что я НЕ девопс - мне пришлось этим заниматься, и всё пишу через призму своего понимания проблемы. Возможно, сейчас придёт корифей AWS/CDK и скажет, что всё можно было сделать проще. Другими словами, не является индивидуальной инвестиционной рекомендацией. Смотреть страху в лицо

    habr.com/ru/articles/1068794/

    #aws #cloudformation #aws_cdk #постмортем #aurora #rds #iac #инциденты #vpc #devops

  13. Качественный и количественный анализ инцидентов в России за 2020–2025 годы

    Мы уже обсуждали общий ландшафт кибератак и защитных стратегий ИБ в 2020–2025 годах в нашей статье на Хабре . Тогда мы описали сдвиг от публичных вымогательских атак к скрытым операциям под контролем государственных. Теперь пришло время собрать под неё полноценную доказательную базу, и для этого обратимся к открытым отчётам российских SOC. Эта статья показывает, как изменились правила игры в кибербезопасности, и позволяет оценить, что эти изменения значат для бизнеса, государства и каждого, кто отвечает за защиту цифровых активов. Материалы, собранные за пять лет, дают основу для того, чтобы задуматься: насколько ваша организация готова к новым вызовам и какие шаги стоит предпринять уже сейчас.

    habr.com/ru/companies/gaz-is/a

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

  14. Мы чинили инциденты всё быстрее — а недовольство клиентов росло. Почему MTBF важнее MTTR

    Инцидентов стало в два раза больше. Время восстановления сократилось вдвое. Uptime сервисов держался в норме. По всем ключевым метрикам мы становились лучше. А обращения в саппорт росли, аккаунт-менеджеры передавали жалобы, и в клиентском чате всё чаще писали, что сервис нестабилен. Эта статья о том, как метрики надёжности могут хором врать о клиентском опыте, почему установка «чините быстрее» — ловушка, которая сжигает дежурных инженеров и прячет настоящую причину проблем, и как мы развернули фокус с MTTR на MTBF, сократили количество инцидентов вдвое и вернули поток обращений клиентов к норме.

    habr.com/ru/articles/1064948/

    #mtbf #mttr #sre #надежность #метрики #инциденты #управление_разработкой

  15. Сократили цикл разработки на 20% — и получили вдвое больше инцидентов

    В продуктовой B2B-компании, где я отвечал за надёжность, поставили амбициозную цель: сократить цикл разработки (dev cycle time) на 20%. Забегая вперёд, скажу: к концу года цель достигли. Но уже через несколько месяцев после старта я смотрел на график инцидентов и не верил своим глазам: рост в два раза год к году. Эта статья — о том, почему так происходит почти всегда, когда компания оптимизирует одну метрику, как мы это починили и — главное — как продать решение руководству. Именно на продаже всё обычно и умирает.

    habr.com/ru/articles/1059894/

    #контрметрики #sre #метрики #надёжность #управление_разработкой #инциденты #dev_cycle_time

  16. Что я узнал за год, мониторя 6 500 сайтов: 108 312 падений в цифрах

    Привет, Хабр! Меня зовут Михаил Шпаков, я руковожу разработкой в Timeweb Cloud и развиваю

    habr.com/ru/companies/timeweb/

    #мониторинг_сайтов #аптайм #uptime #доступность_сайтов #инциденты #статистика #sslсертификаты #таймауты #статусстраницы #statuser

  17. Учимся на чужих ошибках: 5 управленческих просчётов, которые превращают ИТ-сбой в остановку бизнеса

    В 2023 году злоумышленники позвонили в сервис-деск Clorox — международного производителя бытовой химии и товаров для дома. Представившись сотрудниками компании, они убедили службу поддержки восстановить доступ к корпоративным системам. Последствия быстро вышли за пределы ИТ. Компания столкнулась с нарушением производства и отгрузок, дефицитом продукции и снижением продаж. Только прямые дополнительные расходы, признанные к концу 2023 года, составили около $49 млн. Это не уникальная история. За последние годы похожие по масштабу последствия возникали из-за отказа подрядчика, дефектного обновления, непроверенного восстановления и даже нехватки места на сервере. В статье разберём пять повторяющихся управленческих просчётов, проявившихся в крупных инцидентах 2023–2025 годов, и посмотрим, как проверить наличие таких рисков в собственной ИТ-службе.

    habr.com/ru/articles/1058602/

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

  18. Как российские хостинги (и нас особенно) знатно штормило в мае-июне, и почему некоторые теперь не пишут на Хабре

    За два месяца на индустрию высыпалось очень много неприятностей. Из голландского ЦОДа кто-то атаковал правительственные сервисы ЕС, и там сделали массовое изъятие примерно 800 серверов, как бы у нас сказали, почти по беспределу. Но, поскольку это Европа, — в соответствии с духом просвещённой демократии. Сам дата-центр, когда узнал, что произошло, утрируя, поспешно разорвал контракты с оставшимися русскими, теми, кто знаком с Россией, с ней работает или вообще что-то про неё слышал. А второй ЦОД, где любили вставать хостинги, поплавился от жары. На самом деле это не совсем так, но на жару очень удобно списывать. Кто ж знал, что лето настанет! Тут интересно то, что никто ничего нормально не рассказывал клиентам, и, собственно, поэтому посты этих хостингов на Хабре превратились в жалобную книгу на некоторое время. Поэтому постить некоторые перестали, чтобы не размывать репутацию своих славных брендов. Мы было успели обрадоваться, что нас не задело, но тут же случилось изъятие уже наших серверов в Казани. Приехали в дата-центр типа на осмотр и выгребли всё подчистую — копали под одного клиента. И очень интересно грузили и возили. Но мы об этом узнали не сразу. В общем, там тоже феерическая история, сейчас расскажу. И напоследок прилетел масштабный DDoS, а потом ещё память подорожала на 70%, притом что в потребительском сегменте за месяц всего на 1—5%. И да, я тот человек, который считал, что 2023 был тяжёлым годом. Но теперь есть с чем сравнить!

    habr.com/ru/companies/ruvds/ar

    #хостинг #датацентры #инциденты #изъятие_серверов #ddosатаки #серверное_оборудование #резервное_копирование #SLA #инфраструктура #хостингпровайдер

  19. 0 дней без инцидента. Расследуем атаку и восстанавливаемся после неё

    Привет! В первой части, «Как и чем ломали российские компании» , мы рассказали о тактиках и техниках злоумышленников, а также о том, как вовремя обнаружить их в инфраструктуре вашей компании. Сегодня же поделимся второй частью нашего

    habr.com/ru/companies/jetinfos

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

  20. Инциденты под контролем: дежурный бот, MAX и путь к SRE-помощнику

    Привет, это снова Максим Королёв из Петрович-ТЕХ — сервисный менеджер, который автоматизирует всё, до чего дотянутся руки. Сегодня расскажу, как бот для дежурств научился не ждать команды, а действовать первым. Есть такое наблюдение, которое знакомо любому, кто хоть раз дежурил - закон Мерфи: самое неприятное случается в момент, когда ты отошёл за кофе. Именно он стал одним из главных аргументов в пользу проактивного бота, который не ждёт, пока ты нажмёшь кнопку, а сам пинает тебя о приближающихся работах и собирает участников для устранения инцидентов. В первой статье «Дежурный» был одним из семейства Telegram-ботов для ITSM: сбой → Jira → канал, оформление за минуту вместо десяти. Во второй - когда Telegram падал в разгар аварии - я вынес логику в CORE и подключил MAX как второй мессенджер: одно ядро, два входа, паттерн reply_fn. С тех пор бот перестал быть просто кнопкой «завести сбой», а постепенно превратился в SRE-помощника на смене. Теперь он автоматически заранее уведомляет о предстоящих регламентных работах, инициирует war room (чаты) для конкретного инцидента, по справочнику зовёт ответственных, заполняет поля в Jira и отдает статистику по сервисам - всё из мессенджера. Дальше - о том, что я добавил, как это легло на архитектуру CORE и какие решения оказались рабочими, когда интеграций стало больше, чем кнопок в меню.

    habr.com/ru/companies/petrovic

    #бот #max #sre #itsm #инциденты #системное_администрирование #core #параллельная_рассылка #reply_fn

  21. Ваши постмортемы — это поминки. И добрая половина процессов в компании тоже

    Однажды я зашёл в компанию через неделю после крупного падения и попросил показать постмортем. Мне показали — с гордостью. Таймлайн поминутно, five whys, аккуратный список action items, owner напротив каждого, разослано по всем спискам. Красиво. «Видите, мы серьёзно подошли». Я задал один вопрос: а постмортем по прошлому такому же падению — где? Нашли. Открыли. Те же action items. Слово в слово. С прошлого раза не закрыт ни один. То есть полгода назад уже собирались, уже всё проанализировали, уже назначили ответственных — и ничего не сделали. А потом упало снова, по той же причине, и они снова собрались, снова проанализировали, снова назначили. С тем же результатом, который будет и в следующий раз. И вот тут важно не поспешить с выводом «разгильдяи, не довели». Потому что если присмотреться, этот постмортем не провалился. Он отлично сработал. Просто работа у него была не та, что написана на упаковке. Я вхожу в чужие инженерные команды со стороны — посмотреть, что там происходит на самом деле, и навести порядок. И почти в каждой натыкаюсь на одно и то же: изрядная часть процессов в компании существует не чтобы что-то делать, а чтобы что-то изображать. Это не патология конкретной конторы. Это закономерность, у неё есть механика, и её полезно научиться видеть — особенно если ты за эти процессы отвечаешь.

    habr.com/ru/articles/1051542/

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

  22. Пять самых крупных ошибок, которые допускают компании при внедрении SRE

    SRE часто внедряют как набор инструментов, дашбордов и новых должностей, но через полгода команда всё так же тушит инциденты по ночам, а бюджеты ошибок живут только в таблицах. В статье разбираем 5 типичных провалов при внедрении SRE: от формального переименования эксплуатации до поспешной покупки AIOps без нормального observability. Это разбор о том, почему надежность ломается не только в инфраструктуре, но и в процессах, метриках, найме и управленческих стимулах. Разобрать ошибки

    habr.com/ru/companies/otus/art

    #Site_Reliability_Engineering #SRE #надежность_систем #распределенные_системы #мониторинг #observability #slo #бюджет_ошибок #инциденты

  23. Между нами SLA: как бизнесу и поддержке договориться до первого инцидента

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

    habr.com/ru/articles/1032878/

    #системное_администрирование #devops #sla #техническая_поддержка #мониторинг_сервера #инциденты #ревью_кода #рефакторинг #аварийное_восстановление #аварийные_ситуации

  24. Как понять, что мониторинг в ЦОДе шумит

    Днём на работе вокруг всегда коллеги, созвоны, обсуждения в чатах. Если что-то непонятно, можно быстро спросить совета у более опытных инженеров. Ночью всё по-другому. Дежурный остаётся один на один с системой оповещений, и разбираться приходится самостоятельно. Наверное, поэтому одна из самых странных вещей в мониторинге проявляется именно ночью. На одном из дежурств мне за несколько часов пришло больше десятка уведомлений. То температура в стойке подскочила на пару градусов. То CPU неожиданно преодолел порог. То один из дисков выдал предупреждение SMART. Конечно, я проверял каждый сигнал, смотрел графики, открывал логи и переключался между дашбордами. Но метрики и без этого возвращались к исходным значениям, и всё продолжало работать как обычно. К утру инфраструктура так и не полыхнула синим пламенем, зато система оповещений просто разрывалась. Так я впервые узнал об «усталости от алертов» и начал искать способ справиться с этой проблемой.

    habr.com/ru/companies/X5Tech/a

    #цод #мониторинг #алертинг #oncall #дежурства #инфраструктура #runbook #инциденты #резервирование #latency

  25. Не просто дашборд: как DORA-метрики помогли нам сократить инциденты на 80%

    DORA-метрики легко обсуждать как что-то довольно очевидное: выбрал четыре показателя, подключил данные, построил графики — готово. На практике все интересное начинается в тот момент, когда пытаешься сделать это не в презентации, а в живой компании с сотнями сервисов, разными сценариями деплоя и командами, у каждой из которых свой способ довозить код до прода. В Островке из этой задачи в итоге вырос отдельный сервис: он собирает события о релизах, связывает их с изменениями в GitLab, сопоставляет с инцидентами и отдаёт данные в Grafana. На MVP мы покрыли 90% проектов, а после регулярного разбора метрик и автоматизации узких мест количество критичных сбоев по последним данным снизилось на 80% . Под катом — история о том, как мы к этому пришли: откуда брали данные для DORA-метрик, как считали их в условиях очень разных релизных процессов и почему самой сложной частью оказалось не нарисовать графики, а вообще договориться с реальностью.

    habr.com/ru/companies/ostrovok

    #dora_metrics #django #backend #метрики #инциденты #стабильность #деплой #python #gitlab

  26. Хроники Облачного княжества: как я приручал монолит‑дракона: Орден SLO и игла Кощея

    Часть 3. Самая опасная магия в IT — это магия целей. Потому что цель легко обещает, а потом требует процентами отчёта. Есть особый вид страха, который появляется у инженера, когда два календаря совпадают.

    habr.com/ru/articles/1024126/

    #инциденты #продакшн #DevOps #SRE #мониторинг #микросервисы #база_данных #отказоустойчивость #постмортем

  27. Хроники Облачного княжества: как я приручал монолит‑дракона: Ночной алерт и инквизиция безопасности

    Часть 2. Если вам кажется, что инцидент — это про баги, вы просто ещё не видели, как баги превращаются в совещания. Первый ночной алерт приходит в момент, когда организм ещё верит, что сон — это базовая потребность, а не роскошь уровня «enterprise». Пейджер‑амулет (теперь уже и на моём поясе) запел так, будто ему лично не понравилось моё решение спать. Текст был коротким:

    habr.com/ru/articles/1022760/

    #инциденты #продакшн #DevOps #SRE #мониторинг #микросервисы #база_данных #отказоустойчивость #постмортем

  28. Инцидент с Unitree G1 — это не курьёз, а наглядная демонстрация системного риска киберфизических систем. Ошибка в софте, сенсорах или управлении в случае LLM остаётся на уровне текста; в случае роботизированной платформы она немедленно материализуется в силу, импульс и травму.

    По мере масштабирования внедрения человекоподобных машин плотность таких инцидентов будет расти — это статистика, а не предположение. Следовательно, ключевой вектор — не «запретить», а ужесточить инженерные практики: fail-safe архитектуры, ограничение усилий (force limiting), безопасные режимы по умолчанию, стандарты сертификации и протоколы взаимодействия с человеком.

    Иначе рынок получит не «умных помощников», а источник регулярных травм с предсказуемым репутационным и регуляторным откатом.

    #роботы #искусственныйинтеллект #технобезопасность #Unitree #робототехника #AIриски #человекомашинное_взаимодействие #киберфизические_системы #автоматизация #инциденты #безопасность #технологии #будущее #LLM #AI #роботика #рискиИИ #humanrobotinteraction #safetyengineering #failures

    bastyon.com/svalmon37?ref=PJ51

  29. [Перевод] LLM вместо «прочитаем потом»: анализ постмортемов и паттерны инцидентов

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

    habr.com/ru/companies/otus/art

    #sre #постмортемы #инциденты #управление_надёжностью #LLM #галлюцинации #humanintheloop

  30. Ночь с пятницы на понедельник: борьба за устойчивость, когда облако дало сбой

    …Был обычный ноябрьский вечер, 2024 год шёл к своему завершению: на носу была «чёрная пятница». Я вернулся домой в Новосибирск из почти двухнедельной командировки, пробыв в пути 12 часов и поспав часа четыре. В 19:07 алерт сообщил мне о падении одного из контроллеров. В целом, проблема не критичная, так как сервисы зарезервированы. Но всё же одним глазом я заглянул в чат с разбором. Через час ситуация стремительно ухудшилась: каскадом начали отказывать узлы, отвечающие за внешнюю связность. А затем развитие событий приняло фатальный оборот — в какой‑то момент одновременно отказали сервисы внешней связности сразу в двух зонах доступности… Это был один из самых крупных региональных инцидентов в облаке, после которого мы многое изменили в сети, чтобы сделать её устойчивее . С того момента прошло больше года, так что пришла пора рассказать эту историю от начала и до конца. В прошлой статье я уже показал наши основные подходы к повышению отказоустойчивости в этой ситуации. Однако за кадром остался сам процесс разработки новых решений и то, как мы мыслили, чтобы найти наилучший выход. Сегодня расскажу об этом подробнее. Статья основана на моём недавнем выступлении на Highload++ и дополнена по следам дальнейших расследований инцидентов.

    habr.com/ru/companies/yandex/a

    #надежность #sla #отказоустойчивость #инцидентменеджмент #инциденты #отказоустойчивые_системы #отказоустойчивость_сетей

Share on Mastodon

Enter the server where you have an account.