Что такое система мониторинга

Основы распределённого мониторинга: четыре золотых сигнала

Мы в ForePaaS уже какое-то время экспериментируем с DevOps — сначала в одной команде, а теперь и по всей компании. Причина проста: организация растет. Раньше у нас была всего одна команда на все случаи жизни. Она занималась архитектурой, проектированием и безопасностью продукта и быстро реагировала на любые проблемы. Сейчас мы разделились на несколько команд по специализации: фронтенд, бэкенд, разработка, эксплуатация…

Мы поняли, что наши прежние методы будут не так эффективны и нужно что-то менять, при этом сохранить скорость без ущерба для качества и наоборот.

Раньше девопсами мы называли команду, которая, по сути, делала Ops, а еще отвечала за разработки на бэкенде. Раз в неделю другие разработчики говорили команде DevOps, какие новые сервисы надо задеплоить в продакшене. Иногда это приводило к проблемам. С одной стороны, команда DevOps не очень понимала, что происходит у разработчиков, с другой — разработчики не чувствовали ответственность за свои сервисы.

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

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

Пример панели мониторинга Grafana с четырьмя золотыми сигналами для мониторинга сервиса.

Что такое мониторинг?

Мониторинг — это создание, сбор, объединение и использование метрик, которые позволяют получить представление о состоянии системы.

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

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

Созданную таким образом метрику нужно еще собрать и объединить с другими. Эта задача обычно решается с помощью Metricbeat для сбора и Logstash для индексирования метрик в Elasticsearch. Потом эти метрики можно использовать в своих целях. Обычно этот стек дополняет Kibana, которая визуализирует данные, индексированные в Elasticsearch.

Зачем мониторить?

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

Что мониторить?

В книге Site Reliability Engineering есть полезная глава про мониторинг распределенных систем, где описан подход Google, основанный на отслеживании «четырех золотых сигналов» (Four Golden Signals).

Beyer, B., Jones C., Murphy, N. & Petoff, J. (2016) Site Reliability Engineering. How Google runs production systems. O’Reilly. Бесплатная онлайн-версия: https://landing.google.com/sre/sre-book/toc/index.html

Как мониторить?

Возьмем, например, стек технологий. Обычно мы выбираем популярные стандартные инструменты вместо кастомных решений. Кроме случаев, когда доступного функционала нам недостаточно. Большинство сервисов мы деплоим в средах Kubernetes и инструментируем код, чтобы получать метрики о каждом кастомном сервисе. Чтобы собрать эти метрики и подготовить их для Prometheus, мы используем одну из клиентских библиотек Prometheus. Там есть клиентские библиотеки почти для всех популярных языков. В документации можно узнать все необходимое, чтобы написать свою библиотеку.

Если это сторонний опенсорс-сервис, мы обычно берем экспортеры, предложенные сообществом. Экспортеры — это код, который собирает метрики из сервиса и форматирует их для Prometheus. Обычно они используются с сервисами, которые не генерируют метрики в формате Prometheus.

Мы отправляем метрики по пайплайну и храним их в Prometheus в виде временных рядов. Кроме того, мы используем kube-state-metrics в Kubernetes, чтобы собирать и отправлять метрики в Prometheus. Затем мы можем создавать дашборды и алерты в Grafana, используя запросы к Prometheus. Вдаваться в технические детали мы здесь не будем, поэкспериментируйте с этим инструментами сами. У них подробная документация, вы легко разберетесь.

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

Задержка

Задержка — это время, которое занимает обработка запроса. Мы отдельно измеряем задержку для успешно выполненных запросов и для ошибок. Мы не хотим, чтобы эта статистика смешивалась.

Обычно учитывается общая задержка, но не всегда это хороший выбор. Лучше отслеживать распределение задержки, потому что оно больше соответствует требованиям к доступности. Доля запросов, которые обрабатываются быстрее заданного порога, — это распространенный показатель уровня обслуживания (SLI). Вот пример целевого уровня обслуживания (SLO) для этого SLI:

