Итак, мы перепрыгнули через несколько препятствий и реализовали предшествующую выполнению кода проверку: если выясняется, что мы находимся на сервере, где размещается основная база данных нашей группы доступности, обработка кода продолжается. В ином случае при выполнении шага № 1 возникает ошибка, и задание завершается нормально. Впрочем, препятствий, на мой взгляд, пожалуй, многовато.
Конструкция, возникающая при выполнении такого задания, с трудом поддается логическому анализу (к примеру, стороннему специалисту, привлеченному для проведения диагностики, если при выполнении задания возник какой- то сбой, возможно, не удастся сразу сообразить, что именно здесь было сделано). Но есть и более серьезная проблема: что же, собственно, мы получаем в итоге при использовании такого подхода?
Проведем небольшое сравнение. Что мы увидим в окне истории выполнения заданий на сервере, где размещается основная реплика целевой базы данных, показано на экране 9.
На мой взгляд, картина превосходная, я бы даже сказал — идеальная. В соответствии с графиком задание выполняется каждые 10 минут, и при этом видно, что оба шага осуществляются без каких- либо проблем. А теперь сравним эту картинку с той, что мы можем наблюдать на экране истории заданий на неосновном сервере (см. экран 10).
Эта картинка, на мой взгляд, никуда не годится. Да, задание действительно выполняется корректно, раз в 10 минут, как и предполагалось. К тому же, если вы предусмотрели генерацию предупреждений или оповещений, дабы получать соответствующую информацию в случае, если задание завершится сбоем, тогда… минутку, задание не завершилось сбоем, а значит, никаких предупреждений вы не получите! Так что все работает прекрасно, как и следовало ожидать.
Проблема, однако, состоит в том, что, если вы проверяете работу сервера и пытаетесь понять, как ведет себя то или иное задание, вы меньше всего заинтересованы в том, чтобы увидеть в окне истории заданий целую серию предупреждений или список конечных результатов. Как мне кажется, это означало бы слишком большое смешение в пропорции «шум—сигнал». На мой взгляд, отображать тревожные сообщения или предупреждения, касающиеся тех или иных проблем, нужно лишь в тех случаях, когда речь идет о проблемах, требующих внимания или даже вмешательства со стороны оператора. Именно оэтому я не хотел бы внедрять такое решение в рабочие сети.
Итак, рассматриваемый подход работает, но:
- в нем довольно непросто разобраться;
- он вынуждает оператора совершать прыжки через слишком большое количество препятствий (в том смысле, что если мы упустим хотя бы одно звено в цепочке действий, все может пойти не так, как задумано);
- этот метод создает угрозу того, что либо вы, либо члены вашей команды могут подумать, будто где-то произошел сбой (чего не было на самом деле).
Учитывая все это, я могу сказать, что не являюсь сторонником такого подхода. У меня другая позиция: лучший метод тот, который предусматривает динамическую активацию или деактивацию заданий в зависимости от того, содержат ли серверы, на которых они выполняются, целевую или основную реплику. Этому вопросу будет посвящена следующая статья.
Комментарии