#надежность — Public Fediverse posts

Кэш не работал восемь недель. Всё это время он честно писал об этом в лог

Redis у сервиса прогнозов не было восемь недель: контейнер упал с кодом 255 и больше не поднялся. Всё это время каждый запрос считался заново, 1,9 секунды вместо 11 миллисекунд. При этом авария не была тихой. В обработчике ошибки стоит self.redis_client = None с комментарием про заглушку, но заглушки там нет, поэтому каждый вызов get и set падал с AttributeError, ловился своим же except и писал ERROR в лог. Две строки на каждый запрос, восемь недель подряд. Разбираю, почему я этого не видел, почему health сервиса всё это время отдавал вписанное в код «ok» с таймстампом из мая 2025 года, и чем аккуратно обработанный отказ отличается от обычной поломки.

https://habr.com/ru/articles/1092724/

#кэширование #мониторинг #надежность #логирование #redis #docker #fastapi

Как мониторить Java-приложения: метрики, алерты и правило 80/20

Хороший мониторинг помогает быстро понять, что происходит с приложением и куда смотреть в первую очередь. Для этого не нужно пытаться измерить всё: базовый набор технических метрик покрывает большинство типовых проблем, а бизнес-метрики, SLO и анализ аномалий помогают заранее замечать нетипичные отклонения. В Календаре мы называем этот подход правилом 80/20 . Всем привет! Меня зовут Настя, я бэкенд-разработчик в Яндекс 360 и отвечаю за надёжность Календаря. В этой статье я покажу, какие метрики стоит взять за основу, как выбирать полезные алерты и чем дополнять базовый набор для оставшихся 20%.

https://habr.com/ru/companies/yandex/articles/1068874/

#мониторинг #метрики #алертинг #java #devops #sre #site_reliability_engineering #надежность #инцидентменеджмент

Механику на насос деньги дали, а вам на серверную — нет. Дело не в железе, а в языке

Как обосновать ИТ-бюджет через FMEA и RCM — методологию надёжности, которой на предприятии уже доверяют

https://habr.com/ru/articles/1068284/

#fmea #rcm #надежность #итбюджет #управление_активами #iso_55001 #тоир #скрытые_отказы #итдиректор #промышленный_ит

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

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

https://habr.com/ru/articles/1064948/

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

Носители данных — «игра на выбывание» (2026.07)

Статья "LLM free" - все изображения и текст органического происхождения. :) В январе выкладывал пост, в котором рассказывал о ходе эксперимента с 2 флешками - насколько долго они могут сохранить данные в обычных домашних условиях. На сегодня прошло уже 2 года с момента, когда флешки были заполнены данными и отложены в темное сухое место. Этот эксперимент не претендует на какую-либо научность и практическую значимость. Всё делается просто ради прикола. Just for fun.

https://habr.com/ru/articles/1055550/

#microSD #флешпамять #надежность #хранение #эксперимент #тестирование

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

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

https://habr.com/ru/articles/1051542/

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

Сервер работает. Продукт — уже нет

Большинство команд следят за серверами, базами данных и доступностью приложений. Но самые дорогие инциденты часто происходят совсем в другом месте. Истёкший API-ключ, сломанный webhook или отказ внешнего сервиса могут неделями оставаться незамеченными, пока пользователи не начнут жаловаться. Разберём, почему так происходит и почему классический мониторинг часто не видит реальные проблемы SaaS-продуктов

https://habr.com/ru/articles/1046694/

#мониторинг #saas #devops #observability #stripe #openai #webhook #api #интеграции #надежность

Rust: зачем он появился, что умеет и почему компании переписывают на него части своих систем

