Комментарии 8
Как по мне, самый правильный подход — это принципиально разный ux для цифр разных порядков. К примеру, в clickhouse при стандартной настройке таблицы меньше 50 ГБ удаляются без вопросов, а больше — с реальным гемором.
То есть, человек, войдя в поток, и думая, что работает с дев средой, и при этом, попав на прод, должен получить неожиданный сбой в доведенных до автоматизма действиях.
К примеру, до 10 серверов, вообще не требовать даже y/n, с 50 до 100 — написать число. А для 1000+ потребовать число, потом 10 секунд показывать обратный отсчёт с возможностью отменить.
Тогда, человека вовремя выбьет из потока, и он опомнится, что, блин, что-то не то и не так.
Если жестить даже на малых числах, то пробивание сквозь стену станет обыденным и автоматическим
Если жестить даже на малых числах, то пробивание сквозь стену станет обыденным и автоматическим
Не станет. Будет фактором +100 к раздражению (думаю, все знают гуглокаптчу "выбрать всех котиков на картинке"), при это -10 к пониманию процесса из-за отвлечения на этот фактор, т.е. чел вообще забудет про сервера и после котиков вновь надо будет возвращаться к серверам, и вполне возможно, что чел вспомнит про сервера, но уже забудет, что он на проде, а не на стейдже
Именно поэтому жестить не надо. В этом согласен
Коллега делал миграцию, заторонуты несколько десятков а то и сотен датацентров. Часть миграции — удалить все записи в старом формате, там предупреждение типа указаного.
Где-то на десятом датацентре коллега стал не особо проверяя копи-пастить число из предупреждения. Где-то на двадцатом сделал опечатку и удалит 1000000 записей вместно 100000.
После восстановления бекапа начали писать полную автоматизацию (с тестами и всеми делами) чтобы исключить опечатки.
Для продолжения введите точное число машин