«В течение 24 часов 99% запросов должны обрабатываться быстрее, чем за 1 секунду»

Самый наглядный способ представить метрики задержки — график временных рядов. Мы помещаем метрики в бакеты, и экспортеры собирают их каждую минуту. Таким образом можно рассчитать n-квантили для задержек сервисов.

Источник

Что такое мониторинг и его уровни

Поговорим о том, какие уровни мониторинга бывают и что стоит измерять и анализировать в IT-проектах.

Зачем нужен мониторинг и что это такое

Случается, что серверы падают и программы ломаются. Это неизбежно. Случайный баг, скачок напряжения в сети, сбои в подаче электричества — всё это может вызывать поломки.

Кроме того, помимо очевидных проблем, могут быть и куда менее очевидные. Например, менеджеры по продукту приняли плохое решение, реализовали плохую фичу и из-за нового релиза упала выручка. Технически код хорошо работает, серверы в порядке — но бизнес несет убытки.

Начнем снизу: мониторинг оборудования

Что бы вы ни запускали — у вас всё равно будут серверы в дата-центре, а у них есть определенные параметры производительности. Эти показатели надо мониторить на каждом сервере, обслуживающем ваших клиентов:

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

Для анализа поведения серверов в самом простом виде можно использовать штатные средства контроля по типу htop. Более гибкое и масштабируемое решение — Zabbix — он уже умеет анализировать основные параметры целого кластера серверов и собирать их в одной панели. Такое решение требует настройки со стороны квалифицированного администратора.

Поднимаемся выше: мониторинг состояния приложений

Допустим, мониторинг серверов у нас есть и они выглядят адекватно. Памяти много, нагрузка на процессор — незначительная. Наверное, всё хорошо организовано, клиентов немного, всё работает как часы? Может быть. Или всё упало, программы не запущены, клиенты не могут попасть на сервер и выполнить запросы? Тоже может быть.

Какой из вариантов правильный — подскажут метрики приложений.

У любого приложения должны быть параметры, по которым разработчики и администраторы понимают, что программа работает и в ней что-то делается. У каждой программы эти параметры свои, но вот несколько примеров, которые позволят понять, какие метрики нужно придумать для приложения:

У вас в системе 100 активных пользователей, они генерируют 1 000 запросов в минуту и у них случается 1 ошибка в час? Допустим, что всё хорошо. У вас в системе 3 активных пользователя, они генерируют 10 000 запросов в минуту и ловят 5 000 ошибок? Наверное, стоит начать беспокоиться. Даже если метрики нагрузки на процессор и диски в порядке.

Для мониторинга на этом уровне подойдет специализированная СУБД — Prometheus, Graphite, InfluxDB. С установкой самой базы данных проблем не будет, а вот посчитать и пробросить нужные метрики в базу — для этого понадобятся усилия программистов.

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

Есть еще специфические системы отлова ошибок в коде — они могут вовремя оповестить программистов о сбойной ситуации. Иногда этого вполне достаточно для базовой диагностики проблем. Хороший пример такой системы — Sentry.

Третий уровень: мониторинг бизнес-метрик

Конечная цель любой программы — решать чьи-то проблемы и получать за это деньги. Это значит, что для управленцев нужны метрики, которые расскажут:

Список метрик, которые нужны бизнесу, велик и зависит от конкретного проекта и индустрии. Лучше всего вам помогут разобраться с правильными параметрами менеджеры продукта.

Минимально здесь можно обойтись Google Analytics — базовые конверсии и переходы можно смотреть в готовых системах анализа пользовательского поведения. Более глубокое понимание ситуации потребует четкой и слаженной работы администраторов, программистов и ребят из отдела аналитики — они смогут правильно реализовать и посчитать тонкие поведенческие аспекты. Например, зависимость выручки от A/B-тестов на бэкенде.

Источник

система мониторинга

2.19 система мониторинга: Совокупность процедур, процессов и ресурсов, необходимых для проведения мониторинга.

Смотри также родственные термины:

60 система мониторинга и администрирования (сетью железнодорожной электросвязи); СМА: Программно-технический комплекс управления и контроля сетевыми элементами и сетью, обеспечивающий функционирование сети с нормируемым качеством, эффективное использование всех ее ресурсов в интересах пользователей и других сетей, предупреждение отказов и сокращение времени восстановления при их возникновении, повышение производительности труда обслуживающего персонала.

3.27 система мониторинга инженерно-технического обеспечения: Совокупность технических и программных средств, позволяющая осуществлять сбор и обработку информации о различных параметрах работы системы инженерно-технического обеспечения здания (сооружения) в целях контроля возникновения в ней дестабилизирующих факторов и передачи сообщений о возникновении или прогнозе аварийных ситуаций в единую систему оперативно-диспетчерского управления города.

3.26 система мониторинга инженерно-технического обеспечения: Совокупность технических и программных средств, позволяющая осуществлять сбор и обработку информации о различных параметрах работы системы инженерно-технического обеспечения здания (сооружения) с целью контроля возникновения в ней дестабилизирующих факторов и передачи сообщений о возникновении или прогнозе аварийных ситуаций в единую систему оперативно-диспетчерского управления города.

3.36. система мониторинга инженерных (несущих) конструкций, опасных природных процессов и явлений; СМИК: Подсистема СМИС, осуществляющая в режиме реального времени контроль изменения состояния оснований, строительных конструкций зданий и сооружений; сооружений инженерной защиты, зон схода селей, оползней, лавин в зоне строительства и эксплуатации объекта мониторинга с целью предупреждения чрезвычайных ситуаций.

3.36 система мониторинга инженерных (несущих) конструкций, опасных природных процессов и явлений; СМИК: Подсистема СМИС, осуществляющая в режиме реального времени контроль изменения состояния оснований, строительных конструкций зданий и сооружений; сооружений инженерной защиты, зон схода селей, оползней, лавин в зоне строительства и эксплуатации объекта мониторинга с целью предупреждения чрезвычайных ситуаций.

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

2.26. Система мониторинга состояния оборудования: система (машина), продуктом которой является текущая информация о техническом состоянии оборудования и его опасности с необходимыми комментариями (прогноз остаточного ресурса, предписания на неотложные действия персонала и т.д.) и заданным риском.

2.26. Система мониторинга состояния оборудования: система (машина), продуктом которой является текущая информация о техническом состоянии оборудования и его опасности с необходимыми комментариями (прогноз остаточного ресурса, предписания на неотложные действия персонала и т.д.) и заданным риском.

3. Обозначения и сокращения

В настоящем стандарте применены следующие сокращения.

4.1 Принципы построения систем мониторинга

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

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

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

4.1.4. Принцип инвариантности регламентирует выбор и селекцию таких диагностических признаков, которые инвариантны к конструкции оборудования и форме связи с параметрами ее технического состояния, что обеспечивает применение стандартных процедур без эталонной диагностики и прогнозирования ресурса машин и, соответственно, быстрые темпы разработки и внедрения СМ, переводя их в разряд стандартных промышленных систем обеспечения безопасности оборудования и процессов.

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

4.1.6. Принцип структурной гибкости и программируемости обеспечивает реализацию оптимальной параллельно-последовательной структуры ИДС, исходя из критериев необходимого быстродействия при минимальной стоимости. Системы с параллельной сосредоточенной структурой (VME-VXI) имеют максимальное быстродействие при максимальной стоимости. Системы с последовательной распределенной структурой имеют минимальное быстродействие при минимальной стоимости. Системы с последовательно-параллельной структурой занимают промежуточное положение. Главным недостатком применения параллельных систем во взрывопожароопасных производствах является большой расход кабеля, стоимость которого соизмерима со стоимостью СМ. Выбор структуры системы (степени параллельности) требует оценки ее необходимого быстродействия. Последнее определяется скоростью деградации технического состояния диагностируемого объекта и, как показывает опыт, для насосно-компрессорного оборудования опасных производств нефтегазовой отрасли период опроса датчиков не должен превышать 5 мин.

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

