Рубрика «reliability»

в 13:00, , рубрики: reliability, resilience, sre, доклад яндекса, надежность

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

Что такое надёжность

Давайте синхронизируемся, что же мы будем понимать под надёжностью в этой статье.

Читать полностью »

в 7:12, , рубрики: low level, ops, reliability, servers, strace, tools, Блог компании Southbridge, Серверное администрирование, Софт

Отлаживаем развертывание ПО со strace - 1

Моя основная работа — это, по большей части, развертывание систем ПО, то есть уйму времени я трачу, пытаясь ответить на такие вот вопросы:

  • У разработчика это ПО работает, а у меня нет. Почему?
  • Вчера это ПО у меня работало, а сегодня нет. Почему?

Это — своего рода отладка, которая немного отличается от обычной отладки ПО. Обычная отладка — это про логику кода, а вот отладка развертывания — это про взаимодействие кода и среды. Даже если корень проблемы — логическая ошибка, тот факт, что на одной машине все работает, а на другой — нет, означает, что дело неким образом в среде.

Поэтому вместо обычных инструментов для отладки вроде gdb у меня есть другой набор инструментов для отладки развертывания. И мой любимый инструмент для борьбы с проблемой типа "Почему это ПО у меня не пашет?" называется strace.

Читать полностью »

в 7:27, , рубрики: BGP, connectivity, critical asn, IPv4, IPv6, ptr, reliability, Блог компании Qrator Labs, децентрализованные сети, Сетевые технологии

2019 National Internet Segments Reliability Research & Report - 1

This report explains how the outage of a single AS can affect the connectivity of the impacted region with the rest of the world, especially when it is the dominant ISP on the market. Internet connectivity at the network level is driven by interaction between autonomous systems (AS’s). As the number of alternate routes between AS’s increases, so goes the fault-resistance and stability of the internet across the network. Although some paths inevitably become more important than others, establishing as many alternate routes as possible is the only viable way to ensure an adequately robust system.

The global connectivity of any AS, regardless of whether it is a minor provider or an international giant, depends on the quantity and quality of its paths to Tier-1 ISPs. Usually, Tier-1 implies an international company offering global IP transit service over connections to other Tier-1 providers. But there is no guarantee that such connectivity will be maintained. Only the market can motivate them to peer with other Tier-1’s to deliver the highest quality service. Is that enough? We explore this question in the IPv6 section below. For many ISPs at all levels, losing connection to just one Tier-1 peer would likely render them unreachable in some parts of the world.

Measuring Internet Reliability

Let’s examine a case where an AS experiences significant network degradation. We want to answer the following question: “How many AS’s in the region would lose connectivity with Tier-1 operators and their global availability along with it?”
Читать полностью »

в 9:28, , рубрики: actors, clustering, distributed computing, elasticity, Elixir, erlang, Erlang mi fa stare bene, Erlang/OTP, event-driven programming, fault tolerant, flexibility, functional programming, high-load, message-passing, performance, reactive programming, reliability, responsiveness, scalability, Анализ и проектирование систем, распределенные системы, функциональное программирование

Строительные блоки распределенных приложений. Первое приближение - 1

В прошлой статье мы разобрали теоретические основы реактивной архитектуры. Пришло время поговорить о потоках данных, путях реализации реактивных Erlang/Elixir систем и шаблонах обмена сообщениями в них:

в 16:39, , рубрики: architecture, BGP, connectivity, internet segment, reliability, Russia, Блог компании Qrator Labs, Разработка систем связи, Сетевые технологии

As many of our readers know, Qrator.Radar is constantly researching global BGP connectivity, as well as regional. Since the Internet stands for “Interconnected Networks,” to ensure the best possible quality and speed the interconnectivity of individual networks should be rich and diverse, with their growth motivated on a sound competitive basis.

The fault-resistance of an internet connection in any given region or country is tied to the number of alternate routes between ASes. Though, as we stated before in our Internet Segments Reliability reports, some paths are obviously more critical compared to the others (for example, the paths to the Tier-1 transit ISPs or autonomous systems hosting authoritative DNS servers), which means that having as many reachable routes as possible is the only viable way to ensure adequate system scalability, stability and robustness.

This time, we are going to have a closer look at the Russian Federation internet segment. There are reasons to keep an eye on that segment: according to the numbers provided by the RIPE database, there are 6183 autonomous systems in Russia, out of 88664 registered worldwide, which stands for 6.87% of total.

This percentage puts Russia on a second place in the world, right after the USA (30.08% of registered ASes) and before Brazil, owning 6.34% of all autonomous systems. Effects of changes in the Russian connectivity could be observed across many other countries dependant on or adjacent to that connectivity, and ultimately by almost any ISP in the world.
Читать полностью »

в 15:46, , рубрики: devops, distributed systems, fault tolerance, kubernetes, load balancing, prometheus, reliability, Блог компании Southbridge, Серверное администрирование, системное администрирование

Проверки работоспособности и постепенная деградация распределенных систем - 1

Как всегда, спасибо Фреду Хеберту и Саргуну Дхиллону за то, что прочли черновик этой статьи и предложили нескольких бесценных советов.

В своем докладе о скорости Тамар Берковичи из Box подчеркнула важность проверок работоспособности при автоматическом аварийном переключении баз данных. В частности, она отметила, что мониторинг времени выполнения сквозных запросов, как метод определения работоспособности базы данных, — лучше, чем простое эхо-тестирование (пингирование).

