Как уже ответили выше, Вы изобрели велосипед, под названием EventBus. Есть много имплементаций, например, из Guava. Событийное программирование — это огромный антипаттерн, который использовать нужно с особой осторожностью, а по возможности избегать вообще.
Согласен с предыдущим пользователем. Имеем несколько крупных проектов EAI. А это сплошной меппинг между огромным количеством структур, в основном xml. После большого количества итераций было установлено, что тупой джавовский меппинг объектов удобнее в поддержке в 10 раз, чем все остальные способы. Пользовались и графическими мепперами, и различными фреймворками и xslt. Приходилось писать большое число тестов для мепперов (а написание теста по трудоемкости в 2 раза превышает написание самого меппера). Основные проблемы:
1. Несовместимость объектов. Приходилось писать большое число custom-мепперов с достаточно сложной логикой, вдвойне усложненной самими ограничениями фреймворка.
2. Не type-safe-ность. Когда сверху «спускали» новую версию интерфейсов, проводилась огромная работа по установлению какие мепперы задеты изменением.
В итоге решение было — генерация java-объектов через JAXB с последующим ручным меппингом. Плюсы налицо: полная свобода, type-safe, простая возможность custom-логики, поддержка IDE (попапы с полями здорово помогают), повторное использование мепперов в разных структурах, моментальное отслеживание изменений. Для ускорения работы и более чистого кода используем xtend.
С удовольсткием наблюдаю за развитием Котлина. Язык неплохой, однако для его широкой популяризации необходимо, чтобы он и занял определенную практическую нишу. А для этого нужна демонстрация не самого языка, а решений реальных задач. Груви именно этим и взял — концентрация не на самом языке, а на вещах, которые при помощи него можно делать очень просто. Надо чем-то завлечь пользователей, например простотой и удобством, с одной стороны оставаясь совместимым с Java, с другой — предлагая свои, более удобные API, DSL-и и builder-ы, библиотеки, инфраструктуру и набор тулзов; плюс что-то, чего нет у других, напр. компиляция в JS. Чтобы хотелось иметь:
— STL — отчасти враппер для java API, отчасти набор полезных утилит и абстракций (Guava-like).
— Веб фреймворк (Kara — блеск!)
— ORM-библиотека. Хочется что-то вроде скаловского Squeryl.
— Простые в использовании средства работы с XML, type-safe меппинга объектов в XML (наподобие JAXB, XMLBeans, etc) и JSON, а также простая имплементация Restful и WS.
— Плагин для Eclipse!
> Второй момент, почему-то неочевидный для многих разработчиков — изменение данных никогда не блокируют чтение.
Еще более неочевидный момент, Oracle не поддерживает Serializable уровень изоляции. То есть то, что Oracle называют Serializable на самом деле является Snapshot isolation. Оно и понятно — используя MVCC и не имея честных блокировок на чтение true serializable не добиться.
А где подробности? Что они имели ввиду? Сварганить Java-wrapper, дергающий GPU через JNI? Бессмысленно, т.к. джавовские структуры в памяти абсолютно несовместимы с GPU. Основное время будет тратиться на конвертацию-деконвертацию массивов. Либо жестко ограничиться ByteBuffer-ом. Или это претензия на то, что наш Java-код будет прозрачно компилиться JVM в GPU, и это все будет мирно уживаться с обычным интерпретируемым кодом, плюс автоматически оптимизироваться HotSpot-ом там где можно сгенерить код для GPU? Чтож, коммунизм я вижу более реальным ;)
Фиг знает. Обычно у меня куча конфигурируемых компонентов, но всего один конфигурационный файл на все, где свойства для каждого компонента прописываются с неким префиксом. Неплохо бы уметь вытаскивать только эти свойства из одного и того же файла в зависимости от указанного префикса: Cfg(prefix=«db»)…
Пункт первый и второй одновременно! Любая технология, появление которой задерживается столько времени, заведомо будет мертворожденной. Тем более если даже еще не определились с тем, что хотят в итоге получить. Модульность подразумевает следующий функционал:
— подсистема сборки
— подсистема управления зависимостями
— модульная среда выполнения
Прошло уже столько времени, что для каждой из этих вещей давно уже разработаны свои тулзы, и мировая общественность так привыкла к ним, что любые потуги что-то поменять не будут встречены с должным ажиотажем.
Ага. А подобное демо наших конкурентов теперь у меня сидит шилом в заднице. Одним из требований заказчика была отслежка изменений в конфигурации сети в режиме realtime. А realtime для сетей вовсе не означает сиюминутную реакцию (некоторые компании получают данные об изменении конфигурации сети дай бог раз в сутки и живут нормально). Наши конкуренты в своем демо естественно никаких изменений с сетью не производили, а тупо апдейтили базу данных. Поэтому изменения, яко бы отправленные в сеть, в демке появлялись фактически моментально. Проект выиграли мы, но теперь мой начальник требует с меня подобную скорость работы с уже реальной системой, мотивируя тем, что клиенту понравилось, и у них уже все договорено. Все мои аргументы, что требование realtime идет вразрез с остальными (консолидация и целостность данных, возможность ручного коммита изменений) тупо отметаются. Вот понравилось им как на демке!
Зависит опять же от специфики работы. Основная черта месседжинг-систем — это асинхронность, то есть работа по принципу отправил-и-забыл. Хорошо там, где это применимо: подписчики на события, слабо связанные компоненты системы, интерфейс со сторонними системами. Спорным решением проектирования здесь является паттерн request-reply, реализованный через асинхронную очередь. И явной ошибкой является его реализация в одной транзакции, несмотря на то, что JMS позволяет такое. Если нужна только распределенность и отказоустойчивость в рамках синхронного запроса, годится и обычный JNDI+EJB — большинство серверов умеют это делать прозрачно для клиента. Поэтому использовать JMS везде как универсальный транспорт для всей системы, на мой взгляд, плохая идея.
Давайте разберемся. Теорему CAP еще никто не отменял. В бизнес приложениях, связанных с продажей и деньгами, consistency является одним из ключевых параметров. В для веба требуется хороший availability. Поэтому как ни крути архитектурой, узкое горлышко останется именно в persistence store partitioning. Так и поступили, заменив Oracle RAC на in-memory distributed store, и погнали бочку на трехуровневую архитектуру. Вместо этого можно было бы все оптимизировать в рамках прежней системы.
1. На картинке обозначены 2 горлышка: Business Tier и Data Tier. Надо поправить, что с точки зрения архитектуры Business Tier не является узким местом в плане масштабирования, потому как не хранит общего состояния (shared state). J2EE архитектура изначально была задумана как распределенная. Добавить новый нод в Weblogic — пара щелчков мышкой в консоли. Остается только Data Tier.
2. Из картинки непонятна специфика работы интернет-магазина. Веб не только осуществляет транзакции, но также читает данные о продуктах из базы данных. И соотношение read/write запросов может достигать 10:1 (а реально намного больше). Поэтому грузит базу данных именно веб своими запросами на чтение. В этом случае поможет упомянутая прослойка в виде распределенного кеша, например Oracle Coherence. Чтобы архитектура была идентична представленному XAP, нужно добавить асинхронный сброс изменений в bb.dd, который увеличит производительность в десятки раз, однако в случае сбоя дает вероятность потерять целостность.
3. Бизнес логика. Обозначена одним блоком с кучей процессов внутри. А именно она определяет всю кухню. Если хреново написано — тут никакая архитектура не поможет. Задача магазина простая — операции со счетами и логистикой. Пара select-ов и update-ов. Здесь целое поле для оптимизации.
4. JMS. А нахрена он вообще здесь нужeн? MoM и JMS хороши для связи со сторонними системами, чтобы иметь наименьшую зависимость от них. Тут есть свои паттерны проектирования типа ESB. Внутри-то апликации зачем нужна асинхронность на каждом уровне, если все операции должны делаться внутри одной транзакции? Обычный remote EJB call или на крайняк WS! Пересылка каждого persistent-сообщения JMS делает как минимум 2 жестких апдейта в JMS persistence store. Поэтому скорость пересылки JMS невелика: benchmark Apache ActiveMQ давал около 1000 сообщений в секунду, что мало для системы, где все основано на JMS. Плюс геморрой с мониторингом всего этого. Если так нужна асинхронность, есть asynchronous beans.
5. Еще Over 9000 причин, связанных с реализацией и не связанных с архитектурой, которые могут быть выявлены профайлингом или стрессовым тестированием.
Вывод: низкая производительность зависит в большей мере от деталей реализации, нежели от выбранной архитектуры, о которых сложно судить, не обладая всем объемом информации.
Просто некорректна сама идея рассуждать о Вселенной в размерах песочницы. Отсюда идеи вроде «великого фильтра» и подобное. Отсутствие наблюдаемого контакта с другими цивилизациями связана с огромными масштабами и практически нулевой вероятностью данного события.
1. Органиченный временной интервал. Это основная ошибка — полагать, что начиная с какого-то момента цивилизация вступает в космическую эру и остается там навсегда, и поэтому мы должны «слышать» более древних, чем мы. Нам сложно представить во что перерождаются цивилизации после эпохи освоения космоса — превращаются в богов, единый суперорганизм, либо замыкаются в себе, создают виртуальные миры и живут там, и тому подобное. Но нужно четко себе осознавать, что это происходит, и после этого контакт с ними становится невозможен. Время космической эры в масштабах Вселенной очень мало (наша цивилизация по космическим масштабам не существует и секунды). Поэтому вероятность, этих интервалов у двух цивилизаций очень мала.
2. Ограниченное пространство. Область, которую способна исследовать даже развитая космическая цивилизация, незначительна даже в галактических масштабах. Поэтому пересечение этой области с областью, занятой другой цивилизацией, маловероятно. Плюс вероятность самого факта обнаружения чужих очень мала, даже в масштабах одной звездной системы. Две цивилизации могут строить базы на разных планетах, спутниках, и даже на одной планете, и ничего не знать друг о друге.
3. «Экзотическая» форма. Цивилизация может настолько отличаться во всех аспектах от привычной нам формы, что мы просто не замечаем ее. Отличается все: материальные носители, структура, логический фундамент, etc. Как пример не помню у какого фантаста, описывались организмы, живущие в фотосфере звезд, тела которых состоят из плазмы. Другой пример (встречается у многих): вся биосфера планеты, которая является разумной, но никакой организм в отдельности не обладает разумом.
Чтобы получить финальную вероятность, нужно естественно перемножить п.1*2*3. Вот поэтому все и тихо :)
Ну и естественно, это все если предположить, что межзвездные перелеты впринципе возможны… )
Для меня важна домашняя неформальная обстановка, когда офис представляет собой некое подобие закрытого клуб по интересам. Понятно, что бесплатные ништяки в итоге недодаются в зарплате. Однако работнику они необходимы, чтобы почувствовать преимущество своей компании над другими. К сожалению, большинство компаний похожа на проходной двор, где напрочь отсутствует обстановка. Пул безликих рабочих мест, соответствующих нормам, и два социальных места: кофейный автомат и курилка.
Можно (и нужно) сделать официальный запрос в Роскомнадзор и потребовать от них протокол действий по вашему делу. Они обязаны будут его предоставить со всеми предпринятыми шагами. Если протокол не совпадает с текущим законодательсовом, например там отсутствует такая вещь как уведомление, можно треботвать немедленной отмены решения о блокировке и возмещении ущерба. У меня знакомый юрист так гаишников тролит. Все заплаченные штрафы себе вернул.
Другое дело, что факт отсутствия уведомления не подшить к делу. Они естественно отчитаются, что все было послано в срок на такой-то адрес. А уж в том, что не пришло обязательно обвинят клиента. И логи smtp тут не помогут.
Всю жизь пользовался этим:
Clip clip = Applet.newAudioClip( url );
clip.play();
От джавы больше не требовалось.
На линуксе джава работает со звуком отвратительно. Использует старый OSS, поэтому паралельно два клипа не звучат. Каждый раз при проигрывании открывает OSS-порт. Иногда оставляет открытым, и звуки вообще перестают звучать. Единственная штука, которая работала нормально — это java media framework. Но этот проект уже over 10 лет как в дауне.
Единственная точнейшая наука — это математика. Физика тоже построила достаточно надежную и проверенную модель мира. Остальные науки, исследующие более сложные системы, используют фактически один единственный метод — статистику. В частности биология (и особенно генетика) занимаются статистическим поиском корреляции между свойствами A и B (привет британским ученым!), в частности между геном и признаком, ввиду того, что на данном этапе модель функционирования организма далека от завершения и механизм влияния гена на свойство неясен. Поэтому текущая модель основана на ряде гипотез, полученных путем статистической обработки экспериментов, дающих определенную достоверность.
Что касается теорий, объясняющих прошлое, будь то избитая до синяков теория эволюции, теория происхождения жизни, археология, или теория образования планетарных систем, то они вообще не имеют права называться теориями ввиду того, что не может быть соблюден основной методологический принцип — фальсифицируемость, то есть проверяемость. В частности для теории эволюции мы не наблюдаем эволюцию живых организмов (имеется ввиду макроэволюцию). Из неорганики до сих пор никто не смог получить даже простейшие репликаторы. Так что это все гипотезы, а не теории. А раз так, относится к ним надо как к гипотезам, а не как к истинам в последней инстанции, и самое главное — разрешить свободную конкуренцию оных в научной среде. Но людям нужна религия, даже в научной среде. И неповиновение оной строго карается.
> Наука, к Вашему сведению, не состоит из одних закостенелых ортодоксов, шарахающихся от любого нестандартного подхода.
Вы удивитесь, но для серьезной науки это именно так. Один из знакомых физиков как-то сказал, что цикл «обновления» науки — 50-60 лет, когда наконец «свежие» идеи наконец будут приняты научным сообществом. И связано это с тем, что старые идеи отмирают вместе с их носителями. Имеются ввиду не сами научные результаты и инновационные методы, а именно идеи и их философская интерпретация. И если с точными науками все более-менее сносно, то науки, чье здание базируется на эмпирической недоказуемой гипотезе (биология, история...), требуют от своих адептов жесткого подчинения идее. Любые альтернативные мысли заведомо объявляются еретическими.
> Но, извините, когда предлагаемый подход уже изначально грубо попирает базовые научные методы, то здесь вообще нечего проверять.
Я не отрицаю, в 99.9% случаев лежит шарлатанство, особенно раскручиваемое СМИ.
Видите ли, в основе современной физики уже лежит определенная невоспроизводимость результата, поскольку нынешняя модель вероятностна.
> Где эти положительные результаты, о которых Вы говорите ru.wikipedia.org/wiki/%D0%9F%D0%B0%D1%80%D0%B0%D0%BF%D1%81%D0%B8%D1%85%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F
Занимались, и, как видите в достаточной мере. Но реакция академической науки всегда стандартна: то, что мы способны объяснить (непротиворечит текущей главенствующей идее) объявляется нерелевантным. То, что наука не способна объяснить объявляется недостоверным. Впрочем, так было всегда, и это имеет свою логику.
Научный подход устанавливает строгие критерии достоверности, которые в данном контексте соблюсти очень сложно. Например есть проблема репродуцируемости результатов. То есть если группа ученых в работе с конкретным человеком по исследованию экстрасенсорных способностей обнаруживает определенную корреляцию (то есть ответы не случайные), это не значит, что другая группа ученых в работе с этим же человеком (или другим) человеком сможет ее обнаружить. Результаты этих исследований очень нестабильны и зависят от многих (порой неизвестных) факторов. Тем не менее эксперименты ставились и ставятся и дают положительные результаты.
Другая проблема — желтизна темы экстрасенсорики. Заявить о полученных результатах для ученого — это потерять свой иммидж.
☐ спроектировать распределённую систему на самом деле тяжело
☐ а реализовать — ещё тяжелее
Самое тяжелое — оттестировать и удостоверится, что система действительно надежна. Многие следуют принципу «система надежна, пока не доказано обратное» и решают проблемы по мере их появления в продакшне. Вероятность многих сбоев настолько мала, что те реально вообще никогда не появляются.
1. Несовместимость объектов. Приходилось писать большое число custom-мепперов с достаточно сложной логикой, вдвойне усложненной самими ограничениями фреймворка.
2. Не type-safe-ность. Когда сверху «спускали» новую версию интерфейсов, проводилась огромная работа по установлению какие мепперы задеты изменением.
В итоге решение было — генерация java-объектов через JAXB с последующим ручным меппингом. Плюсы налицо: полная свобода, type-safe, простая возможность custom-логики, поддержка IDE (попапы с полями здорово помогают), повторное использование мепперов в разных структурах, моментальное отслеживание изменений. Для ускорения работы и более чистого кода используем xtend.
— STL — отчасти враппер для java API, отчасти набор полезных утилит и абстракций (Guava-like).
— Веб фреймворк (Kara — блеск!)
— ORM-библиотека. Хочется что-то вроде скаловского Squeryl.
— Простые в использовании средства работы с XML, type-safe меппинга объектов в XML (наподобие JAXB, XMLBeans, etc) и JSON, а также простая имплементация Restful и WS.
— Плагин для Eclipse!
Еще более неочевидный момент, Oracle не поддерживает Serializable уровень изоляции. То есть то, что Oracle называют Serializable на самом деле является Snapshot isolation. Оно и понятно — используя MVCC и не имея честных блокировок на чтение true serializable не добиться.
db.driver=aaa
db.url=bbb
db.user=XXX
db.password=YYY
ws.url=…
ws.user=…
ws.passwd=…
component1.prop1=…
component1.prop2=…
— подсистема сборки
— подсистема управления зависимостями
— модульная среда выполнения
Прошло уже столько времени, что для каждой из этих вещей давно уже разработаны свои тулзы, и мировая общественность так привыкла к ним, что любые потуги что-то поменять не будут встречены с должным ажиотажем.
1. На картинке обозначены 2 горлышка: Business Tier и Data Tier. Надо поправить, что с точки зрения архитектуры Business Tier не является узким местом в плане масштабирования, потому как не хранит общего состояния (shared state). J2EE архитектура изначально была задумана как распределенная. Добавить новый нод в Weblogic — пара щелчков мышкой в консоли. Остается только Data Tier.
2. Из картинки непонятна специфика работы интернет-магазина. Веб не только осуществляет транзакции, но также читает данные о продуктах из базы данных. И соотношение read/write запросов может достигать 10:1 (а реально намного больше). Поэтому грузит базу данных именно веб своими запросами на чтение. В этом случае поможет упомянутая прослойка в виде распределенного кеша, например Oracle Coherence. Чтобы архитектура была идентична представленному XAP, нужно добавить асинхронный сброс изменений в bb.dd, который увеличит производительность в десятки раз, однако в случае сбоя дает вероятность потерять целостность.
3. Бизнес логика. Обозначена одним блоком с кучей процессов внутри. А именно она определяет всю кухню. Если хреново написано — тут никакая архитектура не поможет. Задача магазина простая — операции со счетами и логистикой. Пара select-ов и update-ов. Здесь целое поле для оптимизации.
4. JMS. А нахрена он вообще здесь нужeн? MoM и JMS хороши для связи со сторонними системами, чтобы иметь наименьшую зависимость от них. Тут есть свои паттерны проектирования типа ESB. Внутри-то апликации зачем нужна асинхронность на каждом уровне, если все операции должны делаться внутри одной транзакции? Обычный remote EJB call или на крайняк WS! Пересылка каждого persistent-сообщения JMS делает как минимум 2 жестких апдейта в JMS persistence store. Поэтому скорость пересылки JMS невелика: benchmark Apache ActiveMQ давал около 1000 сообщений в секунду, что мало для системы, где все основано на JMS. Плюс геморрой с мониторингом всего этого. Если так нужна асинхронность, есть asynchronous beans.
5. Еще Over 9000 причин, связанных с реализацией и не связанных с архитектурой, которые могут быть выявлены профайлингом или стрессовым тестированием.
Вывод: низкая производительность зависит в большей мере от деталей реализации, нежели от выбранной архитектуры, о которых сложно судить, не обладая всем объемом информации.
1. Органиченный временной интервал. Это основная ошибка — полагать, что начиная с какого-то момента цивилизация вступает в космическую эру и остается там навсегда, и поэтому мы должны «слышать» более древних, чем мы. Нам сложно представить во что перерождаются цивилизации после эпохи освоения космоса — превращаются в богов, единый суперорганизм, либо замыкаются в себе, создают виртуальные миры и живут там, и тому подобное. Но нужно четко себе осознавать, что это происходит, и после этого контакт с ними становится невозможен. Время космической эры в масштабах Вселенной очень мало (наша цивилизация по космическим масштабам не существует и секунды). Поэтому вероятность, этих интервалов у двух цивилизаций очень мала.
2. Ограниченное пространство. Область, которую способна исследовать даже развитая космическая цивилизация, незначительна даже в галактических масштабах. Поэтому пересечение этой области с областью, занятой другой цивилизацией, маловероятно. Плюс вероятность самого факта обнаружения чужих очень мала, даже в масштабах одной звездной системы. Две цивилизации могут строить базы на разных планетах, спутниках, и даже на одной планете, и ничего не знать друг о друге.
3. «Экзотическая» форма. Цивилизация может настолько отличаться во всех аспектах от привычной нам формы, что мы просто не замечаем ее. Отличается все: материальные носители, структура, логический фундамент, etc. Как пример не помню у какого фантаста, описывались организмы, живущие в фотосфере звезд, тела которых состоят из плазмы. Другой пример (встречается у многих): вся биосфера планеты, которая является разумной, но никакой организм в отдельности не обладает разумом.
Чтобы получить финальную вероятность, нужно естественно перемножить п.1*2*3. Вот поэтому все и тихо :)
Ну и естественно, это все если предположить, что межзвездные перелеты впринципе возможны… )
Другое дело, что факт отсутствия уведомления не подшить к делу. Они естественно отчитаются, что все было послано в срок на такой-то адрес. А уж в том, что не пришло обязательно обвинят клиента. И логи smtp тут не помогут.
Clip clip = Applet.newAudioClip( url );
clip.play();
От джавы больше не требовалось.
На линуксе джава работает со звуком отвратительно. Использует старый OSS, поэтому паралельно два клипа не звучат. Каждый раз при проигрывании открывает OSS-порт. Иногда оставляет открытым, и звуки вообще перестают звучать. Единственная штука, которая работала нормально — это java media framework. Но этот проект уже over 10 лет как в дауне.
Что касается теорий, объясняющих прошлое, будь то избитая до синяков теория эволюции, теория происхождения жизни, археология, или теория образования планетарных систем, то они вообще не имеют права называться теориями ввиду того, что не может быть соблюден основной методологический принцип — фальсифицируемость, то есть проверяемость. В частности для теории эволюции мы не наблюдаем эволюцию живых организмов (имеется ввиду макроэволюцию). Из неорганики до сих пор никто не смог получить даже простейшие репликаторы. Так что это все гипотезы, а не теории. А раз так, относится к ним надо как к гипотезам, а не как к истинам в последней инстанции, и самое главное — разрешить свободную конкуренцию оных в научной среде. Но людям нужна религия, даже в научной среде. И неповиновение оной строго карается.
Вы удивитесь, но для серьезной науки это именно так. Один из знакомых физиков как-то сказал, что цикл «обновления» науки — 50-60 лет, когда наконец «свежие» идеи наконец будут приняты научным сообществом. И связано это с тем, что старые идеи отмирают вместе с их носителями. Имеются ввиду не сами научные результаты и инновационные методы, а именно идеи и их философская интерпретация. И если с точными науками все более-менее сносно, то науки, чье здание базируется на эмпирической недоказуемой гипотезе (биология, история...), требуют от своих адептов жесткого подчинения идее. Любые альтернативные мысли заведомо объявляются еретическими.
> Но, извините, когда предлагаемый подход уже изначально грубо попирает базовые научные методы, то здесь вообще нечего проверять.
Я не отрицаю, в 99.9% случаев лежит шарлатанство, особенно раскручиваемое СМИ.
Видите ли, в основе современной физики уже лежит определенная невоспроизводимость результата, поскольку нынешняя модель вероятностна.
> Где эти положительные результаты, о которых Вы говорите
ru.wikipedia.org/wiki/%D0%9F%D0%B0%D1%80%D0%B0%D0%BF%D1%81%D0%B8%D1%85%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F
Занимались, и, как видите в достаточной мере. Но реакция академической науки всегда стандартна: то, что мы способны объяснить (непротиворечит текущей главенствующей идее) объявляется нерелевантным. То, что наука не способна объяснить объявляется недостоверным. Впрочем, так было всегда, и это имеет свою логику.
Другая проблема — желтизна темы экстрасенсорики. Заявить о полученных результатах для ученого — это потерять свой иммидж.
☐ а реализовать — ещё тяжелее
Самое тяжелое — оттестировать и удостоверится, что система действительно надежна. Многие следуют принципу «система надежна, пока не доказано обратное» и решают проблемы по мере их появления в продакшне. Вероятность многих сбоев настолько мала, что те реально вообще никогда не появляются.