Эта статья — для тех, кто только присматривается к Rust или слышал о нем лишь обрывки восторженных или невосторженных отзывов. Если вы не до конца понимаете, зачем миру понадобился еще один системный язык, какие «боли» C++ он лечит и где реально используется сегодня, — здесь вы найдете ответы на эти вопросы. Мы постарались структурированно представить информацию, чтобы у вас сложилась полная картина: что это за язык, зачем его учить и с чего начать освоение. Сразу оговоримся: если «The Book» давно стала вашей настольной книгой, вы уже собаку съели на управлении памятью и знаете все о владении и заимствовании, эта статья вряд ли вас удивит. Остальным же — добро пожаловать. В апреле 2026 года произошло сразу два события, заставивших вновь говорить о Rust. 16 апреля вышел очередной стабильный релиз — Rust 1.95.0. А вскоре после этого Илон Маск заявил, что новый мессенджер XChat построен на Rust и «whole new architecture». В этой статье мы попробуем понять, почему для новых систем, где важны скорость, безопасность и надежность, все чаще выбирают Rust?

https://habr.com/ru/articles/1032714/

#rust #java #go #c++ #webassembly #высоконагруженные_системы #надежность #безопасность

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

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

https://habr.com/ru/companies/yandex/articles/992520/

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

Продляем срок службы светодиодных ламп. Теория

Добрый день, уважаемые коллеги! Некоторое время назад, обнаружил что затраты на покупку светодиодных ламп стали превышать таковые в прошлом на обычные лампочки. Изначально, игнорировал данный момент. Когда денег стало меньше, а работы не прибавлялось, пришлось озадачится вопросом и попытаться понять почему это происходит и как это исправить. Конечно, можно попытаться списать подобные вещи на барабашку, или незваных гостей, которые очень любят общество потребления. Но, мы подойдем к данному вопросу исключительно с точки зрения техники и технологий. Итак. Имеем пару лампочек, которые перегорели. Посмотрим на них изнутри, и попробуем установить причину подобного эффекта. Для начала вскроем лампочку.

https://habr.com/ru/articles/987884/

#светодиодные_лампы #экономия #надежность

pg-status — легковесный микросервис для определения статуса PostgreSQL хостов

Привет! Хочу рассказать о своем новом небольшом проекте - pg-status . Это очень легкий и производительный микросервис, который помогает определять статус хостов postgresql. В первую очередь его задача - помочь вашему backend найти живого мастера и достаточно синхронную реплику.

https://habr.com/ru/articles/982976/

#sql #postgresql #open_source #сезон_open_source #микросервисы #надежность #доступность

«Архитектура в Графе». Графическая визуализация формата CSV/| формы «Операционной надежности и ИТ» (№ 0409072)

1 Операционная надежность (надежность операций, процессов, функций) Регулятор (ЦентоБанк) уже несколько лет ведет «крестовый поход» под знаменем «Операционная надёжность»: выпускает «одноименные» Положения (850-П / 787-П, 779-П), Стандарты Банка России ( СТО БР БФБО-1.5-2023 ), ГОСТы ( ГОСТ 57580.3 / 57580.4 , с его участием), а также методические рекомендации ( 18-МР ) и формы обязательной отчетности по «Операционной надёжности» (operational resilience). Под знаменем «Операционная надёжность» - делается попытка «скрестить» (где-то «ежа с ужом», но сама идея достойная) бизнес-архитектуру (архитектуру процессов, как технологических, так и бизнес – хотя разделение их не понятное), EA (enterprise architecture) / ИТ-архитектуру, ITSM (CMDB, управление инцидентами, в том числе, инцидентами операционной надежности), информационную безопасность (вкл. ГОСТ 57580.1 / 57580.2), надежность / отказоустойчивость / ОНиВД, риск-менеджмент (опер-риски, 716-П), импортозамещение (ФТК). Подобный «единый узел» - это проекции «одного и того же» на разные плоскости (EA, BPM, GRC, ИБ, ITIL и др.) с разными словарями / концепциями, поэтому формализовать его видимо равносильно притчи / сценарию «Вавилонская башня». Однако «язык графа» сближает такое восприятие и снижает барьер сложности. Далее будем говорить только о Форме 0409072 (далее ф072) — «Сведения о показателях операционной надёжности кредитной организации и применяемых ею информационных технологиях при осуществлении банковской деятельности и деятельности в сфере финансовых рынков», точнее о ее части – шифре \ шифровке архитектуры предприятия. «Операционная надёжность» - это всего лишь контекст.

