10) Паритет разработки/работы приложения. Держим среду разработки идентичной среде развертывания. Если на проде используется Postgres, то локально мы тоже используем Postgres, никаких SQLite/Oracle/MySQL, иначе вы очень рискуете стать тем самым «а у меня локально все работает» парнем. На моей практике различие версии одной зависимости между стейджем и продом привели к двухнедельному кранчу. Фактор обеспечивает способность непрерывного развертывания приложения за счет минимизации различий между средами разработки и исполнения.
11) Журналирование. Логи как поток событий. Приложение отдает контроль за своими логами на аутсорс стороннему инструментарию(привет ELK, а если точнее, то logstash). Каждый процесс пишет логи в стандартный вывод, а там оно уже как-нибудь «само». Почему? Опять же: для простоты масштабирования. Еще важно подчеркнуть — логи рассматриваются как поток событий(одна строка логов — одно событие системы), из которых формируется журнал. Журнал — это поток агрегированных, упорядоченных по времени событий, собранных из потоков вывода всех запущенных процессов и вспомогательных сервисов. По сути это такой же текстовый файл, но его можно визуализировать для удобства(привет Kibana).
12) Администрирование. Выполняем администрирование в разовых процессах, причем среда выполнения таких процессов идентична среде выполнения всего приложения. К администрированию относится выполнение миграций, запуск разовых скриптов(например пользака с админскими правами создать), и тому подобное. Очень сильно перекликается с 10 пунктом и нужно по тем же причинам: если мы будем запускать приложение в одной среде, а администрировать приложение в другой, мы точно в конечном итоге нарвемся на рассогласование конфигураций. Хранить разовые скрипты рекомендуется рядом с основным кодом приложения.