... перебрасывая трафик на другую ноду (реплику), чтобы устранить бездействие, надо построить средства защиты от дребезга и других пограничных ситуаций. Это не сложно. Фокус при организации эффективной работы в том, чтобы знать, когда перевести базу данных в первую позицию, т.е. надо быть в состоянии правильно оценить работоспособность базы данных. Сейчас многие параметры, на которые мы привыкли обращать внимание, — например, загрузка процессора, время ожидания блокировки, частота ошибок, — являются вторичными сигналами. Ни один из этих параметров на самом деле не говорит о способности базы данных к обработке клиентского трафика. Поэтому, если используете их для принятия решения о переключении, можете получить как ложноположительные, так и ложноотрицательные результаты. Наше устройство проверки работоспособности фактически выполняет простые запросы к узлам базы данных и использует данные о выполненных и невыполненных запросах для более точной оценки работоспособности базы данных.

Я обсудила это с другом, и он предположил, что проверки работоспособности должны быть предельно простыми, и что реальный трафик — это лучший критерий для оценки работоспособности процесса.

Читать полностью »

в 11:05, , рубрики: algorithms, Chain replication, CRAQ, design, Distributed Databases, Eventual consistency, fault tolerance, FAWN, FAWN-DS, FAWN-KV, Geo-replication, Hibari, HyperDex, key-value store, nosql, reliability, Strong consistency, Алгоритмы, Анализ и проектирование систем, математика, Программирование, распределенные системы
Chain replication: построение эффективного KV-хранилища (часть 2-2) - 1

Продолжаем рассматривать примеры использования цепной репликации. Базовые определения и архитектуры были даны в первой части, рекомендую ознакомиться с ней перед прочтением второй части.
Читать полностью »

в 11:26, , рубрики: algorithms, Chain replication, CRAQ, design, Distributed Databases, Eventual consistency, fault tolerance, FAWN, FAWN-DS, FAWN-KV, Geo-replication, Hibari, HyperDex, key-value store, nosql, reliability, Strong consistency, Алгоритмы, Анализ и проектирование систем, математика, Программирование, распределенные системы
Chain replication: построение эффективного KV-хранилища (часть 1-2) - 1

В данной статье рассмотрим архитектуры простых и эффективных KV-хранилищ с использованием цепной репликации (chain replication), которая активно исследуется и успешно применяется в различных системах.
Читать полностью »

в 20:57, , рубрики: Failure rate, MTTF, reliability, Анализ и проектирование систем, Блог компании Нерепетитор.ру, математика, надежность, Электроника для начинающих

В предыдущей статье мы рассмотрели терминологию и математическую основу расчетов отказоустойчивости различных систем и выяснили, что на практике, когда речь идет об оценках MTTF (Mean Time To Failure — среднего времени до отказа) и других характеристик надежности, в большинстве случаев предполагается, что отказы подчиняются пуассоновской модели. Соответственно, их вероятностное описание основано на экспоненциальном распределении вероятностей.

Этот материал будет посвящен практическим аспектам применения этой модели, причем стоит сразу оговориться, что он широко используется, как в электронике, так и в самых разных областях: например, при оценке рисков в авиационной и атомной отрасли, прогнозирования в автопроме, оценке надежности облачных сервисов в Интернете и т.п. Общим предположением, повторюсь, является гипотеза о постоянстве интенсивности отказов λ, которая, как мы увидели из предыдущей статьи, обратно пропорциональна среднему времени безотказной работы MTTF=1/λ.

Итак, давайте для начала рассмотрим совсем простой пример: устройство, состоящее из двух элементов, для каждого из которых известны интенсивности отказов λ1 и λ2. Отказ любого из элементов приводит к отказу устройства в целом. Например, компьютер (условно) можно представить, как систему, состоящую из процессора и материнской платы. Пусть для них среднее время до отказа (MTTF) равны 2 и 3 годам (соответственно, λ1=1/2 года-1 и λ2=1/3 года-1). Какова будет оценка MTTF для компьютера, в целом? И какова вероятность отказа компьютера через 1 год после начала эксплуатации?

Читать полностью »

в 20:12, , рубрики: Failure rate, Mathcad Express, MTTF, Relex, reliability, Windchill Quality Solutions, Блог компании Нерепетитор.ру, вероятность отказа, интенсивность отказов, математика, статистика, теория надежности, метки: , ,

Понятиям MTTF (Mean Time To Failure — среднее время до отказа) и другим терминам теории надежности посвящено большое количество статей, в том числе на Хабре (см., например, тут). Вместе с тем, редкие публикации «для широкого круга читателей» затрагивают вопросы математической статистики, и уж тем более они не дают ответа на вопрос о принципах расчета надежности электронной аппаратуры по известным характеристикам ее составных элементов.

В последнее время мне довольно много приходится работать с расчетами надежности и рисков, и в этой статье я постараюсь восполнить этот пробел, отталкиваясь от своего предыдущего материала (из цикла о машинном обучении) о пуассоновском случайном процессе и подкрепляя текст вычислениями в Mathcad Express, повторить которые вы сможете скачав этот редактор (подробно о нем тут, обратите внимание, что нужна последняя версия 3.1, как и для цикла по machine learning). Сами маткадовские расчеты лежат здесь (вместе с XPS- копией).
Читать полностью »

12
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js