Control plan что это

Обновлено: 14.10.2024

3.1.1 план управления (control plan): Документированное описание систем и процессов, необходимых для управления продукцией (приложение А).

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

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

3.1.1. план управления ( control plan ): Документированное описание систем и процессов, необходимых для управления продукцией (приложение А).

3.4. план управления (качеством): Краткое формализованное описание технологии формирования показателя качества продукции, его контроля и управления процессом производства.

3.13 план управления в условиях инцидента (incident management plan): Детально разработанный и документально оформленный план действий, предназначенный для использования в условиях инцидента, в котором установлены необходимые для управления в условиях инцидента персонал, ресурсы и действия.

2.21 план управления инцидентом (incident management plan): Точно установленный и документально оформленный план действий, предназначенный для использования при возникновении инцидента, который обычно охватывает вовлеченный персонал, необходимые ресурсы и действия, которые должны быть выполнены в процессе управления инцидентом.

2.19 план управления инцидентом (incident management plan): Точно установленный и документально оформленный план действий, предназначенный для использования при возникновении инцидента, который обычно охватывает вовлеченный персонал, необходимые ресурсы и действия, которые должны быть выполнены в процессе управления инцидентом.

Полезное

Смотреть что такое "план управления" в других словарях:

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

План управления водохозяйственной деятельностью — план освоения, эксплуатации, охраны и / или использования конкретных водных ресурсов и объектов в пределах территориального района или зоны подпитывания подземных вод, включая охрану их экосистем. Источник: ПРОТОКОЛ ПО ПРОБЛЕМАМ ВОДЫ И ЗДОРОВЬЯ … Официальная терминология

план управления риском — (напр. при внедрении новой технологии) [А.С.Гольдберг. Англо русский энергетический словарь. 2006 г.] Тематики энергетика в целом EN risk management plan … Справочник технического переводчика

план управления ( control plan ) — 3.1.1. план управления ( control plan ): Документированное описание систем и процессов, необходимых для управления продукцией (приложение А). Источник … Словарь-справочник терминов нормативно-технической документации

План контроля качества

Для каких компаний это может быть полезно

Очень сложно провести границу, когда IT-подразделение начинает нуждаться в подобных вещах. Я бы сказал что DRP вам гарантированно нужно, если:

Остановка сервера, приложения или потеря какой-то базы приведет к значительным потерям бизнеса в целом.
У вас есть полноценный IT-отдел. В смысле отдел в виде полноценной единицы компании, со своим бюджетом, а не просто несколько уставших сотрудников, прокладывающих сеть, чистящих вирусы и заправляющих принтеры.
У вас есть реальный бюджет хотя бы на частичное резервирование в случае аварийной ситуации.

Как правильно тестировать

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

Не допускайте двусмысленностей. Помните про испуганного стажера.

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

Назначение плана контроля качества

План контроля качества также как и оценку рисков (FMEA) рекомендуется применять в целях обеспечения качества выпускаемой продукции, что особенно актуально для производственных операций. План качества предлагается к использованию международным стандартом ISO 10005 QMS — Guidelines for quality plans, как один из самых эффективных инструментов управления производственным процессом.

План контроля качества или план качества (Process Control Plan (PCP), Control Plan, Quality Plan) — это спецификация или документ, определяющий действия , ответственность и соответствующие ресурсы, которые должны применяться в отношении конкретного объекта. План качества разрабатывается на основе проведенного анализа рисков и последствий отказов и по своей структуре и содержанию является следствием документа FMEA, а также требований заказчика. Целью применения плана качества является документально определить кем и когда будут применяться процессы, процедуры и необходимые ресурсы для достижения требований, предъявляемых к проекту, продукту, услуге, процессу или контракту.

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

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

Структура плана контроля качества

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