Структурная схема системы мониторинга (СМ):

4.1.10. Принцип организации производственных исполнительных систем предприятия (MES-систем) реального времени обеспечивает автоматический ввод в систему планирования ресурсов предприятия информации о состоянии оборудования, поставленной СМ, планах его ремонта т.д., обеспечивая техническое обслуживание и ремонт оборудования (ТОРО) по фактическому техническому состоянию.

4.2. Структурная схема системы

4.2.1. Общая структурная схема системы мониторинга приведена на рисунке.

4.2.2. Объект мониторинга представляет собой совокупность агрегатов 1-1. 1-k. 1-N, каждый из которых содержит до m узлов 2, подлежащих диагностированию. В качестве таких уз лов определяют те, которые ограничивают надежность и ресурс агрегатов и опасных производств в целом.

4.2.3. Диагностические сигналы <ζ>_m = <ζ₁. ζ_m> от диагностируемых узлов 2 через каналы 3 распространения колебаний N_ij поступают на точки внешней поверхности агрегата и далее в систему мониторинга 4, где воспринимаются ее датчика ми 5-i, 1=I=n с использованием методов неразрушающего контроля (МНК): акустического, акустико-эмиссионного, вибродиагностического, визуально-измерительного (параметрического), вихретокового, магнитного, оптического, теплового, радиоволнового, электрического и др.

4.2.4. Анализатор сигналов 9 и блок формирования диагностических признаков 10 осуществляют преобразование массива входных сигналов в массив диагностических признаков, связанных с состоянием объектов на основе алгоритмов цифровой обработки сигналов.

4.2.5. Блок принятия решения 11 на основании входного массива диагностических признаков и эксплуатационных данных, хранящихся в информационной базе данных и знаний 14, определяет состояние объектов и выдает требуемую диагностическую информацию, и/или указания по приведению объекта в допустимое состояние.

4.2.6. Блок оповещения, отображения и регистрации 12 доводит информацию о состоянии оборудования до персонала с использованием различных каналов; визуального (дисплей системы), звукового, осуществляет распечатку протоколов (принтер системы).

4.2.7. Посредством блока сетевых интерфейсов 13 информация о состоянии оборудования передается внешним заинтересованным службам по выделенным Ethernet каналам, последовательным каналам (RS232, 485), телефонным линиям с использованием модемов.

4.2.8. Информационная база данных и знаний 14 содержит:

— базы данных конфигурации диагностируемого оборудования, конфигурации системы, базы данных значений диагностических признаков, сигналов, трендов, журналов, и других необходимых для работы системы данных;

— базы знаний, необходимые для работы экспертной системы.

4.2.9. Блок управления и синхронизации 15 осуществляет общее управление всей системой по определенному алгоритму и/или набору адаптивных алгоритмов.

4.3. Классификация систем мониторинга (СМ)

Устанавливается классификация систем мониторинга по следующим факторам:

— числу и виду используемых МНК;

— по типу экспертной системы;

— по объему выявляемых неисправностей;

— по величине статической ошибки распознавания состояния оборудования;

— по величине динамической ошибки распознавания состояния оборудования;

— по величине риска пропуска внезапного отказа;

— по числу измерительных каналов системы;

— по способу опроса датчиков;

— по типу используемого анализатора сигналов;

— по типу индикатора состояния;

— по наличию и уровню диагностической сети;

— по типу управления.

4.3.1. Классификация по числу и виду используемых МНК

Устанавливаются следующие группы систем:

1. Комплексные системы.

2. Специализированные системы.

Специализированные системы используют один из МНК (например, согласно [13]). Комплексные системы используют набор различных МНК.

4.3.2. Классификация по типу экспертной системы

Устанавливаются следующие группы систем:

1. Системы поддержки принятия решений (ЭСППР).

2. Диагностические (ЭСД).

3. Системы индикации состояния (СИС).