https://habr.com/ru/articles/981610/

#mermaid #cmdb #risk_management #надежность #операционная_устойчивость #enterprise_architecture #bpm

[Перевод] Как проводить архитектурные ревью за 30 минут вместо 3 часов

Архитектурное ревью в разработке ПО часто выглядит как ритуал: собираемся, смотрим диаграммы, соглашаемся с идеей «надо бы подумать про масштабирование», расходимся — и через пару месяцев ловим те же грабли, только дороже. В этой статье разбираем, как превратить ревью из формальности в инструмент, который реально снижает риски: что именно проверять (и в каком порядке), как задавать вопросы так, чтобы вскрывались допущения и скрытые зависимости, как фиксировать решения, и где проходит граница между «всё переписать» и «достаточно подкрутить одну гайку». Разобрать подход

https://habr.com/ru/companies/otus/articles/980762/

#архитектурное_ревью #software_architecture #архитектурные_решения #технический_долг #ADR #нефункциональные_требования #масштабируемость #надежность #ревью

Надежное программирование — часть 6. Неудачники, эволюционировавшие и перспективные языки

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

https://habr.com/ru/articles/980288/

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

Вы уже занимаетесь SRE. Просто не знаете об этом

"У нас нет SRE" – не значит "у нас нет надёжности". Даже без SRE-инженера ваша команда уже что-то делает для надёжности. Покажу, как увидеть уже существующие у вас практики и понять, куда двигаться дальше. Идем смотреть и понимать...

https://habr.com/ru/articles/979686/

#sre #практики #надежность #reliability_engineering #техлиды

Что сломается в вашем дне, если отключат интернет: реальная зависимость от сети и облаков

Мы давно перестали воспринимать интернет как что-то необычное. Для абсолютного большинства из нас это нечто настолько же рядовое, как электричество или водоснабжение. Но это, пока пока интернет вдруг не отключат. Совсем как горячую воду. Вот тогда-то и начинается интересное. Именно в этот момент выясняется, что вся ваша работа была возможной только потому, что возможен ОН, и, если ОН пропадет, встанет буквально весь конвейер.

https://habr.com/ru/companies/finops_ru/articles/979340/

#инфраструктура #финопс #finops #itинфраструктура #облака #серверы #отказоустойчивость #надежность #безопасность #эксплуатация

Предвидеть, чтобы предотвратить: как анализ трендов помогает избегать аварий

Как с помощью математической статистики мы ищем тренды в промышленных данных, предотвращая инциденты и аварии.

https://habr.com/ru/articles/973638/

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

Индекс здоровья: даже моя бабушка поймет, что болит у системы

Привет, Хабр! Меня зовут Николай, я – старший инженер по внедрению в Т2. На определенном этапе эксплуатации системы, когда настроены все мониторинги, и подключены все алерты, появляется необходимость оформить работоспособность всего, что есть, в одной метрике. Такую метрику, знаете, и отделу бизнес-мониторинга можно продемонстрировать, и коллегам из смежных команд – и при этом сделать все максимально прозрачным и понятным. Чтобы, как я иногда говорю, моя бабушка посмотрела и все поняла. В этой статье я расскажу, что у меня получилось из идеи создать доходчивую и простую для восприятия метрику индекса здоровья системы! Интересно? Переходите под кат.

https://habr.com/ru/companies/t2/articles/973578/

#мониторинг #индекс_здоровья #sre #надежность #визуализация #инженерные_практики #grafana #prometheus #allerting #health_monitoring_system

От спонтанных ремонтов к проактивному управлению:

Как повысить доступность оборудования для работы по предназначению и сократить издержки Внезапный выход оборудования из строя это не просто техническая неисправность. Для любого производственного предприятия это прямые финансовые потери, срыв сроков и удар по репутации. Многие руководители ищут спасение в сложных предиктивных технологиях, надеясь, что «умные» датчики предупредят о каждой возможной поломке. Однако, как показывает практика, универсального решения, способного предсказать износ каждого подшипника, провода или шестерни, не существует. Проблема гораздо глубже и требует не столько технологического, сколько системного подхода в работе предприятия. Границы предиктивной аналитики: почему датчики не видят всей картины Современный станок, да и в целом любой оборудование, является сложным комплексом механических, электрических и электронных компонентов. На одном агрегате могут быть десятки подшипников, множество направляющих, зубчатых реек, датчиков, энкодеров и контакторов. А какое электронное устройство способно оценить степень износа зубчатой рейки в зоне активной работы? Как измерить усталость металла в скрытой части станины или определить, что контакт в клеммной коробке стал ненадежным? Никакое. Никак. Практический опыт нашего коллектива показывает, что большинство отказов не сопровождается очевидными предвестниками, такими как вибрация, которую можно было бы легко зафиксировать. Поломка часто происходит внезапно, превращая работу производственного цеха в хаос. Полагаться исключительно на внешние датчики, значит игнорировать первопричину проблемы, которая кроется не в технологии, а в процессах.

https://habr.com/ru/articles/972980/

#контроль #мониторинг #планирование #надежность #производство

Когда ошибка становится наставником: почему баги прошлого нередко полезнее любого чек-листа

Каждый разработчик хотя бы раз в жизни сталкивался с ситуацией, когда баг, который вроде бы уже исправлен, неожиданно возвращался в продакшен. В этой статье я расскажу о тех случаях, когда ошибки служили для меня не провалом, а очень настойчивым, но полезным учителем. Да, иногда именно они объясняют архитектуру, принцип работы систем или забытый corner case лучше самых толстых документаций. Эта статья не учит идеализму — наоборот, она про то, как ценить несовершенство.

https://habr.com/ru/articles/972944/

#ошибка #баг #отладка #архитектура #опыт_разработчика #race_condition #обработка_данных #очереди #продакшен #надежность

[Перевод] Всё, что я знаю о хорошем системном дизайне

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

https://habr.com/ru/companies/otus/articles/960948/

#system_design #system_architecture #системный_дизайн #архитектура_приложений #распределённые_системы #масштабируемость #надежность #базы_данных #проектирование_сервисов

On-call ротация без выгорания

Я уволился из своей первой работы SRE-инженером после особенно тяжелой недели дежурства. Семь ночей подряд я просыпался от PagerDuty. Семь ночей подряд я чинил одну и ту же проблему с памятью, которую никто не хотел исправлять "по-настоящему", потому что "горячий фикс же работает". На восьмое утро я пришел в офис и положил заявление на стол. Это было пять лет назад. С тех пор я прошел через четыре компании, построил on-call процессы с нуля в двух из них, и научился главному: дежурства не должны убивать людей. Физически и морально. Давайте поговорим о том, как построить on-call ротацию, которая не приведет к массовым увольнениям.

https://habr.com/ru/articles/960968/

#oncall #дежурства_в_разработке #дежурство #sre #sreпроцессы #devops #devops_трансформация #надежность

[Перевод] Почему я не верю в ИИ-агентов в 2025 году, несмотря на то, что сам их разрабатываю

Команда AI for Devs перевела статью, в которой автор делится прогнозами о будущем ИИ-агентов в 2025 году. Его выводы: несмотря на шумиху, «автономные агенты» столкнутся с экономическими и техническими барьерами. Почему текущий подход к архитектуре агентов не сработает и какие методы действительно приносят результат — читайте в статье.

https://habr.com/ru/articles/950072/

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

Как правильно формулировать нефункциональные требования

Привет, Хабр! Я старший системный аналитик, эксперт онлайн-школы по системному анализу Ольги Пономарёвой. Материал основан на реальных кейсах из практики: мы в школе System Analyst не просто рассказываем теорию, а делимся тем, что действительно работает на проектах. За свою карьеру я написала не одну сотню требований и поняла такую вещь – самые важные и самые незаметные, это блок нефункциональных требований. В этой статье я расскажу, как правильно выявлять и формулировать НФТ.