Общие сведения, такие как редакция документа, дата ввода в действие, наименование процесса, продукт и т.д.
Шаги процесса — необходимы как для структурирования и последовательности выполнения действий, так и для определения момента для начала выполнения действий.
Оборудование и инструмент, используемые при выполнении данного шага.
Параметр процесса — это параметр, который необходимо проверить/проконтролировать.
Характеристика продукции, зависящая от указанного ранее параметра или которую необходимо проверить/проконтролировать.
Спецификация — требование, представляемое к данной характеристике продукции, параметры процесса.
Процедура — каким образом выполняется проверка или что необходимо сделать для проверки.
Частота — когда выполняется данная проверка.
Выборка — указывается применяемая выборка и тип проверки.
Критерий приемки — это критерий для определения, выполняется данное требование или нет.
Ответственный — должностное лицо, ответственное за выполнение данной проверки.
Отметка о выполнении — регистрация подтверждающая проведение проверки данного действия.
Действие, в случае отклонения — что необходимо выполнить в случае, если данное требование не выполнилось.

Применение

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

Готовим DRP — не забудьте учесть метеорит

Даже во время катастрофы всегда есть время на чашку чая

DRP (disaster recovery plan) — это штука, которая в идеале никогда не понадобится. Но если вдруг мигрирующие в брачный период бобры перегрызут магистральное оптоволокно или джуниор-админ дропнет продуктивную базу, вы точно хотите быть уверены, что у вас будет заранее составленный план, что с этим всем безобразием делать.

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

В этом посте я хочу поделиться рекомендациями, как надо писать DRP и что он должен содержать. А еще мы рассмотрим следующие штуки:

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

Мысли как диверсант

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

Обычно, большинство типовых аварийных ситуаций укладывается в следующие виды:

Отказ сети
Отказ сервисов ОС
Отказ приложения
Отказ железа
Отказ виртуализации

После того, как типовые проблемы записаны, наливаем еще кофе и начинаем рассматривать самые странные сценарии, когда какие-то параметры начинают сильно выходить за пределы нормы. Например:

Что случится, если время на активной ноде сдвинется на минуту назад относительно других в кластере?
А если время вперед сдвинется, а если на 10 лет?
Что произойдет, если во время синхронизации нода кластера внезапно потеряет сеть?
А что будет, если две ноды не поделят лидерство из-за временной изоляции друг друга по сети?

Разделение control и data plane в сетевом оборудовании

В работе сетевого устройства можно выделить две абстракции – управляющий уровень (control plane) и передающий уровень (data plane). Сontrol plane отвечает за логику работы сетевого устройства для обеспечения в дальнейшем возможности передачи пакетов (заполнение различных таблиц, например, маршрутизации, отработку различных служебных протоколов ARP/STP/и пр.). Data plane в свою очередь отвечает непосредственно за передачу полезного трафика через наше сетевое устройство. Т.е. сontrol plane нам предоставляет информацию куда и как слать сетевой трафик, а data plane уже выполняет поставленные перед ним задачи. Данные абстракции могут быть выделены как на логическом, так и на физическом уровне. Но всегда ли на сетевом оборудовании присутствует такое разделение и где именно выполняются функции каждой из абстракций? Давайте попробуем в этом разобраться.

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

Если мы обратим свой взор на программно-определяемые сети (Software-defined Network – SDN), мы обнаружим, что управляющий уровень полностью или частично переносится вообще на выделенное устройство. Однако рассмотрение таких решений оставим за рамками данной статьи.

Коммутаторы

Начнём с коммутаторов, так как тут мы получим наиболее наглядное разделение наших абстракций. Главное для коммутатора– скорость передачи данных. Вся обработка пакетов должна реализоваться на скорости порта (wire-speed), иначе коммутатор будет тормозящим элементом в нашей сети. В связи с этим, именно в коммутаторах мы можем обнаружить реализацию передающего уровня на отдельных микросхемах – ASIC’ах (ASIC — интегральная схема специального назначения). Фактически на коммутаторе управляющий уровень выполняется на базе процессора общего назначения, а передающий уровень, как мы уже отметили, на базе ASIC.

