Опытный разработчик не так давно зашёл в .Net и поставил цель получить сертификат Microsoft. Свой ежедневный прогресс он описывает на канале .Net Разработчик. Заметки об изученном материале, советы по повышению производительности и поддержке мотивации, ин
День 1508. #ЗаметкиНаПолях
Создавайте Аварийные Пути в Вашем ПО
Вы должны проверять входные данные, предполагать, что они враждебны, перепроверять их на каждом слое и т. д. Это принципы написания хорошего кода. Когда всё идёт гладко, хочется запретить недопустимые операции и опасные действия. Проблемы возникают, когда что-то идёт не так.
Концепция аварийных операций — это то, что должно быть основной частью дизайна, потому что чрезвычайные ситуации случаются, и вам не хотелось бы искать пути обхода в режиме аврала.
Допустим, истекает срок действия корневого сертификата, а значит, аутентификации нет. Вы не можете аутентифицироваться на серверах, потому что срок действия используемого вами сертификата аутентификации также истёк. Вам нужен физический доступ, но дата-центр вас не пустит, так как вы не можете аутентифицироваться. Это не фантастика, это случилось недавно в Facebook (не сертификаты, а плохая конфигурация IP, но суть та же).
Важным аспектом хорошего дизайна является рассмотрение действительно плохих сценариев и как вы будете восстанавливаться после этого? В сложных системах можно найти перекрёстные зависимости. Например, сервис аутентификации зависит от кластера базы данных, который использует сервис аутентификации для аутентификации. Если оба не работают одновременно, вы не сможете их запустить.
Частью разработки хорошего ПО является построение аварийных путей. Когда система ломается, есть ли у вас чётко определенная операция, которую вы можете предпринять для её восстановления? Отличным примером являются противопожарные выходы в зданиях. Обычно они не используются, но в экстренной ситуации позволяют быстро и безопасно покинуть здание вместо того, чтобы создавать давку на обычных выходах.
Есть различные операции, которые нельзя делать, потому что они опасны, но которые в то же время позволяют вам оправиться от катастрофы. Можно создать две конечных точки для таких операций. Первая будет включать все возможные проверки, а вторая только для администратора, которая явно предназначена для сценария «Я знаю, что я делаю».
Заблаговременное проектирование этих аварийных путей означает, что вы можете делать это в спокойной обстановке и рассмотреть больше вариантов. Это также означает, что вы можете убедиться, что ваш аварийный механизм не мешает нормальной работе.
Наличие этих процедур, задокументированных и проверенных, оказывается действительно важным во время кризиса. Вам не нужно спотыкаться в темноте или на лету придумывать новые способы что-то исправить. Это особенно важно, так как вы не можете быть уверены, что обычные инварианты, действующие в обычной ситуации, также действуют в случае сбоя.
Очень легко забыть создать такие функции или даже решить, что они не нужны. В конце концов, надо потратить много времени на проектирование и реализацию того, что никогда (надеемся) не будет использовано. Контраргумент заключается в том, что в зданиях устанавливают пожарную сигнализацию и системы пожаротушения с явной надеждой и намерением никогда не использовать их на практике.
Источник: https://ayende.com/blog/198625-A/building-emergency-pathways-in-your-software-never-to-be-used