https://habr.com/ru/articles/948506/

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

Подстилая соломку, или Как выжить в ситуационном центре

Привет, Хабр. Меня зовут Кирилл Борисов, я SRE в Ситуационном центре. Я часто видел, как неправильное использование паттернов отказоустойчивости архитектуры или их игнорирование приводит к серьёзным последствиям. Поэтому хочу рассказать, как обеспечить надёжность в условиях, когда может упасть любой микросервис.

https://habr.com/ru/companies/vk/articles/945292/

#sre #надежность #devops #бэкенд

Надежное программирование — часть 3. Финал (2019)

Немного рассуждений о языках программирования (ЯП) с уклоном на надежное и безопасное программирование. Статья не публиковалась ранее, хотя была написана в 2019г, теперь можно смотреть как некую ретроспективу. Чем и воспользуюсь, вставляя замечания о былом по тексту (тег Upd). Но тормозит развитие серии, ибо вышли уже 3 части и несколько переводов в тему:

https://habr.com/ru/articles/927722/

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

10 Принципов отказоустойчивости (с примерами на Javascript)

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

https://habr.com/ru/articles/918574/

#отказоустойчивость #UX #архитектура #ошибки #стабильность #fallback #устойчивость #frontend #error_handling #надежность

Надежность на масштабе в 45 млн клиентов — инструменты и практики

Всем привет! Меня зовут Алексей Мерсон, я несколько лет работал Developer Advocate в Sage, платформе наблюдаемости Т-Банка. Эта платформа сама по себе очень немаленькая, со сложной архитектурой. Но если посмотреть на ландшафт экосистемы в целом, то Sage — всего лишь одна из платформ в Т-Банке, необходимых, чтобы наши услуги были надежными. А платформы, в свою очередь, — это тоже только часть более общей картины. В этой статье хочу поговорить о том, какие инструменты и практики мы используем для надежности в Т-Банке. Уделим внимание работе с инцидентами. И отдельно сфокусируемся на клиентском опыте: мне кажется, мы, инженеры, часто забываем, что технологии делаются не ради технологий, а ради решения задач бизнеса и его клиентов. Если они будут довольны, то и у нас будет больше возможностей заниматься интересными нам вещами.

https://habr.com/ru/companies/tbank/articles/916238/

#Надежность #sre

[Перевод] Claude лучшая модель?

Данные OpenRouter показывают тенденцию: разработчики охотно платят за Claude, несмотря на наличие бесплатных альтернатив от Google. При создании продакшн-приложений для них важнее стабильность и предсказуемость ответов ИИ, чем цена - даже если токены бесплатны.

https://habr.com/ru/articles/905672/

#искусственный_интеллект #claude #llm #anthropic #openrouter #надежность #gemini #разработка #google

Стильный дизайн и большой запас хода: назван отличный недорогой электрокар с пробегом
https://www.unian.net/economics/auto/kakoy-elektromobil-vybrat-nazvan-nedorogoy-avtomobil-s-bolshim-zapasom-hoda-12958527.html
#unian #авто #автомобили #электрокар #электрокары #электромобиль #электромобили #лучшиеавто #лучшиеавтомобили #надежность #лучшиеэлектромобили #лучшиеэлектрокары

Миф о доказательном программировании без ошибок

Много копий сломано в обсуждениях, какой язык программирования самый лучший с точки зрения корректности и безопасности (под термином "корректность и безопасность" имеется ввиду отсутствие различных ошибок в программе, которые проявляют себя на стадии её выполнения и приводят к выдачей некорректного результата или неожиданному поведения). А некоторые языки программирования, такие как SPARK или OCaml, даже специально разрабатывались для облегчения доказательства корректности программы. А возможно ли вообще писать программы без ошибок?

https://habr.com/ru/articles/886774/

#программирование #ошибки #надежность