Процессоры, которые устанавливаются в сетевое оборудование, зачастую имеют отличия от тех, которые стоят в наших ПК и серверах. Это чаще всего специализированные процессоры, которые рассчитаны на использование внутри различных устройств (сетевых, систем хранения данных и пр.) и относятся к классу встраиваемых процессоров (embedded processors). Обычно они имеют небольшой размер, потребляют немного энергии и являются частью однокристальной системы (System on a chip – SoC). SoC – практически полноценный компьютер, выполненный на базе одной микросхемы (с (микро)процессором, оперативной памятью, контроллером ввода/вывода, интерфейсами и пр.). Некоторые из таких процессоров заточены на выполнение операций в сетевых устройствах, другие имеют более широкий спектр применения. При этом чаще всего на них можно запустить, например, какие-то решения на базе Unix/Linux, так как они всё же остаются в первую очередь процессорами общего назначения.

Классический ASIC имеет предопределённый набор функций, которые выполняются аппаратно. Фактически общая логика обработки пакетов закладывается в ASIC на этапе производства микросхемы, изменить которую достаточно сложно. В ASIC’е мы получаем приемлемый уровень логики и при этом высокую скорость обработки пакетов. Таким образом, высокая производительность в коммутаторе достигается за счёт выполнения функций передающего уровня на ASIC’ах. И именно ASIC’и являются причиной относительно ограниченной логики работы коммутатора, которую сложно дальнейшем изменить. Можно было бы вместо ASIC использовать микросхемы FPGA (Field-Programmable Gate Array), которые можно перепрограммировать. Но они дороги и энергоёмки. Поэтому производители сетевого оборудования, чтобы не увеличивать стоимость своих устройств, с одной стороны, часть обработки пакетов пытаются перенести на процессор общего назначения (т.е. туда где работает управляющий уровень), что не всегда хорошо сказывается на производительности устройства. С другой стороны, стараются модернизировать ASIC, сделав их более функциональными и даже программируемыми (например, ASIC UADP компании Cisco).

Иногда аббревиатура ASIC используется вместе с аббревиатурой SoC. Тут легко можно запутаться, так как ASIC, в котором есть микропроцессор и память, фактически становится решением SoC.

Это чуточку упрощённая формулировка, но для общего понимания, думаю, достаточная. Таким образом, классический ASIC выполнять более специфичные операции, а SoC более общие, так как там есть процессор.
Обычно в коммутаторе стоит один или несколько ASIC’ов. Например, на каждые 12/24 порта ставится свой ASIC. Программирование логики работы ASIC’а выполняет управляющий уровень. Именно он заполняет все таблицы внутри ASIC’а (маршруты, списки доступа и пр.). ASIC может иметь достаточный интеллект, чтобы коммутировать пакеты внутри себя, или же осуществлять коммутацию пакетов через внешнюю шину/коммутационную фабрику. Такая архитектура используется в первую очередь в коммутаторах фиксированной конфигурации (не модульных). Примерами таких коммутаторов могут быть Cisco Catalyst 2960/3650/3850.
В статье в качестве примеров чаще всего будут использоваться устройства компании Cisco. Это обусловлено тем, что данный производитель один из немногих, кто предоставляет достаточно подробную информацию по аппаратной архитектуре всех своих устройств.

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

Если мы имеем дело с модульным коммутатором (коммутатор, в который можно устанавливать платы с различными типами портов), архитектура может быть более сложной. Больше портов, значит, требуется больше производительность и больше ASIC’ов. Существует как минимум два подхода в реализации архитектуры таких коммутаторов.

В первом случае, передающий уровень выполняется централизованно на выделенных ASIC’ах, которые располагаются на отдельной плате. В этом случае ASIC’и на линейных картах являются менее интеллектуальными и выполняют крайне ограниченный набор функций. Программированием логики продолжает заниматься управляющий уровень, которой в свою очередь запускается на своих аппаратных мощностях (используется опять же процессор общего назначения (причём их может быть несколько), расположенный на отдельном модуле — супервизоре). Примером таких коммутаторов могут быть Cisco Catalyst 4500 и Cisco Catalyst 6500/6800 (централизованная коммутация).

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

