Высокая доступность и аварийное восстановление программного обеспечения AntiPatterns - PullRequest
4 голосов
/ 02 мая 2009

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

Ответы [ 6 ]

4 голосов
/ 02 мая 2009

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

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

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

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

3 голосов
/ 02 мая 2009

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

3 голосов
/ 02 мая 2009

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

3 голосов
/ 02 мая 2009

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

1 голос
/ 12 июля 2010

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

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

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

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

0 голосов
/ 02 мая 2009

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

...