Человек лишающий себя права на ошибку,
рано или поздно сталкивается с тем что
это и есть его самая большая ошибка (c)
В прошлой заметке я писал о стратегии минимизации ошибок и для чего она нужна и услышал ряд откликов с критикой нехватки примеров. Эта заметка будет посвящена как раз примерам и некоторым логическим паттернам минимизации рисков разработки и эксплуатации сложных систем .
1. «Выполни и умри!» (Do and Die)
Это уже давно известный шаблон, который, тем не менее игнорируют постоянно. Смысл в том что приложение разделяется на несколько модулей – процессов или нитей (которые Thread) взаимодействующих друг с другом, но способных выживать независимо. Эти процессы делятся на центральный (диспетчек) и рабочие процессы выполняющие «грязную работу» перемалывания данных. В основном данный подход применим к серверным приложениям, что впрочем не отменяет его полезности для разного типа программ.
Наиболее классический пример Apache, его параметр MaxRequestsPerChild как раз обеспечивает гарантированную смерть процесса по достижению определённого числа запросов. Более радикальная вариация этого подхода, это гарантированное убийство процесса или потока немедленно выполнения задачи.
Да, сделать это сложнее чем если бы просто отрабатывать все запросы в рамках одного сервера, одного потока и одного процесса. Потому как один процесс может упасть, могут быть утечки памяти и могут быть ошибки.
Наиболее ярким примером который мне запомнился – это подобное многопроцессное приложение где из-за ошибки в системной библиотеке с трудом поддающейся лечению рабочие процессы всё время помирали. Но, они успевали выполнить задачу и отдать результаты диспетчеру.
2. «Большой брат» (Big Brother)
Когда приложение является сложным, взаимоувяанным и разнесённым по разным серверам и географическим площадкам, то неизбежно возникают ситуации когда где-то запрос теряется, не принимается или же принимается некорректно. И хорошо ещё если это «one vendor solution» где все транзакции на виду, но куда чаще это интеграция нескольких приложений и слишком часто я лично наблюдал как создатели чешут затылок и часами выясняют в чём же проблема в их Web, Cache, SOAP, WSDL, Remoting, Corba монстроидальном приложении.
В ситуации описанной выше это касается не разработки в части кодирования, это касается разработки в части эксплуатации. Без мониторинга нагрузки, жизни транзаций и доступности всех элементов системы вцелом, рано или поздно наступит момент когда пиши пропало полный караул.
При этом обеспечить такой удалённый мониторинг не столь уж сложно, мне довелось в своё время как создавать его вручную для нескольких задач, так и использовать такой продукт как AdventNet OpManager который бесплатен до определённого числа пробов. Было несколько проектов когда это реально спасало лично мне в итоге много нервов. Я знал что если что-то идёт не так, я или служба поддержки получим об этом сообщение.
Как это касается непосредственно разработчиков? Не стоит ленится и всегда полезно создавать веб страницу статуса для веб приложения или же так или иначе экспортировать метрики приложения, на выбор:
- в файл;
- в таблицу в БД;
- публикуя показатели через SNMP;
- через proc, если Linux
- через веб страницу с возможностью машинной обработки
Continue reading «Практика минимизации ошибок»