Системы индикации состояния осуществляют только определение технического состояния объекта (годен/не годен), без указаний на вид неисправности.

Диагностические системы наряду с определением технического состояния должны определять одну или несколько причин (вид) неисправного состояния объекта.

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

4.3.3. Классификация по объему выявляемых неисправностей

Устанавливаются следующие группы систем:

Системы узкого класса выявляют неисправности только одного узла агрегата, например подшипника.

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

4.3.4. Классификация по величине статической ошибки распознавания состояния оборудования

Устанавливаются следующие группы систем:

1. Низкой статической ошибки.

2. Средней статической ошибки.

3. Высокой статической ошибки.

Системы низкой статической ошибки должны иметь ошибку 30%.

4.3.5. Классификация по величине динамической ошибки распознавания состояния оборудования

Устанавливаются следующие группы систем:

1. Низкой динамической ошибки.

2. Средней динамической ошибки.

3. Высокой динамической ошибки.

Системы низкой динамической ошибки должны иметь ошибку 30%.

4.3.6. Классификация по величине риска пропуска внезапного отказа

Устанавливаются следующие группы систем:

1. Низкого риска пропуска.

2. Среднего риска пропуска.

3. Высокого риска пропуска.

Системы низкого риска пропуска должны иметь величину риска пропуска внезапного отказа 30%.

4.3.7. Классификация по числу измерительных каналов системы

Устанавливаются следующие группы систем:

4.3.8. Классификация по способу опроса датчиков

Устанавливаются следующие группы систем:

1. Универсальные (параллельно-последовательные).

Последовательные системы осуществляют поочередное измерение сигналов и их обработку. Последовательные измерения могут проводиться как автоматически, так и человеком-оператором (переносные системы).

Универсальные (параллельно-последовательные) системы имеют смешанную структуру: устанавливаются группы каналов, внутри группы каналы измеряется последовательно и затем осуществляется параллельная обработка выходных сигналов групп и/или наоборот.

Параллельные системы осуществляют одновременное измерение сигналов и их последующую обработку.

4.3.9. Классификация по архитектуре

Устанавливаются следующие группы систем:

Вся аппаратура сосредоточенной системы (за исключением датчиков) размещается в одном месте, как правило, на удалении от объекта контроля.

Аппаратура распределенной системы может размещаться непосредственно на объекте контроля.

4.3.10. Классификация по типу используемого анализатора сигналов

Устанавливаются следующие группы систем:

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

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

4.3.11. Классификация по типу индикатора состояния

Устанавливаются следующие группы систем:

Простые индикаторы состояния имеют только функцию отображения состояния объекта.

Многоуровневые индикаторы состояния наряду с отображением состояния объекта должны иметь функции отображения состояний и параметров различных его составных частей.

Комплексные индикаторы состояния включают функции много уровневых индикаторов и должны отображать даты пуска/ останова систем и агрегатов, их наработки на разные виды ремонта, прогноз остаточного ресурса, а также выводить информацию по следующим каналам: звуковой вывод, печать протоколов, передача данных по сети (публикация на Web сервере).

4.3.12. Классификация по наличию и уровню диагностической сети

Устанавливаются следующие группы систем:

1. Автоматическая диагностическая сеть.

2. Ручная диагностическая сеть, интегрированная с переносными системами.

3. Ручная диагностическая сеть.

4. Нет диагностической сети.

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

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

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

4.3.13. Классификация по типу управления

Устанавливаются следующие группы систем:

Ручные системы выполняют большинство функций мониторинга под управлением человека-оператора.

Автоматические системы мониторинга должны выполнять все функции мониторинга автоматически. Человек в автоматических системах может использоваться как звено управления для выдачи управляющих воздействий на объект.

4.4. Определение класса системы

4.4.1. Класс системы определяют по выражению:

(1)

Системы первого класса имеют К=1.

Системы второго класса имеют К=2.

Системы третьего класса имеют К=3.

4.4.2. Пример расчета класса систем для показателей классификации, представленных выше, приведен в табл. 1.

Источник