home.social

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

Live and recent posts from across the Fediverse tagged #надежность, aggregated by home.social.

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

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

    habr.com/ru/articles/1032714/

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

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

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

    habr.com/ru/articles/1032714/

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

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

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

    habr.com/ru/articles/1032714/

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

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

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

    habr.com/ru/articles/1032714/

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

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

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

    habr.com/ru/companies/yandex/a

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

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

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

    habr.com/ru/articles/987884/

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

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

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

    habr.com/ru/articles/982976/

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

  8. «Архитектура в Графе». Графическая визуализация формата 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) — «Сведения о показателях операционной надёжности кредитной организации и применяемых ею информационных технологиях при осуществлении банковской деятельности и деятельности в сфере финансовых рынков», точнее о ее части – шифре \ шифровке архитектуры предприятия. «Операционная надёжность» - это всего лишь контекст.

    habr.com/ru/articles/981610/

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

  9. «Архитектура в Графе». Графическая визуализация формата 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) — «Сведения о показателях операционной надёжности кредитной организации и применяемых ею информационных технологиях при осуществлении банковской деятельности и деятельности в сфере финансовых рынков», точнее о ее части – шифре \ шифровке архитектуры предприятия. «Операционная надёжность» - это всего лишь контекст.

    habr.com/ru/articles/981610/

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

  10. «Архитектура в Графе». Графическая визуализация формата 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) — «Сведения о показателях операционной надёжности кредитной организации и применяемых ею информационных технологиях при осуществлении банковской деятельности и деятельности в сфере финансовых рынков», точнее о ее части – шифре \ шифровке архитектуры предприятия. «Операционная надёжность» - это всего лишь контекст.

    habr.com/ru/articles/981610/

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

  11. «Архитектура в Графе». Графическая визуализация формата 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) — «Сведения о показателях операционной надёжности кредитной организации и применяемых ею информационных технологиях при осуществлении банковской деятельности и деятельности в сфере финансовых рынков», точнее о ее части – шифре \ шифровке архитектуры предприятия. «Операционная надёжность» - это всего лишь контекст.

    habr.com/ru/articles/981610/

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

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

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

    habr.com/ru/companies/otus/art

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

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

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

    habr.com/ru/articles/980288/

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

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

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

    habr.com/ru/articles/979686/

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

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

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

    habr.com/ru/articles/979686/

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

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

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

    habr.com/ru/articles/979686/

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

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

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

    habr.com/ru/articles/979686/

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

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

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

    habr.com/ru/companies/finops_r

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

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

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

    habr.com/ru/companies/finops_r

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

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

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

    habr.com/ru/companies/finops_r

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

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

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

    habr.com/ru/companies/finops_r

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

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

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

    habr.com/ru/articles/973638/

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

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

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

    habr.com/ru/companies/t2/artic

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

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

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

    habr.com/ru/articles/972980/

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

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

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

    habr.com/ru/articles/972944/

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

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

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

    habr.com/ru/articles/972944/

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

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

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

    habr.com/ru/articles/972944/

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

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

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

    habr.com/ru/articles/972944/

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

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

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

    habr.com/ru/companies/otus/art

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

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

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

    habr.com/ru/articles/960968/

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

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

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

    habr.com/ru/articles/950072/

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

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

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

    habr.com/ru/articles/948506/

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

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

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

    habr.com/ru/companies/vk/artic

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

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

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

    habr.com/ru/articles/927722/

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

  35. Доступность IT-систем: поругаться или договориться?

    Всем привет, меня зовут Александр Москвин, я начальник управления эксплуатации X5 Облака в X5 Tech. У меня несколько зон ответственности, но важнейшая из них – это обеспечение доступности облачной инфраструктуры Х5. Конечно, для того, чтобы управлять доступностью, необходимо оцифровать этот показатель. Статья родилась из жарких дебатов по целевым показателям доступности частного облака X5 и серии больших внутренних митапов, посвящённых этой теме. Кажется, что результатами стоит поделиться с сообществом, т. к. накопилась критическая масса материалов и выводов. Мысли будут полезны менеджерам, принимающим решения, и solution-архитекторам для переговоров с заказчиками, лидам команд инфраструктуры и разработки. К сожалению, получился лонгрид, так как охватить все аспекты данной темы короткой статьёй не выйдет.

    habr.com/ru/companies/X5Tech/a

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

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

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

    habr.com/ru/articles/918574/

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

  37. Запросы двойной надежности

    Отправляем запрос на 20 000 000 евро, на перестановку 900 ордеров на бирже. Что может пойти не так? Сегодня я расскажу, как не терять пару миллиардов клиентских денег, когда уж очень нужно что-то массово сделать на бирже. Этот текст про неявную и, казалось бы, незаметную проблему, которая ждет нас в недрах работы с любыми запросами, которые могут исполниться не до конца – в частности, с HTTP-запросами. Удивительно, как мало об этой проблеме думают и насколько мало инструментов для её решения. Задача была такова – реализовать массовое управления биржевыми ордерами, причём не только в рамках одной биржи, а в целом по всей планете. И чтобы оно точно отработало. В повествовании будут клиенты, серверы и котики. С котиками всегда интереснее.

    habr.com/ru/companies/exante/a

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

  38. Надежность в процессах. Часть 1

    Прежде, чем объединяться, нам надо решительно размежеваться (Business continuity management vs Business Process Continuity vs Dependability in technics) Синонимы: Надежность в процессах = надежность процессов = надежность операций = операционная надежность (с учетом синонимии словосочетаниями «сущ. + сущ.» [Морф23]). En: dependability, reliability, resilience (availability, stability) Business Process. Непрерывность процессов – в контексте «business continuity» (Business Process Continuity, BPC) и т.п. Методологические вводные: текст будет обнадежен от типовых угроз (распространенных рисков): а) простые вещи делаем сложными, т.е. простое формализуем через сложные конструкции (излишнее нагромождение), что часто или необоснованно («овчинка выделки не стоит») или является диверсией, как видимо, определение операционной надежности (operational resilience») в п. 1.4 716П . б) сложные вещи плохо декомпозируем: не верно разбиваем на простые составляющие; в) одно и тоже называем разными словами, а разные вещи – одним термином. 1 Процесс и надёжность Процесс и надёжность – два очень простых термина. Далее под процессом будем понимать «бизнес-процесс», который в отличие от природного процесса (химические, физические процессы) реализуется не природой, а «человеко-машиной», т.е. в общем случае – «рукотворные» (искусственный, артефакт). Процесс В общем случае, синонимы: делание, процесс, операция, функция, действие, активность (activity), см. правильный «Business Process Management», например, книжки ARIS или [BPM23] – там все подробно показано.

    habr.com/ru/articles/844992/

    #надежность #бизнеспроцессы #центральный_банк #bcm #bpm #six_sigma #гост

  39. Пайплайны записи своими руками: думали — велосипед, оказалось — паттерны

    Привет, Хабр! Я Роман Щербаков, ведущий инженер в Sage — это платформа мониторинга в Т-Банке, которую мы разрабатываем с 2019 года. За пять лет нагрузка на платформу возросла многократно, и, чтобы ее выдерживать, мы постоянно докручиваем наше решение. В этой статье расшифровка моего доклада с Saint HighLoad++ 2024 о том, как мы строим нагруженные пайплайны записи. И о том, как было бы здорово заранее знать, что нам потребуется. Мы придумали много всего для надежной работы пайплайнов, а посмотрели ретроспективно, и оказалось, что это просто одни сплошные стандартные паттерны.

    habr.com/ru/companies/oleg-bun

    #паттерны #пайплайны #надежность

  40. Автоматизация ТОиР инженерных систем в ВТБ: кейс внедрения SAP PM для 100 000 единиц оборудования

    В новостных сводках, каналах, изданиях мы все чаще наблюдаем за успехами оптимизации, автоматизации и внедрения новых систем ТОиР промышленного оборудования. На больших предприятиях оборудование принято называть активами, подчеркивая их важность для достижения целей компании. Да, промышленное оборудование - безусловно критически важное оборудование инфраструктуры предприятия и от надежности такого оборудования во многом зависит доход компании. А что же с активами банков? Нет, не теми финансовыми инструментами, которыми они пользуются, а «железными» активами, которые также помогают банкам работать. Как же быть с обслуживанием инженерного оборудования или оборудования противопожарных систем, а еще и кассовой техники? - зададимся мы вопросом. Почему про процессы обслуживания этого оборудования мы мало где можем найти информацию? Ведь оно также является немаловажным звеном основной цепочки бизнес-процесса предприятия, и от его бесперебойной работоспособности зависит многое. Возьмем например банк. Инженерные системы и системы противопожарной безопасности банка – это «сердце», жизненно важный элемент объекта. Кассовая техника – это «стержень» кассового узла, центра пересчета. Исправное и безотказное состояние элементов инженерных систем обеспечивает удобство, уют и комфорт сотрудникам и клиентам банка, а кассовой техники – непрерывность процесса пересчета и, как следствие, напрямую влияет на прибыль. Наша команда Банка ВТБ давно занимается этими вопросами и мы хотим рассказать об одной такой истории автоматизации процессов ТОиР в банковской сфере. В 2020 году Банк ВТБ, как и положено крупным компаниям, обновлял программное обеспечение и переходил на обновленную версию SAP S4. Управление эксплуатации Административного департамента банка, проанализировав текущие процессы ТОиР, вынесла предложение включить в новую сборку программы SAP дополнительный модуль PM (ТОРО). Руководство компании поддержало идею цифровизации технического обслуживания и ремонта. Так началась история автоматизации ТОиР в Банке ВТБ.

    habr.com/ru/articles/864568/

    #ТОиР #ТОРО #Учет_оборудования #Мобильное_ТОРО #SAP_PM #Планирование #надежность #инженерные_системы #здания_и_сооружения

  41. Backblaze: надёжность жёстких дисков падает год от года. Это актуально для HDD большинства производителей

    Компания Backblaze, провайдер облачных сервисов, регулярно публикует отчёты о выходе из строя жёстких дисков, находящихся у неё в эксплуатации. HDD — сотни тысяч, поэтому статистика получается интересной. Правда, обычно такие отчёты выглядят более-менее одинаково: какие-то модели дисков выходят из строя чаще, какие-то реже. А вот сейчас ситуация иная: согласно данным провайдера за 2023 г. , надёжность жёстких дисков разных моделей от любых производителей снизилась. Есть и исключения, но в целом это так. Подробности — под катом.

    habr.com/ru/companies/ru_mts/a

    #диски #hdd #надежность

  42. Streamcast про Надежность(SRE)

    Всем привет! Мы (Дмитрий Масленников(ТБанк), Максим Иванов(ТБанк) и Марина Калетурина(Яндекс)) решили попробовать новый формат — стриминг. Не откладывая надолго, анонсируем первый первый стрим в следующее воскресенье 29 декабря в 19:00! — сохраняйте даты. Посмотреть стрим можно будет на Twitch и YouTube: youtube.com/@srepubstreamcast twitch.tv/srepubstreamcast Темой первого стрима будут этические вопросы в SRE: 1) Необвинительная(Blameless) культура, как ее понимать, 2) Допустимо ли врать в резюме, к чему все это может привести и подобное. Вы сможете задавать нам вопросы в чате, а мы постараемся ответить на них в прямом эфире.

    habr.com/ru/articles/869444/

    #sre #стрим #надежность #найм #сбой #отношения

  43. Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL. Часть. 3

    Привет, Хабр! Это снова мы — Павел Конотопов и Михаил Жилин, сотрудники компании Postgres Professional. Напомню, что Павел занимается архитектурой построения отказоустойчивых кластеров, а я анализом производительности СУБД. У каждого из нас за плечами более десяти лет опыта в своей области. Во второй части статьи «Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL» мы говорили о гарантии согласованности данных и разрешение конфликтов. Разобрали как выявлять и разрешать конфликты, используя разные способы. Теперь пришла пора одной из самых важных характеристик хранения данных — надёжности.

    habr.com/ru/companies/postgres

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

  44. Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL. Часть. 2

    Привет, Хабр! Это снова мы — Павел Конотопов и Михаил Жилин, сотрудники компании Postgres Professional. Напомню, что Павел занимается архитектурой построения отказоустойчивых кластеров, а я анализом производительности СУБД. У каждого из нас за плечами более десяти лет опыта в своей области. В первой части статьи «Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL» мы посмотрели как развивалась технология «Мультимастер» в экосистеме PostgreSQL. Обсудили существует ли «Честный Мультимастер», какие у него реализации и как его следует применять. Теперь поговорим о надёжности хранения данных.

    habr.com/ru/companies/postgres

    #postgresql #postgres_pro #база_дынных #мультимастер #надежность #crdt #репликация #разрешение_конфликтов #silent_data_corruption #устойчивость_к_сбоям

  45. За кулисами разработки: кто такой IT Area Lead в Домклик?

    В эпоху стремительной цифровизации, когда виртуальный мир становится неотъемлемой частью нашей жизни, роль IT-специалистов возрастает многократно. Особенно это касается компаний, которые активно внедряют цифровые решения, делая жизнь своих клиентов комфортнее и доступнее. Но кто же стоит во главе этого процесса? Кто отвечает за бесперебойную работу платформы, внедрение новых технологий и развитие цифрового сервиса? В этой статье я расскажу о роли IT Area Lead в Домклик, о том, какими навыками должен обладать этот человек и с какими вызовами он сталкивается каждый день.

    habr.com/ru/companies/domclick

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

  46. Часть 3. Представление вероятности безотказной работы системы в виде ряда Тейлора

    В технологии логико‑вероятностного моделирования для оценки важности отказов элементов сложных технических систем (СТС) применяются показатели одно, двукратной и к‑кратной значимости. В данной статье представлена вероятность безотказной работы системы в виде ряда Тейлора на основе к‑кратных совместных значимостей. Представление функции вероятности безотказной работы системы в виде ряда Тейлора является эффективным средством для проведения углубленных исследований надежности, безопасности и живучести сложных технических систем. Функция ВБРС представлена на основе к‑кратных совместных значи‑ мостей, учитывающих влияние ряда отказов элементов на систему в целом. На основе представления ВБРС в виде ряда Тейлора выведен ряд показателей важности («весовых коэффициентов»). Кроме этого, еще в 1981 году И.А. Рябинин обозначил широкий класс объектов моделирования под названием структурно‑сложных систем, не ограничиваясь сложными техническими системами. Технология логико‑вероятностного моделирования применима для исследования разнообразных объектов, имеющих сложную структуру и организацию. При этом вероятность может быть не только безотказной работы, но и риска возникновения опасного состояния, а также иных показателей: степени принадлежности или предпочтений, например при оценки рисков реализации проектов, кредитования и тому подобное. In the technology of logic‑probabilistic modeling, to assess the importance of element failures of complex technical systems (CTS), indicators of one, two‑fold and k‑fold significance are used. This article presents the probability of the system's failure‑free operation in the form of a Taylor series based on k‑fold joint significances.

    habr.com/ru/articles/789224/

    #надежность #логиковероятностное_моделирование #сложная_техническая_система #ккратная__совместная_значимость #reliability_engineering #complex_technical_system #kfold_joint_significance #birnbaum_importance_index

  47. Часть 2. Алгоритм расчета к-кратной совместной значимости в технологии логико-вероятностного моделирования

    Algorithm for calculating k-fold joint significance in the logical-probabilistic modeling technology Морозов В.И. , Morozov V.I. В части 1 приведен вывод выражения к-кратной совместной значимости в технологии логико-вероятностного моделирования, которая находится по ссылке . В технологии логико вероятностного моделирования для оценки важности отказов элементов сложных технических систем (СТС) применяются показатели одно, двукратной и к-кратной значимости. В данной статье приведен алгоритм расчета к-кратной совместной значимости в общем виде, который позволяет существенно сокращать объемы расчета при проведении исследований влияния некой совокупности отказов элементов на СТС. In the technology of logic-probabilistic modeling, to assess the importance of element failures of complex technical systems, indicators of one, two-fold and k-fold significance are used. This article provides algorithm for calculating the k-fold joint significance, which allow you to significantly reduce the amount of calculation when conducting research of the influence of a certain set of element failures on the complex technical systems.

    habr.com/ru/articles/788968/

    #надежность #логиковероятностный_метод #ккратная_совместная__значимость #сложная_техническая_система #reliability_engineering #logicalprobabilistic_method #complex_technical_system #kfold_joint_significance #birnbaum_importance_index #показатель_важности_по_бирнбауму

  48. Часть 2. Алгоритм расчета к-кратной совместной значимости в технологии логико-вероятностного моделирования

    Часть 2. Алгоритм расчета к-кратной совместной значимости в технологии логико-вероятностного моделирования Algorithm for calculating k-fold joint significance in the logical-probabilistic modeling technology Морозов В.И. , Morozov V.I. В части 1 приведен вывод выражения к-кратной совместной значимости в технологии логико-вероятностного моделирования, находится по cсылке: habr.com/ru/articles/787902/ В технологии логико вероятностного моделирования для оценки важности отказов элементов сложных технических систем (СТС) применяются показатели одно, двукратной и к-кратной значимости. В данной статье приведен алгоритм расчета к-кратной совместной значимости в общем виде, который позволяет существенно сокращать объемы расчета при проведении исследований влияния некой совокупности отказов элементов на СТС. In the technology of logic-probabilistic modeling, to assess the importance of element failures of complex technical systems, indicators of one, two-fold and k-fold significance are used. This article provides algorithm for calculating the k-fold joint significance, which allow you to significantly reduce the amount of calculation when conducting research of the influence of a certain set of element failures on the complex technical systems.

    habr.com/ru/articles/788968/

    #надежность #логиковероятностный_метод #ккратная_совместная__значимость #сложная_техническая_система #reliability_engineering #logicalprobabilistic_method #complex_technical_system #kfold_joint_significance #birnbaum_importance_index #показатель_важности_по_бирнбауму

  49. Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL. Часть. 3

    Привет, Хабр! Это снова мы — Павел Конотопов и Михаил Жилин, сотрудники компании Postgres Professional. Напомню, что Павел занимается архитектурой построения отказоустойчивых кластеров, а я анализом производительности СУБД. У каждого из нас за плечами более десяти лет опыта в своей области. Во второй части статьи «Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL» мы говорили о гарантии согласованности данных и разрешение конфликтов. Разобрали как выявлять и разрешать конфликты, используя разные способы. Теперь пришла пора одной из самых важных характеристик хранения данных — надёжности.

    habr.com/ru/companies/postgres

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

  50. Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL. Часть. 2

    Привет, Хабр! Это снова мы — Павел Конотопов и Михаил Жилин, сотрудники компании Postgres Professional. Напомню, что Павел занимается архитектурой построения отказоустойчивых кластеров, а я анализом производительности СУБД. У каждого из нас за плечами более десяти лет опыта в своей области. В первой части статьи «Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL» мы посмотрели как развивалась технология «Мультимастер» в экосистеме PostgreSQL. Обсудили существует ли «Честный Мультимастер», какие у него реализации и как его следует применять. Теперь поговорим о надёжности хранения данных.

    habr.com/ru/companies/postgres

    #postgresql #postgres_pro #база_дынных #мультимастер #надежность #crdt #репликация #разрешение_конфликтов #silent_data_corruption #устойчивость_к_сбоям