Возможен вариант, где на каждом модуле с линейными портами, стоит своя специализированная плата передачи. В этом случае каждый модуль имеет свой передающий уровень, что позволяет повысить производительность всей «коробки». Можно сказать, что это промежуточный вариант между первым и вторым подходами реализации архитектуры модульных коммутаторов. Примером таких коммутаторов могут быть Cisco Catalyst 6500/6800 (распределённая коммутация).

* микросхемы Port ASIC, установленные на линейных картах, не обладают большой интеллектуальностью и выполняют крайне ограниченный набор функций

Второй подход – использовать достаточно интеллектуальные ASIC’и на линейных картах. В этом случае каждый ASIC может самостоятельно обработать сетевой трафик, выполняя основной набор функций. Т.е. мы сразу имеем распределённый передающий уровень. Это может оказаться более дорогим решением, но при этом зачастую более производительным. Также мы минимизируем при такой архитектуре задержки при передаче пакетов. Примером подобного коммутатора может быть Cisco Nexus 9500.

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

Отметим, что в коммутаторах мы можем иметь распределение уровня управления. Например, в коммутаторе Cisco Nexus 9500 управляющий уровень внутри одного устройства разнесён: часть функций выполняются на супервизоре, а часть на плате линейных портов (на каждой плате стоит свой процессор общего назначения).

До этого момента всё рассмотрение шло в рамках одного устройства. Но многие коммутаторы умеют объединяться в одно логическое устройство по средствам стекирования. В случае если у нас собран стек из коммутаторов, обычно управляющий уровень запускается на основном коммутаторе (его ещё называют активным/мастером). А передающий уровень будет запущен отдельно на каждом коммутаторе в стеке. Т.е. через стековый канал связи управляющий уровень, расположенный на основном коммутаторе, раздаёт управляющую информацию на все коммутаторы в стеке для работы передающего уровня локально. Примером такой модели работы может быть стек Cisco StackWise или HPE IRF.

Маршрутизаторы

Давайте теперь посмотрим, как обстоят дела с нашими абстракциями в маршрутизаторах. Если мы будем рассматривать относительно бюджетные маршрутизаторы, управляющий и передающий уровни будут выполняться на одном и том же железе — процессоре общего назначения (чаще всего в формате SoC). Процессорное время будет распределяться в этом случае между обеими абстракциями. Никаких специализированных микросхем для передающего уровня, как это было в коммутаторах, мы там не найдём. В связи с этим мы получим очень гибкую логику работы устройства, но не самые выдающиеся значения по производительности (десятки и сотни мегабитов в секунду). Причём разные вендорные ухищрения (например, Cisco Express Forwarding) являются лишь оптимизацией обработки пакетов на программном уровне на базе стандартной аппаратной базы. Примерами таких устройств являются, Cisco 800, 1900, 2900 и пр. Ситуация меняется, если наш процессор общего назначения становится многоядерным (например, в Cisco ISR 4300), да ещё таких процессоров может быть несколько (например, в Cisco ISR 4400). В этом случае управляющий и передающий уровни могут выполняться на разных ядрах и процессорах. Причём передающему уровню выделяется сразу несколько ядер, чтобы получить параллельную обработку пакетов, а значит, повысить производительность нашего устройства. Стоит заметить, что некоторые ядра могут быть отданы вообще под сторонние сервисы (конечно, если процессор это позволяет сделать).

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

Отдельный разговор – это высокопроизводительные маршрутизаторы. В этом случае обычных процессорных мощностей общего назначения может не хватать. Производители сетевого оборудования переносят передающий уровень на отдельное железо, более адаптированное для обработки большого потока трафика. Фактически мы идём к архитектуре коммутаторов. Но так как маршрутизатор более функционален, обычных ASIC’ов не достаточно. В связи с этим каждый производитель предлагает свои решения.

Один из вариантов – использование специализированных сетевых процессоров (Network Processor — NP или Network Processing Unit — NPU). Сетевые процессоры существенно функциональнее, чем ASIC’и, но при этом более производительные, чем процессоры общего назначения.

