Программное обеспечение для обеспечения высокой доступности и аварийного восстановления AntiPatterns

Question

Если вам нужно было провести аудит приложения Java для наихудших практик, когда дело доходит до высокой доступности и аварийного восстановления, вы, вероятно, будете искать жестко закодированные IP-адреса и субоптимальное кэширование ручек привязки. Что еще нужно учитывать?

Answer 1

Отсутствие действий/регистрация состояния.

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

Лучшее, что нужно сделать, это запланировать некоторое время простоя и проверить его. У вас будет еще много проблем. После того, как все будет задокументировано, попросите кого-нибудь сделать это без вашей помощи. ;)

Answer 6

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

Failover/HA: Здесь вы определяете свой SPoF - одиночные точки отказа. Примеры включают жестко заданные адреса, как вы упомянули, но также приложения, которые хранят данные в невоспроизводимых средствах, таких как локальный диск. Другие элементы могут кэшировать DNS-запросы для «слишком долгого», а не для восстановления отлаженных соединений, поиска конкретной информации об оборудовании (таких как MAC-адреса, идентификаторы CPUID, ключи, метки разделов, серийные номера MB или дисков и т. Д.). Я видел все это как проблемы, приводящие к ненужным обходным решениям для обеспечения функциональности BCP/DR.

Целостность данных: Как хранятся данные? Использует ли он пользовательский формат/структуру? Если есть механизм «дампа и восстановления»? Должна ли служба прекратить обслуживание клиентов или же она ухудшает ее обслуживание для резервного копирования? Записывает ли он данные на устройство асинхронно, и если да, то как часто он «размывается» на диск (иногда это зависит от приложения, другие - не столько)? Блокировка файлов, таймфреймы и возможности хранения памяти для постоянного хранения также являются частью этого.

По существу посмотрите, что может заставить вас работать.Затем посмотрите, как это пришло, и вы, вероятно, начнете разрабатывать две важные части знаний: шаблоны, используемые для улучшения BCP/DR, и, как вы упомянули, AntiPatterns, которые вызывают проблемы. Внедрение этих типов вопросов в процесс разработки, как только это возможно, поможет вашим разработчикам получить шаблоны и анти-шаблоны, которые вы ищете. Часто просто задавая вопросы, это предотвращает проблемы.