Я подслушал разговор, в котором вы, вероятно, слышали свой вариант. Один парень так гордился тем фактом, что до сих пор у него не было серьезной конфронтации со своей супругой. Ах, идеальный союз.
В то время как некоторые присоединились к нему в признательности, мне пришлось скрыть настоящие мысли, приходящие в голову:
«Вот дерьмо, ему может повезти, и у него действительно идеальная ситуация, а когда что-то закипает, они никогда не практиковали искусство несогласия. Они никогда не работали в сложной ситуации »
Устойчивое программное обеспечение
Это напомнило мне похожий разговор, который я имел некоторое время назад, когда я услышал, как администратор так гордился тем, что одна машина не работала больше года. Это меня тоже до чертиков напугало. Это означало, что перезапуск не тестировался больше года, и можете ли вы представить себе магию и неразбериху, которые были созданы? Это одна из причин, по которой люди в восторге от неизменяемых серверов или, по крайней мере, от наличия систем, которые создаются с нуля.
Я создаю новое приложение, и оно должно быть не только мобильным, но и автономным. Вероятно, подобным образом следует спроектировать большую часть опыта. В наши дни вы замечаете обратное, и часто в приложениях, которые были созданы до мобильной революции. Постфактум часто бывает намного сложнее подключиться к автономному режиму.
Когда вы создаете оффлайн первого клиента, вы, как правило, получаете несколько отличных побочных преимуществ:
- Если вы работаете с локальными данными, вы можете сохранить отзывчивый пользовательский интерфейс (если вы умеете избегать основного потока!)
- Вы можете постепенно улучшать, находясь в сети
- Например, когда DuoLingo соответствует введенному вами ответу, простое совпадение может произойти локально, в то время как более сложное совпадение может быть начато онлайн (если клиент не в сети).
Вы также можете попасть в ситуацию, когда вы не синхронизированы. Клиент и сервер видят разные версии реальности.
Shift + перезагрузить
Оглядываясь назад, нам повезло в дни Интернета 1.0. Мы могли выполнять рендеринг исключительно на сервере, а клиент представлял собой тупой терминал, который воссоздавал себя при каждом запросе. Поскольку браузеры получили более широкое кэширование, нам потребовалось предоставить пользователям ядерную опцию: Shift + Reload. Не совсем удобен для пользователя, но он наверняка пригодился (и до сих пор пользуется!).
В наши дни нам нужно следить за тем, чтобы наши богатые клиенты не коррумпировались. Чтобы наши клиенты могли хорошо работать в автономном режиме, у них есть местный штат и данные, над которыми нужно работать. Мы все были разочарованы, когда обнаруживалась ошибка, которую нельзя было легко исправить.
Один из примеров для меня - установка приложений на свои устройства. По мере того, как я печатаю, я попал в ситуацию, когда моя загрузка зависла, но у меня нет возможности запустить ее или даже удалить. Когда это происходит, происходит что-то очень неприятное, когда версия shift + reload не исправляет ситуацию. Буквально вчера мы с коллегой создали одни и те же проекты на Asana, потому что не видели, чтобы другой уже сделал это. Мне потребовалась целая вечность, чтобы увидеть его версию и очистить ее.
Трудно понять это правильно. Мы пытаемся сделать правильные вещи для пользователя, кэшируя и сохраняя адаптивность их приложений, но мы должны воспользоваться некоторыми подсказками и иметь системы, которые могут помочь. Если пользователь убивает и перезапускает свое приложение, это современный сдвиг + перезагрузка, не так ли?
Микросервисы
Теоретически рождение микросервисов и попытки скрыть сложность функциональности за красивыми, чистыми и развязанными API-интерфейсами помогают нам добиться устойчивости. На практике я видел, как это обернулось настоящим беспорядком. Дело не в практике, а в деталях реализации. Вот что я видел, пошло не так:
Объем услуг определен неправильно
- В одном примере объем, казалось, был функцией размера команды по сравнению с естественным составом функциональности.
Убийцы взаимозависимости
- Были отдельные небольшие сервисы, но все они зависели друг от друга. Результатом стало много разговоров о том, что «была развернута новая версия службы X, которая нарушила работу службы Y в QA».
Нет представления о системе как о целом
- Когда что-то идет не так, как вас узнают? Как же тогда найти, в чем проблема? Из-за недостаточного обзора всей системы получить эту информацию может быть сложно. Вы должны явно потратить время на швы
Плохая обработка исключений
- Ненавижу, когда все ошибки и исключения рассматриваются как равные. Это приводит к тому, что исключения закрытых сокетов попадают в смесь, где они вообще не были ошибками…. клиент просто отключился, и все было нормально! Как только вы ошибаетесь, вы получаете море информации, которой нельзя доверять, а убийственные ошибки могут остаться незамеченными. Я слишком долго видел шокирующие ошибки в продакшене из-за этого: /
Указательный палец
- Худшие ситуации возникают, когда вы постоянно указываете пальцем. Что-то не так в системе, но каждая команда спорит о том, что на самом деле сломано. Команды служб указывают друг на друга и указывают на специалистов по сети, которые указывают на специалистов по инфраструктуре, которые… указать обратно на народные службы!
Очень важно заранее потратить время на то, чтобы опередить это. Здесь тоже блистают определенные платформы. Erlang известен тем, что считает отказоустойчивость своим основным принципом. Различные реактивные платформы работают хорошо, но, хотя они могут улучшить вашу жизнь, вам нужно проявлять осторожность.
Мне часто приходилось зажимать нос и делать нечистое. У меня есть настраиваемые уровни прокси, которые выполняют автоматические повторные попытки, когда базовая часть ядра должна быть исправлена. Это рискованно, потому что в конечном итоге вы можете увеличить трафик и вызвать еще больше проблем, но если все сделать правильно, это может спасти ваш бекон.
Вы прошли и определили SLA, необходимый для различных услуг? Так часто мы видим наименьший общий знаменатель, когда лучше разделить вещи. В качестве примера, если вы посмотрите на API, который предоставляет вам информацию о продукте (описание, цена, доступность, обзоры, изображения и т. Д.), Вам может понадобиться актуальная цена, но эти обзоры? Не так много. Вы, вероятно, справитесь отлично без этого единственного обзора, который только что пришел. В этом случае вы, вероятно, захотите сказать эквивалент:
«Попробуйте получить самые свежие отзывы, но если они не вернутся в Xms, используйте последние полученные…. и когда этот вызов вернется, обновите кеш, может быть, в следующий раз, круто? "
Неудивительно, что хапи, которое Эран Хаммер и его команда начали со мной в Walmart, делают это очень хорошо благодаря кошачьей коробке, а также с микросервисами в целом.
Для получения отличного современного опыта, который работает быстро и хорошо работает для ваших пользователей, скорее всего, вам следует:
- Создайте автономный первый клиент, но дайте ему достаточно интеллекта, чтобы справиться с коррупцией и вернуться к нормальному состоянию, даже с ядерными опциями.
- Создайте уровень служб, предполагающий сбой на каждом уровне и способный корректно устранить этот сбой.
- Постепенно улучшайте взаимодействие как на клиенте, так и на сервере, чтобы основная служба всегда работала, но она также может включать функции и настройки, когда они доступны.
И как только у вас что-то будет работать, начните приносить свой код на консультацию, чтобы система могла научиться справляться с разногласиями и сбоями;)
