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

Question

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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