программируемые – есть возможность запускать на них различные сервисы (МСЭ, IPSec, NAT и пр.), не ограничиваясь стандартными сетевыми функциями L2/L3. Также программируемость позволяет без замены железа добавлять новый функционал;
многопоточные – количество потоков измеряется сотнями (так как процессоры являются многоядерными), что позволяет получить большую производительность;
энергоэффективность – если сравнивать с обычными процессорами, сетевые процессоры предоставляют лучшее соотношение пропускная способность/Вт. Данный параметр в первую очередь влияет на плотность портов на линейных картах устройств.

В качестве примера рассмотрим маршрутизаторы Cisco ASR 1000, где основные функции передающего уровня выполняется на отдельной плате. На такой плате размещается один или два специализированных сетевых процессоров Cisco QuantumFlow Processor (QFP), которые занимаются непосредственно обработкой трафика. Данный процессор имеет архитектуру RISC и заточен именно под передачу трафика. QFP второго поколения включает до 128 процессорных ядер, на каждом из которых может быть запущено четыре отдельных процесса. Т.е. мы имеем до 256 ядер на одной плате (в случае двух процессоров). Сравнив с архитектурой более простых маршрутизаторов, где всё выполняется на нескольких ядрах, можно сразу сделать вывод, что такие маршрутизаторы являются более производительными.

Сетевые процессоры выпускаются различными компаниями (Cisco, EZChip, Broadcom и пр.) и используются для выполнения функций передающего уровня многими производителями сетевого оборудования. Например, сетевые процессоры используются в оборудовании компаний Huawei (как в маршрутизаторах, например, в NetEngine40E, так и в коммутаторах S12700).

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

Кроме сетевых процессоров, на рынке представлены специализированные чипсеты, например, Juniper Trio chipset. Они позиционируются между сетевыми процессорами и ASIC’ами. По большому счёту, общий смысл сохраняется – передающий уровень выполняется на специализированном железе, в данном случае чипсете Trio Chipset. Отметим, что до вывода на рынок Trio chipset, компания Juniper активно использовала в своих маршрутизаторах программируемые ASIC’и собственной разработки (Internet Processor ASIC и I-Chip).

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

В заключение

Так как реализаций архитектур даже у одного вендора достаточно много, рассмотреть их все крайне сложно. Однако, если нам требуется большая производительность, чаще всего передающий уровень будет выполняться на специализированном железе: будь то сетевой процессор, специализированный чипсет, обычный или программируемый ASIC, или что-то ещё. В некоторых устройствах мы встретим даже комбинацию этих микросхем. Нередко производители сетевого оборудования в своём оборудовании используют микросхемы сторонних компаний (например, ASIC’и или сетевые процессоры).

Документация важна

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

После того, как у вас на руках есть хорошее описание компонентов сервиса, поднимите статистику по авариям. Почти наверняка они будут совершенно типовые. Например, у вас время от времени переполняется диск, что приводит к отказу ноды до ее ручной очистки. Или становится недоступен клиентский сервис из-за того, что кто-то опять забыл продлить сертификат, а Let's Encrypt настроить не смог или не захотел.

Что такое этот ваш DRP?!

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

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

В аварийной ситуации думать сложно! Должны быть простые инструкции для парсинга спинным мозгом.

Хороший DRP состоит из нескольких простых блоков:

Кого оповестить о начале аварии. Это важно для того, чтобы максимально распараллелить процесс устранения.
Как правильно диагностировать — выполняем трассировку, смотрим в systemctl status servicename и так далее.
Сколько можно потратить время на каждый этап. Если не успеваете починить руками за время SLA — виртуальная машина убивается и накатывается из вчерашнего бэкапа.
Как убедиться, что авария завершена.

Не надо путать DRP и паспорт системы! Не перегружайте его излишними данными. Просто дайте возможность быстро и удобно по гиперссылкам перейти в нужный раздел документации и почитать в расширенном формате о нужных участках архитектуры сервиса. А в самом DRP только прямые указания куда и как подключаться с конкретными командами для копипасты.

Читайте также: